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

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

Aplique 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 corresponda aos seus requisitos.

Considerações de arquitetura:

Escolha um padrão de arquitetura de federação.
Particione 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 do Google Cloudcom um IdP externo:

Antes de federar, considere as vantagens e limitações de cada padrão e escolha o que corresponde 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, e não por usuário. A partição do uso por serviço tem menos desvantagens em 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 você precise de ambos 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 os usuários em dois grupos: um que usa a federação de identidade de colaboradores e outro que usa 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 as seguintes:

      • O gerenciamento de grupos de acesso pode ser complexo porque as políticas de permissão do IAM precisam conter uma combinação de tipos de principal, 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 grupos diferentes não podem compartilhar links entre si porque o console do Google Cloud , o Gemini Enterprise e outras ferramentas usam URLs diferentes dependendo de como os usuários fazem login.

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

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

    • Vantagem: simplifica a administração e garante um conjunto de atributos consistente para diferentes usuários.
    • Desvantagem: talvez seja necessário atribuir duas identidades a alguns funcionários: uma que use a federação de identidade de colaboradores e outra que use o Cloud Identity.

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

Para ajudar a aplicar esse particionamento, use as restrições da política da organização.

Fortalecer a governança do grupo

Gerencie o acesso usando grupos e estabeleça processos claros para controlar esses grupos para usar a federação de identidade de colaboradores de maneira eficaz.

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:

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 ao seguinte: 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 identidades de colaboradores.
    • SUBJECT: identifica exclusivamente um usuário específico. O valor e o formato dependem do IdP e do mapeamento de atributos.

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

Conceder acesso a principais individuais pode ser útil em situações específicas, mas tende a não ser escalonável devido aos seguintes problemas:

  • Adicionar principais 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 ao longo do tempo.

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

  • É possível 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 o mesmo papel têm o mesmo acesso aos recursos.

Para usar grupos para gerenciar o acesso, configure o IdP externo de determinadas maneiras e esteja ciente de todas as limitações que o IdP 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 aos serviços ou recursos do GoogleGoogle 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 geralmente são criados de forma ad hoc e de autoatendimento.
  • Grupos de aplicação: os grupos de aplicação, também chamados de grupos de políticas, 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 de 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 o Google Cloud, você só precisa de grupos de acesso e de aplicação.
  • Para o Gemini Enterprise, você precisa de grupos de acesso, grupos de restrição e, se estiver usando conectores baseados em ingestão de dados, determinados grupos organizacionais e de colaboração.

Ao configurar a federação de identidade de colaboradores, exclua tipos de grupo irrelevantes para evitar limites de token com seu IdP. Essa abordagem ajuda a reduzir o risco de exceder as limitações impostas pelo 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 o uso de conjuntos de principais que mapeiam para 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 executar essas funções.

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

  1. No IdP, crie grupos de acesso que representem funções de trabalho.
  2. Mapeie os grupos de acesso para conjuntos de principais para usá-los 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 as seguintes:

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

Verifique se os grupos de acesso são suficientemente refinados. Por exemplo, os grupos a seguir representam grupos de acesso efetivo:

  • 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 de 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 amplos, 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 projetados para listas de e-mails ou colaboração, não como um grupo de acesso.

    Para manter os grupos de acesso detalhados, crie um novo conjunto de grupos de acesso para cada carga de trabalho ou projeto que você integrar ao Google Cloud. Dessa forma, é possível escalonar o número de grupos de acesso para 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 normalmente diferem das seguintes maneiras:

  • Não permitem que os participantes saiam voluntariamente do grupo.
  • 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 de principal
  • Políticas da organização

Exemplos de grupos de aplicação incluem users-in-restricted-locations, fedramp-low e mfa-users. O número de grupos de restrição geralmente é pequeno e é improvável que afete o total de associações de um usuário.

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

Para gerenciar o acesso de forma 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 aos 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. O gerenciamento do acesso com grupos organizacionais pode exigir uma série 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. É possível usar grupos de colaboração para conceder acesso, o que pode levar a permissões excessivas e escalonamento de privilégios.

Para evitar 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 usados 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 aos recursos do Google Cloud , talvez você precise deles para o Gemini Enterprise:

  • Avaliação de ACL: ao usar conectores baseados em 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, talvez ele não avalie corretamente se o usuário está autorizado a acessar esses documentos.
  • Compartilhamento de notebooks: o Gemini Notebook Enterprise 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 nas declarações usadas para a federação de identidade de colaboradores.

Gerenciar pools de identidade de colaboradores

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 para parceiros.
Monitore sua cota de troca de tokens.

Usar 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 identidade de colaboradores gerenciam a autenticação em uma organização do Google Cloud , 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 usa um único IdP para gerenciar a autenticação, use um único pool de identidades de colaboradores.
  • Se a organização usa vários IdPs, por exemplo, devido a uma aquisição, use um pool de identidade de colaboradores por IdP.

