1. 课程导入与安全全景

在传统数据平台中，安全边界通常由网络分区、数据库账号和表级授权构成，边界清晰、对象稳定。但当企业把数据、模型、向量索引、特征表、Notebook、作业与 Agent 应用统一放到 Databricks 上，并让大模型参与数据读取、推理与生成时，安全模型会发生一次结构性变化：访问主体从"人"扩展到"人 + 服务主体 + 模型 + 应用"；访问对象从"表"扩展到"表 + 文件 + 函数 + 模型 + 向量索引 + 特征"；访问路径从"SQL 查询"扩展到"Notebook、作业、Serving 端点、Agent 工具调用"。本章的目标不是立刻配置权限，而是先建立一张完整的"安全地图"，让后续每一章的权限配置、审计与治理动作都能落到这张地图的确定位置上。

一、Databricks AI 数据安全的核心挑战

可以把风险归纳为四类，它们分别对应不同的控制点，而不是同一类问题的不同说法。

第一类是身份与凭证扩散。一个 RAG 应用往往同时涉及：终端用户身份、Serving 端点的服务主体、访问 Unity Catalog 的凭证、访问外部模型 API 的密钥。如果这些身份没有统一纳管，就会出现"应用能读到的数据，用户本不该看到"的越权读取。典型表现是：Notebook 里用个人 PAT 跑通了查询，上线后换成服务主体却报 PERMISSION_DENIED，或者反过来，服务主体权限过大导致任何调用者都能间接读到敏感表。

第二类是数据与 AI 资产的权限粒度不匹配。Unity Catalog 的权限模型是 Catalog → Schema → Table/View/Function/Model/Volume 的层级继承。AI 场景中常见的对象是向量索引、特征表、模型版本、外部位置（External Location）和存储凭证（Storage Credential）。如果只在表级授权，而向量索引或模型注册表未同步授权，就会出现"表锁住了、索引却泄露了"的缝隙。

第三类是数据在推理链路中的二次暴露。当用户向 Agent 提问时，检索到的行级数据会进入提示词、进入模型上下文、可能被写入推理日志或对话历史表。这意味着行级与列级过滤必须在检索阶段生效，而不是在结果返回后补救。行过滤器（Row Filter）、列掩码（Column Mask）和动态视图是这一层的核心工具。

第四类是可观测性与合规证据不足。审计要求回答"谁在什么时候、通过哪条路径、读到了哪些数据"。Databricks 的审计日志、系统表（system.access.audit、system.access.table_lineage）和 Unity Catalog 血缘是回答这个问题的依据。若未提前开启并规划保留策略，事后无法重建证据链。

二、访问控制的基本概念

Databricks 的访问控制由三层叠加而成，理解它们的先后顺序比记住具体权限名更重要。

• 身份层（Identity）：账户级用户、组、服务主体（Service Principal）。组是权限管理的主要载体，建议按"职能 + 数据域"建组，而不是按个人授权。
• 授权层（Authorization）：Unity Catalog 的 GRANT/REVOKE，权限沿 Catalog → Schema → 对象继承；同时支持行过滤器、列掩码、动态视图做细粒度控制。
• 凭证层（Credential）：Storage Credential 与 External Location 决定"能不能访问云存储路径"，与"能不能读表"是两件独立的事，二者都通过才算真正可访问。

一个必须记住的判断顺序是：先看身份是否被识别，再看对象权限是否授予，最后看底层存储凭证是否放行。排障时按这个顺序逐层排除，比盲目改权限高效得多。

三、课程学习路径与实战环境准备

本课程按"认知 → 配置 → 细粒度 → AI 专项 → 审计与治理"推进：先建立安全全景（本章），再掌握 Unity Catalog 的层级授权与组管理，随后进入行级/列级过滤与动态视图，接着覆盖模型、向量索引、Serving 端点与 Agent 工具的权限设计，最后用系统表与审计日志完成可观测性与合规验证。

实战环境建议准备一个 Databricks 工作区，并确认以下前置条件：已启用 Unity Catalog 的 Metastore；拥有一个可用于实验的 Catalog（示例中命名为 ai_sec_lab）；具备创建组与服务主体的账户管理员权限；已开启审计日志并可通过 system.access.audit 查询。下面的示例用于验证环境是否就绪，参数为教学示例，请按实际环境替换。

-- 示例：确认当前身份与可用 Catalog（教学示例，非实测结果）
SELECT current_user() AS whoami;

SHOW CATALOGS;

-- 示例：查看某张表的授权情况
SHOW GRANTS ON TABLE ai_sec_lab.sales.orders;

-- 示例：确认审计日志可查（需已开启系统表访问）
SELECT service_name, action_name, event_time
FROM system.access.audit
WHERE action_name = 'getTable'
ORDER BY event_time DESC
LIMIT 10;

判断环境是否就绪的依据是：SHOW CATALOGS 能列出目标 Catalog；SHOW GRANTS 能返回授权记录而非报错；审计查询能返回近期事件。若审计查询为空，先检查系统表权限与日志开启状态，再继续后续章节。