Implemente o projeto

Last reviewed 2025-05-15 UTC

Esta secção descreve o processo que pode usar para implementar o esquema, as respetivas convenções de nomenclatura e alternativas às recomendações do esquema.

Reunir tudo num só lugar

Para implementar a sua própria base empresarial em conformidade com as práticas recomendadas e as recomendações deste plano detalhado, siga as tarefas de alto nível resumidas nesta secção. A implementação requer uma combinação de passos de configuração prévia, implementação automática através do terraform-example-foundation no GitHub e passos adicionais que têm de ser configurados manualmente após a implementação inicial da base estar concluída.

Processo Passos

Pré-requisitos antes de implementar os recursos do pipeline de base

Conclua os passos seguintes antes de implementar o pipeline de base:

Para fazer a associação a um ambiente no local existente, prepare o seguinte:

Passos para implementar o terraform-example-foundation a partir do GitHub

Siga as direções do ficheiro README para cada fase para implementar o terraform-example-foundation do GitHub:

Passos adicionais após a implementação da IaC

Depois de implementar o código do Terraform, conclua o seguinte:

Controlos administrativos adicionais para clientes com cargas de trabalho confidenciais

Google Cloud oferece controlos administrativos adicionais que podem ajudar a cumprir os seus requisitos de segurança e conformidade. No entanto, alguns controlos envolvem custos adicionais ou compromissos operacionais que podem não ser adequados para todos os clientes. Estes controlos também requerem entradas personalizadas para os seus requisitos específicos que não podem ser totalmente automatizados no esquema com um valor predefinido para todos os clientes.

Esta secção apresenta os controlos de segurança que aplica centralmente à sua base. Esta secção não se destina a ser exaustiva de todos os controlos de segurança que pode aplicar a cargas de trabalho específicas. Para mais informações sobre os produtos e as soluções de segurança da Google, consulte o Google Cloud centro de práticas recomendadas de segurança.

Avalie se os seguintes controlos são adequados para a sua base, com base nos requisitos de conformidade, na tolerância ao risco e na sensibilidade dos dados.

Controlo Descrição

Proteja os seus recursos com os VPC Service Controls

O VPC Service Controls permite-lhe definir políticas de segurança que impedem o acesso a serviços geridos pela Google fora de um perímetro fidedigno, bloqueiam o acesso a dados de localizações não fidedignas e mitigam os riscos de exfiltração de dados. No entanto, os VPC Service Controls podem fazer com que os serviços existentes deixem de funcionar até definir exceções para permitir padrões de acesso pretendidos.

Avalie se o valor da mitigação dos riscos de exfiltração justifica o aumento da complexidade e da sobrecarga operacional da adoção dos VPC Service Controls. O projeto prepara os controlos de rede de pré-requisitos e um perímetro do VPC Service Controls de teste, mas o perímetro não é aplicado até que tome medidas adicionais.

Restrinja as localizações dos recursos

Pode ter requisitos regulamentares que exigem que os recursos na nuvem só sejam implementados em localizações geográficas aprovadas. Esta restrição da política da organização impõe que os recursos só podem ser implementados na lista de localizações que definir.

Ative o Assured Workloads

O Assured Workloads oferece controlos de conformidade adicionais que ajudam a cumprir regimes regulamentares específicos. O projeto fornece variáveis opcionais no pipeline de implementação para ativação.

Ative os registos de acesso aos dados

Pode ter um requisito para registar todo o acesso a determinados dados confidenciais ou recursos.

Avalie onde as suas cargas de trabalho processam dados confidenciais que requerem registos de acesso a dados e ative os registos para cada serviço e ambiente que trabalham com dados confidenciais.

Ative a aprovação de acesso

A aprovação de acesso garante que o apoio ao cliente da Google Cloud e a engenharia requerem a sua aprovação explícita sempre que precisarem de aceder ao seu conteúdo de cliente.

Avalie o processo operacional necessário para rever pedidos de aprovação de acesso de modo a mitigar possíveis atrasos na resolução de incidentes de apoio técnico.

