构建 Medallion 架构——勋章架构的治理与安全在第 11 章中，我们探讨了在大型、复杂组织里日益重要的去中心化与

在第 11 章中，我们探讨了在大型、复杂组织里日益重要的去中心化与联邦式模型在勋章（Medallion）架构中的细微差别。第 12 章将把焦点转向健全的治理与安全协议，其重要性不言而喻。

本章将全面概述有效管理联邦式模型所需的治理与安全要点。我们先详论治理，并将 Unity Catalog 作为最佳实践；随后讨论数据契约及其在跨域安全高效数据共享中的作用，涵盖在数据目录中实施数据契约的方法、使用元存储（metastore）配置，以及配合 Git 的 YAML 模板落地与协作。最后，我们将深入数据安全与访问管理，聚焦如何加固 Microsoft Fabric 与 Azure Databricks 等数据平台，确保数据访问严格受控并符合既定安全规范。

读完本章，你将全面理解在 Medallion 架构中有效管理治理与安全的关键措施，从而确保数据既有价值又受保护。

数据治理

在大型联邦式架构中，数据治理十分复杂。要在所有域内恰当地管理数据质量、完整性与安全，需要一套结构化方法。你需要为每个 Medallion 架构实例建立清晰的管理指引：定义角色、划定边界，并在 Bronze、Silver、Gold 各层中管理数据。下面我们先看如何在 Medallion 架构中有效实施数据治理，然后再介绍 Unity Catalog 这一关键治理组件。

Medallion 架构内的治理

实施数据治理原则，建议从源系统一侧入手——数据的起点。首先识别哪些源系统生成并保存权威数据，随后指定应用负责人与数据负责人：应用负责人处理采集层面的数据问题，数据负责人关注数据质量并决定向数据平台共享哪些数据。

接着，梳理你的应用版图中的边界，将紧密协作且支撑同一业务目标的应用归组；边界确定后，为每个域指派一位域负责人作为主要联系人。

注
“角色（Persona）”代表组织内的职责定位；同一人可能在不同域中身兼多职（如既是应用负责人又是数据负责人），以适应治理需要的灵活性。

完成源系统侧的域边界后，确定每个 Medallion 架构的粒度以及它与前述应用域的对应关系：多个应用团队是否共享一个平台实例，还是各自需要独立的 Medallion 架构？可参考“Medallion 数量”相关指引作出决策。一般而言，组织规模与成熟度会影响这种对应：高成熟度组织更倾向于细粒度对应（小集合应用共享同一架构），低成熟度组织则更偏粗粒度（较大集合应用共用平台实例）。

确定域与平台实例数量后，开始在每个 Medallion 实例内管理数据，从摄取与 Bronze 层做起。务必实施严格的访问控制以防未授权访问，并制定跨层/跨域的数据流动规范。例如：限制 Bronze 层数据仅在本域内使用；对外共享仅限 Silver 层已认证数据集或 Gold 层数据。

在 Bronze 层，与源系统团队保持紧密的反馈回路至关重要：出现技术校验或摄取问题时，应由负责源系统的应用团队尽快修复。此外，应在采集/摄取入口即落实安全措施：自动为数据打上敏感度与分类标签，必要时以对称加密保护 PII 等敏感信息。因此需预先定义组织级敏感度标签与分类体系，确保一致性。

进入 Silver 与 Gold 层时，治理的重点应转向完整性、一致性与可用性。为数据建模制定统一规范（数据格式、命名约定、变换类型等），并与企业级数据/主数据管理标准对齐，尤其在同一数据被多域广泛复用的情况下。Silver 层应尽量避免跨源整合（以便数据所有权与应用团队对齐），并定期审计以确保合规。Gold 层选择最契合组织需求的数据模型，强调“细节取舍”而非绝对标准，将数据模型转化为面向消费的接口模型。

综合上述对各层的治理要点，见下表：

表 12-1：Medallion 各层治理概览

层级	治理相关目标
Bronze	报告技术校验问题；为数据打标签/分级；可选加密；定义原始数据访问控制
Silver	报告业务数据质量问题；避免跨源整合；定期审计；应用 MDM；确保包含安全元数据；定义是否允许运营性使用；与 Bronze 对齐；对运营对齐的数据产品进行签收
Gold	关注消费侧细节；确保数据集间一致性；转化为面向消费的数据模型；数据产品签收

