Práticas recomendadas para usar a federação de identidade de colaboradores

A federação de identidade de colaboradores federa sua Google Cloud organização com um provedor de identidade externo (IdP) para ativar o logon único (SSO).

Você pode aplicar essas práticas recomendadas para usar a federação de identidade de colaboradores de maneira eficaz e minimizar os riscos de segurança.

Escolher a arquitetura certa

As seções a seguir descrevem os principais fatores para escolher uma arquitetura de federação que atenda aos seus requisitos.

Considerações sobre a arquitetura:

Escolha um padrão de arquitetura de federação.
Divida o uso da federação por serviço, não por usuário.

Escolher um padrão de arquitetura de federação

Os quatro padrões a seguir descrevem maneiras comuns de federar uma organização Google Cloudcom um IdP externo:

Antes de federar, considere as vantagens e limitações de cada padrão e escolha aquele que atende aos seus requisitos. Para mais informações, consulte os padrões de arquitetura para federação de identidade.

Uso da federação de partições por serviço

Em geral, recomendamos que você particione o uso da federação por serviço, em vez de por usuário. A partição do uso por serviço tem menos desvantagens no geral.

Para reduzir a complexidade, recomendamos usar o Cloud Identity ou a federação de identidade de colaboradores. No entanto, dependendo dos seus requisitos, talvez seja necessário usar os dois em paralelo, conforme descrito no padrão híbrido.

Se você usar a federação do Cloud Identity e a federação de identidade de colaboradores em paralelo, poderá particionar o uso delas das seguintes maneiras:

  • Partição por usuário: divida seus usuários em duas coortes: uma usando a federação de identidade do Workforce e outra usando a federação do Cloud Identity.

    • Vantagem: cada usuário tem uma única identidade nos Serviços do Google e um método de login.

    • Desvantagens: o particionamento por usuários tem várias desvantagens, incluindo:

      • Gerenciar grupos de acesso pode ser complexo porque as políticas de permissão do IAM precisam conter uma combinação de tipos de principais, e não é possível usar os mesmos grupos para usuários do Cloud Identity e da federação de identidade de colaboradores.

      • Usuários de coortes diferentes não podem compartilhar links entre si porque o console Google Cloud , o Gemini Enterprise e outras ferramentas usam URLs diferentes, dependendo de como os usuários fazem login.

      • Usuários de diferentes coortes podem ter acesso a diferentes conjuntos de recursos.

  • Partição por serviço: configure cada serviço, como Google Cloud ou Gemini Enterprise, para que ele conceda acesso exclusivamente a usuários da federação de identidade da força de trabalho ou do Cloud Identity, mas nunca a ambos.

    • Vantagem: simplifica a administração e garante um conjunto de recursos consistente para diferentes usuários.
    • Desvantagem: alguns funcionários podem precisar receber duas identidades: uma que usa a federação de identidade de colaboradores e outra que usa o Cloud Identity.

Recomendamos particionar por serviço, separando especificamente o Gemini Enterprise e o NotebookLM Enterprise de outros serviços. O Gemini Enterprise e o console Google Cloud são ferramentas separadas criadas para tarefas diferentes. Qualquer diferença nos processos de login deve ter um impacto mínimo na experiência geral do usuário.

Para ajudar a aplicar essa divisão, use restrições de política da organização.

Reforçar a governança do grupo

Gerencie o acesso usando grupos e estabeleça processos claros para governar esses grupos e usar a federação de identidade de colaboradores com eficiência.

As permissões de um usuário para acessar recursos não são determinadas durante a autenticação. Em vez disso, o acesso é avaliado quando o usuário tenta acessar o recurso com base nas políticas anexadas a ele. Essas políticas podem incluir o seguinte:

As políticas definem o acesso para principais individuais ou conjuntos de principais:

  • Principal: um usuário autenticado identificado por um identificador principal. Um identificador principal de colaboradores é semelhante a este: principal://iam.googleapis.com/locations/global/workforcePools/ POOL_ID/subject/SUBJECT

    O identificador principal contém o seguinte:

    • POOL_ID: identifica exclusivamente um pool de identidade da força de trabalho.
    • SUBJECT: identifica um usuário específico de maneira exclusiva. O valor e o formato dependem do seu IdP e do mapeamento de atributos.

  • Conjunto principal: usuários que atendem a critérios específicos. A federação de identidade de colaboradores é compatível com três conjuntos principais: com base em grupo (membros de um grupo), com base em atributo e curinga (todos os usuários).

Conceder acesso a principais individuais pode ser útil em situações específicas, mas não é uma boa opção devido aos seguintes problemas:

  • Adicionar participantes um por um faz com que as políticas de permissão cresçam e se tornem cada vez mais difíceis de gerenciar.
  • O gerenciamento de acesso individual exige mudanças frequentes nas políticas de permissão.
  • As políticas podem se tornar cada vez mais inconsistentes com o tempo.

Para um gerenciamento de acesso escalonável e eficaz, usar conjuntos de principais baseados em grupos oferece estas vantagens:

  • Você pode gerenciar o acesso adicionando ou removendo membros de grupos usando suas ferramentas e processos de identidade atuais.
  • Reduza o tamanho e a complexidade das políticas de permissão.
  • Verifique se os usuários com a mesma função têm o mesmo acesso aos recursos.

Para usar grupos no gerenciamento de acesso, configure seu IdP externo de determinadas maneiras e fique atento às limitações que ele impõe aos grupos.

As seções a seguir descrevem as práticas recomendadas para usar grupos de maneira eficaz e evitar limites do IdP.

Práticas recomendadas:

