Migrar das chaves de conta de serviço

As chaves de conta de serviço são usadas com frequência para autenticação nos serviços do Google Cloud. No entanto, elas também podem ser um risco de segurança se não forem gerenciadas corretamente, aumentando sua vulnerabilidade a ameaças, como vazamento de credenciais, escalonamento de privilégios, divulgação de informações e não repúdio.

Em muitos casos, a autenticação é possível com alternativas mais seguras às chaves de conta de serviço. Neste guia, ajudamos você a migrar do uso de chaves de conta de serviço como principal mecanismo de autenticação para alternativas mais seguras, com exceções pontuais em que as chaves de conta de serviço são realmente necessárias.

Este documento é destinado a administradores de segurança que querem melhorar a postura de segurança reduzindo o uso de chaves de conta de serviço a favor de mecanismos de autenticação mais seguros. Esses administradores de segurança podem ser responsáveis pela segurança de cargas de trabalho de produção, fluxos de trabalho do desenvolvedor e processos internos que já existem e usam chaves de contas de serviço.

Visão geral

A remoção de chaves de contas de serviço das cargas de trabalho atuais requer um planejamento cuidadoso para evitar interrupções acidentais. O plano de migração a seguir foi projetado para permitir que você aplique controles centralizados e minimizem as interrupções para desenvolvedores.

Este plano de migração contém três fases:

Avaliar: nesta fase, você avalia o ambiente atual para entender onde existem chaves de conta de serviço e se elas estão em uso.
Planejar: nesta fase, você decide quais controles implantará por fim e comunica o plano de migração às partes interessadas.
Implantar: nessa fase, você começa a refatorar as cargas de trabalho para autenticação com alternativas mais seguras às chaves de conta de serviço. Você também cria outras capabilities para monitorar continuamente seu ambiente e reduzir riscos futuros.

Avaliar o uso de chaves de conta de serviço

Nesta fase, você avalia seu ambiente atual para entender onde estão as chaves de conta de serviço e se elas estão em uso.

As seções a seguir descrevem os dados que podem ser coletados para entender melhor como as chaves da conta de serviço são usadas na sua organização.

Coletar dados sobre o uso de chaves

Primeiro, identifique onde estão as chaves de conta de serviço e como elas são usadas.

O Google Cloud fornece ferramentas para entender o uso da conta de serviço. Essas ferramentas ajudam a determinar quais contas de serviço e chaves foram usadas recentemente para autenticação, quais contas de serviço não foram usadas nos últimos 90 dias e quais contas de serviço têm papéis com excesso de privilégios.

É possível combinar informações de todas essas ferramentas para entender melhor como as contas de serviço e as chaves são usadas em toda a organização. Para ver um exemplo de como combinar informações dessas várias fontes em toda a organização, consulte a arquitetura de referência implantável no GitHub. Essa arquitetura de referência agrega dados de várias ferramentas e os exporta regularmente para uma tabela do BigQuery para análise.

A arquitetura de referência implanta um pipeline de dados que consulta o Inventário de recursos do Cloud para identificar as chaves de conta de serviço na organização. Em seguida, o pipeline de dados combina esses dados com aqueles sobre o uso de chaves e de permissões da conta associada. A tabela resultante, sa_key_usage, ajuda a responder a perguntas como estas:

Quantas chaves permanentes foram criadas? Esse número pode ser útil como uma métrica de alto nível para acompanhar o progresso à medida que você deixa de usar as chaves.
Quais projetos e contas de serviço usam chaves? Essas informações ajudam você a identificar os proprietários das cargas de trabalho que usam chaves de conta de serviço.
Quais chaves estão inativas? Provavelmente, é possível excluir essas chaves sem avaliações adicionais dos proprietários das cargas de trabalho.
Quais chaves estão associadas a contas de serviço que têm recomendações sobre permissões em excesso? Se uma chave de conta de serviço estiver associada a uma conta de serviço com excesso de privilégios, especialmente uma com papel de Proprietário, Editor ou Leitor, a chave poderá ser de alto risco. Procurar contas de serviço que tenham recomendações de papéis pode ajudar a identificar quais contas de serviço têm excesso de privilégios. Depois de identificar essas contas de serviço, decida priorizar essas cargas de trabalho para migração. Também é possível aplicar as recomendações de papéis para reduzir proativamente o excesso de permissões.

