本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
存取控制清單意識啟用
Bedrock 受管知識庫支援 ACL 感知擷取 — 能夠根據從連線資料來源編目的文件層級存取控制清單 (ACLs) 篩選查詢結果。在資料來源上啟用 ACL 意識時，Bedrock 受管知識庫會擷取許可 （允許的使用者、拒絕的使用者、允許群組、拒絕群組） 以及文件內容。在查詢時間，您提供使用者內容，而 Bedrock 受管知識庫只會傳回允許使用者存取的文件。如需擷取時用來傳遞使用者內容的請求語法，請參閱 受管知識庫上的 ACL 感知擷取。
ACL 意識不是授權
Bedrock 受管知識庫提供 ACL 感知篩選，而不是安全界限。Bedrock 受管知識庫不會驗證最終使用者 — 您的應用程式負責驗證使用者並傳遞已驗證的身分內容。由於 Bedrock 受管知識庫無法驗證您提供的使用者內容的真實性，因此此功能會根據您提供的身分篩選結果，但不會構成真正的授權。在沒有上游身分驗證的情況下，您不得依賴此功能做為唯一存取控制機制。
ACL 感知擷取的運作方式
ACL 感知擷取會以兩個階段運作：
-
擷取前篩選 - 在擷取期間，Bedrock 受管知識庫會從資料來源爬取文件許可。在查詢時間，Bedrock 受管知識庫會使用您提供的使用者內容來篩選搜尋結果，僅傳回使用者 （或其群組） 出現在允許清單中，且未出現在拒絕清單中的文件。
-
即時 ACL 驗證 — 對於支援它的連接器 (SharePoint、OneDrive、Google Drive、Confluence)，Bedrock 受管知識庫會對資料來源進行即時呼叫，以確認使用者仍然可以存取每個傳回的文件。這會擷取同步之間發生的許可變更。S3 和自訂連接器不支援即時驗證，因為其 ACL 中繼資料是由客戶透過組態檔案提供，而不是從即時許可系統爬取。
兩個階段都使用相同的評估邏輯：如果使用者同時出現在允許清單和文件的拒絕清單中，則會拒絕存取。拒絕一律覆寫允許。
身分模型
Bedrock 受管知識庫使用電子郵件作為 ACL 比對的通用使用者識別符。使用者一律由其通用電子郵件識別，您在使用者內容中傳遞的電子郵件必須與每個連線資料來源中與使用者相關聯的電子郵件完全相符。沒有別名解析或cross-identity-provider映射。相較之下，群組由 識別，但來源連接器代表它們：群組名稱、群組 ID 或其他識別符，並與從該資料來源爬取的群組成員資格相符。
群組成員資格會從資料來源解析。在擷取期間，Bedrock 受管知識庫會從每個資料來源爬取群組成員資格，並將其存放在內部。在查詢時間，Bedrock 受管知識庫會根據此編目資料自動解析使用者所屬的群組。
注意
群組成員資格與上次同步一樣新。在下一個擷取任務完成之前，不會反映同步之間的許可變更。對於支援即時 ACL 驗證的連接器，此檢查會擷取自上次同步以來發生的許可變更。
連接器支援矩陣
並非所有連接器都支援 ACL 意識。下表顯示哪些連接器支援擷取前篩選和即時 ACL 驗證。
| 連接器 | 擷取前篩選條件 | 即時 ACL | 備註 |
|---|---|---|---|
| SharePoint | 支援 | 支援 | 使用應用程式層級許可 (2LO)。需要ENTRA_ID_APP_ONLY身分驗證類型。 |
| OneDrive | 支援 | 支援 | 使用應用程式層級許可 (2LO)。需要ENTRA_APP_ID身分驗證類型。 |
| Google 雲端硬碟 | 支援 | 支援 | 使用全網域委派 (2LO)。需要SERVICE_ACCOUNT身分驗證類型。 |
| Confluence | 支援 | 支援 | 使用管理員 API 字符進行即時檢查。需要BASIC身分驗證類型。 |
| Amazon S3 | 支援 | 不支援 | ACLsAmazon S3 中客戶提供的 ACL 組態檔案定義的 ACL。沒有即時驗證，因為客戶提供的中繼資料檔案是事實來源。 |
| Custom | 支援 | 不支援 | 透過客戶提供的中繼資料定義的 ACLs。沒有即時驗證，因為客戶提供的中繼資料是事實來源。 |
| Web 編目程式 | 不支援 | N/A | Web 內容沒有許可模型。無法為此連接器啟用 ACL 意識。 |
如需連接器特定的 ACL 組態詳細資訊，請參閱：
失敗行為
ACL 感知擷取無法關閉。如果 ACL 評估管道的任何部分發生錯誤 — 群組解析失敗、即時驗證逾時或內部服務錯誤 — Bedrock 受管知識庫不會傳回受影響的文件。暫時性失敗永遠不會將文件傳回給未經授權的使用者。
發生 ACL 失敗時，回應可能包含零個結果或少於預期的結果。錯誤回應表示 ACL 解析失敗，因此您可以將它與真正符合沒有文件的查詢區分開來。
您的責任
由於 Bedrock 受管知識庫提供 ACL 感知篩選，而不是完整的授權解決方案，因此您必須負責以下事項：
-
驗證最終使用者 — 您必須先驗證應用程式中的使用者，才能將他們的身分傳遞給 Bedrock 受管知識庫。Bedrock 受管知識庫不會驗證您提供的使用者內容是否真實。
-
一致的電子郵件身分 — 您傳遞的電子郵件地址必須符合每個連線資料來源中使用的電子郵件。如果電子郵件在系統之間不同，ACL 比對會無提示失敗，而且使用者不會收到來自該資料來源的結果。
-
電子郵件生命週期管理 - 如果電子郵件地址重新指派給不同的人員 （例如員工離職後），您必須在將身分傳遞給 Bedrock 受管知識庫之前偵測到此問題。即時 ACL 驗證可做為支援它的連接器的安全網路，但不能取代適當的身分生命週期管理。