2. Databricks安全架构基础

在 Databricks 中谈“安全”，不能只盯着某一个开关或某一张权限表。真正决定一次数据访问是否被允许的，是四个层面共同作用的结果：工作区（Workspace）负责用户与协作边界，Unity Catalog负责数据对象与权限边界，计算资源（Compute）负责执行身份与运行边界，存储层（Cloud Storage）负责数据落地的物理边界。理解这四层各自的职责以及它们之间的衔接方式，是掌握 Databricks 身份、权限与审计模型的前提。

四层安全边界的分工

可以把一次数据访问想象成“一个人，用一台机器，去取一份数据”。这四个动作分别对应四个边界：

• 工作区：解决“谁可以进入这个协作环境”。用户通过身份提供商（如 Azure Entra ID、Okta）登录后进入工作区，工作区管理员可以控制成员、集群策略、笔记本与作业的可见范围。但工作区本身不决定用户能读哪张表。
• Unity Catalog：解决“谁能对哪个数据对象做什么操作”。它以三层命名空间 catalog.schema.table 组织数据与 AI 资产，并通过 GRANT 语句把权限授予用户、组或服务主体。
• 计算资源：解决“以什么身份、在什么隔离环境下执行”。计算分为通用集群、作业集群、SQL 仓库、模型服务等，它们决定了代码运行的位置、可用的库、以及访问凭据的注入方式。
• 存储层：解决“数据物理上放在哪里、由谁托管”。数据通常存放在云对象存储（如 ADLS Gen2、S3、GCS）中，Unity Catalog 通过存储凭据（Storage Credential）和外部位置（External Location）来管理对存储路径的访问。

这四层不是并列的四个独立系统，而是层层递进、缺一不可的链路：用户先通过工作区身份进入，再由计算资源承载执行，由 Unity Catalog 判定权限，最终由存储凭据完成对物理数据的读取。任何一层缺失或配置错误，访问都会失败。

身份、权限与审计的基本模型

Databricks 的身份模型有三个主体：用户（User）、组（Group）、服务主体（Service Principal）。用户代表自然人，服务主体代表自动化程序或应用，组则是权限授予的主要载体。最佳实践是把权限授予组，而不是直接授予个人，这样人员变动时只需调整组成员关系，无需逐个修改数据权限。

权限模型的核心是 Unity Catalog 的三层命名空间与继承关系。权限从上层向下层继承：对 catalog 授予 USE CATALOG 后，用户才能看到该 catalog 下的 schema；对 schema 授予 USE SCHEMA 后，才能访问其中的表。而 SELECT、MODIFY 等数据操作权限则需要在具体对象上单独授予。这种设计让权限管理既灵活又可控。

审计模型则回答“谁在什么时候对什么做了什么”。Databricks 提供三类审计来源：审计日志（Audit Logs）记录 API 调用与访问事件，Unity Catalog 审计记录数据对象的授权与访问，云平台审计（如 Azure Activity Log）记录存储与网络层面的操作。三者结合，才能形成完整的追溯链。

一个具体的访问判定示例

假设分析师 Alice 需要查询 sales.prod.orders 表。她通过 Entra ID 登录工作区，使用一个共享集群运行 SQL。系统会依次进行以下判定：

1. 工作区身份校验：Alice 的账号是否属于该工作区？她的组是否被允许使用该集群？
2. 计算资源校验：该集群的访问模式是否允许 Alice 执行查询？集群策略是否限制了她的操作？
3. Unity Catalog 权限校验：Alice 是否对 sales 有 USE CATALOG、对 prod 有 USE SCHEMA、对 orders 有 SELECT？
4. 存储层校验：Unity Catalog 使用的存储凭据是否有权读取该表对应的 ADLS 路径？

只有四步全部通过，查询才会返回结果。如果 Alice 缺少 SELECT 权限，她会在第三步被拒绝；如果存储凭据配置错误，她会在第四步看到存储访问错误。理解这个顺序，有助于在排障时快速定位问题出在哪一层。

安全边界的关键配置要点

需要特别强调的是，Unity Catalog 是权限判定的中心，但它并不替代工作区和存储层的安全控制。工作区决定了“谁能进来”，存储层决定了“数据放在哪、由谁托管”，而 Unity Catalog 决定了“进来之后能碰什么”。三者配合，才能构成 Databricks 完整的安全架构。