Snowflake RBAC Explorer：看清权限链

现在是周五下午 4:55。有人问：“谁能看到 payroll 表？”于是你打开 Snowflake：

• 打开一个工作表，输入 SHOW GRANTS
• 然后再 SHOW GRANTS
• 然后再来一次

一路查了四层角色，直到你都不确定自己到底有没有被问过问题。

与此同时，一个新用户已被悄悄授予 ACCOUNTADMIN，而新的 AI agent 对你自己能用，对你分享给的人却不能用。

Snowflake RBAC Explorer 是我构建的工具，让你的周五在 5 点结束。请继续阅读。

TL;DR： RBAC Explorer 是一个 Streamlit in Snowflake 应用，面向分配访问权限的人。它显示谁能访问什么（以及通过哪条链路），在你撤销之前告诉你谁会受影响，当有人授予了不该授予的角色时在一两分钟内提醒你，用平实的英语回答问题，并准确算出 AI agent 需要哪些授权。它免费、开源，并且完全运行在你的 Snowflake 账户内。额外亮点：它有一个精心打造、响应迅速的前端，用 React 连接而成！

本文的组织方式：

1. 先是问题，然后快速游览。
2. 深入介绍 AI assets、Alerts 和 Ask。
3. 设置、安全和已知限制在最后。

三个问题，毫无乐趣

“Priya 能读取 SALES 吗？” 听起来是个是非题。实际上却是一场寻宝游戏：她的授权，然后是她的角色们的授权，然后是那些角色们的授权，然后还得快速检查一下途中是否有人记得对数据库和 schema 的 USAGE。再乘上几百个角色，你就有了一个没人要求的爱好。

“如果昨晚有人获得了 ACCOUNTADMIN，我们会知道吗？”最终会知道。ACCOUNT_USAGE 最多可能延迟两个小时，这足够一个“新朋友”把自己安顿下来了。

“为什么 Hana 的 agent 对 Hana 能用，对别人都不行？” 因为一个 agent 是一叠对象，Hana 持有能看到所有这些对象的角色，而其他人需要的授权清单根本没有被写下来。

以前没人画过角色图吗？

有人画过，而且很好。Snowsight 在 Admin > Users & Roles 下有一个，社区还构建了 Grant Report、一个 Streamlit 图表 等等。

RBAC Explorer 站在他们的肩膀上，加入了那些我一直希望有的东西：答案而不只是图片、几分钟内的提醒、平实的英语问题、AI agent 访问，而且无需托管任何东西。

游览

AI assets

帮你免于：猜测一个 agent 需要什么。

一个 agent 依赖的每一项授权、谁已准备好使用它，以及针对任何尚未准备好的人的修复方案。

访问权限的叠叠乐高塔

共享一张表是一个授权加一些 USAGE。共享一个 agent 则是一座高塔：

skill ──> agent ──> semantic view ──> tables
                └─> custom tool ──> whatever it reads
                └─> warehouse

三条平台规则让它摇摇欲坠：

1. Agent 以调用者的默认角色和仓库运行，而不是他们切换到的任何角色（文档）。
2. 缺少工具授权不会失败。 默认情况下，agent 只是在没有该工具的情况下作答。答案更差，没有报错，大量令人困惑的 Slack 讨论串。
3. 路径很重要。 查询一个语义视图需要对该视图的 SELECT 权限。agent 的 Cortex Analyst 工具会访问底层的表（文档）。

选择一个 agent、语义视图、工具或技能（粘贴一个 SKILL.md，它会解析其中的每个名称），然后选择一个人或团队。应用会检查他们的默认角色、他们的所有角色，以及 MCP 客户端可能使用的每个访问令牌，并给出 Ready、Partly works 或 Blocked，并列出每一项缺失的授权。

修复方案是为每个资产设一个整洁的访问角色：

CREATE ROLE IF NOT EXISTS AR_DEMO_SALES_AGENT;
GRANT USAGE ON AGENT DEMO_SALES_DB.CORE.DEMO_SALES_AGENT TO ROLE AR_DEMO_SALES_AGENT;
GRANT SELECT ON SEMANTIC VIEW DEMO_SALES_DB.CORE.DEMO_SALES_SV TO ROLE AR_DEMO_SALES_AGENT;
GRANT SELECT ON TABLE DEMO_SALES_DB.CORE.ORDERS TO ROLE AR_DEMO_SALES_AGENT;
-- ... procedure, warehouse, database, schema, CUSTOMERS
GRANT ROLE AR_DEMO_SALES_AGENT TO ROLE DEMO_SALES_TEAM_ROLE;

复制它，或打开 Apply（默认关闭），它只运行你审核过的内容，拒绝系统和受保护角色，记录一切并提供 Revert。在演示中，它让一位队友从 10 项授权中的 5 项提升到 9 项。第十项是缺少默认仓库，任何授权都无法修复，所以你会得到 ALTER USER 语句。用户也可以通过 SQL 或 Cortex Code 技能请求捆绑包，直接进入应用中的队列。

Alerts

帮你免于：从审计员那里才知道。

规则、日志和一个每分钟检查一次的监视器。

一个不打盹的监视器

两小时的延迟对仪表盘来说没问题，对烟雾探测器来说却很糟糕，所以监视器跳过 ACCOUNT_USAGE，直接询问 Snowflake：

