Implantar o blueprint

Last reviewed 2023-12-20 UTC

Nesta seção, descrevemos o processo que pode ser usado para implantar o blueprint, as convenções de nomenclatura e as alternativas às recomendações de blueprint.

Resumo geral

Para implantar sua própria base corporativa de acordo com as práticas recomendadas e recomendações deste blueprint, siga as tarefas gerais resumidas nesta seção. A implantação requer uma combinação de etapas de configuração de pré-requisito, implantação automatizada por meio de terraform-example-foundation no GitHub e outras etapas que precisam ser configuradas manualmente após o implantação inicial da base estiver concluída.

Processar Etapas

Pré-requisitos antes de implantar os recursos do pipeline básico

Conclua as etapas a seguir antes de implantar o pipeline de base:

Para se conectar a um ambiente local atual, prepare o seguinte:

Etapas para implantar o terraform-example-foundation do GitHub

Siga as instruções README de cada estágio para implantar terraform-example-foundation do GitHub:

Etapas adicionais após a implantação da IaC

Depois de implantar o código do Terraform, siga estas etapas:

Mais controles administrativos para clientes com cargas de trabalho confidenciais

O Google Cloud fornece controles administrativos adicionais que podem ajudar seus requisitos de segurança e conformidade. No entanto, alguns controles envolvem custos adicionais ou compensações operacionais que podem não ser apropriados para todos os clientes. Esses controles também exigem entradas personalizadas para seus requisitos específicos que não podem ser totalmente automatizados no blueprint com um valor padrão para todos os clientes.

Nesta seção, apresentamos os controles de segurança que você aplica centralmente à sua base. Esta seção não inclui todos os controles de segurança que podem ser aplicados a cargas de trabalho específicas. Para mais informações sobre os produtos e as soluções de segurança do Google, consulte a Central de práticas recomendadas de segurança do Google Cloud.

Avalie se os controles a seguir são apropriados para sua base com base em seus requisitos de conformidade, apetite por risco e confidencialidade de dados.

Controle Descrição

Proteger seus recursos com o VPC Service Controls

O VPC Service Controls permite definir políticas de segurança que impedem o acesso a serviços gerenciados pelo Google fora de um perímetro confiável, bloquear o acesso a dados em locais não confiáveis e reduzir os riscos de exfiltração de dados. No entanto, ele pode interromper os serviços atuais até que você defina exceções para permitir os padrões de acesso pretendidos.

Avalie se o valor da redução dos riscos de exfiltração justifica o aumento da complexidade e do overhead operacional da adoção do VPC Service Controls. O blueprint prepara redes restritas e variáveis opcionais para configurar o VPC Service Controls, mas o perímetro não é ativado até que você tome mais etapas para projetá-lo e ativá-lo.

Restringir locais de recursos.

Você pode ter requisitos regulamentares de que os recursos da nuvem só podem ser implantados em localizações geográficas aprovadas. Essa restrição de política da organização impõe que os recursos só podem ser implantados na lista de locais definidos por você.

Ativar Assured Workloads

O Assured Workloads oferece mais controles de compliance que ajudam você a atender a regimes regulatórios específicos. O blueprint fornece variáveis opcionais no pipeline de implantação para ativação.

Ativar registros de acesso a dados

Talvez você tenha que registrar todo o acesso a determinados dados ou recursos confidenciais.

Avalie onde suas cargas de trabalho lidam com dados confidenciais que exigem registros de acesso a dados e ative os registros para cada serviço e ambiente que trabalham com dados confidenciais.

Ativar a aprovação do acesso

A aprovação de acesso garante que o Atendimento ao cliente e a engenharia do Cloud exijam sua aprovação explícita sempre que eles precisarem acessar seus dados.

Avalie o processo operacional necessário para analisar as solicitações de aprovação de acesso e atenuar possíveis atrasos na resolução de incidentes de suporte.

Ativar justificações de acesso às chaves

