Práticas recomendadas para usar a federação de identidades de cargas de trabalho

A Workload Identity Federation permite que as aplicações em execução fora do Google Cloud Google Cloud se façam passar por uma conta de serviço através da utilização de credenciais de um fornecedor de identidade externo.

A utilização da Workload Identity Federation pode ajudar a melhorar a segurança, permitindo que as aplicações usem os mecanismos de autenticação fornecidos pelo ambiente externo e pode ajudar a substituir as chaves de contas de serviço.

Para usar a Workload Identity Federation de forma segura, tem de a configurar de forma a proteger-se das seguintes ameaças:

• Roubo de identidade: um interveniente malicioso pode tentar roubar a identidade de outro utilizador para obter acesso não autorizado a Google Cloud recursos.
• Aumento de privilégios: um ator malicioso pode tirar partido da Workload Identity Federation para obter acesso a recursos aos quais, de outra forma, não teria acesso.
• Não repúdio: um autor malicioso pode ocultar a respetiva identidade e ações através da utilização de credenciais externas que dificultam o rastreio das ações até ao autor.
• Configurações de credenciais maliciosas: um interveniente prejudicial pode fornecer uma configuração de credenciais maliciosa para contornar as suas defesas de segurança.

Este guia apresenta práticas recomendadas para decidir quando usar a Federação de identidades de cargas de trabalho e como configurá-la de forma a ajudar a minimizar os riscos.

Quando usar a Workload Identity Federation

Use a federação de identidade da carga de trabalho para aplicações que têm acesso a credenciais ambientais

As aplicações executadas em fornecedores de nuvem que não sejam o Google Cloud Platform Google Cloud têm frequentemente acesso a credenciais ambientais. Estas são credenciais que a aplicação pode obter sem ter de realizar qualquer autenticação adicional. Os exemplos incluem:

• Na AWS, as aplicações implementadas no EC2 podem usar perfis de instância para assumir uma função e obter credenciais temporárias.
• No Azure, as aplicações podem usar identidades geridas para obter tokens de acesso.
• No GitHub Actions, os fluxos de trabalho podem obter tokens de ID que refletem a identidade da tarefa de implementação.

Se as credenciais ambientais forem tokens OpenID Connect (OIDC), afirmações SAML ou credenciais da AWS, pode configurar a Workload Identity Federation para permitir que as aplicações troquem estas credenciais por tokens de acesso Google de curta duração. Se as credenciais do ambiente usarem um formato diferente, pode trocá-las por um token OIDC ou uma afirmação SAML primeiro e, em seguida, usá-las para a Workload Identity Federation.

Use a Workload Identity Federation sempre que uma aplicação precisar de aceder ao Google Cloud e tiver acesso a credenciais ambientais.

Use uma troca de tokens adicional para usar credenciais ambientais que não são suportadas pela Workload Identity Federation

Em alguns casos, uma aplicação pode ter acesso a credenciais de ambiente, mas os tipos de credenciais não são suportados pela Workload Identity Federation. Nestes casos, verifique se uma troca de tokens adicional lhe permite converter a credencial ambiente num tipo de credencial que pode usar para a Workload Identity Federation.

Por exemplo, se a sua aplicação for executada num ambiente do Active Directory, pode ter acesso a credenciais do Kerberos. Se tiver um fornecedor de identidade, como os Serviços de Federação do Active Directory (AD FS), no seu ambiente que suporte a autenticação integrada do Windows, pode usar estas credenciais Kerberos para autenticar no fornecedor de identidade e obter um token de acesso OAuth que use o formato JWT. Em seguida, pode permitir que a aplicação execute uma segunda troca de tokens para obter credenciais Google de curta duração através deste token de acesso e da Workload Identity Federation.

A encadeamento de trocas de tokens aumenta a complexidade e pode introduzir dependências adicionais, mas pode libertar-se da gestão e proteção das chaves de contas de serviço.

Use a Workload Identity Federation para reduzir o número de credenciais que requerem rotação

As aplicações que se integram com um fornecedor de identidade OpenID ou SAML usam frequentemente um segredo do cliente (ou uma forma diferente de segredo) para autenticar junto do fornecedor de identidade. Normalmente, este segredo é armazenado como parte da configuração da aplicação. Para permitir que uma aplicação aceda a Google Cloud, tem de decidir entre:

