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 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 Cloud de Confiance, 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.

Ao acessar os serviços do Cloud de Confiance by S3NS usando a CLI do Google Cloud, as bibliotecas de cliente do Cloud, ferramentas que aceitam o Application Default Credentials (ADC), como o Terraform, ou solicitações REST, use o diagrama abaixo para escolher um método de autenticação:

Esse diagrama oferece orientações para as seguintes perguntas:

1. Você está executando códigos 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 códigos no Cloud de Confiance by S3NS?
   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?
   1. Se sim, 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. Se não for o caso, 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 em um provedor de identidade externo que aceita a federação de identidade da carga de trabalho?
   1. Se sim, 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 de conta de serviço.

Gerenciar contas de serviço

As contas de serviço são diferentes de outros tipos de principais, 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 de usuários individuais 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 mudam de 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 Cloud de Confiance , 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:

• Crie contas de serviço dedicadas para cada aplicativo e evite usar contas de serviço padrão.
• Não use concessões automáticas de papéis para contas de serviço padrão.
• Use as ferramentas do Google para entender o uso da conta de serviço, que ajudam a monitorar o uso e evitar que contas de serviço sejam compartilhadas entre vários aplicativos.

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 para 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 no local.
• 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.

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 exclua-a somente após um determinado período. Ao esperar para excluir a conta de serviço, você garante que pode removê-la com segurança sem afetar nenhuma das suas vinculações do IAM.

É possível excluir contas de serviço padrão, como a conta de serviço padrão do App Engine ou a conta de serviço padrão do Compute Engine. No entanto, considere o seguinte ao decidir se vai excluir uma conta de serviço padrão:

• Ao excluir uma conta de serviço padrão, você melhora a segurança da implantação. No entanto, sem uma conta de serviço padrão, o serviço correspondente não pode implantar automaticamente jobs que acessam outrosCloud de Confiance , a menos que você configure manualmente uma nova conta de serviço e conceda a ela os papéis apropriados.
• Para recriar as contas de serviço padrão, é necessário desativar e reativar a respectiva API, o que pode interromper a implantação atual. Se você não usa as contas de serviço padrão, recomendamos desativá-las.

Antes de excluir uma conta de serviço padrão, recomendamos verificar se você a usa na sua implantação. Para instruções sobre como conferir o uso de uma conta de serviço específica, consulte Visualizar métricas de uso de uma única conta de serviço.

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 qualquer outro tipo de principal. No entanto, as contas de serviço geralmente têm mais acesso a mais recursos do que outros tipos de principais. 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 Cloud de Confiance by S3NS criam contas de serviço padrão quando você ativa a API em um projeto do Cloud de Confiance 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 Cloud de Confiance , o que permite que elas leiam e modifiquem todos os recursos no projeto Cloud de Confiance . 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 de Confiance ,os serviços do Cloud de Confiance 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 Cloud de Confiance , configure-a na pasta ou no nó da organização. A aplicação da restrição não remove 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 seus recursos do Cloud de Confiance . 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.

Se todas as contas de serviço atuais e futuras em um projeto, pasta ou organização específica compartilharem requisitos, use conjuntos de principais da conta de serviço para conceder papéis a elas em vez de usar grupos personalizados.

Use a API Service Account 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. Isso acontece porque, a qualquer momento, o aplicativo provavelmente terá 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 Service Account 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.

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.

Por exemplo, pense em uma conta de serviço que tenha acesso total a um bucket do Cloud Storage com informações sensíveis. Nesse caso, a conta de serviço é tão valiosa quanto o 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. Se essa tentativa for bem-sucedida, o usuário de má-fé poderá escalonar os privilégios personificando a conta de serviço, o que, por sua vez, dá acesso às informações sensíveis 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, Cloud de Confiance projeto ou pasta. 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.

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 Cloud de Confiance atual 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 Cloud de Confiance atual, 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 pessoa 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 doCloud de Confiance 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 de Confiance 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 de Confiance 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 de Confiance

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 Cloud de Confiance envolvente
• De uma pasta na ancestralidade do projeto Cloud de Confiance
• Do nó da organização

Gerenciar o acesso no nível do projeto do Cloud de Confiance 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 Cloud de Confiance , o usuário poderá personificar qualquer conta de serviço no projeto Cloud de Confiance . 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 Cloud de Confiance .

Para evitar essa concessão excessiva, não gerencie o acesso a contas de serviço no nível do projeto ou da pasta doCloud de Confiance . 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, 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 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 Cloud de Confiance.

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 de Confiance , 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 Cloud de Confiance e a visibilidade dele também é controlada por esse outro projeto Cloud de Confiance .

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.s3ns.iam.gserviceaccount.com. Para um usuário de má-fé, esse endereço de e-mail não apenas revela que há um projeto Cloud de Confiance com ID deployment-project-123, mas também que o projeto Cloud de Confiance executa um servidor Jenkins. Ao escolher um nome mais genérico, como deployer@deployment-project-123.s3ns.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 Cloud de Confiance com acesso menos controlado (como um sandbox ou um projeto de desenvolvimento doCloud de Confiance ), 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 Cloud de Confiance, 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 realizada por uma conta de serviço, essa informação por si só pode não ser suficiente para reconstruir toda a cadeia de eventos. Nesses casos, 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.

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 Cloud de Confiance 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 aos 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 doCloud de Confiance que contêm contas de serviço
• API Security Token Service em todos os projetos do Cloud de Confiance que contêm pools de identidades 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 Cloud de Confiance, essas mudanças 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 Cloud de Confiance, 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 Cloud de Confiance. 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 Cloud de Confiance 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

• Entenda as práticas recomendadas para gerenciar chaves de contas de serviço.
• Revise nossas práticas recomendadas para usar contas de serviço em pipelines de implantação.
• Conheça as práticas recomendadas para usar a federação de identidade da carga de trabalho.