在消费侧（由 Gold 层承载）会因域与用例需求而呈现差异。与其重复铺设平台、导致资源过度配置，不如为团队提供可复用的解决方案模式，并有效管理消费用例组合，避免不必要的平台实例激增。对每个新用例的上架要谨慎：识别重叠诉求，必要时建立“消费者供给域”以预整合常用数据，既提效又契合多域需求。记住：循序渐进比完美更重要——规模化演进需要时间，治理文化、变更管理与架构能力需均衡共同成熟。

要支撑上述活动，你需要一套强健的数据治理框架：清晰的政策、流程与工具，明确职责分工，界定关键元数据、维护方式与质量要求，并通过持续教育与社群促进知识共享与改进。将治理原则融入数据目录也至关重要：它既保持一致性，也强化中心视角、团队协作与数据可发现性；目录提供资产总览、血缘、关键元数据、质量洞察与所有权信息，是管理数据契约、安全与访问的基石。接下来，我们将通过 Unity Catalog 深入理解数据目录的角色。

Unity Catalog

在第 1 章我们回顾了 Hadoop 生态中的 Hive Metastore。它曾长期担任 Databricks 的元数据仓库，但存在灵活性与易用性不足的问题，且每个工作区都需要独立的 metastore，导致大规模权限一致性极难维护。

为此，Databricks 重构了跨工作区的访问控制、审计、血缘与发现能力，推出了集中式的 Unity Catalog，显著简化了多工作区的数据管理。随着广泛采用，Databricks 又将其开源，使组织可在更多平台利用其能力。如今，Unity Catalog 已成为开源生态中的关键组件（见图 12-1）。

开源后的 Unity Catalog 提供通用接口，支持多种数据格式与计算环境；通过 Delta Universal Format（UniForm） 支持 Delta、Iceberg、Hudi 等表格格式，可异步生成 Iceberg 元数据，让客户端将 Delta 表当作 Iceberg/Hudi 表读取。典型客户端包括 Microsoft Fabric、Snowflake、DuckDB、Apache Spark、Trino、Dremio 等。它还支持通过 Credential Vending API、Iceberg REST Catalog 与 Hive Metastore 接口的外部访问，朝着湖仓表元数据标准协作与开放目录的方向迈进。

Unity Catalog 与 Medallion 架构

在 Medallion 架构中，Unity Catalog 几乎是实现稳健运营级治理的必需品：它提供统一资产视图、促进跨工作区协作，并带来多项收益。

其一是命名空间层级扩展：从传统的 schema.table 扩展为 catalog.schema.table。实践中，你可为不同团队/数据域建立独立的 catalog，并以 dev/test/prod 前缀区分环境；在 schema 中融入勋章层级（bronze/silver/gold）。例如：prod_sales.silver_adventureworks.clean_customer 既清楚表达环境、域、层级与主题，也便于检索与治理。

命名规范对规模化与一致性至关重要，通常由**卓越中心（CoE）**制定并发布共享目录与标准。统一、可读的命名也利于未来 AI 应用更高效地定位与整合数据。

TIP
可用“工作区-目录绑定（workspace-catalog binding）”将某些 catalog 限定给特定工作区访问，便于分域/分环境隔离（参见 Databricks 文档）。

Unity Catalog 还是安全闸门：目录中的每个对象都可单独授权，权限由对象所有者（通常为资产创建者）分配；并可与身份提供方（如 Microsoft Entra ID）集成，将组直接授予 catalog、schema 或对象：

GRANT USE CATALOG ON CATALOG <catalog_name> TO <group_name>;
GRANT USE SCHEMA ON SCHEMA <catalog_name>.<schema_name> TO <group_name>;
GRANT SELECT ON <catalog_name>.<schema_name>.<table_name> TO <group_name>;

其层级化与对象级安全相辅相成：上层授予的权限会继承到下层表与视图，同时可在各层灵活加规则，形成稳健而弹性的安全模型。

更多实践可参考 “Unity Catalog Best Practices”。其他关键优势包括：

