Práticas recomendadas para trabalhar com contas de serviço

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

As contas de serviço representam usuários não humanos. Elas são destinadas a cenários em que uma carga de trabalho, como um aplicativo personalizado, precisa acessar recursos ou executar ações sem o envolvimento do usuário final.

As contas de serviço diferem das contas de usuário normais de várias maneiras:

  • Elas não têm senha e não podem ser usadas para fazer login pelo navegador.
  • Elas são criadas e gerenciadas como um recurso que pertence a um projeto do Google Cloud. Por outro lado, os usuários são gerenciados em uma conta do Cloud Identity ou do Google Workspace.
  • Elas são específicas do Google Cloud. Por outro lado, os usuários gerenciados no Cloud Identity ou no Google Workspace trabalham em uma grande variedade de produtos e serviços do Google.
  • Elas são recursos e principais:
    • Como principal, uma conta de serviço pode receber acesso a recursos, como um bucket do Cloud Storage.
    • Como recurso, uma conta de serviço pode ser acessada e possivelmente personificada por outros principais, como um usuário ou grupo.

As contas de serviço são uma ferramenta útil, mas há várias formas de abuso de uma conta de serviço:

  • Encaminhamento de privilégios: um usuário de má-fé pode ter acesso a recursos que, de outra forma, não teria acesso personificando a conta de serviço.
  • Spoofing: um usuário de má-fé pode usar a personificação da conta de serviço para ocultar a identidade.
  • Não repúdio: um usuário de má-fé pode ocultar identidade e ações usando uma conta de serviço para realizar operações em nome dele. Em alguns casos, talvez não seja possível rastrear essas ações do usuário de má-fé.
  • Divulgação de informações: um usuário de má-fé pode receber informações sobre sua infraestrutura, aplicativos ou processos a partir da existência de determinadas contas de serviço.

Para proteger as contas de serviço, considere a natureza dupla delas:

  • Como a conta de serviço é um principal, você precisa limitar os privilégios dela para reduzir o possível dano que pode ser feito por uma conta de serviço comprometida.
  • Como a conta é um recurso, você precisa protegê-la contra comprometimento.

Este guia apresenta as práticas recomendadas para gerenciar, usar e proteger contas de serviço.

Escolher quando usar as contas de serviço

As contas de serviço fornecem uma identidade para aplicativos autônomos, como jobs em lote, processos de worker que enviam mensagens em uma fila ou agentes de monitoramento de recursos. Ao usar uma conta de serviço, você permite que esses aplicativos sejam executados sem a interação do usuário. Além disso, se o aplicativo acessar um recurso, é possível usar os Registros de auditoria do Cloud para rastrear esse acesso até a conta de serviço que o aplicativo usa.

As contas de serviço também são úteis para aplicativos em que um usuário faz a autenticação com um esquema de autenticação personalizado e acessa indiretamente os recursos do Google Cloud. Esses aplicativos podem confirmar que o usuário está autenticado e autorizado e, em seguida, usar uma conta de serviço para autenticar nos serviços do Google Cloud e acessar recursos. Para ajudar a rastrear esse acesso ao usuário, o aplicativo pode gravar uma entrada de registro personalizada sempre que um usuário acessar um recurso e você pode correlacionar as entradas de registro personalizadas com os registros de auditoria do Cloud.

Ao contrário dos usuários, as contas de serviço não podem se autenticar fazendo login com uma senha ou com Logon único (SSO). Elas aceitam um conjunto diferente de métodos de autenticação. Veja nas seções a seguir como escolher entre elas. Você também pode usar o diagrama a seguir para ajudar a escolher um método de autenticação:

Como usar contas de serviço

Veja na seção a seguir as práticas recomendadas para escolher quando e como usar as contas de serviço.

Use contas de serviço anexadas quando possível

Para permitir que um aplicativo implantado no Google Cloud use uma conta de serviço, anexe a conta de serviço ao recurso de computação subjacente. Ao anexar a conta de serviço, você permite que o aplicativo consiga tokens para a conta de serviço e use-os para acessar as APIs e os recursos do Google Cloud.

Para receber tokens de acesso no aplicativo, use as bibliotecas de cliente, se possível. As bibliotecas de cliente usam o Application Default Credentials (ADC) para encontrar automaticamente as credenciais anexadas e adquirir tokens de acesso para o aplicativo.

Em situações em que o uso das bibliotecas de cliente não é prático, ajuste seu aplicativo para receber tokens de maneira programática a partir do servidor de metadados. Os recursos de computação compatíveis com o acesso ao servidor de metadados incluem:

Para ver a lista completa dos recursos de computação que permitem anexar uma conta de serviço, consulte Como gerenciar a personificação da conta de serviço.

Use a Identidade da carga de trabalho para anexar contas de serviço aos pods do Kubernetes

Se você usa o Google Kubernetes Engine, pode ser que esteja executando uma combinação de diferentes aplicativos em um único cluster do GKE. Os aplicativos individuais provavelmente serão diferentes nos recursos e nas APIs que precisam acessar.

Se você anexar uma conta de serviço a um cluster do GKE ou a um dos pools de nós, por padrão, todos os pods em execução no cluster ou no pool de nós poderão personificar a conta de serviço. O compartilhamento de uma única conta de serviço em diferentes aplicativos dificulta a atribuição do conjunto correto de privilégios à conta de serviço:

  • Se você só conceder acesso a recursos que todos os aplicativos exigem, alguns aplicativos podem não funcionar por não ter acesso a determinados recursos.
  • Se você conceder acesso a todos os recursos de que um determinado aplicativo precisa, você poderá estar concedendo acessos em excesso.

