共用方式為

Azure AI 搜尋中的檔層級訪問控制

Azure AI 搜尋支援檔層級訪問控制，讓組織能夠從數據擷取到查詢執行，在檔層級強制執行更細緻的許可權。 這項功能對於構建安全的 AI 主動系統以數據為基礎、Retrieval-Augmented 生成（RAG）應用程式以及需要在文件層級進行授權檢查的企業搜尋解決方案至關重要。

文件層級存取控制的方法

方法 說明
安全性篩選條件 字串比較。 您的應用程式會以字串形式提供使用者或群組身分識別，作為查詢中的篩選條件，排除所有不符合該字串的文件。

安全性篩選器是達成檔層級訪問控制的技術。 此方法不會繫結至 API，因此您可以使用任何版本或套件。
類似 POSIX 的 ACL / RBAC 內窺鏡（預覽） Microsoft 查詢權杖背後的 Microsoft Entra 安全性主體會與搜尋結果中所傳回文件的權限中繼資料進行比較，但不包括任何不符合權限的文件。 存取控制清單 （ACL） 權限適用於 Azure Data Lake Storage （ADLS） Gen2 目錄和檔案。 角色型存取控制 （RBAC） 範圍適用於 ADLS Gen2 內容和 Azure Blob。

文件層級身分識別型存取的內建支援處於預覽狀態，可在 REST API 和提供此功能的預覽 Azure SDK 套件中使用。 請務必檢查 SDK 套件變更記錄 檔，以取得功能支援的證據。
Microsoft Purview 敏感度標籤（預覽） 索引器從支援的資料來源（Azure Blob Storage、ADLS Gen2、Microsoft 365 中的 SharePoint 、OneLake）擷取 Microsoft Purview 定義的敏感度標籤。 這些標籤會被儲存為元資料，並在查詢時進行評估，以根據 Microsoft Entra 令牌和 Purview 原則指派來強制使用者存取。 此方法使 Azure AI Search 授權與您企業的 Microsoft 資訊保護模型對齊。
SharePoint in Microsoft 365 ACLs （預覽） 設定後，Azure AI Search 索引器會在初次擷取時直接從 Microsoft 365 ACL 中擷取 SharePoint 文件權限。 存取檢查使用 Microsoft Entra 的使用者與群組成員權限。 支援的群組類型包括 Microsoft Entra 安全群組、Microsoft 365 群組，以及啟用郵件的安全群組。 SharePoint 群組尚未在預覽階段支援。

使用篩選進行安全性調整的模式

對於原生 ACL/RBAC 範圍整合不可行的案例，我們建議使用安全性字串篩選器，以根據排除準則修剪結果。 此模式包含下列元件：

  • 若要儲存使用者或群組身份，可以在索引中建立字串欄位。
  • 使用包含相關 ACL 的原始文件載入索引。
  • 在查詢邏輯中包含篩選表示式，以比對字串。
  • 在查詢時，取得呼叫端的身分識別。
  • 以篩選字串的形式傳入呼叫端的身分識別。
  • 結果會被裁剪，以排除未能包含使用者或群組身分字串的相符項目。

您可使用推送或提取模型 API。 因為這種方法與 API 無關，您只需要確保索引和查詢具有有效的字串（身分識別）才能進入過濾步驟。

此方法適用於具有自定義存取模型或非Microsoft安全性架構的系統。 如需此方法的詳細資訊，請參閱 Azure AI 搜尋中修剪結果的安全性篩選。

類似 POSIX 的 ACL 和 RBAC 範圍許可權的原生支援模式 （預覽）

原生支援是基於 Microsoft Entra 使用者以及您想要索引和查詢文件相關的群組。

Azure Data Lake Storage （ADLS） Gen2 容器支援容器和檔案上的 ACL。 對於 ADLS Gen2，當你使用 ADLS Gen2 索引器 或 Blob 知識來源（支援 ADLS Gen2） 並使用預覽 API 來匯入內容時，文件層級的 RBAC 範圍保留是原生支援的。 對於使用 Azure blob 索引子或知識來源的 Azure blob，RBAC 範圍保留為容器層級。

