零信任下MySQL访问控制必须升级为每次查询前动态验证，核心是剥离DB自身认证职责，交由外部PEP拦截并基于mTLS、JWT、设备状态、时间等多维属性实时决策，禁用静态IP白名单和GRANT，启用MySQL防火墙或代理层SQL防护，并确保审计日志与策略决策日志通过request_id对齐。
零信任架构下，MySQL 不能只靠 GRANT 和 IP 白名单撑场面——那些配置在横向移动、凭证泄露或云环境动态扩缩容时基本失效。必须把访问控制从“连接层静态放行”升级为“每次查询前动态验证”，核心动作是：剥离数据库自身的认证授权职责，交由外部策略执行点（PEP）拦截并决策。
MySQL 连接必须强制 mTLS + JWT 身份透传
传统 CREATE USER 'app'@'10.20.30.%' 的方式已不满足零信任要求。真实生产中，所有客户端连接 MySQL 前，必须先通过 PEP（如 Envoy + Istio 网关或专用数据库代理）完成双向 TLS 认证，并将用户身份、设备指纹、会话令牌等上下文注入连接元数据。
- MySQL 8.0+ 支持
authentication_policy配合外部插件（如mysqlx+ OAuth2 代理），但更推荐用 PEP 统一处理，避免在 DB 层混入业务逻辑 - 禁止使用
'%'通配主机，'app'@'localhost'仅用于本地调试；生产一律走 PEP 出口 IP 或服务身份标识（如 SPIFFE ID） - 连接字符串中不得携带明文密码；改用短期有效的 JWT 令牌，由 PDP 动态签发并绑定设备健康状态（EDR 报告）、地理位置、时间窗口等条件
权限模型必须从 RBAC 切换到 ABAC + 动态策略下发
MySQL 原生的 GRANT SELECT ON db.table TO 'role_x' 是静态的、粗粒度的，无法响应“财务专员在非工作时间访问客户表”这类场景。零信任要求权限判断发生在每次 SQL 执行前，且依据多维属性实时计算。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 策略定义需脱离 MySQL，写在 MCP 控制平面或 Headscale ACL 文件中，例如：
allow if user.role == "finance" and device.compliant == true and time.hour in [9,18] - PEP 在拦截到
SELECT * FROM customers时，提取请求中的 JWT 声明、客户端证书 SAN 字段、HTTP 头（若走代理）、甚至调用设备健康检查服务 API，再向 PDP 查询是否允许 - 不要试图在 MySQL 内部用存储过程或触发器模拟 ABAC——性能差、不可审计、与零信任“控制面与数据面分离”原则相悖
SQL 级防护必须启用 MySQL Enterprise Firewall 或开源替代方案
零信任不是只管“谁连进来”，更要管“进来后想干什么”。MySQL 自带的防火墙模块可学习合法语句模式，对异常语法（如含 UNION SELECT、SLEEP()、LOAD_FILE()）实时阻断，这是对抗 SQL 注入的最后一道动态防线。
- 启用步骤分三步：
INSTALL PLUGIN mysql_firewall SONAME 'mysql_firewall.so'→SET GLOBAL mysql_firewall_mode = 'RECORDING'（先记录基线）→ 观察 24 小时后切为'PROTECTING' - 注意：该插件不支持 MySQL 5.7 以下版本；云数据库（如 AWS RDS）默认禁用，需确认是否开放插件管理权限
- 若无法启用原生防火墙，可用
ProxySQL或Vitess替代，在代理层做 SQL 解析与规则匹配，但需额外维护规则库和语句特征提取逻辑
审计日志必须与策略决策日志对齐，且保留原始上下文
零信任的“始终验证”意味着每一次拒绝都必须可追溯。MySQL 的 general_log 或 slow_query_log 只记录 SQL 文本，不包含是谁、在哪台设备、用什么令牌发起的——这会导致审计断链。
- PEP 必须在拦截时打上完整上下文标签，例如：
X-Request-ID: req_abc123、X-Auth-Subject: spiffe://example.org/app/payment、X-Device-Status: compliant - MySQL 审计日志（
audit_log插件）需开启audit_log_format = JSON，并确保 PEP 将上述头信息透传至audit_log_connection_policy字段 - 关键陷阱：很多团队只查 MySQL 日志里“谁查了什么”，却忽略 PDP 日志里“为什么拒绝/允许”——两个日志流必须用同一
request_id关联，否则合规检查（如等保2.0、GDPR）直接不通过
最常被跳过的环节是设备健康状态与数据库访问的联动。一个已越狱的 iOS 设备、未打补丁的 Windows 主机、或缺失 EDR agent 的终端，即使拥有有效 JWT，也应被策略引擎实时拒绝——这点在 MySQL 场景中容易被当成“基础设施问题”而搁置，但它恰恰是零信任区别于传统 MFA 的关键分水岭。
