Padrões de arquitetura para federação de identidade

Este documento compara quatro padrões arquitetônicos para federar Google Cloud com um provedor de identidade (IdP) externo. Ele também oferece orientações para ajudar você a escolher uma arquitetura adequada para seu caso de uso.

Os quatro padrões de arquitetura são os seguintes:

Fatores de decisão

Para escolher um padrão de arquitetura adequado à sua organização, considere vários fatores, incluindo:

Portfólio de serviços

Os serviços do Google gerenciam a autenticação e a autorização de maneiras diferentes. Isso afeta a configuração da federação de identidade. Dois fatores determinam essas diferenças: o modelo de serviço SaaS x PaaS e IaaS e o modelo de autorização IAM x específico do serviço.

Modelos de serviço

  • Software como serviço (SaaS): o Google gerencia totalmente serviços como Gmail, Google Ads ou o app Gemini Enterprise. Esses serviços não exigem esforço de desenvolvimento e estão prontos para uso. Como os serviços de SaaS são destinados a um grande público, a maioria dos seus usuários pode precisar de acesso a eles.
  • Plataforma como serviço (PaaS) ou infraestrutura como serviço (IaaS): a maioria dos serviços doGoogle Cloud são PaaS ou IaaS. Esses serviços permitem que usuários técnicos desenvolvam, implantem e operem cargas de trabalho personalizadas. Como esses serviços são destinados a um público técnico, apenas um subconjunto dos seus usuários precisa de acesso.

Modelos de autorização

Os serviços do Google implementam a autorização de uma destas duas maneiras:

  • IAM: a maioria dos serviços do Google Cloud usa o IAM para permitir que os administradores gerenciem o acesso refinado aos recursos.
  • Autorização específica do serviço: serviços como Google Ads, Looker ou Google Workspace não usam o IAM. Em vez disso, os administradores gerenciam o acesso usando ferramentas específicas para cada serviço.

Esses fatores resultam nos seguintes grupos de serviços:

SaaS PaaS ou IaaS
Autorização baseada no IAM Google Cloud Serviços de SaaS, como o app Gemini Enterprise e o NotebookLM Enterprise Google Cloud Serviços de PaaS e IaaS, como BigQuery ou Compute Engine
Autorização específica do serviço Serviços do Google que não são de nuvem, como Google Ads, Google Workspace e Google Maps Nenhum

Para escolher um padrão de arquitetura adequado à sua organização, considere quais grupos de serviços se aplicam a ela.

Residência de dados

Para autenticar usuários e gerenciar sessões, o Cloud Identity, o Google Workspace e a Federação de Identidade de Colaboradores processam informações pessoais do usuário. Essas informações podem incluir:

  • Nomes de usuário ou endereços de e-mail
  • Atributos do usuário, como nome e sobrenome
  • Nomes e associações a grupos

O Cloud Identity, o Google Workspace e a federação de identidade de colaboradores processam esses dados de acordo com os termos para dados de serviço e podem armazená-los fora dos locais da sua organização ou dos usuários:

  • O Cloud Identity e o Google Workspace armazenam dados de serviço em data centers do Google e podem replicá-los em todos os data centers. Os dados armazenados podem incluir informações que não são essenciais para a autenticação, como nomes de departamentos, endereços ou números de telefone.
  • A Federação de identidade da força de trabalho armazena dados de serviço em Google Cloud regiões e pode replicá-los em todas as regiões.

Se você conceder a um usuário acesso a um recurso, o IAM vai armazenar o identificador principal dele em uma vinculação de função.O Google Cloud processa vinculações de função de acordo com os termos para dados de serviço e pode armazená-las em todas as regiões do Google Cloud .

Os padrões de arquitetura descritos nesta página exigem o armazenamento de informações do usuário, mas diferem em quanto tempo essas informações são armazenadas:

Muitos IdPs permitem automatizar a suspensão ou exclusão de contas de usuário quando o status da conta de usuário correspondente muda no IdP. Dependendo do IdP e da configuração dele, o IdP pode atrasar a exclusão da conta de usuário até que um determinado período de carência termine. Isso pode estender o tempo em que o Google Cloudarmazena as informações do usuário.

Integração do Gemini Enterprise com o Microsoft 365

