技术治理

在单体数据库环境中，安全性是集中的。数据库引擎同时控制磁盘存储和查询执行。当执行 GRANT SELECT 语句时，引擎会强制执行该规则，因为它是数据的唯一通道。数据湖架构因计算和存储的分离而带来治理难题。现在需要保护两个不同的层：物理对象存储（S3、GCS、Azure Blob）和逻辑元数据层（Hive Metastore、Glue、Unity Catalog）。

数据湖中的技术治理是实施控制以在这些层之间同步访问的方法。如果没有这种同步，你就有产生安全漏洞的风险，用户可能通过SQL被拒绝访问，但仍可以直接从存储桶下载原始Parquet文件。

双层安全模式

为确保数据湖安全，你必须在两个检查点管理权限。

1. 粗粒度存储访问： 这发生在存储桶或前缀级别。它决定了哪些身份（用户或服务角色）可以物理读取字节。
2. 细粒度逻辑访问： 这发生在目录级别。它决定了用户可以通过计算引擎查询哪些表、列和行。

如果你仅仅依赖存储权限，就会缺少细致性。你无法使用标准S3 IAM策略授予“仅email列”的访问权限，因为对象存储将文件视为一个单一原子单元。反之，如果你仅仅依赖目录权限，熟悉情况的用户如果底层存储桶策略过于宽松，可能会绕过查询引擎并访问原始数据。

下图展现了用户提交查询时的授权流程。

授权流程需要在逻辑元数据层和物理基础设施层进行验证。

基于角色的访问控制 (RBAC)

基于角色的访问控制 (RBAC) 是管理逻辑权限的标准做法。并非将权限分配给单个用户，而是你定义角色，例如 data_engineer、analyst 或 auditor，并将用户分配给这些角色。

在现代数据湖中，RBAC通常在目录中实现。当用户尝试访问表时，目录会检查其当前角色是否拥有所需权限。

例如，analyst 角色可能有权限从 silver 数据库读取，但不能从 gold 数据库读取。

-- 在逻辑目录中定义RBAC的例子
CREATE ROLE data_analyst;

-- 授予逻辑容器（数据库/模式）的使用权限
GRANT USAGE ON SCHEMA silver_sales TO ROLE data_analyst;

-- 授予读取数据的权限
GRANT SELECT ON TABLE silver_sales.transactions TO ROLE data_analyst;

-- 将角色分配给用户或组
GRANT ROLE data_analyst TO GROUP marketing_team;

这种基于SQL的方法简化了文件路径的繁琐。用户无需知道 silver_sales.transactions 映射到 s3://corporate-lake/silver/sales/transactions/v1/。他们只需与逻辑对象交互。

令牌售卖模式

当计算引擎需要读取文件时，出现一个主要的架构难点。如果每个分析师都需要直接的IAM访问S3存储桶，就会遇到“角色膨胀”问题，管理数千个IAM策略。

为解决此问题，现代架构采用令牌售卖机模式（通常由AWS Lake Formation或Azure Managed Identity等服务处理）。

1. 用户向查询引擎进行身份验证。
2. 查询引擎向治理服务请求访问特定数据的权限。
3. 如果通过RBAC获得授权，治理服务会“售卖”（生成）临时的、短期的凭据，这些凭据严格限定于该查询所需的特定S3路径。
4. 查询引擎使用这些临时凭据读取文件。

这确保用户永远不会拥有对底层存储桶的直接、永久访问权限。

细粒度访问控制

随着数据湖的成熟，需求通常从表级安全转向细粒度访问控制。你可能需要限制对特定行的访问（行级安全）或隐藏特定列（列级安全）。

列级安全 (CLS)

CLS 防止未经授权的用户查询特定的敏感列，例如个人身份信息 (PII)，如社会安全号码或电子邮件地址。

在像Parquet这样的列式格式中，这很高效。由于Parquet按列存储数据，如果用户缺少权限，查询引擎可以完全跳过读取受限的列块。

行级安全 (RLS)

RLS 根据行的内容限制数据。例如，“东部”地区的区域经理应该只看到 region = 'East' 的行。

在数据湖中实现RLS的计算成本比传统数据库更高。由于底层文件（Parquet/Avro）包含混合的行，引擎必须读取文件并在内存中过滤数据，然后才能返回结果。

从数学上讲，我们可以将用户 $u$ 的可见数据集 $V$ 定义为总表 $T$ 的一个子集，其中 $P(r, u)$ 是一个谓词函数，如果用户 $u$ 被允许查看行 $r$，则返回真：

$V_u = \{ r \in T \mid P(r, u) = \text{真} \}$

现代开放表格式如Apache Iceberg和Delta Lake原生支持这些功能。它们允许你定义动态视图，在查询时自动应用这些过滤器。

基于标签的治理

随着表数量增长到数千个，管理单个授权变得不可持续。基于标签的治理允许你将元数据标签分配给数据资产，并基于这些标签定义策略。

并非授予对 table_a、table_b 和 table_c 的访问权限，而是你对这些表应用 classification=confidential 标签。然后你创建一个单一策略：

• 策略： “拒绝 intern 角色访问任何标记 (token)为 classification=confidential 的表。”

这使得治理模型从明确列出资源转向描述数据的属性。当创建新表并标记为 confidential 时，它会自动受到保护，无需更新安全策略。

审计与血缘

治理也包含可见性。你必须追踪谁在何时访问了什么数据。

• 访问日志： 这些记录捕获每次查询执行，包括用户、SQL语句和时间戳。
• 存储日志： 这些捕获对物理文件的每次 GET 请求。将逻辑查询日志与物理存储日志关联起来，确保没有数据访问绕过引擎。

血缘追踪描绘了数据流。如果 gold 报告不正确，血缘允许你追溯到 silver 和 bronze 表以找到根本原因。血缘的技术实现涉及解析数据管道的查询计划（抽象语法树），以自动检测输入和输出表。