Blueprint de bases empresariais

Last reviewed 2023-12-20 UTC

É possível imprimir esta página ou salvá-la no formato PDF usando a função de impressão do seu navegador e escolhendo a opção Salvar como PDF. Para acessar a versão padrão desta página, volte ao blueprint de bases empresariais.

Este conteúdo foi atualizado pela última vez em dezembro de 2023 e representa o estado do momento em que foi escrito. Os sistemas e as políticas de segurança do Google podem mudar no futuro, à medida que a proteção dos clientes é aprimorada.

Neste documento, descrevemos as práticas recomendadas que permitem implantar um conjunto fundamental de recursos no Google Cloud. Uma base da nuvem é o valor de referência de recursos, configurações e capacidades que permitem que as empresas adotem o Google Cloud para as necessidades comerciais delas. Uma base bem projetada permite governança consistente, controles de segurança, escala, visibilidade e acesso a serviços compartilhados em todas as cargas de trabalho no seu ambiente do Google Cloud. Depois de implantar os controles e a governança descritos neste documento, será possível implantar cargas de trabalho no Google Cloud.

O Blueprint de bases empresariais (anteriormente conhecido como Blueprint de fundações de segurança) é destinado a arquitetos, profissionais de segurança e equipes de engenharia de plataforma responsáveis por projetar um ambiente pronto para empresas no Google Cloud. O blueprint consiste no seguinte:

• Um repositório do GitHub terraform-example-foundation que contém os recursos implantáveis do Terraform.
• Um guia que descreve a arquitetura, o design e os controles que você implementa com o blueprint (este documento).

Você pode usar este guia de duas maneiras:

• Para criar uma base completa com base nas práticas recomendadas do Google. É possível implantar todas as recomendações deste guia como ponto de partida e personalizar o ambiente para atender aos requisitos específicos da sua empresa.
• Analisar um ambiente atual no Google Cloud. É possível comparar componentes específicos do seu design com as práticas recomendadas do Google.

Casos de uso compatíveis

O blueprint de base empresarial fornece uma camada básica de recursos e configurações que ajudam a ativar todos os tipos de cargas de trabalho no Google Cloud. Não importa se você está migrando cargas de trabalho de computação para o Google Cloud, criando aplicativos da Web conteinerizados ou cargas de trabalho de Big Data e machine learning, o blueprint de base empresarial ajuda você a criar seu ambiente para oferecer suporte a cargas de trabalho corporativas em escala. de dois minutos.

Depois de implantar o blueprint da base da empresa, é possível implantar cargas de trabalho diretamente ou implantar outros blueprints para oferecer suporte a cargas de trabalho complexas que exigem mais recursos.

Um modelo de segurança em profundidade

Os serviços do Google Cloud se beneficiam do design de segurança de infraestrutura do Google subjacente. É sua responsabilidade projetar a segurança nos sistemas criados com base no Google Cloud. O blueprint de base empresarial ajuda você a implementar um modelo de segurança de defesa profunda para seus serviços e cargas de trabalho do Google Cloud.

O diagrama a seguir mostra um modelo de segurança em profundidade para sua organização do Google Cloud, que combina controles de arquitetura, de políticas e de detetive.

O diagrama descreve os seguintes controles:

• Os controles de política são restrições programáticas que aplicam configurações de recursos aceitáveis e evitam configurações arriscadas. O blueprint usa uma combinação de controles de política, incluindo validação de infraestrutura como código (IaC, na sigla em inglês) no pipeline e restrições da política da organização.
• Os controles de arquitetura são a configuração de recursos do Google Cloud, como redes e hierarquia de recursos. A arquitetura de blueprints é baseada nas práticas recomendadas de segurança.
• Os controles de detecção permitem identificar comportamentos anômalos ou maliciosos na organização. O blueprint usa recursos da plataforma, como o Security Command Center, integra-se aos controles e fluxos de trabalho de detetive existentes, como uma central de operações de segurança (SOC, na sigla em inglês), e fornece recursos para aplicar controles de detetive personalizados.

Principais decisões:

Nesta seção, resumimos as decisões arquitetônicas de alto nível do blueprint.

O diagrama descreve como os serviços do Google Cloud contribuem para as principais decisões de arquitetura:

• Cloud Build:os recursos de infraestrutura são gerenciados usando um modelo GitOps. A IaC declarativa é escrita no Terraform e gerenciada em um sistema de controle de versões para revisão e aprovação, e os recursos são implantados usando o Cloud Build como a ferramenta de automação de integração e implantação contínuas (CI/CD). O pipeline também aplica verificações de política como código para validar se os recursos atendem às configurações esperadas antes da implantação.
• Cloud Identity: os usuários e a associação a grupos são sincronizados a partir do provedor de identidade atual. Os controles para o gerenciamento do ciclo de vida da conta de usuário e o Logon único (SSO) dependem dos controles e processos atuais do seu provedor de identidade.
• Identity and Access Management (IAM): as políticas de permissão (anteriormente conhecidas como políticas do IAM) dão acesso a recursos e são aplicadas a grupos com base na função do job. Os usuários são adicionados aos grupos apropriados para receber acesso de leitura aos recursos básicos. Todas as alterações nos recursos de fundação são implantadas por meio do pipeline de CI/CD, que usa identidades de conta de serviço com privilégios.
• Resource Manager: todos os recursos são gerenciados em uma única organização, com uma hierarquia de recursos de pastas que organiza os projetos por ambientes. Os projetos são rotulados com metadados para governança, incluindo atribuição de custos.
• Rede: as topologias de rede usam a VPC compartilhada para fornecer recursos de rede para cargas de trabalho em várias regiões e zonas, separadas por ambiente e gerenciadas centralmente. Todos os caminhos de rede entre hosts locais, recursos do Google Cloud nas redes VPC e serviços do Google Cloud são particulares. Por padrão, nenhum tráfego de saída ou de entrada da Internet pública é permitido.
• Cloud Logging: os coletores de registros agregados são configurados para coletar registros relevantes para segurança e auditoria em um projeto centralizado para retenção de longo prazo, análise e exportação para sistemas externos.
• Cloud Monitoring: projetos de escopo de monitoramento são configurados para visualizar métricas de desempenho de aplicativos em vários projetos em um só lugar.
• Serviço de política da organização: as restrições da política da organização são configuradas para impedir várias configurações de alto risco.
• Gerenciador de secrets:projetos centralizados são criados para uma equipe responsável por gerenciar e auditar o uso de secrets de aplicativos confidenciais para ajudar a atender aos requisitos de conformidade.
• Cloud Key Management Service (Cloud KMS): projetos centralizados são criados para uma equipe responsável por gerenciar e auditar as chaves de criptografia para ajudar a atender aos requisitos de conformidade.
• Security Command Center:os recursos de detecção e monitoramento de ameaças são fornecidos usando uma combinação de controles de segurança integrados do Security Command Center e soluções personalizadas que permitem detectar e responder a ocorrências de segurança.

Confira alternativas para encontrar alternativas a essas decisões importantes.

A seguir

• Leia sobre autenticação e autorização (próximo documento desta série).

Autenticação e autorização

Nesta seção, mostramos como usar o Cloud Identity para gerenciar as identidades que seus funcionários usam para acessar os serviços do Google Cloud.

Provedor de identidade externo como fonte de verdade

Recomendamos federar sua conta do Cloud Identity com o provedor de identidade atual. A federação ajuda você a garantir que seus processos de gerenciamento de conta atuais se apliquem ao Google Cloud e a outros serviços do Google.

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

Observação: Se você já estiver usando o Google Workspace, o Cloud Identity usará o mesmo console, controles administrativos e contas de usuário que sua conta do Google Workspace.

O diagrama a seguir mostra uma visualização de alto nível da federação de identidade e do Logon único (SSO). Ele usa o Microsoft Active Directory, localizado no ambiente local, como o provedor de identidade de exemplo.

Este diagrama descreve as seguintes práticas recomendadas:

• As identidades do usuário são gerenciadas em um domínio do Active Directory localizado no ambiente local e federado ao Cloud Identity. O Active Directory usa o Google Cloud Directory Sync para provisionar identidades para o Cloud Identity.
• Os usuários que tentam fazer login nos serviços do Google são redirecionados para o provedor de identidade externo para Logon único com SAML, usando as credenciais atuais para autenticar. Nenhuma senha é sincronizada com o Cloud Identity.

A tabela a seguir contém links para as orientações de configuração para provedores de identidade.

Provedor de identidade	Orientação
Active Directory	Provisionamento de contas de usuário do Active Directory Logon único do Active Directory
ID do Microsoft Entra (antigo Azure AD)	Como federar o Google Cloud com o Microsoft Entra ID
Outros provedores de identidade externos (por exemplo, Ping ou Okta)	Como integrar soluções de identidade de ping com os serviços de identidade do Google Como usar o Okta com provedores do Google Cloud Práticas recomendadas para federar o Google Cloud com um provedor de identidade externo

É altamente recomendável que você aplique a autenticação multifator no seu provedor de identidade com um mecanismo resistente a phishing, como uma chave de segurança Titan.

As configurações recomendadas para o Cloud Identity não são automatizadas por meio do código do Terraform neste blueprint. Consulte Controles administrativos do Cloud Identity para ver as configurações de segurança recomendadas que você precisa definir além de implantar o código do Terraform.

Grupos para controle de acesso

Um principal é uma identidade que pode receber acesso a um recurso. Os principais incluem Contas do Google para usuários, grupos do Google, contas do Google Workspace, domínios do Cloud Identity e contas de serviço. Alguns serviços também permitem conceder acesso a todos os usuários que se autenticarem com uma Conta do Google ou a todos os usuários na Internet. Para que um principal interaja com os serviços do Google Cloud, conceda papéis no Identity and Access Management (IAM).

Para gerenciar os papéis do IAM em escala, recomendamos que você atribua usuários a grupos com base nas funções do job e nos requisitos de acesso. Em seguida, conceda os papéis do IAM a esses grupos. Adicione usuários a grupos usando os processos no seu provedor de identidade atual para criação e associação de grupos.

Não recomendamos conceder papéis do IAM a usuários individuais, porque as atribuições individuais podem aumentar a complexidade do gerenciamento e da auditoria de papéis.

O blueprint configura grupos e papéis para acesso somente leitura aos recursos fundamentais. Recomendamos que você implante todos os recursos no blueprint por meio do pipeline de base e não conceda papéis a usuários a grupos para modificar recursos de fundação fora do pipeline.

A tabela a seguir mostra os grupos configurados pelo blueprint para visualizar os recursos básicos.

Nome	Descrição	Papéis	Escopo
[e-mail]	Administradores altamente privilegiados que podem conceder papéis do IAM no nível da organização. Eles podem acessar qualquer outro papel. Esse privilégio não é recomendado para uso diário.	Administrador da organização	organização
[e-mail]	Administradores altamente privilegiados que podem modificar a conta do Cloud Billing. Esse privilégio não é recomendado para uso diário.	Administrador de contas de faturamento	organização
[e-mail]	A equipe responsável por visualizar e analisar os gastos em todos os projetos.	Leitor da conta de faturamento	organização
		Usuário do BigQuery	Projeto de faturamento
[e-mail]	A equipe responsável por auditar os registros relacionados à segurança.	Visualizador de registros Usuário do BigQuery	projeto do logging
[e-mail]	A equipe responsável por monitorar as métricas de desempenho do aplicativo.	Visualizador de monitoramento	projeto de monitoramento
[e-mail]	A equipe responsável por analisar a segurança da nuvem.	Revisor de segurança	organização
[e-mail]	A equipe responsável por visualizar e manter as configurações de rede.	Leitor da rede do Compute	organização
[e-mail]	A equipe responsável pela configuração do Security Command Center.	Editor administrador da Central de segurança	organização
[e-mail]	a equipe responsável por gerenciar, armazenar e auditar credenciais e outros secrets usados por aplicativos.	Administrador do Gerenciador de secrets	projetos de secrets
[e-mail]	A equipe responsável por aplicar o gerenciamento de chaves de criptografia para atender aos requisitos de conformidade.	Leitor do Cloud KMS	projetos de kms

À medida que desenvolve suas próprias cargas de trabalho sobre a base, você cria outros grupos e concede papéis do IAM com base nos requisitos de acesso de cada carga de trabalho.

É altamente recomendável evitar papéis básicos (como Proprietário, Editor ou Leitor) e usar papéis predefinidos. Os papéis básicos são permissivos demais e representam um possível risco à segurança. Os papéis de Proprietário e Editor podem levar ao escalonamento de privilégios e à movimentação lateral, e o papel de Leitor inclui acesso para ler todos os dados. Para práticas recomendadas sobre papéis do IAM, consulte Usar o IAM com segurança.

Contas de superadministrador

Os usuários do Cloud Identity com a conta de superadministrador ignoram as configurações de SSO da organização e são autenticados diretamente no Cloud Identity. Essa exceção ocorre desde a concepção, para que o superadministrador ainda possa acessar o console do Cloud Identity em caso de falha ou configuração incorreta do SSO. No entanto, isso significa que você precisa considerar mais proteção para contas de superadministrador.

