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 a Google Identity ao se conectar a fontes de dados do Google Workspace.
  • Todas as fontes de dados de terceiros que usam federação de dados, em que os usuários fazem a autenticação diretamente com o serviço de terceiros usando o OAuth.
  • Todas as fontes de dados de terceiros que usam a ingestão de dados, exceto as 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 usado pela sua organização, 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 Microsoft Entra ID, Okta ou AD FS, é possível usar a Google Identity ou a federação de identidade de colaboradores. O Google recomenda usar o Google Identity para novas configurações. Os clientes atuais que já usam a federação de identidade de colaboradores podem continuar usando esse recurso. 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 usados pela sua organização 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 empresariais e a pesquisa com conectores do Google Workspace (como Pessoas do Google Workspace ou Grupos do Google), o Gemini Enterprise respeita rigorosamente 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 ver e fundamentar respostas com base 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 extras.

  • Pessoas do Google Workspace (diretório): a visibilidade do usuário nos resultados da pesquisa e 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 acessar os perfis de funcionários em departamentos restritos.

  • Grupos do Google:a descoberta e o embasamento de conteúdo obedecem às configurações de acesso e associação a grupos. Um usuário só pode pesquisar e acessar conteúdo dos Grupos do Google de que faz parte e tem permissão para acessar. Quem não é membro não pode descobrir nem acessar discussões de grupos particulares pelo Gemini Enterprise.

Onde gerenciar permissões

Não é necessário configurar o controle de acesso e as configurações de visibilidade no conector do Gemini Enterprise no console Google Cloud . Em vez disso, um administrador do Google Workspace configura as permissões, a associação e as configurações de 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 participação em grupos:o administrador do Google Workspace configura o acesso e a participação em grupos 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 compatível no 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 no local que você quer atualizar.

  4. Clique em Adicionar provedor de identidade e selecione o tipo de provedor.
    Se você selecionar Identidade de terceiros, também será necessário escolher o pool de colaboradores 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 chat, os notebooks e os agentes criados por um usuário ao identificador principal dele. Se você usa a federação de identidade de colaboradores, o identificador principal inclui o valor que seu 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 de 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 principais diferenciam maiúsculas de minúsculas. Portanto, uma mudança na caixa das letras 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 chat, 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.

Preparar 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 provedor de identidade, informe o usuário e peça para ele compartilhar os agentes particulares ou notebooks que ele quer manter.
  • Atribua uma licença do Gemini Enterprise ao novo identificador principal e conceda a ele as funções necessárias. 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 problemas de 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 para o usuário limpar o processo de cache do navegador e os cookies, ou fazer login em uma janela de navegação anônima ou privada.
  • Conta conectada: confira se o usuário fez login com a conta esperada pela configuração do provedor de identidade. Se você usa a federação de identidade de colaboradores, a identidade do usuário precisa 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 causar falha na autenticação.

Políticas de rede e provedor de identidade

  • Proxies e firewalls: proxies, firewalls ou gateways da Web seguros que inspecionam o tráfego TLS podem remover ou mudar o cabeçalho Authorization. Verifique se esses dispositivos não modificam 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 sua organização usa o Acesso Baseado no Contexto com 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, 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 você reproduz o erro. Em seguida, entre em contato com o Cloud Customer Care. Os arquivos HAR podem conter informações sensíveis, como cookies e tokens.

A seguir