Distinguir diferentes tipos de grupos.
Use grupos de acesso para conceder acesso a recursos.
Use grupos de aplicação para restringir o acesso a recursos.
Não use grupos organizacionais e de colaboração para gerenciar o acesso.
Use grupos organizacionais e de colaboração apenas para o Gemini Enterprise.

Distinguir diferentes tipos de grupos

A lista a seguir descreve quatro tipos de grupos comuns em organizações:

  • Grupos de acesso: usados apenas para conceder acesso a Serviços do Google ou recursos do Google Cloud . Eles representam funções de trabalho e simplificam a atribuição de papéis necessários para realizar essas funções.
  • Grupos organizacionais: representam subconjuntos da estrutura de uma organização e geralmente são originados de dados de recursos humanos. Eles podem ser baseados em departamento, estrutura de relatórios, localização geográfica ou outros agrupamentos organizacionais.
  • Grupos de colaboração: representam grupos de trabalho, membros de projetos ou usuários que querem colaborar em um projeto ou discutir um tópico específico e podem ser usados para distribuição de e-mails. Os grupos de colaboração são criados com frequência de forma ad hoc e de autoatendimento.
  • Grupos de aplicação: também chamados de grupos de políticas, eles são usados para restringir o acesso, ao contrário dos grupos de acesso, que são usados para conceder acesso. Por exemplo, limites de acesso de principal, políticas de negação ou aplicação da autenticação multifator. Os grupos de acesso podem permitir que os participantes saiam voluntariamente de um grupo. No entanto, a participação em um grupo de aplicação não é voluntária.

Os grupos que você precisa federar dependem dos seguintes serviços que você usa:

  • Para Google Cloud, você só precisa de grupos de acesso e de restrição.
  • Para o Gemini Enterprise, você precisa de grupos de acesso, grupos de aplicação e, se estiver usando conectores baseados na ingestão de dados, determinados grupos organizacionais e de colaboração.

Ao configurar a federação de identidade de colaboradores, exclua tipos de grupos irrelevantes para evitar limites de token com seu IdP. Essa abordagem ajuda a reduzir o risco de exceder as limitações impostas pelo seu IdP e garante um uso mais consistente dos grupos.

Conceder acesso a recursos usando grupos de acesso

Para gerenciar o acesso de maneira eficaz, recomendamos usar conjuntos de principais que mapeiam grupos de acesso. Os grupos de acesso existem apenas para fornecer acesso. Eles representam funções de trabalho e simplificam a atribuição dos papéis necessários para realizar essas funções.

Para configurar grupos de acesso, faça o seguinte:

  1. No seu IdP, crie grupos de acesso que representem funções de trabalho.
  2. Mapeie os grupos de acesso para conjuntos de principais e use-os no IAM.
  3. Crie vinculações de política para conceder aos conjuntos de principais acesso aos recursos necessários para cada função de trabalho.
  4. No IdP externo, adicione ou remova usuários dos grupos com base nas funções de trabalho deles.

Use grupos de acesso para políticas que concedem acesso, incluindo:

  • Políticas de permissão do IAM
  • Regras de entrada do VPC Service Controls

Verifique se os grupos de acesso são refinados o suficiente. Por exemplo, os seguintes grupos representam grupos de acesso efetivos:

  • widget-sales-dashboard-readers: concede acesso de leitura a um conjunto de dados específico do BigQuery e ao painel associado.

  • dev-ssh-users: concede acesso do Login do SO às VMs do Compute Engine no ambiente de desenvolvimento.

    Por outro lado, os seguintes tipos de grupos geralmente não são adequados para uso como grupos de acesso:

    • Grupos de administradores gerais, como cloud-admins, geralmente não têm especificidade sobre quais cargas de trabalho ou ambientes se aplicam.

    • Os grupos organizacionais, como australia-fte, representam grupos como equipes ou por local, em vez de função.

    • Os grupos de comunicação, como security-discuss, são criados para listas de e-mails ou colaboração, e não para grupos de acesso.

    Para manter os grupos de acesso refinados, crie um novo conjunto de grupos para cada carga de trabalho ou projeto que você integrar ao Google Cloud. Assim, é possível dimensionar o número de grupos de acesso de acordo com o número de cargas de trabalho executadas no Google Cloud.

Restringir o acesso a recursos usando grupos de aplicação

Os grupos de aplicação são semelhantes aos grupos de acesso, mas geralmente diferem das seguintes maneiras:

  • Não permitem que os participantes saiam do grupo por vontade própria.
  • Elas não são específicas de uma carga de trabalho.

Use grupos de aplicação para políticas que reduzem o acesso, incluindo:

  • Políticas de negação do IAM
  • Limites de acesso principal
  • Políticas da organização

Exemplos de grupos de aplicação incluem users-in-restricted-locations, fedramp-low e mfa-users. Normalmente, o número de grupos de aplicação é pequeno e não afeta o total de associações de um usuário a grupos.

Não use grupos organizacionais e de colaboração para gerenciar o acesso

Para gerenciar o acesso de maneira eficaz, use grupos de acesso e de aplicação em vez de grupos organizacionais ou de colaboração.

Os grupos organizacionais representam equipes ou subconjuntos da estrutura de uma organização e geralmente são originados de dados de recursos humanos. Esses grupos não são adequados para gerenciar o acesso a recursos do Google Cloud pelos seguintes motivos:

  • As responsabilidades e a composição da equipe podem mudar com o tempo. Por exemplo, uma equipe pode transferir uma carga de trabalho para outra, ou duas equipes podem se fundir. Gerenciar o acesso com grupos organizacionais pode exigir uma cascata de mudanças de política durante essas transições.
  • Os membros de um grupo organizacional raramente precisam de acesso idêntico aos recursos. Conceder acesso a um grupo organizacional geralmente dá a alguns membros mais acesso do que eles precisam.

