As políticas de segurança hierárquicas são uma categoria de políticas de segurança que estendem o alcance da firewall de aplicação Web (WAF) do Cloud Armor e da proteção contra DDoS para além de projetos individuais. Estão anexadas ao nível da organização, da pasta ou do projeto. Estas diferem das políticas de segurança ao nível do serviço, que estão anexadas diretamente aos serviços de back-end ou aos contentores de back-end.
Quando configura uma política de segurança hierárquica ao nível da organização ou da pasta, os projetos nos níveis inferiores da hierarquia herdam essa política de segurança. Esta herança permite-lhe configurar regras de políticas de segurança que quer aplicar a todos ou a vários projetos na sua organização. Isto permite uma aplicação de segurança centralizada e consistente no seu ambiente Google Cloud .
Esta página explica como as políticas de segurança hierárquicas diferem das políticas de segurança ao nível do serviço. Antes de continuar, leia a vista geral da política de segurança para se certificar de que compreende como funcionam as políticas de segurança. Além disso, recomendamos que se familiarize com a hierarquia de recursos.
Exemplos de utilização
Em organizações grandes, a gestão de políticas de segurança em vários projetos pode ser complexa e demorada. As políticas de segurança hierárquicas oferecem as seguintes vantagens para ajudar a resolver estes desafios:
- Controlo centralizado: ofereça aos administradores ao nível da organização e da pasta a capacidade de definir e aplicar políticas de segurança em vários projetos.
- Consistência: ofereça uma postura de segurança uniforme em toda a organização, o que reduz o risco de configurações incorretas e lacunas de segurança.
- Eficiência: simplifique a implementação de atualizações de segurança e mitigações, como o bloqueio de intervalos de endereços IP específicos ou a resolução de vulnerabilidades críticas, num grande número de recursos em simultâneo.
- Delegação: ative a delegação de responsabilidades de segurança a diferentes equipas ou departamentos aplicando políticas nos níveis adequados da hierarquia.
Pode aplicar e combinar estes princípios gerais para se adequarem às necessidades da sua organização. Considere os seguintes exemplos de utilização:
- Bloqueio de endereços IP ao nível da organização: pode bloquear o tráfego de intervalos de endereços IP maliciosos conhecidos em todos os projetos da sua organização.
- Restrições baseadas na geografia: pode restringir o tráfego de regiões geográficas específicas ao nível da organização ou da pasta.
- Mitigação de CVE: pode implementar rapidamente regras de WAF para mitigar vulnerabilidades críticas em vários projetos.
- Aplicação da conformidade: pode aplicar a adesão aos requisitos regulamentares aplicando políticas de segurança consistentes em toda a sua organização.
- Controlo de acesso detalhado: pode conceder acesso a intervalos de endereços IP específicos ou a regiões geográficas a todos os recursos numa pasta específica.
Funcionalidades
As políticas de segurança hierárquicas suportam um subconjunto das funcionalidades suportadas pelas políticas de segurança ao nível do serviço. A tabela seguinte compara as funcionalidades do Cloud Armor que pode usar com políticas de segurança hierárquicas e políticas de segurança ao nível do serviço:
| Tipo de front-end |
|
|
| Ponto de anexação (recurso protegido) | Serviço de back-end | Nós da hierarquia de recursos |
| Ações da regra |
|
|
| Endereço IP de origem | ||
| Geografia de origem | ||
| ASN de origem | ||
| Gestão de bots | (apenas
EXTERNAL_302 e decoração de pedidos) |
|
| Filtragem da camada 7 | ||
| WAF | ||
| Google Threat Intelligence | ||
| reCAPTCHA | ||
| Proteção adaptável | ||
| Grupos de endereços | ||
| Grupos de moradas ao nível da organização | ||
| Security Command Center | ||
| Cloud Monitoring | ||
| Pedido de registo |
Como funcionam as políticas de segurança hierárquicas
Quando cria uma política de segurança hierárquica, cria-a ao nível da organização ou da pasta, e esse recurso tem a propriedade da política de segurança hierárquica. Depois de criar uma política de segurança hierárquica, as regras da política de segurança não são aplicadas a nenhum dos seus recursos.
Em seguida, associa a política de segurança hierárquica a uma organização, uma pasta ou um projeto, que pode ser o mesmo que o recurso proprietário da política. Depois de associar uma política de segurança hierárquica a um recurso, esta aplica as regras da política de segurança aos recursos protegidos no nó da hierarquia de recursos e abaixo deste. Para ajudar a decidir a que recurso anexar as suas políticas de segurança hierárquicas, consulte a seguinte lista de exemplos de utilização básicos para cada recurso:
- Organização: considere as políticas de segurança hierárquicas ao nível da organização como o tipo predefinido de política de segurança hierárquica.
Estas políticas têm autorizações de gestão de identidade e de acesso (IAM) amplas e aplicam-se a todos os nós na organização. Especifique
estes recursos através da flag
--organizationdurante a associação. - Pasta: use estas políticas de segurança hierárquicas quando quiser aplicar as
mesmas regras de política de segurança em vários projetos, mas não em toda a
sua organização. Especifique estes recursos através da flag
--folderdurante a associação. - Projeto: use este tipo de política de segurança hierárquica quando precisar de aplicar as mesmas regras de política de segurança a todos os recursos num projeto, como aplicar uma lista de negação de endereços IP a vários serviços de back-end.
Especifique estes recursos através da flag
--projectdurante a associação. - Nível de serviço: use políticas de segurança ao nível do serviço quando precisar de regras de política de segurança únicas que difiram entre cada um dos seus serviços. Cada política de segurança ao nível do serviço aplica as respetivas regras apenas à política de back-end à qual está anexada. Especifique estes recursos através da flag
--project-number.
Só pode usar uma destas flags por política de segurança hierárquica. Especifica o resto das flags, como --name ou --type, tal como faz quando configura uma política de segurança ao nível do serviço. Consulte a lista seguinte para obter mais informações sobre o funcionamento das políticas de segurança hierárquicas:
- Quando uma política de segurança hierárquica está associada a um nó da hierarquia de recursos, todos os recursos protegidos abaixo desse nó na hierarquia herdam a política.
- Pode ver as políticas de segurança que se aplicam a cada recurso protegido num projeto, em todas as políticas de segurança hierárquicas e políticas de segurança ao nível do serviço. Para mais informações, consulte o artigo Veja todas as regras do Cloud Armor em vigor para um recurso protegido.
- Pode mover políticas de segurança hierárquicas de um nó da hierarquia de recursos para outro. Pode fazê-lo quando planeia reorganizar a estrutura de pastas.
- Quando elimina um nó da hierarquia de recursos, como uma pasta ou um projeto, a política de segurança hierárquica anexada a esse nó só é eliminada se a tiver criado nesse nó da hierarquia de recursos.
- Se criou a política de segurança noutro local e, em seguida, a moveu para o nó, esta não é eliminada.
- Para evitar a eliminação acidental das suas políticas de segurança hierárquicas, recomendamos que mova todas as políticas de segurança hierárquicas que pretenda manter para outro nó da hierarquia de recursos antes de eliminar o nó existente.
Ordem de avaliação das regras
O Cloud Armor avalia as políticas de segurança pela seguinte ordem:
- Políticas de segurança hierárquicas ao nível da organização
- Políticas de segurança hierárquicas ao nível da pasta (começando pela pasta principal e, em seguida, passando para cada subpasta)
- Políticas de segurança hierárquicas ao nível do projeto
- Políticas de segurança ao nível do serviço
Esta ordem de avaliação das regras significa que pode ter uma política de segurança hierárquica com uma prioridade baixa que é avaliada antes de uma política de segurança ao nível do serviço com uma prioridade alta. Pondere cuidadosamente as regras de política de segurança de nível de serviço de alta prioridade existentes e considere o que acontece se o Cloud Armor não avaliar um pedido permitido ou recusado por uma política de segurança hierárquica em função das mesmas.
A goto_next ação
O Cloud Armor tem uma ação de regra exclusiva das políticas de segurança hierárquicas: a ação goto_next. Quando o Cloud Armor aplica esta ação, deixa de avaliar as regras na política de segurança atual e começa a avaliar as regras na política de segurança seguinte.
Considere um exemplo em que tem uma política de segurança hierárquica ao nível da organização com muitas regras que quer usar para restringir pedidos em toda a organização. Quer permitir que os pedidos provenientes de um determinado intervalo de endereços IP ignorem a avaliação destas regras ao nível da organização. Por conseguinte, cria uma regra de prioridade máxima que corresponda a esse intervalo de endereços IP com a ação goto_next. Os pedidos desse intervalo de endereços IP são avaliados primeiro em função desta regra e, como cumprem a condição de correspondência, não são avaliados em função de outras regras nesta política de segurança hierárquica ao nível da organização.
No mesmo exemplo, se usasse uma ação allow ou deny em vez da ação goto_next, o pedido é permitido ou recusado assim que a condição de correspondência for cumprida. Esta avaliação hierárquica significa que não são avaliadas políticas de segurança adicionais em relação a esse pedido.
Inscrição e comportamento de faturação do Google Cloud Armor Enterprise
Quando anexa uma política de segurança hierárquica, cada um dos projetos que herdam a política de segurança hierárquica tem de estar inscrito no Cloud Armor Enterprise. Isto inclui todos os projetos numa organização ou numa pasta com uma política de segurança hierárquica que não sejam explicitamente excluídos, e todos os projetos com uma política de segurança hierárquica anexada diretamente ao projeto.
- Os projetos associados a uma conta do Cloud Billing com uma subscrição anual do Cloud Armor Enterprise são automaticamente inscritos no Cloud Armor Enterprise anual, se ainda não estiverem inscritos.
- Sem uma subscrição anual do Cloud Armor Enterprise, os projetos são inscritos automaticamente no Cloud Armor Enterprise Paygo quando herdam uma política de segurança hierárquica. Se subscrever a conta de faturação ao Cloud Armor Enterprise anual depois de o seu projeto ter sido inscrito automaticamente no Cloud Armor Enterprise Paygo, o projeto não é inscrito automaticamente no plano anual. Para mais informações sobre o Cloud Armor Enterprise Paygo, consulte o artigo Cloud Armor Standard versus Cloud Armor Enterprise.
- Se atualizar uma política de segurança hierárquica para excluir um projeto depois de o projeto ter sido inscrito automaticamente no Cloud Armor Enterprise, o projeto não é anulado automaticamente. Para anular manualmente a inscrição do seu projeto, consulte o artigo Remova um projeto do Cloud Armor Enterprise.
- Não pode remover um projeto do Cloud Armor Enterprise enquanto tiver políticas de segurança hierárquicas herdadas.
A inscrição automática pode demorar até uma semana a ser concluída. Durante este período, as suas políticas de segurança hierárquicas estão em vigor e não são incorridos custos do Cloud Armor Enterprise. Quando o seu projeto está inscrito, os registos de auditoria são atualizados para refletir o estado do Cloud Armor Enterprise do projeto, e vê o novo nível do projeto na Google Cloud consola.
Limitações
As políticas de segurança hierárquicas têm as seguintes limitações:
- As políticas de segurança hierárquicas não estão disponíveis para projetos que não estejam numa organização.
- Para projetos novos ou restaurados recentemente, a propagação das políticas de segurança herdadas no projeto pode demorar algumas horas.
- Para um projeto que ativou recentemente a API Compute Engine, a propagação de todas as políticas de segurança herdadas neste projeto pode demorar algumas horas.
- Pode otimizar as regras da WAF pré-configuradas em políticas de segurança hierárquicas que lhe pertencem, mas os proprietários dos serviços que herdam uma política de segurança hierárquica não podem otimizar as regras.