Práticas recomendadas para usar contas de serviço

As contas de serviço representam utilizadores não humanos. Destinam-se a cenários em que uma carga de trabalho, como uma aplicação personalizada, precisa de aceder a recursos ou realizar ações sem a participação do utilizador final.

Embora as contas de serviço sejam uma ferramenta útil, existem várias formas de abusar de uma conta de serviço:

• Aumento de privilégios: um ator malicioso pode obter acesso a recursos aos quais, de outra forma, não teria acesso, fazendo-se passar pela conta de serviço.
• Roubo de identidade: um interveniente malicioso pode usar a representação da conta de serviço para ocultar a respetiva identidade.
• Não repúdio: um autor malicioso pode ocultar a respetiva identidade e ações através da utilização de uma conta de serviço para realizar operações em seu nome. Em alguns casos, pode não ser possível rastrear estas ações até ao interveniente prejudicial.
• Divulgação de informações: um ator malicioso pode obter informações sobre a sua infraestrutura, aplicações ou processos a partir da existência de determinadas contas de serviço.

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

• Uma vez que uma conta de serviço é um principal, tem de limitar os respetivos privilégios para reduzir o potencial dano que pode ser causado por uma conta de serviço comprometida.
• Uma vez que uma conta de serviço é um recurso, tem de a proteger contra o compromisso.

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

Escolha quando usar contas de serviço

Nem todos os cenários requerem uma conta de serviço para aceder aos Google Cloud serviços, 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 evite usar chaves de contas de serviço sempre que possível.

Quando acede aos Google Cloud serviços através da CLI Google Cloud, das bibliotecas de cliente da nuvem, das ferramentas que suportam as credenciais predefinidas da aplicação (ADC) como o Terraform ou os pedidos REST, use o diagrama seguinte para ajudar a escolher um método de autenticação:

Este diagrama orienta-o através das seguintes perguntas:

1. Está a executar código num ambiente de desenvolvimento de utilizador único, como a sua própria estação de trabalho, o Cloud Shell ou uma interface de computador virtual?
   1. Em caso afirmativo, avance para a pergunta 4.
   2. Caso contrário, avance para a pergunta 2.
2. Está a executar código no Google Cloud?
   1. Em caso afirmativo, avance para a pergunta 3.
   2. Caso contrário, avance para a pergunta 5.
3. Está a executar contentores no Google Kubernetes Engine?
   1. Em caso afirmativo, use a federação de identidades da carga de trabalho para o GKE para anexar contas de serviço a pods do Kubernetes.
   2. Se não, anexe uma conta de serviço ao recurso.

4. O seu exemplo de utilização requer uma conta de serviço?

   Por exemplo, quer configurar a autenticação e a autorização de forma consistente para a sua aplicação em todos os ambientes.

   1. Se não, autentique com as credenciais do utilizador.
   2. Se sim, use a identidade de uma conta de serviço com credenciais de utilizador.
5. A sua carga de trabalho autentica-se com um fornecedor de identidade externo que suporta a federação de identidade da carga de trabalho?
   1. Se sim, configure a federação de identidades da carga de trabalho para permitir que as aplicações executadas no local ou noutros fornecedores de nuvem usem uma conta de serviço.
   2. Se não, crie uma chave de conta de serviço.

Faça a gestão das contas de serviço

As contas de serviço diferem de outros tipos de responsáveis, não só na forma como são usadas, mas também na forma como têm de ser geridas. As secções seguintes fornecem práticas recomendadas para gerir contas de serviço.

Faça a gestão das contas de serviço como recursos

Normalmente, as contas de utilizadores individuais são geridas de acordo com os processos de admissão, transferência e saída de uma organização: quando um funcionário é admitido, é criada uma nova conta de utilizador para o mesmo. Quando mudam de departamento, a respetiva conta de utilizador é atualizada. Além disso, quando sai da empresa, a respetiva conta de utilizador é suspensa ou eliminada.

Por outro lado, as contas de serviço não estão associadas a nenhum funcionário específico. Em alternativa, é melhor pensar nas contas de serviço como recursos que pertencem ou fazem parte de outro recurso, como uma instância de VM específica ou uma aplicação.

Para gerir eficazmente as contas de serviço, não as analise isoladamente. Em alternativa, considere-as no contexto do recurso ao qual estão associadas e faça a gestão da conta de serviço e do respetivo recurso associado como uma unidade: aplique os mesmos processos, o mesmo ciclo de vida e a mesma diligência à conta de serviço e ao respetivo recurso associado, e use as mesmas ferramentas para os gerir.

Crie contas de serviço de finalidade única

A partilha de uma única conta de serviço em várias aplicações pode complicar a gestão da conta de serviço:

