链式策略执行
DBNginx 的核心模型是链式策略执行。一次数据库访问进入网关后，会依次经过主体识别、资源归一、权限判断、风险识别、SQL 重写、数据保护、链路扩展和审计记录。
为什么要链式执行
数据库安全能力如果分散在应用、旁路逻辑、报表工具和数据库内部，很难统一回答：
- 谁访问了什么资源？
- 访问来自哪个业务系统或工具？
- SQL 是否高危？
- 敏感字段是否被保护？
- 输出数据是否可回溯？
- 最终动作是允许、拒绝、脱敏、加密、限流还是审批？
链式策略执行的目标，是让每个动作都可解释、可审计、可复盘。
标准执行顺序
- 接入入口：识别监听入口、协议类型和业务系统。
- 主体映射：将应用账号、个人账号、来源地址和工具类型归一为访问主体。
- 资源识别：识别目标库、表、列、SQL 动作和数据等级。
- 权限判断：按角色、来源、时间窗口、资源范围和动作类型判断是否允许。
- 风险识别：执行 SQL 防火墙、启发式攻击识别和模型识别。
- SQL 重写：按策略补充过滤条件、租户边界、路由提示或搜索改写。
- 数据保护：执行脱敏、水印、行列过滤、透明加密、密码设备调用。
- 链路扩展：必要时执行 链路动态扩展，补充上下文、路由标签或审计字段。
- 审计输出：记录主体、资源、SQL 语义、策略结果、trace id 和输出动作。
动作类型
| 动作 | 说明 |
|---|---|
| allow | 允许访问 |
| deny | 拒绝访问 |
| approve | 进入审批或人工复核 |
| rewrite | 改写 SQL 或访问计划 |
| mask | 对结果字段执行脱敏 |
| watermark | 写入可见或隐式水印 |
| encrypt/decrypt | 执行透明加解密或设备调用 |
| rate_limit | 对高风险或高成本访问限流 |
| audit | 写入审计事件 |
设计原则
- 高风险动作应优先可解释，再进入强拦截。
- 第一轮试点建议先只审计，确认误报和业务影响后再开启拒绝。
- 链路动态扩展必须服从主策略链，不能绕开权限、防火墙和审计。
- 每个策略版本都要能回滚。