práticas recomendadas para usar contas de serviço

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

Nem todos os cenários exigem uma conta de serviço para acessar os serviços do Google Cloud, e muitos cenários podem ser autenticados com um método mais seguro do que usar uma chave de conta de serviço. Recomendamos que você evite usar chaves de conta de serviço sempre que possível.

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:

  1. 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.
  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.
  3. 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.

  4. 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.
  5. Sua carga de trabalho é autenticada com um provedor de identidade externo compatível com a federação de identidade de 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.

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.

Práticas recomendadas:

Gerencie contas de serviço como recursos.
Crie contas de serviço de finalidade única.
Seguir a convenção de nomenclatura e documentação.
Identifique e desative contas de serviço não utilizadas.
Desative contas de serviço não utilizadas antes de excluí-las.

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.
    • wlifgke- para contas de serviço usadas pela federação de identidade da carga de trabalho do GKE.
    • wlif- 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.

Práticas recomendadas:

Não use concessões automáticas de papéis para contas de serviço padrão.
Não dependa dos escopos de acesso ao anexar uma conta de serviço a uma instância de VM.
Evite usar grupos para conceder acesso a recursos às contas de serviço.
Evite usar a delegação em todo o domínio.
Não use contas de serviço para acessar dados do usuário sem o consentimento dele.
Use a API IAM Credentials para elevação temporária de privilégios.
Use limites de acesso a credenciais para diminuir o escopo dos tokens de acesso.
Usar recomendações de papéis para identificar permissões não utilizadas.
Usar insights de movimento lateral para limitar o movimento lateral.

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 ao ativar a API em um projeto do Google Cloud pela primeira vez. Dependendo da configuração da política da organização, essas contas de serviço podem receber automaticamente o papel de editor (roles/editor) no projeto do Google Cloud, o que permite que elas leiam e modifiquem todos os recursos no projeto do Google Cloud. O papel é concedido para sua conveniência, mas não é essencial para que os serviços funcionem: para acessar os recursos no projeto do Google 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 de 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 Google 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.

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 Google 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).

Use a API IAM Credentials para elevação temporária de privilégios

Alguns aplicativos só exigem acesso a determinados recursos em momentos específicos ou em circunstâncias específicas. Por 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 tenham acesso apenas aos recursos necessários, use a API IAM Credentials para elevação temporária de privilégios:

  • 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.