1. Criar uma chave de conta de serviço e armazená-la juntamente com o outro segredo.
2. Usando tokens emitidos pelo fornecedor de identidade existente e trocando-os por credenciais Google através da Workload Identity Federation.

A primeira opção requer dois segredos, mas a segunda opção requer apenas um. Reduzir o número de segredos pode ajudar a simplificar a rotação de segredos, o que, por sua vez, pode ajudar a melhorar a segurança.

Proteção contra ameaças de spoofing

Um pool de identidades de workload não contém identidades nem contas de utilizador, o que o torna diferente de um diretório de utilizadores, como o Cloud ID. Em alternativa, um conjunto de identidades de carga de trabalho representa uma vista que apresenta identidades de fornecedores de identidade externos para que possam ser usadas como principais do IAM.

Consoante a forma como configura o Workload Identity Pool e os respetivos fornecedores, a mesma identidade externa pode ser representada como vários principais do IAM diferentes, ou várias identidades externas podem ser mapeadas para o mesmo principal do IAM. Essas ambiguidades podem permitir que intervenientes mal intencionados lancem ataques de spoofing.

A secção seguinte descreve as práticas recomendadas que ajudam a evitar mapeamentos ambíguos e a reduzir o risco de ameaças de roubo de identidade.

Use condições de atributos quando federar com o GitHub ou outros fornecedores de identidade multi-inquilinos

A Workload Identity Federation não mantém um diretório de contas de utilizador; em vez disso, implementa identidades baseadas em reivindicações: Como resultado, quando são emitidos dois tokens pelo mesmo fornecedor de identidade (IdP) e as respetivas reivindicações são mapeadas para o mesmo valor google.subject, considera-se que os dois tokens identificam o mesmo utilizador. Para saber que IdP emitiu um token, a Workload Identity Federation inspeciona e valida o URL do emissor do token.

Alguns fornecedores, como o GitHub e o Terraform Cloud, usam um único URL do emissor em todos os respetivos inquilinos. Para estes fornecedores, o URL do emissor identifica todo o GitHub ou Terraform Cloud, e não uma organização específica do GitHub ou Terraform Cloud.

Quando usa estes fornecedores de identidade, não é suficiente permitir que a Workload Identity Federation verifique o URL do emissor de um token para garantir que provém de uma fonte fidedigna e que as respetivas reivindicações são fidedignas. Recomendamos que configure uma condição de atributo da Workload Identity Federation para verificar se o token teve origem num inquilino fidedigno ou, no caso do GitHub ou do Terraform Cloud, numa organização fidedigna.

Para saber mais, consulte o artigo Configure uma condição de atributo.

Use um projeto dedicado para gerir Workload Identity Pools e fornecedores

Em vez de gerir Workload Identity Pools e fornecedores em vários projetos, use um único projeto dedicado para gerir Workload Identity Pools e fornecedores. A utilização de um projeto dedicado ajuda a:

• Certifique-se de que apenas são usados fornecedores de identidade fidedignos para a Workload Identity Federation.
• Controlar centralmente o acesso à configuração de Workload Identity Pools e fornecedores.
• Aplique mapeamentos de atributos e condições consistentes em todos os projetos e aplicações.

Pode usar restrições de políticas organizacionais para aplicar a disciplina de usar um projeto dedicado para gerir os fornecedores e os conjuntos de identidades de cargas de trabalho.

Use restrições de políticas organizacionais para desativar a criação de fornecedores do Workload Identity Pool noutros projetos

Os utilizadores com autorização para criar fornecedores do Workload Identity Pool podem criar Workload Identity Pools e fornecedores que podem ser redundantes para os que gerem num projeto dedicado.

Pode impedir a criação de novos fornecedores de workload identity pool usando a restrição da política organizacional com um conjunto de regras definido como Deny All.constraints/iam.workloadIdentityPoolProviders