Uma abordagem melhor para gerenciar o acesso a recursos em um ambiente do GKE é usar a Identidade da carga de trabalho:

  1. Não anexe contas de serviço a clusters do GKE ou a pools de nós.
  2. Crie uma conta de serviço dedicada para cada pod do Kubernetes que requer acesso a APIs ou recursos do Google.
  3. Crie uma conta de serviço do Kubernetes para cada pod do Kubernetes que precise de acesso a APIs ou recursos do Google e anexe-a ao pod.
  4. Use a Identidade da carga de trabalho para criar um mapeamento entre as contas de serviço e as contas de serviço do Kubernetes correspondentes.

Use a federação de identidade de carga de trabalho para permitir que aplicativos em execução no local ou em outros provedores de nuvem usem uma conta de serviço

Se o aplicativo estiver em execução no local ou em outro provedor de nuvem, não será possível anexar uma conta de serviço aos recursos de computação subjacentes. No entanto, o aplicativo pode ter acesso a credenciais específicas do ambiente, como:

  • Credenciais temporárias da AWS
  • Tokens de acesso do Azure Active Directory
  • Tokens de acesso OpenID ou tokens de ID emitidos por um provedor de identidade local como o Active Directory Federation Services (AD FS) ou o KeyCloak

Se seu aplicativo tiver acesso a uma dessas credenciais e precisar de acesso a APIs ou recursos do Google Cloud, use a federação de identidade da carga de trabalho.

A federação de identidade de carga de trabalho permite que você crie uma relação de confiança unidirecional entre um projeto do Google Cloud e um provedor de identidade externo. Depois de estabelecer a confiança, os aplicativos poderão usar credenciais emitidas pelo provedor de identidade confiável para personificar uma conta de serviço seguindo um processo de três etapas:

  1. Consiga uma credencial pelo provedor de identidade confiável, por exemplo, um token de ID do OpenID Connect.
  2. Use a API Security Token Service (STS) para trocar a credencial por um token do Google STS de curta duração.
  3. Use o token STS para se autenticar na API IAM Service Account Credentials e receba tokens de acesso de curta duração do Google para uma conta de serviço.

Quando você usa uma biblioteca de cliente ou uma ferramenta de linha de comando compatível para acessar os serviços do Google Cloud, esse processo acontece automaticamente.

Ao usar a federação de identidade de carga de trabalho, você pode permitir que os aplicativos usem os mecanismos de autenticação fornecidos pelo ambiente externo e evita a necessidade de armazenar e gerenciar chaves de conta de serviço.

Use a API IAM Credentials para implantar credenciais

Alguns aplicativos só exigem acesso a determinados recursos em momentos específicos ou em circunstâncias específicas. Exemplo:

  • Um aplicativo pode exigir acesso aos dados de configuração durante a inicialização, mas pode não exigir esse acesso depois que for inicializado.
  • Um aplicativo supervisor pode iniciar periodicamente jobs em segundo plano em que cada job tem requisitos de acesso diferentes.

Nessas situações, usar uma única conta de serviço e conceder a ela acesso a todos os recursos vai contra o princípio de privilégio mínimo: é provável que, a qualquer momento, o aplicativo tenha acesso a mais recursos do que realmente precisa.

Para garantir que as diferentes partes do aplicativo só tenham acesso aos recursos de que precisam, use a API IAM Credentials para monitorar credenciais de curta duração:

  • Crie contas de serviço dedicadas para cada parte do aplicativo ou caso de uso e conceda à conta de serviço acesso apenas aos recursos necessários.
  • Crie outra conta de serviço que funcione como o supervisor. Conceda à conta de serviço do supervisor o papel de Criador de token da conta de serviço nas outras contas de serviço para que ele possa solicitar tokens de acesso de curta duração para essas contas de serviço.
  • Divida seu aplicativo para que uma parte do aplicativo sirva como agente de token e permita que somente essa parte do aplicativo use as contas de serviço do supervisor.
  • Use o agente de token para emitir contas de serviço de curta duração para as outras partes do aplicativo.

Use as chaves da conta de serviço se não houver uma alternativa viável

Às vezes, é possível se deparar com uma situação em que não é possível anexar uma conta de serviço e usar a Identidade da carga de trabalho ou a federação de identidade da carga de trabalho também não são opções viáveis. Por exemplo, é possível usar um aplicativo de terceiros que precise acessar seus recursos do Google Cloud e que não seja compatível com a federação de identidade.

Em situações em que outras abordagens de autenticação não são viáveis, crie uma chave de conta de serviço para o aplicativo. A chave da conta de serviço permite que um aplicativo faça a autenticação como uma conta de serviço, semelhante a como um usuário pode se autenticar com um nome de usuário e uma senha. As chaves da conta de serviço são um tipo de secret e precisam ser protegidas contra acesso não autorizado.

Um aplicativo pode exigir acesso a dados confidenciais ou pessoais do usuário. Alguns exemplos são: caixa de e-mails ou agenda de um usuário, documentos armazenados no Drive ou um conjunto de dados do BigQuery que contém dados confidenciais.

O uso de uma conta de serviço para acessar dados do usuário pode ser apropriado se o aplicativo realizar tarefas autônomas em segundo plano, como indexação ou verificação de perda de dados (DLP, na sigla em inglês), ou se o usuário final não tiver sido autenticado com uma identidade do Google. Em todos os outros cenários em que um aplicativo age em nome de um usuário final, é melhor evitar o uso de contas de serviço.

Em vez de usar uma conta de serviço para acessar dados do usuário (possivelmente realizando uma transição principal), use o fluxo de consentimento do OAuth para solicitar o consentimento do usuário final. Em seguida, permita que o aplicativo aja com a identidade do usuário final. Usar OAuth em vez de uma conta de serviço ajuda a garantir que:

  • Os usuários possam analisar a quais recursos estão prestes a conceder acesso ao aplicativo e possam expressar ou negar explicitamente o consentimento deles.
  • Os usuários possam revogar o consentimento na página Minha conta a qualquer momento.
  • Você não precise de uma conta de serviço que tenha acesso irrestrito aos dados de todos os usuários.