集中治理：跨组织统一管理数据资产，追踪血缘、管理元数据、保障质量与治理；并提供受权限控制的搜索界面。
细粒度访问控制：从 catalog、schema 到表/列/行级的授权能力（列/行级详见后文“数据安全与访问管理”）。
数据血缘与可审计性：捕获在 Databricks 上运行的查询血缘（语言无关，精确到列级），并关联到笔记本、作业、仪表板。
分类与标签：按敏感度、用途等对数据进行分类与打标，用于执行治理策略（如敏感数据限定访问、留存规则）。
数据共享：通过 Delta Sharing 将对象分享给组织内外：创建 share、添加对象、添加接收方并授予访问，生成 URL 供对方下载 profile 并以 bearer token 访问。兼容 Power BI、Spark、pandas 等生态。

与分布式治理模型的对齐

按第 11 章的指导，先识别组织内的业务域，为每个域建立独立的工作区与catalog，并指派域负责人管理资产与治理。进一步地，为每个团队与目的建立特定 catalog（如 dev_sales、test_sales、prod_sales），并采用描述性命名以提升可理解性与安全性。

关于域内权限，示例权限矩阵如下：

表 12-2：表级授权示例

	开发 catalog	测试 catalog	生产 catalog
开发者	读写	无	只读或无
测试 SPN	无	读写	无
生产 SPN	无	无	读写

此模型确保：开发者可在开发环境读写、在生产仅只读以便排障；测试 catalog 由专用服务主体执行 CI 测试，严禁访问开发与生产；生产由生产服务主体写入。如此实现环境隔离与稳健运维。

身份管理同样关键：按 schema/catalog 创建具备 INSERT/UPDATE/DELETE 等权限的组，并映射到实际用户（开发、数科、分析等），为不同角色赋予恰当的访问权。例如数科可访问 prod_sales 中 silver_* 的分析数据。我们会在“数据安全与访问管理”中继续展开。

小结：Unity Catalog 极大强化了 Databricks 及开源生态中的数据管理与治理，是数据工程、安全、血缘与监控的运营级目录。在更广的数据基础设施里，将其与 Microsoft Purview 等目录配对更佳：Unity Catalog 侧重 Databricks 的运营治理，Purview 则充当“引用目录/目录之目录”，二者协同可统一跨平台的数据管理策略，提升整体效率。

接下来，我们将深入数据契约，这是去中心化数据管理环境中的治理关键。

数据契约（Data Contracts）

手工的数据安全与治理已经成为过去式。如今，我们需要可计算的治理层来自动化并编排整个数据平台。数据契约在其中发挥关键作用——它能自动执行策略，将手动流程转为可编程流程，同时保持必要的护栏。这一演进简化了流程，也全面增强了安全性。

本质上，数据契约是数据提供方与数据消费方之间就数据共享与使用达成的正式协议。它明确数据格式、质量、可用性与安全策略等细节，以及各方的职责。数据产品关注的是数据本身的定义与内容，而数据契约关注的是数据的接口，旨在将数据共享的期望与责任形式化。

需要注意的是，“数据契约”这一术语和“数据产品”一样存在歧义。不同人可能有不同理解，行业里也没有统一标准。因此，务必在组织内部明确定义数据契约，以避免误解，确保一致认知。

在勋章（Medallion）架构中，运用数据契约有助于管理同一组织内多套 Medallion 架构之间的数据分发。它为数据交付、共享与消费设定规则，从而强化数据质量与治理，并加速数据驱动决策。下面我们先看如何在数据目录中落地数据契约，再转向**元存储（metastore）**的做法，然后看看 YAML 模板 + Git 的实现路径，最后简述一些可选方法。

在目录中管理契约

很多组织会借助数据目录与治理工具（如 Microsoft Purview、Unity Catalog）来实现数据契约或数据共享协议。这些工具可作为集中式存储库来保存与管理数据契约。图 12-2 展示了在 Microsoft Purview 中申请一个数据产品的示例：当你对某数据产品发起访问请求后，会触发一个工作流，由数据资源的所有者或管理者审批授权。某种意义上，这就构成了一种“数据契约”。