Para proteger suas contas de superadministrador, recomendamos que você sempre aplique a verificação em duas etapas com chaves de segurança no Cloud Identity. Veja mais detalhes em Práticas recomendadas de segurança para contas de administrador.

Problemas com contas de usuário pessoais

Se você nunca usou o Cloud Identity ou o Google Workspace antes de se integrar ao Google Cloud, é possível que os funcionários da sua organização já estejam usando contas pessoais que sejam associados a identidades de e-mail corporativo para acessar outros serviços do Google, como Google Marketing Platform ou YouTube. As contas pessoais são contas totalmente controladas e gerenciadas pelas pessoas que as criaram. Como essas contas não estão sob o controle da sua organização e podem incluir dados pessoais e corporativos, você precisa decidir como consolidar essas contas com outras contas corporativas.

Recomendamos que você consolide as contas de usuário pessoais como parte da integração ao Google Cloud. Se você ainda não estiver usando o Google Workspace para todas as suas contas de usuário, recomendamos bloquear a criação de novas contas pessoais.

Controles administrativos do Cloud Identity

O Cloud Identity tem vários controles administrativos que não são automatizados pelo código do Terraform no blueprint. Recomendamos que você aplique cada um desses controles de segurança de práticas recomendadas no início do processo de criação da base.

Controle	Descrição
Implantar a verificação em duas etapas	As contas de usuário podem ser comprometidas por phishing, engenharia social, senha ou várias outras ameaças. A verificação em duas etapas ajuda a reduzir essas ameaças. Recomendamos que você aplique a verificação em duas etapas a todas as contas de usuário da sua organização com um mecanismo resistente a phishing, como as chaves de segurança Titan ou outras chaves baseadas em os padrões FIDO U2F (CTAP1) resistente a phishing.
Definir a duração da sessão para os serviços do Google Cloud	Tokens OAuth persistentes em estações de trabalho do desenvolvedor podem ser um risco de segurança se expostos. Recomendamos definir uma política de reautenticação que exija autenticação a cada 16 horas usando uma chave de segurança.
Definir a duração da sessão para Serviços do Google	(Apenas para clientes do Google Workspace) Sessões da Web persistentes em outros serviços do Google podem ser um risco de segurança se expostas. Recomendamos que você aplique uma duração máxima da sessão da Web e alinhe isso aos controles de duração da sessão no seu provedor de SSO.
Compartilhar dados do Cloud Identity com os serviços do Google Cloud	Os registros de auditoria de atividade do administrador do Google Workspace ou do Cloud Identity geralmente são gerenciados e visualizados no Admin Console, separadamente dos registros no ambiente do Google Cloud. Esses registros contêm informações relevantes para seu ambiente do Google Cloud, como eventos de login do usuário. Recomendamos que você compartilhe os registros de auditoria do Cloud Identity com o ambiente do Google Cloud para gerenciar de maneira centralizada registros de todas as origens.
Configurar a "Verificação pós-SSO"	O blueprint presume que você configure o SSO com seu provedor de identidade externo. Recomendamos que você ative uma camada adicional de controle com base na análise de risco de login do Google. Depois que você aplicar essa configuração, os usuários poderão ver outros desafios de login com base em riscos no login se o Google considerar que um login de usuário é suspeito.
Corrigir problemas com contas de usuário pessoais	usuários com um endereço de e-mail válido no seu domínio, mas nenhuma Conta do Google, podem se inscrever em contas pessoais não gerenciadas. Essas contas podem conter dados corporativos, mas não são controladas pelos processos de gerenciamento do ciclo de vida. Recomendamos que você tome medidas para garantir que todas as contas de usuário sejam gerenciadas.
Desativar a recuperação de contas de superadministrador	A recuperação automática da conta de superadministrador fica desativada por padrão para todos os novos clientes (é possível que os clientes atuais tenham essa configuração ativada). Desativar essa configuração ajuda a reduzir o risco de que um telefone comprometido, um e-mail comprometido ou um ataque de engenharia social possa permitir que um invasor receba privilégios de superadministrador sobre seu ambiente. Planeje um processo interno para que um superadministrador entre em contato com outro superadministrador da organização se perder o acesso à conta e garanta que todos os superadministradores conheçam o processo de recuperação assistida por suporte.
Aplicar e monitorar requisitos de senha para os usuários	Na maioria dos casos, as senhas de usuário são gerenciadas por meio do provedor de identidade externo, mas as contas de superadministrador ignoram o SSO e precisam usar uma senha para fazer login no Cloud Identity. Desative a reutilização e monitore a força da senha de todos os usuários que usam uma senha para fazer login no Cloud Identity, especialmente as contas de superadministrador.
Definir políticas de uso de grupos para toda a organização	Por padrão, as contas de usuário externas podem ser adicionadas a grupos no Cloud Identity. Recomendamos que você defina configurações de compartilhamento para que os proprietários dos grupos não possam adicionar membros externos. Essa restrição não se aplica à conta de superadministrador ou a outros administradores delegados com permissões de administrador do Grupos. Como a federação do seu provedor de identidade é executada com privilégios de administrador, as configurações de compartilhamento de grupo não se aplicam a essa sincronização de grupo. Recomendamos que você revise os controles no provedor de identidade e no mecanismo de sincronização para garantir que participantes que não sejam do domínio não sejam adicionados a grupos ou que você aplique restrições de grupo.

A seguir

• Leia sobre a estrutura organizacional (próximo documento desta série).

Estrutura da organização

O nó raiz para gerenciar recursos no Google Cloud é a organização. A organização do Google Cloud fornece uma hierarquia de recursos que fornece uma estrutura de propriedade para recursos e pontos de anexo para políticas da organização e controles de acesso de dois minutos. A hierarquia de recursos consiste em pastas, projetos e recursos, além de definir a forma e o uso dos serviços do Google Cloud em uma organização.

Os recursos que estão mais abaixo na hierarquia herdam as políticas, como as de permissão do IAM e da organização. Todas as permissões de acesso são negadas porpadrão até que você aplique políticas de permissão diretamente a um recurso ou ele herde as políticas de um nível superior na hierarquia de recursos.

O diagrama a seguir mostra as pastas e os projetos implantados pelo blueprint.

As seções a seguir descrevem as pastas e os projetos no diagrama.

Pastas

O blueprint usa pastas para agrupar projetos com base no ambiente. Esse agrupamento lógico é usado para aplicar configurações como políticas de permissão e políticas da organização no nível da pasta e, em seguida, todos os recursos dentro dela herdam as políticas. A tabela a seguir descreve as pastas que fazem parte do blueprint.

Pasta	Descrição
bootstrap	Contém os projetos usados para implantar componentes básicos.
common	Contém projetos com recursos compartilhados por todos os ambientes.
production	Contém projetos com recursos de produção.
nonproduction	Contém uma cópia do ambiente de produção para permitir que você teste cargas de trabalho antes de promovê-las para produção.
development	Contém os recursos da nuvem usados para desenvolvimento.
networking	Contém os recursos de rede compartilhados por todos os ambientes.

Projetos

O blueprint usa projetos para agrupar recursos individuais com base na funcionalidade e nos limites pretendidos de controle de acesso. Na tabela a seguir, descrevemos os projetos incluídos no blueprint.

Pasta	Projeto	Descrição
bootstrap	prj-b-cicd	Armazena o pipeline de implantação usado para criar os componentes básicos da organização. Para mais informações, consulte a metodologia de implantação.
	prj-b-seed	Contém o estado do Terraform da sua infraestrutura e a conta de serviço do Terraform necessária para executar o pipeline. Para mais informações, consulte a metodologia de implantação.
common	prj-c-secrets	Contém secrets no nível da organização. Para mais informações, consulte Armazenar credenciais de aplicativos com o Secret Manager.
	prj-c-logging	Contém as origens de registros agregadas para registros de auditoria. Para mais informações, consulte geração de registros centralizada para segurança e auditoria.
	prj-c-scc	Contém recursos para ajudar a configurar alertas do Security Command Center e outros monitoramentos de segurança personalizados. Para mais informações, consulte Monitoramento de ameaças com o Security Command Center.
	prj-c-billing-logs	Contém um conjunto de dados do BigQuery com as exportações de faturamento da organização. Para mais informações, consulte alocar custos entre centros de custo internos.
	prj-c-infra-pipeline	Contém um pipeline de infraestrutura para implantar recursos como VMs e bancos de dados a serem usados por cargas de trabalho. Para mais informações, consulte camadas de pipeline.
	prj-c-kms	Contém chaves de criptografia no nível da organização. Para mais informações, consulte Gerenciar chaves de criptografia.
networking	prj-net-{env}-shared-base	Contém o projeto host de uma rede VPC compartilhada para cargas de trabalho que não exigem VPC Service Controls. Para mais informações, consulte a topologia de rede.
	prj-net-{env}-shared-restricted	Contém o projeto host de uma rede VPC compartilhada para cargas de trabalho que exigem o VPC Service Controls. Para saber mais consulte topologia de rede.
	prj-net-interconnect	Contém as conexões do Cloud Interconnect que fornecem conectividade entre o ambiente local e o Google Cloud. Para mais informações, consulte conectividade híbrida.
	prj-net-dns-hub	Contém recursos para um ponto central de comunicação entre o sistema DNS local e o Cloud DNS. Para mais informações, consulte configuração de DNS centralizada.
pastas do ambiente (production, non-production e development)	prj-{env}-monitoring	Contém um projeto de escopo para agregar métricas de projetos nesse ambiente. Para mais informações, consulte Como alertar sobre métricas com base em registros e métricas de desempenho
	prj-{env}-secrets	Contém secrets no nível da pasta. Para mais informações, acesse Armazenar e auditar credenciais de aplicativos com o Secret Manager.
	prj-{env}-kms	Contém chaves de criptografia no nível da pasta. Para mais informações, consulte Gerenciar chaves de criptografia.
	projetos de aplicativos	Contém vários projetos em que você cria recursos para aplicativos. Para mais informações, consulte padrões de implantação de projetos e camadas de pipeline.

Governança para propriedade de recursos

Recomendamos que você aplique rótulos de maneira consistente aos projetos para ajudar na governança e na alocação de custos. A tabela a seguir descreve os rótulos que são adicionados a cada projeto para governança no blueprint.

Rótulo	Descrição
application	O nome legível do aplicativo ou da carga de trabalho associado ao projeto.
businesscode	Um código curto que descreve qual unidadede negócios é proprietária do projeto. O código shared é usado para projetos que não estão explicitamente vinculados a uma unidade de negócios.
billingcode	É um código usado para fornecer informações de estorno.
primarycontact	O nome de usuário do contato principal responsável pelo projeto. Como os rótulos do projeto não podem incluir caracteres especiais, como o "e" comercial (@), ele é definido como o nome de usuário sem o sufixo @example.com.
secondarycontact	O nome de usuário do contato secundário responsável pelo projeto. Como os rótulos do projeto não podem incluir caracteres especiais como @, defina apenas o nome de usuário sem o sufixo @example.com.
environment	Um valor que identifica o tipo de ambiente, como bootstrap, common, production, non-production,development, ou network.
envcode	Um valor que identifica o tipo de ambiente, abreviado para b, c, p, n, d ou net.
vpc	O ID da rede VPC que este projeto vai usar.

Ocasionalmente, o Google pode enviar notificações importantes, como suspensões de conta ou atualizações nos termos dos produtos. O blueprint usa contatos essenciais para enviar essas notificações aos grupos configurados durante a implantação. Os Contatos essenciais são configurados no nó da organização e herdados por todos os projetos na organização. Recomendamos que você analise esses grupos e verifique se os e-mails são monitorados de maneira confiável.

Os contatos essenciais são usados para uma finalidade diferente dos campos primarycontact e secondarycontact, que estão configurados nos rótulos do projeto. Os contatos nos rótulos do projeto são destinados à governança interna. Por exemplo, se você identificar recursos que não estão em conformidade em um projeto de carga de trabalho e precisar entrar em contato com os proprietários, use o campo primarycontact para encontrar a pessoa ou a equipe responsável por essa carga de trabalho.

A seguir

• Leia sobre networking (próximo documento desta série).

Rede

A rede é necessária para que os recursos se comuniquem na sua organização do Google Cloud e entre o ambiente de nuvem e o ambiente local. Nesta seção, descrevemos a estrutura no blueprint para redes VPC, espaço de endereço IP, DNS, políticas de firewall e conectividade com o ambiente local.

Topologia de rede

O repositório de blueprints oferece as seguintes opções para a topologia de rede:

• Use redes VPC compartilhadas separadas para cada ambiente, sem tráfego de rede diretamente permitido entre os ambientes.
• Use um modelo hub-and-spoke que adicione uma rede hub para conectar cada ambiente no Google Cloud, com o tráfego de rede entre ambientes controlados por um dispositivo virtual de rede (NVA, na sigla em inglês).

Escolha a topologia de rede VPC compartilhada quando não quiser conectividade de rede direta entre os ambientes. Escolha a topologia de rede hub e spoke quando quiser permitir a conectividade de rede entre ambientes filtrados por um NVA, como quando você depende de ferramentas atuais que exigem uma rede direta para cada servidor no seu ambiente.