Para ajuda na criação de credenciais de curta duração, consulte Criar credenciais de curta duração para uma conta de serviço.

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:

  • Autenticação como a conta de serviço: você pode conceder acidentalmente uma permissão ao usuário para representar uma conta de serviço ou criar uma chave de conta de serviço de uma conta de serviço. Se a conta de serviço for mais privilegiada do que o próprio usuário, ele poderá se autenticar como a conta de serviço para escalar os privilégios e ter acesso a recursos que não poderiam acessar de outra forma.

  • Usar recursos que têm uma conta de serviço anexada: se um usuário tiver permissão para acessar e modificar pipelines de CI/CD, instâncias de VM ou outros sistemas de automação que tenham contas de serviço anexadas, eles podem executar ações usando as contas de serviço anexadas a esses recursos. Consequentemente, mesmo que eles não tenham permissão para representar a conta de serviço, ainda podem usar as permissões dela para realizar ações que não teriam permissão por conta própria.

    Por exemplo, se um usuário tiver acesso SSH a uma instância de VM do Compute Engine, ele poderá executar o código na instância para acessar qualquer recurso que a conta de serviço anexada à instância possa acessar.

  • 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 Google Cloud. O usuário pode, então, estender uma dessas políticas de permissão para conceder a si mesmo permissão para autenticar (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.

Práticas recomendadas:

Evite permitir que os usuários personifiquem contas de serviço que são mais privilegiadas do que os próprios usuários.
Evite permitir que os usuários alterem as políticas de permissão das contas de serviço que são mais privilegiadas do que os próprios usuários.
Não permita que os usuários criem ou façam upload de chaves de conta de serviço.
Não conceda acesso a contas de serviço no nível do projeto ou da pasta do Google Cloud.
Não execute código de fontes menos protegidas em recursos de computação que têm uma conta de serviço privilegiada anexada.
Limite o acesso de shell às VMs que têm uma conta de serviço privilegiada anexada.
Limite o acesso ao servidor de metadados para usuários e processos selecionados.

Evite permitir que os usuários se autentiquem como contas de serviço com mais privilégios 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 representem uma conta de serviço mais privilegiada.

Os usuários também podem receber indiretamente as permissões de uma conta de serviço anexando-a a um recurso e executando o código nesse recurso. A execução do código dessa maneira não é uma representação da conta de serviço, porque envolve apenas uma identidade autenticada (a da conta de serviço). No entanto, ela pode dar a um usuário acesso que ele não teria de outra forma.

As permissões que permitem que um usuário represente uma conta de serviço ou anexe uma conta de serviço a um recurso:

  • 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 Google 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 Google 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 de usar uma chave de conta de serviço para autenticação é semelhante ao efeito da representação da conta de serviço. Se um usuário tiver acesso a uma chave de conta de serviço ou permitir que ele crie uma nova chave, ele poderá fazer a autenticação como a conta de serviço e acessar todos os recursos que ela 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 Google 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 Google 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 Google 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 Google 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
  • O projeto do Google Cloud incluído
  • De uma pasta na ancestralidade do projeto do Cloud
  • Do nó da organização

Gerenciar o acesso no nível do projeto do Google 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 Google Cloud, o usuário poderá personificar qualquer conta de serviço no projeto do Google 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 Google 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 Google 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 seja autenticado como a conta de serviço e acesse os 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. Por 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 usar 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 de shell ao sistema poderá autenticar e acessar recursos como a conta de serviço. 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 autenticar a conta de serviço tenham permissão para fazer login. Para mais informações, consulte Práticas recomendadas para executar o Active Directory no Google Cloud.

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 (roles/iap.tunnelResourceAccessor) 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

Práticas recomendadas:

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

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 Google 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 Google Cloud e a visibilidade dele também é controlada por esse outro projeto do Google 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.iam.gserviceaccount.com. Para um usuário de má-fé, esse endereço de e-mail não apenas revela que há um projeto do Google Cloud com ID deployment-project-123, mas revela também que o projeto do Google Cloud executa um servidor Jenkins. Ao escolher um nome mais genérico, como deployer@deployment-project-123.iam.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 Google Cloud com acesso menos controlado (como um sandbox ou um projeto de desenvolvimento do Google 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.

Práticas recomendadas:

Use as chaves de conta de serviço somente quando não houver uma alternativa viável.
Ative registros de acesso a dados para APIs IAM.
Verifique se o histórico de CI/CD pode ser correlacionado com os Registros de auditoria do Cloud.
Crie entradas de registro personalizadas para usuários individuais de um aplicativo.

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

Se não for possível usar métodos de autenticação mais seguros, talvez seja necessário criar uma chave de conta de serviço para o aplicativo. No entanto, a autenticação com uma chave de conta de serviço apresenta uma ameaça de não repúdio. Os Registros de auditoria do Cloud criam um registro quando uma conta de serviço modifica um recurso. No entanto, se a conta de serviço for autenticada com uma chave de conta de serviço, não haverá uma maneira confiável de saber quem a usou a chave. Comparativamente, a autenticação com uma conta de serviço representando a conta de serviço com credenciais de usuário registra o principal que agiu com a conta de serviço.

Recomendamos impedir a criação de chaves de conta de serviço aplicando a restrição da política da organização Desativar criação de chave de conta de serviço ao projeto do Google Cloud ou à pasta inclusa. Se você precisar usar chaves de conta de serviço em um cenário que não permite nenhuma das alternativas recomendadas, conceda uma exceção à restrição da política (a mais restritiva possível) e reavalie as práticas recomendadas para gerenciar chaves de conta de serviço.

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 Google Cloud que contêm contas de serviço
  • API Security Token Service em todos os projetos do Google 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.

Crie entradas de registro personalizadas para usuários individuais de um aplicativo

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. No entanto, os Registros de auditoria do Cloud registrarão se a conta de serviço acessou um recurso, não que usuário estava usando o aplicativo.

Para rastrear esse acesso até o usuário, crie uma lógica de aplicativo que grave uma entrada de registro personalizada sempre que um usuário acessar um recurso e correlacione essas entradas com os Registros de auditoria do Cloud.

A seguir