Ao permitir que o aplicativo use as credenciais de usuário final, você adia as verificações de permissão nas APIs do Google Cloud. Essa abordagem limita o risco de exposição acidental de dados que o usuário não deve ter permissão de acesso devido a um erro de codificação (problema de confused deputy).

Não use contas de serviço durante o desenvolvimento

No dia a dia, você pode usar ferramentas como a Google Cloud CLI, o gsutil ou o terraform. Não use uma conta de serviço para executar essas ferramentas. Em vez disso, permita que usem suas credenciais primeiro executando gcloud auth login (para a CLI gcloud e gsutil) ou gcloud auth application-default login (para terraform e outras ferramentas de terceiros).

É possível usar uma abordagem semelhante para desenvolver e depurar aplicativos que você planeja implantar no Google Cloud. Depois de implantado, o aplicativo pode exigir uma conta de serviço. Porém, se você executá-lo na estação de trabalho local, poderá permitir que ele use suas credenciais pessoais.

Para ajudar a garantir que seu aplicativo seja compatível com credenciais pessoais e de conta de serviço, use as bibliotecas de cliente do Cloud e as Application Default Credentials.

Gerenciar contas de serviço

As contas de serviço são diferentes das contas normais de usuário, não apenas na forma como são usadas, mas também na forma como são gerenciadas. As seções a seguir fornecem práticas recomendadas para o gerenciamento de contas de serviço.

Gerencie contas de serviço como recursos

As contas normais de usuário geralmente são gerenciadas de acordo com os processos joiner-mover-leaver de uma organização: quando um funcionário entra para a empresa, uma nova conta de usuário é criada para ele. Quando eles migram para outro departamento, a conta de usuário é atualizada. E quando ele sai da empresa, a conta de usuário é suspensa ou excluída.

Por outro lado, as contas de serviço não são associadas a nenhum funcionário específico. Pense nas contas de serviço como recursos pertencentes, ou que fazem parte, a outro recurso, como uma determinada instância de VM ou um aplicativo.

Para gerenciar contas de serviço de maneira eficaz, não considere as contas de serviço isoladamente. Considere-as no contexto do recurso a que estão associadas e gerencie a conta de serviço e o recurso associado como uma unidade: aplique os mesmos processos, o mesmo ciclo de vida e a mesma vigilância à conta de serviço e ao recurso associado a ela e use as mesmas ferramentas para gerenciá-los.

Criar contas de serviço de finalidade única

O compartilhamento de uma única conta de serviço em vários aplicativos pode complicar o gerenciamento da conta de serviço:

  • Os aplicativos podem ter ciclos de vida diferentes. Se um aplicativo for desativado, talvez não esteja claro se a conta de serviço também pode ser desativada ou se ainda é necessário.
  • Com o tempo, os requisitos de acesso dos aplicativos podem divergir. Se os aplicativos usarem a mesma conta de serviço, talvez seja necessário conceder acesso à conta de serviço a um número cada vez maior de recursos, o que, por sua vez, aumenta o risco geral.
  • Os registros de auditoria do Cloud incluem o nome da conta de serviço que fez uma alteração ou acessou dados, mas não mostram o nome do aplicativo que usou a conta do serviço. Se vários aplicativos compartilharem uma conta de serviço, talvez não seja possível rastrear a atividade para o aplicativo correto.

Especificamente, alguns serviços do Google Cloud, incluindo o App Engine e o Compute Engine, criam uma conta de serviço padrão que tenha o papel de editor (roles/editor) no projeto por padrão. Quando você cria um recurso, como uma instância de máquina virtual (VM) do Compute Engine, e não especifica uma conta de serviço, o recurso pode usar automaticamente a conta de serviço padrão. A conta de serviço padrão facilita o início, mas é muito arriscado compartilhar uma conta de serviço tão eficiente entrevários aplicativos.

Siga estas etapas para evitar essas complicações:

Siga uma convenção de nomenclatura e documentação

Para ajudar a rastrear a associação entre um serviço e um aplicativo ou recurso, siga uma convenção de nomenclatura ao criar novas contas de serviço:

  • Adicione um prefixo ao endereço de e-mail da conta de serviço que identifica como a conta é usada. Por exemplo:
    • vm- para contas de serviço anexadas a uma instância de VM.
    • wi- para contas de serviço usadas pela identidade da carga de trabalho.
    • wif- para contas de serviço usadas pela federação de identidade da carga de trabalho.
    • onprem- para contas de serviço usadas por aplicativos locais.
  • Insira o nome do aplicativo no endereço de e-mail da conta de serviço. Por exemplo, vm-travelexpenses@ se a VM executar um aplicativo de despesas de viagem.
  • Use o campo de descrição para adicionar uma pessoa para contato, links para a documentação relevante ou outras observações.

Não inclua informações ou termos confidenciais no endereço de e-mail de uma conta de serviço.

Identificar e desativar contas de serviço não utilizadas

Quando uma conta de serviço não é mais utilizada, desative-a. Ao desativar contas de serviços não utilizadas, você reduz o risco de abuso das contas de serviço por causa de um comportamento inadequado ou de escalonamento de privilégios por parte de um usuário de má-fé.

Para contas de serviço de finalidade única associadas a um recurso específico, como uma instância de VM, desative a conta de serviço assim que o recurso associado for desativado ou excluído.

Para contas de serviço usadas para vários fins ou compartilhadas em vários recursos, pode ser mais difícil identificar se a conta de serviço ainda está sendo usada. Nesses casos, você pode usar o analisador de atividades para ver as atividades de autenticação mais recentes nas suas contas de serviço.

