As políticas de segurança hierárquicas são uma categoria de políticas de segurança que ampliam o alcance do firewall de aplicativos da Web (WAF) e da proteção contra DDoS do Google Cloud Armor além de projetos individuais. Elas são anexadas no nível da organização, da pasta ou do projeto. Elas são diferentes das políticas de segurança no nível do serviço, que são anexadas diretamente a serviços ou buckets de back-end.
Quando você configura uma política de segurança hierárquica no nível da organização ou da pasta, os projetos em níveis inferiores da hierarquia herdam essa política. Essa herança permite que você configure as regras de política de segurança que quer aplicar a todos ou a vários projetos da sua organização. Isso permite a aplicação de segurança centralizada e consistente em todo o ambiente Google Cloud .
Nesta página, explicamos a diferença entre políticas de segurança hierárquicas e de nível de serviço. Antes de continuar, leia a visão geral da política de segurança para entender como elas funcionam. Além disso, recomendamos que você se familiarize com a hierarquia de recursos.
Casos de uso
Em grandes organizações, gerenciar políticas de segurança em vários projetos pode ser complexo e demorado. As políticas de segurança hierárquicas oferecem as seguintes vantagens para ajudar você a enfrentar esses desafios:
- Controle centralizado: ofereça aos administradores 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, reduzindo o risco de configurações incorretas e falhas de segurança.
- Eficiência: simplifique a implantação de atualizações e mitigações de segurança, como o bloqueio de intervalos de endereços IP específicos ou a correção de vulnerabilidades críticas, em um grande número de recursos simultaneamente.
- Delegação: delegue responsabilidades de segurança a diferentes equipes ou departamentos aplicando políticas nos níveis adequados da hierarquia.
Você pode aplicar e combinar esses princípios gerais para atender às necessidades da sua organização. Considere os seguintes exemplos de casos de uso:
- Bloqueio de endereços IP em toda a organização: é possível bloquear o tráfego de intervalos de endereços IP maliciosos conhecidos em todos os projetos da organização.
- Restrições geográficas: é possível restringir o tráfego de regiões geográficas específicas no nível da organização ou da pasta.
- Mitigação de CVEs: é possível implantar rapidamente regras de WAF para mitigar vulnerabilidades críticas em vários projetos.
- Aplicação da compliance: é possível aplicar a adesão aos requisitos regulatórios com políticas de segurança consistentes em toda a organização.
- Controle de acesso granular: é possível conceder a intervalos de endereços IP ou regiões geográficas específicas acesso a todos os recursos em uma pasta específica.
Recursos
As políticas de segurança hierárquicas são compatíveis com um subconjunto dos recursos das políticas de segurança no nível do serviço. A tabela a seguir compara os recursos do Google Cloud Armor que podem ser usados com políticas de segurança hierárquicas e de nível de serviço:
| Tipo de front-end |
|
|
| Ponto de anexo (recurso protegido) | Serviço de back-end | Nós da hierarquia de recursos |
| Ações da regra |
|
|
| Endereço IP de origem | ||
| País de origem | ||
| ASN de origem | ||
| Gerenciamento de bots | (somente
EXTERNAL_302 e decoração de solicitação) |
|
| Filtragem da camada 7 | ||
| WAF | ||
| Google Threat Intelligence | ||
| reCAPTCHA | ||
| Proteção adaptativa | ||
| Grupos de endereços | ||
| Grupos de endereços no nível da organização | ||
| Security Command Center | ||
| Cloud Monitoring | ||
| Solicitar geração de registros |
Como funcionam as políticas de segurança hierárquicas
Quando você cria uma política de segurança hierárquica, ela é criada no nível da organização ou da pasta, e esse recurso tem propriedade sobre a política. Depois de criar uma política de segurança hierárquica, as regras dela não são aplicadas a nenhum dos seus recursos.
Em seguida, associe a política de segurança hierárquica a uma organização, pasta ou projeto, que pode ser o mesmo recurso proprietário da política. Depois de associar uma política de segurança hierárquica a um recurso, ela aplica as regras da política aos recursos protegidos no nó e abaixo dele na hierarquia de recursos. Para ajudar você a decidir a qual recurso anexar suas políticas de segurança hierárquicas, consulte a lista a seguir de casos de uso básicos para cada recurso:
- Organização: considere as políticas de segurança hierárquicas no nível da organização como o tipo padrão de política de segurança hierárquica.
Essas políticas têm permissões amplas do Identity and Access Management (IAM)
e se aplicam a todos os nós da organização. Especifique esses recursos usando a flag
--organizationdurante a associação. - Pasta: use essas 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 organização. Especifique esses recursos usando a flag
--folderdurante a associação. - Projeto: use esse tipo de política de segurança hierárquica quando precisar aplicar as mesmas regras de política de segurança em todos os recursos de um projeto, como uma lista de bloqueio de endereços IP em vários serviços de back-end.
Especifique esses recursos usando a flag
--projectdurante a associação. - No nível do serviço: use políticas de segurança no nível do serviço quando precisar de regras de política de segurança exclusivas que sejam diferentes entre cada um dos seus serviços. Cada política de segurança no nível do serviço aplica as regras apenas à política de back-end a que está anexada. Especifique esses recursos usando a flag
--project-number.
Só é possível usar uma dessas flags por política de segurança hierárquica. Você
especifica o restante das flags, como --name ou --type, da mesma forma que faz ao
configurar uma política de segurança no nível do serviço. Consulte a lista a seguir para mais informações sobre como as políticas de segurança hierárquicas funcionam:
- Quando uma política de segurança hierárquica é associada a um nó da hierarquia de recursos, todos os recursos protegidos abaixo desse nó na hierarquia herdam a política.
- É possível conferir as políticas de segurança que se aplicam a cada recurso protegido em um projeto, em todas as políticas de segurança hierárquicas e de nível de serviço. Para mais informações, consulte Ver todas as regras efetivas do Google Cloud Armor para um recurso protegido.
- É possível mover políticas de segurança hierárquicas de um nó de hierarquia de recursos para outro. Isso pode ser feito quando você planeja reorganizar a estrutura de pastas.
- Quando você exclui 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ó é excluída se você a criou nesse nó.
- Se você criou a política de segurança em outro lugar e a moveu para o nó, ela não será excluída.
- Para evitar a exclusão acidental das políticas de segurança hierárquicas, recomendamos que você mova as políticas que quer manter para outro nó da hierarquia de recursos antes de excluir o nó atual.
Ordem de avaliação da regra
O Google Cloud Armor avalia as políticas de segurança na seguinte ordem:
- Políticas de segurança hierárquicas no nível da organização
- Políticas de segurança hierárquicas no nível da pasta (começando com a pasta principal e seguindo para cada subpasta)
- Políticas de segurança hierárquicas no nível do projeto
- Políticas de segurança no nível do serviço
Essa ordem de avaliação significa que você pode ter uma política de segurança hierárquica com uma prioridade baixa que é avaliada antes de uma política de segurança no nível do serviço com uma prioridade alta. Pense com cuidado nas regras de política de segurança de alto nível que você já tem e considere o que acontece se o Google Cloud Armor não avaliar uma solicitação permitida ou negada por uma política de segurança hierárquica em relação a elas.
A ação goto_next
O Google Cloud Armor tem uma ação de regra exclusiva para políticas de segurança hierárquicas: a ação goto_next. Quando o Google Cloud Armor aplica
essa ação, ele para de avaliar as regras na política de segurança atual e
começa a avaliar as regras na próxima política de segurança.
Considere um exemplo em que você tem uma política de segurança hierárquica no nível da organização com muitas regras que quer usar para restringir solicitações em toda a organização. Você quer
permitir que solicitações de um determinado intervalo de endereços IP pulem a avaliação dessas
regras em toda a organização. Portanto, crie uma regra de prioridade máxima que corresponda a esse intervalo de endereços IP com a ação goto_next. As solicitações desse intervalo de endereços IP são avaliadas primeiro em relação a essa regra e, como atendem à condição de correspondência, não são avaliadas em relação a outras regras nessa política de segurança hierárquica no nível da organização.
No mesmo exemplo, se você usasse uma ação allow ou deny em vez da
goto_next, a solicitação seria permitida ou negada assim que a condição de
correspondência fosse atendida. Essa avaliação hierárquica significa que nenhuma outra política de segurança é avaliada em relação a essa solicitação.
Comportamento de faturamento e inscrição no Google Cloud Armor Enterprise
Ao anexar uma política de segurança hierárquica, cada um dos projetos que herdam a política precisa ser inscrito no Cloud Armor Enterprise. Isso inclui todos os projetos em uma organização ou pasta com uma política de segurança hierárquica que não foram excluídos explicitamente, e todos os projetos com uma política de segurança hierárquica anexada diretamente ao projeto.
- Os projetos vinculados a uma conta do Cloud Billing com uma assinatura anual do Cloud Armor Enterprise são inscritos automaticamente nesse serviço, caso ainda não estejam.
- Sem uma assinatura 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 você inscrever a conta de faturamento no Cloud Armor Enterprise Anual depois que seu projeto for inscrito automaticamente no Cloud Armor Enterprise Paygo, ele não será inscrito automaticamente no Anual. Para mais informações sobre o Cloud Armor Enterprise Paygo, consulte Google Cloud Armor Standard x Cloud Armor Enterprise.
- Se você atualizar uma política de segurança hierárquica para excluir um projeto depois que ele foi inscrito automaticamente no Cloud Armor Enterprise, ele não será cancelado automaticamente. Para cancelar o registro manual do seu projeto, consulte Remover um projeto do Cloud Armor Enterprise.
- Não é possível remover um projeto do Cloud Armor Enterprise enquanto ele tiver políticas de segurança hierárquicas herdadas.
A inscrição automática pode levar até uma semana para ser concluída. Durante esse período, suas políticas de segurança hierárquicas vão estar em vigor, e não haverá custos do Cloud Armor Enterprise. Quando seu projeto é registrado, os registros de auditoria são atualizados para refletir o status do Cloud Armor Enterprise do projeto, e você vê o novo nível do projeto no console Google Cloud .
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 estão em uma organização.
- Para projetos novos ou restaurados recentemente, pode levar algumas horas para que as políticas de segurança herdadas sejam propagadas.
- Para um projeto que ativou recentemente a API Compute Engine, pode levar algumas horas para que as políticas de segurança herdadas sejam propagadas.
- É possível ajustar regras do WAF pré-configuradas em políticas de segurança hierárquicas de sua propriedade, mas os proprietários de serviços que herdam uma política de segurança hierárquica não podem fazer isso.