Ative as justificações de acesso às chaves

As Justificações de acesso às chaves permitem-lhe controlar programaticamente se a Google pode aceder às suas chaves de encriptação, inclusive para operações automatizadas e para o apoio ao cliente aceder ao conteúdo dos seus clientes.

Avalie o custo e a sobrecarga operacional associados às justificações de acesso a chaves, bem como a respetiva dependência do Cloud External Key Manager (Cloud EKM).

Desativar Cloud Shell

O Cloud Shell é um ambiente de programação online. Esta shell está alojada num servidor gerido pela Google fora do seu ambiente e, por isso, não está sujeita aos controlos que possa ter implementado nas suas estações de trabalho de programador.

Se quiser controlar rigorosamente as estações de trabalho que um programador pode usar para aceder a recursos na nuvem, desative o Cloud Shell. Também pode avaliar as estações de trabalho na nuvem para uma opção de estação de trabalho configurável no seu próprio ambiente.

Restrinja o acesso à Google Cloud consola

Google Cloud permite-lhe restringir o acesso à Google Cloud consola com base em atributos de nível de acesso, como a associação a grupos, intervalos de endereços IP fidedignos e validação de dispositivos. Alguns atributos requerem uma subscrição adicional do Chrome Enterprise Premium.

Avalie os padrões de acesso nos quais confia para o acesso dos utilizadores a aplicações baseadas na Web como a consola, como parte de uma implementação de confiança zero.

Convenções de nomenclatura

Recomendamos que tenha uma convenção de nomenclatura padronizada para os seus Google Cloud recursos. A tabela seguinte descreve as convenções recomendadas para os nomes dos recursos no projeto.

Recurso Convenção de nomenclatura

Pasta

fldr-environment

environment é uma descrição dos recursos ao nível da pasta na organização Google Cloud. Por exemplo, bootstrap, common, production, nonproduction, development ou network.

Por exemplo: fldr-production

ID do projeto

prj-environmentcode-description-randomid

  • environmentcode é uma forma abreviada do campo de ambiente (um de b, c, p, n, d ou net). Os projetos anfitriões da VPC partilhada usam o environmentcode do ambiente associado. Os projetos de recursos de rede que são partilhados entre ambientes, como o projeto interconnect, usam o código do ambiente net.
  • description são informações adicionais sobre o projeto. Pode usar abreviaturas curtas e legíveis.
  • randomid é um sufixo aleatório para evitar colisões de nomes de recursos que têm de ser globalmente exclusivos e para mitigar a adivinhação de nomes de recursos por parte de atacantes. O projeto adiciona automaticamente um identificador alfanumérico de quatro carateres aleatório.

Por exemplo: prj-c-logging-a1b2

Rede da VPC

vpc-environmentcode-vpctype

  • environmentcode é uma forma abreviada do campo de ambiente (um de b, c, p, n, d ou net).
  • vpctype é um de svpc, float ou peer.

Por exemplo: vpc-p-svpc

Sub-rede

sn-environmentcode-vpctype-region{-description}

  • environmentcode é uma forma abreviada do campo de ambiente (um de b, c, p, n, d ou net).
  • vpctype é um de svpc, float ou peer.
  • region é qualquer Google Cloud região válida onde o recurso se encontra. Recomendamos que remova os hífens e use uma forma abreviada de algumas regiões e direções para evitar atingir os limites de carateres. Por exemplo, au (Austrália), na (América do Norte), sa (América do Sul), eu (Europa), se (sudeste) ou ne (nordeste).
  • description são informações adicionais sobre a sub-rede. Pode usar abreviaturas curtas e legíveis.

Por exemplo: sn-p-svpc-uswest1

Políticas de firewall