As Justificativas de acesso às chaves permitem que você controle programaticamente se o Google pode acessar suas chaves de criptografia, inclusive para operações automatizadas e para que o atendimento ao cliente acesse o conteúdo do cliente.

Avalie o custo e a sobrecarga operacional associada às Justificativas de acesso às chaves, bem como a dependência do gerenciador de chaves externas do Cloud (Cloud EKM).

Desativar o Cloud Shell.

O Cloud Shell é um ambiente de desenvolvimento on-line. Esse shell é hospedado em um servidor gerenciado pelo Google fora do seu ambiente e, portanto, não está sujeito aos controles que você pode ter implementado nas suas estações de trabalho do desenvolvedor.

Para controlar rigorosamente quais estações de trabalho um desenvolvedor pode usar para acessar os recursos da nuvem, desative o Cloud Shell. Também é possível avaliar o Cloud Workstations para uma opção de estação de trabalho configurável no seu próprio ambiente.

Restringir o acesso ao console do Google Cloud.

O Google Cloud permite restringir o acesso ao console do Google Cloud com base em atributos de nível de acesso, como associação a grupos, intervalos de endereços IP confiáveis e verificação de dispositivo. Alguns atributos exigem uma assinatura extra do BeyondCorp Enterprise.

Avalie os padrões de acesso em que você confia para o acesso do usuário a aplicativos baseados na Web, como o console, como parte de uma implantação de confiança zero maior.

Convenções de nomeação

Recomendamos que você tenha uma convenção de nomenclatura padronizada para os recursos do Google Cloud. Na tabela a seguir, descrevemos as convenções recomendadas para nomes de recursos no blueprint.

Recurso Convenção de nomenclatura

Pasta

fldr-environment

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

Por exemplo: fldr-production

ID

prj-environmentcode-description-randomid

  • environmentcode é uma forma abreviada do campo de ambiente (um de b, c, p, n, d ou net). Os projetos host de VPC compartilhada usam o environmentcode do ambiente associado. Os projetos para recursos de rede compartilhados entre ambientes, como o projeto interconnect, usam o código de ambiente net.
  • description são informações adicionais sobre o projeto. Use abreviações curtas e legíveis.
  • randomid é um sufixo aleatório para evitar colisões de nomes de recursos que precisam ser globalmente exclusivos e reduzir os invasores que adivinham nomes de recursos. O blueprint adiciona automaticamente um identificador alfanumérico de quatro caracteres aleatório.

Por exemplo: prj-c-logging-a1b2

Rede VPC

vpc-environmentcode-vpctype-vpcconfig

  • environmentcode é uma forma abreviada do campo de ambiente (um de b, c, p, n, d ou net).
  • vpctype é um dos campos shared, float ou peer;
  • vpcconfig é base ou restricted para indicar se a rede precisa ser usada com o VPC Service Controls ou não.

Por exemplo: vpc-p-shared-base

Sub-rede

sn-environmentcode-vpctype-vpcconfig-region{-description}

  • environmentcode é uma forma abreviada do campo de ambiente (um de b, c, p, n, d ou net).
  • vpctype é um dos campos shared, float ou peer;
  • vpcconfig é base ou restricted para indicar se a rede precisa ser usada com o VPC Service Controls ou não.
  • region é qualquer região do Google Cloud válida em que o recurso esteja localizado. Recomendamos remover hífens e usar a forma abreviada de algumas regiões e rotas para evitar atingir os limites de caracteres. 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. Use abreviações curtas e legíveis.

Por exemplo: sn-p-shared-restricted-uswest1

Políticas de firewall

fw-firewalltype-scope-environmentcode{-description}

  • firewalltype é hierarchical ou network.
  • scope é global ou a região do Google Cloud em que o recurso está localizado. Recomendamos remover hífens e usar a forma abreviada de algumas regiões e rotas para evitar atingir os limites de caracteres. 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 é proprietário do recurso de política.
  • description são informações adicionais sobre a política hierárquica de firewall. Você pode usar abreviações curtas e legíveis.

