Configura políticas de seguridad jerárquicas

En esta página, se proporciona información para configurar políticas de seguridad jerárquicas que protejan tu organización, tus carpetas o tus proyectos. Antes de configurar políticas de seguridad jerárquicas, asegúrate de conocer la información que se incluye en la descripción general de las políticas de seguridad jerárquicas.

Configura los permisos de IAM para las políticas de seguridad jerárquicas

Las siguientes operaciones requieren que tengas el rol de Identity and Access Management (IAM) Administrador de políticas de seguridad de la organización de Compute (roles/compute.orgSecurityPolicyAdmin) en el nodo de la jerarquía de recursos objetivo o en la política misma si ya existe:

  • Crea una nueva política de seguridad jerárquica
  • Modificar una política de seguridad jerárquica agregando, actualizando o borrando reglas
  • Borra una política de seguridad jerárquica

Las siguientes operaciones requieren que tengas el rol de administrador de recursos de la organización de Compute (roles/compute.orgSecurityResourceAdmin) de IAM en el nodo de la jerarquía de recursos de destino, además del rol de administrador de políticas de seguridad de la organización de Compute (roles/compute.orgSecurityPolicyAdmin) o el rol de usuario de políticas de seguridad de la organización de Compute (roles/compute.orgSecurityPolicyUser) en el nodo de la jerarquía de recursos de destino o en la política en sí:

  • Asocia una política de seguridad jerárquica a un nodo de jerarquía de recursos

Por último, consulta la siguiente tabla para ver una lista de operaciones diversas que puedes realizar si tienes alguno de los roles que se indican:

Operaciones Funciones
Visualiza todas las reglas efectivas de Google Cloud Armor para un recurso de backend
Ver los recursos de backend efectivos cubiertos por un organizationSecurityPolicy

Configura políticas de seguridad jerárquicas

En las siguientes secciones, se explica cómo crear políticas de seguridad jerárquicas, asociarlas con nodos de la jerarquía de recursos, moverlas entre nodos, borrarlas y ver todas las reglas de la política de seguridad de Google Cloud Armor que se aplican a un recurso protegido.

Crea una política de seguridad jerárquica

Para crear una política de seguridad jerárquica, usa el comando gcloud beta compute org-security-policies create. Creas la política de seguridad jerárquica en una organización o una carpeta con la marca --organization o --folder, junto con el ORGANIZATION_ID o FOLDER_ID correspondiente. Usa los siguientes ejemplos para crear políticas de seguridad jerárquicas y reemplaza POLICY_NAME por el nombre que deseas asignarle a la nueva política de seguridad:

  • Crea una política de seguridad jerárquica a nivel de la organización:

    gcloud beta compute org-security-policies create \
    --organization=ORGANIZATION_ID \
    --type=CLOUD_ARMOR \
    --short-name=POLICY_NAME

  • Crea una política de seguridad jerárquica a nivel de la carpeta:

    gcloud beta compute org-security-policies create \ 
    --folder=FOLDER_ID \
    --type=CLOUD_ARMOR \
    --short-name=POLICY_NAME

Asocia una política de seguridad existente a un nodo de jerarquía de recursos

Si tienes una política de seguridad existente, puedes asociarla con un nodo de la jerarquía de recursos usando el comando gcloud beta compute org-security-policies associations create. Reemplaza lo siguiente:

  • POLICY_ID: ID de la política de seguridad
  • POLICY_NAME: El nombre de la política de seguridad
  • ORGANIZATION_ID: El ID de la organización
  • FOLDER_ID: ID de la carpeta

  • PROJECT_ID: El ID del proyecto

  • Asocia una política de seguridad jerárquica a una organización:

    gcloud beta compute org-security-policies associations create \
    --security-policy=POLICY_ID \
    --organization=ORGANIZATION_ID \
    --name=ASSOCIATION_NAME

  • Asocia una política de seguridad jerárquica a una carpeta:

    gcloud beta compute org-security-policies associations create \
    --security-policy=POLICY_ID \
    --folder=FOLDER_ID \
    --name=ASSOCIATION_NAME

  • Asocia una política de seguridad jerárquica a un proyecto:

    gcloud beta compute org-security-policies associations create \
  --security-policy=POLICY_ID \
  --project-number=PROJECT_ID \
  --name=ASSOCIATION_NAME