fw-firewalltype-scope-environmentcode{-description}

  • firewalltype é hierarchical ou network.
  • scope é global ou a Google Cloud região onde o recurso está localizado. Recomendamos que remova os hífens e use uma forma abreviada de algumas regiões e direções para evitar atingir os limites de carateres. Por exemplo, au (Austrália), na (América do Norte), sa (América do Sul), eu (Europa), se (sudeste) ou ne (nordeste).
  • environmentcode é uma forma abreviada do campo de ambiente (um de b, c, p, n, d ou net) que detém o recurso de política.
  • description são informações adicionais acerca da política de firewall hierárquica. Pode usar abreviaturas curtas e legíveis.

Por exemplo:

fw-hierarchical-global-c-01

fw-network-uswest1-p-svpc

Cloud Router

cr-environmentcode-vpctype-region{-description}

  • environmentcode é uma forma abreviada do campo de ambiente (um de b, c, p, n, d ou net).
  • vpctype é um de svpc, float ou peer.
  • region é qualquer região Google Cloud válida onde o recurso se encontra. Recomendamos que remova os hífens e use uma forma abreviada de algumas regiões e direções para evitar atingir os limites de carateres. Por exemplo, au (Austrália), na (América do Norte), sa (América do Sul), eu (Europa), se (sudeste) ou ne (nordeste).
  • description são informações adicionais sobre o router na nuvem. Pode usar abreviaturas curtas e legíveis.

Por exemplo: cr-p-svpc-useast1-cr1

Ligação do Cloud Interconnect

ic-dc-colo

  • dc é o nome do seu centro de dados ao qual um Cloud Interconnect está ligado.
  • colo é o nome da instalação de alojamento conjunto com a qual o Cloud Interconnect do centro de dados no local tem uma relação de intercâmbio.

Por exemplo: ic-mydatacenter-lgazone1

Associação VLAN do Cloud Interconnect

vl-dc-colo-environmentcode-vpctype-region{-description}

  • dc é o nome do seu centro de dados ao qual um Cloud Interconnect está ligado.
  • colo é o nome da instalação de alojamento conjunto com a qual o Cloud Interconnect do centro de dados no local tem uma relação de peering.
  • environmentcode é uma forma abreviada do campo de ambiente (um de b, c, p, n, d ou net).
  • vpctype é um de svpc, float ou peer.
  • region é qualquer região Google Cloud válida onde o recurso se encontra. Recomendamos que remova os hífens e use uma forma abreviada de algumas regiões e direções para evitar atingir os limites de carateres. Por exemplo, au (Austrália), na (América do Norte), sa (América do Sul), eu (Europa), se (sudeste) ou ne (nordeste).
  • description são informações adicionais sobre a VLAN. Pode usar abreviaturas curtas e legíveis.

Por exemplo: vl-mydatacenter-lgazone1-p-svpc-useast1-cr1

Grupo

grp-gcp-description@example.com

Onde description são informações adicionais sobre o grupo. Pode usar abreviaturas curtas e legíveis.

Por exemplo: grp-gcp-billingadmin@example.com

Função personalizada

rl-description

Onde description estão informações adicionais sobre a função. Pode usar abreviaturas curtas e legíveis por humanos.

Por exemplo: rl-customcomputeadmin

Conta de serviço

sa-description@projectid.iam.gserviceaccount.com

Onde:

  • description são informações adicionais sobre a conta de serviço. Pode usar abreviaturas curtas e legíveis.
  • projectid é o identificador do projeto exclusivo a nível global.

Por exemplo: sa-terraform-net@prj-b-seed-a1b2.iam.gserviceaccount.com

Contentor de armazenamento

bkt-projectid-description

Onde:

  • projectid é o identificador do projeto exclusivo a nível global.
  • description são informações adicionais sobre o contentor de armazenamento. Pode usar abreviaturas curtas e legíveis.

Por exemplo: bkt-prj-c-infra-pipeline-a1b2-app-artifacts

Alternativas às recomendações predefinidas

As práticas recomendadas no plano podem não funcionar para todos os clientes. Pode personalizar qualquer uma das recomendações para cumprir os seus requisitos específicos. A tabela seguinte apresenta algumas das variações comuns que pode precisar com base na sua pilha de tecnologia existente e nas formas de trabalhar.

Área de decisão Alternativas possíveis