Esse pipeline de dados é executado diariamente e grava em uma tabela do BigQuery particionada por data. Use essa tabela para investigar contas de serviço ou chaves específicas ou para acompanhar o progresso da correção usando uma ferramenta de painel como o Looker Studio.

Aprimorar os dados de uso de chaves com mais contexto

Depois de criar o conjunto de dados de uso de chaves, é possível estendê-lo com outras fontes de dados. Recomendamos adicionar fontes de dados que você já usa para rastrear a governança e a procedência dos recursos. Dependendo da sua governança atual, é possível adicionar outros dados, como estes:

Informações de propriedade de um banco de dados de gerenciamento de configuração (CMDB, na sigla em inglês) ou sistema semelhante.
Informações de governança configuradas em rótulos de projeto, como a equipe ou o centro de custos responsável por um projeto.
Informações do ambiente sobre chaves usadas para cargas de trabalho em ambientes fora do Google Cloud.

Criar um plano para reduzir o uso de chaves de conta de serviço

Antes de implantar qualquer alteração para reduzir o uso de chaves de conta de serviço, é preciso determinar quais cargas de trabalho e ambientes serão afetados e como você aplicará essas alterações. Você também precisa comunicar esse plano para toda a empresa e garantir que os proprietários das cargas de trabalho aceitem o plano.

As próximas seções apresentam os principais tópicos que seu plano precisa abordar. O plano específico varia de acordo com o tamanho da sua organização e os requisitos específicos das cargas de trabalho.

Decidir a responsabilidade dos proprietários das cargas de trabalho atuais

Uma equipe de segurança central pode avaliar quais chaves existem, mas uma migração bem-sucedida exige o esforço dos proprietários das cargas de trabalho. Para chaves no escopo da migração, os proprietários das cargas de trabalho precisam determinar quais dos métodos de autenticação disponíveis funcionarão para o caso de uso deles e, em seguida, executar essa migração.

Pense em como equilibrar as melhorias na sua postura de segurança atual com o esforço exigido dos proprietários das cargas de trabalho. Nas próximas seções, descrevemos dois exemplos de abordagem: uma que prioriza fortemente as melhorias na postura de segurança e outra que prioriza fortemente a minimização do esforço dos proprietários das cargas de trabalho. Sua abordagem real pode variar. Por exemplo, você pode decidir selecionar individualmente quais cargas de trabalho estarão no escopo.

Exemplo: todas as cargas de trabalho atuais são avaliadas para migração

Uma abordagem possível é aplicar controles de chaves de conta de serviço a todas as cargas de trabalho atuais e futuras. Isso envolve etapas como estas:

Colaborar com os proprietários das cargas de trabalho para avaliar o uso de chaves deles nas cargas de trabalho atuais.
Exigir que os proprietários das cargas de trabalho migrem todas as cargas de trabalho atuais com o uso de chaves, a menos que tenham recebido uma exceção.
Impedir que todas as cargas de trabalho futuras usem chaves de conta de serviço, a menos que tenham recebido uma exceção.

Essa abordagem prioriza melhorias na postura de segurança atual, mas exige mais esforço dos desenvolvedores e proprietários das cargas de trabalho a curto prazo. Para executar um plano como esse, é preciso ter o compromisso dos proprietários das cargas de trabalho em participar da revisão e refatoração da carga de trabalho.

Exemplo: nenhuma carga de trabalho atual é avaliada para migração

Outra abordagem é permitir que as cargas de trabalho atuais sejam uma exceção automática para continuar usando chaves de conta de serviço e aplicar novos controles apenas em cargas de trabalho futuras.

Essa abordagem melhora a postura de segurança de cargas de trabalho futuras e minimiza a responsabilidade dos proprietários das cargas de trabalho atual. No entanto, isso não melhora a postura de segurança das cargas de trabalho atuais.

Identificar ganhos rápidos

