Configurar políticas de segurança hierárquicas

Esta página contém informações sobre como configurar políticas de segurança hierárquicas para proteger sua organização, pastas ou projetos. Antes de configurar políticas de segurança hierárquicas, familiarize-se com as informações na visão geral das políticas de segurança hierárquicas.

Configurar permissões do IAM para políticas de segurança hierárquicas

As operações a seguir exigem que você tenha o papel do Identity and Access Management (IAM) Administrador da política de segurança da organização do Compute (roles/compute.orgSecurityPolicyAdmin) no nó da hierarquia de recursos de destino ou na própria política, se ela já existir:

  • Criar uma política de segurança hierárquica
  • Modificar uma política de segurança hierárquica adicionando, atualizando ou excluindo regras
  • Excluir uma política de segurança hierárquica

As operações a seguir exigem que você tenha o papel do IAM Administrador de recursos da organização do Compute (roles/compute.orgSecurityResourceAdmin) no nó de hierarquia do recurso de destino, além do papel Administrador de políticas de segurança da organização do Compute (roles/compute.orgSecurityPolicyAdmin) ou Usuário de políticas de segurança da organização do Compute (roles/compute.orgSecurityPolicyUser) no nó de hierarquia do recurso de destino ou na própria política:

  • Associar uma política de segurança hierárquica a um nó de hierarquia de recursos

Por fim, confira na tabela a seguir uma lista de operações diversas que você pode realizar se tiver uma das funções listadas:

Operações Papéis
Ver todas as regras efetivas do Google Cloud Armor para um recurso de back-end
Ver os recursos de back-end efetivos cobertos por um organizationSecurityPolicy

Configurar políticas de segurança hierárquicas

As seções a seguir explicam como criar políticas de segurança hierárquicas, associá-las a nós da hierarquia de recursos, movê-las entre nós, excluí-las e como visualizar todas as regras de política de segurança do Google Cloud Armor que se aplicam a um recurso protegido.

Criar uma política de segurança hierárquica

Crie uma política de segurança hierárquica usando o comando gcloud beta compute org-security-policies create. Você cria a política de segurança hierárquica em uma organização ou pasta usando a flag --organization ou --folder, junto com o ORGANIZATION_ID ou FOLDER_ID correspondente. Use os exemplos a seguir para criar políticas de segurança hierárquicas, substituindo POLICY_NAME pelo nome que você quer dar à nova política de segurança:

  • Crie uma política de segurança hierárquica no nível da organização:

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

  • Crie uma política de segurança hierárquica no nível da pasta:

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

Associar uma política de segurança a um nó da hierarquia de recursos

Se você já tiver uma política de segurança, poderá associá-la a um nó da hierarquia de recursos usando o comando gcloud beta compute org-security-policies associations create. Substitua:

  • POLICY_ID: o ID da política de segurança
  • POLICY_NAME: o nome da política de segurança
  • ORGANIZATION_ID: o ID da organização
  • FOLDER_ID: o ID da pasta

  • PROJECT_ID: o ID do projeto

  • Associe uma política de segurança hierárquica a uma organização:

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

  • Associe uma política de segurança hierárquica a uma pasta:

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

  • Associe uma política de segurança hierárquica a um projeto:

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

Excluir projetos de políticas de segurança hierárquicas

Além disso, é possível excluir projetos das políticas de segurança hierárquicas no nível da pasta e excluir projetos e pastas das políticas de segurança hierárquicas no nível da organização:

  • É possível excluir projetos de uma política de segurança hierárquica usando o comando beta compute org-security-policies associations create com a sinalização --excluded-projects.

    O exemplo de comando a seguir associa a política de segurança example-policy à organização 10000001, excluindo o projeto com o ID 2000000002:

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

  • É possível excluir pastas de uma política de segurança hierárquica no nível da organização usando o comando beta compute org-security-policies associations create com a flag --excluded-folders.

    O exemplo de comando a seguir associa a política de segurança example-policy à organização 10000001, excluindo a pasta com o ID 3000000003:

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

Mover uma política de segurança hierárquica

