本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 知识库中管理 ACL 的最佳实践
通过文档级访问控制列表 (ACL)，Amazon Quick 强制执行知识库的源文档权限。 ACL-aware 每个授权用户仅检索他们有权访问的索引文档。当不同的用户需要访问同一知识库中的不同文档时，使用 ACL。
您有责任保持来源身份、群组和文档权限的准确性。Quick 在每次检索时强制执行同步文档权限。对于支持的集成，它还会在返回结果时对照源实时验证文档访问权限。如果 Quick 无法评估查询的文档权限，则它不会返回任何文档，而不是未筛选的结果。
Quick 根据知识库刷新计划同步身份和文档权限更改，默认情况下，该计划每 24 小时更新一次。当您的访问变更要求时，请配置不同的时间表。
**共享和文档访问是单独的控件**
共享知识库和授予文档访问权限是单独的控制措施。 Knowledge-base 共享决定了谁可以使用知识库。对于 ACL-aware 知识库，源文档 ACL 进一步限制了每个授权用户可以检索哪些索引文档。在授予访问权限之前，请查看这两个控件。
有关为特定数据源配置 ACL 的更多信息，请参阅 [ Amazon S3 ](s3-integration.md)、[Google Drive](google-drive-kb-acl.md)、或[Microsoft SharePoint](sharepoint-kb-acl.md)。对于[Atlassian Confluence Cloud](confluence-kb-acl.md)和 [Microsoft OneDrive](onedrive-kb-acl.md)，请在控制台中配置文档级 ACL（如果有）。
要验证文档级访问控制和解决权限问题，请参阅。[检查文档访问权限（ACL 验证）](sync-reports-observability.md#sync-reports-acl-verification)
**注意**
Quick 将所有电子邮件地址视为不区分大小写。`JohnDoe@example.com``johndoe@example.com`、和`JOHNDOE@example.com`都被视为同一个用户。
## 在创建之前规划 ACL-aware 知识库
在创建 ACL-aware 知识库之前，请完成以下步骤：
1. 确认您的集成支持文档级 ACL。
1. 确认 Quick 用于解析用户和群组的身份属性。
Quick 解析知识库创建者的命名空间中的 ACL。有关更多信息，请参阅 [限制](#acl-limitations)。
1. 在将共享或回收的身份分配给其他人之前，将其从源 ACL 中移除。
1. 选择符合您的访问变更要求的刷新时间表。对于 Amazon S3，权限更改将在下次同步时生效，因此请相应地规划时间表。
1. 在广泛共享知识库之前，先与代表性用户测试文档访问权限。要检查文档访问权限，请参阅[检查文档访问权限（ACL 验证）](sync-reports-observability.md#sync-reports-acl-verification)。
1. 确认 “快速研究” 不需要知识库。
1. 为管理员管理的知识库分配至少一个额外的所有者，以便在其原始创建者离开时仍能对其进行管理。
## 重要的用户管理场景
**了解电子邮件绑定 **
当用户发起聊天互动时，电子邮件地址会动态绑定到 Quick 用户。这种绑定遵循先到先得的方法。第一个使用给定电子邮件地址聊天的用户会在命名空间中建立该身份的绑定。
**当员工离开您的组织时 **
员工离职时，立即清理其访问权限：
1. 更新 ACL 配置文件以删除对其电子邮件地址的引用。例如，在 Amazon S3 中，更新全局 ACL 文件或元数据文件。
1. 刷新知识库以应用更改。
这样可以防止以后将电子邮件重新分配给其他人时出现潜在的安全问题。
更新知识库 ACL 与从 Quick 中移除用户是分开的。有关删除用户如何影响用户资产和数据的完整模型，请参阅[Amazon Quick 中的用户生命周期和数据处理](user-lifecycle-data-handling.md)。
**与共同所有者共享管理员管理的知识库 **
Admin-managed 知识库（服务凭证）通常用于团队和组织。如果原始创建者离开公司并且没有共同所有者，则知识库将变得难以管理——没有人可以编辑设置、触发同步或更新权限。为避免这种情况，请与至少一个其他所有者共享管理员管理的知识库。有关更多信息，请参阅 [共享知识库和数据源](sharing-kb-datasources.md)。
**当电子邮件地址被重新分配给新员工时 **
+ ACL-aware 重新分配的电子邮件地址的知识库访问权限会自动锁定，以保护数据安全。
+ 在新员工可以访问与该电子邮件相关的文档之前，请与 Quick 支持部门联系以清理先前用户的访问权限。
## 限制
为知识库配置文档级 ACL 时，请注意以下限制：
+ **Document-level ACL 配置是永久性的 ** — 如果没有 ACL 支持，则无法为创建的知识库启用 ACL。开启后也无法将其关闭。要更改 ACL 配置，请从一开始就使用所需的设置创建一个新的知识库。
+ **命名空间内的共享电子邮件地址 ** — 如果多个 Quick 用户在命名空间内共享同一个电子邮件地址，则系统会拒绝使用该共享电子邮件的所有人进行访问。这种保护措施可防止意外地将文档访问权限授予错误的人。
+ **ACL 解析范围 ** — Quick 解析知识库创建者命名空间中的所有 ACL。无论您是通过电子邮件地址还是组名指定 ACL，这都适用。在创作者的组织环境中快速查找身份，以确保一致的身份解析。
+ **电子邮件地址回收时机 ** — 如果您的组织将电子邮件地址从一名员工重新分配给另一名员工，则需要考虑一个重要的时间因素。如果上一位员工从未使用 Quick 进行聊天或 AI 互动，并且电子邮件在下一次 ACL 刷新之前被重新分配，则新员工可以临时访问专为前任员工准备的文档。
为避免这种情况，请按顺序完成以下步骤：
1. 更新您的 ACL（如果适用，例如在 Amazon S3 中）以删除旧用户并添加新用户。
1. 手动刷新知识库，或等待每日自动刷新。
1. 将电子邮件地址分配给新员工。
这样可以确保在新用户开始使用 Quick 之前正确同步访问权限。
**研究兼容性**
启用了文档级 ACL 的知识库目前与 Quick Research 不兼容。如果您需要使用 ACL-enabled 知识库中的文档进行研究，请为这些文档创建一个不带 ACL 的单独知识库。