开源堡垒机通过协议代理拦截MySQL流量实现审计与脱敏，要求所有访问必须经代理（如192.168.10.100:3307），禁直连；审计基于网络层SQL解析，脱敏靠动态重写字段，拦截需手动启用高危命令策略。
开源堡垒机（如 JumpServer）本身不修改 MySQL 服务端配置，也不依赖 MySQL 原生审计插件；它通过协议代理层拦截、解析、重写 SQL 流量来实现审计与拦截——这是关键前提，绕过代理就等于绕过审计。
必须走数据库协议代理，不能直连 MySQL
所有运维人员访问 MySQL，必须连接堡垒机提供的代理地址（如 192.168.10.100:3307），而非直接连真实数据库 IP:3306。JumpServer 的 coco 组件负责处理 MySQL 协议转发，guacamole 不参与数据库协议。
- 客户端（DBeaver / Navicat / mysql CLI）填写的主机是堡垒机 IP，端口是堡垒机开放的 MySQL 代理端口（默认非 3306，需在 JumpServer Web 界面确认）
- 真实数据库的账号密码由堡垒机托管，用户只看到“逻辑账号”，看不到后端高权限账号（如
db_admin） - 若用户仍能直连 MySQL（比如跳过堡垒机用内网 IP 连），则所有审计和拦截策略完全失效
- 确保数据库防火墙/安全组只放行堡垒机 IP 的入向连接，禁止其他来源访问 3306
审计日志靠会话级 SQL 解析，不是 MySQL 自带 general_log
JumpServer 的审计记录来自网络层捕获的原始 MySQL 协议包，逐条提取 COM_QUERY 类型指令，并结构化解析出语句类型、表名、WHERE 条件、影响行数等字段，不依赖 MySQL 的 general_log 或 audit_log 插件。
- 会话记录页面中，“数据库会话” Tab 下每条记录对应一次
mysql -h连接生命周期，含登录时间、退出时间、总命令数 - 点击详情可查看完整交互：包括认证过程、每条执行语句、返回结果集行数（但不存完整结果数据）
- 关键词筛选支持
DELETE、DROP、UPDATE.*WHERE等正则匹配，不是简单字符串查找 - 若语句被客户端预编译（如 JDBC PreparedStatement），部分 WHERE 条件可能无法还原，此时审计粒度降为“语句模板+参数个数”
脱敏靠动态 SQL 重写，不是数据库视图或应用层过滤
从 JumpServer v4.10.10 LTS 起，SELECT 查询返回结果前，系统自动识别字段名（如 id_card、mobile），注入脱敏函数（如 CONCAT(LEFT(mobile,3), '****', RIGHT(mobile,4))），整个过程在内存中完成，原始数据在数据库里始终未变。
- 脱敏规则按角色配置：DBA 角色可设为“无脱敏”，开发角色设为“手机号掩码”，审计员设为“身份证前6后4”
- 规则生效前提是字段名与预设关键词精确匹配（区分大小写），别名（
SELECT mobile AS phone）会导致匹配失败 - 聚合查询（
SELECT COUNT(*) FROM user）或子查询中嵌套敏感字段，可能跳过脱敏引擎，需结合高危操作告警兜底 - 脱敏动作本身记入审计日志，字段重写前后的 SQL 会并列展示，确保“谁看到什么”全程可追溯
拦截高危操作需显式开启策略，非默认行为
JumpServer 默认只记录，不阻断。要实现 DROP TABLE 或无 LIMIT 的 DELETE 拦截，必须在 Web 控制台手动启用“高危命令阻断”策略，并绑定到对应用户/资产组。
- 策略配置路径：
授权管理 > 命令过滤 > 新建规则，类型选“数据库”，匹配模式填^DROP\s+TABLE或^DELETE\s+FROM.*?WHERE - 注意正则语法兼容 MySQL 协议解析器，不支持 \b、(?i) 等高级特性；建议先用测试会话验证匹配效果
- 阻断动作分“告警+放行”和“告警+拒绝”两种，后者会向客户端返回
ERROR 1142 (42000): Access denied类错误 - 若用户使用客户端批量执行（如 source xxx.sql），整条文件会被当作单条命令解析，可能导致误拦或漏拦，应避免
真正难的不是配置开关，而是让所有人——包括 DBA 和开发——彻底放弃直连习惯；一旦出现“临时调试绕过堡垒机”的例外，整套审计链路就出现不可修复的盲区。
