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çaPOLICY_NAME
: o nome da política de segurançaORGANIZATION_ID
: o ID da organizaçãoFOLDER_ID
: o ID da pastaPROJECT_ID
: o ID do projetoAssocie 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ção10000001
, ao mesmo tempo que exclui o projeto com o ID2000000002
: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ção10000001
, ao mesmo tempo que exclui a pasta com o ID3000000003
: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
:
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
Adicione uma regra com a prioridade
1000
com uma condição de correspondência para o intervalo de endereços IP192.0.2.0/24
e uma açãodeny
: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"
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
:
Use os seguintes comandos para mover
project-1
,project-2
eproject-3
para uma pasta com o ID20000002
:gcloud projects move project-1 --folder=20000002 gcloud projects move project-2 --folder=20000002 gcloud projects move project-3 --folder=20000002
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
Adicione uma regra com a prioridade
1000
com uma condição de correspondência para o intervalo de endereços IP192.0.2.0/24
e uma ação de regragoto_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"
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 a1000
. Pode realizar este passo mais tarde.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