Esta página foi traduzida pela API Cloud Translation.

Práticas recomendadas de operações

Last reviewed 2025-05-15 UTC

Esta secção apresenta operações que tem de considerar à medida que implementa e opera cargas de trabalho adicionais no seu ambiente Google Cloud . Esta secção não se destina a ser exaustiva de todas as operações no seu ambiente de nuvem, mas apresenta decisões relacionadas com as recomendações arquitetónicas e os recursos implementados pelo projeto.

Atualize os recursos básicos

Embora o projeto forneça um ponto de partida com opiniões para o seu ambiente de base, os requisitos da base podem aumentar ao longo do tempo. Após a implementação inicial, pode ajustar as definições de configuração ou criar novos serviços partilhados para serem consumidos por todas as cargas de trabalho.

Para modificar recursos básicos, recomendamos que faça todas as alterações através do pipeline básico. Reveja a estratégia de ramificação para uma introdução ao fluxo de escrita de código, à respetiva união e ao acionamento dos pipelines de implementação.

Decida os atributos para novos projetos de carga de trabalho

Quando cria novos projetos através do módulo de fábrica de projetos do pipeline de automatização, tem de configurar vários atributos. O seu processo de conceção e criação de projetos para novas cargas de trabalho deve incluir decisões para o seguinte:

Que APIs Google Cloud ativar
Que VPC partilhada usar ou se deve criar uma nova rede VPC
Que funções de IAM criar para o project-service-account inicial que é criado pelo pipeline
Que etiquetas de projeto aplicar
A pasta para a qual o projeto é implementado
Que conta de faturação usar
Se deve adicionar o projeto a um perímetro do VPC Service Controls
Se deve configurar um orçamento e um limite de alerta de faturação para o projeto

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

Faça a gestão das autorizações em grande escala

Quando implementa projetos de carga de trabalho na sua base, tem de considerar como vai conceder acesso aos programadores e consumidores pretendidos desses projetos. Recomendamos que adicione utilizadores a um grupo gerido pelo seu fornecedor de identidade existente, sincronize os grupos com o Cloud ID e, em seguida, aplique funções de IAM aos grupos. Tenha sempre em atenção o princípio do menor privilégio.

Também recomendamos que use o recomendador do IAM para identificar políticas de autorização que concedem funções com privilégios excessivos. Conceba um processo para rever periodicamente as recomendações ou aplicar automaticamente as recomendações nas suas linhas de implementação.

Coordenar as alterações entre a equipa de rede e a equipa de aplicações

As topologias de rede implementadas pela planta pressupõem que tem uma equipa responsável pela gestão dos recursos de rede e equipas separadas responsáveis pela implementação dos recursos de infraestrutura de cargas de trabalho. À medida que as equipas de cargas de trabalho implementam a infraestrutura, têm de criar regras de firewall para permitir os caminhos de acesso pretendidos entre os componentes da respetiva carga de trabalho, mas não têm autorização para modificar as próprias políticas de firewall de rede.

Planeie como as equipas vão trabalhar em conjunto para coordenar as alterações aos recursos de rede centralizados necessários para implementar aplicações. Por exemplo, pode criar um processo em que uma equipa de carga de trabalho pede etiquetas para as respetivas aplicações. Em seguida, a equipa de rede cria as etiquetas e adiciona regras à política da firewall de rede que permitem o fluxo de tráfego entre recursos com as etiquetas, e delega as funções do IAM para usar as etiquetas à equipa de carga de trabalho.

Otimize o seu ambiente com o portefólio do Active Assist

Além do recomendador de IAM, Google Cloud fornece o portefólio de serviços do Active Assist para fazer recomendações sobre como otimizar o seu ambiente. Por exemplo, as estatísticas da firewall ou o recomendador de projetos não supervisionados fornecem recomendações acionáveis que podem ajudar a reforçar a sua postura de segurança.

Conceba um processo para rever periodicamente as recomendações ou aplicar automaticamente recomendações nas suas linhas de implementação. Decida que recomendações devem ser geridas por uma equipa central e quais devem ser da responsabilidade dos proprietários das cargas de trabalho e aplique as funções de IAM para aceder às recomendações em conformidade.

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

O projeto base aplica um conjunto de restrições de políticas da organização que são recomendadas à maioria dos clientes na maioria dos cenários, mas pode ter exemplos de utilização legítimos que exijam exceções limitadas às políticas da organização que aplica de forma geral.