Limitar o número de pools de identidade de colaboradores ajuda a garantir 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 do Google Cloud os usuários individuais podem acessar.

Escolha um nome exclusivo e significativo para o pool

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

  • Exclusividade: escolha um nome exclusivo no Google Cloud e que não tenha sido reivindicado por outra organização.
  • Imutabilidade: não é possível alterar o nome de um pool de identidade de colaboradores. Escolha um nome que permaneça significativo ao longo do tempo, evitando nomes de iniciativas temporárias.
  • Experiência do usuário: dependendo da 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 de grupo 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 organização do Google Cloud . O comprometimento desses componentes pode permitir que usuários de má-fé realizem ataques de spoofing.

Para realizar um ataque de spoofing, os usuários de má-fé podem tentar as seguintes ações:

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

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

  • Restringir 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 just-in-time: use o Privileged Access Manager (PAM) para conceder acesso administrativo just-in-time em vez de acesso permanente.

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

A federação do 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:

  • Realizar a autenticação multifator (MFA) que atenda aos seus requisitos de segurança.
  • Fazer declarações precisas sobre identidades de usuários e associações a grupos.
  • Siga os processos de governança de identidade que garantem que os usuários sejam removidos imediatamente e que as associações de grupo reflitam com precisão os papéis 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 de colaboradores não é compatível com a 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 é apropriado. Não use a federação de identidade de colaboradores para acesso de parceiros, a menos que você confie que o parceiro e o IdP dele atendem de forma consistente aos seus padrões de segurança.

Monitorar sua cota de troca de tokens

A troca de tokens da federação de identidade de colaboradores é limitada pela métrica de cota sts.googleapis.com/workforce_requests, que tem como padrão 1.000 solicitações por minuto e é aplicada por organização. A cota é compartilhada entre todos os pools de colaboradores, provedores, usuários e cargas de trabalho na organização. Os pools separados não recebem cotas separadas. Para ver o valor atual, consulte Cotas e limites.

Como a cota é para toda a organização, um único cliente de alta frequência pode esgotá-la e causar erros 429 RESOURCE_EXHAUSTED para todos os outros usuários na organização, incluindo administradores.

Recomendamos o seguinte:

  • Reserve a federação de identidade de colaboradores para o login humano. Encaminhe cargas de trabalho automatizadas, pipelines de CI/CD e agentes para a federação de identidade da carga de trabalho, que foi projetada para tráfego de máquina para máquina.
  • Recue quando houver limitação. Tente novamente as respostas 429 RESOURCE_EXHAUSTED com espera exponencial e instabilidade. Loops de repetição apertados aprofundam a saturação e prolongam a interrupção para todo mundo na organização.
  • Solicite mais cota antes de precisar dela. Se a organização tiver uma necessidade legítima e sustentada acima do padrão, solicite um aumento de cota em vez de operar no limite.
  • Alerta antes de atingir o limite da cota. Crie um alerta do Cloud Monitoring que é acionado quando o uso atinge 80% do limite, comparando serviceruntime.googleapis.com/quota/rate/net_usage com serviceruntime.googleapis.com/quota/limit, filtrado para metric.label.quota_metric="sts.googleapis.com/workforce_requests".
  • Manter o acesso de emergência. Verifique se pelo menos um administrador pode acessar sua organização sem a federação de identidade de colaboradores para que você ainda possa agir se a troca de tokens estiver sendo limitada.

Para ver o uso e o limite atuais, acesse a página "Cotas" no console do Google Cloud , selecione sua organização como o recurso e filtre por Workforce Pool token exchange requests.

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

Um provedor de pool de identidade de colaboradores 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 fornecidos pelo IdP.
  • Opcional: o locatário do SCIM a ser usado para procurar informações de associação ao grupo.

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.
Usar 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 identidade de colaboradores, esse nome não precisa ser globalmente exclusivo e não é codificado em identificadores de principal. No entanto, dependendo da configuração de login, talvez os usuários precisem 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, como entra ou staff.

Evite usar nomes como oidc ou saml, porque essas siglas podem não ser conhecidas pelos usuários.

Mostrar serviços individuais no portal do aplicativo 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 a eles. 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 do Google Cloud .
  • Configure links para fazer login do usuário automaticamente.

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

Aplicativo URL
Google Cloud Console da federação de identidade de colaboradores, também conhecido como 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
Gemini Notebook 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 de colaboradores.
  • PROVIDER: o nome do provedor do pool.
  • WEBAPP_ID: o ID do app da Web do Gemini Enterprise.
  • PROJECT_NUMBER: o número do projeto do Gemini Notebook Enterprise.