• As aplicações podem ter ciclos de vida diferentes. Se uma aplicação for desativada, pode não ser claro se a conta de serviço também pode ser desativada ou se ainda é necessária.
• Ao longo do tempo, os requisitos de acesso das aplicações podem divergir. Se as aplicações usarem a mesma conta de serviço, pode ter de conceder à conta de serviço acesso a um número crescente de recursos, o que, por sua vez, aumenta o risco geral.
• Os registos de auditoria da nuvem incluem o nome da conta de serviço que efetuou uma alteração ou acedeu aos dados, mas não mostram o nome da aplicação que usou a conta de serviço. Se várias aplicações partilharem uma conta de serviço, pode não conseguir rastrear a atividade até à aplicação correta.

Em particular, alguns Google Cloud serviços, incluindo o App Engine e o Compute Engine, criam uma conta de serviço predefinida que tem a função de editor (roles/editor) no projeto por predefinição. Quando 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 predefinida. Embora a conta de serviço predefinida facilite o início, é muito arriscado partilhar uma conta de serviço tão poderosa em várias aplicações.

Pode tomar várias medidas para evitar estas complicações:

• Crie contas de serviço dedicadas para cada aplicação e evite usar contas de serviço predefinidas.
• Não use concessões de funções automáticas para contas de serviço predefinidas.
• Use as ferramentas da Google para compreender a utilização das contas de serviço, o que pode ajudar a monitorizar a utilização e impedir que as contas de serviço sejam partilhadas em várias aplicações.

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

Para ajudar a acompanhar a associação entre um serviço e uma aplicação ou um recurso, siga uma convenção de nomenclatura quando criar novas contas de serviço:

• Adicione um prefixo ao endereço de email da conta de serviço que identifique 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 identidades da carga de trabalho para o GKE.
  • wlif- para contas de serviço usadas pela federação de identidades da carga de trabalho.
  • onprem- para contas de serviço usadas por aplicações no local.
• Incorporar o nome da aplicação no endereço de email da conta de serviço, por exemplo: vm-travelexpenses@ se a VM executar uma aplicação de despesas de viagens.
• Use o campo de descrição para adicionar uma pessoa de contacto, links para documentação relevante ou outras notas.

Não incorpore informações confidenciais nem termos no endereço de email de uma conta de serviço.

Identifique e desative contas de serviço não usadas

Quando uma conta de serviço deixa de ser usada, desative-a. Ao desativar contas de serviço não usadas, reduz o risco de as contas de serviço serem usadas indevidamente para movimento lateral ou para elevação de privilégios por um agente malicioso.

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

Para contas de serviço usadas para vários fins ou partilhadas em vários recursos, pode ser mais difícil identificar se a conta de serviço ainda é usada. Nestes casos, pode usar o analisador de atividade para ver as atividades de autenticação mais recentes das suas contas de serviço.

Desative as contas de serviço não usadas antes de as eliminar

Se eliminar uma conta de serviço e, em seguida, criar uma nova conta de serviço com o mesmo nome, é atribuída uma identidade diferente à nova conta de serviço. Como resultado, nenhuma das vinculações de IAM originais se aplica à nova conta de serviço. Por outro lado, se desativar e reativar uma conta de serviço, todas as associações do IAM permanecem intactas.

Para evitar perder inadvertidamente associações de IAM, é melhor não eliminar contas de serviço imediatamente. Em alternativa, desative uma conta de serviço se já não for necessária e elimine-a apenas após um determinado período.

Nunca elimine contas de serviço predefinidas, como a conta de serviço predefinida do App Engine ou a conta de serviço predefinida do Compute Engine. Não é possível recriar estas contas de serviço sem desativar e reativar a API respetiva, o que pode afetar a implementação existente. Se não usar as contas de serviço predefinidas, desative-as.

Limite 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 têm frequentemente maior acesso a mais recursos do que outros tipos de principais. Além disso, à medida que adiciona funcionalidades às suas aplicações, as respetivas contas de serviço tendem a ganhar cada vez mais acesso ao longo do tempo. Também pode esquecer-se de revogar o acesso que já não é necessário.

Não use concessões de funções automáticas para contas de serviço predefinidas

Alguns Google Cloud serviços criam contas de serviço predefinidas quando ativa pela primeira vez a respetiva API num Google Cloud projeto. Consoante a configuração da política da organização, estas contas de serviço podem receber automaticamente a função de editor (roles/editor) no seu Google Cloud projeto, o que lhes permite ler e modificar todos os recursos no Google Cloud projeto. A função é concedida para sua conveniência, mas não é essencial para o funcionamento dos serviços: para aceder aos recursos no seu Google Cloud projeto Google Cloud , os serviços usam agentes de serviço e não as contas de serviço predefinidas.

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

Se aplicar esta restrição, as contas de serviço predefinidas em novos projetos não têm acesso aos seus Google Cloud recursos. Tem de conceder funções adequadas às contas de serviço predefinidas para que possam aceder aos seus recursos.

Não confie nos âmbitos de acesso quando anexar uma conta de serviço a uma instância de VM

Quando anexa uma conta de serviço a uma instância de VM, pode especificar um ou mais âmbitos de acesso. Os âmbitos de acesso permitem restringir os serviços aos quais a VM pode aceder. As restrições são aplicadas além das políticas de permissão.