Desative contas de serviço não utilizadas antes de excluí-las

Se você excluir uma conta de serviço e, em seguida, criar uma nova conta de serviço com o mesmo nome, uma identidade diferente será atribuída à nova conta de serviço. Como resultado, nenhuma das vinculações originais do IAM se aplicará à nova conta de serviço. Por outro lado, se você desativar e reativar uma conta de serviço, todas as vinculações do IAM permanecerão intactas.

Para evitar a perda acidental de vinculações do IAM, é melhor não excluir as contas de serviço imediatamente. Em vez disso, desative uma conta de serviço se ela não for mais necessária e só a exclua após um determinado período.

Nunca exclua contas de serviço padrão, como o App Engine ou a conta de serviço padrão do Compute Engine. Essas contas de serviço não podem ser recriadas sem desativar e reativar a respectiva API, o que pode interromper a implantação existente. Se você não usa as contas de serviço padrão, desative-as.

Limitar os privilégios da conta de serviço

As contas de serviço são principais e podem receber acesso a um recurso, como uma conta de usuário comum. No entanto, as contas de serviço geralmente têm mais acesso a mais recursos do que um usuário típico. Além disso, à medida que você adiciona funcionalidades aos seus aplicativos, as contas de serviço tendem a ganhar cada vez mais acesso com o tempo. Também é possível revogar o acesso que não é mais necessário.

Não use concessões de papel automáticas para contas de serviço padrão

Alguns serviços do Google Cloud criam contas de serviço padrão quando você ativa a API em um projeto do Google Cloud pela primeira vez. Por padrão, essas contas de serviço recebem o papel de editor (roles/editor) no projeto do Cloud, o que permite que elas leiam e modifiquem todos os recursos no projeto do Cloud. O papel é concedido para sua conveniência, mas não é essencial para que os serviços funcionem: para acessar os recursos no seu projeto do Cloud, os serviços do Google Cloud usam agentes de serviços, não as contas de serviço padrão.

Para impedir que contas de serviço padrão recebam automaticamente o papel Editor, ative a restrição Desativar concessões automáticas do IAM para contas de serviço padrão (constraints/iam.automaticIamGrantsForDefaultServiceAccounts) para sua organização. Para aplicar a restrição a vários projetos do Cloud, configure-a na pasta ou no nó da organização. A aplicação da restrição não exclui o papel Editor das contas de serviço padrão existentes.

Se você aplicar essa restrição, as contas de serviço padrão em novos projetos não terão acesso aos recursos do Google Cloud. Conceda os papéis adequados às contas de serviço padrão para que elas acessem os recursos.

Não dependa dos escopos de acesso ao anexar uma conta de serviço a uma instância de VM

Ao anexar uma conta de serviço a uma instância de VM, é possível especificar um ou mais escopos de acesso. Com os escopos de acesso, é possível restringir quais serviços a VM pode acessar. Restrições são aplicadas, além de políticas de permissão.

Os escopos de acesso são granulares. Por exemplo, ao usar o escopo https://www.googleapis.com/auth/devstorage.read_only, é possível restringir o acesso às operações somente leitura do Cloud Storage, mas não é possível restringir o acesso a buckets específicos. Portanto, os escopos de acesso não são uma substituição adequada para políticas de permissão refinadas.

Em vez de depender dos escopos de acesso, crie uma conta de serviço dedicada e use políticas de permissão refinadas para restringir a quais recursos a conta de serviço tem acesso.

Evite usar grupos para conceder acesso a recursos às contas de serviço

Em uma organização, é comum que vários funcionários executem funções de job semelhantes ou sobrepostas e, portanto, requeiram acesso semelhante aos recursos. Ao usar grupos, você pode aproveitar essas semelhanças para reduzir a sobrecarga administrativa.

As contas de serviço devem ser usadas por aplicativos. É raro aplicativos executarem a mesma função e, portanto, terem requisitos de acesso semelhantes ou idênticos. Os aplicativos tendem a ser exclusivos, e os recursos aos quais eles requerem acesso normalmente são diferentes para cada aplicativo.

Usar grupos para conceder acesso a recursos às contas de serviço pode ter alguns resultados negativos:

  • Uma proliferação de grupos, em que cada grupo contém apenas uma ou algumas contas de serviço.
  • Acúmulo de permissões: com o tempo, um grupo recebe acesso a um número crescente de recursos, embora cada membro do grupo só precise de acesso a um subconjunto dos recursos.

A menos que o objetivo de um grupo seja restritamente definido, é melhor evitar o uso de grupos. Em vez disso, conceda diretamente às contas de serviço os recursos necessários.

Evite usar a delegação em todo o domínio

A delegação em todo o domínio permite que uma conta de serviço personifique qualquer usuário em uma conta do Cloud Identity ou do Google Workspace. A delegação em todo o domínio permite que uma conta de serviço execute determinadas tarefas administrativas no Google Workspace e no Cloud Identity ou acesse as APIs do Google que não são compatíveis com contas de serviço de fora do Google Cloud.

A delegação em todo o domínio não restringe uma conta de serviço a personificar um usuário específico, mas permite que ela personifique qualquer usuário em uma conta do Cloud Identity ou do Google Workspace, incluindo superadministradores. Portanto, permitir que uma conta de serviço use a delegação em todo o domínio pode torná-la um alvo atraente para ataques de escalonamento de privilégios.

Evite usar a delegação em todo o domínio se for possível executar a tarefa diretamente com uma conta de serviço ou usando o fluxo de consentimento do OAuth.

