Configura políticas de seguridad jerárquicas

En esta página, se describe cómo puedes configurar políticas de seguridad jerárquicas para proteger tu organización, tus carpetas o tus proyectos. Antes de configurar las políticas de seguridad jerárquicas, asegúrate de conocer la información de 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) de administrador de políticas de seguridad de la organización de Compute (roles/compute.orgSecurityPolicyAdmin) en el nodo de jerarquía de recursos objetivo o en la política, 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 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 jerarquía de recursos de destino o en la política:

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

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

Operaciones Funciones
Visualiza todas las reglas de Google Cloud Armor vigentes para un recurso de backend
Visualiza los recursos de backend efectivos que cubre una 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 jerarquía de recursos, moverlas entre nodos, borrarlas y ver todas las reglas de la política de seguridad de 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 compute org-security-policies create. Crea 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 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 carpeta:

    gcloud 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 jerarquía de recursos con el comando gcloud compute org-security-policies associations create.

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

    gcloud 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 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 compute org-security-policies associations create \
    --security-policy=POLICY_ID \
    --project-number=PROJECT_ID \
    --name=ASSOCIATION_NAME

Reemplaza lo siguiente:

  • POLICY_ID: Es el ID de la política de seguridad.
  • ORGANIZATION_ID: Es el ID de la organización.
  • ASSOCIATION_NAME: Es el nombre de la asociación.
  • FOLDER_ID: el ID de la carpeta
  • PROJECT_ID: el ID del proyecto

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 carpeta, y puedes excluir 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 con el comando gcloud compute org-security-policies associations create con la marca --excluded-projects.

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

    gcloud 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 gcloud 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, mientras se excluye la carpeta con el ID 3000000003:

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

Mueve una política de seguridad jerárquica

Puedes cambiar el elemento superior de una política de seguridad jerárquica con el comando gcloud compute org-security-policies move para mover la política de seguridad jerárquica a un nodo de jerarquía de recursos superior diferente. 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 el recurso con el 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 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 tiene la política con los nodos de la jerarquía de recursos. En el siguiente ejemplo, usas el comando gcloud 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 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 gcloud compute org-security-policies delete, como en el siguiente ejemplo:

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

Visualiza todas las reglas de Cloud Armor vigentes para un recurso protegido

Puedes ver todas las reglas de la política de seguridad de Cloud Armor que se aplican a un recurso protegido con el comando gcloud compute backend-services get-effective-security-policies.

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

Reemplaza PROTECTED_RESOURCE por el nombre del recurso protegido que deseas verificar.

Cuando ejecutas el comando gcloud compute backend-services get-effective-security-policies en un servicio de backend dentro de un proyecto que hereda una política de seguridad jerárquica, la respuesta puede incluir la política de seguridad jerárquica, incluso si las políticas de seguridad jerárquicas no admiten el tipo de 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 los casos de uso de 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 permitido 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 los 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 la organización que rechace 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 compute org-security-policies create \
     --organization=1000000001 \
     --type=CLOUD_ARMOR \
     --description= "this org policy denies a set of IP addresses for all resources" \
     --short-name=org-level-deny-ip-policy

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

     gcloud 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 con 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 compute org-security-policies associations create \
     --security-policy=org-level-deny-ip-policy \
     --organization=ORGANIZATION_ID

Otorgar 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 hacer esto si tienes un proxy ascendente 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, usas una política de seguridad jerárquica a nivel de carpeta para otorgar el rango de direcciones IP 192.0.2.0/24 acceso a los proyectos llamados 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 compute org-security-policies create \
     --folder=20000002 \
     --type=CLOUD_ARMOR \
     --short-name=org-level-proxy-filtering

  3. Agrega una regla con prioridad 1000 con 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, Cloud Armor deja de evaluar las reglas dentro de esta política de seguridad:

     gcloud 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ítica 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 compute org-security-policies associations create \
     --security-policy=org-level-proxy-filtering \
     --folder=20000002

¿Qué sigue?