A fragmentação de ferramentas de trabalho em uma empresa—como Microsoft 365, Google Workspace, Slack, Jira, Confluence, Salesforce e repositórios internos desenvolvidos sob medida—cria um dilema fundamental de segurança para as equipes de TI. Embora os colaboradores necessitem de uma busca unificada e de assistentes de IA generativa para localizar rapidamente informações de projetos e decisões anteriores, as organizações não podem arriscar o vazamento de dados confidenciais. Planilhas de remuneração de executivos, roadmaps de produtos ainda não anunciados e chamados confidenciais de RH jamais devem ser expostos a colaboradores sem autorização prévia.
O Glean soluciona esse impasse por meio de uma arquitetura consciente de permissões alicerçada em três pilares: espelhamento de permissões (Permission Mirroring), unificação de identidades (Identity Stitching) e imposição de acesso em tempo de consulta (Query-Time Access Enforcement). Em vez de exigir que a equipe de TI recrie um modelo de controle de acesso paralelo, o Glean extrai e aplica diretamente as Listas de Controle de Acesso (ACLs) nativas de cada ferramenta de origem.
Este guia técnico orienta os administradores de TI corporativos em todas as etapas de implantação de conectores, configuração de federação de identidades, alinhamento de aliases de usuário e validação de limites de permissão.
Fundamentos de Arquitetura: Como o Glean Garante a Segurança
Antes de conectar as aplicações corporativas, é imprescindível entender os três mecanismos fundamentais que regem a governança de dados no Glean:
1. Espelhamento de Permissões (Permission Mirroring)
O Glean não opera com uma camada de permissões artificial ou desvinculada. Quando os conectores nativos indexam o conteúdo, eles capturam simultaneamente as regras de segurança do sistema original. Seja uma pasta aninhada com herança restrita no SharePoint, um espaço restrito a determinados grupos no Confluence ou regras personalizadas de compartilhamento no Salesforce, o Glean reflete essas ACLs diretamente em seu Grafo de Conhecimento Corporativo (Enterprise Knowledge Graph).
2. Unificação de Identidades entre Múltiplas Ferramentas (Identity Stitching)
Os colaboradores raramente mantêm os mesmos identificadores em todas as ferramentas da empresa. Um usuário pode autenticar-se no Okta como jane.doe@enterprise.com, ser reconhecido no Jira como jdoe, registrar commits no GitHub com um nome de usuário pessoal e manter um e-mail de um domínio legado após uma fusão ou aquisição. O Glean rastreia os atributos de diretório do Provedor de Identidade (IdP) principal e consolida essas contas dispersas em um único registro de pessoa (Person Record).
3. Imposição de Acesso em Tempo de Consulta e em Nível de Trecho
Sempre que um usuário realiza uma pesquisa ou faz uma pergunta ao Glean Assistant, o Glean valida sua identidade e autorizações em tempo real:
- Filtro em Resultados de Busca: Documentos que o usuário não tem permissão para visualizar na ferramenta de origem são completamente removidos dos resultados, das pré-visualizações e das recomendações de links.
- Respostas com IA Generativa (RAG): O Glean Assistant formula respostas via Geração Aumentada por Recuperação (RAG) exclusivamente a partir de conteúdos que o usuário que fez a pergunta tem direito de ler. Se um colaborador consultar previsões orçamentárias, a IA não utilizará arquivos confidenciais da diretoria para elaborar a resposta.
- Isolamento em Nível de Trecho (Passage-Level): Em dados que oferecem suporte a controles granulares, o Glean restringe o acesso a seções específicas dentro de um documento mais amplo, impedindo a visualização indevida de trechos sigilosos em arquivos amplamente compartilhados.
Fase 1: Integração com Provedor de Identidade (IdP) e Delegação de Funções
O primeiro marco de implantação é consolidar a infraestrutura de autenticação. O Glean exige o uso de Logon Único (SSO) e sincroniza a hierarquia organizacional por meio de coletas automáticas de dados de pessoas (People Data Crawl).
Configuração de SSO e IdP
O SSO é obrigatório em todas as instâncias do Glean. Os administradores realizam a configuração em Admin Console > Users & permissions > Authentication:
- Protocolos Suportados: Suporte a OpenID Connect (OIDC) e SAML 2.0. O OIDC é fortemente recomendado pela equipe do Glean por sua precisão na gestão de atributos e sincronização dinâmica de diretório.
- Provedores Homologados: Integrações nativas disponíveis para Microsoft Entra ID (antigo Azure AD), Okta e Google Workspace.
Hierarquia de Funções Administrativas e Menor Privilégio
O Glean estabelece três funções administrativas estruturadas segundo o princípio do menor privilégio:
| Função | Atribuições Principais | Perfil de Usuário Típico |
|---|---|---|
| Setup Admin (Administrador de Configuração) | Conecta e gerencia conectores, inicia varreduras, configura parâmetros de SSO, gera tokens para a Indexing API e gerencia integrações de extensão de navegador. | Responsáveis por aplicações SaaS específicas (como o administrador do SharePoint ou do Jira), sem necessidade de acesso amplo ao restante da plataforma. |
| Admin (Administrador) | Acesso total de leitura e escrita ao console, atribuição de funções a usuários, personalização da interface e geração de tokens de API (exceto de escopo global). | Engenheiros de sistemas e administradores centrais de TI. |
| Super Admin (Superadministrador) | Todas as permissões de Admin, além de busca em dados confidenciais (Admin Search), relatórios de auditoria DLP, registros de descobertas críticas e políticas de segurança de IA. | Diretores de Segurança da Informação (CISO), diretores de TI ou líderes de conformidade. |
Essas funções podem ser atribuídas individualmente ou sincronizadas dinamicamente por meio de Permissões baseadas em grupos (Group-based permissions), conectando grupos de segurança do IdP (como Entra-IT-Admins) para que os privilégios sejam concedidos ou revogados automaticamente.
Fase 2: Aliases de Usuário e Unificação de Identidades
Para que a busca unificada funcione com exatidão, o Glean precisa associar os documentos criados ou visualizados por jdoe ao perfil correto do colaborador no IdP principal.
Coleta de Diretório e Atributos de Aliases
Durante as varreduras de dados de pessoas, o Glean utiliza o e-mail principal para criar a ficha do usuário e mapeia os demais identificadores como aliases.
Mapeamento de Atributos no Microsoft Entra ID
userPrincipalName: Coletado como e-mail principal padrão. (Pode ser alterado para o atributomailsolicitando ao suporte do Glean a ativação deazure.useMailAsPrimaryEmailField=true).mail: Coletado como alias por padrão.proxyAddresses: Coletado como alias por padrão. Fonte recomendada: No Entra ID, esse campo é estritamente controlado pela TI, sendo o canal mais seguro para registrar e-mails secundários e domínios múltiplos.otherMails: Desativado por padrão (exige a configuraçãoazure.crawlOtherMailsForAlias=true).
Mapeamento de Atributos no Okta
email: Coletado como e-mail principal.login: Coletado como alias por padrão.proxyAddresses: Coletado como alias por padrão quando mapeado via Active Directory ou configurado como atributo personalizado gerenciado.secondEmail: Desativado por padrão.
Alerta Crítico de Segurança: Atributos Editáveis por Usuários
[!WARNING] Em muitos ambientes corporativos, campos como
otherMailsno Entra ID esecondEmailno Okta podem ser editados livremente pelos próprios colaboradores em suas páginas de perfil pessoal. Se o Glean tratasse esses campos como aliases confiáveis sem restrições, um colaborador mal-intencionado poderia inserir o e-mail de um colega ou gestor em seu perfil para unificar indevidamente as contas e herdar o acesso aos documentos confidenciais dessa pessoa.Mantenha esses campos desativados, a menos que sua organização tenha bloqueado de forma estrita a edição por usuários finais no IdP. Utilize sempre atributos protegidos, como
proxyAddresses.
Boas Práticas em Fusões, Aquisições e Múltiplos Domínios
- Centralize os e-mails secundários no atributo
proxyAddressesdo IdP principal. - Certifique-se de que a regra abranja todas as novas contratações, e não apenas o lote de migração inicial.
- Caso o IdP de origem não permita gravação de novos atributos, utilize o recurso de upload manual de arquivo CSV de aliases disponível no Console Administrativo do Glean como plano de contingência.
Fase 3: Configuração dos Conectores de Fontes de Dados
O ecossistema do Glean disponibiliza diferentes modelos de integração:
- Native Connectors (Conectores Nativos): Abrangem mais de 100 serviços SaaS líderes de mercado (Google Drive, SharePoint, Slack, Jira, Confluence, Salesforce, GitHub, ServiceNow etc.), extraindo conteúdo, metadados e regras de ACL via APIs oficiais.
- Push API Connectors (Conectores de API Push): Utilizam a Glean Indexing API para integrar aplicações proprietárias ou bancos de dados internos mantidos em infraestrutura local ou atrás de firewalls.
- Partner Connectors (Conectores de Parceiros): Mantidos por parceiros de tecnologia diretamente na plataforma de desenvolvedores do Glean.
- Web History Connectors (Conectores de Histórico Web): Empregados quando não há APIs públicas disponíveis, registrando o histórico de navegação por meio da extensão do Glean e mantendo esses dados visíveis estritamente para o próprio usuário.
Fluxo de Trabalho de Implantação de um Conector
[1. Selecionar o aplicativo no Hub]
│
▼
[2. Validar pré-requisitos e escopos de API]
│
▼
[3. Inserir credenciais e autenticar]
│
▼
[4. Definir regras em "Manage Data"]
│
▼
[5. Executar varredura inicial e indexação]
│
▼
[6. Validar permissões no grupo de teste]
Passo 1: Localizar a aplicação no Connectors Hub
No console de administração, navegue até Admin Console > Connectors > Connectors hub e selecione o sistema desejado (como Confluence Cloud ou SharePoint).
Passo 2: Validar pré-requisitos e permissões no sistema de origem
Analise o guia específico do conector:
- Contas de Serviço e Acessos: Para integrar o ServiceNow, o administrador deve elevar sua conta temporariamente para
security_admine conceder as ACLs de leitura nas tabelas; para o Microsoft 365, é necessária a aprovação do administrador do inquilino. - Escopos de Menor Privilégio: Utilize credenciais restritas exclusivamente a leitura (por exemplo,
Sites.Read.AlleFiles.Read.Allno Microsoft Graph). O Glean nunca solicita permissões de gravação para a indexação de busca.
Passo 3: Fornecer credenciais e salvar a conexão
Clique em Add connector, insira o domínio do serviço, forneça as credenciais OAuth ou tokens de serviço e salve a configuração.
Passo 4: Refinar o escopo na aba "Manage Data"
Muitos conectores nativos disponibilizam a aba Manage data:
- Regras de Exclusão: Crie listas de bloqueio para repositórios confidenciais ou irrelevantes (sites da diretoria no SharePoint, canais de assuntos jurídicos restritos no Slack ou projetos arquivados no Jira).
- Modos de Acesso aos Dados: Escolha entre Indexed (Indexado), para indexação prévia com respostas instantâneas, ou Live / Hybrid (Ao vivo ou Híbrido), para dados que mudam em tempo real.
Fase 4: Varredura Inicial, Indexação e Validação de Permissões
Após salvar as configurações, o conector inicia o ciclo de sincronização primária.
As Duas Etapas da Sincronização
- Fase de Varredura (Crawling): Os coletores do Glean consultam as APIs de origem para extrair texto, metadados (autor, datas de alteração) e a malha de permissões (ACLs de usuários, grupos vinculados e links de compartilhamento).
- Fase de Indexação (Indexing): O Glean processa o texto, gera embeddings semânticos, resolve relações entre entidades, alinha contas de origem com o People Graph e incorpora os dados ao Grafo de Conhecimento.
A duração depende do volume total de dados e das taxas de limitação (rate limits) das APIs de origem. O progresso pode ser acompanhado em tempo real em Admin Console > Connectors > Manage connectors.
Validação em Grupo de Teste (Etapa Crítica de Homologação)
Antes da liberação ampla para toda a empresa, a equipe de TI deve realizar testes rigorosos:
- Restringir Visibilidade a um Grupo Piloto: Nas configurações do conector, restrinja o acesso a um grupo de testes interno de TI.
- Testes de Busca Positivos: Faça login com contas de teste autorizadas e certifique-se de que os usuários conseguem localizar os arquivos aos quais têm direito de acesso no Google Drive, SharePoint ou Confluence.
- Testes de Busca Negativos (Essencial): Pesquise por termos ou títulos sabidamente confidenciais (planilhas de salários ou atas de diretoria) utilizando uma conta não autorizada. Verifique se o resultado retornado é nulo e se o Glean Assistant não cita ou menciona qualquer trecho desses conteúdos.
- Verificação de Ferramentas de IA: Se ferramentas ativas de execução (como criação de chamados ou servidores MCP) tiverem sido habilitadas para o assistente, confirme que as ações ocorrem sob a identidade delegada do usuário solicitante e que ferramentas bloqueadas pelo administrador não podem ser disparadas.
Fase 5: Governança Contínua, Monitoramento e Controle de Agentes de IA
A sustentabilidade de uma busca unificada robusta requer supervisão periódica:
Atualizações Incrementais e Webhooks
Após a varredura inicial completa, o Glean monitora adições e exclusões por meio de webhooks e varreduras incrementais frequentes. Na maioria dos conectores SaaS nativos, alterações em ACLs efetuadas na ferramenta original são refletidas no Glean em questão de minutos.
Monitoramento de Alertas e Logs de Auditoria
A equipe de TI deve acompanhar o Notifications dashboard e os Admin Alerts para identificar e corrigir problemas como tokens expirados ou bloqueios por excesso de requisições de API. Todas as ações administrativas (alterações em conectores, concessão de funções e exclusões) são registradas de forma imutável nos Audit Logs.
Governança do Model Context Protocol (MCP) e Agentes Autônomos
À medida que a organização adota servidores MCP e agentes inteligentes:
- O Glean garante que os agentes nunca ultrapassem os privilégios do usuário que acionou o comando.
- Os administradores podem autorizar ou bloquear ferramentas em Admin Console > Tools, exigindo confirmação explícita do usuário (Needs approval) para ações de escrita, prevenindo alterações indevidas em ferramentas downstream.
Lista de Verificação de Melhores Práticas para TI
- Blindar Atributos de Identidade: Audite o Entra ID e o Okta para garantir que aliases sejam derivados exclusivamente de atributos controlados pela TI, como
proxyAddresses, mantendo campos editáveis por usuários desativados. - Adotar RBAC Baseado em Grupos: Vincule as funções administrativas de Setup Admin e Admin a grupos de segurança do IdP, evitando atribuições manuais soltas.
- Definir Exclusões Antecipadamente: Utilize a aba Manage data para excluir diretórios confidenciais ou arquivados antes de disparar a primeira varredura completa.
- Executar Testes Negativos Rigorosos: Comprove na prática que materiais sigilosos ficam completamente invisíveis para contas sem autorização, tanto na busca quanto nas respostas de IA.
- Acompanhar a Saúde das Conexões: Monitore relatórios periódicos de sincronização para prevenir a interrupção da busca por vencimento de tokens ou credenciais de serviço.
Ao combinar uma arquitetura sólida de identidades, papéis administrativos bem delimitados e o espelhamento contínuo de permissões do Glean, a equipe de TI entrega uma busca unificada de alto impacto, garantindo segurança corporativa e conformidade irrestrita.