第3章 输出限制概念：输出限制、数据脱敏、字段级权限控制、行级安全策略
输出限制，说白了就是管住“数据出去的那个口子”。你想想看，很多安全漏洞其实都不是数据库被拖库，而是正常业务接口返回了不该返回的数据。我之前在某金融项目里就遇到过——一个查询余额的API，后端开发偷懒直接把整行用户记录扔回去了，结果密码哈希、身份证号全带出来了……嗯，从那以后我对输出限制这件事就特别敏感。
这一章我们要拆解的四个概念，其实是一套组合拳。从最粗粒度的策略到底层的行级过滤，它们共同构成了“数据能看、但不能全看”的防线。我个人习惯把它们画成一个漏斗结构。
什么是输出限制
输出限制不是单一的技术，而是一套管控策略。它定义了一个原则：即使你有权限读取某条数据，也不代表你能看到原始的全部内容。 我见过不少团队把权限只做到了“能查/不能查”的粒度，结果一个业务员就能看到所有客户的交易明细——这在合规审计里是红线。
核心要求：输出限制必须在数据离开数据库之前生效，而不是在前端做隐藏。前端脱敏纯属掩耳盗铃，拦截数据包照样能看到。
数据脱敏
数据脱敏就是对敏感信息做“模糊化”处理。比如手机号只显示前3位后4位，中间用星号代替；身份证号只留前后各两位。它会改变数据的展示形态，但保留数据的部分特征供业务判断。
我在电商项目中做过支付卡号脱敏——后端API返回银行卡号时，统一截取前6后4，中间全部打码。但注意，如果同时返回了校验位（Luhn算法），黑客其实能反推卡号。所以我建议脱敏要彻底，不只是遮住，还要清理掉可用于推断的冗余信息。
常用脱敏方法：
- 替换：用固定字符（如*）替换真实字符
- 截断：只保留部分字符，其余丢弃
- 偏移/取整：对数值做随机增量或保留精度（适合地理位置、金额）
- 加噪：加入随机噪声，但统计特征不变（适合大数据分析）
字段级权限控制
字段级权限，说白了就是“按列控制”。你想想看，一个用户表可能有十几列，有些角色只能看到用户名和邮箱，不能看到身份证号和密码哈希。这就是字段级干的事。
我有个避坑经验：字段级权限不要只依赖ORM框架的字段过滤。因为ORM层面虽然只查询了指定列，但如果业务逻辑里不慎用了 SELECT *，或者后来增加了新字段忘了加到权限清单里，数据就会泄露。我建议在数据库视图或API网关层再做一层字段白名单拦截。
实现方式通常有两种：
- 查询时动态拼装SQL——根据角色只选择允许的列。性能好，但维护复杂。
- 返回后过滤——查出完整行，在序列化阶段删除不可见字段。简单但浪费带宽。
行级安全策略
行级安全是限制“你能看到哪些行”。比如一个销售主管只能看自己团队的数据，不能看其他团队的。它在数据库层面通过行级安全（RLS）实现，比如PostgreSQL的CREATE POLICY。
我这里给一个简单的行级安全策略示例（PostgreSQL）：
-- 创建行级安全策略：只允许查看自己部门的数据
CREATE POLICY dept_policy ON employees
FOR SELECT
USING (department_id = current_setting('app.current_dept')::int);
-- 启用行级安全
ALTER TABLE employees ENABLE ROW LEVEL SECURITY;注意：行级安全必须配合认证上下文一起使用。如果应用层可以随意设置current_setting，那策略就形同虚设。我建议把用户部门、角色等信息放在数据库连接参数里，由数据库连接池统一注入，禁止应用层直接修改。
四种策略的对比
| 策略 | 控制粒度 | 典型场景 | 实现层级 |
|---|---|---|---|
| 输出限制（宏观） | 整体策略/接口 | 定义数据出域规则 | API网关 / 业务层 |
| 数据脱敏 | 字段值 | 手机号、身份证、银行卡 | DB视图 / 序列化层 |
| 字段级权限 | 列 | 用户表的敏感列隐藏 | ORM / 视图 / API |
| 行级安全策略 | 行 | 多租户数据隔离 | 数据库RLS / 业务过滤 |
常见陷阱：我曾经在审计时发现，一个系统同时启用了字段级权限和行级安全，但两者配置冲突——行级策略过滤掉了某些记录，但字段级仍然把敏感列暴露给了不该看的人。解决办法：两种策略必须统一配置管理，建议用策略引擎做交集运算。
实践建议：四步搭好输出限制
- 第一步：梳理所有对外输出接口，标记敏感字段和敏感查询条件。
- 第二步：按角色设计字段白名单和行过滤规则，优先在数据库层实现。
- 第三步：对敏感字段类型做脱敏策略，并在测试环境验证脱敏效果。
- 第四步：写审计检测脚本，定期检查API返回内容是否包含未脱敏字段。