企业内部工具分散在不同孤岛中——Microsoft 365、Google Workspace、Slack、Jira、Confluence、Salesforce 以及内部自研系统，这给 IT 管理团队带来了严峻的安全与效率博弈。一方面，员工急需跨软件的统一工作区搜索与生成式 AI 助手来检索分散的项目信息与业务知识；另一方面，企业绝不能允许越权访问导致敏感数据泄露。高管薪酬表、未公开的产品规划、法务合规文件或 HR 敏感工单，绝不能被无权限员工检索到。
Glean 解决这一难题的核心架构在于权限镜像（Permission Mirroring）、身份拼接（Identity Stitching）与查询时访问校验（Query-Time Access Enforcement）。IT 管理员无需在 Glean 内重新维护一套孤立的权限系统，Glean 会直接抓取并严格继承各原始系统的访问控制列表（ACL）。
本文为企业 IT 管理员提供一份完整的端到端实操指南，详解数据源连接器部署、身份认证联邦、用户别名对齐与权限边界验证的具体配置路径。
核心架构：Glean 如何在统一搜索中实施安全隔离
在配置连接器前，IT 管理员需要理清 Glean 维护企业数据治理的三大基础支柱：
1. 权限镜像（Permission Mirroring）
Glean 不脱离源系统自建权限体系。原生连接器在抓取数据时，会完整提取源系统的内容与对应权限。无论 SharePoint 文档是否继承上层文件夹权限、Confluence 空间是否限定指定用户组、还是 Salesforce 记录具有特殊的共享规则，Glean 都会将这些 ACL 规则同步至其企业知识图谱（Enterprise Knowledge Graph）中。
2. 跨工具身份拼接（Identity Stitching）
员工在不同系统中的账号命名往往并不统一。例如在 Okta 中主邮箱为 jane.doe@enterprise.com，在 Jira 中可能为 jdoe，在 GitHub 中使用个人昵称，而经历企业并购后还可能保有旧域名的邮箱地址。Glean 通过对主身份提供商（IdP）的人员目录进行爬取，将分散在各连接器中的从属账号自动“缝合”至同一个人员主体（Person Record）。
3. 查询时与段落级权限校验（Query-Time & Passage-Level Enforcement）
当员工在工作区搜索框输入关键词，或向 Glean Assistant 提问时，Glean 会在查询执行时实时校验用户权限：
- 搜索结果过滤： 用户在原始系统中无权查看的文档，会在搜索结果、预览与推荐列表中被物理剔除，无权用户无法感知这些文档的存在。
- 生成式 AI 上下文检索（RAG）： Glean Assistant 基于检索增强生成生成答案时，只使用提问员工拥有阅读权限的文档进行事实基准化。如果普通员工询问公司财报预测，AI 绝不会基于受限的高管文件夹内容合成回复。
- 段落级细粒度控制： 对于支持按块或按字段限制的数据类型，Glean 能够执行段落级隔离，防止包含机密信息的局部内容在广泛共享的文档中泄露。
第一阶段：配置身份提供商（IdP）与管理角色分权
部署的第一步是打通企业主身份认证基础设施。Glean 要求必须启用单点登录（SSO），并通过自动的人员数据爬取（People Data Crawl）同步组织架构。
配置 SSO 与身份提供商
在 Glean 中，SSO 是必选配置项。管理员需前往 Admin Console > Users & permissions > Authentication 进行设置：
- 协议选择： 支持 OpenID Connect（OIDC）与 SAML 2.0。Glean 官方强烈推荐使用 OIDC，因其对细粒度权限控制与目录属性同步具有更完善的支持。
- 支持的主流 IdP： 支持 Microsoft Entra ID（原 Azure AD）、Okta 以及 Google Workspace 的原生集成。
管理员角色层级与最小特权原则
Glean 提供三种管理员角色以实现权限最小化：
| 角色 | 核心权限范围 | 典型适用人员 |
|---|---|---|
| Setup Admin（配置管理员） | 配置与管理连接器、触发内容爬取、管理 SSO 设置、生成 Indexing API 令牌、管理浏览器插件集成。 | 各 SaaS 系统管理员（如 SharePoint 管理员、Jira 管理员），仅负责本系统的接入，无需全局管理权。 |
| Admin（系统管理员） | 控制台全局读写、分配用户角色、配置工作区外观及主页、生成除全局作用域外的 API 令牌。 | 企业中心 IT 工程师与系统管理员。 |
| Super Admin（超级管理员） | 拥有 Admin 的全部权限，额外独享敏感数据搜索（Admin Search）、DLP 审计报表、敏感发现日志以及 AI 安全治理策略。 | 首席信息安全官（CISO）、IT 总监或合规主管。 |
管理员除了手动给账号授权外，还可以启用 基于组的权限映射（Group-based permissions），直接将 IdP 中的安全组（如 Entra-IT-Admins）映射至对应的 Glean 管理角色，实现角色随目录变动自动继承与回收。
第二阶段：配置用户别名（Aliases）与身份拼接
为了让跨工具的统一搜索生效，Glean 必须准确识别某篇由 jdoe 撰写或分享的文档，对应主 IdP 中的哪位员工。
目录爬取与别名提取规则
在身份爬取期间，Glean 提取 IdP 目录属性，以用户的首选主邮箱创建人员档案，并将其余属性作为别名存入索引。
Microsoft Entra ID 目录映射
userPrincipalName： 默认作为人员主邮箱。（若格式不符合要求，可联系技术支持开启azure.useMailAsPrimaryEmailField=true，切换为使用mail属性作为主邮箱）。mail： 默认作为别名自动爬取。proxyAddresses： 默认作为别名自动爬取。推荐实践： 在 Entra ID 中该属性由 IT 管理员集中控制，是承载跨域多邮箱与历史别名的安全来源。otherMails： 默认关闭。需配置azure.crawlOtherMailsForAlias=true才能作为别名。
Okta 目录映射
email： 默认作为人员主邮箱。login： 默认作为别名自动爬取。proxyAddresses： 从 AD/Entra 导入或通过管理员映射时，默认作为别名爬取，也是推荐的安全别名字段。secondEmail： 默认关闭。
关键安全警示：警惕用户可编辑属性冒领权限
[!WARNING] 在许多企业的 IdP 配置中，Entra ID 的
otherMails或 Okta 的secondEmail允许普通员工在个人资料页面自行修改。如果将这些字段无条件作为 Glean 别名，攻击者或越权员工只需将同事或高管的邮箱填入自己的备用邮箱中，就会在 Glean 中错误拼接身份，从而窃取并继承目标人员的文档访问权限。除非企业已在 IdP 租户端完全锁死普通员工的修改权限，否则切勿开启上述字段的别名同步。企业应始终使用管理员专管的
proxyAddresses维护别名。
并购与多域名场景的身份拼接
在企业并购（M&A）或多域名共存场景下：
- 统一在主 IdP 中将历史域名或从属租户的邮箱维护在员工的
proxyAddresses属性中； - 确保对所有在职员工配置，避免仅给历史迁移批次配置而漏掉新入职员工；
- 若上游 IdP 无法写入自定义属性，可使用 Glean 控制台提供的别名 CSV 手动上传功能作为兜底补全。
第三阶段：配置数据源连接器
Glean 的连接器体系支持多种接入模式：
- Native Connectors（原生连接器）： 涵盖 100+ 主流 SaaS（如 Google Drive、SharePoint、Slack、Jira、Confluence、Salesforce、GitHub、ServiceNow 等），通过标准 API 同时抓取内容与安全 ACL。
- Push API Connectors（推送式 API 连接器）： 基于 Glean Indexing API，专为部署在防火墙内的内网系统、本地自建应用或私有数据库设计，由企业主动推送文档与对应权限。
- Partner Connectors（合作伙伴连接器）： 由第三方厂商基于 Glean 平台维护的集成。
- Web History Connectors（网页历史连接器）： 针对缺乏开放 API 的长尾系统，通过 Glean 浏览器插件抓取员工个人的访问历史，记录仅对该员工本人私有。
连接器实操配置流程
[1. 连接器中心选择应用]
│
▼
[2. 核查前置条件与 API 权限范围]
│
▼
[3. 填写鉴权凭证并保存配置]
│
▼
[4. 在"数据管理"中设定包含与排除规则]
│
▼
[5. 启动全量爬取与索引构建]
│
▼
[6. 在测试组中完成权限正反向验证]
步骤 1：在连接器中心挑选应用
登录 Admin Console > Connectors > Connectors hub，找到需要接入的目标系统（如 Confluence Cloud 或 Microsoft SharePoint）。
步骤 2：准备源系统权限与前置凭证
仔细对照该连接器文档要求的前置准备：
- 服务账号与源端权限： 接入 ServiceNow 需要管理员在源系统提升至
security_admin角色并配置特定读取 ACL；接入 Microsoft 365 需要租户管理员审批。 - 最小特权 API 作用域： 准备具备只读权限的应用凭证（如 Microsoft Graph 的
Sites.Read.All、Files.Read.All）。Glean 的索引爬虫仅需读取权限，严禁赋予不必要的写入范围。
步骤 3：完成身份认证与配置保存
点击 Add connector，填入系统域名、OAuth 凭据或服务令牌（Service Account Token），完成授权并保存。
步骤 4：在“数据管理（Manage Data）”设定过滤范围
多数原生连接器在保存后会提供 Manage data 选项卡：
- 排除规则： 明确排除高敏感度或无关内容（例如高管专属 SharePoint 网站、绝密法律案件 Slack 频道、归档废弃代码库）。
- 数据模式选择： 按需求选择 Indexed（索引模式，预先爬取入库以保证检索低延迟） 或 Live / Hybrid（实时/混合模式，针对变更极频繁或长尾对象于查询时实时调取）。
第四阶段：全量爬取、索引构建与权限验证
配置完成后，连接器将进入初始化同步。
同步双阶段
- Crawling（爬取阶段）： 爬虫调用源系统 API，抓取文档文本、作者、更新时间戳以及关联的 ACL（人员清单、组映射、共享链接范围）。
- Indexing（索引阶段）： Glean 对文本建立向量和关键词索引，解析实体关联，将源端用户 ID 与 People Graph 对齐，并写入统一安全图谱。
初次同步耗时受数据总量与源系统 API 限流速率影响。管理员可在 Admin Console > Connectors > Manage connectors 中实时监控已同步条目数（Items synced）与健康度。
测试组验证（安全上线关键）
在正式向全公司开放前，必须执行权限沙盒验证：
- 限定测试组可见性： 在连接器设置中，将搜索可见性限制为 IT 测试组或特定试点部门。
- 正向检索测试： 切换至不同部门的测试账号，验证员工能否正常检索到其在源系统中有权访问的正常业务文档。
- 反向穿透测试（至关重要）： 使用普通员工测试账号检索受控文档（如高管薪酬明细表、绝密重组通知）。确认搜索列表完全不返回该文档，且 Glean Assistant 在问答中绝对不引用、不泄露受限文件的任何段落。
- 工具调用权限复核： 若连接器启用了供 AI Assistant 或 Agent 调用的实时工具（如工单创建、MCP 服务），需确认操作均以发起用户的委托身份执行，被管理员禁用的工具无法被绕过。
第五阶段：日常治理、增量同步与 AI Agent 管控
上线后的长期健康运行依赖于持续的监控与策略约束：
增量爬取与 Webhook 实时更新
完成首次全量抓取后，Glean 依赖源系统的 Webhook 推送或高频增量爬虫捕获新增、修改与删除事件。大部分 SaaS 原生连接器能在数分钟内完成源系统 ACL 变更的同步，确保权限不会滞后失效。
监控告警与审计日志
管理员应定期查看 Notifications dashboard 与 Admin Alerts，及时处理凭证过期、API 频率超限或爬虫异常中断告警。系统所有的管理员操作（如连接器修改、角色升降、排除规则变动）均会完整记录在不可篡改的 Audit Logs 中。
模型上下文协议（MCP）与 Agent 安全治理
随着企业部署自主智能体与 MCP 服务：
- Glean 保证智能体在调用数据与执行操作时，严格受限于提问员工的自身权限边界。
- 管理员可在 Admin Console > Tools 统一管理各工具的启用状态，锁定需要人工二次确认（Needs approval）的写回操作，杜绝非受控变更。
企业 IT 管理员最佳实践清单
- 锁死身份属性来源： 严格审查 Entra ID 或 Okta 配置，通过管理员专管的
proxyAddresses同步别名，杜绝开启普通员工可修改的备用邮箱字段。 - 推行组基 RBAC： 将 Glean 的 Admin 与 Setup Admin 角色绑定至 IdP 安全组，避免分散的手动指派。
- 爬取前严设排除清单： 在初次全量抓取前，务必在 Manage data 中将法务绝密、并购专区等无需公开检索的资产源头剔除。
- 必做负向未授权测试： 切忌仅做“能搜到”的验证，必须设计跨权限测试用例，确保隔离内容在搜索与 AI 问答中双重静默。
- 常态化关注健康指标： 定期检查各连接器的同步状态与目录爬取日志，防止因第三方服务令牌过期导致检索断流。
通过规范的身份属性映射、分层的管理授权以及 Glean 原生权限镜像能力，IT 团队不仅能够彻底消除分散工具的信息孤岛，更能构建坚不可摧的合规与数据安全底座。