Os âmbitos de acesso são pouco detalhados. Por exemplo, ao usar o âmbito https://www.googleapis.com/auth/devstorage.read_only, pode restringir o acesso a operações de leitura do Cloud Storage, mas não pode restringir o acesso a contentores específicos. Por conseguinte, os âmbitos de acesso não são uma substituição adequada para políticas de autorização detalhadas.

Em vez de depender dos âmbitos de acesso, crie uma conta de serviço dedicada e use políticas de autorização detalhadas para restringir os recursos aos quais a conta de serviço tem acesso.

Se todas as contas de serviço atuais e futuras num projeto, numa pasta ou numa organização específicos partilharem requisitos, use conjuntos de principais de contas de serviço para lhes conceder funções em vez de usar grupos personalizados.

Para mais informações, consulte o artigo Práticas recomendadas para usar os Grupos Google.

Evite usar a delegação ao nível do domínio

A delegação ao nível do domínio permite que uma conta de serviço se faça passar por qualquer utilizador numa conta do Cloud ID ou do Google Workspace. A delegação ao nível do domínio permite que uma conta de serviço execute determinadas tarefas administrativas no Google Workspace e no Cloud Identity, ou aceda a APIs Google que não suportam contas de serviço fora do Google Cloud.

A delegação ao nível do domínio não restringe uma conta de serviço a roubar a identidade de um utilizador específico, mas permite-lhe roubar a identidade de qualquer utilizador numa conta do Cloud Identity ou do Google Workspace, incluindo superadministradores. Por conseguinte, permitir que uma conta de serviço use a delegação ao nível do domínio pode tornar a conta de serviço um alvo atrativo para ataques de escalada de privilégios.

Evite usar a delegação ao nível do domínio se puder realizar a sua tarefa diretamente com uma conta de serviço ou usando o fluxo de consentimento do OAuth. Por exemplo, se precisar de usar o Google Drive para armazenar ficheiros, pode usar diretamente uma conta de serviço para carregar ficheiros para um disco partilhado ou pode usar o fluxo de consentimento do OAuth 2.0 para carregar ficheiros em nome de um utilizador.

Se não puder evitar a utilização da delegação ao nível do domínio, restrinja o conjunto de âmbitos do OAuth que a conta de serviço pode utilizar. Embora os âmbitos do OAuth não restrinjam os utilizadores que a conta de serviço pode representar, restringem os tipos de dados do utilizador aos quais a conta de serviço pode aceder.

Tenha em atenção que as contas de serviço não podem ser diretamente proprietárias de recursos no Google Workspace. Se precisar de usar o Google Drive para armazenar ficheiros em vez de usar contentores, carregue os ficheiros diretamente para um disco partilhado, opere em nome de um utilizador através do fluxo de consentimento do OAuth 2.0 ou use a delegação ao nível do domínio.

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

Algumas aplicações só requerem acesso a determinados recursos em momentos específicos ou em circunstâncias específicas. Por exemplo:

• Uma aplicação pode exigir acesso a dados de configuração durante o arranque, mas pode não exigir esse acesso depois de inicializada.
• Uma aplicação de supervisão pode iniciar periodicamente tarefas em segundo plano em que cada tarefa tem requisitos de acesso diferentes.

Em tais cenários, a utilização de uma única conta de serviço e a concessão de acesso a todos os recursos vai contra o princípio do menor privilégio. Isto deve-se ao facto de, em qualquer momento, a aplicação ter provavelmente acesso a mais recursos do que realmente precisa.

Para ajudar a garantir que as diferentes partes da sua aplicação só têm acesso aos recursos de que precisam, use a API Service Account Credentials para a elevação temporária de privilégios:

• Crie contas de serviço dedicadas para cada parte da aplicação ou exemplo de utilização e conceda apenas à conta de serviço acesso aos recursos necessários.
• Crie outra conta de serviço que funcione como supervisor. Conceda à conta de serviço do supervisor a função de criador de tokens de contas de serviço nas outras contas de serviço para que possa pedir tokens de acesso de curta duração para estas contas de serviço.
• Divida a sua aplicação para que uma parte da aplicação funcione como agente de tokens e permita que apenas esta parte da aplicação use as contas de serviço do supervisor.
• Use o agente de tokens para emitir contas de serviço de curta duração para as outras partes da aplicação.

Para obter ajuda com a criação de credenciais de curta duração, consulte o artigo Crie credenciais de curta duração para uma conta de serviço.

Use limites de acesso às credenciais para reduzir o âmbito dos tokens de acesso

Os tokens de acesso da Google são tokens de portador, o que significa que a respetiva utilização não está associada a nenhuma aplicação específica. Se a sua aplicação transmitir um token de acesso a uma aplicação diferente, essa outra aplicação pode usar o token da mesma forma que a sua aplicação. Da mesma forma, se um token de acesso for divulgado a um interveniente prejudicial, este pode usar o token para obter acesso.

