企業內部軟體分散於各個部門孤島——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維護別名。
企業併購與多網域情境的身分拼接實務
在跨租戶、多網域或組織整併情境中：
- 統一於主要 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 Token），完成授權並儲存。
步驟 4：於「資料管理（Manage Data）」自訂檢索範疇
多數原生連接器於儲存後會顯示 Manage data 標籤頁：
- 排除規則： 設定黑名單排除敏感或無關資源（例如高階主管專用 SharePoint 網站、法律合規 Slack 頻道、過期歸檔程式碼庫）。
- 資料存取模式： 依需求設定為 Indexed（索引模式，預先耙梳至租戶資料庫，確保超低檢索延遲） 或 Live / Hybrid（即時/混合模式，於查詢當下呼叫 API，適用於極度頻繁變動或長尾資料）。
第四階段：首次耙梳、索引建立與權限驗證
設定儲存後，連接器即進入初次同步週期。
同步雙階段
- Crawling（耙梳階段）： 背景程式呼叫源系統 API，提取文件本文、中繼資料（作者、建立時間、更新紀錄）以及完整的 ACL（人員名單、群組對應、網域共用標籤）。
- Indexing（索引階段）： Glean 將內文轉換為語義向量與關鍵字索引，解析實體關係，並將來源使用者識別碼與 People Graph 對齊，納入安全知識圖譜。
初次同步時長取決於資料總量與目標系統 API 的頻率限制。管理員可在 Admin Console > Connectors > Manage connectors 中即時檢視已同步項目數（Items synced）與連線健康度。
於測試群組落實安全性驗證（上線必經關卡）
在開放全體員工使用前，必須進行存取控制驗收：
- 設定測試群組可見性： 於連接器設定中，將可搜尋範圍限制為 IT 測試群組或試行部門。
- 正向搜尋測試： 以不同部門的測試帳號登入，驗證員工能正常找到其在 Google Drive、SharePoint 或 Confluence 中本就擁有權限的文件。
- 反向隔離測試（最關鍵步驟）： 使用一般員工測試帳號，主動搜尋受限機密檔案（如高階主管薪資明細、人事重組名單）。確認搜尋結果呈現「零結果」，且 Glean Assistant 在任何對話中皆不會引用或暗示受限內容。
- 工具呼叫權限確認： 若連接器開啟了供 AI 助理使用的即時工具（如建立 Jira 工單、MCP 伺服器），需確認該操作確實以發起使用者的代理身分執行，且被管理員封鎖的工具無法被呼叫。
第五階段：日常維運、增量同步與 AI Agent 治理
確保系統長期穩定與合規，有賴於持之以恆的維運機制：
增量耙梳與 Webhook 即時更新
首次全量同步完成後，Glean 主要依賴源系統的 Webhook 推送或高頻率增量耙梳來捕捉文件的增刪修改。在絕大多數 SaaS 原生連接器中，原始系統的權限調整通常能在數分鐘內反映於 Glean，避免權限不同步。
監控告警與稽核日誌
管理員應定期查看 Notifications dashboard 與 Admin Alerts，即時排除 OAuth 憑證過期或 API 頻率受限等連線問題。所有管理員操作（包括連接器設定變更、角色調整、排除清單修改）均被完整保存於無法被篡改的 Audit Logs 中。
模型上下文協定（MCP）與 Agent 安全防護
隨著企業廣泛導入自主智慧體與 MCP 伺服器：
- Glean 確保智慧體在檢索資料與執行操作時，絕不超越提問員工自身的權限範圍。
- 管理員可於 Admin Console > Tools 集中管理可用工具，將關鍵寫回操作設定為「需審核（Needs approval）」，嚴防非預期的自動化資料修改。
企業 IT 管理員實務檢核清單
- 鎖死身分屬性源頭： 徹底盤查 Entra ID 或 Okta 設定，確保別名僅由管理員專管的
proxyAddresses產生，嚴禁使用使用者可自行編輯的次要欄位。 - 落實群組型 RBAC： 將 Glean 的 Setup Admin 與 Admin 角色綁定至 IdP 安全性群組，實現權限動態管理。
- 初次耙梳前預先排除： 在發起全量同步前，務必於 Manage data 中剔除極機密或非業務性的孤立空間。
- 落實反向未授權檢核： 驗收切忌僅做「找得到」測試，必須嚴格驗證跨權限資源的「完全隱形」。
- 監控憑證與健康指標： 定期檢閱連接器連線狀態與人員目錄耙梳報表，防範因 API 權杖過期導致搜尋中斷。
透過嚴謹的身分屬性對齊、分層管理授權與 Glean 原生的權限鏡像機制，IT 團隊能一舉打破企業內部工具的資訊孤島，同時建立符合最高合規標準的安全工作區搜尋平台。