O Gemini Enterprise permite que você se conecte aos serviços do Microsoft 365 usando dois tipos de conectores:

  • Conectores baseados na ingestão de dados: esses conectores rastreiam o Microsoft 365 para criar um índice de pesquisa no Google Cloud. Quando um usuário envia um comando, o Gemini Enterprise usa esse índice para pesquisar conteúdo e realiza verificações de acesso localmente, avaliando as listas de controle de acesso (ACLs) obtidas do Microsoft 365.
  • Conectores federados: esses conectores consultam o Microsoft 365 para cada comando. Eles usam a autorização delegada para permitir que o Microsoft 365 faça as verificações de acesso diretamente.

Os conectores baseados na ingestão de dados introduzem requisitos específicos para a federação de usuários:

  • Reconhecimento da associação a grupos: as ACLs do Microsoft 365 podem incluir entradas para grupos e usuários. Para avaliar se um usuário pode acessar o conteúdo, os conectores precisam considerar todos os grupos a que ele pertence. Se o conector conhecer apenas um subconjunto dos grupos do usuário, ele poderá permitir ou negar o acesso incorretamente.
  • Conversão de identificadores: para avaliar as ACLs, o conector precisa converter entre os identificadores de usuário e grupo usados pelo Microsoft 365 e os identificadores usados pelo Google Cloud.

Ao usar a federação de identidade de colaboradores, o Gemini Enterprise pode converter identificadores e avaliar ACLs de forma confiável se você configurar mapeamentos de atributos para serem compatíveis com o Gemini Enterprise.

Ao usar a federação do Cloud Identity ou do Google Workspace, o Microsoft Entra ID controla os mapeamentos de atributos para o provisionamento de usuários e grupos, em vez de Google Cloud. O Entra determina as regras de conversão para identificadores de usuários e grupos, que podem envolver transformações complexas. Para avaliar uma ACL, o conector do Gemini Enterprise precisa aplicar as mesmas regras de conversão, mas não tem visibilidade da configuração do Entra. Portanto, quando você usa a federação do Cloud Identity ou do Google Workspace, o Gemini Enterprise não consegue converter identificadores de usuários e grupos nem avaliar ACLs de forma confiável.

Para determinar qual padrão de arquitetura é adequado à sua organização, considere o uso do Gemini Enterprise e se você planeja usar conectores baseados em ingestão de dados.

Padrões de arquitetura

O fluxograma a seguir mostra como esses fatores determinam qual padrão atende aos requisitos da sua organização:

Fluxograma mostrando como selecionar o padrão de federação de identidade.

  1. Uma parte significativa da sua organização usa o Google Workspace?

  2. Você usa serviços além do Google Cloud , como o Google Ads ou o Google Maps?

    • Se a resposta for Sim, prossiga para a decisão 3.
    • Se a resposta for Não, vá para a decisão 4.

  3. Você planeja usar o Gemini Enterprise e integrá-lo ao Microsoft 365?

  4. Você planeja usar o Gemini Enterprise?

  5. Você tem requisitos de residência de dados que exigem a minimização do armazenamento de informações do usuário?

Federação do Cloud Identity ou do Google Workspace

Selecione esse padrão quando sua organização atender a um dos seguintes critérios:

  • Uma parte significativa da sua organização já usa o Google Workspace.
  • Você usa os Serviços do Google além do Google Cloud , como o Google Ads ou o Google Maps, mas não planeja integrar o Gemini Enterprise ao Microsoft 365 usando conectores baseados em ingestão de dados.
  • Você usa apenas os serviços do Google Cloud , não planeja usar o Gemini Enterprise e não tem requisitos rígidos de residência de dados para minimizar o armazenamento de dados do usuário.

Neste padrão, você não usa a federação de identidade de colaboradores. Em vez disso, você federa sua conta do Cloud Identity ou do Google Workspace com seu IdP e usa o provisionamento antecipado de usuários e grupos.

Arquitetura da federação do Cloud Identity e do Google Workspace.

Nesse padrão, é necessário provisionar usuários e grupos antes que os usuários possam fazer login. Caso contrário, a tentativa de login falhará:

  • Provisionamento de usuários: ajuda a garantir a integração e o desligamento oportunos de usuários.
  • Provisionamento de grupos: permite usar grupos para gerenciar o acesso aos serviços do Google e aos recursos do Google Cloud .

