Configurar políticas de seguridad jerárquicas

En esta página se explica cómo configurar políticas de seguridad jerárquicas para proteger tu organización, carpetas o proyectos. Antes de configurar las políticas de seguridad jerárquicas, familiarízate con la información que se incluye en el resumen de las políticas de seguridad jerárquicas.

Configurar permisos de gestión de identidades y accesos para políticas de seguridad jerárquicas

Para realizar las siguientes operaciones, debes tener el rol de gestión de identidades y accesos Administrador de políticas de seguridad de la organización de Compute (roles/compute.orgSecurityPolicyAdmin) en el nodo de la jerarquía de recursos de destino o en la propia política si ya existe:

  • Crear una política de seguridad jerárquica
  • Modificar una política de seguridad jerárquica añadiendo, actualizando o eliminando reglas
  • Eliminar una política de seguridad jerárquica

Para realizar las siguientes operaciones, debe tener el rol de gestión de identidades y accesos Administrador de recursos de organización de Compute (roles/compute.orgSecurityResourceAdmin) en el nodo de jerarquía de recursos de destino, así como el rol Administrador de políticas de seguridad de organización de Compute (roles/compute.orgSecurityPolicyAdmin) o el rol Usuario de políticas de seguridad de organización de Compute (roles/compute.orgSecurityPolicyUser) en el nodo de jerarquía de recursos de destino o en la propia política:

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

Por último, en la siguiente tabla se muestra una lista de operaciones diversas que puedes realizar si tienes alguno de los roles indicados:

Operaciones Roles
Ver todas las reglas de Cloud Armor efectivas de un recurso de backend
Ver los recursos de backend efectivos cubiertos por un organizationSecurityPolicy

Configurar políticas de seguridad jerárquicas

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

Crear 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. Para crear la política de seguridad jerárquica, debes usar las marcas --organization o --folder, junto con los valores ORGANIZATION_ID o FOLDER_ID correspondientes, en una organización o una carpeta. Usa los siguientes ejemplos para crear políticas de seguridad jerárquicas. Sustituye POLICY_NAME por el nombre que quieras dar a la nueva política de seguridad:

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

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

  • Para crear una política de seguridad jerárquica a nivel de carpeta, sigue estos pasos:

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

Asociar una política de seguridad a un nodo de jerarquía de recursos

Si ya tienes una política de seguridad, puedes asociarla a un nodo de la jerarquía de recursos mediante el comando gcloud beta compute org-security-policies associations create. Haz los cambios siguientes:

  • POLICY_ID: el 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: el 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

Excluir 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 carpeta, así como proyectos y carpetas de tus políticas de seguridad jerárquicas a nivel de organización:

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

    El siguiente comando de ejemplo asocia la política de seguridad example-policy con la organización 10000001, al tiempo que 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 organización mediante el comando beta compute org-security-policies associations create con la marca --excluded-folders.

    El siguiente comando de ejemplo asocia la política de seguridad example-policy con la organización 10000001, al tiempo que 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

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 otro nodo de la jerarquía de recursos superior. El origen se indica con la primera marca y el destino, con la segunda. Al mover una política de seguridad jerárquica, cambia su propiedad, pero no los recursos a 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

Eliminar una política de seguridad jerárquica

Para poder eliminar una política de seguridad jerárquica, primero debes eliminar todas las asociaciones que tenga con los nodos de la jerarquía de recursos. En el siguiente ejemplo, se usa 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. Si la política de seguridad jerárquica no tiene asociaciones, puedes eliminarla 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

Ver todas las reglas de Cloud Armor activas de un recurso protegido

Para ver todas las reglas de política de seguridad de Cloud Armor que se aplican a un recurso protegido, usa el comando gcloud beta compute backend-services get-effective-security-policies. En el siguiente ejemplo, sustituye RESOURCE_NAME por el nombre del recurso protegido que quieras comprobar:

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 de un proyecto que hereda una política de seguridad jerárquica, la respuesta puede incluir la política de seguridad jerárquica aunque el tipo de ese servicio de backend específico no sea compatible con las políticas de seguridad jerárquicas. Para ver una lista de las configuraciones de backend admitidas para las políticas de seguridad jerárquicas, consulta la información general sobre las políticas de seguridad jerárquicas.

Casos prácticos

En las siguientes secciones se describen casos prácticos de políticas de seguridad jerárquicas.

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

Puedes usar políticas de seguridad jerárquicas para gestionar una lista de direcciones IP que no tengan permiso para acceder a toda la red de tu organización o para denegar el tráfico de una región o un país concretos. Esto puede ayudarte a abordar problemas de seguridad específicos 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 organización que deniegue el tráfico del intervalo de direcciones IP 192.0.2.0/24:

  1. Crea una política de seguridad jerárquica llamada org-level-deny-ip-policy, asociada 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. Añade una regla con la prioridad 1000 y una condición de coincidencia para el intervalo 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 para denegar 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

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

Puedes conceder acceso a algunos proyectos de tu organización a una o varias direcciones IP. Te recomendamos que lo hagas si tienes un proxy upstream de confianza que quieres excluir de la evaluación de reglas solo en algunos de tus proyectos. En el siguiente ejemplo basado en Cloud CDN, se usa una política de seguridad jerárquica a nivel de carpeta para conceder acceso al intervalo de direcciones IP 192.0.2.0/24 a los proyectos project-1, project-2 y project-3 de 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. Añade una regla con la prioridad 1000 y una condición de coincidencia para el intervalo de direcciones IP 192.0.2.0/24 y una goto_next regla de acción. Si una solicitud coincide con esta condición, Cloud Armor deja de evaluar las reglas 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 quiere aplicar reglas de política de seguridad a estos proyectos para las solicitudes que no procedan de 192.0.2.0/24 , añada más reglas con una prioridad inferior a 1000. Puedes realizar este paso más adelante.

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

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

Siguientes pasos