Usar 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 IdPs diferentes. 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 um risco de colisões de assunto. Nessas colisões, o mapeamento de atributos google.subject de um provedor retorna o mesmo valor que 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 os usuários.

Se você precisar fazer a federação com vários provedores, crie vários pools de colaboradores e configure um provedor para cada pool.

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

Se você usa a federação de identidade de colaboradores 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 precisar 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 de acordo com o provedor usado para fazer login.

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

Ao configurar um provedor, você especifica um URI de 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 do 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.

Evitar o uso do fluxo implícito do OpenID Connect (OIDC)

Ao configurar um provedor OIDC, prefira o fluxo do código de autorização ao 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 de colaboradores. A federação de identidade de colaboradores deriva o identificador principal de um usuário do token ou da declaração do usuário executando as seguintes etapas:

  1. Determine o identificador do assunto aplicando o mapeamento de atributos para google.subject. O identificador de assunto precisa identificar de maneira exclusiva um usuário em um pool de identidade de colaboradores, mas não precisa ser exclusivo em Google Cloud.

  2. Derive o identificador principal anexando o identificador de assunto a um prefixo que identifica o pool de identidade 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 nas políticas de permissão e o 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 identificador de assunto.

Usar um identificador de assunto imutável

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

  • O usuário não pode acessar recursos que antes estavam disponíveis porque o novo identificador de principal não corresponde mais aos identificadores listados nas políticas de permissão.
  • As entradas de registro 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 o identificador principal de um usuário estável, use um mapeamento de atributos que resulte em um valor estável para google.subject.

Muitos IdPs geram automaticamente um identificador numérico exclusivo ou formatado em UUID 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 usar.

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

  1. Exclusividade: o valor identifica de forma exclusiva um usuário no IdP.
  2. Usabilidade: o valor é significativo ou, pelo menos, facilmente pesquisável no diretório de usuários do IdP.
  3. Imutabilidade: o valor é imutável ou, pelo menos, mutável apenas por administradores.

Não reutilize identificadores de assunto

Muitos IdPs aplicam restrições de exclusividade em 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 provedor para google.subject se referir a um identificador de usuário que permite a reutilização, talvez você encontre colisões de assunto: a federação de identidade de colaboradores não consegue distinguir entre um usuário antigo e um novo se o google.subject deles for o mesmo. Como resultado, o novo usuário pode ter acesso a recursos destinados apenas ao usuário antigo.

Para evitar colisões de assunto, faça o seguinte:

Microsoft Entra ID: use o UPN como identificador de assunto

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

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

  • 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 identificador de 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 tendem a ser significativos e fáceis de usar.
  • 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 rege a reutilização de identificadores principais de usuário.

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 eles e não é significativo para os seres humanos.
  • O endereço de e-mail não é um atributo obrigatório e pode não ser preenchido para todos os usuários.

Independentemente do identificador escolhido, recomendamos que você evite aplicar transformações, como forçar identificadores para letras minúsculas.

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 de colaboradores.

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
SAML ou token de ID
API do Microsoft Graph - -
Locatário do SCIM - -

Se você usa o Microsoft Entra ID como IdP, pode ativar o recurso de atributos extras. A federação de identidade de colaboradores usa apenas a API Microsoft Graph como origem para as associações de grupo:

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

Se você usa o Gemini Enterprise, pode 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 do SCIM e ignora as informações de associação a grupos da declaração SAML ou do token de ID.
  • Google Cloud usa as informações de associação ao grupo da declaração SAML ou do token de ID e ignora as informações de associação ao grupo do locatário do SCIM.
Origem Google Cloud Gemini Enterprise
SAML ou token de ID -
API do Microsoft Graph - -
Locatário do SCIM -

Para cada associação de grupo, a federação de identidade de colaboradores deriva um identificador principal executando as seguintes 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 do 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 papel nas políticas de permissão.

Práticas recomendadas:

Use um identificador de grupo imutável.
Reduza as associações de grupos 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 fazem referência a grupos pelo identificador principal. Quando você renomeia um grupo no 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 papel 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 mudanças organizacionais.

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

Por padrão, seu IdP pode incluir mais associações de grupo em declarações SAML ou tokens de ID do que o necessário 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 ser incluídas em um token ou uma declaração. Quando um usuário excede esse limite (excesso de grupos), o IdP pode remover algumas associações de grupo, 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ê expor grupos ao Google Cloud, os proprietários do projeto poderão decidir usar esses grupos para gerenciar o acesso aos recursos, mesmo que você nunca tenha pretendido que determinados grupos fossem usados no Google Cloud.