Aplique estas restrições na raiz da hierarquia organizacional para negar a criação de novos fornecedores do Workload Identity Pool por predefinição. Crie exceções para os projetos nos quais quer permitir a gestão de Workload Identity Pools e fornecedores aplicando uma restrição de política que permita determinadas contas da AWS ou fornecedores OIDC fidedignos.

Use um único fornecedor por Workload Identity Pool para evitar conflitos de assuntos

A federação de identidades de cargas de trabalho permite-lhe criar mais do que um fornecedor por Workload Identity Pool. A utilização de vários fornecedores pode ser útil se as identidades forem geridas por vários fornecedores, mas quiser ocultar esta complexidade dos fluxos de trabalho em execução no Google Cloud.

A utilização de vários fornecedores introduz um risco de colisões de assuntos, em que o mapeamento de atributos para google.subject de um fornecedor devolve o mesmo valor que o mapeamento de atributos para outro fornecedor. O resultado de tal colisão é que várias identidades externas são mapeadas para o mesmo principal do IAM, o que torna as identidades externas indistinguíveis nos registos de auditoria da nuvem.

Para evitar conflitos de assuntos, use um único fornecedor por Workload Identity Pool. Se precisar de federar com vários fornecedores, crie vários Workload Identity Pools, cada um a usar um único fornecedor de Workload Identity.

Evite a federação com o mesmo fornecedor de identidade duas vezes

Pode federar com o mesmo fornecedor de identidade várias vezes criando vários fornecedores do pool de identidades de carga de trabalho que usam a mesma configuração ou uma configuração semelhante. Se estes fornecedores pertencerem ao mesmo Workload Identity Pool, essa configuração pode originar conflitos de assuntos. Se os fornecedores pertencerem a diferentes Workload Identity Pools, não podem ocorrer colisões de assuntos e, em vez disso, a mesma identidade externa é representada como diferentes principais do IAM.

O mapeamento de uma única identidade externa para vários principais da IAM dificulta a análise dos recursos aos quais uma determinada identidade externa tem acesso. Essa ambiguidade também pode aumentar o risco ao tentar revogar o acesso: um administrador pode revogar o acesso de um principal, mas pode não ter conhecimento da existência de outro principal, o que faz com que a identidade externa mantenha o acesso inadvertidamente.

Para minimizar o risco de ambiguidades, evite a federação com o mesmo fornecedor de identidade mais do que uma vez. Em alternativa, crie um único Workload Identity Pool e fornecedor e use um mapeamento de atributos e uma condição que garantam que pode ser usado para todas as identidades externas que requerem acesso a recursos Google Cloud .

Proteja o ponto final de metadados OIDC do seu fornecedor de identidade

Quando faz a federação com um fornecedor OpenID Connect, a Workload Identity Federation transfere periodicamente os metadados OIDC do seu fornecedor de identidade. A Workload Identity Federation usa os metadados do IdP e o conjunto de chaves Web JSON (JWKS) para validar tokens.

Para garantir a autenticidade, a comunicação com o seu fornecedor de identidade é protegida através de TLS. Se o seu fornecedor estiver implementado atrás de um equilibrador de carga ou um proxy inverso que termine o TLS, a ligação TLS garante a autenticidade do equilibrador de carga ou do proxy inverso, mas não do fornecedor de identidade real.

Um ator malicioso pode tirar partido desta configuração ao iniciar um ataque de intrusos (MITM) no qual reconfigura o balanceador de carga para lhe permitir transmitir pedidos JWKS para um ponto final malicioso que publica um conjunto diferente de chaves. A troca do JWKS permite que um ator malicioso assine tokens considerados válidos pela Workload Identity Federation e pode permitir-lhe roubar as identidades de outros utilizadores.

Para se proteger contra a troca de JWKS, certifique-se de que o seu IdP está implementado de forma a protegê-lo contra ataques MITM.

Use o URL do fornecedor do Workload Identity Pool como público-alvo

Quando faz a federação com um fornecedor do OpenID Connect, a Workload Identity Federation verifica se o público-alvo dos tokens (codificado na reivindicação aud) corresponde à definição de público-alvo permitida do fornecedor. Da mesma forma, quando faz a federação com um fornecedor SAML, a Workload Identity Federation verifica se a declaração SAML especifica uma restrição de público-alvo que corresponda ao público-alvo esperado.