Organização: o projeto usa uma única organização como o nó de raiz para todos os recursos.

Decidir uma hierarquia de recursos para a sua Google Cloud zona de destino apresenta cenários em que pode preferir várias organizações, como os seguintes:

  • A sua organização inclui subempresas que provavelmente serão vendidas no futuro ou que funcionam como entidades completamente separadas.
  • Quer fazer experiências num ambiente de sandbox sem conetividade com a sua organização existente.

Estrutura de pastas: o projeto tem uma estrutura de pastas que divide as cargas de trabalho em pastas production, non-production e development na camada superior.

Decidir uma hierarquia de recursos para a sua Google Cloud zona de destino apresenta outras abordagens para estruturar pastas com base na forma como quer gerir recursos e herdar políticas, como:

  • Pastas com base nos ambientes de aplicação
  • Pastas com base em entidades ou subsidiárias regionais
  • Pastas com base na estrutura de responsabilidade

Políticas da organização: o projeto aplica todas as restrições das políticas da organização no nó da organização.

Pode ter políticas de segurança ou formas de trabalhar diferentes para diferentes partes da empresa. Neste cenário, aplique restrições da política da organização num nó inferior na hierarquia de recursos. Reveja a lista completa das restrições das políticas da organização que ajudam a cumprir os seus requisitos.

Ferramentas de pipeline de implementação: o esquema usa o Cloud Build para executar o pipeline de automatização.

Pode preferir outros produtos para o seu pipeline de implementação, como o Terraform Enterprise, os GitLab Runners, as GitHub Actions ou o Jenkins. O plano inclui instruções alternativas para cada produto.

Repositório de código para implementação: o projeto usa os Cloud Source Repositories como o repositório Git privado gerido.

Use o seu sistema de controlo de versões preferido para gerir repositórios de código, como o GitLab, o GitHub ou o Bitbucket.

Se usar um repositório privado alojado no seu ambiente no local, configure um caminho de rede privado do seu repositório para o seu ambiente Google Cloud.

Fornecedor de identidade: o projeto pressupõe um Active Directory no local e federa identidades para o Cloud ID através da Sincronização de diretórios do Google Cloud.

Se já usa o Google Workspace, pode usar as identidades Google que já são geridas no Google Workspace.

Se não tiver um fornecedor de identidades existente, pode criar e gerir identidades de utilizadores diretamente no Cloud Identity.

Se tiver um fornecedor de identidade existente, como o Okta, o Ping ou o Azure Entra ID, pode gerir as contas de utilizador no seu fornecedor de identidade existente e sincronizá-las com o Cloud ID.

Se tiver requisitos de soberania de dados ou de conformidade que lhe impeçam de usar o Cloud Identity e se não precisar de identidades de utilizadores Google geridas para outros serviços Google, como o Google Ads ou a Google Marketing Platform, pode preferir a federação de identidades da força de trabalho. Neste cenário, tenha em atenção as limitações dos serviços suportados.

Várias regiões: o esquema implementa recursos regionais em duas regiões diferentes para ajudar a ativar a conceção de cargas de trabalho tendo em conta os requisitos de alta disponibilidade e recuperação de desastres. Google Cloud

Se tiver utilizadores finais em mais localizações geográficas, pode configurar mais Google Cloud regiões para criar recursos mais próximos do utilizador final com menor latência.

Se tiver restrições de soberania dos dados ou as suas necessidades de disponibilidade puderem ser satisfeitas numa única região, pode configurar apenas umaGoogle Cloud região.

Atribuição de endereços IP: o projeto fornece um conjunto de intervalos de endereços IP.

Pode ter de alterar os intervalos de endereços IP específicos que são usados com base na disponibilidade de endereços IP no seu ambiente híbrido existente. Se modificar os intervalos de endereços IP, use o projeto como orientação para o número e o tamanho dos intervalos necessários e reveja os intervalos de endereços IP válidos para Google Cloud.

Rede híbrida: o esquema usa o interligação dedicada em vários sites físicos e Google Cloud regiões para obter a largura de banda e a disponibilidade máximas.