Se apenas um subconjunto de usuários da sua organização precisar do Google Workspace, adicione uma assinatura do Google Workspace e uma do Cloud Identity à sua conta e atribua licenças do Google Workspace apenas aos usuários que precisam delas.

Benefícios

  • Os usuários podem se autenticar nos serviços do Google, independente de eles usarem o IAM ou não. Na conta do Cloud Identity ou do Google Workspace, controle quais Serviços do Google os usuários podem usar.
  • Você pode limitar o logon único (SSO) e o provisionamento antecipado a um subconjunto de usuários e continuar gerenciando usuários específicos, como usuários de acesso de emergência, diretamente no Cloud Identity ou no Google Workspace.
  • É possível provisionar grupos do seu IdP externo, gerenciar grupos localmente na sua conta do Cloud Identity ou do Google Workspace ou combinar as duas abordagens.

Limitações

  • O provisionamento antecipado de contas de usuário aumenta o overhead e pode deixar o processo de integração mais lento.

  • Não é possível controlar ou restringir os locais que o Cloud Identity ou o Google Workspace usam para armazenar dados de usuários e grupos. Como o Google processa e armazena dados do usuário e dados de grupo de acordo com os termos para dados de serviço, os controles de região de dados não abrangem esses dados, e o Google pode replicar esses dados em locais de data center do Google.

  • O Gemini Enterprise oferece suporte limitado para conexão com fontes de dados da Microsoft quando você usa a federação do Cloud Identity ou do Google Workspace.

Federação de identidade da força de trabalho sem sincronização

Selecione esse padrão quando sua organização atender aos seguintes critérios:

  • Você usa apenas os serviços do Google Cloud .
  • Você usa o Gemini Enterprise, mas espera ficar dentro das limitações de grupo impostas pelo seu IdP.
  • Você tem requisitos de residência de dados que exigem a minimização do armazenamento de informações pessoais do usuário.

Arquitetura da federação de identidade da força de trabalho, sem sincronização.

Nesse padrão, você usa a federação de identidade de colaboradores para federar sua Google Cloud organização com seu IdP externo.

Esse padrão não exige provisionamento de usuários ou grupos. Sempre que um usuário faz login, o IdP transmite as informações necessárias sobre o usuário, incluindo associações a grupos e atributos personalizados, para o Google Cloud, e o Google Cloud mantém essas informações apenas durante a sessão do usuário.

Benefícios

  • Não é necessário armazenar ou gerenciar contas ou grupos de usuários em Google Cloud.
  • O padrão permite usar conectores baseados na ingestão de dados para integrar o Gemini Enterprise ao Microsoft 365.

Limitações

  • A federação de identidade de colaboradores é um recurso do IAM e permite que os usuários acessem apenas serviços que usam o IAM. Os usuários que fazem autenticação usando a federação de identidade de colaboradores não podem acessar serviços do Google, como Google Ads, Looker ou Google Marketing Platform.
  • Os usuários que se autenticam usando a federação de identidade de colaboradores não podem acessar alguns recursos do Google Cloud . Para mais detalhes, consulte Federação de identidade: produtos e limitações.
  • Muitos IdPs limitam o número de associações a grupos que podem transmitir para a federação de identidade da força de trabalho em uma declaração SAML ou um token de ID. Para ficar abaixo desses limites, talvez seja necessário reforçar a governança de grupos e restringir os tipos de grupos a incluir em declarações ou tokens.
  • Ao compartilhar recursos, como um notebook do NotebookLM Enterprise, não é possível pesquisar um grupo por nome. Em vez disso, os usuários precisam inserir manualmente os identificadores.

Se você usa o Microsoft Entra ID, é possível usar uma variação desse padrão configurando atributos extras. Ao configurar atributos extras, a federação de identidade de colaboradores executa um callback para a API Microsoft Graph durante a autenticação do usuário para recuperar as associações a grupos. Essa configuração permite superar os limites de associação a grupos do Entra para declarações SAML e tokens de ID e usar até 999 associações a grupos por usuário.

Federação de identidade da força de trabalho com SCIM