對於 ACL 保護的內容，我們建議使用群組存取而非個別使用者存取，以方便管理。 此模式包含下列元件：

  • 從具有 ACL 指派的檔或檔案開始。
  • 在索引中啟用許可權篩選。
  • 在索引中的字串欄位加上許可權篩選。
  • 使用具有相關聯 ACL 的來源文件載入索引。
  • 查詢索引，並加入 x-ms-query-source-authorization 請求標頭。

您的客戶端應用程式透過 搜尋索引資料閱讀 器或 搜尋索引資料貢獻 者角色，獲得索引的讀取權限。 查詢時的存取權由索引內容中的使用者或群組權限元資料決定。 包含權限篩選器的查詢會傳遞使用者或群組權杖，如請求標頭中所示 x-ms-query-source-authorization 。 當你在查詢時使用權限篩選器時，Azure AI Search 會檢查兩件事：

  • 首先，它會檢查允許用戶端應用程式存取索引的搜尋 索引資料讀取器 權限。

  • 其次，假設要求上有額外的語彙基元，它會檢查搜尋結果中傳回之文件的使用者或群組權限，但不包括任何不符合權限的文件。

若要將權限中繼資料新增至索引，您可以使用推送模型 API，將任何 JSON 文件推送至搜尋索引，其中資料負載包含字串欄位，為每個文件提供類似 POSIX 的 ACL。 此方法與安全性修剪之間的重要差異在於，索引和查詢中的許可權篩選中繼資料會辨識為 Microsoft Entra ID 驗證，而安全性修剪因應措施是簡單的字串比較。 此外，您可以使用 Graph SDK 來擷取身分識別。

如果資料來源是 Azure Data Lake Storage （ADLS） Gen2 ，且您的程式碼會呼叫預覽 API 進行索引，您也可以使用提取模型 （索引子） API。

在資料引入過程中取得 ACL 權限的元資料（預覽）

擷取 ACL 權限的方式會因您推送文件承載或使用 ADLS Gen2 索引子而有所不同。

從提供功能的預覽 API 開始：

對於推送模型方法：

  1. 請確定您的索引架構也會使用預覽或發行前版本 SDK 來建立，而且架構具有許可權篩選。
  2. 考慮使用 Microsoft Graph SDK 來取得群組或使用者身份。
  3. 使用 索引檔 或對等的 Azure SDK API，將檔及其相關聯的許可權元數據推送至搜尋索引。

對於提取模型 ADLS Gen2 索引子方法或 Blob (ADLS Gen2) 知識來源：

  1. 使用 ADLS Gen2訪問控制模型確認目錄中的檔案受到保護。
  2. 使用 Create Indexer REST API 或 Create Knowledge Source REST API 或等效的 Azure SDK API 來建立索引器、索引和資料來源。

Microsoft 365 的 SharePoint 基本 ACL 權限匯入模式（預覽）

對於 Microsoft 365 內容中的 SharePoint 權限，Azure AI Search 可以根據 SharePoint ACL 套用文件層級權限。 此整合促進只有擁有 SharePoint 原始文件存取權的使用者或群組，只要權限在索引中同步，才能在搜尋結果中取得該文件。 權限會在初始文件擷取期間或其他時間套用於索引。

SharePoint ACL 支援可透過 SharePoint 索引器預覽版，使用 2025-11-01-preview REST API 或支援的 SDK 提供。 索引器會擷取檔案和清單項目權限的元資料，並將其保存在搜尋索引中，用於查詢時強制存取控制。

此模式包含下列元件：

  • 使用 Microsoft 365 中的 SharePoint 索引器，具備 App 權限以讀取 SharePoint 網站內容，並具備完整存取權限以讀取存取控制清單 (ACL)。 請依照 SharePoint 索引器 ACL 的設定說明 來啟用與限制。
  • 在初始索引時，SharePoint ACL 條目（使用者與群組）會作為權限元資料儲存在搜尋索引中。
  • 關於 ACL 的增量索引，請參閱公開預覽期間可用的 SharePoint ACL 重新同步機制 。
  • 在查詢時，Azure AI Search 會將查詢權杖中的 Microsoft Entra 主體與索引中儲存的 SharePoint ACL 元資料進行檢查。 它排除了來電者未被授權存取的文件。