Os grupos de colaboração geralmente são autogerenciados, permitindo que os membros participem com a aprovação de outro membro ou sem aprovação. O uso de grupos de colaboração para conceder acesso pode levar ao excesso de permissões e ao escalonamento de privilégios.

Para impedir que grupos organizacionais e de colaboração sejam usados para gerenciamento de acesso, configure seu IdP para excluir essas associações de grupo nos tokens ou declarações usadas para a federação de identidade de colaboradores.

Usar grupos organizacionais e de colaboração apenas para o Gemini Enterprise

Embora os grupos organizacionais e de colaboração não sejam adequados para gerenciar o acesso a recursos do Google Cloud , talvez você precise deles para o Gemini Enterprise:

  • Avaliação de ACL: quando você usa conectores baseados na ingestão de dados para integrar o Gemini Enterprise ao Microsoft 365, ele pode encontrar documentos com listas de controle de acesso (ACLs) que se referem a grupos organizacionais e de colaboração. Se o Gemini Enterprise não tiver acesso às associações de um usuário nesses grupos, ele poderá não avaliar corretamente se o usuário está autorizado a acessar esses documentos.
  • Compartilhamento de notebooks: o NotebookLM permite que os usuários compartilhem notebooks. Permitir que os usuários compartilhem notebooks com grupos de colaboração é geralmente mais conveniente do que restringir o compartilhamento a usuários individuais.

Para garantir que os grupos organizacionais e de colaboração estejam disponíveis apenas para o Gemini Enterprise, configure seu IdP da seguinte maneira:

  • Use o SCIM para provisionar grupos organizacionais e de colaboração e as associações deles.
  • Exclua as associações a grupos organizacionais e de colaboração nos tokens ou asserções usadas para a federação de identidade de colaboradores.

Gerenciar pools de identidade da força de trabalho

Um pool de identidade de colaboradores define um namespace para identificadores principais e serve como um contêiner para sua configuração de federação. Ao contrário de um diretório de usuários, um pool não armazena informações sobre usuários ou grupos.

Práticas recomendadas:

Use um único pool por IdP.
Escolha um nome exclusivo e significativo para o pool.
Trate os pools como recursos altamente privilegiados.
Considere os riscos ao estender a federação a parceiros.

Use um único pool por IdP

Os pools de identidade de colaboradores são um recurso no nível da organização, não para envolvidos no projeto. Esse design reflete que os pools de identidades de colaboradores gerenciam a autenticação em uma Google Cloud organização, em vez de um projeto ou carga de trabalho individual.

Para a maioria das organizações, o número de pools de identidade da força de trabalho precisa corresponder ao número de IdPs:

  • Se a organização usar um único IdP para gerenciar a autenticação, use um único pool de identidades da força de trabalho.
  • Se a organização usar vários IdPs, por exemplo, devido a uma aquisição, use um pool de identidade da força de trabalho por IdP.

Ao limitar o número de pools de identidades de colaboradores, você garante o seguinte:

  • Não é necessário criar ou modificar pools de identidades de colaboradores ao integrar novas cargas de trabalho ao Google Cloud.
  • É possível usar o IAM para controlar quais projetos e recursos dentro de Google Cloud usuários individuais podem acessar.

Escolha um nome exclusivo e significativo para o pool

Para tornar os identificadores principais globalmente exclusivos, a identidade de colaboradores codifica o nome do pool de identidade de colaboradores no identificador principal. Ao escolher um nome para um pool de identidades da força de trabalho, considere as seguintes restrições:

  • Exclusividade: escolha um nome exclusivo em Google Cloud e que não seja reivindicado por outra organização.
  • Imutabilidade: não é possível mudar o nome de um pool de identidades de colaboradores. Escolha um nome que continue significativo ao longo do tempo, evitando nomes temporários de iniciativas.
  • Experiência do usuário: dependendo da sua configuração de login, os usuários podem precisar inserir o nome do pool durante o login. Escolha um nome curto e fácil de lembrar.

Tratar pools como recursos altamente privilegiados

O pool e o provedor de identidade de colaboradores determinam como os usuários fazem login e controlam como as identidades e as associações a grupos são derivadas do IdP externo. Como esses componentes controlam a lógica de autenticação, eles são essenciais para a segurança da sua Google Cloud organização. Um comprometimento desses componentes pode permitir que pessoas mal-intencionadas realizem ataques de spoofing.

Para realizar um ataque de spoofing, pessoas mal-intencionadas podem tentar as seguintes ações:

  • Modificar mapeamentos de atributos: alterar os mapeamentos de atributos pode permitir que um usuário de má-fé se autentique como outra pessoa e consiga acesso privilegiado não autorizado.
  • Adicionar um provedor malicioso: ao adicionar um provedor, um usuário de má-fé pode ignorar o IdP da sua organização e fazer a autenticação usando um IdP diferente que ele controla.

Os pools e provedores de identidade da força de trabalho são recursos essenciais para a segurança que exigem a seguinte proteção:

  • Restrinja o acesso a usuários não federados: limite o acesso administrativo a um pequeno número de usuários do Cloud Identity ou do Google Workspace, incluindo pelo menos um usuário de acesso de emergência.
  • Proteja os usuários administrativos: exija a verificação em duas etapas para todos os usuários administrativos e de acesso de emergência.
  • Acesso no momento certo: use o Privileged Access Manager (PAM) para conceder acesso administrativo no momento certo, em vez de acesso permanente.

Considere os riscos ao estender a federação para parceiros

