本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 在知識庫中管理 ACLs最佳實務
將知識庫與存取控制清單 (ACLs) 搭配使用時，您必須負責確保使用者身分和許可的準確性。這可確保適當的人員可以存取正確的文件。根據預設，快速會每 24 小時自動同步身分和文件層級 ACL 變更。除非您已為知識庫設定不同的重新整理排程，否則使用者或許可的任何更新最多需要一天的時間才會出現在系統中。
如需為特定資料來源設定 ACLs 的詳細資訊，請參閱 [Amazon S3](s3-integration.md)、[Atlassian Confluence Cloud](confluence-kb-acl.md)、[Google Drive](google-drive-kb-acl.md) 或 [Microsoft SharePoint](sharepoint-kb-acl.md)。
若要驗證文件層級存取控制並疑難排解許可問題，請參閱 [檢查文件存取 (ACL 驗證）](sync-reports-observability.md#sync-reports-acl-verification)。
**注意**
快速將所有電子郵件地址視為不區分大小寫。`JohnDoe@example.com`、 `johndoe@example.com`和 `JOHNDOE@example.com` 都視為相同的使用者。
## 重要的使用者管理案例
**了解電子郵件繫結**
當使用者啟動聊天互動時，電子郵件地址會動態繫結至快速使用者。此繫結遵循first-come-first-serve方法。第一個與指定電子郵件地址聊天的使用者會在命名空間中建立該身分的繫結。
**當員工離開您的組織時**
當員工離開時，立即清除其存取權：
1. 更新 ACL 組態檔案，以移除對其電子郵件地址的參考。例如，在 Amazon S3 中，更新全域 ACL 檔案或中繼資料檔案。
1. 重新整理知識庫以套用變更。
如果稍後將電子郵件重新指派給其他人，這可防止潛在的安全問題。
**與共同擁有者共用管理的知識庫**
管理的知識庫 （服務登入資料） 通常用於團隊和組織。如果原始建立者離開公司，而且沒有共同擁有者，知識庫就無法管理 — 沒有人可以編輯設定、觸發同步或更新許可。若要避免這種情況，請至少與一個額外的擁有者共用管理員管理的知識庫。如需詳細資訊，請參閱[共用知識庫和資料來源](sharing-kb-datasources.md)。
**將電子郵件地址重新指派給新員工時**
+ ACL 感知知識庫存取會自動鎖定重新指派的電子郵件地址，以保護資料安全。
+ 請聯絡 Quick Support 以清除上一個使用者的存取權，然後新員工才能存取與該電子郵件相關聯的文件。
## 限制
為您的知識庫設定文件層級 ACLs 時，請注意下列限制：
+ **文件層級 ACL 組態為永久性** – 您無法在無 ACLs 支援的情況下建立的知識庫上啟用 ACL。您也無法在啟用後停用 ACLs。若要變更 ACL 組態，請從頭開始建立具有所需設定的新知識庫。
+ **命名空間內的共用電子郵件地址** – 如果多個快速使用者在命名空間內共用相同的電子郵件地址，系統會拒絕使用該共用電子郵件的每個人存取。此保護可防止意外將文件存取權授予錯誤的人員。
+ **ACL 解析範圍** – 所有 ACLs都會在知識庫建立者的快速命名空間內解析。這適用於是否透過電子郵件地址或群組名稱指定 ACLs。快速在建立者的組織內容中查詢身分，以確保一致的身分解析。
+ **電子郵件地址回收時間** – 如果您的組織將電子郵件地址從一個員工重新指派給另一個員工，則有重要的時間考量。如果前一位員工從未使用 Quick 進行聊天或 AI 互動，且電子郵件在下一次 ACL 重新整理之前重新指派，則新員工可能會暫時存取適用於前一位員工的文件。
若要避免這種情況，請依序完成下列步驟：
1. 更新您的 ACLs（如適用，例如在 Amazon S3 中），以移除舊使用者並新增新使用者。
1. 手動重新整理您的知識庫，或等待自動每日重新整理。
1. 將電子郵件地址指派給新員工。
這可確保在新使用者開始使用 Quick 之前，存取許可已正確同步。
+ **研究相容性** – 已啟用文件層級 ACLs知識庫目前與 Quick Research 不相容。如果您需要將啟用 ACL 的知識庫中的文件用於研究，請為這些文件建立沒有 ACLs的個別知識庫。