Por exemplo, o projeto impõe a restrição iam.disableServiceAccountKeyCreation. Esta restrição é um controlo de segurança importante porque uma chave de conta de serviço roubada pode ter um impacto negativo significativo, e a maioria dos cenários deve usar alternativas mais seguras às chaves de conta de serviço para autenticar. No entanto, podem existir exemplos de utilização que só podem ser autenticados com uma chave de conta de serviço, como um servidor no local que requer acesso a serviços e não pode usar a federação de identidades da carga de trabalho.Google Cloud Neste cenário, pode decidir permitir uma exceção à política, desde que sejam aplicados controlos de compensação adicionais, como práticas recomendadas para gerir chaves de contas de serviços.

Por conseguinte, deve criar um processo para que as cargas de trabalho peçam uma exceção às políticas e garantir que os decisores responsáveis por conceder exceções têm os conhecimentos técnicos para validar o exemplo de utilização e consultar se têm de ser implementados controlos adicionais para compensar. Quando concede 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 pode adicionar condicionalmente restrições a uma política da organização definindo uma etiqueta que conceda uma exceção ou uma aplicação para a política e, em seguida, aplicando a etiqueta a projetos e pastas.

Proteja os seus recursos com os VPC Service Controls

O projeto ajuda a preparar o seu ambiente para o VPC Service Controls aplicando configurações de pré-requisitos, como o VIP restrito. No entanto, o projeto inicial implementa o VPC Service Controls apenas no modo de teste , porque a mudança para o modo aplicado pode ser um processo disruptivo que requer planeamento exclusivo para a sua organização.

Um perímetro nega o acesso a serviços Google Cloud restritos a partir de tráfego que se origina fora do perímetro, o que inclui a consola, as estações de trabalho dos programadores e o pipeline de base usado para implementar recursos. Se usar os VPC Service Controls, tem de criar exceções ao perímetro que permitam os caminhos de acesso pretendidos.

Um perímetro do VPC Service Controls destina-se a controlos de exfiltração entre a sua Google Cloud organização e fontes externas. O perímetro não se destina a substituir nem duplicar políticas de permissão para o controlo de acesso detalhado a projetos ou recursos individuais. Quando concebe e cria uma arquitetura de um perímetro, recomendamos que use um perímetro unificado comum para reduzir os custos de gestão.

Se tiver de conceber vários perímetros para controlar detalhadamente o tráfego de serviços na sua organização, recomendamos que defina claramente as ameaças que são abordadas por uma estrutura de perímetro mais complexa e os caminhos de acesso entre perímetros necessários para as operações pretendidas. Google Cloud

Para adotar os VPC Service Controls, avalie o seguinte:

Quais dos seus exemplos de utilização requerem os VPC Service Controls.
Se os Google Cloud serviçosnecessários suportam osVPC Service Controls.
Como configurar o acesso de emergência para modificar o perímetro caso este interrompa os seus pipelines de automação.
Como usar as práticas recomendadas para ativar o VPC Service Controls para conceber e implementar o seu perímetro.

Depois de alterar o perímetro do modo de teste para o modo aplicado, recomendamos que crie um processo para adicionar consistentemente novos projetos ao perímetro correto e um processo para criar exceções quando os programadores tiverem um novo exemplo de utilização que seja recusado pela configuração do perímetro atual.

Teste alterações ao nível da organização numa organização separada

Recomendamos que nunca implemente alterações na produção sem as testar. Para os recursos de carga de trabalho, esta 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 os testes.

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

Controle o acesso remoto a máquinas virtuais

Como recomendamos que implemente uma infraestrutura imutável através do pipeline de base, do pipeline de infraestrutura e do pipeline de aplicações, também recomendamos que conceda aos programadores acesso direto a uma máquina virtual através de SSH ou RDP apenas para exemplos de utilização limitados ou excecionais.

Para cenários que requerem acesso remoto, recomendamos que faça a gestão do acesso dos utilizadores através do início de sessão no SO sempre que possível. Esta abordagem usa serviços Google Cloud geridos para aplicar o controlo de acesso, a gestão do ciclo de vida da conta, a validação em dois passos e o registo de auditoria. Em alternativa, se tiver de permitir o acesso através de chaves SSH nos metadados ou credenciais RDP, é da sua responsabilidade gerir o ciclo de vida das credenciais e armazená-las em segurança fora do Google Cloud.