Uma vez que os tokens de acesso são tokens de portador, tem de os proteger contra fugas ou visibilidade por partes não autorizadas. Pode limitar os danos potenciais que um token de acesso divulgado pode causar restringindo os recursos aos quais concede acesso. Este processo é denominado redução do âmbito.

Use limites de acesso a credenciais para reduzir o âmbito dos tokens de acesso sempre que passa um token de acesso a uma aplicação diferente ou a um componente diferente da sua aplicação. Defina o limite de acesso de modo que o token conceda acesso suficiente aos recursos necessários, mas não mais.

Use recomendações de funções para identificar autorizações não usadas

Quando implementa uma aplicação pela primeira vez, pode não saber que funções e permissões a aplicação precisa realmente. Como resultado, pode conceder à conta de serviço da aplicação mais autorizações do que as necessárias.

Da mesma forma, os requisitos de acesso de uma aplicação podem evoluir ao longo do tempo e algumas das funções e autorizações que concedeu inicialmente podem não ser necessárias.

Use as recomendações de funções para identificar as autorizações que uma aplicação está realmente a usar e as autorizações que podem não estar a ser usadas. Ajuste as políticas de autorização dos recursos afetados para ajudar a garantir que uma aplicação não recebe mais acesso do que realmente precisa.

Use as estatísticas de movimento lateral para limitar o movimento lateral

O movimento lateral ocorre quando uma conta de serviço num projeto tem autorização para se fazer passar por uma conta de serviço noutro projeto. Por exemplo, uma conta de serviço pode ter sido criada no projeto A, mas ter autorizações para se fazer passar por uma conta de serviço no projeto B.

Estas autorizações podem resultar numa cadeia de roubos de identidade entre projetos que concede aos responsáveis acesso não intencional aos recursos. Por exemplo, um principal pode roubar a identidade de uma conta de serviço no projeto A e, em seguida, usar essa conta de serviço para roubar a identidade de uma conta de serviço no projeto B. Se a conta de serviço no projeto B tiver autorização para se fazer passar por outras contas de serviço noutros projetos na sua organização, o principal pode continuar a usar a representação da conta de serviço para se mover de projeto em projeto, obtendo autorizações à medida que avança.

O Recomendador fornece estatísticas de movimento lateral para ajudar a mitigar este problema. As estatísticas de movimento lateral identificam funções que permitem que uma conta de serviço num projeto se faça passar por uma conta de serviço noutro projeto. Para saber como ver e gerir as estatísticas de movimento lateral diretamente, consulte o artigo Gerir estatísticas de movimento lateral.

Algumas estatísticas de movimento lateral estão associadas a recomendações de funções. Pode aplicar essas recomendações para reduzir o movimento lateral nos seus projetos. Para saber como, consulte o artigo Reveja e aplique recomendações.

Proteja-se contra ameaças de escalada de privilégios

Uma conta de serviço à qual não foram concedidas funções, que não tem acesso a recursos e que não está associada a regras de firewall, tem normalmente um valor limitado. Depois de conceder a uma conta de serviço acesso a recursos, o valor da conta de serviço aumenta: a conta de serviço torna-se mais útil para si, mas também se torna um alvo mais atrativo para ataques de escalada de privilégios.

Por exemplo, considere uma conta de serviço que tenha acesso total a um contentor do Cloud Storage que contenha informações confidenciais. Nesta situação, a conta de serviço é tão valiosa quanto o contentor do Cloud Storage. Em vez de tentar aceder diretamente ao contentor, um interveniente malicioso pode tentar assumir o controlo da conta de serviço. Se essa tentativa for bem-sucedida, o autor da ameaça pode aumentar os respetivos privilégios ao roubar a identidade da conta de serviço, o que, por sua vez, lhe dá acesso às informações confidenciais no contentor.

As técnicas de escalada de privilégios que envolvem contas de serviço enquadram-se normalmente nestas categorias:

• Autenticação como conta de serviço: pode conceder inadvertidamente a um utilizador autorização para usar a identidade de uma conta de serviço ou para 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 utilizador, o utilizador pode autenticar-se como a conta de serviço para aumentar os respetivos privilégios e obter acesso a recursos aos quais, de outra forma, não conseguiria aceder.

• Usar recursos que tenham uma conta de serviço anexada: se um utilizador tiver permissão para aceder e modificar pipelines de CI/CD, instâncias de VMs ou outros sistemas de automatização que tenham contas de serviço anexadas, pode conseguir realizar ações através das contas de serviço anexadas desses recursos. Como resultado, apesar de não terem autorização para se fazerem passar pela conta de serviço, podem continuar a usar as autorizações da conta de serviço para realizar ações que não lhes seriam permitidas.

  Por exemplo, se um utilizador tiver acesso SSH a uma instância de VM do Compute Engine, pode executar código na instância para aceder a qualquer recurso ao qual a conta de serviço anexada da instância possa aceder.