Se não for possível evitar o uso de delegação em todo o domínio, restrinja o conjunto de escopos do OAuth que a conta de serviço pode usar. Embora os escopos do OAuth não restrinjam os usuários que a conta de serviço pode personificar, eles restringem os tipos de dados do usuário que a conta de serviço pode acessar.

Use limites de acesso a credenciais para diminuir o escopo dos tokens de acesso

Os tokens de acesso do Google são tokens do portador, o que significa que o uso deles não está vinculado a nenhum aplicativo específico. Se seu aplicativo transmitir um token de acesso a um aplicativo diferente, esse outro aplicativo poderá usar o token da mesma forma que seu aplicativo. Da mesma forma, se um token de acesso for vazado para um usuário de má-fé, ele poderá usar o token para conseguir acesso.

Como os tokens de acesso são tokens do portador, você precisa protegê-los de serem vazados ou ficarem visíveis para partes não autorizadas. É possível limitar o risco potencial de um vazamento de token de acesso restringindo os recursos a que ele concede acesso. Esse processo é chamado de redução do escopo.

Use Limites de acesso a credenciais para diminuir o escopo dos tokens de acesso sempre que transmitir um token de acesso para um aplicativo diferente ou para um componente diferente do aplicativo. Defina o limite de acesso para que o token conceda acesso suficiente aos recursos necessários, mas não mais.

Usar recomendações de papéis para identificar permissões não utilizadas

Ao implantar um aplicativo pela primeira vez, talvez você não tenha certeza dos papéis e das permissões realmente necessários para o aplicativo. Como resultado, você pode acabar concedendo à conta de serviço do aplicativo mais permissões do que o necessário.

Da mesma forma, os requisitos de acesso de um aplicativo podem evoluir com o tempo, e alguns dos papéis e permissões que você concedeu inicialmente podem não ser necessários.

Use recomendações de papel para identificar quais permissões um aplicativo está realmente usando e quais permissões podem não ser usadas. Ajuste as políticas de permissão dos recursos afetados para ajudar a garantir que um aplicativo não receba mais acesso do que realmente precisa.

Usar insights de movimento lateral para limitar o movimento lateral

O movimento lateral ocorre quando uma conta de serviço em um projeto tem permissão para personificar uma conta de serviço em outro projeto. Por exemplo, uma conta de serviço pode ter sido criada no projeto A, mas tem permissões para personificar uma conta de serviço no projeto B.

Essas permissões podem resultar em uma cadeia de representações entre projetos que dá aos diretores acesso não intencional aos recursos. Por exemplo, um principal pode representar uma conta de serviço no projeto A e, em seguida, usar essa conta de serviço para uma conta de serviço no projeto B. Se a conta de serviço no projeto B tiver permissão para personificar outras contas de serviço em outros projetos da organização, o principal poderá continuar usando a representação da conta de serviço para mover do projeto para o projeto, recebendo permissões conforme ir.

O recomendador fornece insights de movimento colateral para ajudar a reduzir esse problema. Os insights de movimento lateral identificam papéis que permitem que uma conta de serviço em um projeto represente uma conta de serviço em outro projeto. Para saber como ver e gerenciar diretamente os insights de movimento lateral, consulte Gerenciar insights de movimento lateral.

Alguns insights de movimento lateral estão associados a recomendações de papel. Você pode aplicar essas recomendações para reduzir o movimento lateral nos projetos. Para saber como fazer isso, consulte Analisar e aplicar as recomendações.

Proteger contra ameaças de escalonamento de privilégios

Uma conta de serviço que não recebeu nenhum papel, não tem acesso a nenhum recurso e não está associada a nenhuma regra de firewall normalmente é de valor limitado. Depois de conceder acesso a recursos a uma conta de serviço, o valor dela aumenta: a conta de serviço se torna mais útil para você, mas também se torna um alvo mais atrativo para ataques de escalonamento de privilégios.

Como exemplo, pense em uma conta de serviço que tenha acesso total a um bucket do Cloud Storage, que contém informações confidenciais. Nesse caso, a conta de serviço é efetivamente valiosa como o próprio bucket do Cloud Storage: em vez de tentar acessar o bucket diretamente, um usuário de má-fé pode tentar assumir o controle da conta de serviço. Caso ele consiga fazer isso, ele também poderá escalonar seus privilégios personificando a conta de serviço, que, por sua vez, permite o acesso às informações confidenciais no bucket.

As técnicas de escalonamento de privilégios que envolvem contas de serviço geralmente se enquadram nas seguintes categorias:

  • Personificação direta: é possível conceder a um usuário permissão acidentalmente para personificar uma conta de serviço ou criar uma chave de conta de serviço para uma conta de serviço. Se a conta de serviço tiver mais privilégios do que o próprio usuário, ele poderá usar esse recurso para escalonar os privilégios dele e conseguir acesso aos recursos que normalmente não conseguiria acessar.

  • Falsificação de identidade indireta:se um usuário não puder representar diretamente uma conta de serviço, ele poderá fazer isso indiretamente se a conta de serviço for usada por um pipeline de CI/CD, a VM ou um sistema de automação diferente que eles possam acessar. Como resultado, se o sistema não impedir o usuário de fazer isso, ele poderá realizar operações que não teriam permissão para realizar por conta própria.

    Por exemplo, se um usuário tiver acesso SSH a uma instância de VM do Compute Engine, ele poderá representar indiretamente a conta de serviço anexada à instância de VM e acessar qualquer recurso do Google Cloud que a conta de serviço possa acesso.

  • Modificações de política de permissão, grupo ou papel personalizado: um usuário que não tem acesso a uma conta de serviço com privilégios ainda pode ter permissão para modificar as políticas de permissão da conta de serviço, projeto ou pasta do Cloud. O usuário pode, então, estender uma dessas políticas de permissão para conceder a si mesmo permissão para personificar (diretamente ou indiretamente) a conta de serviço.

