Configurar o provedor de identidade

Para aplicar o controle de acesso à fonte de dados e proteger os dados no Gemini Enterprise, configure um provedor de identidade. Isso envolve configurar o provedor de identidade e gerenciar as permissões das fontes de dados. O Google usa seu provedor de identidade para identificar o usuário final que está fazendo uma pesquisa e determinar se ele tem acesso aos documentos retornados como resultados.

Escolher o tipo de provedor de identidade

O tipo de provedor de identidade escolhido depende das fontes de dados conectadas ao app Gemini Enterprise. O Gemini Enterprise oferece suporte às seguintes opções:

Tipo de provedor de identidade Quando usar
Google Identity O Google Identity é o provedor de identidade recomendado para o Gemini Enterprise.

O Google Identity é compatível com:
  • Todas as fontes de dados próprios do Google que usam ingestão ou federação de dados. Você precisa usar o Google Identity ao se conectar a fontes de dados do Google Workspace.
  • Todas as fontes de dados de terceiros que usam a federação de dados, em que os usuários se autenticam diretamente com o serviço de terceiros usando o OAuth.
  • Todas as fontes de dados de terceiros que usam a ingestão de dados, com exceção das fontes de dados do Microsoft 365, como SharePoint, OneDrive ou Outlook, que exigem o Microsoft Entra ID e a federação de identidade de colaboradores.
Antes de configurar o Google Identity, determine o atributo de usuário exclusivo que sua organização usa, que geralmente é o e-mail do usuário. Se os usuários tiverem mais de um endereço de e-mail, adicione um alias de e-mail.
Provedor de identidade terceirizado Ao conectar o Gemini Enterprise apenas a fontes de dados de terceiros e já usar um provedor de identidade de terceiros compatível com OIDC ou SAML 2.0, como o Microsoft Entra ID, o Okta ou o AD FS, é possível usar o Google Identity ou a federação de identidade de colaboradores. O Google recomenda o uso do Google Identity para novas configurações. Os clientes que já usam a federação de identidade de colaboradores podem optar por permanecer nela. Saiba mais em federação de identidade de colaboradores.

Antes de configurar a federação de identidade de colaboradores, determine os atributos de usuário exclusivos que sua organização usa e mapeie-os para a federação de identidade de colaboradores.

Controle de acesso para conectores do Google Workspace

Quando você usa o embasamento de dados corporativos e a pesquisa com conectores do Google Workspace (como Pessoas do Google Workspace ou Grupos do Google), o Gemini Enterprise respeita estritamente as listas de controle de acesso (ACLs) e as permissões do sistema de origem.

Princípio básico: sem escalonamento de privilégios

Um usuário que interage com o Gemini Enterprise só pode visualizar e embasar respostas em informações que já tem autorização para acessar diretamente no aplicativo de origem do Google Workspace. O Gemini Enterprise nunca ignora os controles de acesso do sistema de origem nem concede permissões adicionais.

  • Pessoas do Google Workspace (Diretório): a visibilidade do usuário na pesquisa e nos resultados de embasamento respeita as configurações de visibilidade do Diretório da sua organização. Por exemplo, se a visibilidade de um usuário no diretório do Google Workspace estiver limitada ao próprio departamento ou unidade organizacional, ele só poderá encontrar colegas desse departamento usando o Gemini Enterprise. Eles não podem ver perfis de funcionários em departamentos restritos.

  • Grupos do Google:a descoberta e o embasamento de conteúdo seguem as configurações de acesso e participação no grupo. Um usuário só pode pesquisar e ver conteúdo dos Grupos do Google de que é membro e tem permissão para ver. Os não participantes não podem descobrir nem ver discussões de grupos particulares pelo Gemini Enterprise.

Onde gerenciar as permissões

Não é possível definir as configurações de controle de acesso e visibilidade nas configurações do conector do Gemini Enterprise no console do Google Cloud . Em vez disso, um administrador do Google Workspace define as configurações de permissão, associação e visibilidade no sistema de origem:

  • Visibilidade do perfil do usuário: o administrador do Google Workspace configura a visibilidade do perfil do usuário no Google Admin Console. Para mais informações, consulte Configurar o compartilhamento de diretórios.

  • Acesso e associação ao grupo:o administrador do Google Workspace configura o acesso e a associação ao grupo nos Grupos do Google ou no Google Admin Console. Para mais informações, consulte Configurar e gerenciar grupos.

Federação de identidade de colaboradores para provedores de identidade terceirizados