• Permitir modificações de políticas, grupos ou funções personalizadas: um utilizador que não tenha acesso a uma conta de serviço privilegiada pode continuar a ter autorização para modificar as políticas de permissão da conta de serviço, incluindo oGoogle Cloud projeto ou a pasta. Em seguida, o utilizador pode expandir uma destas políticas de autorização para se conceder a si próprio autorização para (direta ou indiretamente) autenticar como a conta de serviço.

As secções seguintes fornecem práticas recomendadas para proteger as contas de serviço de ameaças de escalada de privilégios.

Evite permitir que os utilizadores façam a autenticação como contas de serviço com mais privilégios do que os próprios utilizadores

Ao roubar a identidade de uma conta de serviço, um utilizador ganha acesso a alguns ou a todos os recursos aos quais a conta de serviço pode aceder. Se a conta de serviço tiver um acesso mais extenso do que o utilizador, é efetivamente mais privilegiada do que o utilizador.

Conceder a um utilizador autorização para se fazer passar por uma conta de serviço com mais privilégios pode ser uma forma de permitir deliberadamente que os utilizadores elevem temporariamente os respetivos privilégios, semelhante à utilização da ferramenta sudo no Linux ou à utilização da elevação de processos no Windows. A menos que esteja a lidar com um cenário em que essa elevação temporária de privilégios seja necessária, é melhor evitar que os utilizadores se façam passar por uma conta de serviço com mais privilégios.

Os utilizadores também podem obter indiretamente as autorizações de uma conta de serviço anexando-a a um recurso e, em seguida, executando código nesse recurso. A execução de código desta forma não é uma representação da conta de serviço porque envolve apenas uma identidade autenticada (a da conta de serviço). No entanto, pode conceder a um utilizador acesso que, de outra forma, não teria.

As autorizações que permitem a um utilizador usar a identidade de uma conta de serviço ou anexar uma conta de serviço a um recurso incluem o seguinte:

• 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

As funções que contêm algumas destas autorizações incluem (mas não se limitam a):

• Proprietário (roles/owner)
• Editor (roles/editor)
• Utilizador da conta de serviço (roles/iam.serviceAccountUser)
• Criador de tokens de contas 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)
• Utilizador do Workload Identity (roles/iam.workloadIdentityUser)
• Editor do Deployment Manager (roles/deploymentmanager.editor)
• Editor do Cloud Build (roles/cloudbuild.builds.editor)

Antes de atribuir qualquer uma destas funções a um utilizador, pondere o seguinte:

• A que recursos dentro e fora do projeto atual é que o utilizador pode aceder ao roubar a identidade da conta de serviço? Google Cloud
• Este nível de acesso é justificado?
• Existem proteções suficientes em vigor que controlam as circunstâncias em que o utilizador pode roubar a identidade da conta de serviço?

Não atribua a função se não conseguir confirmar todas as perguntas. Em alternativa, considere atribuir ao utilizador uma conta de serviço diferente com menos privilégios.

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

Os utilizadores que podem usar ou roubar a identidade de uma conta de serviço são captados pela política de autorização da conta de serviço. A política de permissão pode ser modificada ou alargada por utilizadores que tenham a autorização iam.serviceAccounts.setIamPolicy na conta de serviço específica. As funções que contêm essa autorização incluem:

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

As funções que incluem a autorização iam.serviceAccounts.setIamPolicy dão a um utilizador controlo total sobre uma conta de serviço:

• O utilizador pode conceder a si próprio autorização para se fazer passar pela conta de serviço, o que lhe dá a capacidade de aceder aos mesmos recursos que a conta de serviço.
• O utilizador pode conceder a outros utilizadores o mesmo nível de acesso ou um nível semelhante à conta de serviço.

Antes de atribuir qualquer uma destas funções a um utilizador, pergunte-se a que recursos dentro e fora do projeto atual o utilizador pode obter acesso ao roubar a identidade da conta de serviço. Google Cloud Não permita que um utilizador altere a política de autorização de uma conta de serviço se a conta de serviço tiver mais privilégios do que o utilizador.

Não permitir que os utilizadores criem nem carreguem chaves de contas de serviço

As chaves de contas de serviço permitem que as aplicações ou os utilizadores se autentiquem como uma conta de serviço. Ao contrário de outras formas de representação de contas de serviço, a utilização de uma chave de conta de serviço não requer qualquer forma de autenticação anterior. Qualquer pessoa que possua uma chave de conta de serviço pode utilizá-la.

O efeito líquido da utilização de uma chave de conta de serviço para autenticar é semelhante ao efeito da simulação da conta de serviço. Se um utilizador tiver acesso a uma chave de conta de serviço ou lhe for concedida autorização para criar uma nova chave de conta de serviço, o utilizador pode autenticar-se como a conta de serviço e aceder a todos os recursos aos quais a conta de serviço pode aceder.