Por predefinição, a Workload Identity Federation espera que o público-alvo corresponda ao URL https://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/PROVIDER_ID que identifica exclusivamente o fornecedor do Workload Identity Pool. Exigir tokens e afirmações para usar este URL como público-alvo ajuda a reduzir o risco de um ataque de confused deputy. Num ataque deste tipo, um interveniente prejudicial apresenta um token ou uma afirmação SAML à Workload Identity Federation que não se destinava a ser usado para a Workload Identity Federation, mas para alguma outra API.

Exigir que o token ou a afirmação contenham o URL do fornecedor do conjunto do Workload Identity de destino ajuda a garantir que os clientes só podem usar tokens e afirmações que foram emitidos especificamente para a Workload Identity Federation.

Use atributos imutáveis em mapeamentos de atributos

Para conceder a uma identidade externa autorização para usar a identidade de uma conta de serviço, crie uma associação da IAM que faça referência à identidade externa por assunto, grupo ou um atributo personalizado. Os atributos personalizados, de grupo e de assunto da identidade externa são derivados dos atributos que o fornecedor de identidade externo transmite à Workload Identity Federation durante a troca de tokens.

Alguns fornecedores de identidade permitem que os utilizadores alterem alguns dos seus próprios atributos. Por exemplo, um utilizador pode ter autorização para modificar o respetivo endereço de email ou aliases. Se as suas associações de IAM fizerem referência a atributos modificáveis, os utilizadores podem perder acidentalmente o acesso a determinados recursos modificando o respetivo perfil de utilizador. Pior ainda, os autores de ameaças podem conseguir acesso não autorizado a outros recursos modificando deliberadamente os respetivos atributos de utilizador para corresponderem às associações de IAM existentes.

Para se proteger contra esta ameaça de roubo de identidade, limite os mapeamentos de atributos a atributos que não podem ser modificados pelo utilizador ou que não podem ser modificados de todo.

Use atributos não reutilizáveis em mapeamentos de atributos

Quando concede a uma identidade externa autorização para se fazer passar por uma conta de serviço e, posteriormente, elimina o utilizador no fornecedor de identidade externo, a associação do IAM da conta de serviço permanece em vigor.

Se adicionar posteriormente um novo utilizador ao seu fornecedor de identidades externo e o utilizador partilhar determinados atributos com o utilizador eliminado anteriormente (por exemplo, o mesmo endereço de email), os utilizadores antigos e novos serão indistinguíveis para a Workload Identity Federation. Consequentemente, uma associação da IAM destinada a referir-se apenas ao utilizador antigo também pode aplicar-se ao novo utilizador.

Para evitar estas ambiguidades, use mapeamentos de atributos que dependam exclusivamente de atributos que não podem ser reutilizados ao longo do tempo, como um ID do utilizador único.

Se a política da sua empresa permitir a reutilização de atributos, como endereços de email, evite usar estes atributos em mapeamentos de atributos e use, em alternativa, um atributo diferente que seja garantidamente único ao longo do tempo.

Não permitir a modificação dos mapeamentos de atributos

A Workload Identity Federation usa mapeamentos de atributos para selecionar quais dos atributos fornecidos pelo fornecedor de identidade externo devem ser incorporados num token STS e como os nomes dos atributos devem ser traduzidos. A configuração dos mapeamentos de atributos é um passo fundamental para configurar a relação de confiança entre o fornecedor de identidade externo e Google Cloud.

Os mapeamentos de atributos também são cruciais para a segurança da utilização da Workload Identity Federation: se tiver concedido a um principal federado ou a um conjunto de principais a capacidade de roubar a identidade de uma conta de serviço, e, em seguida, alterar o mapeamento de atributos, pode alterar os utilizadores que têm acesso à conta de serviço.

A modificação dos mapeamentos de atributos requer a autorização iam.googleapis.com/workloadIdentityPoolProviders.update. As funções que contêm esta autorização incluem:

• Proprietário (roles/owner)
• Administrador do conjunto do Workload Identity do IAM (roles/iam.workloadIdentityPoolAdmin)