As duas topologias usam a VPC compartilhada como uma construção de rede principal porque ela permite uma separação clara de responsabilidades. Os administradores de rede gerenciam recursos de rede em um projeto host centralizado, e as equipes de carga de trabalho implantam os próprios recursos de aplicativos e consomem os recursos de rede em projetos de serviço anexados ao projeto host.

As duas topologias incluem uma versão básica e restrita de cada rede VPC. A rede VPC base é usada para recursos que contêm dados não confidenciais, e a rede VPC restrita é usada para recursos com dados confidenciais que exigem VPC Service Controls. Para mais informações sobre como implementar o VPC Service Controls, consulte Proteger recursos com o VPC Service Controls.

Topologia de rede VPC compartilhada dupla

Se você precisar de isolamento de rede entre suas redes de desenvolvimento, de não produção e de produção no Google Cloud, recomendamos a topologia de rede VPC compartilhada dupla. Essa topologia usa redes VPC compartilhadas separadas para cada ambiente, com cada ambiente também dividido entre uma rede VPC compartilhada de base e uma rede VPC compartilhada restrita.

O diagrama a seguir mostra a topologia de rede VPC compartilhada dupla.

O diagrama descreve esses conceitos principais da topologia dupla de VPC compartilhada:

• Cada ambiente (produção, não produção e desenvolvimento) tem uma rede VPC compartilhada para a rede de base e uma rede VPC compartilhada para a rede restrita. Este diagrama mostra apenas o ambiente de produção, mas o mesmo padrão é repetido para cada ambiente.
• Cada rede VPC compartilhada tem duas sub-redes, e cada sub-rede está em uma região diferente.
• A conectividade com recursos locais é ativada por quatro anexos da VLAN para a instância da Interconexão dedicada em cada rede VPC compartilhada usando quatro serviços do Cloud Router (dois em cada região para redundância). Para mais informações, consulte Conectividade híbrida entre o ambiente local e o Google Cloud.

Por projeto, essa topologia não permite que o tráfego de rede flua diretamente entre ambientes. Se você precisar que o tráfego de rede flua diretamente entre ambientes, será necessário realizar outras etapas para permitir esse caminho de rede. Por exemplo, é possível configurar endpoints do Private Service Connect para expor um serviço de uma rede VPC para outra. Como alternativa, é possível configurar sua rede local para deixar o tráfego fluir de um ambiente do Google Cloud para o ambiente local e, em seguida, para outro ambiente do Google Cloud.

Topologia de rede hub e spoke

Se você implantar recursos no Google Cloud que exigem um caminho de rede direto para recursos em vários ambientes, recomendamos a topologia de rede hub and spoke.

A topologia hub e spoke usa vários dos conceitos que fazem parte da topologia de VPC compartilhada dupla, mas modifica a topologia para adicionar uma rede hub. O diagrama a seguir mostra a topologia hub e spoke.

O diagrama descreve estes conceitos-chave da topologia de rede hub e spoke:

• Esse modelo adiciona uma rede hub e cada uma das redes de desenvolvimento, de não produção e de produção (spoke) é conectada à rede do hub por peering de rede VPC. Como alternativa, se você antecipar que o limite da cota seja excedido, use um gateway de VPN de alta disponibilidade.
• A conectividade com redes locais é permitida apenas pela rede do hub. Todas as redes spoke podem se comunicar com recursos compartilhados na rede do hub e usar esse caminho para se conectar a redes locais.
• As redes de hub incluem um NVA para cada região, implantado de forma redundante atrás de instâncias do balanceador de carga de rede interno. Esse NVA funciona como o gateway para permitir ou negar a comunicação entre redes spoke.
• A rede do hub também hospeda ferramentas que exigem conectividade com todas as outras redes. Por exemplo, é possível implantar ferramentas em instâncias de VM para gerenciar configurações no ambiente comum.
• O modelo hub e spoke é duplicado para uma versão base e uma versão restrita de cada rede.

Para ativar o tráfego spoke para spoke, o blueprint implanta NVAs na rede VPC compartilhada hub que atuam como gateways entre redes. Essas rotas são trocadas do hub para as redes VPC spoke por meio da troca de rotas personalizadas. Nesse cenário, a conectividade entre spokes precisa ser roteada por meio do NVA porque o peering de rede VPC não é transitivo e, portanto, as redes VPC spoke não podem trocar dados entre si diretamente. É preciso configurar os dispositivos virtuais para permitir seletivamente o tráfego entre spokes.

Para mais informações sobre como usar NVAs para controlar o tráfego entre spokes, consulte dispositivos de rede centralizados no Google Cloud.

Padrões de implantação do projeto

Ao criar novos projetos para cargas de trabalho, é preciso decidir como os recursos desse projeto se conectam à rede atual. A tabela a seguir descreve os padrões de implantação de projetos que são usados no blueprint.

Padrão	Descrição	Exemplo de uso
Projetos base compartilhados	Esses projetos são configurados como projetos de serviço para um projeto host de VPC compartilhada de base. Use esse padrão quando os recursos do projeto tiverem os seguintes critérios: Exija conectividade de rede ao ambiente local ou aos recursos na mesma topologia de VPC compartilhada. Exigem um caminho de rede para os Serviços do Google contidos no endereço IP virtual particular. Não exija o VPC Service Controls.	example_base_shared_vpc_project.tf
Projetos restritos compartilhados	Esses projetos são configurados como projetos de serviço para um projeto host de VPC compartilhada restrito. Use esse padrão quando os recursos do projeto tiverem os seguintes critérios: Exija conectividade de rede ao ambiente local ou aos recursos na mesma topologia de VPC compartilhada. Exija um caminho de rede para os Serviços do Google contidos no endereço IP virtual restrito. Exija o VPC Service Controls.	example_restricted_shared_vpc_project.tf
Projetos flutuantes	Projetos flutuantes não estão conectados a outras redes VPC em sua topologia. Use esse padrão quando os recursos do projeto tiverem os seguintes critérios: Não exija conectividade de malha completa com um ambiente local ou recursos na topologia da VPC compartilhada. Não exija uma rede VPC ou você quer gerenciar a rede VPC para este projeto independentemente da topologia de rede VPC principal (como quando você quer usar um intervalo de endereços IP que entre em conflito com os intervalos) 101}já está em uso). Talvez você queira manter a rede VPC de um projeto flutuante separada da topologia da rede VPC principal, mas também queira expor um número limitado de endpoints entre as redes. Nesse caso, publique serviços usando o Private Service Connect para compartilhar o acesso a um endpoint individual em redes VPC sem expor toda a rede.	example_floating_project.tf
Projetos de peering	Projetos de peering criam as próprias redes VPC e fazem peering com outras redes VPC na sua topologia. Use esse padrão quando os recursos do projeto tiverem os seguintes critérios: Requer conectividade de rede na rede VPC com peering direto, mas não exige conectividade transitiva com um ambiente local ou outras redes VPC. precisam gerenciar a rede VPC deste projeto independentemente da topologia de rede principal. Se você criar projetos de peering, é sua responsabilidade alocar intervalos de endereços IP não conflitantes e planejar a cota do grupo de peering.	example_peering_project.tf

Alocação de endereço IP

Nesta seção, você verá como a arquitetura de blueprint aloca intervalos de endereços IP. Talvez seja necessário alterar os intervalos de endereços IP específicos usados com base na disponibilidade do endereço IP no ambiente híbrido atual.

A tabela a seguir fornece um detalhamento do espaço de endereços IP alocado para o blueprint. O ambiente hub só se aplica à topologia hub e spoke.

Finalidade	Tipo de VPC	Região	Ambiente hub	Ambiente de desenvolvimento	Ambiente que não seja de produção	Ambiente de produção
Intervalos de sub-rede principal	Base	Região 1	10.0.0.0/18	10.0.64.0/18	10.0.128.0/18	10.0.192.0/18
		Região 2	10.1.0.0/18	10.1.64.0/18	10.1.128.0/18	10.1.192.0/18
		Não alocado	10.{2-7}.0.0/18	10.{2-7}.64.0/18	10.{2-7}.128.0/18	10.{2-7}.192.0/18
	Restrito	Região 1	10.8.0.0/18	10.8.64.0/18	10.8.128.0/18	10.8.192.0/18
		Região 2	10.9.0.0/18	10.9.64.0/18	10.9.128.0/18	10.9.192.0/18
		Não alocado	10.{10-15}.0.0/18	10.{10-15}.64.0/18	10.{10-15}.128.0/18	10.{10-15}.192.0/18
Acesso a serviços particulares	Base	Global	10.16.0.0/21	10.16.8.0/21	10.16.16.0/21	10.16.24.0/21
	Restrito	Global	10.16.32.0/21	10.16.40.0/21	10.16.48.0/21	10.16.56.0/21
Endpoints do Private Service Connect	Base	Global	10.17.0.1/32	10.17.0.2/32	10.17.0.3/32	10.17.0.4/32
	Restrito	Global	10.17.0.5/32	10.17.0.6/32	10.17.0.7/32	10.17.0.8/32
Sub-redes somente proxy	Base	Região 1	10.18.0.0/23	10.18.2.0/23	10.18.4.0/23	10.18.6.0/23
		Região 2	10.19.0.0/23	10.19.2.0/23	10.19.4.0/23	10.19.6.0/23
		Não alocado	10.{20-25}.0.0/23	10.{20-25}.2.0/23	10.{20-25}.4.0/23	10.{20-25}.6.0/23
	Restrito	Região 1	10.26.0.0/23	10.26.2.0/23	10.26.4.0/23	10.26.6.0/23
		Região 2	10.27.0.0/23	10.27.2.0/23	10.27.4.0/23	10.27.6.0/23
		Não alocado	10.{28-33}.0.0/23	10.{28-33}.2.0/23	10.{28-33}.4.0/23	10.{28-33}.6.0/23
Intervalos de sub-rede secundários	Base	Região 1	100.64.0.0/18	100.64.64.0/18	100.64.128.0/18	100.64.192.0/18
		Região 2	100.65.0.0/18	100.65.64.0/18	100.65.128.0/18	100.65.192.0/18
		Não alocado	100.{66-71}.0.0/18	100.{66-71}.64.0/18	100.{66-71}.128.0/18	100.{66-71}.192.0/18
	Restrito	Região 1	100.72.0.0/18	100.72.64.0/18	100.72.128.0/18	100.72.192.0/18
		Região 2	100.73.0.0/18	100.73.64.0/18	100.73.128.0/18	100.73.192.0/18
		Não alocado	100.{74-79}.0.0/18	100.{74-79}.64.0/18	100.{74-79}.128.0/18	100.{74-79}.192.0/18

A tabela anterior demonstra esses conceitos para alocar intervalos de endereços IP:

• A alocação de endereços IP é subdividida em intervalos para cada combinação de VPC compartilhada de base, VPC compartilhada restrita, região e ambiente.
• Alguns recursos são globais e não exigem subdivisões para cada região.
• Por padrão, para recursos regionais, o blueprint é implantado em duas regiões. Além disso, há intervalos de endereços IP não utilizados. Assim, você pode expandir para mais seis regiões.
• A rede hub é usada apenas na topologia de rede hub e spoke, enquanto os ambientes de desenvolvimento, não produção e produção são usados nas duas topologias de rede.

A tabela a seguir mostra como cada tipo de intervalo de endereços IP é usado.

Finalidade	Descrição
Intervalos de sub-rede principal	Os recursos implantados na rede VPC, como instâncias de máquina virtual, usam endereços IP internos desses intervalos.
Acesso a serviços particulares	Alguns serviços do Google Cloud, como o Cloud SQL, exigem que você pré-aloque um intervalo de sub-rede para o acesso a serviços particulares. O blueprint reserva um intervalo /21 globalmente para cada uma das redes VPC compartilhadas com o objetivo de alocar endereços IP para serviços que exigem acesso a serviços particulares. Ao criar um serviço que depende do acesso a serviços particulares, você aloca uma sub-rede /24 regional do intervalo /21 reservado.
Private Service Connect	O blueprint provisiona cada rede VPC com um endpoint do Private Service Connect para se comunicar com as APIs do Google Cloud. Esse endpoint permite que os recursos na rede VPC alcancem as APIs do Google Cloud sem depender de tráfego de saída para a Internet ou de intervalos de Internet anunciados publicamente.
Balanceadores de carga baseados em proxy	Alguns tipos de balanceadores de carga de aplicativo exigem que você pré-aloque sub-redes somente proxy. Embora o blueprint não implante balanceadores de carga de aplicativo que exigem esse intervalo, alocar intervalos com antecedência ajuda a reduzir o atrito das cargas de trabalho quando elas precisam solicitar um novo intervalo de sub-rede para ativar determinado balanceador de carga do Google Cloud.
Intervalos de sub-rede secundários	Alguns casos de uso, como cargas de trabalho baseadas em contêiner, exigem intervalos secundários. O blueprint aloca intervalos do espaço de endereços IP RFC 6598 para intervalos secundários.

Configuração de DNS centralizada

Para resolução de DNS entre o Google Cloud e ambientes locais, recomendamos que você use uma abordagem híbrida com dois sistemas DNS autoritativos. Nessa abordagem, o Cloud DNS lida com a resolução de DNS autoritativa para o ambiente do Google Cloud, e os servidores DNS locais atuais processam a resolução de DNS autoritativo para recursos locais. O ambiente local e o do Google Cloud realizam buscas DNS entre ambientes por meio de solicitações de encaminhamento.

