2. Databricks安全基础对象

理解Databricks的安全与访问控制，第一步不是记住某个权限开关，而是先建立一张“对象地图”：谁承载计算、谁存放代码、谁保存数据、谁负责身份与授权。只有把工作区、集群、笔记本、作业、DBFS、Unity Catalog和元存储之间的边界与依赖关系理清，后续的权限模型、隔离策略和审计路径才有落脚点。

可以把这些对象分成四层来理解：接入与协作层（工作区）、计算层（集群）、开发与调度层（笔记本、作业）、数据与治理层（DBFS、Unity Catalog、元存储）。它们不是并列的七个名词，而是存在明确的“承载”和“引用”关系：工作区是用户进入平台的边界；集群为笔记本和作业提供执行环境；笔记本和作业读取或写入数据；数据位置由DBFS或Unity Catalog管理；而Unity Catalog的权限判断又依赖元存储中的身份、目录和授权记录。

工作区：安全边界的第一道门

工作区是用户登录Databricks后看到的协作空间，也是大多数权限判断的起点。一个账户下可以有多个工作区，例如“生产工作区”和“开发工作区”。工作区级角色通常分为管理员、普通用户和访客。管理员可以管理用户、组、集群策略和Unity Catalog的账户级配置；普通用户可以创建笔记本、集群和作业，但能创建什么、能访问哪些数据，取决于后续的集群策略和Unity Catalog授权。

需要特别注意的是：工作区不是数据隔离的最终边界。如果两个工作区挂载了同一个云存储路径，或者都连接到同一个元存储，那么数据权限必须在Unity Catalog或存储层单独控制，不能假设“换了工作区就看不到数据”。

集群：计算资源与访问模式

集群是笔记本和作业真正执行代码的地方。从安全视角看，集群的关键属性不是配置多高，而是访问模式。单用户集群只允许一个用户或服务主体使用，适合处理敏感数据；共享集群允许多个用户同时使用，但隔离能力较弱；无隔离共享集群则基本不提供用户间隔离，通常只用于非敏感场景。

集群还决定了“谁能在计算层做什么”。例如，一个用户即使拥有某张表的SELECT权限，如果他没有权限在某个集群上运行代码，也无法通过该集群读取数据。因此，集群权限和Unity Catalog权限是两道独立的门，必须同时打开。

笔记本与作业：代码载体与运行身份

笔记本是交互式开发的主要载体，保存代码、注释、可视化结果和版本历史。作业则是把笔记本或JAR、Python脚本按调度计划运行起来。两者在安全上的核心差异是运行身份：笔记本通常以当前登录用户身份执行；作业可以配置为“以创建者身份运行”或“以指定服务主体身份运行”。

这意味着，同一个笔记本在交互式运行时能访问的数据，被包装成作业后不一定还能访问。如果作业使用服务主体运行，就必须把服务主体加入对应的Unity Catalog组，并授予必要的表权限。否则，作业会在运行时抛出权限错误，而不是在保存时提示。

DBFS：工作区文件系统与挂载点

DBFS是Databricks工作区内的文件系统抽象，用户可以通过/FileStore、/databricks-results等路径访问文件，也可以把云存储桶挂载到DBFS路径下。DBFS的权限模型相对简单，主要依赖工作区级权限和挂载点的访问控制。

在启用Unity Catalog后，推荐的做法是：不要把敏感数据长期放在DBFS根路径或挂载点下，而是通过Unity Catalog的外部位置和卷来管理。DBFS更适合存放临时文件、日志和结果输出。如果必须使用挂载点，应确保挂载点背后的云存储权限与Unity Catalog授权一致，避免出现“DBFS能读、UC不能读”或反过来的混乱局面。

Unity Catalog与元存储：统一治理的核心

Unity Catalog是Databricks的统一数据治理层，它用三级命名空间组织数据对象：catalog.schema.table。例如prod.sales.orders表示生产目录下sales模式中的orders表。权限可以授予目录、模式、表、视图、函数和卷等对象，并且支持继承：授予目录的权限会向下传递到模式和表。

元存储是Unity Catalog的账户级容器，保存目录、模式、表、视图、函数、卷以及用户、组、服务主体和授权记录。一个账户通常有一个元存储，可以关联多个工作区。元存储决定了“哪些身份在哪些工作区中能看到哪些数据对象”。如果元存储没有正确关联工作区，或者用户没有被同步到元存储中，就会出现“工作区里看不到目录”的问题。

一个可复现的权限判断示例

假设用户alice@example.com需要在一个共享集群上运行笔记本，读取prod.sales.orders表。管理员需要完成以下配置：

1. 把alice加入Unity Catalog中的sales_readers组。
2. 授予sales_readers组对prod.sales模式的USE SCHEMA权限，以及对prod.sales.orders表的SELECT权限。
3. 确保alice有权限使用目标集群，或者集群策略允许她创建单用户集群。
4. 如果该笔记本被包装成作业，确认作业运行身份是alice本人，或者把作业的服务主体也加入sales_readers组。

配置完成后，alice在笔记本中执行SELECT * FROM prod.sales.orders LIMIT 10;应当成功返回数据。如果返回“TABLE_OR_VIEW_NOT_FOUND”或“PERMISSION_DENIED”，应依次检查：元存储是否关联当前工作区、组是否同步、模式权限是否授予、表权限是否授予、集群是否可访问。这个排查顺序，正是这些基础对象之间依赖关系的直接体现。

把这些对象的关系理顺后，后续学习权限模型、行级过滤、列级掩码和审计日志时，就能清楚知道每项控制措施作用在哪一层、影响哪些对象、以及出现问题时应该从哪个对象开始排查。