把 Amazon Quick 从概念验证做到生产：智能体、流程与空间

#把 Amazon Quick 从概念验证做到生产：智能体、流程与空间

Amazon Quick 的概念验证（proof of concept，POC）项目常常能在小型试点团队里成功，却在安全与合规团队审查生产方案时停滞。一套对十名试点用户有效的权限模型，在增加五个部门后往往会失效。智能体（Agent）可能返回超出既定范围的数据，合规团队也难以审计数据集、智能体与空间（Space）之间如何连接。

Amazon Quick 把仪表板（Dashboard）、聊天智能体（Chat Agent）、流程（Flow）和带知识库（knowledge base）的空间组合在一起。每一种能力都会引入标准仪表板控件覆盖不到的安全面。

本文逐步说明如何为 AnyCompany 场景设计仪表板、空间、知识库、智能体和流程，并使安全控制在增加用户和部门后仍然成立。演练覆盖四种模式：数据集塑形（dataset shaping）、智能体隔离（agent isolation）、文档分级（document classification）和审批门（approval gate）。其中还包括治理框架和生产就绪检查清单。

用例概览

设想 AnyCompany：5000 名员工、5 个部门、5 个地点。三类受众需要同一份数据的不同层级：

• 人力资源领导层：完整的员工数据，包括薪资和离职风险。
• 部门经理：仅其团队的运营指标。
• 全体员工：公司政策与匿名化趋势。

把同一数据集暴露给这三类受众，并只依赖权限，会留下过大的误配置空间。

方案概览

该方案把一份源数据集塑形为三个与授权对齐的视图，并分别连接到专用智能体。它按受众发布对应的仪表板，按内容所有权限定空间范围，并通过带人工在环（human-in-the-loop）控制的流程把出站动作拦住。

下面的截图展示人力资源领导层仪表板，它提供完整的员工可见性，包括全体员工的薪资、离职风险和职级分解。

图 1a：人力资源领导层仪表板：覆盖全部 5000 名员工的完整员工可见性，包括薪资、离职风险和职级分解。

下面的截图展示部门经理仪表板，它通过行级安全（Row-Level Security，RLS）显示限定在单个部门的运营指标。

图 1b：部门经理仪表板：底层数据相同，但敏感列已移除并应用了 RLS。每位经理只能看到本部门的员工。

下面的截图展示公司趋势仪表板，它只显示按部门与地点汇总的结果。从该视图无法访问任何员工个人记录。

图 1c：公司趋势仪表板：汇总到部门 × 地点层级。看不到员工个人数据。面向全体员工开放。

创建并发布仪表板： 要从这些数据集创建仪表板，进入 Analyses（分析），然后选择 Create analysis（创建分析），选中三个数据集之一，构建可视化，然后选择 Share（共享），再选择 Publish dashboard（发布仪表板）。把每个仪表板共享给对应的组。详细指导见 Publishing dashboards。

已验证的模式

本文演示四种协同生效的已验证模式，它们通过数据架构来落实安全：

每种模式都在数据到达用户之前将其移除，而不是依赖权限设置来阻止访问。下面的演练会实现全部四种模式。

前提条件

开始之前，请确认已具备以下条件：

• 一个已启用 Amazon Quick 的 AWS 账户（企业版计划）
• 至少三个代表不同角色的 Amazon Quick 用户账户（或一个可以切换角色的用户）
• 一份示例员工数据集（5000 行、30 列）。使用后面步骤 1 中的生成步骤，或使用列结构相近的自有人力资源数据集。
• 账户中已配置 AWS CloudTrail 跟踪。
• 若流程要连接外部系统，则需要 AWS Secrets Manager 访问权限。

注意： 本演练使用 Amazon Quick 托管身份（非 IDC）。组的创建和用户管理直接在 Amazon Quick 控制台中完成。如果账户使用 AWS IAM 身份中心（IAM Identity Center，IDC）做身份联合，组管理在 AWS IAM 身份中心控制台中处理，而不是在 Amazon Quick 内部。安全模式（数据集塑形、RLS、智能体隔离）仍然适用，但分配组的步骤会有所不同。

方案演练

下面九个步骤带你走过方案的每一层：从塑形数据集、应用行级安全，到配置智能体、空间、流程和审计日志。

步骤 1：按授权塑形数据集

在 Amazon Quick 中，最重要的安全决策之一是如何塑形数据集。数据集的列决定了任何连接到它的人能够看到的上限。从数据集中移除列，在结构上比把列藏在权限后面更强。