目前，Microsoft Purview 中记录的这些协议，与其他数据服务的联动仍较松散。Purview 负责记录数据请求并通过自助流程促成契约，但不会直接强制执行或分发数据本身。要做到这点，还需要对接 HTTP 连接器或其他工具（如 ServiceNow）。

优点：用 Purview 之类的服务可以快速搭建与管理数据契约。
潜在问题：可能形成对某平台的过度依赖，当你需要扩展到不完全兼容的技术时会受限；同时，服务的预置范围也可能限制你为特殊需求定制契约的能力。

因此，我们转向更通用的方法。先看自定义元存储如何助力数据契约管理，再看用 YAML + GitOps 管理契约。

在元存储中管理契约

使用元存储（metastore）能在多方面支撑数据契约的构建与管理：
一是提供清晰一致的全量数据资产视图（参见第 6 章“元数据存储的实现”）；二是可自动化治理环节（如访问控制与审计），保证契约在全组织范围内被一致遵循。

实践中，你可以在现有的元存储之上扩展额外的表：若你已有用于描述架构（schema）的表，就可增加敏感信息标记、存储位置与方式、访问规则、审计日志等结构，将与数据契约相关的关键信息完整落在元存储中。

一种可行的设计是：

以 Azure SQL 作为契约元存储；
叠加一个Web 应用用于可视化与审阅契约；
通过 Logic Apps 编排审批工作流，按规则流转与授权；
审批通过后由 Azure Functions 触发资源开通，例如调用 Microsoft Fabric OneLake Shortcuts REST APIs 配置数据访问。

这类定制方案既能确保契约的安全管理，又能按需调整流程以适配组织特色。很多组织依赖组成员关系管理权限——将方案对接 Microsoft Entra ID，即可同时处理“用户因组而得权”“应用因服务主体而得权”的场景，在安全与可用之间取得平衡。

当然，上述只是其中一条路径；你也可以采用更偏自助或更偏强治理的变体。接下来看看 YAML + GitOps 的方法。

用 YAML 与 GitOps 管理数据契约

将数据契约定义为 YAML 文件，并配合 GitOps 流程，是另一条高效路线。你把契约写成人类可读且易于版本化的 YAML，纳入 Git，走 Pull Request 审核，契合前文“YAML/JSON 配置”的理念。

例如，当你需要消费并校验某数据集时，先准备一个契约 YAML，形式化描述该数据：指定数据集、过滤 SQL、数据集所有者等。简化示例：

owner: piethein@oceanicairlines.internal
purpose: To analyze customer behavior and sales trends.
use_case:
  description: Tailored for targeted campaigns in New York.
workspace_id: 92187CE0-B7EB-4FDF-80CE-EFF76639EED8
dataset_location: https://onelake.dfs.fabric.microsoft.com/<workspace>/<item>
dataset: dim_customer
filter_sql: customer_state = 'New York'
columns:
  - name: first_name
  - name: last_name
  - name: birthdate

实际场景下，还应增补数据留存策略、分发方式等条款。

创建契约后，可通过多种方式校验与审批：

借助元存储：在 PR 合入前对契约做校验与审批，审批后再加载进元存储。
融入 CI/CD：针对 YAML 模板做规范校验，由数据治理团队在 Pull Request 中审阅/核准；核准后触发发布流水线，按契约通过 REST API 在平台上下发权限。这样既守住数据完整性，又确保符合组织标准。

其他数据契约规范

一些数据从业者会采用**数据契约规范（specification）**这一更正式的文档形态，技术中立、可跨平台实施。

可参考 Open Data Contract Standard 与 Data Contract Specification 开源仓库（通常以 YAML/JSON 书写）。
实操资源如 “How To Build a Data Product with Databricks” （讲述如何用 CI/CD、Databricks 与 Azure DevOps 基于数据契约构建数据产品）。
还有 Data Contract CLI 等开源工具，可通过命令行签发契约并支持 Unity Catalog。

另一种思路是围绕数据集结构的强保证来理解“契约”。例如 dbt 将此称为 contract：对模型产出的架构、列类型、数据约束给出硬性约束——一旦不匹配，模型直接构建失败，而不是仅做质量测试。可查阅 dbt 的 model contracts 指南。