Na avaliação, identifique chaves que podem ser excluídas com segurança sem trabalho de correção extra dos proprietários das cargas de trabalho. Por exemplo, se uma chave ficar inativa por 90 dias ou estiver relacionada a recursos que não estão mais ativos, será possível removê-la com segurança sem precisar migrar para outro mecanismo de autenticação.

Faça uma lista de chaves que atendam a esses critérios. Use essa lista durante a fase de implantação para excluir chaves desnecessárias. Antes de adicionar uma chave à lista, confirme se há casos de uso que exigem a chave de conta de serviço com pouca frequência, como acesso de produção de emergência que depende de chaves de conta de serviço.

Planejar onde aplicar as alterações de políticas da organização

Para deixar de usar chaves de conta de serviço, é necessário impedir a criação de novas chaves. Durante a fase de implantação, você aplica a restrição de políticas da organização iam.disableServiceAccountKeyCreation para impedir a criação de novas chaves de conta de serviço.

Essa restrição não impede o uso das chaves que já existem, mas pode interromper as cargas de trabalho atuais que fazem a rotação das chaves regularmente. Antes de iniciar a fase de implantação, decida onde ela será aplicada na hierarquia de recursos para minimizar a interrupção.

Talvez você prefira aplicar a restrição inicialmente no nível do projeto ou da pasta no lugar do nível da organização. Por exemplo, você pode aplicar a restrição na pasta usada para o ambiente de desenvolvimento antes de implantá-la em pastas de produção. Ou, em uma organização de grande porte com muitas equipes, você pode aplicar a restrição em uma pasta para uma única equipe primeiro e, em seguida, aplicar a restrição a outras pastas à medida que você as migra.

É possível usar políticas da organização com tags para aplicar condicionalmente as políticas da organização no nível do projeto ou da pasta.

Desenvolver um processo de exceções

O objetivo dessa migração é reduzir ou eliminar o uso de chaves de conta de serviço, mas há alguns casos de uso legítimos que exigem essas chaves. Mesmo que nenhuma carga de trabalho atual exija chaves de conta de serviço, é possível que as futuras cargas de trabalho exijam. Portanto, é preciso definir um processo operacional para avaliar e aprovar exceções em casos de uso que exigem chaves de conta de serviço.

Defina um processo para que os proprietários das cargas de trabalho solicitem uma exceção que permita que a carga de trabalho use chaves de conta de serviço. Verifique se os tomadores de decisões responsáveis por conceder uma exceção têm o conhecimento técnico para validar o caso de uso, consulte os proprietários das cargas de trabalho sobre quais alternativas mais seguras às chaves de conta de serviço podem ser mais apropriadas e oriente-os sobre as práticas recomendadas para gerenciar chaves de conta de serviço.

Comunicar as próximas alterações aos proprietários das cargas de trabalho

Depois de elaborar um plano, você precisa comunicá-lo com clareza em toda a organização e garantir que as partes interessadas, principalmente os líderes seniores, estejam dispostas a se comprometer com a migração.

Os detalhes específicos da migração variam de acordo com a organização, mas considere a inclusão dos tópicos a seguir no seu plano de comunicação:

O impacto negativo que as chaves de conta de serviço não seguras podem ter sobre a organização e as motivações que levam à migração das chaves de conta de serviço.
Os novos controles de segurança para impedir a criação de chaves de conta de serviço e como isso pode afetar os processos atuais.
Orientação para desenvolvedores identificarem alternativas mais seguras às chaves de conta de serviço.
O processo para que as equipes solicitem uma exceção para permitir chaves de conta de serviço, incluindo a frequência com que essa exceção é reavaliada.
O cronograma para aplicar as alterações propostas.

Trabalhe com proprietários de carga de trabalho para refinar seu plano e garantir que ele funcione em toda a organização.

Implantar controles e refatorar cargas de trabalho

Depois de criar um plano e comunicá-lo aos proprietários das cargas de trabalho, comece a migrar das chaves de conta de serviço.

Nesta fase, você começa a refatorar as cargas de trabalho para autenticação com alternativas mais seguras às chaves de conta de serviço. Você também cria outras capabilities para monitorar continuamente seu ambiente e reduzir riscos futuros.