Exemplo:

fw-hierarchical-global-c-01

fw-network-uswest1-p-shared-base

Cloud Router

cr-environmentcode-vpctype-vpcconfig-region{-description}

  • environmentcode é uma forma abreviada do campo de ambiente (um de b, c, p, n, d ou net).
  • vpctype é um dos campos shared, float ou peer;
  • vpcconfig é base ou restricted para indicar se a rede precisa ser usada com o VPC Service Controls ou não.
  • region é qualquer região válida do Google Cloud em que o recurso está localizado. Recomendamos remover hífens e usar a forma abreviada de algumas regiões e rotas para evitar atingir os limites de caracteres. 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 Cloud Router. Você pode usar abreviações curtas e legíveis.

Por exemplo: cr-p-shared-base-useast1-cr1

Conexão do Cloud Interconnect

ic-dc-colo

  • dc é o nome do data center ao qual um Cloud Interconnect está conectado.
  • colo é o nome da instalação de colocation com que o Cloud Interconnect do data center local faz peering.

Por exemplo: ic-mydatacenter-lgazone1

Anexo da VLAN do Cloud Interconnect

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

  • dc é o nome do data center ao qual um Cloud Interconnect está conectado.
  • colo é o nome da instalação de colocation com que o Cloud Interconnect do data center local faz peering.
  • environmentcode é uma forma abreviada do campo de ambiente (um de b, c, p, n, d ou net).
  • vpctype é um dos campos shared, float ou peer;
  • vpcconfig é base ou restricted para indicar se a rede precisa ser usada com o VPC Service Controls ou não.
  • region é qualquer região válida do Google Cloud em que o recurso está localizado. Recomendamos remover hífens e usar a forma abreviada de algumas regiões e rotas para evitar atingir os limites de caracteres. 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. Use abreviações curtas e legíveis.

Por exemplo: vl-mydatacenter-lgazone1-p-shared-base-useast1-cr1

Grupo

grp-gcp-description@example.com

Em que description representa informações adicionais sobre o grupo. Use abreviações curtas e legíveis.

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

Função personalizada

rl-description

em que description apresenta informações adicionais sobre o papel. Use abreviações curtas e legíveis.

Por exemplo: rl-customcomputeadmin

Conta de serviço

sa-description@projectid.iam.gserviceaccount.com

Em que:

  • description são informações adicionais sobre a conta de serviço. Você pode usar abreviações curtas e legíveis.
  • projectid é o identificador de projeto globalmente exclusivo.

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

Bucket de armazenamento

bkt-projectid-description

Em que:

  • projectid é o identificador de projeto globalmente exclusivo.
  • description é uma informação adicional sobre o bucket de armazenamento. Você pode usar abreviações curtas e legíveis.

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

Alternativas às recomendações padrão

As práticas recomendadas no modelo podem não funcionar para todos os clientes. É possível personalizar qualquer uma das recomendações para atender aos seus requisitos específicos. A tabela a seguir apresenta algumas das variações comuns que podem ser necessárias com base na pilha de tecnologia atual e nas formas de trabalho.

arearea de decisão Alternativas possíveis

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

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

  • Sua organização inclui subempresas que provavelmente serão vendidas no futuro ou que são executadas como entidades completamente separadas.
  • Você quer testar um ambiente de sandbox sem conectividade com sua organização atual.

Estrutura de pastas: o blueprint tem uma estrutura de pastas simples, com as cargas de trabalho divididas em pastas production, non-production e development na camada superior.

Decidir uma hierarquia de recursos para a zona de destino do Google Cloud apresenta outras abordagens para estruturar pastas com base em como você quer gerenciar recursos e herdar políticas, como:

  • Pastas com base em ambientes de aplicativos
  • Pastas com base em entidades regionais ou subsidiárias
  • Pastas com base no framework de responsabilidade

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