生成一份 5000 行、30 列的合成员工数据集（员工 ID、性别、年龄、部门、岗位角色、职级、地点、年薪、敬业度得分、离职标志等）。使用五个部门（销售、工程、运营、财务、人力资源）、五个地点，以及符合实际的取值范围。随附的 GitHub 仓库包含完整列清单和一份示例生成脚本，你也可以换成结构相近的自有人力资源数据集。

把生成的 employee_data.csv 上传到数据（数据集，然后新建数据集，然后上传文件），创建三个数据集：

下面的截图展示创建这三个数据集之后的数据集控制台。

图 1d：数据集控制台。请注意经理数据集上的 RLS 已启用标记、权限数据集上的规则数据集标签，以及所有数据集的 SPICE 存储。

对于汇总数据集，使用数据准备中的分组界面，或在上传前预先聚合 CSV：

要创建汇总数据集，按部门和地点对源数据分组，然后计算：每组的员工人数、平均敬业度得分和平均满意度得分。这将产生 25 行汇总（5 个部门 × 5 个地点）。把结果作为单独的数据集上传。

为何重要：仅靠权限，对比数据架构：

如果把完整数据集暴露给所有受众并只依赖权限，一次误配置（错误的组分配、过宽的共享规则）就可能把薪资数据暴露给全体员工。有了数据集塑形，薪资列在下游数据集中并不存在。权限错误无法暴露并不存在的内容。

步骤 2：应用行级安全

Amazon Quick 的行级安全（RLS）限制数据访问，使用户只能根据身份看到特定行。你在数据集层级设置 RLS：创建一个映射数据集，把用户或组与特定列值关联起来，然后传播到所有关联的分析和仪表板。

创建一份 RLS 规则 CSV 并作为权限数据集上传：

创建一份权限 CSV（rls-rules.csv），包含两列：UserName 和 Department。为每个用户—部门组合添加一行（例如，人力资源管理员获得五行以实现完全访问。销售经理获得一行）。

提示：要找到精确的 RLS 用户名，在任意分析中添加计算字段 username()。格式因身份提供方而异。哪怕只差一个字符，也会返回零行。

把 rls-rules.csv 作为新数据集上传（命名为 anycompany-rls-rules），然后打开 anycompany-employees-manager 数据集，进入行级安全选项卡，选择规则数据集，映射 UserName 和 Department，然后保存。

验证：以 hr-admin 登录，应看到 5000 行。以经理登录，应只看到本部门（约 1000 行）。零行意味着用户名字符串不匹配。

步骤 3：创建三个组并分配用户

在“管理 Amazon Quick”，然后“管理组”中创建三个组：

为了在企业规模上简化共享，把数据集共享给组，而不是共享给个人用户。更多细节见 Amazon Quick 文档中的共享数据集。

下面的截图展示在管理组控制台中创建的三个组。

图 1e：在“管理 Amazon Quick”，然后“管理组”中创建的三个组：all-employees、hr-leadership 和 dept-managers。组成员身份控制全部数据集、智能体和空间权限。

步骤 4：创建空间、上传知识库文档并设置权限

空间用于组织文档，并通过知识库提供基于文档的问答。三个智能体都会连接到这个空间，因此要在配置智能体之前创建它。

创建空间：

1. 在 Amazon Quick 控制台中进入 Spaces（空间），然后选择 Create Space（创建空间）。
2. 在 Space name（空间名称） 字段中输入：AnyCompany HR。
3. 选择 Create（创建）。

上传文档：

4. 在 AnyCompany HR 空间内，选择 File uploads（文件上传），然后选择 Upload files（上传文件）。
5. 上传前对每份文档分级。只纳入适合目标受众的文档。
6. 从随附的 GitHub 仓库下载的示例文件中上传以下文档：

employee_feedback_full_dataset.pdf 是有意排除，而不是用权限限制。知识库中的所有文档对任何具有查看者访问权限的人都可查询，因此阻止访问敏感内容的唯一办法是完全不放入。如果人力资源领导层需要这些数据，请另建一个只与 hr-leadership 共享的空间。

下面的截图展示上传文件后的知识库文档列表。

图 2：知识库文档列表。五份文档已上传并完成索引（就绪状态）。第六份文档（employee\_feedback\_full\_dataset.pdf）被有意排除，因为它包含未通过分级复核的个人绩效评价。

把空间共享给组：

空间使用两层模型：所有者（Owner） 可以查看、查询和上传。查看者（Viewer） 只能查看和查询。未被添加的用户没有任何访问权限。

