Configure políticas de segurança hierárquicas

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

Configure autorizações IAM para políticas de segurança hierárquicas

As seguintes operações requerem que tenha a função Administrador da política de segurança da organização do Compute (roles/compute.orgSecurityPolicyAdmin) na hierarquia de recursos de destino ou no próprio nó da política, se já existir:

  • Crie uma nova política de segurança hierárquica
  • Modifique uma política de segurança hierárquica adicionando, atualizando ou eliminando regras
  • Elimine uma política de segurança hierárquica

As seguintes operações requerem que tenha a função de administrador de recursos da organização do Compute IAM (roles/compute.orgSecurityResourceAdmin) no nó da hierarquia de recursos de destino, além da função de administrador da política de segurança da organização do Compute (roles/compute.orgSecurityPolicyAdmin) ou da função de utilizador da política de segurança da organização do Compute (roles/compute.orgSecurityPolicyUser) no nó da hierarquia de recursos de destino ou na própria política:

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

Por último, consulte a tabela seguinte para ver uma lista de operações diversas que pode realizar se tiver alguma das funções indicadas:

Operações Funções
Veja todas as regras do Cloud Armor eficazes para um recurso de back-end
Veja os recursos de back-end eficazes abrangidos por um organizationSecurityPolicy

Configure políticas de segurança hierárquicas

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

Crie 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. Cria a política de segurança hierárquica numa organização ou numa pasta através da flag --organization ou --folder, juntamente com a flag ORGANIZATION_ID ou FOLDER_ID correspondente. Use os exemplos seguintes para criar políticas de segurança hierárquicas, substituindo POLICY_NAME pelo nome que quer dar à nova política de segurança:

  • Crie uma política de segurança hierárquica ao 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 ao nível da pasta:

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

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

Se tiver uma política de segurança existente, pode associá-la a um nó da hierarquia de recursos através do comando gcloud beta compute org-security-policies associations create. Substitua o seguinte:

  • 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
    

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

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

  • Pode excluir projetos de uma política de segurança hierárquica através do comando beta compute org-security-policies associations create com a flag --excluded-projects.

    O seguinte comando de exemplo associa a política de segurança example-policy à organização 10000001, ao mesmo tempo que exclui o projeto com o ID 2000000002:

    gcloud beta compute org-security-policies associations create \
        --security-policy=example-policy \
        --excluded-projects="projects/2000000002" \
        --organization=10000001
    
  • Pode excluir pastas de uma política de segurança hierárquica ao nível da organização usando o comando beta compute org-security-policies associations create com a flag --excluded-folders.

    O seguinte comando de exemplo associa a política de segurança example-policy à organização 10000001, ao mesmo tempo que exclui a pasta com o ID 3000000003:

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

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

Pode alterar o elemento principal de uma política de segurança hierárquica usando o comando gcloud beta compute org-security-policies move para mover a política de segurança hierárquica para um nó da hierarquia de recursos principal diferente. Fornece a origem como o primeiro indicador e o destino como o segundo indicador. A movimentação de uma política de segurança hierárquica altera a respetiva propriedade e não os recursos aos quais está associada. Apenas as organizações e as pastas podem ter políticas de segurança hierárquicas, pelo que não pode movê-las para projetos.

No exemplo seguinte, move uma política de segurança hierárquica 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

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

Antes de poder eliminar uma política de segurança hierárquica, tem de eliminar primeiro todas as associações que a política tem a nós da hierarquia de recursos. No exemplo seguinte, usa o comando beta compute org-security-policies associations delete para remover a associação com o nome 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 esta não for a única associação que a política de segurança tem, repita o passo anterior para cada associação. Quando a política de segurança hierárquica não tem associações, pode eliminá-la através do comando compute org-security-policies delete, como no exemplo seguinte:

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

Veja todas as regras do Cloud Armor eficazes para um recurso protegido

Pode ver todas as regras da política de segurança do Cloud Armor que se aplicam a um recurso protegido através do comando gcloud beta compute backend-services get-effective-security-policies. No exemplo seguinte, substitua RESOURCE_NAME pelo nome do recurso protegido que quer verificar:

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

Quando executa o comando gcloud beta compute get-effective-security-policies num serviço de back-end num 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 desse serviço de back-end específico não seja suportado por políticas de segurança hierárquicas. Para ver uma lista das configurações de back-end suportadas para políticas de segurança hierárquicas, consulte a vista geral das políticas de segurança hierárquicas.

Exemplos de utilização

As secções seguintes descrevem casos de utilização para políticas de segurança hierárquicas.

Recuse tráfego de um conjunto de endereços IP para todos os equilibradores de carga de aplicações na sua organização

Pode usar políticas de segurança hierárquicas para gerir uma lista de endereços IP que não têm autorização para aceder a toda a rede da sua organização ou para negar tráfego de uma região ou um país específico. Isto pode ajudar a resolver preocupações de segurança específicas da empresa ou a manter a conformidade. Os passos seguintes mostram como criar uma política de segurança hierárquica ao 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 denominada org-level-deny-ip-policy, anexada a uma organização com o 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 com a 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 último, associe a política de segurança à organização, recusando pedidos 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
    

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

Pode conceder acesso a alguns projetos na sua organização a um endereço IP ou a vários endereços IP. Pode fazê-lo se tiver um proxy a montante fidedigno que queira excluir da avaliação de regras apenas para alguns dos seus projetos. No exemplo seguinte baseado no Cloud CDN, usa uma política de segurança hierárquica ao nível da pasta para conceder ao intervalo de endereços IP 192.0.2.0/24 acesso a projetos denominados 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 seguinte comando para criar uma política de segurança com o nome 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 com a 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 um pedido corresponder a esta condição, o Cloud Armor deixa de avaliar as regras nesta 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 quiser aplicar regras de política de segurança a estes projetos para pedidos que não sejam de 192.0.2.0/24 , adicione mais regras com uma prioridade inferior a 1000. Pode realizar este passo mais tarde.

  5. Use o seguinte comando para associar a política à pasta com o ID 20000002, para a qual moveu os projetos no passo 1:

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

O que se segue?