跳板机账号严禁授予all privileges，必须遵循最小权限原则：仅限必要动态权限、精确ip/cidr限制、禁用通配符主机、启用密码策略，并明确授权指定库表的select等操作，避免权限滥用导致横向渗透风险。
跳板机（堡垒机）专用账号不能直接给 ALL PRIVILEGES，也不能用 root 或通配符主机（如 '%'@'%' ）硬套——这是最常被忽略的安全基线。
为什么不能用 GRANT ALL PRIVILEGES ON *.* 给跳板机账号
跳板机账号本质是「代理入口」，不是运维终端。它不执行交互式管理命令（如 DROP DATABASE、CREATE USER），只承担连接转发与审计上下文传递。授予全库全权等于把数据库控制台钥匙交给了跳板机本身，一旦该账号凭证泄露或跳板机被横向渗透，后果远超单个应用账号失陷。
-
RELOAD、PROCESS、LOCK TABLES这类权限必须显式声明，且仅限必要场景（如配合mydumper做一致性备份） -
SELECT ON *.*是为了能查information_schema和performance_schema，但绝不应包含INSERT/UPDATE/DELETE权限 - MySQL 8.0+ 的动态权限（如
BACKUP_ADMIN）默认不继承自ALL，盲目授权反而导致工具报错
CREATE USER 时必须限定主机和协议来源
堡垒机账号的 host 部分不能写成 '%' 或留空，必须精确到跳板机出口 IP 或 CIDR 段。例如跳板机 NAT 后的真实出口是 10.0.1.50，那就只能写 'dba_admin'@'10.0.1.50'；若跳板机集群有多个节点，需逐条添加，或使用最小必要 CIDR（如 'dba_admin'@'10.0.1.0/24'）。
- 避免用
localhost—— 跳板机基本不会走 Unix socket 连接，该 host 值会导致连接失败 - 不要依赖 DNS 反解：堡垒机配置里填的是 IP，MySQL 服务端也应禁用
skip-name-resolve，否则主机名解析失败会静默拒绝 - 密码强度必须启用验证插件：
ALTER USER 'dba_admin'@'10.0.1.50' PASSWORD EXPIRE INTERVAL 90 DAY;
JumpServer 等堡垒机对接 MySQL 时的权限映射陷阱
JumpServer 的「系统用户」配置中填写的 MySQL 账号，其权限范围决定了最终用户能访问哪些数据库。如果填的是 root，那所有库都可连；但如果填的是一个只对 finance_db 有 SELECT 权限的账号，那即使堡垒机界面上显示“已授权”，用户点开后也只能看到 finance_db，其他库连 SHOW DATABASES 都不可见。
- 堡垒机本身不校验数据库级权限，它只做连接透传。真正的权限控制仍在 MySQL server 端
- 务必在堡垒机「应用授权」环节绑定正确的「系统用户」，而非复用 DBA 的高权账号
- 若需多库访问，应在 MySQL 侧用
GRANT SELECT ON db1.* TO ...+GRANT SELECT ON db2.* TO ...显式授权，而不是靠SHOW DATABASES权限绕过
客户端工具（如 MySQL Workbench）连不通的真正原因
90% 的「Access denied for user」错误不是因为 MySQL 拒绝了账号，而是 Workbench 的 Hostname 字段填错了——这里必须填数据库服务器真实内网地址（如 10.0.2.100 或 db-prod.internal），不是跳板机地址，也不是堡垒机 Web 地址。
- SSH 隧道已通 ≠ 数据库直连地址可用。Workbench 默认走 TCP/IP，不是通过堡垒机代理 HTTP 流量
- 如果堡垒机提供的是「Web 终端」或「数据库 Web 控制台」，那根本不需要填
Hostname，那是另一套路径 - 确认
wait_timeout和connect_timeout设置合理（建议 ≥300），避免堡垒机长连接空闲断开后重连失败
最容易被绕过的其实是「权限最小化」原则：很多团队花大力气部署 JumpServer，却让跳板机账号拥有比 DBA 还高的权限。堡垒机再强，也防不住自己被当成 root 用。
