Hyperf携程MySQL生产环境安全配置加固清单-php教程-PHP中文网

Hyperf项目MySQL生产环境加固必须聚焦MySQL服务端：bind-address设为内网IP、应用账号禁用root并最小权限、启用validate_password插件设STRONG策略、DSN显式配置ssl_mode=REQUIRED，任一环节缺失均导致整体失效。

hyperf携程mysql生产环境安全配置加固清单

Hyperf 项目连接 MySQL 生产环境时，不能只靠框架层的配置“看起来安全”——真正起作用的是 MySQL 实例本身的访问控制、认证强度和网络暴露面。Hyperf 本身不干预数据库账号权限或服务监听策略，所有加固必须落在 MySQL 服务端配置与账号体系上。

bind-address 配置为内网 IP 而非 0.0.0.0

Hyperf 应用通常部署在独立服务器或容器中，与 MySQL 通过内网通信。若 MySQL bind-address 仍为默认的 0.0.0.0，等于把数据库端口（如 3306 或自定义端口）暴露给整个网络段，极易被扫描器发现并发起暴力破解。

必须修改 /etc/my.cnf 或 /etc/mysql/my.cnf 的 [mysqld] 区块：

[mysqld]
bind-address = 192.168.10.5

其中 192.168.10.5 是 MySQL 所在服务器的内网 IP（非容器网桥 IP）。改完后执行 systemctl restart mysqld，再用 ss -tlnp | grep :3306 确认监听地址已变更。

常见错误：

误设为 127.0.0.1：Hyperf 容器或远程应用服务器无法连接；
未同步更新防火墙规则：即使绑定了内网 IP，若 iptables/ufw 未放行对应源 IP，连接仍会超时；
忽略 Docker 场景：宿主机 MySQL 若绑定内网 IP，容器需用 host 网络模式或确保容器能路由到该 IP。

Hyperf 应用账号必须禁用 root 并遵循最小权限

Hyperf 的 config/autoload/database.php 中配置的 MySQL 用户，绝不能是 root，也不能拥有 ALL PRIVILEGES。一旦该配置泄露（如误传 GitHub、日志打印），攻击者可直接执行 DROP DATABASE 或读取系统表。

正确做法是创建专用账号，并精确限定库、表、IP 和权限：

CREATE USER 'hyperf_app'@'192.168.10.100' IDENTIFIED BY 'StrongPass@2026';
GRANT SELECT, INSERT, UPDATE, DELETE ON myapp_db.* TO 'hyperf_app'@'192.168.10.100';
REVOKE FILE, SUPER, SHUTDOWN ON *.* FROM 'hyperf_app'@'192.168.10.100';
FLUSH PRIVILEGES;

说明：

192.168.10.100 是 Hyperf 应用服务器的内网 IP，避免用 %；
不授 ALTER 或 DROP，防止 SQL 注入导致表结构破坏；
MySQL 8.0+ 默认插件为 caching_sha2_password，Hyperf 3.x 默认兼容，但需确认 PDO DSN 中未强制指定 mysql_native_password；
若使用连接池（如 Hyperf 的 pool 配置），账号密码泄露风险更高，更需隔离权限。

validate_password 插件必须启用且策略设为 STRONG

Hyperf 应用本身不校验 MySQL 密码强度，全依赖 MySQL 服务端。若未启用 validate_password，开发可能设出 123456 或 hyperf123 这类弱口令，暴破工具几秒即可命中。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

启用方式（MySQL 5.7+）：

INSTALL PLUGIN validate_password SONAME 'validate_password.so';
SET GLOBAL validate_password.policy = STRONG;
SET GLOBAL validate_password.length = 14;
SET GLOBAL validate_password.mixed_case_count = 1;
SET GLOBAL validate_password.number_count = 1;
SET GLOBAL validate_password.special_char_count = 1;

同时写入 my.cnf 持久化：

[mysqld]
validate_password_policy = STRONG
validate_password_length = 14
validate_password_mixed_case_count = 1
validate_password_number_count = 1
validate_password_special_char_count = 1

注意：

MySQL 8.0.4+ 使用 INSTALL COMPONENT 替代 INSTALL PLUGIN，命令不同；
Hyperf 启动时若连接失败报错 ERROR 1819 (HY000)，大概率是密码不符合当前策略，需重设；
该插件不影响已有账号，仅对新设或修改密码生效。

SSL 加密必须开启且 Hyperf DSN 显式启用

Hyperf 默认不强制加密连接，即使 MySQL 已配好 SSL，只要 DSN 中没加 &ssl_mode=REQUIRED，连接仍是明文。内网流量虽难被截获，但云厂商 VPC 或多租户环境中存在旁路风险。

先确认 MySQL 已启用 SSL：

SHOW VARIABLES LIKE 'have_ssl'; -- 必须为 YES
SHOW VARIABLES LIKE 'ssl_cert'; -- 确认路径有效
SHOW VARIABLES LIKE 'ssl_key';

然后在 Hyperf 的 database.php 中，DSN 后追加参数：

mysql:host=192.168.10.5;port=3306;dbname=myapp_db;charset=utf8mb4;ssl_mode=REQUIRED

关键点：

仅加 ssl_mode=REQUIRED 不够，还需确保 PHP 的 OpenSSL 扩展已启用，且 MySQL 客户端证书信任链完整；
若用自签名证书，Hyperf 的 PDO 不自动校验 CA，需额外配置 ssl_ca、ssl_cert 等参数，否则连接会拒绝；
性能影响极小（现代 CPU 下加解密开销可忽略），但能过等保三级“通信传输加密”项。

真正的加固难点不在某一条命令，而在于所有环节必须闭环：MySQL 配置改了，防火墙要同步；账号建了，Hyperf 的 DSN 必须立刻更新；SSL 开了，PHP 连接参数漏一个字段就形同虚设。任何一环松动，都可能让前面所有操作失效。