Nas seções a seguir, você verá as práticas recomendadas para proteger contas de serviço contra ameaças de escalonamento de privilégios.

Evite permitir que os usuários personifiquem contas de serviço que são mais privilegiadas do que os próprios usuários

Ao personificar uma conta de serviço, um usuário recebe acesso a alguns ou todos os recursos que essa conta pode acessar. Se a conta de serviço tiver acesso mais amplo do que o usuário, ela será efetivamente mais privilegiada do que o usuário.

Conceder a um usuário permissão para personificar uma conta de serviço mais privilegiada pode ser uma maneira de permitir que os usuários, temporariamente, elevem os privilégios deles, semelhante ao uso da ferramenta sudo no Linux, ou usando a elevação do processo no Windows. A menos que você esteja lidando com um cenário em que essa elevação temporária de privilégios é necessária, é melhor evitar que os usuários personifiquem uma conta de serviço mais privilegiada.

As permissões que permitem que um usuário personifique uma conta de serviço incluem:

  • iam.serviceAccounts.getAccessToken
  • iam.serviceAccounts.getOpenIdToken
  • iam.serviceAccounts.actAs
  • iam.serviceAccounts.implicitDelegation
  • iam.serviceAccounts.signBlob
  • iam.serviceAccounts.signJwt
  • iam.serviceAccountKeys.create
  • deploymentmanager.deployments.create
  • cloudbuild.builds.create

Os papéis que contêm algumas dessas permissões incluem, entre outros:

  • Proprietário (roles/owner)
  • Editor (roles/editor)
  • Usuário da conta de serviço (roles/iam.serviceAccountUser)
  • Criador do token da conta de serviço (roles/iam.serviceAccountTokenCreator)
  • Administrador da chave da conta de serviço (roles/iam.serviceAccountKeyAdmin)
  • Administrador da conta de serviço (roles/iam.serviceAccountAdmin)
  • Usuário de identidade da carga de trabalho (roles/iam.workloadIdentityUser)
  • Editor do Deployment Manager (roles/deploymentmanager.editor)
  • Editor do Cloud Build (roles/cloudbuild.builds.editor)

Antes de atribuir qualquer um desses papéis a um usuário, pergunte-se:

  • Quais recursos dentro e fora do projeto atual do Cloud o usuário poderia acessar personificando a conta de serviço?
  • Esse nível de acesso é justificado?
  • Existem proteções suficientes em vigor que controlam em quais circunstâncias o usuário pode personificar a conta de serviço?

Não atribua a função se não for possível confirmar todas as perguntas. Em vez disso, considere dar ao usuário uma conta de serviço diferente e com menos privilégios.

Evite permitir que os usuários alterem as políticas de permissão de contas de serviço com mais privilégios

Os usuários com permissão para usar ou personificar uma conta de serviço são capturados pela política de permissão da conta de serviço. A política de permissão pode ser modificada ou estendida por usuários que têm a permissão iam.serviceAccounts.setIamPolicy na conta de serviço específica. Os papéis que contêm essa permissão incluem:

  • Proprietário (roles/owner)
  • Administrador de segurança (roles/iam.securityAdmin)
  • Administrador da conta de serviço (roles/iam.serviceAccountAdmin)

Os papéis que incluem a permissão iam.serviceAccounts.setIamPolicy dão ao usuário controle total sobre uma conta de serviço:

  • O usuário pode conceder a si mesmo permissão para personificar a conta de serviço, o que dá a ele a capacidade de acessar os mesmos recursos que a conta de serviço.
  • O usuário pode conceder a outros usuários um nível de acesso igual ou semelhante à conta de serviço.

Antes de atribuir qualquer um desses papéis a um usuário, pergunte-se quais recursos, dentro e fora do projeto atual do Cloud o usuário poderia acessar personificando a conta de serviço. Não permita que um usuário mude a política de permissão de uma conta de serviço se a conta tiver mais privilégios que o usuário.

Não permita que os usuários criem ou façam upload de chaves de contas de serviço

As chaves da conta de serviço permitem que aplicativos ou usuários se autentiquem como uma conta de serviço. Diferentemente de outras formas de personificação de conta de serviço, o uso de uma chave de conta de serviço não requer nenhuma forma de autenticação prévia, qualquer um que tenha uma chave de conta de serviço pode usá-la.

O efeito líquido do uso de uma chave de conta de serviço para autenticar é semelhante a outras formas de personificação de identidade. Se você conceder acesso a uma chave de conta de serviço a um usuário ou autorizar a criação de uma nova chave de conta de serviço, o usuário poderá personificar a conta de serviço e acessar todos os recursos que essa conta pode acessar.

Para criar ou fazer upload de uma chave de conta de serviço, é preciso ter a permissão iam.serviceAccountKeys.create, que está incluída nos papéis de Administrador (roles/iam.serviceAccountKeyAdmin) e Editor (roles/editor) de chave da conta de serviço.

Antes de atribuir qualquer papel que inclua a permissão iam.serviceAccountKeys.create a um usuário, pergunte-se quais recursos dentro e fora do projeto atual do Cloud o usuário poderia acessar personificando a conta de serviço. Não permita que um usuário crie chaves de conta de serviço para contas de serviço com mais privilégios do que ele.

Se o projeto do Cloud não exigir nenhuma chave de conta de serviço, aplique as restrições Desativar criação da chave da conta de serviço e Desativar upload da chave da conta de serviço da política da organização para o projeto do Cloud ou a pasta contida. Essas restrições impedem que todos os usuários criem e façam upload de chaves de contas de serviço, incluindo aquelas com permissão iam.serviceAccountKeys.create em uma conta de serviço.

Não conceda acesso a contas de serviço no nível do projeto ou da pasta do Cloud