No diagrama a seguir, demonstramos a topologia de DNS nas várias redes VPC usadas no blueprint.

O diagrama descreve os seguintes componentes do design de DNS implantado pelo blueprint:

• O projeto do hub de DNS na pasta comum é o ponto central da troca de DNS entre o ambiente local e o do Google Cloud. O encaminhamento de DNS usa as mesmas instâncias de Interconexão dedicada e Cloud Routers que já estão configurados na topologia de rede.
  • Na topologia de VPC compartilhada dupla, o hub DNS usa a rede VPC compartilhada de produção base.
  • Na topologia hub-and-spoke, o hub DNS usa a rede VPC compartilhada do hub de base.
• Os servidores em cada rede VPC compartilhada podem resolver registros DNS de outras redes VPC compartilhadas por meio do encaminhamento de DNS, que é configurado entre o Cloud DNS em cada projeto host da VPC compartilhada. e o hub DNS.
• Os servidores locais podem resolver registros DNS em ambientes do Google Cloud usando políticas de servidor DNS que permitem consultas de servidores locais. O blueprint configura uma política de servidor de entrada no hub DNS para alocar endereços IP, e os servidores DNS locais encaminham as solicitações para esses endereços. Todas as solicitações de DNS para o Google Cloud chegam ao hub de DNS primeiro, que resolve os registros dos pares de DNS.
• Os servidores no Google Cloud podem resolver registros DNS no ambiente local usando zonas de encaminhamento que consultam servidores locais. Todas as solicitações de DNS para o ambiente local são originadas do hub de DNS. A origem da solicitação DNS é 35.199.192.0/19.

Políticas de firewall

O Google Cloud tem vários tipos de políticas de firewall. As políticas hierárquicas de firewall são aplicadas no nível da organização ou da pasta para herdar as regras da política de firewall de forma consistente em todos os recursos na hierarquia. Além disso, é possível configurar políticas de firewall de rede para cada rede VPC. O blueprint combina essas políticas de firewall para aplicar configurações comuns em todos os ambientes usando políticas hierárquicas de firewall e aplicar configurações mais específicas em cada rede VPC individual usando políticas de firewall de rede.

O blueprint não usa regras de firewall da VPC legada. Recomendamos usar apenas políticas de firewall e evite misturar o uso com regras de firewall da VPC legada.

Políticas de firewall hierárquicas

O blueprint define uma única política hierárquica de firewall e anexa essa política a cada uma das pastas comuns, de produção, de não produção, de desenvolvimento e de inicialização. Essa política hierárquica de firewall contém as regras que precisam ser aplicadas amplamente em todos os ambientes e delega a avaliação de regras mais granulares à política de firewall de rede para cada ambiente individual.

Na tabela a seguir, descrevemos as regras da política hierárquica de firewall implantadas pelo blueprint.

Descrição da regra	Direção do tráfego	Filtro (intervalo IPv4)	Protocolos e portas	Ação
Delegar a avaliação do tráfego de entrada da RFC 1918 aos níveis inferiores da hierarquia.	Ingress	192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12	all	Go to next
Delegar a avaliação do tráfego de saída à RFC 1918 para níveis inferiores na hierarquia.	Egress	192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12	all	Go to next
IAP para encaminhamento de TCP	Ingress	35.235.240.0/20	tcp:22,3390	Allow
Ativação do Windows Server	Egress	35.190.247.13/32	tcp:1688	Allow
Verificações de integridade do Cloud Load Balancing.	Ingress	130.211.0.0/22, 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22	tcp:80,443	Allow

Políticas de firewall de rede

O blueprint configura uma política de firewall de rede para cada rede. Cada política de firewall de rede começa com um conjunto mínimo de regras que permitem o acesso aos serviços do Google Cloud e negam a saída para todos os outros endereços IP.

No modelo hub e spoke, as políticas de firewall de rede contêm outras regras para permitir a comunicação entre spokes. A política de firewall de rede permite o tráfego de saída de um para o hub ou outro spoke e permite o tráfego de entrada do NVA na rede hub.

Na tabela a seguir, descrevemos as regras da política de firewall de rede global implantadas para cada rede VPC no blueprint.

Descrição da regra	Direção do tráfego	Filtro	Protocolos e portas
Permitir tráfego de saída para as APIs do Google Cloud.	Egress	O endpoint do Private Service Connect que é configurado para cada rede individual. Consulte Acesso particular às APIs do Google.	tcp:443
Negar tráfego de saída que não corresponda a outras regras.	Egress	todas	all
Permitir tráfego de saída de um spoke para outro spoke (somente para o modelo hub e spoke).	Egress	A agregação de todos os endereços IP usados na topologia "hub and spoke". O tráfego que sai de uma VPC spoke é encaminhado para o NVA na rede do hub primeiro.	all
Permitir o tráfego de entrada de um spoke do NVA na rede hub (somente para o modelo hub e spoke).	Ingress	Tráfego originado dos NVAs na rede do hub.	all

Quando você implanta o blueprint pela primeira vez, uma instância de VM em uma rede VPC pode se comunicar com os serviços do Google Cloud, mas não com outros recursos de infraestrutura na mesma rede VPC. Para permitir que as instâncias de VM se comuniquem, adicione outras regras à política de firewall de rede e às tags que permitam explicitamente a comunicação entre as instâncias de VM. As tags são adicionadas às instâncias de VM, e o tráfego é avaliado em relação a elas. As tags também têm controles do IAM para que você possa defini-las centralmente e delegar o uso a outras equipes.

Observação: todas as referências a tags neste documento se referem a tags com controles do IAM. Não recomendamos regras de firewall de VPC com tags de rede legadas.

O diagrama a seguir mostra um exemplo de como adicionar tags personalizadas e regras de política de firewall de rede para permitir que as cargas de trabalho se comuniquem dentro de uma rede VPC.

O diagrama demonstra os seguintes conceitos deste exemplo:

• A política de firewall de rede contém a Regra 1 que nega o tráfego de saída de todas as origens com prioridade 65530.
• A política de firewall de rede contém a regra 2, que permite o tráfego de entrada de instâncias com a tag service=frontend para instâncias com a tag service=backend com prioridade 999.
• A VM "instance-2" pode receber tráfego da "instance-1" porque o tráfego corresponde às tags permitidas pela regra 2. A regra 2 é correspondida antes da avaliação da Regra 1 com base no valor de prioridade.
• A VM instance-3 não recebe tráfego. A única regra da política de firewall que corresponde a esse tráfego é a regra 1. Portanto, o tráfego de saída da instância-1 é negado.

Acesso particular às APIs do Google Cloud

Para permitir que os recursos nas redes VPC ou no ambiente local acessem os serviços do Google Cloud, recomendamos a conectividade particular em vez do tráfego de saída da Internet para endpoints de APIs públicos. O blueprint configura o Acesso privado do Google em cada sub-rede e cria endpoints internos com o Private Service Connect para se comunicar com os serviços do Google Cloud. Usados juntos, esses controles permitem um caminho particular para os serviços do Google Cloud, sem depender do tráfego de saída da Internet ou de intervalos de Internet anunciados publicamente.

O blueprint configura endpoints do Private Service Connect com pacotes de API para diferenciar quais serviços podem ser acessados em qual rede. A rede base usa o pacote all-apis e pode acessar qualquer serviço do Google, e a rede restrita usa o pacote vpcsc, que permite acesso a um conjunto limitado de serviços que oferecer suporte ao VPC Service Controls.

Para acesso de hosts localizados em um ambiente local, recomendamos usar uma convenção de FQDN personalizado para cada endpoint, conforme descrito na tabela a seguir. O blueprint usa um endpoint exclusivo do Private Service Connect para cada rede VPC, configurado para acessar um conjunto diferente de pacotes de APIs. Portanto, pense em como rotear o tráfego do serviço do ambiente local para a rede VPC com o endpoint de API correto e, se você estiver usando o VPC Service Controls, verifique se o tráfego para o Os serviços do Cloud alcançam o endpoint dentro do perímetro pretendido. Configure os controles locais para DNS, firewalls e roteadores para permitir acesso a esses endpoints e configure hosts locais para usar o endpoint apropriado. Para mais informações, consulte Acessar APIs do Google por meio de endpoints.

Veja na tabela a seguir os endpoints do Private Service Connect criados para cada rede.

VPC	Ambiente	Pacote de API	Endereço IP do endpoint do Private Service Connect			FQDN personalizado
Base	Nome	all-apis	10.17.0.1/32			c.private.googleapis.com
	Desenvolvimento	all-apis	10.17.0.2/32			d.private.googleapis.com
	Não produção	all-apis	10.17.0.3/32			n.private.googleapis.com
	Produção	all-apis	10.17.0.4/32			p.private.googleapis.com
Restrito	Nome	vpcsc	10.17.0.5/32			c.restricted.googleapis.com
	Desenvolvimento	vpcsc	10.17.0.6/32			d.restricted.googleapis.com
	Não produção	vpcsc	10.17.0.7/32			n.restricted.googleapis.com
	Produção	vpcsc	10.17.0.8/32			p.restricted.googleapis.com

Para garantir que o tráfego dos serviços do Google Cloud tenha uma busca DNS para o endpoint correto, o blueprint configura zonas de DNS particulares para cada rede VPC. A tabela a seguir descreve essas zonas DNS particulares.

Nome da zona particular	Nome do DNS	Tipo de registro	Dados
googleapis.com.	*.googleapis.com.	CNAME	private.googleapis.com. (para redes base) ou restricted.googleapis.com. (para redes restritas)
	private.googleapis.com (para redes base) ou restricted.googleapis.com (para redes restritas)	A	O endereço IP do endpoint do Private Service Connect para essa rede VPC.
gcr.io.	*.gcr.io	CNAME	gcr.io.
	gcr.io	A	O endereço IP do endpoint do Private Service Connect para essa rede VPC.
pkg.dev.	*.pkg.dev.	CNAME	pkg.dev.
	pkg.dev.	A	O endereço IP do endpoint do Private Service Connect para essa rede VPC.

O blueprint tem outras configurações para garantir que esses endpoints do Private Service Connect sejam usados de maneira consistente. Cada rede VPC compartilhada também aplica o seguinte:

• Uma regra de política de firewall de rede que permita o tráfego de saída de todas as origens para o endereço IP do endpoint do Private Service Connect na TCP:443.
• Uma regra da política de firewall de rede que nega o tráfego de saída para 0.0.0.0/0, que inclui os domínios padrão usados para acesso aos serviços do Google Cloud.

Conectividade à Internet

O blueprint não permite tráfego de entrada ou saída entre as redes VPC e a Internet. Para cargas de trabalho que exigem conectividade com a Internet, você precisa seguir outras etapas para criar os caminhos de acesso necessários.

Para cargas de trabalho que exigem tráfego de saída para a Internet, recomendamos gerenciar o tráfego de saída por meio do Cloud NAT para permitir o tráfego de saída sem conexões de entrada não solicitadas, ou por meio de Use o Secure Web Proxy para ter um controle mais granular e permitir o tráfego de saída apenas para serviços da Web confiáveis.

Para cargas de trabalho que exigem tráfego de entrada da Internet, recomendamos que você projete sua carga de trabalho com o Cloud Load Balancing e o Google Cloud Armor para se beneficiar das proteções contra DDoS e WAF.

Não recomendamos que você projete cargas de trabalho que permitam conectividade direta entre a Internet e uma VM usando um endereço IP externo na VM.

Conectividade híbrida entre um ambiente no local e o Google Cloud

Para estabelecer a conectividade entre o ambiente local e o Google Cloud, recomendamos que você use a Interconexão dedicada para maximizar a segurança e a confiabilidade. Uma Interconexão dedicada é um link direto entre a rede local e o Google Cloud.

No diagrama a seguir, apresentamos a conectividade híbrida entre o ambiente local e uma rede de nuvem privada virtual do Google.

O diagrama descreve os seguintes componentes do padrão de disponibilidade de 99,99% na Interconexão dedicada:

• quatro conexões de Interconexão dedicada, com duas conexões em uma área metropolitana (metro) e duas conexões em outra.
• As conexões são divididas em dois pares, e cada um deles conectado a um data center local separado.
• Os anexos da VLAN são usados para conectar cada instância de Interconexão dedicada aos Cloud Routers anexados à topologia da VPC compartilhada. Esses anexos da VLAN estão hospedados no projeto prj-c-interconnect.
• Cada rede VPC compartilhada tem quatro Cloud Routers, dois em cada região, com o modo de roteamento dinâmico definido como global. Assim, cada Cloud Router pode anunciar todas as sub-redes, independentemente da região.

Com o roteamento dinâmico global, o Cloud Router anuncia rotas para todas as sub-redes na rede VPC. O Cloud Router divulga rotas para sub-redes remotas (sub-redes fora da região do Cloud Router) com prioridade mais baixa em comparação com as sub-redes locais (sub-redes que estão na região do Cloud Router). Também é possível alterar os prefixos e as prioridades anunciados ao configurar a sessão do BGP para um Cloud Router.