此外，数据契约也可出现在数据摄取环节：入湖数据必须符合预定义契约（格式、架构、质量要求），不符合则拒收。这类似软件世界的 SLA：数据提供方承诺按约向平台提供数据。

无论选择哪种路径，契约都需贴合组织的具体需求。它并非一刀切，一般以平台中的元数据记录形式实现，管理数据流与完整性/质量，并与域拥有的数据产品相连接。由此，契约与其保护与执行机制必须紧密耦合——这也把我们自然引向数据平台上的数据安全与访问管理：在那里，契约之“规”将真正落地生效，确保数据被正确使用并免遭未授权访问。

数据安全与访问管理

在大型组织中，基于角色与职责精细划分的前提下，管理数据访问——谁可以在何时、在何种特定条件下查看哪些数据——会相当复杂。此外，不同平台各自具有独特的安全特性与要求。因此，在数据平台的多个层面正确实施安全至关重要。为了落实数据契约（data contract）中的约束，你通常需要将多种安全措施与访问管理策略组合起来使用。

本节聚焦于数据安全与访问管理，重点讨论 Microsoft Fabric 与 Azure Databricks 等平台。请牢记：安全既关键又复杂。关于 Microsoft Fabric，请参阅其安全白皮书；关于 Azure Databricks，建议阅读“安全与合规”指南。

你可以通过多种方式配置数据访问，以控制谁能查看或使用某些数据。这些方法在复杂度与精细度上存在差异，从宽松到高度细粒度的访问控制不等。下面先看看一些常见选项，随后我们将结合参考图进行总结：

网络安全基础

隔离网络是网络安全的关键。首先阻断公共访问，使用 VNET 注入（VNET injection），并在隔离的虚拟网络中部署 Spark 工作负载。使用私有终结点（Private Endpoints）仅向受信任服务开放访问。为存储账户启用防火墙以进一步保护数据。为工作区建立“工作区标识/托管标识”（workspace identities/managed identities），以持续验证受信访问；并使用 Key Vault 安全高效地管理密钥。通过这些措施，你能加固网络以抵御潜在威胁，确保数据得到保护。

此外，考虑使用安全落地区域（safe landing zones）。与其让数据平台（不安全地）直接与公共端点通信，不如使用隔离的 Azure Data Factory 自托管集成运行时（self-hosted integration runtime）从（外部）源头将数据传送至中间存储位置。这样可以确保数据平台仅与受信源对接。

单点登录（SSO）与多重身份验证（MFA）

SSO 与 MFA 是保护数据平台的基础性安全措施。SSO 允许用户使用一组凭据访问多个应用，简化登录流程。MFA 通过要求两种或以上验证要素（例如手机或认证应用的一次性验证码）来增加一道安全屏障。二者结合可有效防止未授权访问平台服务。

全量审计

审计是数据安全的关键环节。通过启用诊断日志、Storage Analytics 日志、网络安全组（NSG）流日志等来审计所有活动并跟踪用户行为，你就能知道谁在对哪个对象执行哪些操作。这有助于提升架构安全性，并满足诸如监管合规与记录管理等要求。

实施时间点恢复（Point-in-Time Recovery）

时间点恢复是一项关键的安全措施，允许你将数据恢复到某个特定时间点。它在意外删除、数据损坏或安全事件（例如勒索软件攻击）发生时尤其有用。René Bremer 发布过关于使用 Azure Databricks 或 Synapse Analytics 保护 Azure Data Lake 的优秀文章。对于保护 Microsoft Fabric，可参考 Nicholas Hurt 关于业务连续性与灾难恢复（BCDR）策略规划的最佳实践与注意事项。

工作区角色与权限

Microsoft Fabric 以及 Azure Databricks、Synapse Analytics 等平台都提供了一组内置角色，你可以将其分配给某个工作区的用户或用户组。这些角色决定了用户可以执行的操作以及可以访问的对象。你也可以创建符合组织特定需求的自定义角色。例如，你可以定义一个“查看工作区全部内容”的角色，和另一个“工作区管理”的角色。一旦定义好角色，就可以将其分配给相关用户或用户组。

需要注意，这些工作区角色与权限仅适用于工作区对象。对于数据访问，推荐通过 Unity Catalog 等工具实施细粒度的数据权限，从而实现更有效、更安全的数据管理。