É possível ter diferentes políticas de segurança ou formas de trabalhar para diferentes partes da empresa. Nesse cenário, aplique as restrições da política da organização em um nó inferior na hierarquia de recursos. Analise a lista completa de restrições da política da organização que ajudam a atender aos seus requisitos.

Ferramentas de pipeline de implantação: o blueprint usa o Cloud Build para executar o pipeline de automação.

Talvez você prefira outros produtos para seu pipeline de implantação, como Terraform Enterprise, GitLab Runners, GitHub Actions ou Jenkins. O projeto inclui direções alternativas para cada produto.

Repositório de código para implantação: o blueprint usa o Cloud Source Repositories como o repositório Git particular gerenciado.

Use seu sistema de controle de versão preferido para gerenciar repositórios de código, como GitLab, GitHub ou Bitbucket.

Se você usa um repositório particular hospedado no seu ambiente local, configure um caminho de rede particular do repositório para o ambiente do Google Cloud.

Provedor de identidade: o blueprint presume um Active Directory local e federa identidades para o Cloud Identity usando o Google Cloud Directory Sync.

Se você já usa o Google Workspace, pode usar as identidades do Google que já são gerenciadas no Google Workspace.

Se você não tiver um provedor de identidade, poderá criar e gerenciar identidades de usuário diretamente no Cloud Identity.

Se você tiver um provedor de identidade, como Okta, Ping ou Azure Entra ID, pode gerenciar contas de usuário no provedor de identidade e sincronizar com o Cloud Identity.

Se você tiver requisitos de soberania de dados ou conformidade que impeçam o uso do Cloud Identity e não exigir identidades de usuário gerenciadas do Google para outros serviços do Google, como o Google Ads ou o Google Marketing Platform: você pode preferir a federação de identidade da força de trabalho. Nesse cenário, esteja ciente das limitações dos serviços compatíveis.

Várias regiões:o blueprint implanta recursos regionais em duas regiões diferentes do Google Cloud para permitir o design da carga de trabalho com alta disponibilidade e requisitos de recuperação de desastres em mente.

Se você tiver usuários finais em mais localizações geográficas, poderá configurar mais regiões do Google Cloud para criar recursos mais próximos do usuário final com menos latência.

Se você tiver restrições de soberania de dados ou se suas necessidades de disponibilidade puderem ser atendidas em uma única região, configure apenas uma região do Google Cloud.

Alocação de endereços IP: o blueprint fornece um conjunto de intervalos de endereços IP.

Talvez seja necessário alterar os intervalos de endereços IP específicos usados com base na disponibilidade de endereços IP no ambiente híbrido atual. Se você modificar os intervalos de endereços IP, use o blueprint como orientação para o número e o tamanho dos intervalos necessários e revise os intervalos de endereços IP válidos para o Google Cloud.

Rede híbrida: o blueprint usa a Interconexão dedicada em vários locais físicos e regiões do Google Cloud para disponibilidade e largura de banda máximas.

Dependendo dos seus requisitos de custo, largura de banda e confiabilidade, é possível configurar a Interconexão por parceiro ou o Cloud VPN.

Se você precisar começar a implantar recursos com conectividade particular antes de concluir uma Interconexão dedicada, comece com o Cloud VPN e passe a usar a Interconexão dedicada mais tarde.

Se você não tiver um ambiente local atual, talvez não precise de nenhuma rede híbrida.

Perímetro do VPC Service Controls: o blueprint recomenda um único perímetro que inclui todos os projetos de serviço associados a uma rede VPC restrita. Os projetos associados a uma rede VPC de base não são incluídos dentro do perímetro.

Talvez você tenha um caso de uso que exija vários perímetros para uma organização ou decida não usar o VPC Service Controls.

Para mais informações, consulte Decidir como reduzir a exfiltração de dados usando as APIs do Google.

Gerenciador de secrets:o blueprint implanta um projeto para usar o Secret Manager na pasta common para secrets de toda a organização e um projeto em cada pasta do ambiente para secrets específicos do ambiente de dois minutos.

