Práticas recomendadas para proteger contas de serviço

As contas de serviço diferem das contas de usuário porque 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.

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 de serviço é um recurso, você precisa protegê-la de ficar comprometida.

Uma conta de serviço está sujeita a diversas formas de abuso:

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

Neste guia, apresentamos as práticas recomendadas para limitar os privilégios de contas de serviço e atenuar esses grandes riscos.

Como limitar 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.

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.

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. As restrições são aplicadas além das políticas de gerenciamento de identidade e acesso (IAM, na sigla em inglês).

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 refinadas do IAM.

Em vez de depender dos escopos de acesso, crie uma conta de serviço dedicada e use políticas refinadas do IAM 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 do IAM dos recursos afetados para ajudar a garantir que um aplicativo não receba mais acesso do que realmente precisa.

Como se 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.
  • Personificação indireta: se um usuário não conseguir personificar uma conta de serviço diretamente, ele poderá fazer isso indiretamente se a conta de serviço for usada por um pipeline de CI/CD, por uma instância de VM ou um sistema de automação diferente que ele consiga acessar: se o sistema não implementar restrições de acesso apropriadas, o usuário poderá permitir que o sistema execute operações que não conseguiria executar por conta própria, escalonando os privilégios.
  • Modificações de política de IAM, 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 IAM da conta de serviço, projeto ou pasta do Cloud. O usuário pode, então, estender uma dessas políticas do IAM 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.serviceAccountKeys.create
  • iam.serviceAccountKeys.get
  • 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 do IAM 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 IAM da conta de serviço. A política de IAM 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 IAM 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 devem 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.

Como se proteger contra ameaças de spoofing

A federação de identidade da carga de trabalho permite que você crie uma relação de confiança unidirecional entre um projeto do Cloud e um provedor de identidade externo. Depois de estabelecer essa relação de confiança, é possível trocar as credenciais recebidas do provedor de identidade externo por um token do serviço de token de segurança (STS, na sigla em inglês). Esse token poderá ser usado para acessar ou personificar uma conta de serviço.

Os tokens do STS são diferentes dos tokens de acesso porque não correspondem a uma identidade específica do Google. Os tokens do STS também não correspondem necessariamente a uma identidade específica no provedor de identidade externo. Em vez disso, um token do STS representa um conjunto de atributos. Dependendo desses atributos, eles podem corresponder a uma ou várias identidades no provedor de identidade externo.

Se os atributos representados por um token do STS forem ambíguos ou usados inadequadamente, eles poderão permitir que usuários de má-fé falsifiquem a própria identidade. Na seção a seguir, descrevemos as práticas recomendadas que ajudam você a se proteger contra tais ameaças de spoofing.

Não permita que os mapeamentos de atributos sejam modificados

A federação de identidade da carga de trabalho usa mapeamentos de atributo para selecionar quais atributos fornecidos pelo provedor de identidade externo precisam ser incorporados em um token STS e como os nomes dos atributos precisam ser traduzidos. A configuração de mapeamentos de atributos é uma etapa fundamental da configuração da relação de confiança entre o provedor de identidade externo e o Google Cloud.

Os mapeamentos de atributos também são essenciais para a segurança de uso da federação de identidade da carga de trabalho: se você tiver concedido a um principal federado ou a um conjunto de principais permissão para personificar uma conta de serviço e alterar o mapeamento de atributos posteriormente, talvez você altere os usuários que têm acesso à conta de serviço.

A modificação do mapeamento de atributos requer a permissão iam.googleapis.com/workloadIdentityPoolProviders.update. Os papéis que contêm essa permissão incluem:

  • Proprietário (roles/owner)
  • Administrador de pool de Identidade da carga de trabalho do IAM (roles/iam.workloadIdentityPoolAdmin)

Se um usuário de má-fé tiver permissão para modificar os mapeamentos de atributos, ele conseguirá alterar as regras de mapeamento de forma que permita falsificar a identidade e conseguir acesso a uma conta de serviço. Para evitar modificações mal-intencionadas, verifique se apenas alguns usuários administrativos têm permissão para modificar os mapeamentos de atributos.

Considere criar um projeto dedicado do Cloud para gerenciar pools de identidades de carga de trabalho para limitar o risco de usuários receberem acidentalmente um desses papéis em um nível superior na hierarquia de recursos.

Não dependa de atributos não estáveis ou autoritativos.

Ao usar a federação de identidade de carga de trabalho, você está confiando em um provedor de identidade externo para autenticar usuários e relatar informações precisas sobre o usuário autenticado ao Google Cloud.

Um provedor de identidade usa atributos para comunicar informações sobre usuários autenticados. Embora alguns desses atributos geralmente sejam garantidos como sendo autoritários, outros talvez não sejam. Por exemplo, um provedor de identidade externo pode incorporar um nome de usuário e um ID de usuário em um token de ID do OpenID Connect. Os dois atributos identificam um usuário de maneira exclusiva e podem parecer intercambiáveis. No entanto, o provedor de identidade externo pode permitir que os usuários troquem o nome de usuário, além de garantir que o ID de usuário deles seja estável e autoritário.

Se os mapeamentos de atributos dependem de atributos que não são estáveis ou autoritários, um usuário de má-fé pode conseguir personificar a identidade deles modificando o perfil do usuário no provedor de identidade externo. Por exemplo, ele pode alterar o nome de usuário para o de um usuário que foi excluído recentemente no provedor de identidade externo, mas que ainda tem acesso a uma conta de serviço no Google Cloud.

Para evitar ataques de spoofing, verifique se os mapeamentos de atributos dependem apenas de atributos que o provedor de identidade externo garante que sejam estáveis e autoritários.

Proteção contra ameaças de 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 IAM do recurso. Assim como o próprio recurso, a política de IAM 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 IAM 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 tem permissão para visualizar uma política de IAM também pode ver os endereços de e-mail dos principais 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 do IAM 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.

Proteção 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. 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