Se um autor malicioso tiver autorização para modificar os mapeamentos de atributos, pode alterar as regras de mapeamento de forma a falsificar a sua identidade e obter acesso a uma conta de serviço. Para evitar estas modificações maliciosas, certifique-se de que apenas alguns utilizadores administrativos têm autorização para modificar os mapeamentos de atributos.

Considere criar um Google Cloud projeto dedicado para gerir os conjuntos de identidades de cargas de trabalho, o que ajuda a limitar o risco de os utilizadores receberem inadvertidamente uma destas funções a um nível superior na hierarquia de recursos.

Não confie em atributos que não sejam estáveis nem autorizados

Um fornecedor de identidade usa atributos para comunicar informações sobre utilizadores autenticados. Normalmente, os fornecedores de identidade garantem que alguns atributos são autorizados, mas outros não. Por exemplo, um fornecedor de identidade externo pode incorporar um nome de utilizador e um ID de utilizador num token OIDC. Ambos os atributos identificam um utilizador de forma exclusiva e podem parecer intermutáveis. No entanto, o fornecedor de identidade externo pode garantir que o ID do utilizador é estável e autoritário, mas permite que os nomes de utilizador sejam alterados.

Se os seus mapeamentos de atributos dependerem de atributos que não sejam estáveis nem autorizados, um agente malicioso pode falsificar a respetiva identidade modificando o perfil de utilizador no fornecedor de identidade externo. Por exemplo, podem alterar o nome de utilizador para o de um utilizador que foi eliminado recentemente no fornecedor de identidade externo, mas que ainda tem acesso a uma conta de serviço no Google Cloud.

Para evitar estes ataques de spoofing, certifique-se de que os mapeamentos de atributos dependem apenas de atributos que o fornecedor de identidade externo garante serem estáveis e autorizados.

Proteção 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 do Google Cloud são uma fonte importante de informações para saber quando a atividade ocorreu e que utilizadores estiveram envolvidos.

Quando uma aplicação usa a federação de identidades da carga de trabalho, faz-se passar por uma conta de serviço. Nos registos de auditoria da nuvem, qualquer atividade realizada pela aplicação é atribuída à conta de serviço roubada. Para reconstruir a cadeia completa de eventos que originaram a atividade, tem de conseguir correlacionar os registos de auditoria do Google Cloud com os registos do seu fornecedor de identidade para poder saber que identidade externa esteve envolvida e por que motivo foi realizada uma atividade.

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

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. Quando uma aplicação usa a Workload Identity Federation, esta secção inclui o assunto do principal que foi usado para se fazer passar pela conta de serviço.

Nem todos os serviços incluem detalhes de roubo de identidade nos registos de auditoria da nuvem. Para ajudar a manter uma trilha de auditoria não repudiável, também tem de registar todos os eventos de roubo de identidade ativando os registos de acesso aos dados para a API Security Token Service e a API Identity and Access Management. Ative estes registos para todos os projetos do Google Cloud que contenham Workload Identity Pools ou contas de serviço usadas para a federação de identidades da carga de trabalho.

Ao ativar estes registos, garante que é adicionada uma entrada aos registos de auditoria na nuvem sempre que uma aplicação usa a Federação de identidades de carga de trabalho para trocar uma credencial externa e roubar a identidade de uma conta de serviço.

Use um mapeamento de assunto único

O principal sujeito usado na secção serviceAccountDelegationInfo nas entradas dos registos de auditoria do Google Cloud é determinado pelo mapeamento de atributos do fornecedor do pool de identidades da carga de trabalho para google.subject.

Quando deteta atividade suspeita e precisa de saber que identidade externa esteve envolvida, tem de poder procurar uma identidade externa pelo respetivo valor google.subject.

Da mesma forma, quando uma identidade externa foi comprometida e precisa de saber se a identidade foi usada para aceder a recursos Google Cloud , tem de conseguir encontrar entradas dos registos de auditoria na nuvem que correspondam à identidade externa.

Quando define o mapeamento de atributos para um fornecedor do Workload Identity Pool, escolha um mapeamento exclusivo para google.subject para que:

• Uma identidade externa é mapeada para exatamente um valor google.subject.
• Um valor de google.subject é mapeado para exatamente uma identidade externa.
• Pode procurar uma identidade externa pelo respetivo valor google.subject.