Selecione esse padrão quando sua organização atender aos seguintes critérios:

  • Você usa apenas os serviços do Google Cloud . Ou seja, você não usa serviços externos do Google, como o Google Ads ou o Google Maps.
  • Você planeja usar o Gemini Enterprise ou o NotebookLM Enterprise e precisa oferecer suporte a até 2.000 associações a grupos por usuário ou a capacidade de pesquisar grupos por nome ao compartilhar recursos.

Arquitetura da federação de identidade de colaboradores com SCIM.

Neste padrão, você usa a federação de identidade de colaboradores para federar sua Google Cloud organização. Para aumentar o número de grupos que podem ser usados no Gemini Enterprise, configure o SCIM para provisionar informações de associação a grupos com antecedência.

Benefícios

  • O padrão permite usar conectores baseados na ingestão de dados para integrar o Gemini Enterprise ao Microsoft 365.
  • É possível usar até 2.000 associações a grupos por usuário para controlar o acesso ao Gemini Enterprise e ao NotebookLM Enterprise e permitir que os conectores baseados na ingestão de dados do Gemini Enterprise façam verificações de acesso.
  • Ao compartilhar recursos, como um notebook do NotebookLM Enterprise, você pode pesquisar grupos por nome para melhorar a experiência geral do usuário.

Limitações

  • O suporte a grupos provisionados com SCIM é limitado ao Gemini Enterprise e ao NotebookLM Enterprise. Outros serviços só podem consumir as associações a grupos que seu IdP transmite na declaração SAML ou no token de ID.
  • A federação de identidade de colaboradores é um recurso do IAM e permite que os usuários acessem apenas serviços que usam o IAM. Os usuários que fazem autenticação usando a federação de identidade de colaboradores não podem acessar serviços do Google, como Google Ads, Looker ou Google Marketing Platform.
  • Os usuários que se autenticam usando a federação de identidade de colaboradores não podem acessar alguns dos recursos do Google Cloud . Para mais detalhes, consulte Federação de identidade: produtos e limitações.

Cloud Identity híbrida e federação de identidade da força de trabalho

Selecione esse padrão quando sua organização atender aos seguintes critérios:

  • Você usa Serviços do Google além de Google Cloud (como o Google Ads ou o Google Maps).
  • Você planeja usar o Gemini Enterprise e integrá-lo ao Microsoft 365.

Arquitetura da federação híbrida do Cloud Identity e da federação de identidade da força de trabalho.

Esse padrão combina dois dos padrões anteriores:

  • Você usa a federação de identidade de colaboradores (sem sincronização ou com SCIM) para gerenciar o acesso ao Gemini Enterprise e ao NotebookLM Enterprise.
  • Você usa a federação do Cloud Identity ou do Google Workspace para gerenciar o acesso a outros serviços, incluindo Google Cloud e serviços do Google que não são da nuvem.

Benefícios

Esse padrão permite combinar os benefícios dos dois padrões anteriores:

  • Você pode conectar o Gemini Enterprise a fontes de dados da Microsoft sem limitações de recursos.
  • Os usuários podem se autenticar nos serviços do Google, independente de eles usarem o IAM ou não.
  • Use o conjunto completo de recursos do Google Cloud .

Limitações

  • Você precisa manter duas configurações de relying party separadas no IdP externo: uma para o Cloud Identity e outra para a federação de identidade de colaboradores.
  • Dependendo se você configurar um usuário para usar o Cloud Identity ou a federação de identidade de colaboradores, a experiência de login pode ser diferente.
  • Ao gerenciar políticas de permissão do IAM, é necessário usar diferentes identificadores principais dependendo de como um usuário se autentica. Por exemplo, um usuário conhecido como bob@example.com no seu IdP externo pode ter o identificador principal bob@example.com ou principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID//subject/SUBJECT_ID no IAM, dependendo se ele faz autenticação usando a federação do Cloud Identity ou a federação de identidade de colaboradores.
  • Não é possível criar grupos que contenham uma mistura de usuários do Cloud Identity e principais da federação de identidade de colaboradores. Os grupos do Cloud Identity só podem conter usuários do Cloud Identity, e os grupos de identidade de colaboradores só podem conter principais da federação de identidade de colaboradores.
  • Estender o uso da federação de identidade de colaboradores além do Gemini Enterprise pode exigir que os usuários troquem de identidade ou fiquem em dúvida sobre como fazer a autenticação.

A seguir