Consoante os seus requisitos de custo, largura de banda e fiabilidade, pode configurar o Partner Interconnect ou o Cloud VPN.

Se precisar de começar a implementar recursos com conetividade privada antes de poder concluir um Dedicated Interconnect, pode começar com a Cloud VPN e mudar para o Dedicated Interconnect mais tarde.

Se não tiver um ambiente no local existente, pode não precisar de redes híbridas.

Perímetro dos VPC Service Controls: o esquema recomenda um único perímetro que inclua todos os projetos de serviço para a sua topologia de VPC partilhada.

Pode ter um exemplo de utilização que requer vários perímetros para uma organização ou pode decidir não usar os VPC Service Controls.

Para mais informações, consulte decida como mitigar a exfiltração de dados através das APIs Google.

Secret Manager: o esquema implementa um projeto para usar o Secret Manager na pasta common para secrets ao nível da organização e um projeto em cada pasta de ambiente para secrets específicos do ambiente.

Se tiver uma única equipa responsável pela gestão e auditoria de segredos confidenciais em toda a organização, pode preferir usar apenas um único projeto para gerir o acesso a segredos.

Se permitir que as equipas de cargas de trabalho geram os seus próprios segredos, pode não usar um projeto centralizado para gerir o acesso aos segredos e, em alternativa, permitir que as equipas usem as suas próprias instâncias do Secret Manager em projetos de cargas de trabalho.

Cloud KMS: o esquema implementa um projeto para usar o Cloud KMS na pasta common para chaves ao nível da organização e um projeto para cada pasta de ambiente para chaves em cada ambiente.

Se tiver uma única equipa responsável pela gestão e auditoria das chaves de encriptação em toda a organização, pode preferir usar apenas um único projeto para gerir o acesso às chaves. Uma abordagem centralizada pode ajudar a cumprir os requisitos de conformidade, como os custodiantes de chaves de PCI.

Se permitir que as equipas de cargas de trabalho geram as suas próprias chaves, pode não usar um projeto centralizado para gerir o acesso às chaves e, em alternativa, permitir que as equipas usem as suas próprias instâncias do Cloud KMS em projetos de cargas de trabalho.

Sinks de registo agregados: o esquema configura um conjunto de sinks de registo no nó da organização para que uma equipa de segurança central possa rever os registos de auditoria de toda a organização.

Pode ter diferentes equipas responsáveis pela auditoria de diferentes partes da empresa, e estas equipas podem precisar de registos diferentes para fazer o seu trabalho. Neste cenário, crie vários destinos agregados nas pastas e nos projetos adequados e crie filtros para que cada equipa receba apenas os registos necessários ou crie vistas de registos para um controlo de acesso detalhado a um contentor de registos comum.

Granularidade dos pipelines de infraestrutura: o esquema usa um modelo em que cada unidade de negócio tem um pipeline de infraestrutura separado para gerir os respetivos projetos de carga de trabalho.

Pode preferir um único pipeline de infraestrutura gerido por uma equipa central se tiver uma equipa central responsável pela implementação de todos os projetos e infraestrutura. Esta equipa central pode aceitar pedidos de envio das equipas de cargas de trabalho para revisão e aprovação antes da criação do projeto, ou a equipa pode criar o pedido de envio em resposta a um sistema de pedidos.

Pode preferir pipelines mais detalhados se: as equipas de cargas de trabalho individuais tiverem a capacidade de personalizar os seus próprios pipelines e quiser criar contas de serviços privilegiadas mais detalhadas para os pipelines.

Exportações do SIEM: o esquema gere todas as conclusões de segurança no Security Command Center.

Decida se vai exportar as conclusões de segurança do Security Command Center para ferramentas como o Google Security Operations ou o seu SIEM existente, ou se as equipas vão usar a consola para ver e gerir as conclusões de segurança. Pode configurar várias exportações com filtros únicos para diferentes equipas com diferentes âmbitos e responsabilidades.

O que se segue?