项目级（Item-level）权限

项目级权限与工作区角色/权限类似，但可针对单个项目（Item）提供更为精确的、相对粗粒度的访问控制。Microsoft Fabric 与 Azure Databricks 等平台都支持对特定项目（如某个管道或数据科学项目）设置权限，从而更精细地控制工作区中单个数据资产的访问。在 Azure Databricks 中，你可以使用 ACL（访问控制列表）来设置工作区层面的对象权限；在 Microsoft Fabric 中，项目级权限可让你决定谁能查看、修改与管理工作区内的各个项目。

分配这些权限通常遵循“创建”与“等待完成”的工作流，以手动为用户或用户组设定角色与权限。或者，可以借助 ServiceNow 之类的工具来处理访问请求与授权。批准后，你就可以应用内置角色来赋予工作区或项目的特定权限，并将这些角色分配给合适的用户或用户组，确保只有获授权的人员才能访问数据与制品。

在 Microsoft Fabric 中共享项目

仍然在工作区与项目级安全的层面上，还有一种与未在工作区内分配角色的团队成员协作的方式：你可以直接与其他用户共享项目。更多信息参见“在 Microsoft Fabric 中共享项目（Share Items in Microsoft Fabric）”与“使用 Databricks Notebooks 协作（Collaborate Using Databricks Notebooks）”。

使用敏感度标签

另一种提升安全性的有效方法，是为所有数据与制品使用敏感度标签（Sensitivity Labels）。例如，在 Microsoft Fabric 搭配 Microsoft Purview 的场景中，你可以在信息保护管理器中设置策略，基于内容自动为数据打上敏感度标签。比如，若某文档包含客户个人信息（如信用卡号、社会保障号或护照号），系统即可自动将其标记为“高度机密”。打标之后，你可以实施严格的访问策略，只有拥有适当权限的用户才能查看这些高度机密信息。该方法确保敏感数据获得妥善保护，仅供真正需要的人访问。关于标签设置，参见 Microsoft Purview 的保护策略、“Fabric 与 Power BI 中的受保护敏感度标签”，以及 YouTube 视频《Microsoft 365 信息保护的实际工作机制》。

在 Databricks 中使用 Unity Catalog

若要在不同 schema 及其相关数据结构之间实现更细致的数据访问管理，使用 Databricks 的 Unity Catalog 是一种很好的策略。借助 Unity Catalog 的 Privileges，你可以控制谁能访问哪些 catalog、表、视图与其他对象，并为用户或用户组分配在这些对象上的特定操作权限。Databricks 文档对 Unity Catalog 的权限管理有更详细的介绍。

此外，你可以通过标签与规则建立基于属性的安全模型（ABAC）。例如，为数据打上 pii:ccn 标签，并创建规则：对打有该标签的数据应用正则掩码，将所有数字替换为 “X”。这样即使用户被过度授权，也不会看到敏感数据的明文。关于如何设置标签与规则，可参考该主题的视频演示。

在 Azure Data Lake Storage（ADLS）中设置 ACL

这种方法并不被作为最佳实践推荐，但在一些企业中依然存在：通过在 ADLS 中实施 ACL 来做安全管理。该方式通常导致粗粒度的权限，难以进行精确管理，并可能因对底层数据开放过广而带来显著风险。

通过 Fabric 的“快捷方式（Shortcuts）”授予访问

在 Microsoft Fabric 中，你可以通过“快捷方式”直接共享数据。借助快捷方式，你无需共享项目本身、也无需移动数据，即可授予对数据的访问。在使用快捷方式时，访问权限由“快捷方式路径”与“目标路径”的权限组合决定；当用户通过快捷方式访问时，两者中更严格的权限将被应用。更多信息可参见 Microsoft 文档。

实施细粒度数据访问控制

你可以通过行级安全（RLS）、列级安全（CLS）与对象级安全（OLS）来限制对数据的访问。假设你有一张包含敏感信息的表，希望限制某些行或列的访问，那么可以使用 RLS 与 CLS 控制谁能查看或修改特定行/列；而 OLS 则用于限制对特定对象（如表或视图）的访问。当你需要以细粒度方式管理敏感数据访问时，这种方法尤为有用。相关资料：Microsoft Fabric 的“数据仓库安全”与“OneLake 基于角色的访问控制（RBAC）”；Azure Databricks 的“使用行过滤与列掩码过滤敏感表数据”。