Nesta seção, descrevemos como configurar a federação de identidade de colaboradores para provedores de identidade de terceiros. Se quiser, verifique se a configuração da federação de identidade de colaboradores está funcionando conforme o esperado.

Configurar a federação de identidade de colaboradores

Para detalhes sobre como configurar a federação de identidade de colaboradores com seu conector de identidade de terceiros, consulte os seguintes recursos:

Provedor de identidade Recursos
Entra ID
Okta
OIDC ou SAML 2.0

Configurar o mapeamento de atributos

O mapeamento de atributos ajuda a conectar suas informações de identidade de terceiros ao Google usando a federação de identidade da força de trabalho.

Ao configurar o mapeamento de atributos na federação de identidade de colaboradores, considere o seguinte:

  • O atributo google.subject é usado para mapeamento de atributos, atribuição de licenças e compartilhamento de notebooks. Recomendamos mapear google.subject para o endereço de e-mail do usuário em letras minúsculas, já que a atribuição de licenças diferencia maiúsculas de minúsculas.

  • Se a organização tiver mais de um identificador exclusivo, mapeie esses atributos organizacionais exclusivos usando o atributo attribute.as_user_identifier_number between 1 and 50.

    Por exemplo, se a organização usar e-mail e nome principal como identificadores de usuário em diferentes aplicativos, e o nome principal for definido como preferred_username no provedor de identidade de terceiros, você poderá mapeá-lo para o Gemini Enterprise usando o mapeamento de atributos da federação de identidade de colaboradores (por exemplo, attribute.as_user_identifier_1=assertion.preferred_username).

Confira a seguir exemplos dos mapeamentos de atributos necessários para provedores de identidade comuns. É possível adicionar mais mapeamentos de atributos para oferecer suporte a outros identificadores exclusivos, conforme descrito anteriormente.

  • ID do Entra com protocolo OIDC
    Este exemplo usa o e-mail para identificar usuários de forma exclusiva.

    google.subject=assertion.email.lowerAscii()
google.groups=assertion.groups
google.display_name=assertion.given_name

  • ID do Entra com protocolo SAML
    Este exemplo usa o e-mail para identificar usuários de forma exclusiva.

    google.subject=assertion.attributes['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'][0].lowerAscii()
google.groups=assertion.attributes['http://schemas.microsoft.com/ws/2008/06/identity/claims/groups']
google.display_name=assertion.attributes['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname'][0]

  • Okta com protocolo OIDC
    Este exemplo usa o e-mail para identificar usuários de forma exclusiva.

    google.subject=assertion.email.lowerAscii()
google.groups=assertion.groups

  • Okta com protocolo SAML
    Este exemplo usa a declaração de assunto do JWT para identificar usuários de forma exclusiva.

    google.subject=assertion.subject.lowerAscii()
google.groups=assertion.attributes['groups']

Opcional: verificar a configuração da federação de identidade de colaboradores

Para verificar se os inícios de sessão foram bem-sucedidos e se o mapeamento de atributos está correto usando o recurso de geração de registros de auditoria da federação de identidade da força de trabalho, faça o seguinte:

  1. Ative os registros de auditoria para a API Security Token Service da atividade de acesso a dados.

    1. No console Google Cloud , acesse a página Registros de auditoria:

      Acesse Registros de auditoria

      Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo IAM e administrador.

    2. Selecione um projeto, uma pasta ou uma organização Google Cloud .
    3. Ative os registros de auditoria de acesso a dados.
      1. Consulte a documentação do Logging para ver as etapas detalhadas sobre como ativar os registros de auditoria.
      2. Para a API Security Token Service, selecione o tipo de registro de auditoria Leitura de administrador. Para mais informações, consulte Registros de exemplo para a federação de identidade de colaboradores.

  2. Ative o registro detalhado no pool de funcionários. O recurso de grupos estendidos da federação de identidade de colaboradores para o Microsoft Entra ID não gera informações detalhadas de registro de auditoria.

    1. Acesse a página Pools de identidade da força de trabalho:

      Acessar pools de identidade de colaboradores

    2. Na tabela, selecione o pool.

    3. Clique no botão Ativar registro de auditoria detalhado para a posição ativada.

    4. Clique em Salvar pool.

  3. Na seção Provedores, clique no URL de login do seu provedor e faça login no console do Google Cloud como usuário de um pool de colaboradores.

  4. Consulte os registros de auditoria gerados quando você fez login.

    1. Acesse a página Pools de identidade da força de trabalho:

      Acessar pools de identidade de colaboradores

    2. Na tabela, selecione o pool em que você fez login.

    3. Clique em Ver ao lado de Registros.

    4. Na página do registro de auditoria, limpe o filtro protoPayload.resourceName da consulta.

    5. Clique em Executar consulta.

  5. Verifique os registros de auditoria para encontrar uma entrada com o método google.identity.sts.SecurityTokenService.WebSignIn que corresponda ao carimbo de data/hora do login.

  6. Confirme se o campo metadata.mapped_attributes no registro corresponde ao atributo usado ao configurar a federação de identidade de colaboradores para provedores de identidade de terceiros.

    Exemplo:

    "metadata": {
  "mapped_attributes": {
    "attributes.as_user_identifier_1": "alex@admin.altostrat.com"
    "google.subject": "alex@altostrat.com"
    "google.groups": "[123abc-456d, efg-h789-ijk]"
  }
},