在預覽階段，SharePoint ACL 僅支援以下主要類型：

  • Microsoft Entra 使用者帳號
  • Microsoft Entra 安全性群組
  • Microsoft 365 群組
  • 已啟用郵件的安全性群組

SharePoint 群組在預覽版中不被支援。

關於設定細節及完整限制，請參閱如何在 Microsoft 365 中索引 SharePoint 文件層級權限（預覽）。

Microsoft Purview 敏感標籤的模式（預覽）

Azure AI Search 可以匯入並執行 Microsoft Purview 敏感度標籤 ，用於文件層級的存取控制，將 Microsoft Purview 的資訊保護政策擴展到您的搜尋與檢索應用程式中。

啟用標籤擷取時，Azure AI Search 會從支援的資料來源中擷取敏感度元資料。 這些包括：Azure Blob Storage、Azure Data Lake Storage Gen2（ADLS Gen2）、Microsoft 365 中的 SharePoint 以及 Microsoft OneLake。 擷取後的標籤會與文件內容一同儲存在索引中。

在查詢時，Azure AI Search 會檢查每份文件的敏感性標籤、使用者的 Microsoft Entra 令牌，以及組織的 Purview 政策，以判斷存取權限。 文件僅在使用者身份及標籤權限允許在已設定的 Purview 政策下存取時才會回傳。

此模式包含下列元件：

  • 請使用 2025-11-01-preview REST API 或支援 Purview 標籤擷取的相應 SDK 來設定您的 索引、 資料來源 和 索引器 （用於排程）。
  • 為您的搜尋服務啟用 系統指派的管理身份 。 接著請租戶全域管理員或特權角色管理員 授權所需存取權，讓搜尋服務能安全存取 Microsoft Purview 並擷取標籤元資料。
  • 在索引前對文件貼上敏感標籤，以便在擷取時能被識別並保存。
  • 在查詢時，透過標頭 x-ms-query-source-authorization 為每個查詢請求附加一個有效的 Microsoft Entra 令牌。 Azure AI Search 會評估憑證及相關的標籤元資料，以強制執行基於標籤的存取控制。

Purview 敏感性標籤的強制執行僅限於單一租戶情境，需 RBAC 認證，且公開預覽版僅支援 REST API 或 SDK。 目前，對於啟用了 Purview 的索引，自動完成和建議 API 無法使用。

欲了解更多資訊，請參閱 使用 Azure AI 搜尋索引器來導入 Microsoft Purview 敏感度標籤。

在查詢時間強制執行檔層級許可權

使用原生 令牌型查詢，Azure AI 搜尋會驗證使用者的 Microsoft Entra 令牌，並修剪結果集以只包含用戶獲授權存取的檔。

您可以將使用者的 Microsoft Entra 令牌附加至查詢要求，以達到自動修剪。 欲了解更多資訊，請參閱 Azure AI Search 中的查詢時 ACL 與 RBAC 強制執行。

檔層級訪問控制的優點

檔層級訪問控制對於保護 AI 驅動應用程式中的敏感性信息至關重要。 其可協助組織建置符合其存取原則的系統，降低暴露未經授權或機密數據的風險。 藉由將存取規則直接整合到搜尋管線中，AI 系統可以提供以安全且授權的資訊為基礎的回應。

藉由將許可權強制執行卸除至 Azure AI 搜尋服務，開發人員可以專注於建置高品質的擷取和排名系統。 這種方法有助於減少處理巢狀群組、撰寫自定義篩選或手動修剪搜尋結果的需求。

Azure AI 搜尋中的檔層級許可權提供結構化架構，以強制執行符合組織原則的訪問控制。 藉由使用Microsoft以 Entra 為基礎的 ACL 和 RBAC 角色，組織可以建立支持強固合規性的系統，並提升使用者之間的信任。 這些內建功能可減少自定義編碼的需求，提供檔層級安全性的標準化方法。

教學課程和範例

使用更多文章和範例，深入瞭解 Azure AI 搜尋中的檔層級訪問控制。

相關內容

  • Last updated on