Amazon Quick 的会话记录不等于审计日志、数据连接也不等于权限边界

文章导读
在 Amazon Quick 里能翻到一段会话记录,不代表这段记录可以直接当审计凭证;把某个数据源接进来,也不代表谁能看到哪一行数据已经定好了。会话留存、数据连接、权限归属分属三层配置,通常由不同角色维护,改动后的生效方式和验证方式也不一样。比较稳妥的做法是:先把三件事分别确认清楚,再用一次跨部门的真实提问去验证,最后落到一张 IT 与业务都能看懂的分工表上。
📋 目录
  1. 壹 在管理端分别找到会话留存与数据连接的开关位置
  2. 贰 把权限归属拆成身份源与资源两侧
  3. 叁 用一次跨部门提问验证边界
  4. 肆 整理成给 IT 与业务的分工表
A A

在 Amazon Quick 里能翻到一段会话记录,不代表这段记录可以直接当审计凭证;把某个数据源接进来,也不代表谁能看到哪一行数据已经定好了。会话留存、数据连接、权限归属分属三层配置,通常由不同角色维护,改动后的生效方式和验证方式也不一样。比较稳妥的做法是:先把三件事分别确认清楚,再用一次跨部门的真实提问去验证,最后落到一张 IT 与业务都能看懂的分工表上。

适用场景:Quick 已经接入多个数据源并开放给多个部门使用。操作动作:在管理端分别核对会话留存策略、数据连接清单、身份源与资源侧共享范围,不要用会话记录代替审计日志。验证方式:安排一名只属于单一组的业务同事,提一个跨组问题,记录预期可见范围与实际返回结果。风险边界:留存策略变更通常不追溯历史会话,连接与权限调整也可能存在生效延迟,需要结合环境确认后再对外承诺。

在管理端分别找到会话留存与数据连接的开关位置

这两件事在管理端通常不在同一处,也不控制同一层行为。会话留存管的是“对话内容留多久、谁能看、能不能导出”;数据连接管的是“Quick 能读到哪些库表、用哪套凭据去读”。把其中一个开关当成另一个,是后面审计和权限判断出错的常见起点。

  • 会话留存:影响会话正文、附件引用、检索与导出能力,以及到期清理行为。它决定你事后能拿到什么材料,但通常不包含“谁在何时改了哪条权限、谁通过了哪次身份校验”这类完整事件。
  • 数据连接:影响可查询的数据源、库表范围和连接使用的账号或角色。它决定数据能不能进来,不决定某个登录用户在 Quick 里能看到哪些行。
  • 改动后多久生效:留存策略调整通常从新产生的会话开始按新策略处理,历史会话是否被一并清理要看具体配置;数据连接的新增、停用或凭据轮换,一般在后续请求重新建立连接后生效,可能受会话保持或缓存影响。建议改动后用一次新会话或新查询去验证,不要假设立即全量生效。

确认位置时,可以同时在管理端页面和云平台日志服务里各看一遍:页面告诉你功能开没开,日志告诉你动作有没有被记下。两边对不上时,先别对外说“已经可审计”,也不必急着改配置,先把差异记下来找平台负责人确认。

把权限归属拆成身份源与资源两侧

只改身份源或只改资源侧共享,都容易出现“看起来收紧了,实际没收紧”的情况。这两侧要分别确认。

Amazon Quick 的会话记录不等于审计日志、数据连接也不等于权限边界
  • 身份源侧要确认:账号从哪里来(IAM Identity Center、外部 IdP 同步,还是本地用户),组关系如何映射到 Quick 的组或角色,成员停用、离职或换组后的同步延迟如何。重点看账号归属和组关系,而不是只看邮箱是否存在。
  • 资源侧要确认:数据集、主题、仪表板、文件夹的共享范围,行级与列级安全规则,以及数据源凭据是共享还是按用户传递。重点看资源可见范围,而不是只看数据连接是否成功。

这里有一组最容易被混用的概念:数据连接不等于权限边界。如果数据连接使用共享凭据,那么权限边界实际落在数据集共享和行级规则上,连接本身不构成边界;如果按用户传递凭据,边界才可能部分由底层数据源承担。确认时先问一句“这次查询用的是谁的身份”,再决定去查哪一侧。另一组容易混用的是会话记录与审计日志:前者偏向业务对话内容,后者偏向可检索的事件流水,两者可以互补,但通常不能互相替代。

用一次跨部门提问验证边界

前面的判断是否成立,用一次可复现的提问来检验即可。选一个只在单组、且不在数据 Owner 组里的账号,让这名同事在 Quick 里问一个跨部门的问题。提问内容可以同时包含本组范围内和明确越界的两个部分,便于观察返回结果的边界。

Amazon Quick 的会话记录不等于审计日志、数据连接也不等于权限边界
提问内容                 | 预期可见范围                                   | 实际结果
-------------------------|------------------------------------------------|------------------------------
请给出上个季度华东区销售明细 | 仅返回该同事所属组对应的区域数据,跨区行应为空或被拒 | 记录返回、部分返回或拒绝,附时间与账号
请给出其他部门的项目预算表   | 无权限,应被拒绝或返回空结果                       | 记录实际返回内容与提示信息

记录实际结果时,建议请数据平台在后台查看这次查询实际使用的身份,而不是只看页面提示。如果实际结果比预期宽,先查资源侧的共享范围和行级规则,再查身份源的组关系与账号状态;如果实际结果比预期窄,先确认账号是否在正确的组里,再看数据集是否已刷新权限。每次权限或连接变更后,重跑这一组提问即可作为回归验证。

整理成给 IT 与业务的分工表

把前面的确认结果写成一张表,后续沟通就不容易再混用概念。每一行都写清事项、负责方和确认方式,确认方式尽量落到页面、日志或一次可复现操作上。

事项负责方确认方式
会话留存周期与导出权限IT 或平台管理员,安全与法务参与确认在管理端核对留存策略,并实际导出一次小样本,确认导出的字段与范围
审计事件留存与检索安全或云平台团队在日志服务里按时间窗检索一次权限变更或会话相关事件,确认可检索字段
数据连接清单与凭据归属数据平台或 IT逐条列出连接及其使用的凭据主体,标注是共享凭据还是按用户传递
身份源账号归属与组关系IT 身份团队抽样核对账号来源与状态,并抽查一次加组、移组后的可见范围变化
资源可见范围与行级规则数据 Owner 或业务负责人用测试账号打开数据集与仪表板,记录可见项、不可见项及被拒提示
跨部门提问回归业务方与数据平台共同执行每次权限或连接变更后重跑一次跨部门提问,按三栏模板记录结果

分工表不用一次写全,先覆盖会话留存、数据连接、权限归属各一行,把负责方和确认方式填上,再按实际环境补充细节。之后每次有人问“这个记录能不能当审计用”或“接上数据源是不是就安全了”,直接回到表中对应行确认即可。