7. 在 AnyCompany HR 空间上选择 Share（共享）。
8. 把每个组分配到相应层级：

下面的截图展示已配置组分配的空间权限面板。

图 3：空间权限面板。hr-leadership 拥有所有者访问权限，dept-managers 拥有查看者访问权限，all-employees 未列出（无访问权限）。

步骤 5：配置三个专用聊天智能体

Amazon Quick 聊天智能体是人工智能（artificial intelligence，AI）助手，它们通过查询所连接的数据集或知识库，用自然语言回答问题，范围由你配置的权限和数据源限定。

要创建每个智能体，在 Amazon Quick 控制台进入 Chat Agents（聊天智能体），然后选择 Create a chat agent（创建聊天智能体）（选择 + Blank（空白））。

高管洞察智能体（完整示例）：

1. 说明（角色提示）： 在说明字段中输入以下角色提示：

_“你是 AnyCompany 的高管分析助手。你只使用部门和地点层级的汇总来回答关于员工趋势的问题。规则：_

• _你可以访问按部门和地点分组的汇总数据。_
• _你可以报告敬业度、满意度、培训时长和员工人数的平均值。_
• _你不能访问员工个人记录、薪资或姓名。_
• _如果被问到某位具体员工，回答：“我只能访问部门层级的汇总。关于员工个人详情，请联系人力资源。”_

2. 选择 Generate（生成）。

图 4：智能体配置界面显示：（1）界定数据边界的角色说明；（2）把访问限制在相应组的共享面板；（3）提示共享此智能体不会自动授予对关联资源的访问权限。每个数据集必须单独共享。

步骤 6：用对抗查询验证智能体边界

在宣布任何智能体可用于生产之前，先测试安全边界是否成立。对每个智能体，打开智能体聊天，以相应的测试用户登录，并提交下列查询。

高管洞察智能体： 以 hr-leadership 用户测试：

经理助手智能体： 以 dept-managers 用户测试（例如一名销售经理）：

员工自助智能体： 以 all-employees 用户测试：

如果智能体返回了超出既定范围的数据，请检查该智能体的数据集列、主题排除项和 RLS 规则。

步骤 7：把智能体共享给正确的组

创建并测试全部三个智能体之后，限制访问，使每个受众只能看到指定给自己的智能体。

1. 打开要共享的智能体并选择 Share（共享）。
2. 分配以下权限：

移除任何把访问权扩大到目标受众之外的默认共享。

每个智能体现在被锁定到这样的组：该组的数据集权限与智能体所连接的数据源一致。部门经理打不开高管洞察智能体，all-employees 用户也无法访问经理助手智能体。

下面的截图展示以 hr-leadership 用户测试高管洞察智能体的结果。

图 5a：高管洞察智能体正确回答“工程部门的平均敬业度是多少？”，并给出按地点分解的表。这能成立，是因为汇总数据集支持该查询。

下面的截图展示智能体拒绝一条员工个人数据查询。

图 5b：当被问到“EMP779251 的薪资是多少？”时，智能体拒绝：“我只能访问部门层级的汇总。”这些数据并不存在于该智能体的数据集中。

下面的截图展示以 all-employees 用户测试员工自助智能体的结果。它根据已上传文档回答政策问题，并拒绝个人数据请求。

图 5c：“我有多少天假期？”智能体从 leave\_policy.pdf 检索出带引用的详细回答，表明知识库已接入。

下面的截图展示智能体连续拒绝多条对抗查询。

图 5d：连续拒绝三条对抗查询：“我的经理薪资是多少？”“有多少名员工？”“我这个岗位的平均薪资是多少？”该数据集只包含汇总。

步骤 8：构建带人工在环控制的流程

流程把多个步骤串起来，并能在继续之前暂停以等待人工复核。创建一个名为“每周离职风险警报”的流程。它识别高离职风险员工并通知其经理，但只在人工复核之后进行。

创建该流程：

1. 在 Amazon Quick 控制台进入 Flows（流程），然后选择 Create Flow（创建流程）。
2. 流程名称： 每周离职风险警报。
3. 流程描述： 输入：

从公司数据中识别高离职风险员工，要求人工批准，并向部门经理发送通知。

4. 连接到空间： 把流程关联到 AnyCompany HR 空间。
5. 配置四个步骤：

6. 发布该流程，并把触发器设为按周计划运行。

下面的截图展示一次测试运行中，流程执行暂停在人工批准步骤。

图 6：包含四个步骤的流程。触发手动测试运行后，流程在步骤 3（人工批准过程）暂停，直到审批人明确批准或拒绝后才会继续。