Nas próximas seções, descrevemos as etapas para refatorar cargas de trabalho e excluir chaves com o mínimo de interrupção. É possível seguir essas etapas em qualquer ordem, com base na prioridade e no esforço necessários para sua organização.

Aplicar controles para interromper a criação de novas chaves de conta de serviço

Para interromper a criação de novas chaves de conta de serviço, aplique a restrição de políticas da organização iam.disableServiceAccountKeyCreation.

No entanto, antes de aplicar essa restrição, é preciso adicionar tags a todos os projetos ou pastas que serão isentos da política. Você pode permitir exceções para as cargas de trabalho atuais que não conseguem migrar das chaves de conta de serviço ou para novas cargas de trabalho que tenham um motivo legítimo para autenticação apenas com chaves de conta de serviço.

Depois de adicionar tags para isentar projetos e pastas, defina uma política da organização com tags para aplicar a restrição iam.disableServiceAccountKeyCreation a projetos e pastas sem isenção.

Para impedir a criação de chaves de conta de serviço em todos os projetos e pastas sem isenção, faça isto:

Verifique se você tem os papéis do IAM necessários para administrar tags e administrar políticas da organização no nível da organização.
No nível da organização, crie uma chave de tag e um valor de tag que serão usados para definir se um projeto ou uma pasta será isento da política da organização. Recomendamos criar uma tag com a chave disableServiceAccountKeyCreation e os valores enforced e not_enforced.

Para saber como criar chaves e valores de tag, consulte Como criar e definir uma nova tag.
Anexe a tag disableServiceAccountKeyCreation à organização e defina o valor como enforced. Todos os projetos ou pastas da organização herdam esse valor de tag, a menos que ele seja substituído por um valor de tag diferente.

Para saber como anexar tags aos recursos, consulte Como anexar tags aos recursos.
Para cada projeto ou pasta que você quer isentar da política da organização, anexe a tag disableServiceAccountKeyCreation e defina-a com o valor not_enforced. Definir um valor de tag para um projeto ou uma pasta dessa maneira substitui o valor da tag herdado da organização.
Crie uma política da organização que impeça a criação de chaves de conta de serviço para todos os recursos, exceto aqueles isentos. Essa política precisa ter as seguintes regras:
- Configure a restrição iam.disableServiceAccountKeyCreation para que não seja aplicada aos recursos com a tag disableServiceAccountKeyCreation: not_enforced. A condição nessa regra precisa ser semelhante a esta:
```
resource.matchTag(\"ORGANIZATION_ID/disableServiceAccountKeyCreation\", \"not_enforced\")
```
- Configure a restrição iam.disableServiceAccountKeyCreation para que seja aplicada a todos os outros recursos.
Para saber como criar políticas da organização com condições de tag, consulte Como definir uma política da organização com tags.

Corrigir cargas de trabalho atuais

Para cada carga de trabalho que usa chaves de conta de serviço, colabore com os proprietários das cargas de trabalho para escolher e implementar um método de autenticação alternativo.

Quando você acessa os serviços do Google Cloud usando a CLI do Google Cloud, as bibliotecas de cliente do Cloud, ferramentas compatíveis com Application Default Credentials (ADC), como Terraform ou REST solicitações, use o diagrama a seguir para escolher um método de autenticação:

Árvore de decisão para escolher o método de autenticação com base no caso de uso

Este diagrama orienta você nas seguintes perguntas:

Você está executando o código em um ambiente de desenvolvimento de usuário único, como sua própria estação de trabalho, o Cloud Shell ou uma interface de área de trabalho virtual?
1. Se sim, prossiga para a pergunta 4.
2. Caso contrário, prossiga para a pergunta 2.
Você está executando o código no Google Cloud?
1. Se sim, prossiga para a pergunta 3.
2. Caso contrário, prossiga para a pergunta 5.
Você está executando contêineres no Google Kubernetes Engine ou no GKE Enterprise?
1. Em caso afirmativo, use a federação de identidade da carga de trabalho para GKE para anexar contas de serviço aos pods do Kubernetes.
2. Caso contrário, anexe uma conta de serviço ao recurso.
Seu caso de uso requer uma conta de serviço?