Contas de serviço são recursos e parte da hierarquia de recursos. Portanto, você pode gerenciar o acesso a contas de serviço em qualquer um dos seguintes níveis:

  • Da conta de serviço individual
  • Do projeto contido do Cloud
  • De uma pasta na ancestralidade do projeto do Cloud
  • Do nó da organização

Gerenciar o acesso no nível do projeto do Cloud ou em um nível superior da hierarquia de recursos pode ajudar a reduzir a sobrecarga administrativa, mas também pode levar à concessão de privilégios em excesso. Por exemplo, se você conceder a um usuário o papel Criador do token da conta de serviço em um projeto do Cloud, o usuário poderá personificar qualquer conta de serviço no projeto do Cloud. A possibilidade de personificar qualquer conta de serviço implica na possibilidade de o usuário ter acesso a todos os recursos que essas contas de serviço podem acessar, incluindo recursos fora deste projeto do Cloud.

Para evitar essa concessão excessiva, não gerencie o acesso a contas de serviço no nível do projeto ou da pasta do Cloud. Em vez disso, gerencie de maneira individual o acesso para cada conta de serviço.

Não execute código de fontes menos protegidas em recursos de computação que têm uma conta de serviço privilegiada anexada

Quando você anexa uma conta de serviço a um recurso de computação, como uma instância de VM ou um aplicativo do Cloud Run, os processos executados nesse recurso podem usar o servidor de metadados para solicitar tokens de acesso e tokens de ID. Esses tokens permitem que o processo personifique a conta de serviço e acesse recursos em nome dela.

Por padrão, o acesso ao servidor de metadados não é restrito a processos ou usuários específicos. Em vez disso, qualquer código executado no recurso de computação pode acessar o servidor de metadados e receber um token de acesso. Esse código pode incluir:

  • O código do seu aplicativo.
  • Código enviado por usuários finais, se o aplicativo permitir qualquer avaliação de script do servidor.
  • Leitura de código de um repositório de origem remota, se o recurso de computação fizer parte de um sistema de CI/CD.
  • Scripts de inicialização e encerramento veiculados por um bucket do Cloud Storage.
  • Políticas de convidado distribuídas pelo VM Manager.

Se o código for enviado por usuários ou for lido em um local de armazenamento remoto, será necessário garantir que ele seja confiável e que os locais de armazenamento remoto estejam pelo menos tão seguros quanto a conta de serviço anexada. Se um local de armazenamento remoto for menos protegido do que a conta de serviço, um usuário de má-fé poderá escalonar os privilégios dele. Ele pode fazer isso inserindo código malicioso que usa os privilégios da conta de serviço nesse local.

Limite o acesso ao shell às VMs que têm uma conta de serviço privilegiada anexada

Alguns recursos de computação aceitam acesso interativo e permitem que os usuários tenham acesso ao shell. Exemplo:

  • O Compute Engine permite usar o SSH ou o RDP para fazer login em uma instância de VM.
  • O Google Kubernetes Engine permite que você use o kubectl exec para executar um comando ou iniciar um shell em um contêiner do Kubernetes.

Se uma instância de VM tiver uma conta de serviço privilegiada anexada, qualquer usuário com acesso ao shell poderá personificar a conta de serviço e acessar recursos em seu nome. Para evitar que os usuários abusem desse recurso para escalonar os privilégios, você precisa garantir que o acesso ao shell seja pelo menos tão seguro quanto a conta de serviço anexada.

Para instâncias do Linux, é possível exigir que o acesso SSH seja mais restritivo que o acesso à conta de serviço anexada usando o login do SO. Para se conectar a uma instância de VM que tenha o login do SO ativado, não basta que o usuário tenha permissão para usar o Login do SO, ele também precisa da permissão iam.serviceAccounts.actAs na conta de serviço anexada.

O mesmo nível de controle de acesso não se aplica a instâncias de VM que usam chaves baseadas em metadados ou a instâncias do Windows: publicar uma chave SSH em metadados ou solicitar credenciais do Windows requer acesso aos metadados da instância de VM e a permissão iam.serviceAccounts.actAs na conta de serviço anexada. No entanto, depois que a chave SSH for publicada ou as credenciais do Windows terem sido recebidas, os logins subsequentes não estarão sujeitos a nenhuma verificação de permissão adicional do IAM.

Da mesma forma, se uma instância de VM usar um módulo de autenticação conectável personalizado do Linux para autenticação ou for membro de um domínio do Active Directory, é possível que os usuários que não teriam permissão para personificar a conta de serviço tenham permissão para fazer login.

Particularmente para instâncias de VM que não usam o login do SO, considere atribuir o acesso ao shell pelo Identity-Aware Proxy. Conceda o papel de usuário do túnel protegido pelo IAP somente a usuários que precisam ter permissão para personificar a conta de serviço anexada à instância de VM.

Limite o acesso ao servidor de metadados para usuários e processos selecionados

Quando você anexa uma conta de serviço a uma instância de VM, as cargas de trabalho implantadas na VM podem acessar o servidor de metadados para solicitar tokens para as contas de serviço. Por padrão, o acesso ao servidor de metadados não é limitado a nenhum processo ou usuário específico na VM: mesmo os processos em execução como um usuário de pouco privilégio, como nobody no Linux ou LocalService no Windows, têm acesso total ao servidor de metadados e podem conseguir tokens para a conta de serviço.

Para limitar o acesso do servidor de metadados a usuários específicos, configure o firewall do host do sistema operacional convidado para apenas permitir que esses usuários abram conexões de saída ao servidor de metadados.