识别敏感数据

要有效管理敏感数据，首先需要将其识别出来。你可以使用根据预定义模式或规则自动检测与分类敏感数据的工具。目前较常用的包括 Presidio 与 Data Profiler。

通过掩码或加密来保护数据

在某些情况下，你可能希望从数据摄取入口就对敏感信息进行掩码或加密。该过程通常需要随数据携带元数据，以帮助定位敏感数据元素。通过掩码或加密，可在处理与存储过程中维护机密性，从而防止未授权访问，并在数据生命周期的各个阶段都保护敏感信息。

Power BI 安全

在 Power BI 中，用户既可以将数据导入平台，也可以直接连接到数据源。导入模式下，初次连接与后续的数据刷新的认证均使用用户的凭据；导入后的数据可在报表与仪表板中查看，而无需再次访问源系统。Power BI 对特定数据源支持 SSO，这允许在数据连接时使用语义模型所有者的凭据。

对于直接连接（DirectQuery/Live），可以使用预配置凭据或 SSO。若使用预配置凭据，所有用户都以同一套凭据访问数据源；若使用 SSO，则使用每个用户的个人凭据，从而可以在数据源侧实施 RLS 与 OLS，增强安全性。

当将 Power BI 与 Azure Databricks 集成时，有两种常见方式：其一，使用服务账户从 Databricks 直接导入数据；其二，通过 Databricks SQL 发起直接查询，最佳做法是使用 Microsoft Entra 直通身份验证（pass-through authentication）。这种方式会在 Unity Catalog 范围内利用终端用户的身份。当向 Databricks SQL 仓库发送认证请求时，系统会通过 Unity Catalog 校验数据访问权限，然后返回查询结果。无论哪种方式，都必须在 Unity Catalog（供直接通过 Databricks SQL 消费数据的用户）与 Power BI 两侧建立细粒度访问控制策略。要深入了解该集成及其具体设置细节，可参考技术文章《从 Azure Databricks 发布到 Power BI Online》与《Power BI 与 Databricks 的访问控制与网络安全》。

在 Azure Databricks 与包含 Power BI 的 Microsoft Fabric 等跨平台集成场景中，必须在两边维持一致的安全策略。由于每个平台都有其独特的安全模型与访问控制机制，对齐它们往往颇具挑战。这需要在两个系统之间配置角色、权限与数据访问控制。此外，有效的数据治理依赖一致且良好管理的元数据；跨平台运行时，需要确保反映数据结构、使用与来源的元数据保持同步与准确，必要时还需借助额外工具或采用人工流程来在平台间对齐元数据。数据契约同理：它们必须在所有平台上保持一致且最新，以确保安全而准确地共享数据。

此外，完善的总体架构应在各个层次组合多种安全机制来保护数据。请参见图 12-3，其中展示了一个 Azure Databricks 的示例安全架构。

从基础层开始，网络安全至关重要。通过将计算集群与用户工作区分离，并控制这些虚拟网络之间的入站与出站访问，你可以显著提升安全性。实施诸如禁用公网上网、使用私有终结点、只授予受信任工作区的访问、强制条件式访问（Conditional Access）、维护 IP 访问列表等措施，可确保只有获授权的流量能够进入网络。这不仅从一开始就防止了未授权的数据访问，也构成了你的第一道防线。

提示
René Bremer 撰写了一篇关于将 Microsoft Fabric 安全连接到 Databricks SQL 的长文，其中包含多张使用安全 VNET 与网关的架构图。

接下来是认证与访问控制。通过与企业级身份提供方（如 Entra ID）协同，并实施 SSO、MFA 以及仅允许通过 VPN 访问，系统可以从源头阻止未授权访问。一旦授予访问，重点就转向“授权”。这一阶段的核心是定义角色与权限。管理员会设定具体规则，决定用户可以访问哪些数据以及可执行哪些操作——例如访问工作区与项目（Items）、查看笔记本、执行特定作业等。