As abordagens a seguir podem ajudar a reduzir esses riscos e o número de participações em 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 grupo 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 você pode precisar incluir em declarações ou tokens, dependendo dos serviços que 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 ao Google Cloud, é necessário incluir grupos de acesso e grupos de restriçã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 de grupo incluídas em declarações ou tokens, então não é necessário incluir grupos específicos do Gemini Enterprise. Se você não usa o SCIM, precisa incluir os grupos de acesso e de aplicação necessários para o Gemini Enterprise. Dependendo de você planejar usar conectores baseados em 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 as associações a grupos em tokens e declarações a 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, pode especificar 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 de grupo.

Para testar ou resolver problemas de filtros, use a ferramenta Depurar token do IdP no console do Google Cloud ou ative a geração de registros de auditoria detalhados.

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

Essa prática recomendada só se aplica se você usa o Microsoft Entra ID 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 o 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 é necessariamente exclusivo.

Independentemente do identificador escolhido, recomendamos que você evite aplicar transformações, como forçar identificadores para letras minúsculas.

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 controlar a federação.
Não conceda acesso a todos os membros de um pool.
Limitar a duração da sessão.
Alinhe a duração da sessão com os requisitos de acesso JIT.

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

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

Os usuários de acesso de emergência fornecem acesso ao ambiente do Google Cloud quando os serviços estão configurados incorretamente, comprometidos ou não estão funcionando normalmente. Os usuários com acesso de emergência têm privilégios elevados. Depender da federação de identidade de colaboradores para autenticar usuários de acesso de emergência introduz os seguintes riscos:

  • Um erro na configuração do provedor do pool de identidade de colaboradores pode fazer com que você seja bloqueado.
  • 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.
  • Se o IdP externo for comprometido, usuários de má-fé poderão se autenticar como um usuário de acesso de emergência e ter acesso amplo aos recursos do Google Cloud.

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

  • Criar 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 elevados têm amplo acesso ao ambiente do Google Cloud. Veja alguns exemplos desses usuários:

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

Se você usar a federação de identidade de colaboradores para usuários com privilégios elevados, qualquer configuração incorreta ou comprometimento no IdP externo poderá afetar a segurança dos recursos do Google Cloud . Em particular, um comprometimento do IdP externo pode permitir que usuários de má-fé se autentiquem como um usuário com privilégios elevados e tenham acesso amplo aos recursos do Google Cloud .

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

Mais verificações do SSO podem parecer redundantes se o IdP já exige 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 indisponível para a federação de identidade de colaboradores.

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

Se você usa o Cloud Identity para fins que não sejam de emergência ou de acesso altamente privilegiado, particione o uso da federação do Cloud Identity e da federação de identidade de colaboradores por serviço. Para aplicar essa prática, use restrições personalizadas da política da organização para limitar quais tipos de principal 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 de principal permitidos a iam.googleapis.com/WorkforcePoolPrincipal e iam.googleapis.com/WorkforcePoolPrincipalSet. Estes são os tipos de principal usados pela federação de identidade de colaboradores.
  • Para todos os outros projetos, aplique uma restrição que permita todos os tipos de principal, exceto iam.googleapis.com/WorkforcePoolPrincipal e iam.googleapis.com/WorkforcePoolPrincipalSet.

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

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

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

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

Esse identificador corresponde a todos os usuários que o 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 de caractere curinga leva a um excesso de permissões.

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 controlado pela associação intencional ao grupo, e não pela 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:

  • Usar e navegar entre o console (federado), o Gemini Enterprise ou outros portais compatíveis com a federação de identidade de colaboradores.
  • Usar 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:

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 ao grupo fiquem desatualizadas:

  • Os usuários podem manter o acesso por mais tempo do que o pretendido se as permissões forem revogadas no IdP.
  • Talvez os usuários não consigam exercer o acesso recém-concedido até que se autentiquem 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 com os 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. O uso de grupos just-in-time para gerenciar o acesso privilegiado ao Google Cloud ou ao Gemini Enterprise pode introduzir 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 ao grupo just-in-time, a mudança na associação só vai entrar em vigor quando o usuário sair e fizer login novamente. Como alternativa, se o provedor do pool de identidades de colaboradores usar o SCIM, a mudança na associação não entrará em vigor até que a mudança na associação ao grupo seja provisionada.
  • Revogação atrasada: se uma assinatura de grupo expirar, o usuário não perderá o acesso privilegiado até que saia e faça login novamente ou que a mudança na assinatura do grupo seja provisionada usando o SCIM. Dependendo da duração da sessão, esse atraso pode prejudicar a finalidade da expiração da associação.

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

Monitorar atividade

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

Ativar registros de acesso aos dados

A federação de identidade de colaboradores 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 às atividades de login e troca de tokens são classificados como registros de acesso a 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 organização doGoogle Cloud . Para aumentar ainda mais a verbosidade dos registros de login, ative a geração de registros de auditoria detalhados.

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

A seguir