Em qualquer cenário, um utilizador com acesso SSH ou RDP a uma VM pode ser um risco de escalada de privilégios, pelo que deve conceber o seu modelo de acesso tendo isto em mente. O utilizador pode executar 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 pedidos de API. Este acesso pode, então, ser uma escalada de privilégios se não tiver a intenção deliberada de que o utilizador opere com os privilégios da conta de serviço.

Mitigue os gastos excessivos planeando alertas de orçamento

O plano detalhado implementa práticas recomendadas introduzidas na Google Cloud Well-Architected Framework: Cost Optimization para gerir os custos, incluindo o seguinte:

Use uma única conta de faturação em todos os projetos da base empresarial.
Atribua a cada projeto uma etiqueta de metadados billingcode que é usada para atribuir o custo entre os centros de custos.
Defina orçamentos e limites de alerta.

É da sua responsabilidade planear orçamentos e configurar alertas de faturação. O esquema cria alertas de orçamento para projetos de carga de trabalho quando a previsão de gastos está a caminho de atingir 120% do orçamento. Esta abordagem permite que uma equipa central identifique e mitigue incidentes de gastos excessivos significativos. Aumentos inesperados significativos nos gastos sem uma causa clara podem ser um indicador de um incidente de segurança e devem ser investigados do ponto de vista do controlo de custos e da segurança.

Consoante o seu exemplo de utilização, pode definir um orçamento com base no custo de uma pasta de ambiente inteira ou de todos os projetos relacionados com um determinado centro de custos, em vez de definir orçamentos detalhados para cada projeto. Também recomendamos que delegue a definição de orçamentos e alertas aos proprietários das cargas de trabalho que podem definir um limite de alerta mais detalhado para a respetiva monitorização diária.

Para ver orientações sobre a otimização de custos, consulte o artigo Otimize os custos com o hub do FinOps.

Atribua custos entre centros de custos internos

A consola permite-lhe ver os relatórios de faturação para ver e prever o custo em várias dimensões. Além dos relatórios pré-criados, recomendamos que exporte os dados de faturação para um conjunto de dados do BigQuery no projeto do prj-c-billing-export. Os registos de faturação exportados permitem-lhe atribuir custos a dimensões personalizadas, como os seus centros de custos internos, com base em metadados de etiquetas de projetos, como billingcode.

A seguinte consulta SQL é uma consulta de exemplo para compreender os custos de todos os projetos que estão agrupados pela etiqueta do projeto 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 esta exportação, consulte o artigo Exporte dados de faturação do Google Cloud para o BigQuery.

Se precisar de contabilidade interna ou de estornos entre centros de custos, é da sua responsabilidade incorporar os dados obtidos a partir desta consulta nos seus processos internos.

Carregue resultados dos controlos de deteção no seu SIEM existente

Embora os recursos básicos ajudem a configurar destinos agregados para registos de auditoria e conclusões de segurança, é da sua responsabilidade decidir como consumir e usar estes sinais.

Se tiver um requisito para agregar registos em todos os ambientes na nuvem e no local num SIEM existente, decida como ingerir registos do projeto prj-c-logging e conclusões do Security Command Center nas suas ferramentas e processos existentes. Pode criar uma única exportação para todos os registos e resultados se uma única equipa for responsável pela monitorização da segurança em todo o seu ambiente, ou pode criar várias exportações filtradas para o conjunto de registos e resultados necessários para várias equipas com responsabilidades diferentes.

Em alternativa, se o volume e o custo dos registos forem proibitivos, pode evitar a duplicação retendo os registos e as conclusões apenas no Google Cloud .Google CloudNeste cenário, certifique-se de que as suas equipas existentes têm o acesso e a formação adequados para trabalhar com registos e resultados diretamente noGoogle Cloud.

Para registos de auditoria, crie visualizações de registos para conceder acesso a um subconjunto de registos no seu contentor de registos centralizado a equipas individuais, em vez de duplicar registos em vários contentores, o que aumenta o custo de armazenamento de registos.
Para conclusões de segurança, conceda funções ao nível da pasta e do projeto para que o Security Command Center permita que as equipas vejam e geram conclusões de segurança apenas para os projetos pelos quais são responsáveis, diretamente na consola.

Desenvolva continuamente a sua biblioteca de controlos

O projeto começa com uma base de controlos para detetar e impedir ameaças. Recomendamos que reveja estes controlos e adicione controlos adicionais com base nos seus requisitos. A tabela que se segue resume os mecanismos para aplicar políticas de governação e como os pode expandir para os seus requisitos adicionais:

Controlos de políticas aplicados pelo projeto	Orientações para expandir estes controlos
O Security Command Center deteta vulnerabilidades e ameaças de várias origens de segurança.	Defina módulos personalizados para o Security Health Analytics e módulos personalizados para a Deteção de ameaças de eventos.
O serviço de políticas da organização aplica um conjunto recomendado de restrições de políticas da organização aosGoogle Cloud serviços.	Aplique restrições adicionais a partir da lista predefinida de restrições disponíveis ou crie restrições personalizadas.
O agente de políticas Open (OPA) valida o código no pipeline de base para configurações aceitáveis antes da implementação.	Desenvolva restrições adicionais com base nas orientações em GoogleCloudPlatform/policy-library.
Os alertas nas métricas baseadas em registos e nas métricas de desempenho configuram métricas baseadas em registos para alertar sobre alterações às políticas IAM e às configurações de alguns recursos sensíveis.	Conceba métricas baseadas em registos adicionais e políticas de alerta para eventos de registo que espera que não ocorram no seu ambiente.
Uma solução personalizada para a análise automatizada de registos consulta regularmente os registos para verificar a existência de atividade suspeita e cria resultados do Centro de comandos de segurança.	Escreva consultas adicionais para criar resultados para eventos de segurança que quer monitorizar, usando as estatísticas dos registos de segurança como referência.
Uma solução personalizada para responder a alterações de recursos cria resultados do Security Command Center e pode automatizar ações de remediação.	Crie feeds adicionais do inventário de recursos da nuvem para monitorizar alterações de tipos de recursos específicos e escreva funções adicionais do Cloud Run com lógica personalizada para responder a violações de políticas.

Estes controlos podem evoluir à medida que os seus requisitos e maturidade na Google Cloud mudam.

Faça a gestão das chaves de encriptação com o Cloud Key Management Service

Google Cloud oferece encriptação predefinida em repouso para todo o conteúdo do cliente, mas também oferece o Cloud Key Management Service (Cloud KMS) para lhe dar controlo adicional sobre as chaves de encriptação dos dados em repouso. Recomendamos que avalie se a encriptação predefinida é suficiente ou se tem um requisito de conformidade que exige que use o Cloud KMS para gerir as chaves. Para mais informações, consulte o artigo decida como cumprir os requisitos de conformidade para a encriptação em repouso.

O projeto fornece um projeto prj-c-kms na pasta comum e um projeto prj-{env}-kms em cada pasta de ambiente para gerir as chaves de encriptação de forma centralizada. Esta abordagem permite que uma equipa central audite e faça a gestão das chaves de encriptação usadas por recursos em projetos de cargas de trabalho, de modo a cumprir os requisitos regulamentares e de conformidade.

Consoante o seu modelo operacional, pode preferir uma única instância de projeto centralizada do Cloud KMS sob o controlo de uma única equipa, pode preferir gerir as chaves de encriptação separadamente em cada ambiente ou pode preferir várias instâncias distribuídas para que a responsabilidade pelas chaves de encriptação possa ser delegada nas equipas adequadas. Modifique o exemplo de código do Terraform conforme necessário para se adequar ao seu modelo operacional.

Opcionalmente, pode aplicar políticas da organização de chaves de encriptação geridas pelo cliente (CMEK) para aplicar que determinados tipos de recursos requerem sempre uma chave CMEK e que só podem ser usadas chaves CMEK de uma lista de autorizações de projetos fidedignos.

Armazene e audite credenciais de aplicações com o Secret Manager

Recomendamos que nunca confirme segredos confidenciais (como chaves da API, palavras-passe e certificados privados) em repositórios de código fonte. Em alternativa, comprometa o segredo com o Secret Manager e conceda a função de IAM Secret Manager Secret Accessor ao utilizador ou à conta de serviço que precisa de aceder ao segredo. Recomendamos que conceda a função do IAM a um segredo individual e não a todos os segredos no projeto.

Sempre que possível, deve gerar segredos de produção automaticamente nos pipelines de CI/CD e mantê-los inacessíveis aos utilizadores humanos, exceto em situações de emergência. Neste cenário, certifique-se de que não concede funções do IAM para ver estes segredos a utilizadores ou grupos.