Criar ou carregar uma chave de conta de serviço requer a autorização iam.serviceAccountKeys.create, que está incluída nas funções de administrador da chave de conta de serviço (roles/iam.serviceAccountKeyAdmin) e editor (roles/editor).

Antes de atribuir qualquer função que inclua a autorização iam.serviceAccountKeys.create a um utilizador, pergunte-se a que recursos dentro e fora do projeto Google Cloud atual o utilizador pode obter acesso ao roubar a identidade da conta de serviço. Não permitir que um utilizador crie chaves de contas de serviço para contas de serviço que tenham mais privilégios do que ele.

Se o seu Google Cloud projeto não precisar de chaves de contas de serviço, aplique as restrições da política da organização Desativar a criação de chaves de contas de serviço e Desativar o carregamento de chaves de contas de serviço ao Google Cloud projeto ou à pasta que o contém. Estas restrições impedem que todos os utilizadores criem e carreguem chaves de contas de serviço, incluindo os que têm a autorização iam.serviceAccountKeys.create numa conta de serviço.

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

As contas de serviço são recursos e fazem parte da hierarquia de recursos. Por conseguinte, pode gerir o acesso às contas de serviço em qualquer um dos seguintes níveis:

• A conta de serviço individual
• O Google Cloud projeto
• Uma pasta na hierarquia do projeto Google Cloud
• O nó da organização

A gestão do acesso ao Google Cloud nível do projeto ou a um nível superior da hierarquia de recursos pode ajudar a reduzir os custos administrativos, mas também pode levar à concessão excessiva de privilégios. Por exemplo, se conceder a um utilizador a função de criador de tokens de conta de serviço num Google Cloud projeto, o utilizador pode roubar a identidade de qualquer conta de serviço no Google Cloud projeto. A capacidade de se fazer passar por qualquer conta de serviço implica que o utilizador pode potencialmente obter acesso a todos os recursos aos quais essas contas de serviço podem aceder, incluindo recursos fora desse projeto Google Cloud .

Para evitar a concessão excessiva, não faça a gestão do acesso às contas de serviço ao Google Cloud nível do projeto ou da pasta. Em alternativa, pode gerir individualmente o acesso de cada conta de serviço.

Não execute código de fontes menos protegidas em recursos de computação que tenham uma conta de serviço privilegiada associada

Quando associa uma conta de serviço a um recurso de computação, como uma instância de VM, os processos em execução nesse recurso podem usar o servidor de metadados para pedir tokens de acesso e tokens de ID. Estes tokens permitem que o processo seja autenticado como a conta de serviço e aceda aos recursos em nome da mesma.

Por predefinição, o acesso ao servidor de metadados não está restrito a processos ou utilizadores específicos. Em alternativa, qualquer código executado no recurso de computação pode aceder ao servidor de metadados e obter uma chave de acesso. Esse código pode incluir:

• O código da sua aplicação.
• Código enviado por utilizadores finais, se a sua aplicação permitir qualquer avaliação de scripts do lado do servidor.
• Código lido a partir de um repositório de origem remoto, se o recurso de computação fizer parte de um sistema de CI/CD.
• Scripts de arranque e encerramento disponibilizados por um contentor do Cloud Storage.
• Políticas de convidados distribuídas pelo VM Manager.

Se o código for enviado por utilizadores ou lido a partir de uma localização de armazenamento remoto, tem de se certificar de que é fidedigno e que as localizações de armazenamento remoto estão, pelo menos, tão bem protegidas como a conta de serviço anexada. Se uma localização de armazenamento remoto estiver menos bem protegida do que a conta de serviço, um agente malicioso pode conseguir aumentar os respetivos privilégios. Podem fazê-lo injetando código malicioso que usa os privilégios da conta de serviço nessa localização.

Limite o acesso à shell a VMs que tenham uma conta de serviço privilegiada anexada

Alguns recursos de computação suportam o acesso interativo e permitem que os utilizadores obtenham acesso à shell do sistema. Por exemplo:

• O Compute Engine permite-lhe usar SSH ou RDP para iniciar sessão numa instância de VM.
• O Google Kubernetes Engine permite-lhe usar kubectl exec para executar um comando ou iniciar uma shell num contentor do Kubernetes.

Se uma instância de VM tiver uma conta de serviço privilegiada anexada, qualquer utilizador com acesso à shell do sistema pode autenticar e aceder aos recursos como a conta de serviço. Para impedir que os utilizadores abusem desta capacidade para aumentar os respetivos privilégios, tem de garantir que o acesso à shell está, pelo menos, tão bem protegido quanto a conta de serviço associada.

Para instâncias do Linux, pode aplicar o acesso SSH de forma mais restritiva do que o acesso à conta de serviço anexada através do Início de sessão do SO: para estabelecer ligação a uma instância de VM com o Início de sessão do SO ativado, um utilizador não só tem de ter autorização para usar o Início de sessão do SO, como também tem de ter a autorização iam.serviceAccounts.actAs na conta de serviço anexada.