É possível mudar o pai de uma política de segurança hierárquica usando o gcloud beta compute org-security-policies move para mover a política de segurança hierárquica para um nó diferente na hierarquia de recursos pai. Você fornece a origem como a primeira flag e o destino como a segunda. Mover uma política de segurança hierárquica muda a propriedade dela, não os recursos a que ela está associada. Somente organizações e pastas podem ter políticas de segurança hierárquicas. Portanto, não é possível movê-las para projetos.

No exemplo a seguir, uma política de segurança hierárquica é movida da organização ORGANIZATION_ID para a pasta FOLDER_ID:

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

Excluir uma política de segurança hierárquica

Antes de excluir uma política de segurança hierárquica, é preciso excluir todas as associações que ela tem com os nós da hierarquia de recursos. No exemplo a seguir, você usa o comando beta compute org-security-policies associations delete para remover a associação chamada ASSOCIATION_NAME entre a política de segurança hierárquica com o nome POLICY_NAME e a organização ORGANIZATION_ID:

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

Se essa não for a única associação da política de segurança, repita a etapa anterior para cada associação. Quando a política de segurança hierárquica não tem associações, é possível excluí-la usando o comando compute org-security-policies delete, como no exemplo a seguir:

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

Ver todas as regras efetivas do Google Cloud Armor para um recurso protegido

É possível conferir todas as regras da política de segurança do Google Cloud Armor que se aplicam a um recurso protegido usando o comando gcloud beta compute backend-services get-effective-security-policies. No exemplo a seguir, substitua RESOURCE_NAME pelo nome do recurso protegido que você quer verificar:

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

Quando você executa o comando gcloud beta compute get-effective-security-policies em um serviço de back-end em um projeto que herda uma política de segurança hierárquica, a resposta pode incluir a política de segurança hierárquica, mesmo que o tipo específico do serviço de back-end não seja compatível com políticas de segurança hierárquicas. Para conferir uma lista de configurações de back-end compatíveis com políticas de segurança hierárquicas, consulte a visão geral das políticas de segurança hierárquicas.

Casos de uso

As seções a seguir descrevem casos de uso para políticas de segurança hierárquicas.

Negar o tráfego de um conjunto de endereços IP para todos os balanceadores de carga de aplicativo na sua organização

É possível usar políticas de segurança hierárquicas para gerenciar uma lista de endereços IP que não têm permissão para acessar toda a rede da organização ou para negar o tráfego de uma região ou país específico. Isso pode ajudar você a resolver problemas de segurança específicos da empresa ou manter a conformidade. As etapas a seguir mostram como criar uma política de segurança hierárquica no nível da organização que nega o tráfego do intervalo de endereços IP 192.0.2.0/24:

  1. Crie uma política de segurança hierárquica chamada org-level-deny-ip-policy, anexada a uma organização com 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. Adicione uma regra na prioridade 1000 com uma condição de correspondência para o intervalo de endereços IP 192.0.2.0/24 e uma ação 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 fim, associe a política de segurança à organização, negando solicitações do endereço IP 192.0.2.0/24 a todos os serviços na organização:

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

Conceder a um conjunto de endereços IP de origem acesso a alguns projetos na sua organização

Você pode conceder acesso a alguns projetos da sua organização a um ou vários endereços IP. Isso é útil quando você tem um proxy upstream confiável que quer excluir da avaliação de regras apenas para alguns dos seus projetos. No exemplo a seguir baseado no Cloud CDN, você usa uma política de segurança hierárquica no nível da pasta para conceder ao intervalo de endereços IP 192.0.2.0/24 acesso aos projetos chamados project-1, project-2 e project-3 na organização 10000001:

  1. Use os seguintes comandos para mover project-1, project-2 e project-3 para uma pasta com o ID 20000002:

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

  2. Use o comando a seguir para criar uma política de segurança chamada org-level-proxy-filtering:

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

  3. Adicione uma regra na prioridade 1000 com uma condição de correspondência para o intervalo de endereços IP 192.0.2.0/24 e uma ação de regra goto_next. Se uma solicitação corresponder a essa condição, o Google Cloud Armor vai parar de avaliar as regras nessa política de segurança:

     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: se você quiser aplicar regras de política de segurança a esses projetos para solicitações que não são de 192.0.2.0/24 , adicione mais regras com uma prioridade menor que 1000. Você pode fazer isso mais tarde.

  5. Use o comando a seguir para associar a política à pasta com o ID 20000002, para onde você moveu os projetos na etapa 1:

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

A seguir