A utilização de um mapeamento de atributos que satisfaça estes critérios de unicidade ajuda a garantir que pode procurar identidades externas pelo respetivo valor google.subject e valores google.subject pelas respetivas identidades externas.

Proteção contra ameaças de escalamento de privilégios

Para aplicar o princípio do menor privilégio quando usar a Workload Identity Federation, tem de:

• limitar o número de identidades externas que podem usar a identidade de uma conta de serviço
• limitar os recursos aos quais uma conta de serviço pode aceder

Uma configuração excessivamente permissiva pode levar a uma situação em que um agente malicioso pode usar uma identidade externa para aumentar os respetivos privilégios e aceder a recursos aos quais não deveria ter acesso.

As secções seguintes fornecem práticas recomendadas que podem ajudar a proteger contra ameaças de escalada de privilégios.

Use contas de serviço que residam no mesmo projeto que os recursos aos quais precisa de aceder

Quando um cliente usa a Workload Identity Federation através de bibliotecas cliente ou da API REST, segue um processo de três passos:

1. Obtenha uma credencial do fornecedor de identidade fidedigno.
2. Troque a credencial por um token do serviço de tokens de segurança.
3. Use o token do serviço de tokens de segurança para se fazer passar por uma conta de serviço e obter um token de acesso Google de curta duração.

Para o último passo, use uma conta de serviço que resida no mesmo projeto que os recursos aos quais precisa de aceder. A utilização de uma conta de serviço gerida no mesmo projeto ajuda a aplicar autorizações de acesso mais restritivas e facilita a decisão de quando a conta de serviço pode deixar de ser necessária.

Use uma conta de serviço dedicada para cada aplicação

Se tiver várias aplicações que usam a Workload Identity Federation para aceder a recursos no mesmo projeto, crie uma conta de serviço dedicada para cada aplicação. A utilização de contas de serviço específicas da aplicação ajuda a evitar a atribuição excessiva de autorizações, concedendo acesso apenas aos recursos que cada aplicação individual requer.

Evite conceder acesso a todos os membros de um conjunto

Antes de uma identidade externa poder usar a identidade de uma conta de serviço, tem de conceder-lhe a função roles/iam.workloadIdentityUser na conta de serviço. Quando conceder esta função, evite concedê-la a todos os membros do conjunto do Workload Identity. Em alternativa, conceda a função a identidades externas específicas ou a identidades que correspondam a determinados critérios.

Inicialmente, o número de utilizadores externos que precisam de acesso aos recursos Google Cloud pode ser pequeno. Por conseguinte, a condição de atributo do seu Workload Identity Pool e a configuração do seu fornecedor de identidade podem permitir apenas que algumas identidades externas usem a federação de identidades de carga de trabalho.

Quando integrar posteriormente novas cargas de trabalho no Google Cloud, pode ter de modificar a configuração do fornecedor de identidade ou a condição de atributo do Workload Identity Pool para permitir identidades externas adicionais.

Ao conceder apenas a função roles/iam.workloadIdentityUser a identidades externas específicas, pode garantir que faz crescer um conjunto do Workload Identity em segurança sem conceder inadvertidamente acesso de roubo de identidade a mais identidades externas do que o necessário.

Proteção contra configurações de credenciais maliciosas

Algumas configurações de credenciais contêm URLs e caminhos de ficheiros que, se não forem validados adequadamente por uma carga de trabalho, podem fazer com que a carga de trabalho use pontos finais maliciosos.

Valide as configurações de credenciais a partir de uma origem externa antes de as usar para autenticar nas APIs Google

Quando aceita uma configuração de credenciais de uma origem externa, tem de validar o JSON antes de o usar. Se não validar a configuração das credenciais, um ator malicioso pode usar a configuração das credenciais para fazer com que a sua carga de trabalho aceda a pontos finais maliciosos.

Para mais informações, consulte o artigo Requisitos de segurança quando usa configurações de credenciais de uma origem externa.

O que se segue?

• Saiba mais sobre as práticas recomendadas para trabalhar com contas de serviço.
• Leia mais acerca das práticas recomendadas para gerir chaves de contas de serviço.