O mesmo nível de controlo de acesso não se aplica a instâncias de VMs que usam chaves baseadas em metadados nem a instâncias do Windows: a publicação de uma chave SSH nos metadados ou o pedido de credenciais do Windows requer acesso aos metadados da instância de VM e à autorização iam.serviceAccounts.actAs na conta de serviço anexada. No entanto, depois de a chave SSH ter sido publicada ou as credenciais do Windows terem sido obtidas, os inícios de sessão subsequentes não estão sujeitos a verificações de autorizações da IAM adicionais.

Da mesma forma, se uma instância de VM usar um módulo de autenticação conectável do Linux personalizado para autenticação ou for membro de um domínio do Active Directory, é possível que os utilizadores que, de outra forma, não teriam autorização para autenticar como a conta de serviço tenham autorização para iniciar sessão. Para mais informações, consulte as práticas recomendadas para executar o Active Directory no Google Cloud.

Em particular, para instâncias de VM que não usam o início de sessão no SO, considere restringir o acesso à shell através do proxy com reconhecimento de identidade. Conceda apenas a função de utilizador do túnel protegido pelo IAP (roles/iap.tunnelResourceAccessor) aos utilizadores aos quais deve ser permitido autenticar como a conta de serviço anexada à instância de VM.

Limite o acesso ao servidor de metadados a utilizadores e processos selecionados

Quando anexa uma conta de serviço a uma instância de VM, as cargas de trabalho implementadas na VM podem aceder ao servidor de metadados para pedir tokens para as contas de serviço. Por predefinição, o acesso ao servidor de metadados não está limitado a nenhum processo ou utilizador específico na VM. Mesmo os processos executados como um utilizador com poucos privilégios, como nobody no Linux ou LocalService no Windows, têm acesso total ao servidor de metadados e podem obter tokens para a conta de serviço.

Para limitar o acesso ao servidor de metadados a utilizadores específicos, configure a firewall do anfitrião do sistema operativo convidado para permitir apenas que estes utilizadores abram ligações de saída para o servidor de metadados.

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

Proteja-se contra ameaças de divulgação de informações

Evite divulgar informações confidenciais em endereços de email de contas de serviço

Para conceder a uma conta de serviço acesso a um recurso noutro Google Cloud projeto, pode adicionar uma associação de funções à política de autorização do recurso. Tal como o próprio recurso, a política de autorização faz parte do outro Google Cloud projeto e a respetiva visibilidade também é controlada por esse outro Google Cloud projeto.

Normalmente, a visualização de políticas de autorização não é considerada uma operação privilegiada. Muitas funções incluem a autorização *.getIamPolicy necessária, incluindo a função básica de leitor.

Um utilizador que pode ver uma política de autorização também pode ver os endereços de email dos diretores aos quais foi concedido acesso ao recurso. No caso das contas de serviço, os endereços de email podem dar pistas a intervenientes prejudiciais.

Por exemplo, uma política de autorização pode incluir uma associação para uma conta de serviço com o endereço de email jenkins@deployment-project-123.iam.gserviceaccount.com. Para um ator malicioso, este endereço de email não só revela que existe um Google Cloud projeto com o ID deployment-project-123, mas também que o Google Cloud projeto executa um servidor Jenkins. Ao escolher um nome mais genérico, como deployer@deployment-project-123.iam.gserviceaccount.com, evita a divulgação de informações sobre o tipo de software que está a usar no deployment-project-123.

Se conceder a uma conta de serviço acesso a recursos num Google Cloud projeto com acesso menos rigoroso (como uma sandbox ou um projeto de Google Cloud desenvolvimento), certifique-se de que o endereço de email da conta de serviço não divulga informações. Em particular, não divulgue informações confidenciais nem informações que possam dar pistas aos atacantes.

Proteja-se contra ameaças de não repúdio

Sempre que detetar atividade suspeita que afete um dos seus recursos no Google Cloud, os registos de auditoria na nuvem são uma fonte importante de informações para saber quando ocorreu a atividade e que utilizadores estiveram envolvidos.

Sempre que os registos de auditoria da nuvem indicam que a atividade foi realizada por uma conta de serviço, essas informações por si só podem não ser suficientes para reconstruir a cadeia completa de eventos. Nestes casos, também tem de conseguir saber que utilizador ou aplicação fez com que a conta de serviço realizasse a atividade.

Esta secção contém práticas recomendadas que podem ajudar a manter uma trilha de auditoria não repudiável.

Use chaves de contas de serviço apenas quando não existir uma alternativa viável

Se não conseguir usar métodos de autenticação mais seguros, pode ter de criar uma chave de conta de serviço para a aplicação. No entanto, a autenticação com uma chave de conta de serviço introduz uma ameaça de não repúdio. Os registos de auditoria do Cloud criam um registo quando uma conta de serviço modifica um recurso, mas se a conta de serviço for autenticada com uma chave de conta de serviço, não existe uma forma fiável de saber quem usou a chave. Em comparação, a autenticação como uma conta de serviço através da representação da conta de serviço com credenciais de utilizador regista o principal que atuou como a conta de serviço.

