基于角色的访问控制模型

可扩展的数据平台不能依赖临时授权。尽管从技术上讲，可以授予特定用户访问特定表的权限，但这种方式会造成被称为“权限爆炸”的维护难题。随着数据团队的壮大，必要的访问控制列表（ACL）数量相对于用户和数据资产的数量呈指数级增长。

为了在生产环境中管理访问权限，我们采用基于角色的访问控制（RBAC）。在这种模型中，权限不是分配给用户，而是分配给角色。用户随后被分配到这些角色。这种间接性级别使得工程师可以通过更改单个角色分配来修改用户的访问权限，而不是更新数百个表级别的授权。

RBAC实体模型

RBAC系统的架构包含三个主要实体：主体、角色和特权。在数据工程场景中，这些实体对应特定的基础设施组件。

1. 主体： 请求访问的实体。这通常是人类用户（例如数据分析师）或服务账户（例如ETL流程或BI工具）。
2. 角色： 一组权限的集合，代表一个工作职能或一套职责。示例包括data_engineer、pii_reader或reporting_service。
3. 特权（或权限）： 对资源执行操作的特定授权，例如对表的SELECT、对模式的USAGE或对S3存储桶的listObjects。

这种关系意味着一个主体可以拥有多个角色，而一个角色可以包含多个特权。

用户仅通过角色分配获得权限的映射流程，将身份与资源访问权限分离。

实现角色层级

在生产系统中，扁平的角色列表通常不够用。我们实施分层RBAC以减少冗余。在此模型中，角色可以从其他角色继承权限。

例如，senior_data_analyst角色应自然地拥有data_analyst角色所持有的所有权限，以及额外的特权。高级角色不是重新定义基本权限，而是继承基本角色。

在数学上，如果$R$是角色集合，我们定义一个偏序关系$\succeq$，其中$r_1 \succeq r_2$表示角色$r_1$继承$r_2$的所有权限。

分配给角色集合$R_u$的用户$u$的有效权限$P_{eff}$可以表示为：

$$P_{eff}(u) = \bigcup_{r \in R_u} \{ p \mid \exists r' \in R : r \succeq r' \land p \in Permissions(r') \}$$

这种层级结构使安全模型保持“DRY”（不重复自己）。如果基础data_analyst角色获得访问新模式的权限，senior_data_analyst角色也会自动获得该权限。

逻辑访问与物理访问

在为数据仓库（如Snowflake、Redshift或BigQuery）设计这些模型时，有必要区分逻辑职能角色和物理访问角色。

• 职能角色： 这些角色对应职位或团队（例如marketing_team、finance_analyst）。这些角色通常不包含对数据库对象的直接授权。相反，它们包含其他角色。
• 访问角色： 这些角色对应数据资产集合（例如raw_data_read、finance_mart_write）。这些角色持有实际的GRANT SELECT或GRANT INSERT特权。

通过遵守这种分离原则，您可以将marketing_data_read访问角色分配给marketing_team职能角色。这创建了一个可组合的安全层。

权限稀疏性可视化

精心设计的RBAC模型会产生稀疏的权限矩阵。大多数用户不应访问大多数数据。下面的热图显示了一个健康的权限分布，其中特权访问（如删除数据或读取PII）高度集中，而普通读取访问则范围更广。

权限矩阵中，1（蓝色）表示可访问，0（灰色）表示受限制。请留意破坏性权限如何被限定于工程角色。

通过SQL强制执行

在基于SQL的环境中，我们使用数据控制语言（DCL）实施RBAC。尽管方言有所不同（PostgreSQL、Snowflake与T-SQL），但模式保持一致。我们首先创建角色，然后向角色授予特权，最后将角色授予用户。

设想一个我们需要授予报告模式读取权限的场景。

-- 1. 创建访问角色（权限的容器）
CREATE ROLE reporting_read_access;

-- 2. 将权限应用于访问角色
-- 注意：在读取表之前，通常需要'USAGE'权限来遍历模式
GRANT USAGE ON SCHEMA reporting TO ROLE reporting_read_access;
GRANT SELECT ON ALL TABLES IN SCHEMA reporting TO ROLE reporting_read_access;

-- 3. 创建职能角色（职位名称）
CREATE ROLE bi_developer;

-- 4. 创建层级（继承）
-- BI开发人员“是”报告读取者
GRANT ROLE reporting_read_access TO ROLE bi_developer;

-- 5. 分配给用户
GRANT ROLE bi_developer TO USER alice;

基于策略的集成

现代数据技术栈常使用基础设施即代码（IaC）工具（如Terraform）或专门的治理工具来管理这些授权。在临时脚本中硬编码GRANT语句会使审计变得困难。

在策略即代码架构中，您在配置文件中定义这些关系。部署流水线读取配置并将其状态应用于数据仓库。

roles:
  - name: reporting_read_access
    privileges:
      - schema: reporting
        type: SELECT
  
  - name: bi_developer
    inherits:
      - reporting_read_access
    members:
      - alice
      - bob

这种方法使您可以通过拉取请求审查访问权限更改。如果开发人员试图将用户添加到特权角色，此更改会在版本控制历史中可见，从而提供一份关于谁在何时授予谁访问权限的不可变审计日志。

最小权限原则

所有RBAC实施都必须遵循最小权限原则（PoLP）。用户或进程应仅拥有执行其功能所需的最低限度权限。

在数据工程中，这主要体现在两种常见方式中：

1. 范围缩小： 授予对特定视图的访问权限，而非底层原始表。
2. 临时访问： 为特定的维护任务使用临时凭证或有时限的角色，而非永久管理员权限。

未能遵循PoLP会大大增加安全漏洞或意外DROP TABLE命令的影响范围。通过使用细粒度角色而非宽泛的“超级用户”特权，我们限制了错误可能造成的潜在影响。