再往上是数据安全，这是架构中的关键一层。数据访问控制模型使用详细的规则来指定哪些应用、用户与用户组可以访问数据。为增强该模型，建议使用用户自定义函数（UDF）、标签（tags）或敏感度标签（sensitivity labels）来对数据进行分类并强制执行策略。这些控制明确界定了谁可以查看数据以及他们与数据交互的方式。

最后一块拼图是监控与合规。这包括跟踪使用模式，并确保所有操作都符合监管标准。持续的监控有助于维护整个系统的完整性与安全性。

在这一切之上，是一个治理框架，确保上述措施得到落实、流程得到执行。该框架包含规范、流程与指南，用于管理数据如何被访问、使用与保护；还包括定期审计，以确保系统的安全与合规。该框架由目录（catalog）支撑，用于管理标签、分类、血缘与其他元数据（如数据所有权与数据质量信息）。

这就是全部了吗？还不是。在联邦式（federated）模型中，安全元数据与参考数据在 Medallion 架构中的数据访问管理中起着关键作用。这些元数据包含关于数据访问、分类与保护的细节，确保数据使用符合组织的政策与法规。当数据契约涉及敏感信息（如个人或财务数据）时，这一点尤为重要。

在 Medallion 架构中，你可以用多种工具与技术来管理安全元数据。一种有效做法是将安全元数据直接嵌入到数据产品中。这样可确保访问控制与分类信息随着数据一同流转到任何地方。

还记得你在第二部分使用过的 AdventureWorks 数据库吗？在 customer 表中有一个名为 SalesPerson 的列。假设你希望基于该列来限制对该表的访问。你可以创建一个使用用户自定义函数的安全策略来强制执行此限制。下面的示例展示了如何基于 SalesPerson 列限制对 SalesLT.Customer 表的访问：

CREATE SCHEMA Security;
GO

-- 为 SalesPerson 创建函数
-- 这里假设系统中的姓名不超过 50 个字符，但实际可调整
CREATE FUNCTION Security.udf_securitypredicate(@SalesPerson AS varchar(50))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS udf_securitypredicate_result
    WHERE @SalesPerson = USER_NAME() OR IS_ROLEMEMBER('manager') = 1;
GO

-- 使用该函数创建安全策略
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.udf_securitypredicate(SalesPerson)
ON SalesLT.Customer
WITH (STATE = ON);
GO

此策略确保只有与 SalesPerson 列值相匹配的用户，或属于 manager 角色的用户才能访问数据。要使该策略有效，必须将这类元数据嵌入到数据本身中。因此，如果该元数据存在于 Bronze 层，那么在 Silver 与 Gold 层也必须保留。

请注意，数据安全与访问管理与数据治理密切相关，因为二者共同目标都是有效地保护与管理数据。可以将数据治理视作“规则手册”，规定数据应如何存储、如何附带元数据与分类、如何审批、以及如何被访问。

结论

在我们总结关于通过数据治理、数据契约与数据安全来实现规模化的讨论时，我强调了目录（catalog）与元数据在管理与控制数据分发中的重要性。不过，故事不止于此。有效的数据安全不只是搭起目录或数据契约，更关乎自动化与坚实的数据治理框架。这意味着要定义角色、建立清晰流程、设计高效工作流、编写政策文档，并对用户进行系统培训。这是一种整体性的做法，远不止部署一套工具那么简单。

若要高效扩展并保持稳健、合规的数据架构，就必须优先推进数据治理、战略规划与组织对齐。这些要素是任何数据架构的地基。关键在于让这些不同关注点同步发展。举例而言，即便你的数据平台设计完美，但如果没有被治理的数据，你也无法信任这些数据，平台就失去意义；反过来，一个高度成熟的数据治理组织如果缺乏稳定的数据平台，同样无效，因为你无法信任数据处理过程。因此，要成功扩展 Medallion 架构，务必确保各个领域并行且均衡地成长与成熟。

在第 13 章，我们将深入探讨如何将包括 AI 在内的新兴技术集成到 Medallion 架构中。AI 在自动化复杂数据任务、增强分析能力、并助力更智能决策方面的潜力，为这些架构的演进带来了令人振奋的可能性。