本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 知识库中管理 ACL 的最佳实践
使用带有访问控制列表 (ACL) 的知识库时，您有责任保持用户身份和权限的准确性。这样可以确保合适的人员可以访问正确的文档。默认情况下，Quick 每 24 小时自动同步一次身份和文档级 ACL 更改。除非您为知识库配置了不同的刷新计划，否则对用户或权限的任何更新最多需要一天的时间才能显示在系统中。
[有关为特定数据源配置 ACL 的更多信息，请参阅[亚马逊 S3](s3-integration.md)、A [tlassian Confluence Cloud、Google 云端](confluence-kb-acl.md)[硬盘](google-drive-kb-acl.md)或微软。 SharePoint](sharepoint-kb-acl.md)
要验证文档级访问控制并解决权限问题，请参阅。[检查文档访问权限（ACL 验证）](sync-reports-observability.md#sync-reports-acl-verification)
**注意**
Quick 将所有电子邮件地址视为不区分大小写。 `JohnDoe@example.com`、`johndoe@example.com`、和`JOHNDOE@example.com`都被视为同一个用户。
## 重要的用户管理场景
**了解电子邮件绑定**
当用户发起聊天互动时，电子邮件地址会动态绑定到 Quick 用户。这种绑定遵循先到先得的方法。第一个与给定电子邮件地址聊天的用户在命名空间中为该身份建立绑定。
**当员工离开您的组织时**
当员工离开时，请立即清理其访问权限：
1. 更新 ACL 配置文件以删除对其电子邮件地址的引用。例如，在 Amazon S3 中，更新全局 ACL 文件或元数据文件。
1. 刷新知识库以应用更改。
这样可以防止以后将电子邮件重新分配给其他人时出现潜在的安全问题。
**与共同所有者共享管理员管理的知识库**
Admin-managed 知识库（服务凭证）通常用于团队和组织。如果原始创作者离开公司并且没有共同所有者，知识库就会变得难以管理——没有人可以编辑设置、触发同步或更新权限。为避免这种情况，请与至少一个其他所有者共享管理员管理的知识库。有关更多信息，请参阅 [共享知识库和数据源](sharing-kb-datasources.md)。
**将电子邮件地址重新分配给新员工时**
+ ACL-aware 系统会自动锁定重新分配的电子邮件地址的知识库访问权限，以保护数据安全。
+ 在新员工可以访问与该电子邮件关联的文档之前，请联系 Quick Support 以清理先前用户的访问权限。
## 限制
为知识库配置文档级 ACL 时，请注意以下限制：
+ **Document-level ACL 配置是永久性的** — 您无法在没有 ACL 支持的情况下创建的知识库中启用 ACL。启用 ACL 后，您也无法禁用。要更改 ACL 配置，请从一开始就使用所需的设置创建一个新的知识库。
+ **命名空间内的共享电子邮件地址-如果多个 Quick 用户在一个**命名空间内共享同一个电子邮件地址，则系统会拒绝所有使用该共享电子邮件的用户进行访问。这种保护措施可防止意外向错误的人授予文档访问权限。
+ **ACL 解析范围**-所有 ACL 都是在知识库创建者的快速命名空间中解析的。无论是通过电子邮件地址还是组名指定 ACL，这都适用。在创作者的组织环境中快速查找身份，以确保一致的身份解析。
+ **电子邮件地址回收时机** — 如果您的组织将电子邮件地址从一名员工重新分配给另一名员工，则需要考虑一个重要的时机。如果之前的员工从未使用过 Quick 进行聊天或 AI 互动，并且在下一次 ACL 刷新之前重新分配了电子邮件，则新员工可以临时访问为前任员工准备的文档。
为避免这种情况，请按顺序完成以下步骤：
1. 更新您的 ACL（如果适用，例如在 Amazon S3 中）以移除旧用户并添加新用户。
1. 手动刷新您的知识库，或者等待每日自动刷新。
1. 将电子邮件地址分配给新员工。
这样可以确保在新用户开始使用 Quick 之前正确同步访问权限。
+ **研究兼容性** — 启用了文档级 ACL 的知识库目前与 Quick Research 不兼容。如果您需要将 ACL-enabled 知识库中的文档用于研究目的，请为这些文档创建一个不带 ACL 的单独知识库。