A federação Google Cloud com um IdP externo usando a federação de identidade de colaboradores estabelece uma relação de confiança. Ao usar a federação, você depende do IdP externo para realizar as seguintes ações:

  • Faça a autenticação multifator (MFA) que atenda aos seus requisitos de segurança.
  • Faça declarações precisas sobre identidades de usuários e associações a grupos.
  • Siga os processos de governança de identidade para garantir que os usuários sejam desligados rapidamente e que as associações a grupos reflitam com precisão as funções atuais.

A federação de identidade de colaboradores oferece mecanismos limitados para validar as declarações feitas por um IdP externo. Especificamente, a federação de identidade da força de trabalho não oferece suporte à MFA pós-SSO da mesma forma que o Cloud Identity.

Antes de usar a federação de identidade de colaboradores para permitir que parceiros ou prestadores de serviços externos acessem seus recursos do Google Cloud , determine se esse nível de confiança é adequado. Não use a federação de identidade do Workforce para acesso de parceiros, a menos que você confie no parceiro e no IdP dele para atender consistentemente aos seus padrões de segurança.

Gerenciar provedores de pool de identidade da força de trabalho

Um provedor de pool de identidade da força de trabalho define uma relação de federação com um IdP externo e contém a configuração para o seguinte:

  • O IdP a ser usado para o Logon único.
  • O mapeamento de atributos a ser usado para derivar identificadores principais de tokens ou declarações fornecidas pelo IdP.
  • Opcional: o locatário do SCIM a ser usado para pesquisar informações de associação a grupos.

Práticas recomendadas:

Escolha um nome significativo para o provedor.
Use o portal de aplicativos do IdP para expor serviços individuais.
Use um único provedor por pool para evitar conflitos de assunto.
Use o mesmo pool e provedor para o console do Google Cloud e o Gemini Enterprise.
Use um URI do emissor específico do locatário.
Evite usar o fluxo implícito do OpenID Connect (OIDC).

Escolha um nome significativo para o provedor

Ao criar um provedor de pool de identidade de colaboradores, é necessário atribuir um nome a ele. Ao contrário dos nomes de pools de identidades de força de trabalho, esse nome não precisa ser exclusivo globalmente e não é codificado em identificadores principais. No entanto, dependendo da configuração de login, talvez seja necessário inserir o nome do provedor durante o login. Para melhorar a experiência do usuário, escolha um nome significativo e fácil de lembrar, por exemplo, entra ou staff.

Evite usar nomes como oidc ou saml, porque essas siglas podem ser desconhecidas para os usuários.

Mostrar serviços individuais no portal de aplicativos do IdP

Provedores de identidade como o Microsoft Entra ID e o Okta oferecem um portal de aplicativos que permite aos usuários descobrir e acessar os aplicativos atribuídos. Use o portal para otimizar a experiência do usuário fazendo o seguinte:

  • Configure o portal para mostrar os serviços relevantes do Google individualmente em vez de mostrar um único link Google Cloud .
  • Configure links para fazer login do usuário automaticamente.

A tabela a seguir lista os Serviços do Google comuns que oferecem suporte à federação de identidade de colaboradores e os URLs para login automático:

Aplicativo URL
Google Cloud Console de federação de identidade da força de trabalho, também conhecido como o console (federado) https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fconsole.cloud.google
Gemini Enterprise https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fvertexaisearch.cloud.google%2Fhome%2Fcid%2FWEBAPP_ID
NotebookLM Enterprise https://auth.cloud.google/signin/locations/global/workforcePools/POOL/providers/PROVIDER?continueUrl=https%3A%2F%2Fnotebooklm.cloud.google%2Fglobal%2F%3Fproject%3DPROJECT_NUMBER
Apps da Web do IAP URL do aplicativo, como https://iap.example.com/

Substitua:

  • POOL: o nome do pool de identidade da força de trabalho.
  • PROVIDER: o nome do provedor do pool.
  • WEBAPP_ID: o ID do app da Web Gemini Enterprise.
  • PROJECT_NUMBER: o número do projeto do NotebookLM Enterprise.

Use um único provedor por pool para evitar conflitos de assunto

É possível usar a federação de identidade de colaboradores para adicionar vários provedores a um pool de colaboradores. Adicionar um segundo provedor é útil durante migrações em que você permite temporariamente que os usuários se autentiquem usando diferentes IdPs. Além de situações temporárias, evite usar vários provedores pelos seguintes motivos:

  • Colisões de assunto: o uso de vários provedores apresenta risco de colisões de assunto. Nessas colisões, o mapeamento do atributo google.subject de um provedor retorna o mesmo valor de outro provedor. Essa colisão mapeia várias identidades externas para o mesmo principal do IAM, tornando-as indistinguíveis nos registros de auditoria do Cloud.
  • Compatibilidade com o IAP: o IAP exige que os pools de identidade de colaboradores tenham um único provedor para redirecionar automaticamente os usuários não autenticados ao IdP. Se você adicionar outro provedor, o IAP não poderá autenticar usuários.

Se você precisar federar com vários provedores, crie vários pools de força de trabalho e configure um provedor para cada pool.

Usar o mesmo pool e provedor para o console Google Cloud e o Gemini Enterprise

Se você usa a Workforce Identity Federation para o Gemini Enterprise e o Google Cloud, use um único provedor para garantir que os usuários possam acessar os dois serviços simultaneamente sem fazer login de novo. Se você usar provedores separados com mapeamentos de atributos diferentes, os usuários poderão encontrar situações em que o acesso aos recursos varia dependendo do provedor com que eles fazem login.

Usar um URI do emissor específico do locatário