O tráfego do Google Cloud para um ambiente local usa o Cloud Router mais próximo dos recursos da nuvem. Em uma única região, várias rotas para redes locais têm o mesmo valor de discriminador de várias saídas (MED, na sigla em inglês), e o Google Cloud usa vários caminhos de custo igual (ECMP, na sigla em inglês) para distribuir o tráfego de saída entre todas as rotas possíveis.

Mudanças na configuração no local

Para configurar a conectividade entre o ambiente local e o Google Cloud, configure outras alterações no seu ambiente local. O código do Terraform no blueprint configura automaticamente os recursos do Google Cloud, mas não modifica nenhum dos recursos de rede no local.

Alguns dos componentes de conectividade híbrida do seu ambiente local para o Google Cloud são ativados automaticamente pelo blueprint, incluindo o seguinte:

• O Cloud DNS é configurado com encaminhamento de DNS entre todas as redes VPC compartilhadas para um único hub, conforme descrito em Configuração do DNS. Uma política de servidor do Cloud DNS é configurada com endereços IP de encaminhador de entrada.
• O Cloud Router está configurado para exportar rotas para todas as sub-redes e rotas personalizadas para os endereços IP usados pelos endpoints do Private Service Connect.

Para ativar a conectividade híbrida, você precisa seguir estas etapas:

1. Solicitar uma conexão de interconexão dedicada
2. Configure roteadores e firewalls locais para permitir o tráfego de saída para o espaço de endereços IP internos definido em Alocação do espaço de endereços IP.
3. Configure os servidores DNS locais para encaminhar buscas DNS vinculadas ao Google Cloud para os endereços IP do encaminhador de entrada que já estão configurados pelo blueprint.
4. Configure os servidores DNS, os firewalls e os roteadores locais para aceitar consultas DNS da zona de encaminhamento do Cloud DNS (35.199.192.0/19).
5. Configure servidores DNS locais para responder a consultas de hosts locais para serviços do Google Cloud com os endereços IP definidos no acesso particular às APIs do Cloud.
6. Para criptografia em trânsito pela conexão de Interconexão dedicada, configure MACsec para Cloud Interconnect ou configurar VPN de alta disponibilidade pelo Cloud Interconnect para criptografia IPsec.

Se você quiser mais informações, consulte Como configurar o Acesso privado do Google para hosts locais.

A seguir

• Leia sobre controles de detecção (próximo documento desta série).

Controles de detetive

Os recursos de detecção e monitoramento de ameaças são fornecidos usando uma combinação de controles de segurança integrados do Security Command Center e soluções personalizadas que permitem detectar e responder a eventos de segurança.

Geração de registros centralizada para segurança e auditoria

O blueprint configura recursos de geração de registros para rastrear e analisar alterações nos recursos do Google Cloud com registros agregados a um único projeto.

No diagrama a seguir, mostramos como o blueprint agrega registros de várias origens em vários projetos em um coletor de registros centralizado.

O diagrama descreve o seguinte:

• Os coletores de registros são configurados no nó da organização para agregar registros de todos os projetos na hierarquia de recursos.
• Vários coletores de registros são configurados para enviar registros que correspondem a um filtro a destinos diferentes para armazenamento e análise.
• O projeto prj-c-logging contém todos os recursos para armazenamento de registros e análise.
• Se quiser, você pode configurar outras ferramentas para exportar registros para um SIEM.

O blueprint usa diferentes origens de registro e os inclui no filtro do coletor para que os registros possam ser exportados para um destino centralizado. A tabela a seguir descreve as origens de registro.

Origem do registro	Descrição
Registros de auditoria de atividade do administrador	Não é possível configurar, desativar ou excluir os registros de auditoria de atividade do administrador.
Registros de auditoria de evento do sistema	Não é possível configurar, desativar ou excluir registros de auditoria de eventos do sistema.
Registros de auditoria de política negada:	Não é possível configurar ou desativar os registros de auditoria de políticas negadas, mas você pode excluí-los com filtros de exclusão.
Registros de auditoria de acesso aos dados	Por padrão, o blueprint não ativa os registros de acesso a dados porque o volume e o custo desses registros podem ser altos. Para determinar se você precisa ativar os registros de acesso a dados, avalie onde suas cargas de trabalho lidam com dados confidenciais e considere se há um requisito para ativar os registros de acesso a dados para cada serviço e ambiente que trabalha com dados confidenciais.
Registros de fluxo de VPC	O blueprint ativa os registros de fluxo de VPC para cada sub-rede. O blueprint configura a amostragem de registros para criar amostras de 50% dos registros e reduzir o custo. Se você criar outras sub-redes, garanta que os registros de fluxo de VPC estejam ativados em cada sub-rede.
Registro de regras de firewall	O blueprint ativa a geração de registros de regras de firewall para todas as regras da política de firewall. Se você criar outras regras de política de firewall para cargas de trabalho, verifique se a geração de registros de regras de firewall está ativada para cada regra nova.
Geração de registros do Cloud DNS	O blueprint ativa os registros do Cloud DNS para zonas gerenciadas. Se você criar outras zonas gerenciadas, será necessário ativar esses registros DNS.
Geração de registros de auditoria do Google Workspace	Requer uma etapa única de ativação que não é automatizada pelo blueprint. Para mais informações, consulte Compartilhar dados com os serviços do Google Cloud.
os registros de Transparência no acesso	Requer uma etapa única de ativação que não é automatizada pelo blueprint. Para mais informações, consulte Ativar transparência no acesso.

Veja na tabela a seguir os coletores de registro e como eles são usados com destinos compatíveis no blueprint.

Coletor	Destino	Finalidade
sk-c-logging-la	Registros roteados para buckets do Cloud Logging com a Análise de registros e um conjunto de dados vinculado do BigQuery ativado	Analisa registros ativamente. Execute investigações específicas usando o Explorador de registros no console ou escreva consultas, relatórios e visualizações SQL usando o conjunto de dados vinculado do BigQuery.
sk-c-logging-bkt	Registros roteados para o Cloud Storage	Armazene registros a longo prazo para fins de conformidade, auditoria e rastreamento de incidentes. Opcionalmente, se você tiver requisitos de conformidade para a retenção obrigatório de dados, recomendamos que configure também o Bloqueio de bucket.
sk-c-logging-pub	Registros roteados para o Pub/Sub	Exporte os registros para uma plataforma externa, como seu SIEM atual. Isso exige mais trabalho para integração ao SIEM, como estes mecanismos: Para muitas ferramentas, a integração de terceiros com o Pub/Sub é o método preferido para ingerir registros. Para o Google Chronicle, é possível ingerir dados do Google Cloud para o Chronicle sem provisionar mais infraestrutura. Para o Splunk, é possível fazer streaming de registros do Google Cloud para o Splunk usando o Dataflow.

Para orientações sobre como ativar outros tipos de registro e gravar filtros de coletor de registros, consulte a ferramenta de escopo de registros.

Monitoramento de ameaças com o Security Command Center

Recomendamos que você ative o Security Command Center Premium para sua organização detectar automaticamente ameaças, vulnerabilidades e configurações incorretas nos recursos do Google Cloud. O Security Command Center cria descobertas de segurança de várias fontes, incluindo:

• Security Health Analytics:detecta vulnerabilidades comuns e configurações incorretas nos recursos do Google Cloud.
• Exposição ao caminho de ataque:mostra um caminho simulado de como um invasor pode explorar recursos de alto valor com base nas vulnerabilidades e configurações incorretas detectadas por outras fontes do Security Command Center.
• Detecção de ameaças a eventos:aplica a lógica de detecção e a inteligência reservada contra ameaças aos seus registros para identificar ameaças quase em tempo real.
• Detecção de ameaças a contêineres:detecta ataques comuns ao ambiente de execução do contêiner.
• Detecção de ameaças a máquinas virtuais:detecta aplicativos potencialmente maliciosos em execução nas máquinas virtuais.
• Web Security Scanner: verifica as dez principais vulnerabilidades do OWASP nos seus aplicativos voltados para a Web no Compute Engine, no App Engine ou no Google Kubernetes Engine.

Para mais informações sobre as vulnerabilidades e ameaças abordadas pelo Security Command Center, consulte Origens do Security Command Center.

Ative o Security Command Center depois de implantar o blueprint. Para mais instruções, consulte Ativar o Security Command Center para uma organização.

Depois de ativar o Security Command Center, recomendamos que você exporte as descobertas produzidas pelo Security Command Center para as ferramentas ou processos atuais a fim de fazer a triagem e responder a ameaças. O blueprint cria o projeto prj-c-scc com um tópico do Pub/Sub a ser usado para essa integração. Dependendo das ferramentas atuais, use um dos métodos a seguir para exportar as descobertas:

• Se você usar o console para gerenciar descobertas de segurança diretamente no Security Command Center, configure papéis no nível da pasta e do projeto do Security Command Center para permitir que as equipes visualizem e gerenciem as descobertas de segurança para os projetos pelos quais é responsável.

• Se você usa o Chronicle como SIEM, ingere os dados do Google Cloud para o Chronicle.

• Se você usa uma ferramenta SIEM ou SOAR com integrações ao Security Command Center, compartilhe dados com o Cortex XSOAR, o Elastic Stack, ServiceNow, Splunk ou QRadar.

• Se você usa uma ferramenta externa que pode ingerir descobertas do Pub/Sub, configure exportações contínuas para o Pub/Sub e as ferramentas atuais para ingerir descobertas do Pub/Sub Subtópico.

Alertas sobre métricas com base em registros e de desempenho

Quando você começar a implantar cargas de trabalho em sua base, recomendamos que use o Cloud Monitoring para medir as métricas de desempenho.

O blueprint cria um projeto de monitoramento, como prj-p-monitoring, para cada ambiente. Esse projeto é configurado como um projeto de escopo para reunir métricas de desempenho agregadas em vários projetos. O blueprint implanta um exemplo com métricas com base em registros e uma política de alertas para gerar notificações por e-mail se houver alguma alteração na política do IAM. que é aplicado aos buckets do Cloud Storage. Isso ajuda a monitorar atividades suspeitas em recursos confidenciais, como o bucket no projeto prj-b-seed que contém o estado do Terraform.

Em geral, também é possível usar o Cloud Monitoring para medir as métricas de desempenho e a integridade dos aplicativos de carga de trabalho. Dependendo da responsabilidade operacional por oferecer suporte e monitorar aplicativos na sua organização, é possível criar projetos de monitoramento mais granulares para diferentes equipes. Use esses projetos de monitoramento para visualizar métricas de desempenho, criar painéis de integridade do aplicativo e acionar alertas quando o SLO esperado não for atendido.

O diagrama a seguir mostra uma visão de alto nível de como o Cloud Monitoring agrega métricas de desempenho.

Para orientações sobre como monitorar cargas de trabalho de maneira eficaz quanto à confiabilidade e disponibilidade, consulte o manual Engenharia de confiabilidade do site do Google, especialmente o capítulo sobre monitoramento distribuído sistemas.

Solução personalizada para análise automatizada de registros

Você pode ter requisitos para criar alertas para eventos de segurança baseados em consultas personalizadas em registros. As consultas personalizadas podem complementar os recursos do SIEM analisando registros no Google Cloud e exportando apenas os eventos que merecem investigação, especialmente se você não tiver capacidade de exportar todos os registros da nuvem para o SIEM.

O blueprint ajuda a ativar essa análise de registros, configurando uma fonte centralizada de registros que pode ser consultada usando um conjunto de dados vinculado do BigQuery. Para automatizar esse recurso, implemente o exemplo de código em bq-log-alerting e amplie os recursos básicos. O exemplo de código permite consultar regularmente uma origem de registro e enviar uma descoberta personalizada ao Security Command Center.

O diagrama a seguir apresenta o fluxo geral da análise de registros automatizada.

O diagrama mostra os seguintes conceitos de análise automatizada de registros:

• Os registros de várias origens são agregados em um bucket de registros centralizado com análise de registros e um conjunto de dados vinculado do BigQuery.
• As visualizações do BigQuery são configuradas para consultar registros do evento de segurança que você quer monitorar.
• O Cloud Scheduler envia um evento para um tópico do Pub/Sub a cada 15 minutos e aciona o Cloud Functions.
• O Cloud Functions consulta as visualizações em busca de novos eventos. Se ele encontrar eventos, ele os enviará para o Security Command Center como descobertas personalizadas.
• O Security Command Center publica notificações sobre novas descobertas em outro tópico do Pub/Sub.
• Uma ferramenta externa, como um SIEM, assina o tópico do Pub/Sub para ingerir novas descobertas.

A amostra tem vários casos de uso para consultar comportamentos potencialmente suspeitos. Exemplos incluem um login de uma lista de superadministradores ou outras contas altamente privilegiadas especificadas por você, alterações nas configurações de registro ou alterações nas rotas de rede. É possível ampliar os casos de uso gravando novas visualizações de consulta para seus requisitos. Escreva suas próprias consultas ou consulte a análise de registros de segurança para uma biblioteca de consultas SQL que vai ajudar você a analisar os registros do Google Cloud.

Solução personalizada para responder a mudanças nos recursos