Se você tiver uma única equipe responsável por gerenciar e auditar secrets em toda a organização, talvez prefira usar apenas um único projeto para gerenciar o acesso aos secrets.

Se você permitir que as equipes de carga de trabalho gerenciem os próprios secrets, não use um projeto centralizado para gerenciar o acesso aos secrets. Em vez disso, permita que as equipes usem as próprias instâncias do Secret Manager em projetos de carga de trabalho.

O Cloud KMS: O blueprint implanta um projeto para usar o Cloud KMS nacommon pasta para chaves para toda a organização e um projeto para cada pasta de ambiente para chaves em cada ambiente.

Se houver uma única equipe responsável por gerenciar e auditar as chaves de criptografia em toda a organização, talvez você prefira usar apenas um único projeto para gerenciar o acesso às chaves. Uma abordagem centralizada pode ajudar a atender aos requisitos de conformidade, como custodiários de chaves PCI.

Se você permitir que as equipes de carga de trabalho gerenciem as próprias chaves, talvez não use um projeto centralizado para gerenciar o acesso a chaves. Em vez disso, permita que as equipes usem as próprias instâncias do Cloud KMS em projetos de carga de trabalho.

Coletores de registros agregados: o blueprint configura um conjunto de coletores de registros no nó da organização para que uma equipe de segurança central possa analisar os registros de auditoria de toda a organização.

Você pode ter equipes diferentes responsáveis pela auditoria de diferentes partes do negócio, e essas equipes podem exigir registros distintos para realizar os jobs. Nesse cenário, projete vários coletores agregados nas pastas e projetos adequados e crie filtros para que cada equipe receba apenas os registros necessários, ou projete visualizações de registros para acesso granular para um bucket de registros comum.

Projetos de escopo de monitoramento: o blueprint configura um único projeto de escopo de monitoramento para cada ambiente.

É possível configurar projetos de escopo mais granulares gerenciados por equipes diferentes, com escopo para o conjunto de projetos que contêm os aplicativos que cada equipe gerencia.

Granularidade de pipelines de infraestrutura: o blueprint usa um modelo em que cada unidade de negócios tem um pipeline de infraestrutura separado para gerenciar os projetos de carga de trabalho.

Talvez você prefira um único pipeline de infraestrutura gerenciado por uma equipe central, se você tiver uma equipe central responsável por implantar todos os projetos e a infraestrutura. Essa equipe central pode aceitar solicitações de envio de equipes de carga de trabalho para revisão e aprovação antes da criação do projeto, ou a equipe pode criar a solicitação de envio por conta própria em resposta a um sistema com tíquete.

É possível preferir pipelines mais granulares se as equipes de carga de trabalho individuais tiverem a capacidade de personalizar os próprios pipelines e você quiser projetar contas de serviço com privilégios mais granulares para os pipelines.

Exportações SIEM:o blueprint gerencia todas as descobertas de segurança no Security Command Center.

Decida se você vai exportar as descobertas de segurança do Security Command Center para ferramentas como o Google Security Operations ou o SIEM atual ou se as equipes vão usar o console para visualizar e gerenciar as descobertas de segurança. É possível configurar várias exportações com filtros exclusivos para diferentes equipes com diferentes escopos e responsabilidades.

Pesquisas DNS para serviços do Google Cloud no local: o blueprint configura um endpoint exclusivo do Private Service Connect para cada VPC compartilhada, o que pode ajudar a ativar designs com vários serviços de VPC Controla os perímetros.

Talvez não seja necessário solicitar o roteamento de um ambiente local para os endpoints do Private Service Connect nesse nível de granularidade se você não precisar de vários perímetros do VPC Service Controls.

Em vez de mapear hosts locais para endpoints do Private Service Connect por ambiente, você pode simplificar esse design para usar um único endpoint do Private Service Connect com o pacote de APIs apropriado ou usar o genérico: endpoints para private.googlepais.com e restricted.googleapis.com.

A seguir