Ao configurar um provedor, você especifica um URI do emissor para identificar exclusivamente seu IdP. No entanto, dependendo da configuração do IdP, o URI do emissor pode não ser exclusivo do locatário da sua organização. Por exemplo, se você usar um URI de emissor genérico ou compartilhado, como o endpoint comum do Microsoft Entra ID (https://login.microsoftonline.com/common/v2.0), poderá permitir inadvertidamente que usuários de outras organizações se autentiquem na sua organização Google Cloud.

Para evitar o acesso não intencional entre locatários, use um URI do emissor específico do locatário. Se o IdP não fornecer um URI de emissor específico do locatário, configure uma condição de atributo para limitar o acesso ao locatário específico.

Evite usar o fluxo implícito do OpenID Connect (OIDC)

Ao configurar um provedor OIDC, prefira o fluxo do código de autorização em vez do fluxo implícito. O fluxo implícito foi descontinuado na versão 2.1 da especificação do OAuth porque é vulnerável a vazamento e injeção de tokens. O uso do fluxo do código de autorização ajuda a reduzir o risco de interceptação de tokens.

Gerenciar usuários

É possível gerenciar usuários usando a federação de identidade da força de trabalho. A federação de identidade de colaboradores deriva o identificador principal de um usuário do token ou da declaração dele seguindo estas etapas:

  1. Determine o identificador do assunto aplicando o mapeamento de atributos para google.subject. O identificador do assunto precisa identificar de forma exclusiva um usuário em um pool de identidades da força de trabalho, mas não precisa ser exclusivo em Google Cloud.

  2. Derive o identificador principal anexando o identificador do assunto a um prefixo que identifica o pool de identidades de colaboradores. O identificador principal resultante é exclusivo em Google Cloud e tem o seguinte formato:

    principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/\
subject/SUBJECT

Quando um usuário autenticado usando a federação de identidade de colaboradores acessa um recurso, o IAM usa o identificador principal para avaliar as vinculações de papéis em políticas de permissão e as registra nos registros de auditoria do Cloud.

Práticas recomendadas:

Use um identificador de assunto imutável.
Não reutilize identificadores de assunto.
Microsoft Entra ID: use o UPN como o identificador do assunto.

Usar um identificador de assunto imutável

Quando o identificador de assunto de um usuário muda, o identificador principal também muda. Como resultado, Google Cloud não os reconhece mais como o mesmo usuário:

  • O usuário não pode acessar recursos a que tinha acesso antes porque o novo identificador principal não corresponde mais aos identificadores principais listados nas políticas de permissão.
  • As entradas dos Registros de auditoria do Cloud contêm apenas o novo identificador principal e não podem mais ser correlacionadas com registros que usavam o identificador principal antigo.

Para manter estável o identificador principal de um usuário, use um mapeamento de atributos que resulte em um valor estável para google.subject.

Muitos IdPs geram automaticamente um identificador numérico ou formatado em UUID exclusivo para os usuários. Esses identificadores são exclusivos e estáveis, o que os torna bons candidatos para google.subject. No entanto, usar esses identificadores como google.subject pode resultar em identificadores principais longos e enigmáticos que podem ser difíceis de trabalhar.

Para ajudar você a escolher um identificador para google.subject, considere os seguintes requisitos em ordem de prioridade decrescente:

  1. Unicidade: o valor identifica de forma exclusiva um usuário no seu IdP.
  2. Usabilidade: o valor é significativo ou pelo menos pode ser pesquisado facilmente no diretório de usuários do seu IdP.
  3. Imutabilidade: o valor é imutável ou, pelo menos, só pode ser mudado por administradores.

Não reutilize identificadores de assunto

Muitos IdPs aplicam restrições de exclusividade a determinados identificadores de usuário, mas permitem que eles sejam reutilizados. Por exemplo, um IdP pode não permitir que você crie dois usuários com o mesmo nome de usuário bob. No entanto, depois de excluir a conta de usuário bob, o IdP pode permitir que você crie um novo usuário e atribua a ele o nome de usuário bob novamente.

Se o mapeamento de atributos do seu provedor para google.subject se referir a um identificador de usuário que permite a reutilização, você poderá encontrar colisões de assunto: a federação de identidade da força de trabalho não consegue distinguir entre um usuário antigo e um novo usuário se o google.subject deles for o mesmo. Como resultado, o novo usuário pode acessar recursos destinados apenas ao usuário antigo.

Para evitar colisões de assunto, faça uma ou ambas as ações a seguir:

Microsoft Entra ID: use o UPN como identificador de assunto

Essa prática recomendada só se aplica se você usa o ID do Microsoft Entra como IdP.

Se você usa o Microsoft Entra ID, os identificadores que podem ser usados como identificador de assunto incluem o seguinte:

  • Nome principal do usuário (upn)
  • ID do objeto (oid)
  • Endereço de e-mail (o endereço principal em proxyAddresses)

Entre essas opções, recomendamos usar o nome principal do usuário como o identificador do assunto pelos seguintes motivos:

  • Todos os usuários têm um nome principal de usuário.
  • Os nomes principais de usuário identificam um usuário de forma exclusiva.
  • Os nomes principais de usuários costumam ser significativos e fáceis de trabalhar.
  • Os nomes principais de usuário incorporam um nome de domínio, que identifica de forma exclusiva o locatário do Microsoft Entra ID ao qual o usuário está associado.
  • Sua organização pode ter uma política que proíbe ou governa a reutilização de identificadores principais de usuários.

Por outro lado, o ID do objeto e o endereço de e-mail de um usuário são menos adequados pelos seguintes motivos:

  • Um ID de objeto (oid) é imutável, mas formatado como um GUID. Esse formato dificulta o trabalho com elas e não é significativo para os humanos.
  • O endereço de e-mail não é um atributo obrigatório e pode não ser preenchido para todos os usuários.

Recomendamos que você evite aplicar transformações, como forçar identificadores para caixa baixa, seja qual for o identificador escolhido.

Gerenciar grupos

A federação de identidade de colaboradores pode determinar a participação de um usuário em um grupo com base nas seguintes fontes:

  • A declaração SAML ou o token de ID fornecido pelo IdP.
  • A API Microsoft Graph, se você usa o Microsoft Entra ID como IdP.
  • O locatário do SCIM associado ao provedor do pool de identidades da força de trabalho.

Por padrão, a federação de identidade de colaboradores usa apenas a declaração SAML ou o token de ID:

Origem Google Cloud Gemini Enterprise
Token de ID ou SAML
API do Microsoft Graph - -
Locatário do SCIM - -

Se você usa o ID do Microsoft Entra como IdP, é possível ativar o recurso de atributos extras. A federação de identidade de colaboradores usa apenas a API Microsoft Graph como fonte para associações a grupos:

Origem Google Cloud Gemini Enterprise
Token de ID ou SAML - -
API do Microsoft Graph
Locatário do SCIM - -

Se você usa o Gemini Enterprise, é possível configurar a federação de identidade de colaboradores para usar um locatário do SCIM, o que muda o comportamento da seguinte maneira:

  • O Gemini Enterprise usa as associações a grupos do locatário SCIM e ignora as informações de associação a grupos da declaração SAML ou do token de ID.
  • Google Cloud usa informações de associação a grupos da declaração SAML ou do token de ID e ignora as informações de associação a grupos do locatário do SCIM.
Origem Google Cloud Gemini Enterprise
Token de ID ou SAML -
API do Microsoft Graph - -
Locatário do SCIM -

Para cada associação a um grupo, a federação de identidade de colaboradores deriva um identificador principal seguindo estas etapas:

  1. Determine o identificador do grupo seguindo um destes procedimentos:
    • Declaração SAML ou token de ID: aplique o mapeamento de atributos para google.groups.
    • Locatário SCIM: aplique o mapeamento de declarações para google.group.
    • API Microsoft Graph: siga extra-attributes-type na configuração do provedor.

  2. Derive o identificador principal anexando o identificador do grupo a um prefixo que identifica o pool de identidades de colaboradores. O identificador principal resultante é exclusivo em Google Cloud e tem o seguinte formato:

    principalSet://iam.googleapis.com/locations/global/workforcePools/\
POOL_ID/group/GROUP_ID

Quando um usuário autenticado usando a federação de identidade de colaboradores acessa um recurso, o IAM usa esses identificadores principais para avaliar as vinculações de papéis em políticas de permissão.

Práticas recomendadas:

Use um identificador de grupo imutável.
Reduza as associações de grupo em declarações ou tokens.
Microsoft Entra ID: use o ID do objeto como identificador do grupo.

Usar um identificador de grupo imutável

Todas as políticas do IAM referenciam grupos pelo identificador principal. Quando você renomeia um grupo no seu IdP para que o identificador dele mude, oGoogle Cloud não o reconhece mais como o mesmo grupo:

  • As vinculações de papel do IAM atuais continuam se referindo ao identificador principal antigo e se tornam ineficazes.
  • Os membros do grupo renomeado perdem o acesso porque o novo identificador principal do grupo não corresponde mais a nenhuma vinculação de função do IAM.

Para evitar essas interrupções, configure o mapeamento de atributos e declarações para usar um valor estável e imutável, como um ID exclusivo gerado pelo IdP. Evite usar nomes de exibição ou endereços de e-mail como identificadores de grupo, porque eles podem mudar durante as mudanças organizacionais.

Reduzir as associações a grupos em declarações ou tokens

Por padrão, seu IdP pode incluir mais associações a grupos em declarações SAML ou tokens de ID do que você precisa para gerenciar o acesso ao Gemini Enterprise e aos recursos do Google Cloud . Incluir associações desnecessárias a grupos cria vários riscos:

  • Perda parcial de acesso: muitos IdPs impõem limites ao número de associações a grupos que podem incluir em um token ou uma declaração. Quando um usuário excede esse limite (excesso de grupos), o IdP pode descartar algumas associações a grupos, fazendo com que o usuário perca o acesso a determinados recursos.
  • Falhas de login: a federação de identidade de colaboradores limita o tamanho e o número de associações a grupos que o mapeamento de atributos google.groups pode produzir. Os usuários que excederem um desses limites não poderão fazer login.
  • Uso inconsistente de grupos: se você expuser grupos a Google Cloud, os proprietários do projeto poderão decidir usar esses grupos para gerenciar o acesso a recursos, mesmo que você nunca tenha pretendido que determinados grupos fossem usados emGoogle Cloud.

As abordagens a seguir podem ajudar a reduzir esses riscos e o número de associações a grupos em declarações ou tokens:

  • Filtrar por tipo de grupo: alguns IdPs, incluindo o Microsoft Entra ID, permitem configurar um filtro que determina quais grupos incluir em declarações ou tokens. É possível configurar um filtro para excluir tipos de grupos que não são relevantes com base na sua configuração e nos serviços que você planeja usar.

    A tabela a seguir indica quais tipos de grupos podem ser necessários para incluir em declarações ou tokens, dependendo dos serviços que você planeja usar:

    Tipo de grupo Google Cloud Gemini (sem sincronização) Gemini (SCIM)
    Grupos de acesso -
    Grupos de restrição -
    Grupos organizacionais Não é necessário * -
    Grupos de colaboração Não é necessário * -

    * Obrigatório apenas se você estiver usando conectores baseados em ingestão de dados.

    • Para gerenciar o acesso a Google Cloud, inclua grupos de acesso e de imposição.
    • O filtro necessário para gerenciar o acesso ao Gemini Enterprise depende do uso do SCIM. Se você usa o SCIM, o Gemini Enterprise ignora as associações a grupos incluídas em asserções ou tokens. Portanto, não é necessário incluir grupos específicos do Gemini Enterprise. Se você não usa o SCIM, inclua os grupos de acesso e de aplicação necessários para o Gemini Enterprise. Dependendo se você planeja usar conectores baseados na ingestão de dados, talvez também seja necessário incluir determinados grupos organizacionais e de colaboração.

  • Atribuição: alguns IdPs, incluindo o Microsoft Entra ID, permitem restringir associações a grupos em tokens e declarações aos grupos atribuídos, que são os grupos que você atribui explicitamente à configuração da parte confiável.

  • Filtro de atributos extras: se você usa o Microsoft Entra ID e ativou o recurso de atributos extras, especifique um filtro usando a flag --extra-attributes-filter. A federação de identidade de colaboradores transmite esse filtro para a API Microsoft Graph ao solicitar associações a grupos.

Para testar ou resolver problemas com filtros, use a ferramenta Depurar token do IdP no console Google Cloud ou ative o registro de auditoria detalhado.

Microsoft Entra ID: use o ID do objeto como identificador do grupo

Essa prática recomendada só se aplica se você usa o ID do Microsoft Entra como IdP.

Se você usa o Microsoft Entra ID, os identificadores que podem ser usados como identificador de grupo incluem:

  • ID do objeto (oid)
  • Endereço de e-mail
  • Nome de exibição

Entre essas opções, recomendamos usar o ID do objeto (oid) como identificador do grupo pelos seguintes motivos:

  • Todos os grupos têm um ID de objeto. Por outro lado, o endereço de e-mail é um campo opcional que pode ser preenchido apenas para grupos do Microsoft 365.
  • O ID do objeto é exclusivo e imutável. Por outro lado, o nome de exibição de um grupo pode mudar e não ser exclusivo.

Recomendamos que você evite aplicar transformações, como forçar identificadores para caixa baixa, seja qual for o identificador escolhido.

Gerenciar acesso

Práticas recomendadas para limites de acesso e gerenciamento Just-in-Time (JIT).

Práticas recomendadas:

Use usuários do Cloud Identity para acesso de emergência.
Use o Cloud Identity para acesso altamente privilegiado.
Use as restrições da política da organização para governar a federação.
Não conceder acesso a todos os membros de um pool.
Limitar a duração da sessão.
Alinhe a duração da sessão aos requisitos de acesso JIT.

Usar usuários do Cloud Identity para acesso de emergência

Para garantir o acesso contínuo aos seus Google Cloud ambientes, crie usuários de acesso de emergência para cada um deles.

Os usuários com acesso de emergência fornecem acesso ao seu ambiente Google Cloud quando os serviços estão mal configurados, comprometidos ou não estão funcionando normalmente. Os usuários com acesso de emergência têm muitos privilégios. Confiar na federação de identidade de colaboradores para autenticar usuários com acesso de emergência apresenta os seguintes riscos:

  • Um erro na configuração do provedor de pool de identidade de colaboradores pode fazer com que você perca o acesso.
  • Uma interrupção de serviço que afete o IdP externo pode impedir que você use um usuário de acesso de emergência quando mais precisar.
  • Uma violação do IdP externo pode permitir que usuários mal-intencionados se autentiquem como um usuário de acesso de emergência e tenham acesso amplo aos seus recursos do Google Cloud.

Para reduzir esses riscos, use o Cloud Identity ou o Google Workspace para usuários de acesso de emergência, mesmo que você use a federação de identidade de colaboradores para outros usuários:

  • Crie usuários de acesso de emergência no Cloud Identity.
  • Exclua esses usuários do Logon único e permita que eles façam a autenticação usando um nome de usuário e uma senha.
  • Proteja esses usuários inscrevendo-os na verificação em duas etapas com uma chave de segurança.

Para mais informações sobre usuários com acesso de emergência, consulte Práticas recomendadas para acesso contínuo ao Google Cloud.

Usar o Cloud Identity para acesso altamente privilegiado

Os usuários com privilégios altos têm acesso amplo ao seu ambiente Google Cloud. Exemplos desses usuários:

  • Usuários com o papel de administrador da organização (roles/resourcemanager.organizationAdmin)
  • Usuários com a função de administrador de segurança (roles/iam.securityAdmin) ou uma função semelhante que pode modificar políticas de permissão em partes significativas da hierarquia de recursos do Google Cloud

Se você usa a federação de identidade de colaboradores para usuários com muitos privilégios, qualquer erro de configuração ou comprometimento no seu IdP externo pode afetar a segurança dos recursos do Google Cloud . Em particular, uma violação do IdP externo pode permitir que usuários mal-intencionados se autentiquem como um usuário altamente privilegiado e tenham acesso amplo aos seus recursos do Google Cloud .

Para mitigar esses riscos, use o Cloud Identity para usuários com muitos privilégios:

  • Crie usuários com muitos privilégios no Cloud Identity.
  • Proteja esses usuários inscrevendo-os na verificação em duas etapas com uma chave de segurança.
  • Se você federou o Cloud Identity com um IdP externo, ative mais verificações de SSO e a verificação em duas etapas para esses usuários.

Mais verificações do SSO podem parecer redundantes se o IdP já exigir a autenticação multifator. No entanto, essa configuração ajuda a proteger os usuários caso o IdP seja comprometido. As verificações adicionais de SSO são um recurso compatível com o Cloud Identity, mas não estão disponíveis para a federação de identidade de colaboradores.

Usar restrições de política da organização para governar a federação

Se você usa o Cloud Identity para fins diferentes do acesso de emergência ou altamente privilegiado, divida o uso da federação de identidade do Cloud Identity e da federação de identidade de colaboradores por serviço. Para aplicar essa prática, use restrições personalizadas de política da organização para restringir quais tipos de principais são permitidos em projetos específicos.

Por exemplo, é possível limitar a federação de identidade de colaboradores ao Gemini Enterprise fazendo o seguinte:

  • Aplique uma restrição de política da organização personalizada ao seu projeto do Gemini Enterprise que usa a função MemberTypeMatches para limitar os tipos principais permitidos a iam.googleapis.com/WorkforcePoolPrincipal e iam.googleapis.com/WorkforcePoolPrincipalSet. Estes são os principais tipos usados pela federação de identidade de colaboradores.
  • Para todos os outros projetos, aplique uma restrição que permita todos os tipos de principais, exceto iam.googleapis.com/WorkforcePoolPrincipal e iam.googleapis.com/WorkforcePoolPrincipalSet.

O uso de restrições personalizadas de política da organização ajuda a garantir a consistência e evita o uso acidental de tipos principais incorretos.

Não conceder acesso a todos os membros de um pool

A federação de identidade de colaboradores é compatível com um identificador principal curinga que usa o seguinte formato:

principalSet://iam.googleapis.com/locations/global/workforcePools/
POOL_ID/*

Esse identificador corresponde a todos os usuários que seu IdP permite autenticar no Google Cloud.

Não use esse identificador curinga para conceder permissões. À medida que a base de usuários do IdP cresce, conceder acesso com o identificador principal curinga leva a permissões excessivas.

Em vez disso, crie grupos de acesso no IdP e use-os para gerenciar o acesso aos recursos. Essa abordagem ajuda a garantir que o acesso seja regido pela associação intencional a grupos, em vez de uma autenticação bem-sucedida, reduzindo o risco de permissões excessivas.

Limitar a duração da sessão

Quando um usuário faz login, a federação de identidade de colaboradores inicia uma sessão. A sessão permite que um usuário faça o seguinte:

  • Use e navegue entre o console (federado), o Gemini Enterprise ou outros portais que oferecem suporte à federação de identidade de colaboradores.
  • Use aplicativos da Web protegidos pelo IAP.
  • Receba tokens de atualização federados e tokens de acesso federados, por exemplo, executando gcloud auth login.

Uma sessão permanece válida até que uma das seguintes situações ocorra:

  • A duração da sessão atinge o limite definido pelo pool de identidades da força de trabalho.
  • A duração da sessão atinge o limite definido no atributo SessionNotOnOrAfter na declaração SAML do usuário, se presente.
  • O usuário sai da conta.

Permitir que as sessões permaneçam válidas por períodos prolongados aumenta o risco de roubo de token e pode fazer com que as informações de associação a grupos fiquem desatualizadas:

  • Os usuários podem manter o acesso por mais tempo do que o pretendido se as permissões forem revogadas no IdP.
  • Os usuários talvez não consigam usar o acesso recém-concedido até que façam a autenticação novamente e estabeleçam uma nova sessão.

Para reduzir esses riscos, limite a duração da sessão para que os usuários precisem fazer login novamente pelo menos uma vez por dia.

Alinhar a duração da sessão aos requisitos de acesso JIT

Para gerenciar o acesso privilegiado, seus IdPs podem oferecer suporte a grupos just-in-time (JIT) que os membros podem ativar temporariamente. Usar grupos just-in-time para gerenciar o acesso privilegiado ao Google Cloud ou ao Gemini Enterprise pode apresentar os seguintes riscos:

  • Ativação atrasada: se um usuário tiver uma sessão ativa da federação de identidade de colaboradores ao ativar a associação a um grupo just-in-time, a mudança de associação ao grupo não vai entrar em vigor até que o usuário saia e faça login novamente. Como alternativa, se o provedor do pool de identidade da força de trabalho usar o SCIM, a mudança de associação não vai entrar em vigor até que a mudança de associação ao grupo seja provisionada.
  • Revogação atrasada: se uma associação a um grupo expirar, o usuário não perderá o acesso privilegiado até sair e fazer login de novo ou até que a mudança na associação ao grupo seja provisionada usando o SCIM. Dependendo da duração da sessão, esse atraso pode prejudicar o propósito do vencimento da assinatura.

Para reduzir esses riscos, configure a duração da sessão do pool de identidades de colaboradores para ser suficientemente curta.

Monitorar atividade

Sempre que você notar atividades suspeitas afetando um recurso em Google Cloud, os registros de auditoria do Cloud fornecem informações importantes para determinar quando a atividade ocorreu e quais usuários estavam envolvidos.

Ativar registros de acesso aos dados

A federação de identidade da força de trabalho pode gerar registros que permitem rastrear atividades de login e troca de tokens. A API Security Token Service grava esses registros, que incluem os seguintes métodos:

  • google.identity.sts.SecurityTokenService.WebSignIn
  • google.identity.sts.SecurityTokenService.WebSignOut
  • google.identity.sts.v1.SecurityTokenService.ExchangeToken
  • google.identity.sts.v1beta.SecurityTokenService.ExchangeToken

Todos os registros relacionados a atividades de login e troca de token são classificados como registros de acesso aos dados e ficam desativados por padrão. Para capturar esses registros, ative os registros de acesso aos dados para a API Security Token Service em toda a suaGoogle Cloud organização. Para aumentar ainda mais o nível de detalhes dos registros de acesso, ative a geração de registros detalhados de auditoria.

Para acompanhar outras atividades relacionadas à autenticação, recomendamos que você ative e use os seguintes registros:

A seguir