La proliferación de herramientas empresariales independientes—como Microsoft 365, Google Workspace, Slack, Jira, Confluence, Salesforce y aplicaciones internas personalizadas—plantea un dilema crítico de seguridad para los administradores de TI. Si bien los empleados necesitan una búsqueda unificada en el espacio de trabajo y un asistente de IA generativa para localizar el contexto empresarial, las organizaciones no pueden tolerar fugas de datos confidenciales. Las hojas de cálculo de compensación ejecutiva, los mapas de ruta de productos no anunciados y los tickets confidenciales de recursos humanos jamás deben quedar expuestos a usuarios no autorizados.
Glean resuelve este desafío mediante una arquitectura consciente de la seguridad basada en tres pilares: reflejo de permisos (Permission Mirroring), unión de identidades (Identity Stitching) y verificación de acceso en tiempo de consulta (Query-Time Access Enforcement). En lugar de obligar al equipo de TI a recrear y mantener un modelo de permisos paralelo, Glean ingiere y aplica directamente las listas de control de acceso (ACL) nativas de cada herramienta de origen.
Esta guía técnica explica paso a paso cómo los administradores de TI pueden desplegar conectores, configurar la federación de identidades, alinear alias de usuario y validar los límites de permisos para habilitar una búsqueda corporativa segura.
Fundamentos arquitectónicos: Cómo garantiza Glean la seguridad en la búsqueda unificada
Antes de conectar las aplicaciones, los administradores de TI deben comprender los tres mecanismos principales de gobernanza de Glean:
1. Reflejo de permisos (Permission Mirroring)
Glean no utiliza un esquema de permisos sintético o independiente. Al indexar los datos, los conectores nativos extraen simultáneamente las reglas de acceso de los sistemas de origen. Si un archivo de SharePoint hereda permisos de una carpeta específica, un espacio de Confluence está restringido a un grupo concreto o un registro de Salesforce posee reglas de uso compartido complejas, Glean replica estas ACL directamente en su gráfico de conocimiento empresarial (Enterprise Knowledge Graph).
2. Unión de identidades entre sistemas dispares (Identity Stitching)
Los empleados rara vez tienen el mismo identificador de cuenta en todas las herramientas de la empresa. Un usuario puede autenticarse en Okta con jane.doe@enterprise.com, aparecer en Jira como jdoe, registrar código en GitHub con un nombre de usuario personal y conservar una dirección de correo de un dominio heredado tras una adquisición. Glean analiza los atributos del directorio del proveedor de identidades (IdP) principal para unificar estas cuentas dispersas en un único registro de persona (Person Record).
3. Verificación de acceso en tiempo de consulta y a nivel de pasaje
Cuando un empleado realiza una búsqueda o formula una pregunta en Glean Assistant, Glean valida su identidad en tiempo real:
- Filtrado de resultados de búsqueda: Los documentos a los que el usuario no tiene acceso en la aplicación de origen se excluyen por completo. No aparecen en la lista de resultados, en las vistas previas ni en las sugerencias.
- Respuestas de IA generativa (RAG): Glean Assistant genera respuestas mediante generación aumentada por recuperación (RAG) utilizando exclusivamente el material que el empleado tiene permiso explícito para leer. Si un empleado consulta proyecciones financieras, la IA no utilizará informes ejecutivos confidenciales para elaborar la respuesta.
- Aislamiento a nivel de pasaje: En formatos de datos que admiten permisos granulares, Glean puede restringir secciones o campos específicos dentro de un documento ampliamente compartido, evitando que fragmentos confidenciales queden expuestos.
Fase 1: Integración del Proveedor de Identidades (IdP) y Delegación de Roles
El primer paso consiste en establecer la infraestructura de identidad. Glean requiere la activación obligatoria de inicio de sesión único (SSO) y sincroniza los directorios de usuarios mediante rastreos automáticos de datos de personas (People Data Crawl).
Configuración de SSO e IdP
El inicio de sesión único es un requisito indispensable en todas las implementaciones de Glean. La configuración se realiza en Admin Console > Users & permissions > Authentication:
- Protocolos disponibles: Admite OpenID Connect (OIDC) y SAML 2.0. Glean recomienda OIDC debido a su precisión en la gestión de permisos y su sincronización de atributos de directorio.
- Proveedores compatibles: Ofrece integraciones nativas con Microsoft Entra ID (antes Azure AD), Okta y Google Workspace.
Jerarquía de roles de administrador y principio de mínimo privilegio
Glean implementa tres roles administrativos para limitar el alcance de acceso:
| Rol | Alcance de responsabilidades | Asignación típica |
|---|---|---|
| Setup Admin (Administrador de configuración) | Conecta y administra conectores, inicia rastreos, gestiona ajustes de SSO, genera tokens para la Indexing API y configura extensiones de navegador. | Responsables técnicos de aplicaciones SaaS (administradores de SharePoint o Jira) que solo requieren integrar sus herramientas sin acceso global. |
| Admin (Administrador) | Acceso completo de lectura y escritura a la consola, asignación de roles de usuario, personalización de la interfaz y emisión de tokens de API (excepto alcance global). | Ingenieros de sistemas y administradores centrales de TI. |
| Super Admin (Superadministrador) | Todas las facultades de Admin, más acceso a la búsqueda de datos confidenciales (Admin Search), informes de auditoría DLP, registros de hallazgos sensibles y políticas de seguridad de IA. | Directores de seguridad de la información (CISO), directores de TI o responsables de cumplimiento normativo. |
Estos roles pueden asignarse a cuentas individuales o sincronizarse dinámicamente mediante Permisos basados en grupos (Group-based permissions), vinculando grupos de seguridad del IdP (por ejemplo, Entra-IT-Admins) para que los privilegios se asignen y revoquen de forma automatizada.
Fase 2: Alias de usuario y unión de identidades
Para que la búsqueda unificada funcione con precisión, Glean debe asociar los documentos generados o compartidos por jdoe en una herramienta con la identidad del empleado en el IdP principal.
Extracción de atributos de directorio y alias
Durante los rastreos de directorio, Glean toma el correo principal para crear el registro de persona y almacena los identificadores secundarios como alias.
Asignación de atributos en Microsoft Entra ID
userPrincipalName: Se utiliza como correo principal predeterminado. (Se puede cambiar al campomailsolicitando a soporte la configuraciónazure.useMailAsPrimaryEmailField=true).mail: Se rastrea como alias de forma predeterminada.proxyAddresses: Se rastrea como alias de forma predeterminada. Fuente recomendada: En Entra ID, este atributo está bajo el control exclusivo de los administradores de TI, siendo la vía más segura para registrar direcciones de dominios múltiples y correos alternativos.otherMails: Desactivado por defecto (requiereazure.crawlOtherMailsForAlias=true).
Asignación de atributos en Okta
email: Se utiliza como correo principal.login: Se rastrea como alias de forma predeterminada.proxyAddresses: Si proviene de Active Directory o de un atributo personalizado administrado, se rastrea como alias de forma predeterminada.secondEmail: Desactivado por defecto.
Advertencia crítica de seguridad: Riesgo en atributos editables por el usuario
[!WARNING] Atributos como
otherMailsen Entra ID ysecondEmailen Okta son editables por los propios empleados en las configuraciones predeterminadas de muchos inquilinos. Si Glean tratara estos campos como alias de confianza, un usuario podría introducir la dirección de correo de un colega o directivo en su perfil y obtener acceso no autorizado a los documentos confidenciales compartidos con esa persona.Mantenga estos campos desactivados a menos que su organización haya bloqueado estrictamente la edición por parte de los usuarios finales en el IdP. Utilice siempre atributos controlados por TI como
proxyAddresses.
Buenas prácticas en fusiones, adquisiciones y dominios múltiples
- Mantenga las direcciones de correo secundarias en el atributo
proxyAddressesdel IdP principal. - Asegúrese de que esta regla se aplique a todos los usuarios nuevos y no solo a los lotes migrados originalmente.
- Si el IdP de origen no admite nuevos atributos, utilice la función de carga manual de alias por archivo CSV disponible en la consola de Glean.
Fase 3: Configuración de conectores de fuentes de datos
El catálogo de integraciones de Glean abarca distintas modalidades:
- Native Connectors (Conectores nativos): Diseñados para más de 100 aplicaciones SaaS (Google Drive, SharePoint, Slack, Jira, Confluence, Salesforce, GitHub, ServiceNow, etc.), extrayendo contenido, metadatos y ACL mediante APIs estándar.
- Push API Connectors (Conectores de API push): Basados en la Glean Indexing API para conectar herramientas propietarias o bases de datos locales ubicadas tras cortafuegos corporativos.
- Partner Connectors (Conectores de socios): Desarrollados y mantenidos por fabricantes asociados sobre la plataforma de Glean.
- Web History Connectors (Conectores de historial web): Permiten que la extensión de navegador registre visitas a herramientas web sin API abierta, manteniendo los resultados totalmente privados para el propio usuario.
Flujo de trabajo para configurar un conector
[1. Seleccionar la aplicación en el hub]
│
▼
[2. Revisar requisitos y alcances de API]
│
▼
[3. Configurar credenciales y autenticación]
│
▼
[4. Establecer exclusiones en "Manage Data"]
│
▼
[5. Ejecutar rastreo inicial e indexación]
│
▼
[6. Validar permisos con un grupo de prueba]
Paso 1: Seleccionar la aplicación en Connectors Hub
Acceda a Admin Console > Connectors > Connectors hub y seleccione la herramienta a integrar (por ejemplo, Confluence Cloud o SharePoint).
Paso 2: Verificar credenciales y permisos en la herramienta de origen
Revise los requisitos previos:
- Cuentas de servicio y roles de origen: Al conectar ServiceNow, el administrador debe elevarse al rol
security_adminy otorgar permisos ACL de lectura en las tablas correspondientes; en Microsoft 365, se requiere el consentimiento del administrador del inquilino. - Alcances de API bajo el principio de mínimo privilegio: Utilice permisos exclusivamente de lectura (por ejemplo,
Sites.Read.AllyFiles.Read.Allen Microsoft Graph). Glean nunca requiere permisos de escritura para indexar contenido de búsqueda.
Paso 3: Configurar autenticación y guardar el conector
Haga clic en Add connector, ingrese el dominio del servicio, suministre las credenciales OAuth o tokens de servicio y guarde la configuración.
Paso 4: Ajustar el alcance en la pestaña "Manage Data"
Muchos conectores nativos ofrecen la pestaña Manage data:
- Reglas de inclusión y exclusión: Excluya repositorios confidenciales o irrelevantes (sitios de SharePoint de la dirección ejecutiva, canales de Slack de asuntos legales confidenciales o proyectos archivados de Jira).
- Modos de acceso: Elija entre Indexed (Indexado) para almacenar el contenido de forma anticipada y garantizar tiempos de respuesta mínimos, o Live / Hybrid (En vivo o Híbrido) para consultar datos que cambian con mucha frecuencia.
Fase 4: Rastreo inicial, indexación y verificación de acceso
Tras guardar la configuración, el conector inicia el proceso de sincronización.
Las dos etapas de la sincronización inicial
- Fase de rastreo (Crawling): Los procesos de Glean llaman a las APIs de origen para recopilar el texto de los documentos, metadatos (autor, fecha de modificación) y las listas ACL (permisos individuales, grupos, vínculos compartidos).
- Fase de indexación (Indexing): Glean analiza el texto, genera representaciones vectoriales, conecta las relaciones de entidades, vincula las cuentas de origen con el People Graph y almacena los datos en el gráfico de conocimiento.
El tiempo necesario varía según el volumen de datos y los límites de frecuencia de las APIs. El avance puede supervisarse en Admin Console > Connectors > Manage connectors.
Validación de permisos en un grupo piloto (Paso indispensable)
Antes de habilitar la búsqueda para toda la empresa, realice las siguientes comprobaciones:
- Restringir la visibilidad al grupo de prueba: En la configuración del conector, limite el acceso al equipo de TI o a un departamento piloto.
- Pruebas de búsqueda positiva: Inicie sesión con cuentas de prueba autorizadas y verifique que pueden encontrar los archivos a los que tienen acceso legítimo en Google Drive, SharePoint o Confluence.
- Pruebas de búsqueda negativa (Crucial): Busque documentos confidenciales restringidos (como tablas salariales o actas de juntas directivas) desde una cuenta no autorizada. Confirme que no se devuelven resultados y que Glean Assistant no cita ni alude a dicha información.
- Verificación de herramientas de IA: Si se han habilitado herramientas en vivo para Glean Assistant (por ejemplo, creación de tickets o servidores MCP), compruebe que se ejecutan bajo la identidad delegada del usuario y que las acciones bloqueadas por el administrador no pueden invocarse.
Fase 5: Gobernanza continua, alertas y control de agentes de IA
El mantenimiento de la plataforma requiere un monitoreo continuo:
Actualizaciones incrementales y Webhooks
Tras el rastreo inicial, Glean utiliza webhooks y rastreos incrementales periódicos para detectar adiciones y cambios de permisos. En la mayoría de los conectores SaaS nativos, las modificaciones de ACL en la herramienta de origen se reflejan en Glean en cuestión de minutos.
Supervisión de alertas y registros de auditoría
Los administradores deben revisar periódicamente el Notifications dashboard y las Admin Alerts para resolver posibles vencimientos de tokens OAuth o bloqueos por límite de peticiones de API. Todas las acciones administrativas se registran en los Audit Logs de forma inmutable.
Gobernanza de servidores MCP y agentes de IA
Al implementar agentes autónomos y servidores basados en Model Context Protocol (MCP):
- Glean garantiza que los agentes nunca sobrepasen los privilegios del usuario que realiza la consulta.
- Los administradores pueden gestionar qué herramientas están permitidas desde Admin Console > Tools, exigiendo aprobación explícita (Needs approval) para operaciones de escritura crítica.
Lista de verificación de mejores prácticas para administradores de TI
- Asegurar los atributos de identidad: Compruebe que los alias provengan de campos administrados como
proxyAddressesy que los campos editables por los usuarios estén desactivados. - Implementar RBAC basado en grupos: Vincule los roles de Setup Admin y Admin a grupos de seguridad del IdP en lugar de asignar cuentas de forma manual.
- Definir exclusiones antes del rastreo: Configure las exclusiones en Manage data antes de iniciar la primera sincronización para evitar indexar material confidencial innecesario.
- Ejecutar pruebas negativas rigurosas: Valide que el contenido restringido sea completamente invisible para los usuarios no autorizados tanto en la búsqueda como en las respuestas de IA.
- Monitorear la salud de los conectores: Supervise los paneles de control de sincronización para prevenir interrupciones derivadas del vencimiento de credenciales de API.
Al articular una gestión estricta de identidades, una asignación prudente de roles y el mecanismo de reflejo de permisos de Glean, los equipos de TI pueden derribar los silos de información internos mientras preservan los más altos estándares de seguridad corporativa.