Por exemplo, você quer configurar a autenticação e a autorização de maneira consistente para seu aplicativo em todos os ambientes.
1. Caso contrário, faça a autenticação com credenciais de usuário.
2. Se for o caso, represente uma conta de serviço com credenciais de usuário.
Sua carga de trabalho é autenticada com um provedor de identidade externo compatível com a federação de identidade da carga de trabalho?
1. Em caso afirmativo, configure a federação de identidade da carga de trabalho para permitir que os aplicativos em execução no local ou em outros provedores de nuvem usem uma conta de serviço.
2. Caso contrário, crie uma chave da conta de serviço.

Em alguns casos, talvez não seja possível usar um método de autenticação além das chaves de conta de serviço. Confira os exemplos a seguir em que uma chave de conta de serviço pode ser sua única opção viável:

Você usa produtos comerciais prontos para uso (COTS, na sigla em inglês) ou aplicativos de software como serviço (SaaS) que solicitam a inserção de uma chave de conta de serviço do Google Cloud diretamente na interface do usuário.
Sua carga de trabalho é executada fora do Google Cloud e não é autenticada com um provedor de identidade compatível com a federação de identidade da carga de trabalho.

Nos casos em que você precisa continuar usando chaves de conta de serviço, siga as práticas recomendadas para gerenciar chaves de conta de serviço.

Você pode decidir também não corrigir determinadas cargas de trabalho porque avalia que o risco de continuar usando as chaves de conta de serviço não justifica o custo de mudar para um método de autenticação diferente.

Excluir chaves desnecessárias

Se você tiver certeza de que a chave de conta de serviço não é necessária, exclua-a. Confira algumas chaves desnecessárias:

Chaves sem uso recente ou chaves relacionadas a recursos não utilizados, que você identificou na seção Identificar ganhos rápidos desta página.
Chaves para cargas de trabalho que foram migradas para outros métodos de autenticação.

Depois de excluir todas as chaves de conta de serviço em um projeto, verifique se a restrição iam.disableServiceAccountKeyCreation foi aplicada a ele. Se o projeto estava isento dessa restrição, remova a tag que permitiu a isenção.

Para excluir as chaves de maneira segura, recomendamos desativar a chave antes de excluí-la. A exclusão é irreversível, mas desativá-la permite reativar rapidamente a chave se você identificar problemas inesperados. Depois de desativar a chave, aguarde até ter certeza de que a remoção permanente não causará problemas e depois exclua a chave. Depois de desativar a chave, se você identificar problemas inesperados, reative-a, resolva os problemas e repita o processo até que seja possível excluí-la com segurança.

Usar controles integrados para ajudar a responder ao vazamento de chaves

O Google Cloud oferece várias ferramentas e serviços para ajudar a detectar e responder ao vazamento de chaves de conta de serviço. Use os mecanismos a seguir para ajudar a responder ao vazamento de chaves de conta de serviço:

Ative a Detecção de anomalias do Security Command Center para verificar repositórios públicos em busca de chaves. Essa verificação criará uma descoberta account_has_leaked_credentials se um vazamento de chaves for detectado.
Analise o Programa de proteção contra mineração de criptomoedas do Security Command Center e verifique se você atende aos pré-requisitos técnicos de qualificação. O abuso de mineração de criptomoedas é um exploit comum quando há vazamento de credenciais.
Configure os Contatos essenciais para que a equipe de segurança receba notificações do Google Cloud, incluindo abusos resultantes de chaves comprometidas. Verifique se o endereço de e-mail é monitorado e não depende de usuários individuais como um ponto único de falha.

Para saber mais sobre a gestão de incidentes, consulte Criar um processo colaborativo de gestão de incidentes.

Melhorias contínuas no gerenciamento de contas de serviço

Sempre que possível, implemente as práticas recomendadas para gerenciar chaves de conta de serviço. Melhorar os processos de gerenciamento de chaves pode diminuir o risco de chaves de conta de serviço restantes na organização.