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-accountinicial 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
billingcodeusado 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.
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 dana@example.com para uso diário e admin-dana@example.com 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).