Databricks发布AI/BI仪表板嵌入安全模式：统一权限表实现多租户数据隔离
Databricks发布参考设计，通过统一授权表、签名外部值和Unity Catalog行过滤，实现外部合作伙伴与内部团队在同一仪表板上的数据隔离。
AI解读：Databricks发布了一个参考设计，解决AI/BI仪表板嵌入到客户应用后，不同用户看到不同数据子集的授权问题。核心是将权限规则集中在一张授权表中，通过后端签发的令牌携带用户作用域，配合视图过滤和Unity Catalog行过滤，实现每行数据按查看者隔离。
这套方案的关键在于把外部合作伙伴（无Databricks账号）和内部员工（通过IdP组同步）统一到同一种权限模型里。内部员工通过身份提供商组（如Okta）自动获得权限，无需手动维护用户列表；外部合作伙伴则在登录时分配固定合作伙伴ID。所有规则都存放在一张表中，便于审计和修改。
实际部署时需注意几个限制：令牌有效期仅 1 小时，需要应用刷新；external_value和external_viewer_id合计须小于 1 KB；每个工作区外部嵌入的仪表板加载速率限制为每秒 20 次；下载功能默认开启，可能泄露数据。这些都需要在规划时考虑。
对需要将仪表板嵌入门户并服务多个客户的组织，这套模式提供了现成的实现路径，避免了为每个客户复制仪表板导致的数据漂移问题。但若是纯内部使用场景，则无需采用此复杂方案，基础的Unity Catalog行级安全可能就足够了。
Databricks发布了一份参考设计指南，解决AI/BI仪表板嵌入客户应用后的授权难题：如何在多租户或多部门场景下，让不同查看者只能看到自己有权访问的数据行，并隐藏敏感字段。该指南以共享的“开放应收账款任务”仪表板为例，覆盖美国西部、东部和中部三个区域，服务外部运营合作伙伴（如Acme Ops、Bolt Partners）和内部团队（如财务部、区域运营团队）共五类查看者。核心是统一授权表、签名令牌和Unity Catalog行过滤的组合使用。
核心设计：统一授权表与两种执行路径
该模式以一张授权表（entitlements table）作为访问控制的唯一事实来源，表中每一行记录某个查看者作用域（viewer_scope）能访问的区域以及是否需要屏蔽联系邮箱等敏感信息。viewer_scope列同时存储外部合作伙伴ID（如partner_acme）和内部组名（如finance_all），因此同一行过滤逻辑可以同时覆盖两种受众。
授权表通过安全视图与基础表（open_ar_tasks）连接，视图按查看者作用域过滤数据行，并根据mask_pii标志决定是否屏蔽email列。基础表结构包含task_id、market、operating_partner、amount_open、contact_email等字段，示例数据为三个区域各一条记录。
该模式区分两种访问路径：外部合作伙伴通过嵌入的仪表板访问，内部员工直接通过Databricks SQL查询。两条路径共用同一张授权表，但执行机制不同。
- 嵌入路径：后端用服务主体签发令牌，携带外部查看者ID（external_viewer_id，用于审计）和作用域值（external_value，代表查看者作用域），该值在仪表板SQL中作为 __aibi_external_value暴露，查看者无法修改。查询以发布身份（通常是服务主体）运行，而非查看者的Databricks身份，因此行过滤依赖授权的 __aibi_external_value和视图。
- 直接SQL路径：Databricks用户在工作区直接查询基础表时，Unity Catalog行过滤基于调用者的身份和组（通过is_account_group_member() 检查）来限制访问，可合并该用户的多个组权限。发布身份（current_user()）在函数中作为例外，仅用于仪表板发布或刷新，属于高风险的可选操作，需按部署审批。
组管理：身份提供商组同步与失效关闭
组织通常通过从身份提供商（如Okta或Entra ID）同步的组来管理访问权限。当员工加入财务组时，其访问权限自动映射为finance_all（对应所有区域），无需手动修改授权表。授权表通常由上游授权系统或应用拥有的组到区域映射填充，而非逐查看者手工编辑。
在嵌入路径中，由于查询以服务主体身份运行，is_account_group_member() 无法识别实际查看者，因此应用必须在后端解析查看者所属组，再签发令牌。方案建议：若应用部署在Databricks Apps并启用用户授权，可通过用户自己的OBO（on-behalf-of）令牌调用SCIM /Me接口读取其组，无需服务主体管理员权限。但该功能仍在完善中，需在生产环境验证。
如果后端找不到查看者任何有权限的组，则拒绝签发令牌（fail closed），而非回退到更宽泛的身份。若查看者属于多个组，需确定优先级顺序或映射为单一作用域，保证访问一致。
- 外部合作伙伴无Databricks账号，其作用域固定为合作伙伴ID，登录时直接分配，无需额外查询。
- 令牌的一个限制是只携带单个external_value，对于一个角色对应一个人的常见场景足够；如需合并多个组权限，应使用全访问组或直接SQL路径（该路径的行过滤可以用OR跨多个组）。
加固措施：默认拒绝与掩码
指南强调分层加固。除行过滤外，敏感列掩码：mask_pii标志为true时（例如合作伙伴），视图中的CASE表达式将邮箱显示为类似 ****@example.com；为false时（内部组）显示完整邮箱。复杂掩码规则建议使用Unity Catalog列掩码和ABAC。
默认拒绝行为通过未知作用域实现：如果external_value是令牌中未签名的值（即查看者修改了令牌），则匹配不到授权行，仪表板返回空结果，不提示任何结构错误。更早在后端签发令牌前检查授权表，拒绝零行的作用域，并记录签发和拒绝日志，便于审计。令牌中的external_viewer_id应使用非个人身份信息（如客户ID），因为它会被写入日志。
- 下载功能默认开启：嵌入的查看者可导出CSV、TSV、Excel、PNG，除非工作区管理员关闭。发布前需确认导出内容与所看到的数据一致。
- Unity Catalog行过滤和掩码使用账户级组（account-level groups），而非工作区本地组；嵌入路径不调用该函数。
- 令牌寿命和负载限制：令牌有效期 1 小时，应用需通过客户端SDK的getNewToken回调在到期前刷新；external_viewer_id和external_value合计须小于 1 KB，避免使用JSON或长邮箱。
适用场景与前置条件
该模式的适用场景为：需要将同一仪表板共享给无Databricks账号的外部合作伙伴和内部员工。若所有查看者都是内部Databricks用户，则基础嵌入配合Unity Catalog行和列安全可能已足够。
指南强调安全模式建立在多个Databricks功能的组合上，包括 __aibi_external_value、Unity Catalog行过滤和列掩码、从身份提供商同步的组，是一个设计模式而非单一功能开关。
文档列出了实际限制：嵌入加载速率每个工作区每秒 20 次，大型B2B门户需规划；授权表可能包含数千个作用域，需保持联表逻辑简洁，规则复杂时建议使用ABAC。
- 指南建议先从基础嵌入教程开始，再应用本文的授权、掩码和默认拒绝模式，具体功能限制需对照当前官方文档验证。