Recomendamos que você defina restrições de política que apliquem configurações aceitáveis de recursos e evitem configurações arriscadas. O blueprint usa uma combinação de restrições de política da organização e validação de infraestrutura como código (IaC) no pipeline. Esses controles impedem a criação de recursos que não atendem às diretrizes da sua política. A aplicação desses controles no início do design e na criação de suas cargas de trabalho ajuda a evitar o trabalho de correção mais tarde.
Restrições das políticas da organização
O serviço Política da organização aplica restrições para garantir que determinadas configurações de recursos não possam ser criadas na sua organização do Google Cloud, mesmo por alguém com um papel do IAM suficientemente privilegiado.
O blueprint aplica políticas no nó da organização para que esses controles sejam herdados por todas as pastas e projetos dentro da organização. Esse pacote de políticas foi criado para impedir determinadas configurações de alto risco, como expor uma VM à Internet pública ou conceder acesso público a buckets de armazenamento, a menos que você permita deliberadamente uma exceção à política.
A tabela a seguir apresenta as restrições da política da organização implementadas no blueprint:
| Restrição da política da organização | Descrição |
|---|---|
| A virtualização aninhada nas VMs do Compute Engine pode escapar do monitoramento e de outras ferramentas de segurança das VMs se configuradas incorretamente. Essa restrição impede a criação de virtualização aninhada. |
| Os papéis do IAM, como |
| As sub-redes IPv6 externas podem ser expostas a acesso não autorizado da Internet se estiverem configuradas incorretamente. Essa restrição impede a criação de sub-redes IPv6 externas. |
| O comportamento padrão de definir chaves SSH em metadados pode permitir acesso remoto não autorizado a VMs se as chaves estiverem expostas. Essa restrição aplica o uso do Login do SO em vez de chaves SSH baseadas em metadados. |
|
O encaminhamento de protocolo de VM para endereços IP externos poderá levar a saída de Internet não autorizada se o encaminhamento estiver configurado incorretamente. Essa restrição permite o encaminhamento de protocolo da VM apenas para endereços internos. |
|
A exclusão de um projeto host de VPC compartilhada pode ser prejudicial a todos os projetos de serviço que usam recursos de rede. Essa restrição impede a exclusão acidental ou maliciosa dos projetos host da VPC compartilhada e impede a remoção da garantia do projeto. |
|
Não recomendamos uma configuração legada para DNS interno global (em todo o projeto) porque ela reduz a disponibilidade do serviço. Essa restrição impede o uso da configuração legada. |
| Uma rede VPC padrão e regras de firewall VPC padrão excessivamente permissivas são criadas em cada novo projeto que ativa a API Compute Engine. Essa restrição ignora a criação das regras de firewall da rede padrão e da VPC padrão. |
| Por padrão, uma VM é criada com um endereço IPv4 externo que pode levar a acesso não autorizado à Internet. Essa restrição configura uma lista de permissões vazia de endereços IP externos que a VM pode usar e nega todos os outros. |
|
Por padrão, os Contatos essenciais podem ser configurados para enviar notificações sobre seu domínio para qualquer outro domínio. Essa restrição garante que apenas endereços de e-mail em domínios aprovados possam ser definidos como destinatários de contatos essenciais. |
| Por padrão, as políticas de permissão podem ser concedidas a qualquer Conta do Google, incluindo contas não gerenciadas e contas pertencentes a organizações externas. Essa restrição garante que as políticas de permissão na organização só possam ser concedidas a contas gerenciadas no seu próprio domínio. Você também pode permitir outros domínios. |
|
Por padrão, as contas de serviço padrão recebem automaticamente papéis excessivamente permissivos. Essa restrição impede a concessão automática de papéis do IAM a contas de serviço padrão. |
|
As chaves de conta de serviço são uma credencial persistente de alto risco e, na maioria dos casos, uma alternativa mais segura para as chaves de conta de serviço pode ser usada. Essa restrição impede a criação de chaves de contas de serviço. |
|
Fazer upload do material da chave da conta de serviço pode aumentar o risco se esse material for exposto. Essa restrição impede o upload de chaves de contas de serviço. |
|
As instâncias do Cloud SQL poderão ser expostas ao acesso não autenticado à Internet se estiverem configuradas para usar redes autorizadas sem um proxy de autenticação do Cloud SQL. Essa política impede a configuração de redes autorizadas para acesso ao banco de dados e força o uso do proxy do Cloud SQL Auth. |
| As instâncias do Cloud SQL podem ser expostas ao acesso não autenticado à Internet se elas forem criadas com endereços IP públicos. Essa restrição impede endereços IP públicos em instâncias do Cloud SQL. |
| Por
padrão, os objetos no Cloud Storage podem ser acessados por listas de controle de acesso (ACLs)
legadas em vez do IAM. Isso pode levar a controles de acesso
inconsistentes e exposição acidental se forem configurados incorretamente de dois minutos. O acesso da ACL legada não é afetado pela restrição |
|
Os buckets do Cloud Storage podem ser expostos ao acesso
não autenticado à Internet se configurados incorretamente. Essa restrição impede ACLs e permissões do IAM que concedem acesso a |
Essas políticas são um ponto de partida recomendado para a maioria dos clientes e
para a maioria dos cenários, mas talvez seja necessário modificar as restrições da política da organização para
acomodar determinados tipos de carga de trabalho. Por exemplo, uma carga de trabalho que usa um
bucket do Cloud Storage como back-end para o Cloud CDN hospedar
recursos públicos é bloqueada por storage.publicAccessPrevention ou um
aplicativo do Cloud Run voltado para o público que não exigir autenticação é
bloqueada por iam.allowedPolicyMemberDomains. Nesses casos, modifique a política da organização no nível da pasta ou do projeto para permitir uma exceção restrita.
Também é possível adicionar restrições à política da organização de modo condicional definindo uma tag que conceda uma exceção ou aplicação para a política e, em seguida, aplicando a tag a projetos e pastas.
Para ver outras restrições, consulte as restrições disponíveis e as restrições personalizadas.
Validação pré-implantação de infraestrutura como código
O blueprint usa uma abordagem de GitOps para gerenciar a infraestrutura, o que significa que todas as alterações de infraestrutura são implementadas por meio da infraestrutura como código (IaC, na sigla em inglês) com controle de versões e podem ser validadas antes da implantação.
As políticas aplicadas no blueprint definem configurações de recursos aceitáveis que podem ser implantadas pelo pipeline. Se o código enviado ao seu repositório do GitHub não passar nas verificações de política, nenhum recurso será implantado.
Para informações sobre como os pipelines são usados e como os controles são aplicados por meio da automação de CI/CD, consulte a metodologia de implantação.
A seguir
- Leia sobre a metodologia de implantação (próximo documento desta série)