every minute ──> serverless task ──> CALL CHECK_PROTECTED_ROLES()
                   live SHOW GRANTS / SHOW USERS / SHOW ROLES
                   ├─ new violation  ──> ALERT_LOG (OPEN) ──> email / Slack
                   └─ violation gone ──> ALERT_LOG (RESOLVED)

一条 protected-role 规则规定谁可以持有某个角色（“这两个人、这些父角色，仅此而已”）。父角色检查很重要：把一个角色授予 ACCOUNTADMIN，你就等于把它授予了该角色中的所有用户，一下子多了很多新朋友。自定义提醒能捕获新的持有者、MANAGE GRANTS 等敏感权限、命名可疑的新用户，以及悄悄失去对某物访问权限的 AI agent。

每个提醒都附带链路、授予角色和一个可直接运行的修复方案。确切的用户和语句会在 QUERY_HISTORY 跟上后从中填充。自动撤销是按规则选择启用的，默认关闭。

日志就是一张表，所以你的 SIEM 只需一次查询：

SELECT detected_at, kind, role_name, grantee, reason, granted_by_user, status
FROM RBAC_EXPLORER_DB.ALERTS.ALERT_LOG ORDER BY detected_at DESC LIMIT 50;

Ask

帮你免于：编写 SQL 来回答一个问题。

一个平实英语助手，位于每个标签页旁边，基于你正在查看的同一份授权数据作答。

用平实英语说： 假设你在 Revoke what-if 中，想知道一次清理是否安全。问 “如果我从 REPORTING 撤销 ANALYST，会破坏什么？” 它会列出失去访问权限的用户及其失去的权限，与你在暂存后该标签页会给出的答案相同。

没有模型会针对你的账户编写 SQL。应用把已经加载的那部分授权数据连同屏幕上的内容一起交给 AI_COMPLETE，因此答案与图一致。Ask 也可以用一句话起草提醒（“如果有新的人获得 ACCOUNTADMIN 就告诉我”），供你在保存前检查。

Ask 需要你所在区域有 Cortex 模型。在依赖它之前，请查看 Cortex AI 区域可用性；应用中的其他一切无需它也能工作。

底层实现

RBAC 问题是图问题，每次点击一次查询会慢得让人痛苦。所以应用从 ACCOUNT_USAGE 一次性加载模型（再加上系统角色的实时 SHOW 输出），缓存 30 分钟，并在浏览器中进行图计算。

点击是即时的。UI 是 React，用 esbuild 打包，并通过 st.html 在 Streamlit 的 容器运行时 上渲染。

关于安全的细则

• 仅限管理员。该应用以其所有者身份运行，所有者拥有 MANAGE GRANTS，因此任何打开它的人都能看到所有 RBAC 元数据。请把它授予访问管理员，而不是全公司。
• 除此之外的最小权限：SECURITY_VIEWER、GOVERNANCE_VIEWER、CORTEX_USER 和任务权限。
• 除非你明确要求，否则不会有任何变化。只有开启 Apply 或自动撤销时，授权才会变动。
• 仅限元数据。它从不读取你的表数据。

试一试

在 ACCOUNTADMIN 上，只需把 Cortex Code 指向仓库 https://github.com/sfc-gh-vshiv/snowflake-rbac-explorer 并让它部署到你的 Snowflake 账户中。

GitHub - sfc-gh-vshiv/a-better-snowflake-rbac-explorer

或者

如果你想真正亲自动手（你需要 Snowflake CLI）：

git clone https://github.com/sfc-gh-vshiv/snowflake-rbac-explorer.git
cd snowflake-rbac-explorer
snow sql -c <connection> -f setup/setup.sql \
  -D admin_user=<YOUR_USER> -D warehouse=<WH> -D alert_email=<[email protected]>
snow sql -c <connection> -f setup/alerts.sql -D warehouse=<WH>
snow sql -c <connection> -f setup/access.sql -D warehouse=<WH> -D requester_role=<ROLE_THAT_CAN_REQUEST>
RX_WAREHOUSE=<WH> bash deploy/deploy.sh <connection>

以 RBAC_EXPLORER_ROLE 身份打开 Projects > Streamlit > Role Explorer。setup/demo_seed.sql 提供了一个可触发的告警，setup/demo_access_seed.sql 构建演示代理，setup/uninstall.sql 负责清理（你已应用的任何 AR_* 角色都会保留，因为可能有人正在使用它们）。

在你离开之前

已知限制，以免让你措手不及：

• 图最多可能滞后两小时。实时检查：监视器和人员检查始终是最新的。
• 未来授权未被建模，而且任何拥有 ACCOUNTADMIN 或 MANAGE GRANTS 的人仍然可以给自己授予更多权限。没有应用能解决这一点；只有组织架构图能做到。
• MCP 服务器工具尚未被遍历，并且应用的角色需要对代理拥有 MONITOR 才能描述它们。
• 监视器每分钟运行一次，因此在其恢复运行期间会消耗无服务器计算积分。

这是一个示例应用，按原样提供，不包含 Snowflake 官方支持。

安装前请阅读代码及其请求的权限。欢迎提交问题和拉取请求。

现在去享受你的周五 🍻。

“谁有权访问这个？”最初发表于 Snowflake Builders Blog: Data Engineers, App Developers, AI, & Data Science（发布于 Medium），人们正在那里通过高亮并回应这个故事来继续对话。