No Linux, é possível usar as opções --uid-owner e --gid-owner para configurar uma regra iptables que se aplique apenas a usuários ou grupos específicos. No Windows, o comando Set-NetFirewallSecurityFilter permite personalizar uma regra de firewall para que ela se aplique a usuários ou grupos selecionados.

Proteger contra ameaças à divulgação de informações

Evite divulgar informações confidenciais nos endereços de e-mail da conta de serviço

Para conceder a uma conta de serviço acesso a um recurso em outro projeto do Cloud, adicione uma vinculação de papel à política de permissão do recurso. Assim como o próprio recurso, a política de permissão faz parte do outro projeto do Cloud e a visibilidade dele também é controlada por esse outro projeto do Cloud.

A visualização de políticas de permissão normalmente não é considerada uma operação privilegiada. Muitos papéis incluem a permissão *.getIamPolicy obrigatória, inclusive o papel básico de Visualizador.

Um usuário que pode visualizar uma política de permissão também pode ver os endereços de e-mail dos participantes que receberam acesso ao recurso. No caso das contas de serviço, os endereços de e-mail podem dar dicas aos usuários de má-fé.

Por exemplo, uma política de permissão pode incluir uma vinculação para uma conta de serviço com o endereço de e-mail jenkins@deployment-project-123.gserviceaccount.com. Para um usuário de má-fé, esse endereço de e-mail não apenas revela que há um projeto do Cloud com ID deployment-project-123, mas revela também que o projeto do Cloud executa um servidor Jenkins. Ao escolher um nome mais genérico, como deployer@deployment-project-123.gserviceaccount.com, você evita divulgar informações sobre o tipo de software que está em execução no deployment-project-123.

Se você conceder a uma conta de serviço acesso a recursos em um projeto do Cloud com acesso menos controlado (como um sandbox ou um projeto de desenvolvimento do Cloud), certifique-se de que o endereço de e-mail da conta de serviço não divulga nenhuma informação. Não divulgue informações confidenciais ou que possam dar dicas aos invasores.

Proteger contra ameaças de não repúdio

Sempre que você notar atividades suspeitas afetando um dos seus recursos no Google Cloud, os registros de auditoria do Cloud são uma fonte de informação importante para descobrir quando a atividade ocorreu e quais usuários estavam envolvidos.

Sempre que os registros de auditoria do Cloud indicarem que a atividade foi executada por uma conta de serviço, essa informação por si só pode não ser suficiente para reconstruir a cadeia completa de eventos. Você também precisa descobrir qual usuário ou aplicativo fez com que a conta de serviço realizasse a atividade.

Esta seção apresenta as práticas recomendadas que podem ajudar você a manter uma trilha de auditoria não repudiável.

Ative registros de acesso a dados para APIs IAM

Para ajudar você a identificar e compreender cenários de personificação de conta de serviço, serviços como o Compute Engine incluem uma seção serviceAccountDelegationInfo nos registros de auditoria do Cloud. Esta seção indica se a conta de serviço foi falsificada e por qual usuário.

Nem todos os serviços incluem detalhes de personificação de identidade nos registros de auditoria do Cloud. Para registrar todos os eventos de falsificação de identidade, você também precisa ativar os registros de acesso a dados para as seguintes APIs:

  • API Identity and Access Management (IAM) em todos os projetos do Cloud que contêm contas de serviço
  • API Security Token Service em todos os projetos do Cloud que contêm pools de identidade de carga de trabalho.

Ao ativar esses registros, você garante que uma entrada é adicionada aos registros de auditoria do Cloud sempre que um usuário solicitar um token de acesso ou um ID de token para uma conta de serviço.

Verifique se o histórico de CI/CD pode ser correlacionado com os registros de auditoria do Cloud

As contas de serviço geralmente são usadas por sistemas de CI/CD para realizar implantações depois que uma alteração de código é verificada e aprovada para implantação. Normalmente, os sistemas de CI/CD mantêm um histórico de eventos que levam a uma implantação. Esse histórico pode incluir os IDs das revisões de código correspondentes, confirmações e execuções de pipeline, bem como informações sobre quem aprovou a implantação.

Se uma implantação modificar algum recurso no Google Cloud, essas alterações serão monitoradas nos registros de auditoria do Cloud dos respectivos recursos. Os registros de auditoria do Cloud contêm informações sobre o usuário ou a conta de serviço que iniciou a alteração. No entanto, em uma implantação acionada por um sistema de CI/CD, a própria conta de serviço geralmente não é suficiente para reconstruir toda a cadeia de eventos que levaram à mudança.

Para estabelecer uma trilha de auditoria consistente no seu sistema de CI/CD e no Google Cloud, verifique se os registros de auditoria do Cloud podem ser correlacionados com eventos no histórico do sistema de CI/CD. Se você encontrar um evento inesperado nos registros de auditoria do Cloud, poderá usar essa correlação para determinar se a alteração foi realmente realizada pelo sistema de CI/CD, por que foi executada e quem a aprovou.

As maneiras de estabelecer uma correlação entre os registros de auditoria do Cloud e os eventos no histórico do sistema de CI/CD incluem:

  • Solicitações de API de registro realizadas por cada execução de pipeline de CI/CD.
  • Sempre que a API retornar um ID de operação, registre o ID nos registros do sistema de CI/CD.
  • Adicione um cabeçalho HTTP X-Goog-Request-Reason às solicitações da API e transmita o ID da execução do pipeline de CI/CD. O Terraform pode adicionar automaticamente esse cabeçalho se você especificar um motivo da solicitação.

    Como alternativa, incorpore as informações no cabeçalho User-Agent para que sejam capturadas nos registros de auditoria do Cloud.

Para ajudar a garantir o não repúdio, configure os arquivos de registros e confirme os históricos para que eles fiquem imutáveis e para que um usuário de má-fé não possa ocultar retroativamente os rastros dele.

A seguir