O projeto fornece um projeto prj-c-secrets na pasta comum e um projeto prj-{env}-secrets em cada pasta de ambiente para gerir segredos de forma centralizada. Esta abordagem permite que uma equipa central audite e faça a gestão de segredos usados por aplicações para cumprir os requisitos regulamentares e de conformidade.

Consoante o seu modelo operacional, pode preferir uma única instância centralizada do Secret Manager sob o controlo de uma única equipa ou pode preferir gerir segredos separadamente em cada ambiente, ou pode preferir várias instâncias distribuídas do Secret Manager para que cada equipa de carga de trabalho possa gerir os seus próprios segredos. Modifique o exemplo de código do Terraform conforme necessário para se adequar ao seu modelo operacional.

Planeie o acesso de emergência a contas com privilégios elevados

Embora recomendemos que as alterações aos recursos básicos sejam geridas através de IaC com controlo de versões implementado pelo pipeline básico, pode haver cenários excecionais ou de emergência que exijam acesso privilegiado para modificar o seu ambiente diretamente. Recomendamos que planeie contas de acesso de emergência (por vezes, denominadas contas de chamada de incêndio ou de emergência) que tenham acesso altamente privilegiado ao seu ambiente em caso de emergência ou quando os processos de automatização falham.

A tabela seguinte descreve alguns exemplos de finalidades das contas de acesso de emergência.

Finalidade do plano de último recurso	Descrição
Superadministrador	Acesso de emergência à função de superadministrador usada com o Cloud ID, por exemplo, para corrigir problemas relacionados com a federação de identidades ou a autenticação multifator (MFA).
Administrador da organização	Acesso de emergência à função de administrador da organização, que pode conceder acesso a qualquer outra função do IAM na organização.
Administrador da pipeline de fundação	Acesso de emergência para modificar os recursos no seu projeto de CICD noGoogle Cloud e no repositório Git externo, caso a automatização do pipeline de base deixe de funcionar.
Operações ou SRE	Uma equipa de operações ou SRE precisa de acesso privilegiado para responder a interrupções ou incidentes. Isto pode incluir tarefas como reiniciar VMs ou restaurar dados.

O seu mecanismo para permitir o acesso de emergência depende das ferramentas e dos procedimentos existentes que tem em vigor, mas alguns exemplos de mecanismos incluem o seguinte:

Use as suas ferramentas existentes para a gestão de acesso privilegiado para adicionar temporariamente um utilizador a um grupo predefinido com funções IAM altamente privilegiadas ou use as credenciais de uma conta altamente privilegiada.
Aprovisione previamente contas destinadas apenas à utilização por parte do administrador. Por exemplo, o programador Dana pode ter uma identidade dana@example.com para utilização diária e admin-dana@example.com para acesso de emergência.
Use uma aplicação como o acesso privilegiado just-in-time que permite a um programador aumentar os privilégios para funções mais privilegiadas.

Independentemente do mecanismo que usar, considere como aborda operacionalmente as seguintes questões:

Como concebe o âmbito e a granularidade do acesso de emergência? Por exemplo, pode conceber um mecanismo de acesso de emergência diferente para diferentes unidades de negócio para garantir que não se prejudicam mutuamente.
Como é que o seu mecanismo impede o abuso? Precisa de aprovações? Por exemplo, pode ter operações divididas em que uma pessoa detém as credenciais e outra pessoa detém o token de AFA.
Como faz auditorias e envia alertas sobre o acesso de emergência? Por exemplo, pode configurar um módulo de deteção de ameaças de eventos personalizado para criar uma descoberta de segurança quando é usada uma conta de acesso de emergência predefinida.
Como remove o acesso de emergência e retoma as operações normais após o incidente terminar?

Para tarefas comuns de escalamento de privilégios e reversão de alterações, recomendamos que crie fluxos de trabalho automatizados em que um utilizador possa realizar a operação sem necessitar de escalamento de privilégios para a respetiva identidade de utilizador. Esta abordagem pode ajudar a reduzir os erros humanos e melhorar a segurança.

Para sistemas que requerem intervenção regular, a automatização da correção pode ser a melhor solução. A Google incentiva os clientes a adotarem uma abordagem de produção sem intervenção humana para fazerem todas as alterações de produção através da automatização, de proxies seguros ou de acesso de emergência auditado. A Google disponibiliza os livros de EFS para os clientes que pretendem adotar a abordagem de EFS da Google.

O que se segue?

Leia o artigo Implemente o plano detalhado (o documento seguinte desta série).