YMatrix

前言

在数字经济快速发展的今天，数据已成为企业最宝贵的资产之一。然而，随着数据价值的提升，数据安全风险也日益凸显。

如何在充分发挥数据价值的同时，有效保护个人隐私和商业敏感信息，成为企业面临的重要挑战。

01 当前权限系统，真的够用吗？

在构建数据应用时，我们常依赖数据库系统强大的 ROLE 系统来管理访问控制。通过GRANT SELECT ON TABLE ... TO role_name，我们可以轻松地决定谁能看哪张表。

但这只是故事的开始。当面对真正的生产环境时，这套机制很快会暴露其局限：

问题1：粒度太粗？

我们能否只允许普通员工查看客户姓名，但对其手机号进行部分掩码（如 138****1234）？原生权限只能做到“全有或全无”（能看到整行，或完全看不到）。

问题2：静态规则难应对复杂策略？

对于“超级 VIP 客户”，我们希望连专属客户经理也只能看到姓氏（如“张先生”）和模糊化的联系方式，而总经理则能查看全部信息。这种基于角色和数据属性的动态规则，仅靠 GRANT 和视图难以优雅实现。

问题3：绕过风险高？

如果开发或测试人员拥有直接连接数据库的权限，他们很容易通过SELECT * FROM sensitive_table绕过应用层的脱敏逻辑，导致敏感数据泄露。

这些正是传统方案在满足《个人信息保护法》(PIPL)、GDPR 等法规的“最小必要”、“去标识化”原则时所面临的挑战。我们需要的，是一种更精细、更动态、且内置于数据库引擎的数据访问控制能力。

02 真实场景出发：Anonymizer 可以实现什么功能？

仅用 SQL命令，即可完成全库动态脱敏配置，环境秒变“合规沙箱”。

这些场景凸显了 Anonymizer 的核心价值：它让数据本身具备了“智能”，能够根据访问者的身份和上下文，实时呈现不同级别的“视图”。

让我们看一个典型的企业级需求场景：

这种灵活的权限控制机制，使得企业能够根据不同岗位和角色设置相应的数据访问权限，既保证了数据的可用性，又确保了数据的安全性。

03 Anonymizer 究竟是什么呢？

💡 Anonymizer 就像给数据库装了一副「智能滤镜」——不同角色戴上不同镜片，看到的数据天然不同。

Anonymizer 是一个专为企业级数据安全设计的扩展功能。它允许您通过标准的 SQL DDL（数据定义语言）语句，在数据库模式（Schema）层面直接声明数据脱敏规则。

其核心目标是实现透明的动态数据屏蔽（Transparent Dynamic Masking），即在不改变原始数据存储的前提下，根据访问者的身份（Role），实时地、动态地返回已脱敏的数据视图。

关键特性：

声明式管理：使用 SECURITY LABEL 语法定义规则，与数据库对象生命周期紧密结合。
内核级执行：脱敏逻辑在数据库查询执行引擎内部完成，性能损耗极低。
动态与透明：对被授权用户透明，仅对特定“屏蔽角色”生效，无需修改应用代码。
企业级支持：作为 YMatrix 企业版专属功能，提供稳定的技术支持与保障。

04 超越原生：Anonymizer 核心优势

YMatrix Anonymizer 作为一款强大的数据匿名化工具扩展，突破原生权限系统的局限，通过灵活的匿名化策略和精细化的权限控制，为企业提供了“权限+脱敏一体化”的全面数据安全保障——让敏感数据在“可用”与“安全”间找到完美平衡。

05 Anonymizer 快速构建

Anonymizer 的工作流简洁而强大，遵循“创建 -> 声明 -> 授权 -> 访问”的模式。

1. 启用与初始化

首先，需要在目标数据库中加载 Anonymizer 扩展并激活动态屏蔽引擎。

-- 创建数据库并预加载扩展
CREATE DATABASE demo;
ALTER DATABASE demo SET session_preload_libraries = 'anon';

\c demo -- 连接到新数据库

-- 创建扩展并开启透明动态屏蔽
CREATE EXTENSION anon;
ALTER DATABASE demo SET anon.transparent_dynamic_masking TO true;

2.定义脱敏规则

这是 Anonymizer 的核心。用户可以为特定的列（COLUMN）或角色（ROLE）指定脱敏函数。

场景一：基础字段屏蔽

-- 将姓氏替换为虚构的假名
SECURITY LABEL FOR anon ON COLUMN people.lastname 
IS 'MASKED WITH FUNCTION anon.dummy_last_name()';
-- 对电话号码进行部分掩码 (保留前2位和后2位)
SECURITY LABEL FOR anon ON COLUMN people.phone 
IS 'MASKED WITH FUNCTION anon.partial(phone, 2, $$******$$, 2)';

当屏蔽用户查询时，0609110911 将显示为 06**11。

场景二：基于角色与条件的精细化控制

Anonymizer 支持复杂的条件判断，实现细粒度的访问控制。例如，在银行客户管理系统中：

-- 核心规则：普通员工(bank_emp)和VIP经理(vip_mgr)在查询super vip时，PII字段显示为'****'
SECURITY LABEL FOR anon ON COLUMN customers.pii 
IS 'MASKED WITH FUNCTION anon.ternary(
    (CURRENT_ROLE = ''bank_emp'') OR 
    (CURRENT_ROLE = ''vip_mgr'' AND status = ''super vip''), 
    ''****''::text, 
    pii 
)';
-- 声明哪些角色是"被屏蔽的"
SECURITY LABEL FOR anon ON ROLE bank_emp IS 'MASKED';
SECURITY LABEL FOR anon ON ROLE vip_mgr IS 'MASKED';