Para responder a eventos em tempo real, recomendamos que você use o Inventário de recursos do Cloud para monitorar as alterações de recursos. Nesta solução personalizada, um feed de recursos é configurado para acionar notificações no Pub/Sub sobre alterações nos recursos em tempo real e, em seguida, o Cloud Functions executa o código personalizado para aplicar sua própria lógica de negócios com base a mudança deve ser permitida.

O blueprint tem um exemplo dessa solução de governança personalizada que monitora alterações do IAM que adicionam papéis altamente confidenciais, incluindo administrador, proprietário e editor da organização. O diagrama a seguir descreve essa solução.

O diagrama anterior mostra esses conceitos:

• Foram feitas alterações em uma política de permissão.
• O feed do Inventário de recursos do Cloud envia uma notificação em tempo real sobre a alteração da política de permissão para o Pub/Sub.
• O Pub/Sub aciona uma função.
• O Cloud Functions executa código personalizado para aplicar sua política. A função de exemplo tem lógica para avaliar se a alteração adicionou os papéis de administrador, proprietário ou editor da organização a uma política de permissão. Nesse caso, a função cria uma descoberta de segurança personalizada e a envia ao Security Command Center.
• Opcionalmente, é possível usar esse modelo para automatizar os esforços de correção. Grave uma lógica de negócios extra no Cloud Functions para realizar ações automaticamente com relação à descoberta, como reverter a política de permissão para o estado anterior.

Além disso, é possível estender a infraestrutura e a lógica usadas por essa solução de exemplo para adicionar respostas personalizadas a outros eventos importantes para seu negócio.

A seguir

• Leia sobre controles de detecção (próximo documento desta série).

Controles preventivos para configurações aceitáveis de recursos

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
compute.disableNestedVirtualization	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.
compute.disableSerialPortAccess	Os papéis do IAM, como compute.instanceAdmin, permitem acesso privilegiado à porta serial da instância usando chaves SSH. Se a chave SSH for exposta, um invasor poderá acessar a porta serial e ignorar os controles de rede e firewall. Essa restrição impede o acesso à porta serial.
compute.disableVpcExternalIpv6	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.
compute.requireOsLogin	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.
compute.restrictProtocolForwardingCreationForTypes	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.
compute.restrictXpnProjectLienRemoval	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.
compute.setNewProjectDefaultToZonalDNSOnly	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.
compute.skipDefaultNetworkCreation	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.
compute.vmExternalIpAccess	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.
essentialcontacts.allowedContactDomains	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.
iam.allowedPolicyMemberDomains	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.
iam.automaticIamGrantsForDefaultServiceAccounts	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.
iam.disableServiceAccountKeyCreation	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.
iam.disableServiceAccountKeyUpload	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.
sql.restrictAuthorizedNetworks	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.
sql.restrictPublicIp	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.
storage.uniformBucketLevelAccess	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 iam.allowedPolicyMemberDomains. Essa restrição garante que o acesso só possa ser configurado por meio de acesso uniforme no nível do bucket do IAM, não de ACLs legadas.
storage.publicAccessPrevention	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 allUsers e allAuthenticatedUsers.

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)

Metodologia de implantação

Recomendamos que você use uma infraestrutura declarativa para implantar sua base de maneira consistente e controlável. Essa abordagem permite uma governança consistente, aplicando controles de política sobre configurações aceitáveis de recursos nos seus pipelines. O blueprint é implantado usando um fluxo do GitOps, com o Terraform usado para definir a infraestrutura como código (IaC, na sigla em inglês), um repositório Git para controle de versões e aprovação de código, e o Cloud Build para automação de CI/CD no o pipeline de implantação. Para conferir uma introdução a esse conceito, consulte Gerenciar a infraestrutura como código com o Terraform, o Cloud Build e o GitOps.

As seções a seguir descrevem como o pipeline de implantação é usado para gerenciar recursos na sua organização.

Camadas do pipeline

Para separar as equipes e a pilha de tecnologia responsáveis por gerenciar diferentes camadas do ambiente, recomendamos um modelo que use pipelines diferentes e perfis responsáveis por cada camada da pilha.

No diagrama a seguir, apresentamos nosso modelo recomendado para separar um pipeline de fundação, um pipeline de infraestrutura e um pipeline de aplicativo.

O diagrama apresenta as camadas de pipeline neste modelo:

• O pipeline de base implanta os recursos básicos que são usados em toda a plataforma. Recomendamos que uma única equipe central seja responsável por gerenciar os recursos de base consumidos por várias unidades de negócios e cargas de trabalho.
• O pipeline de infraestrutura implanta projetos e infraestrutura que são usados por cargas de trabalho, como instâncias de VM ou bancos de dados. O blueprint configura um pipeline de infraestrutura separado para cada unidade de negócios. Você também pode preferir um único pipeline de infraestrutura usado por várias equipes.
• O pipeline do aplicativo implanta os artefatos para cada carga de trabalho, como contêineres ou imagens. É possível ter várias equipes de aplicativo diferentes com pipelines de aplicativos individuais.

As seções a seguir apresentam o uso de cada camada do pipeline.

O pipeline de base

O pipeline de base implanta os recursos básicos. Ele também configura o pipeline de infraestrutura usado para implantar a infraestrutura usada pelas cargas de trabalho.

Para criar o pipeline de base, primeiro clone ou bifurque a base do Terraform-example para seu próprio repositório Git. Siga as etapas no arquivo README 0-bootstrap para configurar a pasta e os recursos de inicialização.

Etapa

Descrição

0-bootstrap

Inicializa uma organização do Google Cloud. Esta etapa também configura um pipeline de CI/CD para o código de blueprint nos estágios subsequentes. O projeto CICD contém o pipeline base do Cloud Build para implantar recursos. O projeto seed inclui os buckets do Cloud Storage que contêm o estado do Terraform da infraestrutura da fundação e contas de serviço altamente privilegiadas que são usadas pelo pipeline da fundação para criar recursos. O estado do Terraform é protegido pelo controle de versões de objetos de armazenamento. Quando o pipeline de CI/CD é executado, ele atua como as contas de serviço gerenciadas no projeto seed.

Depois de criar o pipeline de base no cenário 0-bootstrap, os estágios a seguir implantam recursos nele. Revise as instruções README de cada etapa e implemente cada uma em sequência.

Etapa	Descrição
1-org	Configura as pastas compartilhadas de nível superior, projetos para serviços compartilhados, geração de registros no nível da organização e configurações de segurança de valor de referência por meio de políticas da organização.
2-environments	Configura os ambientes de desenvolvimento, de não produção e de produção na organização do Google Cloud que você criou.
3-networks-dual-svpc ou 3-networks-hub-and-spoke	Configura as VPCs compartilhadas na topologia escolhida e nos recursos de rede associados.

O pipeline de infraestrutura

O pipeline de infraestrutura implanta os projetos e a infraestrutura (por exemplo, as instâncias de VM e os bancos de dados) que são usados pelas cargas de trabalho. O pipeline de base implanta vários pipelines de infraestrutura. Essa separação entre o pipeline de base e o pipeline de infraestrutura permite separar recursos de toda a plataforma e recursos específicos da carga de trabalho.

No diagrama a seguir, descrevemos como o blueprint configura vários pipelines de infraestrutura destinados ao uso por equipes separadas.

O diagrama descreve os seguintes conceitos principais:

• Cada pipeline de infraestrutura é usado para gerenciar recursos de infraestrutura independentemente dos recursos de fundação.
• Cada unidade de negócios tem o próprio pipeline de infraestrutura, gerenciado em um projeto dedicado na pasta common.
• Cada um dos pipelines de infraestrutura tem uma conta de serviço com permissão para implantar recursos apenas em projetos associados a essa unidade de negócios. Essa estratégia cria uma separação de tarefas entre as contas de serviço privilegiadas usadas para o pipeline de fundação e aquelas usadas por cada pipeline de infraestrutura

Essa abordagem com vários pipelines de infraestrutura é recomendada quando há várias entidades dentro da organização com as habilidades e o apetite para gerenciar a infraestrutura separadamente, especialmente se elas tiverem requisitos diferentes, como tipos de validação de pipeline política que eles querem aplicar. Outra opção é ter um único pipeline de infraestrutura gerenciado por uma única equipe com políticas de validação consistentes.

Em terraform-example-foundation, o estágio 4 configura um pipeline de infraestrutura e o estágio 5 demonstra um exemplo de uso desse pipeline para implantar recursos de infraestrutura.

Etapa	Descrição
4-projects	Configura uma estrutura de pastas, projetos e um pipeline de infraestrutura.
5-app-infra (opcional)	Implanta projetos de carga de trabalho com uma instância do Compute Engine usando o pipeline de infraestrutura como exemplo.

Pipeline do aplicativo

O pipeline do aplicativo é responsável por implantar artefatos de aplicativos para cada carga de trabalho individual, como imagens ou contêineres do Kubernetes que executam a lógica de negócios do aplicativo. Esses artefatos são implantados nos recursos de infraestrutura que foram implantados pelo pipeline de infraestrutura.

O blueprint de base da empresa configura o pipeline de fundação e o pipeline de infraestrutura, mas não implanta um pipeline de aplicativos. Para ver um exemplo de pipeline de aplicativos, consulte o Blueprint de aplicativos empresariais.

Como automatizar seu pipeline com o Cloud Build

O blueprint usa o Cloud Build para automatizar processos de CI/CD. Na tabela a seguir, descrevemos que os controles são incorporados ao pipeline de fundação e ao pipeline de infraestrutura implantados pelo repositório terraform-example-foundation. Se estiver desenvolvendo seus próprios pipelines usando outras ferramentas de automação de CI/CD, recomendamos que você aplique controles semelhantes.

Controle	Descrição
Configurações de build separadas para validar o código antes da implantação	O blueprint usa dois arquivos de configuração do build do Cloud Build para todo o pipeline, e cada repositório associado a um estágio tem dois gatilhos do Cloud Build que são associados a esses arquivos de configuração de compilação. Quando o código é enviado por push para uma ramificação de repositório, os arquivos de configuração do build são acionados para executar primeiro cloudbuild-tf-plan.yaml, que valida seu código com verificações de política e o Terraform plan em relação a essas então cloudbuild-tf-apply.yaml executa terraform apply no resultado desse plano.
Verificações de política do Terraform	O blueprint inclui um conjunto de restrições do Open Policy Agent que são aplicadas pela validação de política na CLI do Google Cloud. Essas restrições definem as configurações de recursos aceitáveis que podem ser implantadas pelo pipeline. Se um build não atender à política na primeira configuração do build, a segunda não vai implantar nenhum recurso. As políticas aplicadas no blueprint são ramificadas de GoogleCloudPlatform/policy-library no GitHub. É possível escrever outras políticas para a biblioteca aplicar políticas personalizadas a fim de atender aos seus requisitos.
Princípio de privilégio mínimo	O pipeline de base tem uma conta de serviço diferente para cada estágio, com uma política de permissão que concede apenas os papéis mínimos do IAM para esse estágio. Cada gatilho do Cloud Build é executado como a conta de serviço específica para esse estágio. O uso de contas diferentes ajuda a reduzir o risco de que a modificação de um repositório possa afetar os recursos gerenciados por outro. Para entender os papéis específicos do IAM aplicados a cada conta de serviço, consulte o código sa.tf do Terraform no estágio de inicialização.
Pools privados do Cloud Build	O blueprint usa pools particulares do Cloud Build. Com os pools particulares, você tem a opção de aplicar outros controles, como restringir o acesso a repositórios públicos ou executar o Cloud Build dentro de um perímetro do VPC Service Controls.
Criadores personalizados do Cloud Build	O blueprint cria o próprio criador personalizado para executar o Terraform. Para ver mais informações, consulte 0-bootstrap/Dockerfile. Esse controle garante que o pipeline seja executado de maneira consistente com um conjunto conhecido de bibliotecas em versões fixadas.
Aprovação da implantação	Também é possível adicionar um estágio de aprovação manual ao Cloud Build. Essa aprovação adiciona outro checkpoint após o build ser acionado, mas antes de ser executado, para que um usuário com privilégios possa aprová-lo manualmente.

Estratégia de ramificação

Recomendamos uma estratégia de ramificação permanente para enviar código ao sistema Git e implantar recursos por meio do pipeline de base. O diagrama a seguir descreve a estratégia de ramificação permanente.

O diagrama descreve três ramificações persistentes no Git (desenvolvimento, não produção e produção) que refletem os ambientes correspondentes do Google Cloud. Há também várias ramificações de recursos temporárias que não correspondem aos recursos implantados nos ambientes do Google Cloud.

Recomendamos que você aplique um processo de solicitação de envio (PR, na sigla em inglês) ao sistema Git para que qualquer código mesclado a uma ramificação persistente tenha um PR aprovado.

Para desenvolver código com essa estratégia de ramificação persistente, siga estas etapas gerais:

