运维管控网关：安当DBG如何把DBA这个不可信边界立起来

“我们的数据库很安全只有 DBA 能直连。”——这句话恰恰是很多数据泄露故事的开头。一、DBA 是传统架构里最大的不可信边界DBA 掌握数据库最高权限能直连、能全量导出、能绕过应用层所有权限控制。在内部人视角下这不是信任而是风险离职员工用残留权限批量导出客户名单外包运维在排障时顺手看了不该看的表账号共享出了事谁都追溯不到。传统做法靠人靠谱 审计日志但日志往往是事后补救且 DBA 自己就能改日志。二、运维管控网关的思路让运维看得到库看不到明文运维管控网关部署在运维人员与数据库之间逻辑很直接唯一入口数据库只允许网关 IP 访问从网络层杜绝直连强制脱敏运维查出来的结果敏感字段自动变成138****1234这类脱敏形态库里数据没改运维始终接触不到真实明文全量审计谁、何时、执行了什么 SQL、看到了什么数据全部记录高危拦截DROP TABLE、DELETE等高危操作可自动拦截或触发审批。关键区别它不改变数据库存储库里仍是明文应用模糊查询完全不受影响只管控运维这条通道的输出。这与透明加密网关改存储互补形成存储层 访问层双层防护。以安当 DBG 的运维管控模式为例它强制 DBA、运维、外包经网关访问按运维账号权限对查询结果自动脱敏或加密返回数据库配置仅允许网关 IP 直连同时全量记录 SQL 操作并支持高危语句拦截——把特权账号不可信从口号变成机制。三、为什么这比改应用权限更管用应用层权限控制管不到用客户端直连的人。运维管控网关把判定下沉到数据库访问层无论访问来自 Navicat、命令行还是应用规则统一生效。这正是它和单纯应用里做权限的本质差异。四、落地要避开的两个坑别只审计不拦截日志留痕是底线但对DROP/TRUNCATE这类高危操作应有实时拦截或审批而不是等出了事再查日志。脱敏规则要跟着合规走手机号、身份证、银行卡的脱敏规则不一样要按字段集中配置别硬编码在脚本里。方案参考安当 DBG 数据库加密网关的运维管控模式以 SQL 协议代理工作覆盖 MySQL、Oracle、达梦、人大金仓等几乎不限数据库类型把 DBA 直连收敛为受控脱敏通道并提供语句级高危拦截与完整审计。对库不能改、但运维通道必须收口的金融、医疗、政务场景可作为落地参考。注本文为技术解析具体兼容数据库与拦截策略以官方文档 doc.andang.cn 为准。