Recomendamos que defina restrições de políticas que apliquem configurações de recursos aceitáveis e evitem configurações arriscadas. O projeto usa uma combinação de restrições de políticas da organização e validação de infraestrutura como código (IaC) no seu pipeline. Estes controlos impedem a criação de recursos que não cumprem as diretrizes das suas políticas. A aplicação destes controlos no início da conceção e criação das suas cargas de trabalho ajuda a evitar o trabalho de remediação mais tarde.
Restrições de políticas da organização
O serviço Organization Policy aplica restrições para garantir que não é possível criar determinadas configurações de recursos na sua Google Cloud organização, mesmo por alguém com uma função do IAM suficientemente privilegiada.
O projeto base aplica políticas no nó da organização para que estes controlos sejam herdados por todas as pastas e projetos na organização. Este conjunto de políticas foi concebido para impedir determinadas configurações de alto risco, como expor uma VM à Internet pública ou conceder acesso público a contentores de armazenamento, a menos que permita deliberadamente uma exceção à política.
A tabela seguinte apresenta as restrições da política da organização implementadas no projeto:
| Restrição da política da organização | Descrição |
|---|---|
| A virtualização aninhada em VMs do Compute Engine pode evitar a monitorização e outras ferramentas de segurança para as suas VMs se estiver mal configurada. Esta restrição impede a criação de virtualização aninhada. |
| As funções de IAM, como |
| As sub-redes IPv6 externas podem ser expostas a acesso não autorizado à Internet se estiverem mal configuradas. Esta restrição impede a criação de sub-redes IPv6 externas. |
| O comportamento predefinido de definir chaves SSH nos metadados pode permitir o acesso remoto não autorizado a VMs se as chaves forem expostas. Esta restrição aplica a utilização do Início de sessão do SO em vez de chaves SSH baseadas em metadados. |
|
O encaminhamento do protocolo de VM para endereços IP externos pode levar à saída não autorizada da Internet se o encaminhamento estiver mal configurado. Esta restrição permite o encaminhamento de protocolos de VMs apenas para endereços internos. |
|
A eliminação de um projeto anfitrião da VPC partilhada pode ser prejudicial para todos os projetos de serviço que usam recursos de rede. Esta restrição impede a eliminação acidental ou maliciosa dos projetos anfitriões da VPC partilhada, impedindo a remoção da retenção do projeto nestes projetos. |
|
Não recomendamos uma definição antiga para o DNS interno global (ao nível do projeto) porque reduz a disponibilidade dos serviços. Esta restrição impede a utilização da definição antiga. |
| A rede de VPC predefinida e as regras de firewall de VPC predefinidas excessivamente permissivas são criadas em todos os novos projetos que ativam a API Compute Engine. Esta restrição ignora a criação da rede predefinida e das regras de firewall da VPC predefinidas. |
| Por predefinição, é criada uma VM com um endereço IPv4 externo que pode originar um acesso não autorizado à Internet. Esta restrição configura uma lista de autorizações vazia de endereços IP externos que a VM pode usar e nega todos os outros. |
|
Por predefinição, os contactos essenciais podem ser configurados para enviar notificações sobre o seu domínio a qualquer outro domínio. Esta restrição garante que apenas os endereços de email em domínios aprovados podem ser definidos como destinatários para contactos essenciais. |
| Por predefinição, as políticas de permissão podem ser concedidas a qualquer Conta Google, incluindo contas não geridas e contas pertencentes a organizações externas. Esta restrição garante que as políticas de permissão na sua organização só podem ser concedidas a contas geridas do seu próprio domínio. Opcionalmente, pode permitir domínios adicionais. |
|
Por predefinição, as contas de serviço predefinidas recebem automaticamente funções excessivamente permissivas. Esta restrição impede as concessões automáticas de funções do IAM a contas de serviço predefinidas. |
|
As chaves de contas de serviço são uma credencial persistente de alto risco e, na maioria dos casos, pode usar uma alternativa mais segura às chaves de contas de serviço. Esta restrição impede a criação de chaves de contas de serviço. |
|
O carregamento de material de chaves de contas de serviço pode aumentar o risco se o material de chaves for exposto. Esta restrição impede o carregamento de chaves de contas de serviço. |
|
As instâncias do Cloud SQL podem ser expostas a acesso não autenticado à Internet se as instâncias estiverem configuradas para usar redes autorizadas sem um proxy Auth do Cloud SQL. Esta política impede a configuração de redes autorizadas para acesso à base de dados e força a utilização do proxy Auth do Cloud SQL. |
| As instâncias do Cloud SQL podem ser expostas a acesso à Internet não autenticado se forem criadas com endereços IP públicos. Esta restrição impede endereços IP públicos em instâncias do Cloud SQL. |
| Por predefinição, os objetos no Cloud Storage podem ser acedidos através de listas de controlo de acesso (ACLs) antigas, em vez da IAM, o que pode levar a controlos de acesso inconsistentes e exposição acidental se estiverem configurados incorretamente. O acesso à LCA antiga não é afetado pela restrição |
|
Os contentores do Cloud Storage podem ser expostos a acesso à Internet não autenticado se estiverem configurados incorretamente. Esta restrição impede as ACLs e as autorizações da IAM que concedem acesso a |
Estas políticas são um ponto de partida que recomendamos para a maioria dos clientes e
a maioria dos cenários, mas pode ter de 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 contentor do Cloud Storage como back-end para o Cloud CDN para alojar recursos públicos é bloqueada por storage.publicAccessPrevention, ou uma app do Cloud Run virada para o público que não requer autenticação é bloqueada por iam.allowedPolicyMemberDomains. Nestes casos, modifique a política da organização ao nível da pasta ou do projeto para permitir uma exceção restrita.
Também pode adicionar condicionalmente restrições à política da organização
definindo uma etiqueta que conceda uma exceção ou uma aplicação para a política e, em seguida,
aplicando a etiqueta a projetos e pastas.
Para ver restrições adicionais, consulte as restrições disponíveis e as restrições personalizadas.
Validação pré-implementação da infraestrutura como código
O projeto usa uma abordagem GitOps para gerir a infraestrutura, o que significa que todas as alterações à infraestrutura são implementadas através da infraestrutura como código (IaC) controlada por versões e podem ser validadas antes da implementação.
As políticas aplicadas no projeto definem configurações de recursos aceitáveis que podem ser implementadas pelo seu pipeline. Se o código enviado para o seu repositório do GitHub não passar nas verificações de políticas, não são implementados recursos.
Para obter informações sobre como as pipelines são usadas e como os controlos são aplicados através da automatização de CI/CD, consulte a metodologia de implementação.
O que se segue?
- Leia acerca da metodologia de implementação (documento seguinte nesta série)