Excluye proyectos de las políticas de seguridad jerárquicas

Además, puedes excluir proyectos de tus políticas de seguridad jerárquicas a nivel de la carpeta y puedes excluir proyectos y carpetas de tus políticas de seguridad jerárquicas a nivel de la organización:

  • Puedes excluir proyectos de una política de seguridad jerárquica con el comando beta compute org-security-policies associations create y la marca --excluded-projects.

    En el siguiente comando de ejemplo, se asocia la política de seguridad example-policy con la organización 10000001 y se excluye el proyecto con el ID 2000000002:

    gcloud beta compute org-security-policies associations create \
    --security-policy=example-policy \
    --excluded-projects="projects/2000000002" \
    --organization=10000001

  • Puedes excluir carpetas de una política de seguridad jerárquica a nivel de la organización con el comando beta compute org-security-policies associations create y la marca --excluded-folders.

    En el siguiente comando de ejemplo, se asocia la política de seguridad example-policy con la organización 10000001 y se excluye la carpeta con el ID 3000000003:

    gcloud beta compute org-security-policies associations create \
    --security-policy=example-policy \
    --excluded-folders="folders/3000000003" \
    --organization=10000001

Cómo mover una política de seguridad jerárquica

Puedes cambiar el elemento superior de una política de seguridad jerárquica con gcloud beta compute org-security-policies move para mover la política de seguridad jerárquica a un nodo diferente de la jerarquía de recursos principal. Proporcionas la fuente como la primera marca y el destino como la segunda. Mover una política de seguridad jerárquica cambia su propiedad, no los recursos con los que está asociada. Solo las organizaciones y las carpetas pueden tener políticas de seguridad jerárquicas, por lo que no puedes moverlas a proyectos.

En el siguiente ejemplo, se mueve una política de seguridad jerárquica de la organización ORGANIZATION_ID a la carpeta FOLDER_ID:

gcloud beta compute org-security-policies move policy-1 \
    --organization ORGANIZATION_ID \
    --folder FOLDER_ID

Borra una política de seguridad jerárquica

Antes de borrar una política de seguridad jerárquica, primero debes borrar todas las asociaciones que la política tenga con los nodos de la jerarquía de recursos. En el siguiente ejemplo, usas el comando beta compute org-security-policies associations delete para quitar la asociación llamada ASSOCIATION_NAME entre la política de seguridad jerárquica con el nombre POLICY_NAME y la organización ORGANIZATION_ID:

gcloud beta compute org-security-policies associations delete ASSOCIATION_NAME \
    --security-policy=POLICY_NAME \
    --organization=ORGANIZATION_ID

Si esta no es la única asociación que tiene la política de seguridad, repite el paso anterior para cada asociación. Cuando la política de seguridad jerárquica no tiene asociaciones, puedes borrarla con el comando compute org-security-policies delete, como en el siguiente ejemplo:

gcloud beta compute org-security-policies delete POLICY_NAME \
    --organization=ORGANIZATION_ID

Cómo ver todas las reglas de Google Cloud Armor vigentes para un recurso protegido

Puedes ver todas las reglas de políticas de seguridad de Google Cloud Armor que se aplican a un recurso protegido con el comando gcloud beta compute backend-services get-effective-security-policies. En el siguiente ejemplo, reemplaza RESOURCE_NAME por el nombre del recurso protegido que deseas verificar:

gcloud beta compute backend-services get-effective-security-policies PROTECTED_RESOURCE

Cuando ejecutas el comando gcloud beta compute get-effective-security-policies en un servicio de backend dentro de un proyecto que hereda una política de seguridad jerárquica, la respuesta podría incluir la política de seguridad jerárquica, incluso si las políticas de seguridad jerárquicas no admiten el tipo de ese servicio de backend específico. Para obtener una lista de las configuraciones de backend compatibles con las políticas de seguridad jerárquicas, consulta la descripción general de las políticas de seguridad jerárquicas.