1. Quando você estiver desenvolvendo novos recursos ou trabalhando em uma correção de bug, crie uma nova ramificação com base na ramificação de desenvolvimento. Use uma convenção de nomenclatura para a ramificação que inclua o tipo de alteração, um número de tíquete ou outro identificador e uma descrição legível, como feature/123456-org-policies.
2. Ao concluir o trabalho na ramificação de recursos, abra um PR que segmente a ramificação de desenvolvimento.
3. Quando você envia o PR, ele aciona o pipeline de fundação para executar terraform plan e terraform validate para preparar e verificar as alterações.
4. Depois de validar as alterações no código, mescle o recurso ou a correção de bug na ramificação de desenvolvimento.
5. O processo de mesclagem aciona o pipeline de base para executar terraform apply e implantar as alterações mais recentes na ramificação de desenvolvimento no ambiente de desenvolvimento.
6. Analise as alterações no ambiente de desenvolvimento usando revisões manuais, testes funcionais ou testes completos relevantes para seu caso de uso. Em seguida, promova as mudanças no ambiente de não produção abrindo um PR que segmenta a ramificação que não é de produção e mescle as alterações.
7. Para implantar recursos no ambiente de produção, repita o mesmo processo da etapa 6: revisar e validar os recursos implantados, abrir um PR para a ramificação de produção e fazer a mesclagem.

A seguir

• Leia sobre as práticas recomendadas de operações (próximo documento desta série).

Práticas recomendadas de operações

Nesta seção, apresentamos as operações que você precisa considerar ao implantar e operar cargas de trabalho extras no ambiente do Google Cloud. Esta seção não aborda todas as operações no seu ambiente de nuvem, mas apresenta decisões relacionadas às recomendações de arquitetura e aos recursos implantados pelo blueprint.

Atualizar recursos básicos

Embora o projeto forneça um ponto de partida específico para seu ambiente de fundação, os requisitos dela podem aumentar com o tempo. Após a implantação inicial, é possível ajustar as definições de configuração ou criar novos serviços compartilhados para serem consumidos por todas as cargas de trabalho.

Para modificar os recursos de base, recomendamos que você faça todas as mudanças pelo pipeline de base. Consulte a estratégia de ramificação para ver uma introdução ao fluxo de programação de código, mesclando-o e acionando os pipelines de implantação.

Decidir atributos para novos projetos de carga de trabalho

Ao criar novos projetos por meio do módulo de fábrica do projeto do pipeline de automação, você precisa configurar vários atributos. Seu processo para projetar e criar projetos para novas cargas de trabalho precisa incluir decisões para o seguinte:

• Quais APIs do Google Cloud ativar
• Qual VPC compartilhada será usada ou se uma nova rede VPC será criada.
• Quais papéis do IAM criar para a project-service-account inicial que é criada pelo pipeline
• Quais rótulos do projeto aplicar
• A pasta em que o projeto está implantado
• Qual conta de faturamento usar
• Se o projeto deve ser adicionado a um perímetro do VPC Service Controls
• Define se um limite de alerta de orçamento e faturamento precisa ser configurado para o projeto

Para uma referência completa dos atributos configuráveis para cada projeto, consulte as variáveis de entrada para a fábrica do projeto no pipeline de automação.

Gerenciar permissões em escala

Ao implantar projetos de carga de trabalho em sua base, você precisa considerar como concederá acesso aos desenvolvedores e consumidores pretendidos desses projetos. Recomendamos que você adicione usuários a um grupo gerenciado pelo seu provedor de identidade, sincronize os grupos com o Cloud Identity e aplique papéis do IAM a eles. Sempre tenha em mente o princípio de privilégio mínimo.

Também recomendamos que você use o recomendador do IAM para identificar políticas de permissão que concedem papéis com muito privilégios. Crie um processo para revisar periodicamente as recomendações ou aplicar recomendações automaticamente aos seus pipelines de implantação.

Coordenar as alterações entre as equipes de rede e de aplicativos

As topologias de rede implantadas pelo blueprint presumem que você tenha uma equipe responsável por gerenciar recursos de rede e equipes separadas responsáveis por implantar recursos de infraestrutura de carga de trabalho. À medida que as equipes de carga de trabalho implantam a infraestrutura, elas precisam criar regras de firewall que permitam os caminhos de acesso pretendidos entre os componentes da carga de trabalho, mas não têm permissão para modificar as políticas de firewall de rede.

Planeje como as equipes trabalharão juntas para coordenar as alterações nos recursos de rede centralizados necessários para implantar aplicativos. Por exemplo, é possível projetar um processo em que uma equipe de carga de trabalho solicita tags para aplicativos. A equipe de rede cria as tags e adiciona regras à política de firewall da rede para permitir que o tráfego flua entre os recursos com as tags e delegar os papéis do IAM para usar as tags ao administrador de carga de trabalho.

Otimizar seu ambiente com o portfólio do Active Assist

Além do recomendador do IAM, o Google Cloud oferece o portfólio de serviços do Active Assist para fazer recomendações sobre como otimizar o ambiente. Por exemplo, os insights do firewall ou o recomendador do projeto autônomo oferecem recomendações práticas que podem ajudar a reforçar sua postura de segurança.

Crie um processo para revisar periodicamente as recomendações ou aplicá-las automaticamente aos seus pipelines de implantação. Decida quais recomendações precisam ser gerenciadas por uma equipe central e quais devem ser responsabilidade dos proprietários da carga de trabalho e aplique papéis do IAM para acessar as recomendações de maneira adequada.

Conceder exceções às políticas da organização

O blueprint aplica um conjunto de restrições de políticas da organização recomendadas para a maioria dos clientes na maioria dos cenários. No entanto, é possível ter casos de uso legítimos que exijam exceções limitadas às políticas da organização aplicadas amplamente.

Por exemplo, o blueprint aplica a restrição iam.disableServiceAccountKeyCreation. Essa restrição é um controle de segurança importante porque um vazamento de uma chave de conta de serviço pode ter um impacto negativo significativo. A maioria dos cenários precisa usar alternativas mais seguras para chaves de conta de serviço para autenticar. de dois minutos. No entanto, pode haver casos de uso que só podem ser autenticados com uma chave de conta de serviço, como um servidor local que exige acesso aos serviços do Google Cloud e não pode usar a federação de identidade da carga de trabalho. Nesse cenário, você pode permitir uma exceção à política, desde que controles de compensação adicionais, como práticas recomendadas para gerenciar chaves de conta de serviço, sejam aplicados.

Portanto, crie um processo para que as cargas de trabalho solicitem uma exceção às políticas e garanta que os tomadores de decisões responsáveis por conceder exceções tenham o conhecimento técnico para validar o caso de uso e consultar se os responsáveis pela tomada de decisões é necessário haver controles adicionais para compensar. Ao conceder uma exceção a uma carga de trabalho, modifique a restrição da política da organização da forma mais restrita possível. Também é possível adicionar restrições condicionalmente a uma política da organização definindo uma tag que conceda uma exceção ou aplicação para a política e aplicando a tag a projetos e pastas.

Proteger seus recursos com o VPC Service Controls

O blueprint ajuda a preparar o ambiente para o VPC Service Controls separando as redes base e restrita. No entanto, por padrão, o código do Terraform não ativa o VPC Service Controls porque essa ativação pode ser um processo disruptivo.

Um perímetro nega acesso a serviços restritos do Google Cloud de tráfego que se origina fora do perímetro, que inclui o console, as estações de trabalho do desenvolvedor e o pipeline de fundação usado para implantar recursos. Se você usar o VPC Service Controls, precisará projetar exceções ao perímetro que permitam os caminhos de acesso pretendidos.

Um perímetro do VPC Service Controls é destinado aos controles de exfiltração entre sua organização do Google Cloud e fontes externas. O perímetro não se destina a substituir ou duplicar políticas de permissão para controle de acesso granular a projetos ou recursos individuais. Ao projetar e arquitetar um perímetro, recomendamos o uso de um perímetro unificado comum para reduzir a sobrecarga de gerenciamento.

Se for necessário projetar vários perímetros para controlar de maneira granular o tráfego de serviço na sua organização do Google Cloud, recomendamos definir claramente as ameaças que são abordadas por uma estrutura de perímetro mais complexa e os caminhos de acesso entre os perímetros que são necessárias para as operações pretendidas.

Para adotar o VPC Service Controls, avalie o seguinte:

• Quais dos seus casos de uso exigem o VPC Service Controls?

• Se os serviços necessários do Google Cloud são compatíveis com o VPC Service Controls.

• Como configurar o acesso de implantação forçada para modificar o perímetro, caso ele interrompa os pipelines de automação.

• Como usar práticas recomendadas para permitir o VPC Service Controls a fim de projetar e implementar seu perímetro.

Depois que o perímetro for ativado, recomendamos que você projete um processo para adicionar consistentemente novos projetos ao perímetro correto e um processo para projetar exceções quando os desenvolvedores tiverem um novo caso de uso negado pela configuração atual do perímetro.

Testar mudanças em toda a organização em uma organização separada

Recomendamos que você nunca implante alterações na produção sem testes. Para recursos de carga de trabalho, essa abordagem é facilitada por ambientes separados para desenvolvimento, não produção e produção. No entanto, alguns recursos da organização não têm ambientes separados para facilitar o teste.

Para alterações no nível da organização ou outras alterações que podem afetar os ambientes de produção, como a configuração entre seu provedor de identidade e o Cloud Identity, considere criar uma organização separada para fins de teste.

Controlar o acesso remoto a máquinas virtuais

Como recomendamos a implantação da infraestrutura imutável por meio do pipeline de fundação, do pipeline de infraestrutura e do pipeline de aplicativos, também recomendamos que você conceda somente aos desenvolvedores acesso direto a uma máquina virtual por SSH ou RDP para casos de uso excepcionais.

Para cenários que exigem acesso remoto, recomendamos gerenciar o acesso de usuários usando o Login do SO quando possível. Essa abordagem usa serviços gerenciados do Google Cloud para aplicar o controle de acesso, o gerenciamento do ciclo de vida da conta, a verificação em duas etapas e a geração de registros de auditoria. Como alternativa, se você precisar permitir o acesso por meio de chaves SSH em metadados ou credenciais RDP, é sua responsabilidade gerenciar o ciclo de vida da credencial e armazenar com segurança fora do Google Cloud.

Em qualquer cenário, um usuário com acesso SSH ou RDP a uma VM pode ser um risco de escalonamento de privilégios. Portanto, projete seu modelo de acesso com isso em mente. O usuário pode executar o código nessa VM com os privilégios da conta de serviço associada ou consultar o servidor de metadados para ver o token de acesso usado para autenticar as solicitações da API. Esse acesso pode ser um escalonamento de privilégios se você não pretendia deliberadamente que o usuário opere com os privilégios da conta de serviço.

Reduzir gastos excessivos planejando alertas de orçamento

O blueprint implementa as práticas recomendadas apresentadas no framework de arquitetura do Google Cloud: otimização de custos para gerenciar custos, incluindo o seguinte:

• Usar uma única conta de faturamento em todos os projetos da base empresarial.

• Atribua a cada projeto um rótulo de metadados billingcode usado para alocar o custo entre os centros de custo.

• Definir orçamentos e limites de alertas.

É sua responsabilidade planejar orçamentos e configurar alertas de faturamento. O blueprint cria alertas de orçamento para projetos de carga de trabalho quando os gastos previstos estão no caminho certo para atingir 120% do orçamento. Essa abordagem permite que uma equipe central identifique e mitigue incidentes de gastos excessivos significativos. Aumentos significativos e inesperados nos gastos sem uma causa clara podem ser um indicador de um incidente de segurança e precisam ser investigados da perspectiva do controle de custos e da segurança.

Observação: os alertas de orçamento abrangem um tipo de notificação diferente da categoria de faturamento dos contatos essenciais. Os alertas de orçamento estão relacionados ao consumo de orçamentos definidos para cada projeto. As notificações de faturamento dos contatos essenciais estão relacionadas a atualizações de preços, erros e créditos.

Dependendo do caso de uso, é possível definir um orçamento com base no custo de uma pasta de ambiente inteira ou de todos os projetos relacionados a um determinado centro de custo, em vez de definir orçamentos granulares para cada projeto. Também recomendamos que você delegue a configuração de orçamento e alerta aos proprietários de carga de trabalho que possam definir um limite de alertas mais granular para o monitoramento diário.

Para orientações sobre como criar recursos de FinOps, incluindo a previsão de orçamentos para cargas de trabalho, consulte Introdução ao FinOps no Google Cloud.

Alocar custos entre centros de custo internos

No console, é possível acessar seus relatórios de faturamento para conferir e prever os custos em várias dimensões. Além dos relatórios pré-criados, recomendamos que você exporte dados de faturamento para um conjunto de dados do BigQuery no projeto prj-c-billing-logs. Os registros de faturamento exportados permitem alocar custos em dimensões personalizadas, como seus centros de custo internos, com base em metadados de rótulo do projeto, como billingcode.

A consulta SQL a seguir é um exemplo de consulta para entender os custos de todos os projetos agrupados pelo rótulo billingcode.