验证方法：触发一次手动测试运行，确认流程在步骤 3（人工批准）暂停，直到被明确批准。批准之后，确认步骤 4 向 dept-managers 发送通知。

步骤 9：开启 AWS CloudTrail 并核验事件

AWS CloudTrail 会自动记录 Amazon Quick 管理事件（API 调用），无需额外配置。如果账户中有一条活动跟踪，你可以核验智能体查询、数据集访问、流程执行和权限变更是否出现在事件历史中。

在 AWS 控制台中进入 AWS CloudTrail，然后进入你的跟踪，然后编辑，再为 AWS::QuickSight::Dashboard 开启管理事件和数据事件。也可以使用 AWS 命令行界面（AWS Command Line Interface，AWS CLI）的 put-event-selectors 命令，并设置 ReadWriteType: All 以及 Quick 仪表板资源类型。

核验事件是否正在被记录：

1. 在 AWS 控制台进入 AWS CloudTrail，然后进入 Event history（事件历史）。
2. 按 Event source（事件源） 筛选：quicksight.amazonaws.com（Amazon Quick 的服务端点）。
3. 在完成前面步骤中的智能体测试和流程执行之后，确认能看到包括以下内容的事件：
4. 用户身份（谁执行了该操作）
5. 时间戳
6. 事件名称（例如 DescribeDataSet、CreateAnalysis）
7. 资源 ARN

如果没有出现事件，请确认账户至少有一条活动的 AWS CloudTrail 跟踪。更多信息见创建跟踪。

下面的截图展示已记录 Amazon Quick 事件的 AWS CloudTrail 事件历史。

图 7：AWS CloudTrail 事件历史，展示已记录的 Amazon Quick 管理事件

安全如何随采用规模扩展

你可以增加用户、部门和数据集，而不改变底层安全模型。基于组的模型意味着，增加一名新员工是一次组成员变更，而不是一次访问权重新配置。在试点阶段，每个受众一个数据集和一个智能体就够了。当扩展到 50 个或更多团队时，只有在出现真正新的保密边界时，才新增数据集或空间。

治理框架

企业部署需要明确的所有权和复核节奏。下表是一个起点。所有权和复核频率会随团队结构和合规要求而变化。

如何应用该框架：

为每种资产类型指定所有者和复核人，按节奏列安排复核，并对任何例外写出理由并记录。

分阶段推广

下面是一份建议的推广时间表。请按组织规模、合规要求和采用节奏调整时间：

生产就绪检查清单

任何新资产进入生产之前都过一遍。这些是团队中任何人都能核验的布尔检查。

数据集

☐ 数据集限定于单一受众

☐ 敏感列已从数据集中移除，而不是仅仅隐藏

☐ 已应用 RLS，并用至少两个用户账户测试

☐ 权限分配给组，而不是个人

聊天智能体

☐ 智能体只连接一个数据集

☐ 主题排除了不应被查询的列

☐ 当数据集中没有个人记录时，智能体拒绝针对个人记录的查询

☐ 智能体拒绝针对已排除列的查询

空间和知识库

☐ 每份文档在上传前都已分级

☐ 除非该受众确有需要，否则没有任何文档包含个人可识别信息（PII）

☐ 查看、查询和上传权限分别设置

☐ 上传仅限于内容所有者

流程

☐ 流程使用经过 RLS 保护且已裁剪列的数据集

☐ 任何出站动作之前都存在人工批准步骤

☐ 外部凭据存放在 AWS Secrets Manager 中，而不是写在流程定义里

☐ 已开启 AWS CloudTrail，并正在捕获流程事件

清理

为避免持续计费，不再需要时删除这些资源：

• 该流程
• 三个聊天智能体
• 知识库文档
• 人力资源空间
• 三个员工数据集
• RLS 规则数据集
• 这些组
• AWS CloudTrail 跟踪（如果仅为本次演练而创建）

结论

本演练说明了数据集塑形、智能体隔离、文档分级和审批门如何一起在数据层落实安全。数据集塑形和单数据集智能体连接构成基础。流程门在任何数据离开系统之前增加人工复核步骤。文档分级从一开始就把敏感内容挡在共享知识库之外。治理框架和生产检查清单帮助你在部署扩大后维持这些控制。因为安全边界存在于数据集结构中，而不是权限设置中，所以可以增加用户和团队，而无需重新配置访问权。

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/securing-amazon-quick-from-poc-to-production-agents-flows-and-spaces