Casos de uso

En las siguientes secciones, se describen casos de uso para las políticas de seguridad jerárquicas.

Rechaza el tráfico de un conjunto de direcciones IP a todos los balanceadores de cargas de aplicaciones de tu organización

Puedes usar políticas de seguridad jerárquicas para administrar una lista de direcciones IP que no tienen permiso para acceder a toda la red de tu organización o para rechazar el tráfico de una región o un país específicos. Esto puede ayudarte a abordar las inquietudes de seguridad específicas de la empresa o a mantener el cumplimiento. En los siguientes pasos, se muestra cómo crear una política de seguridad jerárquica a nivel de la organización que rechaza el tráfico del rango de direcciones IP 192.0.2.0/24:

  1. Crea una política de seguridad jerárquica llamada org-level-deny-ip-policy, adjunta a una organización con el ID 1000000001:

     gcloud beta compute org-security-policies create \
     --organization=1000000001 \
     --type=CLOUD_ARMOR \
     --description= "this is an org policy to deny a set of IP addresses for all resources" \
     --short-name=org-level-deny-ip-policy

  2. Agrega una regla con la prioridad 1000, una condición de coincidencia para el rango de direcciones IP 192.0.2.0/24 y una acción deny:

     gcloud beta compute org-security-policies rules create 1000 \
     --action=deny \
     --security-policy=org-level-deny-ip-policy \
     --organization=1000000001 \
     --description "Deny traffic from 192.0.2.0/24" \
     --src-ip-ranges "192.0.2.0/24"

  3. Por último, asocia la política de seguridad a la organización y rechaza las solicitudes de la dirección IP 192.0.2.0/24 a todos los servicios de la organización:

     gcloud beta compute org-security-policies associations create \
     --security-policy=org-level-deny-ip-policy \
     --organization=ORGANIZATION_ID

Otorga acceso a un conjunto de direcciones IP de origen a algunos proyectos de tu organización

Puedes otorgar acceso a algunos proyectos de tu organización a una o varias direcciones IP. Es posible que desees hacerlo si tienes un proxy upstream de confianza que deseas excluir de la evaluación de reglas solo para algunos de tus proyectos. En el siguiente ejemplo basado en Cloud CDN, se usa una política de seguridad jerárquica a nivel de la carpeta para otorgar al rango de direcciones IP 192.0.2.0/24 acceso a los proyectos denominados project-1, project-2 y project-3 en la organización 10000001:

  1. Usa los siguientes comandos para mover project-1, project-2 y project-3 a una carpeta con el ID 20000002:

    gcloud projects move project-1 --folder=20000002
gcloud projects move project-2 --folder=20000002
gcloud projects move project-3 --folder=20000002

  2. Usa el siguiente comando para crear una política de seguridad llamada org-level-proxy-filtering:

     gcloud beta compute org-security-policies create \
     --folder=20000002 \
     --type=CLOUD_ARMOR \
     --short-name=org-level-proxy-filtering

  3. Agrega una regla con la prioridad 1000, una condición de coincidencia para el rango de direcciones IP 192.0.2.0/24 y una acción de regla goto_next. Si una solicitud coincide con esta condición, Google Cloud Armor deja de evaluar reglas dentro de esta política de seguridad:

     gcloud beta compute org-security-policies rules create 1000 \
     --action=goto_next \
     --security-policy=org-level-proxy-filtering \
     --organization=10000001 \
     --src-ip-ranges="192.0.2.0/24"

  4. Opcional: Si deseas aplicar reglas de políticas de seguridad a estos proyectos para las solicitudes que no provienen de 192.0.2.0/24 , agrega más reglas con una prioridad inferior a 1000. Puedes realizar este paso más tarde.

  5. Usa el siguiente comando para asociar la política a la carpeta con el ID 20000002, a la que moviste los proyectos en el paso 1:

     gcloud beta compute org-security-policies associations create \
     --security-policy=org-level-proxy-filtering \
     --folder=20000002

¿Qué sigue?