Limitações

Ao conectar suas fontes de dados usando um conector para criar repositórios de dados, as seguintes limitações se aplicam:

  • São permitidos 3.000 leitores por documento. Cada principal conta como um leitor, e um principal pode ser um grupo ou um usuário individual.

  • É possível selecionar um tipo de provedor de identidade por local (global, us ou eu) compatível com o Gemini Enterprise. Ao usar a federação de identidade de colaboradores, o pool de identidade de colaboradores precisa ser criado no local global (locations/global/workforcePools/<var>WORKFORCE_POOL_ID</var>) e pode ser associado a qualquer local compatível com o Gemini Enterprise.

  • Se as configurações do provedor de identidade forem atualizadas mudando o tipo de provedor ou o pool de força de trabalho, os repositórios de dados atuais não serão atualizados automaticamente para as novas configurações. É necessário excluir e recriar esses repositórios de dados para aplicar as novas configurações de identidade.

  • Para definir uma fonte de dados como controlada por acesso, selecione essa configuração durante a criação do repositório de dados. Não é possível ativar ou desativar essa configuração para um repositório de dados existente.

  • Para conferir os resultados da interface em apps de pesquisa que usam controle de acesso de terceiros, faça login no console federado ou use o app da Web. Consulte Visualizar seu app.

Conectar ao seu provedor de identidade

A seção a seguir descreve como se conectar ao provedor de identidade usando o console doGoogle Cloud .

Antes de começar

Antes de conectar o provedor de identidade, faça o seguinte:

  • Conceder permissões aos administradores.

  • Se você estiver conectando um provedor de identidade de terceiros usando a federação de identidade de colaboradores, configure a federação de identidade de colaboradores.

Conectar provedor de identidade

Para especificar um provedor de identidade para o Gemini Enterprise e ativar o controle de acesso à fonte de dados, siga estas etapas:

  1. No console Google Cloud , acesse a página Gemini Enterprise.

    Gemini Enterprise

  2. Clique em Configurações > Autenticação.

  3. Clique em Adicionar provedor de identidade para o local do Gemini Enterprise (global, us ou eu) que você quer atualizar.

  4. Clique em Adicionar provedor de identidade e selecione o tipo de provedor.
    Se você selecionar Identidade de terceiros, escolha o pool de colaboradores (localizado em global) que se aplica às suas fontes de dados.

  5. Clique em Salvar alterações.

Conceder permissões aos usuários

Os usuários precisam da função de usuário corporativo do Gemini Enterprise (roles/discoveryengine.agentspaceUser) para acessar, gerenciar e compartilhar apps.

Tipo de provedor de identidade Descrição
Google Identity
  • Se você usa o Google Identity, recomendamos criar um grupo do Google que inclua todos os funcionários que usam o app.
  • Se você for administrador do Google Workspace, poderá incluir todos os usuários de uma organização em um grupo do Google seguindo as etapas em Adicionar todos os usuários da sua organização a um grupo.
  • Conceda a função de usuário corporativo do Gemini Enterprise (roles/discoveryengine.agentspaceUser) aos usuários. Para mais informações sobre como adicionar a função, consulte Conceder permissões aos usuários.
Provedor de identidade terceirizado

Impacto das mudanças nas configurações do provedor de identidade nos conectores de ingestão

Quando você muda as configurações de identidade, como o provedor de identidade ou o pool da federação de identidade de colaboradores, os repositórios de dados atuais que usam a ingestão de dados não são atualizados automaticamente. Para aplicar as novas configurações de identidade, exclua e recrie os repositórios de dados afetados.

A tabela a seguir resume quais mudanças na configuração de identidade exigem a recriação do repositório de dados:

Alterar tipo Exige recriação do repositório de dados
Alternar entre a Identidade do Google e um provedor de identidade terceirizado Sim
Mudar completamente para um novo pool da federação de identidade de colaboradores Sim
Editar o mapeamento de atributos no provedor de identidade atual Não
Mudar para um novo provedor no mesmo pool da federação de identidade de colaboradores. Por exemplo, usar o Entra em vez do Okta. Não

Mudanças na identidade do usuário

O Gemini Enterprise associa o histórico de conversas, os notebooks e os agentes que o usuário cria ao identificador principal dele. Se você usar a federação de identidade de colaboradores, o identificador principal vai incluir o valor que o mapeamento de atributos atribui a google.subject. Exemplo:

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

Impacto de uma mudança no valor do assunto

Se o valor mapeado para google.subject mudar para um usuário, o Gemini Enterprise vai tratar o usuário como um novo usuário. Por exemplo, isso acontece quando o nome principal do usuário (UPN) ou o endereço de e-mail do usuário muda no Microsoft Entra ID e o mapeamento de atributos usa esse atributo. Os identificadores de principal diferenciam maiúsculas de minúsculas, então uma mudança na formatação também é uma mudança.

Após a mudança, o seguinte se aplica:

  • O usuário não pode acessar o histórico de conversas, os notebooks ou os agentes associados ao identificador principal anterior.
  • O Gemini Enterprise não migra dados do identificador principal anterior para o novo.
  • As licenças e os papéis do IAM concedidos ao identificador principal anterior não se aplicam ao novo identificador principal.

Preparar-se para uma mudança no valor do assunto

Para reduzir o impacto de uma mudança no valor do assunto, faça o seguinte:

  • Antes de mudar o UPN ou o endereço de e-mail de um usuário no seu provedor de identidade, informe o usuário e peça que ele compartilhe os agentes particulares ou notebooks que ele quer manter.
  • Atribua uma licença do Gemini Enterprise ao novo identificador de principal e conceda os papéis necessários a ele. Para mais informações, consulte Conceder permissões aos usuários.
  • Transfira a propriedade dos agentes que o usuário compartilhou com outras pessoas para o novo identificador principal. Não é possível transferir a propriedade de agentes que não são compartilhados.

Resolver erros de autenticação

Se os usuários receberem erros de HTTP 401 que informam credenciais de autenticação inválidas ao acessar o Gemini Enterprise, verifique o seguinte.

Verificações básicas

  • Estado do navegador: peça ao usuário para limpar o cache e os cookies do navegador ou fazer login em uma janela de navegação anônima ou privada.
  • Conta conectada: verifique se o usuário fez login com a conta que a configuração do provedor de identidade espera. Se você usar a federação de identidade de colaboradores, a identidade do usuário precisará corresponder ao mapeamento de atributos.
  • Relógio do dispositivo: verifique se o relógio do dispositivo está sincronizado, por exemplo, usando o Network Time Protocol (NTP). O desvio de relógio no dispositivo pode fazer com que a autenticação falhe.

Políticas de rede e de provedor de identidade

  • Proxies e firewalls: proxies, firewalls ou gateways da Web seguros que inspecionam o tráfego TLS podem remover ou alterar o cabeçalho Authorization. Verifique se esses dispositivos não modificam as solicitações para domínios do Google.
  • Políticas de acesso do provedor de identidade: verifique se as políticas de acesso no seu provedor de identidade, como as políticas de acesso condicional no Microsoft Entra ID, bloqueiam o login devido à conformidade do dispositivo, intervalos de endereços IP ou localização.
  • Acesso baseado no contexto: se a organização usa o acesso baseado no contexto com o Google Cloud ou o Google Workspace, verifique se um nível de acesso baseado em IP bloqueia as solicitações que o Gemini Enterprise faz em nome do usuário. Essas solicitações são originadas dos servidores do Google, não da rede do usuário. Portanto, elas não correspondem aos intervalos de IP corporativos. Adicione um nível de acesso que permita o ID do cliente OAuth 2.0 usado pelo Gemini Enterprise, combinado com o nível de acesso baseado em IP como uma condição OR. As solicitações negadas aparecem nos registros de auditoria da sua organização para contextawareaccess.googleapis.com.
  • Resolução de DNS: verifique se os resolvedores de DNS resolvem corretamente os domínios do Google, incluindo *.google.com e *.googleapis.com.

Coletar informações de diagnóstico

Se o erro persistir, capture um arquivo HAR (HTTP Archive) e os registros do console do navegador enquanto reproduz o erro e entre em contato com o Cloud Customer Care. Os arquivos HAR podem conter informações sensíveis, como cookies e tokens.

A seguir