Recomendamos que impeça a criação de chaves de contas de serviço aplicando a restrição da política da organização Desativar a criação de chaves de contas de serviço ao Google Cloud projeto ou à pasta envolvente. Se tiver de usar chaves de conta de serviço para um cenário que não possa ser resolvido com nenhuma das alternativas recomendadas, conceda uma exceção à restrição da política, o mais restritamente possível, e reveja as práticas recomendadas para gerir chaves de conta de serviço.

Ative os registos de acesso aos dados para APIs IAM

Para ajudar a identificar e compreender cenários de roubo de identidade de contas de serviço, os serviços como o Compute Engine incluem uma secção serviceAccountDelegationInfo nos registos de auditoria do Cloud. Esta secção indica se a conta de serviço estava a ser roubada e por que utilizador.

Nem todos os serviços incluem detalhes de roubo de identidade nos respetivos registos de auditoria do Cloud. Para registar todos os eventos de roubo de identidade, também tem de ativar os registos de acesso a dados para as seguintes APIs:

• API Identity and Access Management (IAM) em todos os Google Cloud projetos que contêm contas de serviço
• API Security Token Service em todos os Google Cloud projetos que contêm Workload Identity Pools

Ao ativar estes registos, garante que é adicionada uma entrada aos registos de auditoria na nuvem sempre que um utilizador pede um token de acesso ou um token de ID para uma conta de serviço.

Certifique-se de que o histórico de CI/CD pode ser correlacionado com os registos de auditoria do Cloud

As contas de serviço são usadas frequentemente por sistemas de CI/CD para fazer implementações depois de uma alteração de código ter sido validada e aprovada com êxito para implementação. Normalmente, os sistemas de CI/CD mantêm um histórico de eventos que levam a uma implementação. Este histórico pode incluir os IDs das revisões de código, das confirmações e das execuções de pipelines correspondentes, bem como informações sobre quem aprovou a implementação.

Se uma implementação modificar recursos em Google Cloud, estas alterações são registadas nos registos de auditoria do Google Cloud dos respetivos recursos. Os registos de auditoria da nuvem contêm informações sobre o utilizador ou a conta de serviço que iniciou a alteração. No entanto, numa implementação acionada por um sistema de CI/CD, a conta de serviço em si é frequentemente insuficiente para reconstruir toda a cadeia de eventos que levaram à alteração.

Para estabelecer uma trilha de auditoria consistente no seu sistema de CI/CD e Google Cloud, tem de garantir que os registos do Cloud Audit Logs podem ser correlacionados com eventos no histórico do sistema de CI/CD. Se encontrar um evento inesperado nos registos de auditoria do Google Cloud, pode usar esta correlação para determinar se a alteração foi realmente efetuada pelo sistema de CI/CD, por que motivo foi efetuada e quem a aprovou.

Seguem-se algumas formas de estabelecer uma correlação entre os registos do Cloud Audit Logs e os eventos no histórico do sistema de CI/CD:

• Registe os pedidos de API realizados por cada execução da pipeline de CI/CD.
• Sempre que a API devolve um ID de operação, registe o ID nos registos do sistema de CI/CD.

• Adicione um X-Goog-Request-Reason cabeçalho HTTP aos pedidos de API e transmita o ID da execução da pipeline de CI/CD. O Terraform pode adicionar automaticamente este cabeçalho se especificar um motivo do pedido.

  Em alternativa, incorpore as informações no cabeçalho User-Agent para que sejam captadas nos registos de auditoria do Cloud.

Para ajudar a garantir a não repudiação, configure os ficheiros de registo e os históricos de commits de forma que sejam imutáveis e que um interveniente malicioso não consiga ocultar retroativamente os seus rastos.

Crie entradas de registo personalizadas para utilizadores individuais de uma aplicação

As contas de serviço também são úteis para aplicações em que um utilizador se autentica com um esquema de autenticação personalizado e, em seguida, acede indiretamente Google Cloud a recursos. Estas aplicações podem confirmar que o utilizador está autenticado e autorizado e, em seguida, usar uma conta de serviço para fazer a autenticação nos Google Cloud serviços e aceder aos recursos. No entanto, os registos de auditoria do Google Cloud registam que a conta de serviço acedeu a um recurso e não que utilizador estava a usar a sua aplicação.

Para ajudar a rastrear esse acesso até ao utilizador, crie uma lógica de aplicação para escrever uma entrada de registo personalizada sempre que um utilizador acede a um recurso e correlacione as entradas de registo personalizadas com os registos de auditoria na nuvem.

O que se segue?

• Compreenda as práticas recomendadas para gerir chaves de contas de serviço.
• Reveja as nossas práticas recomendadas para usar contas de serviço em pipelines de implementação.
• Saiba mais acerca das práticas recomendadas para usar a Workload Identity Federation.