#standardSQL
SELECT
   (SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
   service.description AS description,
   SUM(cost) AS charges,
   SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC

Para configurar essa exportação, consulte Exportar dados do Cloud Billing para o BigQuery.

Se você precisar de contabilidade interna ou estorno entre centros de custo, será sua responsabilidade incorporar os dados obtidos dessa consulta aos seus processos internos.

Ingerir descobertas de controles de detecção no seu SIEM atual

Embora os recursos básicos ajudem você a configurar destinos agregados para registros de auditoria e descobertas de segurança, é sua responsabilidade decidir como consumir e usar esses sinais.

Se você precisa agregar registros de todos os ambientes de nuvem e no local em um SIEM, decida como ingerir registros do prj-c-logging projeto e as descobertas do Security Command Center para as ferramentas e processos atuais. É possível criar uma única exportação para todos os registros e descobertas se uma única equipe for responsável por monitorar a segurança em todo o ambiente. Também é possível criar várias exportações filtradas para o conjunto de registros e descobertas necessários para várias equipes com diferentes responsabilidades.

Como alternativa, se o volume e o custo dos registros forem proibitivos, será possível evitar a duplicação mantendo os registros e as descobertas do Google Cloud apenas no Google Cloud. Nesse cenário, verifique se as equipes atuais têm o acesso e o treinamento certos para trabalhar com registros e descobertas diretamente no Google Cloud.

• Para registros de auditoria, crie visualizações de registros para conceder acesso a um subconjunto de registros no bucket de registros centralizados para equipes individuais, em vez de duplicar os registros em vários buckets, o que aumenta o custo de armazenamento.
• Para descobertas de segurança, conceda papéis no nível da pasta e do projeto ao Security Command Center para permitir que as equipes visualizem e gerenciem descobertas de segurança apenas dos projetos pelos quais são responsáveis, diretamente console.

Desenvolver continuamente sua biblioteca de controles

O modelo começa com uma linha de base de controles para detectar e evitar ameaças. Recomendamos que você analise esses controles e adicione outros controles com base nos seus requisitos. A tabela a seguir resume os mecanismos para aplicar políticas de governança e como estendê-los aos seus outros requisitos:

Controles de política aplicados pelo blueprint	Orientações para estender esses controles
O Security Command Center detecta vulnerabilidades e ameaças de várias fontes de segurança.	Defina módulos personalizados para a Análise de integridade da segurança e módulos personalizados para o Event Threat Detection.
O serviço Política da organização aplica um conjunto recomendado de restrições da política da organização nos serviços do Google Cloud.	Aplique outras restrições usando a lista predefinida de restrições disponíveis ou crie restrições personalizadas.
A política Open Policy Agent (OPA) valida o código no pipeline de base para configurações aceitáveis antes da implantação.	Desenvolvemos outras restrições com base nas orientações disponíveis em GoogleCloudPlatform/policy-library.
A configuração Alertas sobre métricas com base em registros e métricas de desempenho configura métricas com base em registros para alertar sobre alterações nas políticas e configurações do IAM de alguns recursos confidenciais.	Projete outras métricas com base em registros e políticas de alertas para eventos de registro que não podem ocorrer no seu ambiente.
Uma solução personalizada para análise automatizada de registros consulta regularmente os registros em busca de atividades suspeitas e cria descobertas do Security Command Center.	Escreva outras consultas para criar descobertas para eventos de segurança que você quer monitorar usando a análise de registros de segurança como referência.
Uma solução personalizada para responder a mudanças de recursos cria descobertas do Security Command Center e pode automatizar as ações de correção.	Crie feeds adicionais do Inventário de recursos do Cloud para monitorar alterações de tipos de recursos específicos e grave funções do Cloud adicionais com lógica personalizada para responder a violações da política.

Esses controles podem evoluir à medida que seus requisitos e maturidade são alterados no Google Cloud.

Gerenciar chaves de criptografia com o Cloud Key Management Service

O Google Cloud fornece criptografia padrão em repouso para todo o conteúdo do cliente, mas também fornece o Cloud Key Management Service (Cloud KMS) para fornecer outras controle sobre as chaves de criptografia dos dados em repouso. Recomendamos avaliar se a criptografia padrão é suficiente ou se você tem um requisito de conformidade que precisa usar o Cloud KMS para gerenciar as chaves por conta própria. Para mais informações, consulte decidir como atender aos requisitos de compliance para criptografia em repouso.

O blueprint inclui um projeto prj-c-kms na pasta comum e um projeto prj-{env}-kms em cada pasta do ambiente para gerenciar as chaves de criptografia centralmente. Essa abordagem permite que uma equipe central audite e gerencie chaves de criptografia usadas por recursos em projetos de carga de trabalho para atender aos requisitos regulatórios e de conformidade.

Dependendo do seu modelo operacional, você pode preferir uma única instância de projeto centralizada do Cloud KMS sob o controle de uma única equipe, gerenciar as chaves de criptografia separadamente em cada ambiente ou várias instâncias distribuídas para que a responsabilidade pelas chaves de criptografia possa ser delegada às equipes apropriadas. Modifique o exemplo de código do Terraform conforme necessário para se ajustar ao modelo operacional.

Também é possível aplicar políticas da organização de chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês) para que determinados tipos de recursos sempre exijam uma chave CMEK e que apenas chaves CMEK de uma lista de permissões de projetos confiáveis podem ser usados.

Armazenar e auditar credenciais de aplicativos com o Secret Manager

Recomendamos que você nunca confirme secrets confidenciais (como chaves de API, senhas e certificados particulares) em repositórios de código-fonte. Em vez disso, confirme o secret no Secret Manager e conceda o papel do IAM de Acessador de secrets do Secret Manager à conta de serviço ou usuário que precisa acessar o secret. Recomendamos que você conceda o papel do IAM a um secret individual, não a todos os secrets no projeto.

Sempre que possível, gere secrets de produção automaticamente nos pipelines de CI/CD e mantenha-os inacessíveis aos usuários humanos, exceto em situações de acesso de emergência. Nesse cenário, não conceda papéis do IAM para visualizar esses secrets para nenhum usuário ou grupo.

O blueprint fornece um único projeto prj-c-secrets na pasta comum e um projeto prj-{env}-secrets em cada pasta de ambiente para gerenciar secrets centralmente. Essa abordagem permite que uma equipe central audite e gerencie secrets usados por aplicativos para atender aos requisitos regulatórios e de conformidade.

Dependendo do seu modelo operacional, você pode preferir uma única instância centralizada do Secret Manager sob o controle de uma equipe, ou gerenciar os secrets separadamente em cada ambiente ou vários instâncias distribuídas do Secret Manager para que cada equipe de carga de trabalho possa gerenciar os próprios secrets. Modifique o exemplo de código do Terraform conforme necessário para se ajustar ao modelo operacional.

Planejar o acesso de implantação forçada a contas altamente privilegiadas

Recomendamos que as mudanças nos recursos de fundação sejam gerenciadas por uma IaC com controle de versão implantada pelo pipeline de fundação, mas talvez haja cenários excepcionais ou de emergência que exijam acesso privilegiado para modificar o ambiente diretamente. Recomendamos que você se planeje para contas de acesso de emergência (às vezes chamadas de chamadas de emergência ou contas de emergência) que tenham acesso altamente privilegiado ao ambiente em caso de emergência ou quando o processo de automação for interrompido.

A tabela a seguir descreve alguns exemplos de contas de implantação forçada.

Finalidade do implantação forçada	Descrição
Superadministrador	Acesso emergencial ao papel Super administrador usado com o Cloud Identity para, por exemplo, corrigir problemas relacionados à federação de identidade ou à autenticação multifator. MFA).
Administrador da organização	Acesso emergencial ao papel de Administrador da organização, que pode conceder acesso a qualquer outro papel do IAM na organização.
Administrador do pipeline de base	Acesso emergencial para modificar os recursos no projeto CICD no Google Cloud e no repositório Git externo caso a automação do pipeline de fundação falhe.
Operações ou SRE	Uma equipe de operações ou de SRE precisa de acesso privilegiado para responder a interrupções ou incidentes. Isso pode incluir tarefas como reiniciar VMs ou restaurar dados.

O mecanismo para permitir o acesso de implantação forçada depende das ferramentas e dos procedimentos atuais, mas alguns mecanismos de exemplo incluem:

• Use as ferramentas atuais de gerenciamento de acesso privilegiado para adicionar temporariamente um usuário a um grupo predefinido com papéis do IAM altamente privilegiados ou usar as credenciais de uma conta altamente privilegiada.
• Pré-provisionar contas destinadas apenas ao uso do administrador. Por exemplo, a desenvolvedora Dana pode ter uma identidade [e-mail] para uso diário e [e-mail] para acesso de implantação forçada.
• Use um aplicativo como o acesso privilegiado just-in-time, que permite que um desenvolvedor encaminhe papéis mais privilegiados.

Independentemente do mecanismo usado, considere como você aborda operacionalmente as seguintes perguntas:

• Como você projeta o escopo e a granularidade do acesso de implantação forçada? Por exemplo, é possível projetar um mecanismo de implantação forçada diferente para diferentes unidades de negócios a fim de garantir que elas não interrompam umas às outras.
• Como seu mecanismo evita abusos? Você precisa de aprovações? Por exemplo, é possível ter operações de divisão em que uma pessoa tem credenciais e outra tem o token MFA.
• Como auditar e alertar sobre o acesso de implantação forçada? Por exemplo, é possível configurar um módulo personalizado do Event Threat Detection para criar uma descoberta de segurança quando uma conta de implantação forçada predefinida for usada.
• Como remover o acesso de implantação forçada e retomar as operações normais após o incidente?

Para tarefas comuns de escalonamento de privilégios e reversão de alterações, recomendamos projetar fluxos de trabalho automatizados em que um usuário possa executar a operação sem exigir escalonamento de privilégios para a identidade do usuário. Essa abordagem pode ajudar a reduzir erros humanos e melhorar a segurança.

Para sistemas que exigem intervenção regular, automatizar a correção pode ser a melhor solução. O Google incentiva os clientes a adotar uma abordagem de produção sem toque para fazer todas as alterações de produção usando automação, proxies seguros ou implantação forçada auditada. O Google fornece os livros de SRE para clientes que queiram adotar a abordagem de SRE do Google.

A seguir

• Leia Implantar o blueprint (próximo documento desta série).

Implantar o blueprint

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: Crie uma conta do Cloud Identity e verifique a propriedade do domínio. Solicite uma conta com fatura da equipe de vendas do Google Cloud ou crie uma conta de faturamento por autoatendimento. Práticas recomendadas de segurança para contas de administrador Verifique e reconcilie problemas com contas de usuário pessoais. Configure seu provedor de identidade externo como fonte de verdade para sincronizar contas de usuário e o SSO. Provisione os grupos para controle de acesso necessários para executar o blueprint. Determine a topologia de rede que você usará. Escolha a ferramenta de gerenciamento de código-fonte. As instruções para terraform-example-foundation são gravadas em um repositório Git hospedado no Cloud Source Repositories. Decida as ferramentas de automação de CI/CD. terraform-example-foundation fornece diferentes conjuntos de instruções para diversas ferramentas de automação. Para se conectar a um ambiente local atual, prepare o seguinte: Planeje sua alocação de endereços IP com base no número e no tamanho dos intervalos exigidos pelo blueprint. Solicite suas conexões de Interconexão dedicada.
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: Prepare 0-bootstrap para criar um pipeline de base. Se você estiver usando uma conta de faturamento de autoatendimento, solicite uma cota adicional de projeto antes de prosseguir para a próxima etapa. Prepare 1-org para configurar os recursos no nível da organização. Prepare 2-environments para criar ambientes. Prepare 3-networks-dual-svpc or 3-networks-hub-and-spoke para criar recursos de rede na sua topologia preferida. Prepare 4-projects para criar um pipeline de infraestrutura. Opcionalmente, prepare 5-app-infra para uma amostra de uso do pipeline de infraestrutura.
Etapas adicionais após a implantação da IaC	Depois de implantar o código do Terraform, siga estas etapas: Conclua as alterações de configuração no local. Ativar o Security Command Center Premium. Exportar dados do Cloud Billing para o BigQuery Inscreva-se em um plano do Cloud Customer Care. Ative os registros de transparência no acesso. Compartilhar dados do Cloud Identity com o Google Cloud. Aplique os controles administrativos do Cloud Identity que não são automatizados pela implantação de IaC. Avalie quais dos controles administrativos adicionais para clientes com cargas de trabalho confidenciais são adequados para seu caso de uso. Consulte as práticas recomendadas de operação e planeje como conectar suas operações e recursos atuais aos recursos de fundação.

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	[e-mail] Em que description representa informações adicionais sobre o grupo. Use abreviações curtas e legíveis. Por exemplo: [e-mail]
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	[e-mail] 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: [e-mail]
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 Chronicle 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

• Implemente o blueprint usando a base de exemplo do Terraform no GitHub.
• Saiba mais sobre os princípios de design de práticas recomendadas com o Framework de arquitetura do Google Cloud.

• Consulte a biblioteca de blueprints para acelerar o design e a criação de cargas de trabalho empresariais comuns, incluindo:

  • Importar dados do Google Cloud para um data warehouse seguro do BigQuery

  • Importar dados de uma rede externa para um data warehouse seguro do BigQuery

  • Implantar uma arquitetura sem servidor segura usando o Cloud Functions

  • Implantar uma arquitetura sem servidor segura usando o Cloud Run

• Confira soluções relacionadas para implantar no seu ambiente de base.

• Para acessar um ambiente de demonstração, entre em contato em [e-mail].