如何系统性地保障 Amazon Q 的安全性

Amazon Q 将仪表板、对话智能体、工作流（Flows）和知识库整合于一体，每项能力都引入了标准仪表板控制所无法覆盖的安全面。仅依赖权限设置来阻止访问，往往会因配置失误留下隐患。更可靠的做法是在数据到达用户之前就完成过滤与裁剪，从架构层面消除敏感信息的暴露风险。

第一个核心模式是数据集整形。在 AnyCompany 场景中，同一份员工数据被拆分为三个视图：面向 HR 领导层的完整数据集包含全部 30 列；面向部门经理的数据集移除了年薪、奖金比例、离职日期等四个敏感列，并叠加行级安全策略，确保每位经理只能看到本部门员工；面向全体员工的数据集则仅保留按部门和地点汇总的 25 行聚合数据，不含任何个人记录。列的移除是结构性限制，比隐藏列更为可靠。

第二个模式是智能体隔离。每个 Chat Agent 仅连接到与其受众权限对齐的单一数据集，不允许跨数据集查询。这样即便智能体被诱导执行超出预期的查询，其能够访问的数据上限也已由数据集本身决定。第三个模式是文档分类：在构建知识库时，将敏感文档从索引范围内排除，而非依赖权限控制来限制访问，从根本上避免敏感内容被检索到。

第四个模式是审批门控。在 Flows 中配置人工审核节点，要求所有对外部系统的写操作在执行前必须经过人工确认。这一机制在自动化流程中引入了关键的人工监督环节，有效防止智能体在无人知晓的情况下触发高风险操作。四种模式协同作用，构成一套纵深防御体系，而非单点依赖权限配置。

在治理层面，文章建议配置 AWS CloudTrail 以记录所有 Amazon Q 操作日志，并在 Flows 连接外部系统时通过 AWS Secrets Manager 管理凭证。对于使用 AWS IAM Identity Center 进行身份联合的账户，用户组管理需在 IAM Identity Center 控制台完成，而非在 Amazon Q 控制台内操作，但数据集整形、行级安全和智能体隔离等安全模式依然适用。完整的生产就绪检查清单和示例代码已发布于配套的 GitHub 仓库。

要点

• 在数据集层面移除敏感列，比依赖权限隐藏列具有更强的结构性安全保障，是防止数据泄露的首选手段。
• 每个智能体应仅连接与其受众权限对齐的单一数据集，智能体隔离是防止跨权限数据访问的关键模式。
• 知识库应在索引阶段排除敏感文档，而非事后依赖权限控制，文档分类需在架构设计时前置考虑。
• Flows 中的人工审批门控为自动化流程引入必要的监督节点，可有效防止高风险操作在无人知晓的情况下执行。
• 从概念验证扩展至生产环境时，需同步配置 CloudTrail 审计日志和 Secrets Manager 凭证管理，确保治理框架与业务规模同步成长。