1. 项目概述：为什么需要一份专项加固指南？

在当前的数字化环境中，Web应用和数据服务是绝大多数业务的核心。Nginx作为最流行的Web服务器和反向代理，MySQL作为最广泛使用的关系型数据库，它们的组合几乎构成了互联网服务的“标准底座”。然而，这个底座的稳固性，直接决定了上层业务的安全水位。我见过太多项目，业务逻辑写得天花乱坠，前端界面炫酷无比，但一扒开Nginx配置和MySQL参数，安全配置几乎处于“裸奔”状态——默认安装、空密码或弱密码、日志不开启、权限混乱。这就像把金库建在纸糊的墙上。

“等保”，即网络安全等级保护，它不是一份简单的检查清单，而是一套系统化的安全建设和管理框架。等保测评会从物理、网络、主机、应用、数据等多个层面进行审查。对于Nginx和MySQL而言，其配置直接关系到“应用安全”和“数据安全”这两个核心层面的合规性。很多团队在应对等保测评时，往往临时抱佛脚，四处搜索零散的加固命令，头痛医头，脚痛医脚，缺乏体系化的理解和可落地的操作指南，导致整改过程反复、效率低下，甚至引入新的风险。

这份指南的目的，就是基于我多年在运维和安全合规一线的实战经验，将等保2.0（尤其是二级和三级要求）中与Nginx、MySQL强相关的安全控制点，转化为具体、可逐项核对、可直接操作的配置指令和加固步骤。它不是理论空谈，而是能让你“抄作业”的实战手册。无论你是运维工程师、开发负责人还是安全专员，通过系统性地实施本指南，你不仅能有效满足等保测评的硬性要求，更能实实在在地提升服务自身的安全免疫能力，防患于未然。

2. 等保视角下的安全加固核心思路拆解

在动手修改任何一个配置文件之前，我们必须先建立正确的安全观。等保测评不是“找茬”，而是引导我们建立“持续保护”的思维。针对Nginx和MySQL的加固，我们可以从以下几个核心维度来构建防御体系：

2.1 最小权限原则：收紧每一个入口

这是安全的第一铁律。对于Nginx，这意味着：不以root权限运行工作进程；配置文件、日志目录的权限严格控制；隐藏不必要的版本信息；限制HTTP方法（如禁止TRACE、DELETE）；为不同的虚拟主机或应用分配仅够用的权限。对于MySQL，则体现在：为每个应用创建独立的数据库和专属用户，并授予其完成业务所必需的最小权限（SELECT, INSERT, UPDATE, DELETE），坚决杜绝使用root账户或拥有ALL PRIVILEGES的账户进行日常业务连接。

2.2 纵深防御：不把鸡蛋放在一个篮子里

安全不能只靠一层防护。Nginx层面，我们可以通过配置实现Web应用防火墙（WAF）的部分功能，如限制请求速率、过滤恶意User-Agent、防止SQL注入和XSS攻击的常见特征。同时，Nginx作为反向代理，其本身应与后端应用服务器（如Tomcat、uWSGI）以及数据库服务器在网络层面进行隔离，通常部署在不同的安全域或通过内网防火墙策略控制访问。MySQL则应该仅监听在内网地址上，并通过防火墙严格限制访问源IP，只有特定的应用服务器才能连接。

2.3 可审计性：留下完整的“脚印”

“雁过留声，人过留痕”。所有重要的操作和行为都必须有据可查。Nginx的访问日志和错误日志是分析攻击行为、排查问题的关键。我们需要确保日志完整开启、格式包含足够的信息（如客户端IP、请求时间、方法、URI、状态码、响应大小、Referer、User-Agent等），并妥善管理日志轮转和长期存储。MySQL的审计更为关键，必须开启通用查询日志（general_log）或慢查询日志（slow_query_log）用于行为审计，同时二进制日志（binlog）不仅是数据恢复的基础，也记录了所有数据变更，是数据安全审计的重要依据。等保明确要求审计覆盖到每个用户的重要行为。

2.4 配置安全与漏洞防范：堵住已知的“破窗”

使用稳定的官方版本，并及时更新安全补丁。禁用存在安全隐患的旧协议、弱加密算法（如SSLv2, SSLv3, TLS 1.0， MySQL的旧式密码认证）。对Nginx，要小心处理文件路径解析，防止目录遍历；对MySQL，要移除测试数据库、匿名用户等默认安装的“赠品”。这些看似细微的配置，往往是攻击者最先尝试的突破口。

基于以上思路，我们的加固工作将分为Nginx和MySQL两条主线，每条主线都遵循“身份认证与授权 -> 通信安全 -> 日志审计 -> 配置与漏洞”的流程来展开，确保覆盖全面，逻辑清晰。

3. Nginx专项安全加固配置实操

Nginx的安全加固，主要围绕其配置文件（通常是nginx.conf及其包含的conf.d/*.conf或sites-enabled/*）展开。在修改任何配置前，务必先备份原文件。

3.1 运行权限与进程隔离

默认情况下，Nginx主进程以root启动，以便绑定1024以下端口（如80、443），但工作进程（worker processes）必须以非特权用户运行。

操作步骤：

1. 创建一个专用的系统用户和组，例如nginx。

   groupadd nginx useradd -g nginx -s /sbin/nologin -M nginx

2. 修改nginx.conf主配置文件中的user指令。

   # 在main上下文（events块之前）修改 user nginx nginx; worker_processes auto; # 根据CPU核心数自动设置

3. 修改Nginx相关目录的权限，确保nginx用户有必要的读写权限。

   chown -R root:nginx /etc/nginx/ # 配置文件所有权归root，组为nginx chmod -R 750 /etc/nginx/ # root可读写执行，nginx组可读执行，其他无权限 chown -R nginx:nginx /var/log/nginx /var/cache/nginx # 日志和缓存目录归nginx用户

注意事项：

如果网站需要上传功能，上传目录的所有权应设置为运行后端应用的用户（如www-data或php-fpm用户），而不是nginx用户，并结合client_body_temp_path设置合适的临时目录权限，防止通过上传漏洞获取nginx权限。

3.2 隐藏敏感信息与减少攻击面

泄露软件版本和操作系统信息会为攻击者提供便利。

1. 隐藏Nginx版本号：在http块或server块中配置。

   server_tokens off;

2. 自定义错误页面：避免在4xx、5xx错误页面中暴露默认信息。可以设置统一的友好错误页。

   error_page 404 /404.html; error_page 500 502 503 504 /50x.html; # 并确保这些html文件存在且内容无害

3. 限制HTTP方法：通常只允许GET, HEAD, POST。

   location / { limit_except GET HEAD POST { # 限制除了GET/HEAD/POST之外的方法 deny all; } # ... 其他配置 }

4. 禁用非必要模块：在编译安装Nginx时，使用--without-http_autoindex_module禁用自动目录列表，除非业务确实需要。

3.3 传输安全与SSL/TLS强化

如果提供HTTPS服务，SSL/TLS配置是重中之重。

1. 仅使用强加密协议和套件：禁用SSLv2、SSLv3、TLS 1.0，甚至TLS 1.1。优先使用TLS 1.2/1.3。

   ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4:!DH:!DHE; ssl_prefer_server_ciphers on;

2. 启用HSTS：强制浏览器使用HTTPS连接。

   add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

   注意：includeSubDomains和preload要谨慎使用，确认所有子域名都支持HTTPS后再添加。

3. 安全的Cookie设置：

   proxy_cookie_path / "/; secure; HttpOnly; SameSite=Strict";

   这会在通过Nginx反向代理设置Cookie时，自动添加安全属性。

3.4 访问控制与请求限制

1. 限制客户端连接和请求速率：防止CC攻击和暴力扫描。

   http { limit_conn_zone $binary_remote_addr zone=perip:10m; limit_conn_zone $server_name zone=perserver:10m; limit_req_zone $binary_remote_addr zone=reqlimit:10m rate=10r/s; # 每秒10个请求 server { limit_conn perip 10; # 每个IP同时最多10个连接 limit_conn perserver 100; # 整个server同时最多100个连接 location /api/ { limit_req zone=reqlimit burst=20 nodelay; # 突发处理20个请求 proxy_pass http://backend; } } }

2. 基于IP的访问控制：对于管理后台等敏感接口，应限制访问IP。

   location /admin/ { allow 192.168.1.0/24; # 允许内网网段 allow 10.10.10.100; # 允许特定管理IP deny all; # 拒绝其他所有 # ... 代理配置 }

3.5 日志配置与安全管理

1. 确保日志开启且格式完整：

   http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log warn; # 日志级别设为warn，避免debug信息过多 }

2. 日志轮转与保护：使用系统的logrotate工具定期切割、压缩并保留一定天数的日志。确保日志文件权限正确（如640，属主root，属组adm或nginx），防止被篡改。
3. 监控关键错误：定期检查error.log中出现的permission denied、connection reset by peer以及大量4xx/5xx状态码的请求，这些可能是攻击尝试或配置问题的信号。

4. MySQL专项安全加固配置实操

MySQL的加固主要通过SQL命令修改全局变量、调整配置文件(my.cnf或my.ini)，以及执行安全审计操作来完成。操作前请务必在测试环境验证，并对生产数据库进行完整备份。

4.1 初始化安全与账户权限加固

这是最基础也最重要的一步。

1. 运行mysql_secure_installation：如果是全新安装，首先运行这个脚本。它会引导你：
   • 设置root密码。
   • 移除匿名用户。
   • 禁止root账户远程登录（极其重要）。
   • 移除测试数据库test。
2. 创建专属应用账户，遵循最小权限原则：

   -- 首先，为每个应用创建独立的数据库 CREATE DATABASE app_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; -- 创建仅能访问该数据库的用户，并限制其来源IP（例如，仅允许应用服务器IP 192.168.1.100访问） CREATE USER 'app_user'@'192.168.1.100' IDENTIFIED BY 'StrongPassword123!'; -- 授予该用户对app_db数据库的必要权限，通常不包括GRANT, FILE, PROCESS, SUPER等管理权限 GRANT SELECT, INSERT, UPDATE, DELETE, CREATE TEMPORARY TABLES, EXECUTE ON app_db.* TO 'app_user'@'192.168.1.100'; -- 立即刷新权限 FLUSH PRIVILEGES;

3. 检查并清理多余用户和权限：

   SELECT User, Host, authentication_string FROM mysql.user; -- 删除任何非必要的用户，特别是Host为'%'（任意主机）的root或高权限用户 DROP USER 'root'@'%'; -- 如果存在，务必删除！

4.2 网络与连接安全配置

1. 绑定内网地址，禁止公网监听：在[mysqld]配置段中修改。

   [mysqld] bind-address = 192.168.1.10 # 改为你的内网IP，切勿使用 0.0.0.0

2. 修改默认端口（可选但推荐）：将默认的3306端口改为其他端口，可以减少自动化扫描工具的发现概率。

   port = 33066

   注意：修改后，所有客户端连接都需要指定新端口。

3. 配置连接数限制和超时：防止资源耗尽。

   max_connections = 500 # 根据服务器资源设置 connect_timeout = 10 wait_timeout = 600 # 非交互连接超时时间 interactive_timeout = 600 # 交互连接超时时间

4.3 审计日志与安全监控

等保对审计日志有明确要求，必须开启。

1. 开启通用查询日志（用于全量审计）：此日志记录所有连接和语句，对性能影响较大，通常用于短期排查或安全事件调查，不建议在生产环境长期全量开启。如需满足等保，可考虑使用第三方审计插件或MariaDB的审计功能。

   SET GLOBAL general_log = 'ON'; SET GLOBAL general_log_file = '/var/log/mysql/general.log';

   或在配置文件中永久设置：

   general_log = 1 general_log_file = /var/log/mysql/general.log

2. 开启慢查询日志（用于性能与异常分析）：记录执行时间超过阈值的查询，有助于发现性能问题和潜在的恶意慢查询。

   slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 2 # 单位秒，超过2秒的查询被记录 log_queries_not_using_indexes = 1 # 记录未使用索引的查询（谨慎开启，可能日志量巨大）

3. 确保二进制日志开启（用于数据恢复与复制）：Binlog是数据安全的关键，必须开启。

   log_bin = /var/log/mysql/mysql-bin.log expire_logs_days = 30 # 自动清理30天前的binlog server_id = 1 # 在复制环境中需唯一

4. 日志文件权限管理：确保日志文件不被未授权访问。

   chown mysql:adm /var/log/mysql/ chmod 750 /var/log/mysql/

4.4 密码策略与加密强化

1. 启用密码复杂度策略（MySQL 5.7+ / MariaDB 10.3+）：

   -- 安装密码验证组件（MySQL 5.7/8.0） INSTALL COMPONENT 'file://component_validate_password'; -- 然后设置策略 SET GLOBAL validate_password.policy = MEDIUM; -- 或 STRONG SET GLOBAL validate_password.length = 12; SET GLOBAL validate_password.number_count = 2; SET GLOBAL validate_password.special_char_count = 1;

   在配置文件中永久生效：

   [mysqld] plugin-load-add = validate_password.so validate_password.policy = MEDIUM validate_password.length = 12

2. 确保使用安全的密码哈希算法：MySQL 8.0默认使用caching_sha2_password，比旧的mysql_native_password更安全。如果使用5.7，应确保用户不使用旧的、不安全的哈希方式。

   -- 查看用户认证插件 SELECT user, host, plugin FROM mysql.user; -- 修改用户插件（例如root用户） ALTER USER 'root'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'YourNewStrongPassword';

4.5 其他关键安全配置

1. 禁用LOCAL INFILE：防止客户端通过LOAD DATA LOCAL INFILE读取服务器上的任意文件。

   local_infile = 0

2. 禁用符号链接：防止通过数据库表符号链接到系统文件。

   symbolic_links = 0

3. 设置安全的umask：确保MySQL创建的文件和目录有安全的默认权限。

   [mysqld] umask = 0027 # 创建的文件权限为640，目录为750

5. 加固后的验证与持续监控

配置修改完成后，绝不能一改了之，必须进行严格的验证。

5.1 配置验证清单

Nginx验证：

1. 语法检查：nginx -t
2. 重载配置：systemctl reload nginx(确保服务不中断)
3. 检查进程运行用户：ps aux | grep nginx，确认worker进程以nginx用户运行。
4. 测试信息隐藏：访问一个不存在的页面，查看错误响应头是否包含Server: nginx。
5. 测试HTTPS：使用openssl s_client -connect yourdomain.com:443 -tls1_2或在线工具（如SSL Labs）检查SSL/TLS配置是否安全。
6. 测试访问控制：尝试从非授权IP访问管理后台，应被拒绝。

MySQL验证：

1. 重启或重载MySQL服务：systemctl restart mysql(或mysqld)
2. 使用应用账户从指定IP登录测试：mysql -u app_user -p -h 192.168.1.10 -P 33066
3. 尝试远程用root登录：mysql -u root -p -h <公网IP>，应该被拒绝。
4. 检查日志是否正常生成：查看/var/log/mysql/error.log,general.log(如果开启)，slow.log。
5. 运行安全审计脚本：MySQL自带mysql_secure_installation，也可以使用像mysqltuner.pl这样的第三方脚本进行安全检查和建议。

5.2 持续监控与应急响应

安全加固是一个持续的过程，不是一次性的任务。

1. 日志监控：使用ELK Stack、Graylog或Loki+Promtail+Grafana等工具集中收集、分析Nginx和MySQL的日志。设置告警规则，例如：
   • Nginx：短时间内同一IP产生大量5xx或4xx错误。
   • MySQL：出现大量失败的登录尝试、Access denied错误、或执行时间极长的慢查询。
2. 定期漏洞扫描与配置复查：定期使用Nessus、OpenVAS等工具对服务器进行漏洞扫描。每季度或发生重大变更后，重新对照本指南的检查项进行配置复查。
3. 备份与恢复演练：确保MySQL的备份策略（物理备份+逻辑备份+binlog）有效，并定期进行恢复演练。Nginx的配置也应纳入版本控制系统（如Git）进行管理。
4. 建立变更管理流程：任何对生产环境Nginx/MySQL配置的修改，都必须经过申请、评审、测试、实施的流程，并记录在案。

6. 常见问题与排查技巧实录

在实际操作中，你肯定会遇到各种“坑”。这里记录了几个典型问题和我的解决思路。

6.1 Nginx配置错误导致服务不可用

问题：修改配置后，nginx -t测试通过，但systemctl reload nginx后网站无法访问，systemctl status nginx显示服务是active (running)。排查：

1. 检查错误日志：第一时间查看error.log(tail -f /var/log/nginx/error.log)，这里通常有最直接的错误信息。
2. 检查端口监听：netstat -tlnp | grep nginx或ss -tlnp | grep nginx。确认Nginx是否成功监听了80/443端口。如果没有，可能是与旧进程冲突或权限问题。
3. 检查SELinux/AppArmor：在RHEL/CentOS或Ubuntu等高安全发行版上，安全模块可能会阻止Nginx绑定端口或访问日志文件。可以暂时将其设为宽容模式测试：setenforce 0(SELinux) 或sudo aa-complain /usr/sbin/nginx(AppArmor)。如果问题解决，则需要添加正确的安全上下文或策略，而不是永久关闭它。
4. 回滚与二分法：如果以上都无果，最有效的方法是回滚到上一个可用的配置。如果修改点很多，采用“二分法”，注释掉一半修改，重载测试，逐步定位问题配置行。

6.2 MySQL无法远程连接或权限错误

问题：应用服务器无法连接到MySQL数据库，报错 “Host ‘xxx.xxx.xxx.xxx’ is not allowed to connect”。排查：

1. 确认用户权限：在MySQL服务器上登录，执行SELECT user, host FROM mysql.user WHERE user='app_user';。确保host字段精确匹配应用服务器的IP地址或通配符%（不推荐）。localhost和127.0.0.1在MySQL中是不同的。
2. 检查绑定地址：确认my.cnf中的bind-address不是127.0.0.1，并且服务器防火墙（如firewalld, iptables）允许了从应用服务器IP到MySQL端口（默认3306或自定义端口）的流量。
3. 检查密码插件：MySQL 8.0的caching_sha2_password插件可能被一些老的客户端（如某些PHP版本）不支持。可以尝试将用户认证插件改回mysql_native_password，但这会降低安全性。更好的方案是升级客户端或驱动。

   ALTER USER 'app_user'@'192.168.1.100' IDENTIFIED WITH mysql_native_password BY 'password';

6.3 开启日志后磁盘空间暴涨

问题：开启了MySQL的general_log或slow_log，或者Nginx访问量巨大，导致日志文件迅速占满磁盘。应对：

1. 立即清理或轮转：
   • Nginx:logrotate -f /etc/logrotate.d/nginx或手动清空access.log(echo > /var/log/nginx/access.log)。
   • MySQL: 对于通用日志，可以临时关闭SET GLOBAL general_log = 'OFF';，然后安全地删除或移动旧日志文件。切勿直接删除正在被MySQL写入的日志文件。
2. 调整日志策略：
   • Nginx: 在log_format中考虑精简字段；对于静态资源请求，可以在location块中使用access_log off;来关闭日志。
   • MySQL:general_log仅用于临时调试，切勿长期开启。slow_query_log的long_query_time可以适当调大（如从2秒调到5秒），并谨慎开启log_queries_not_using_indexes。
3. 设置监控告警：对/var/log和/等关键分区设置磁盘使用率告警（如 >80%），这是运维的基本功。

6.4 性能与安全的平衡点

安全配置往往会带来一定的性能开销，需要找到平衡。

• Nginx的limit_req/limit_conn：限制过于严格会误伤正常用户，过于宽松则失去防护意义。需要根据业务实际QPS和用户行为模式，通过监控日志来调整rate和burst参数。对于API，可以设置得严格一些；对于首页等静态资源，可以放宽或不做限制。
• MySQL的密码验证插件：validate_password的STRONG策略会要求非常复杂的密码，可能增加用户管理难度。对于内部系统，MEDIUM策略通常已足够。关键在于杜绝弱密码和默认密码。
• SSL/TLS加密：会消耗CPU资源。对于性能敏感的内网服务，如果网络环境完全可信，可以考虑不使用TLS。但对于任何经过公网或涉及敏感数据的传输，TLS是必须的，性能开销可以通过硬件加速（如支持AES-NI的CPU）来缓解。

安全加固没有一劳永逸的银弹。它始于一套严谨的配置，成于持续的监控、审计和应急响应。这份指南为你提供了满足等保要求和提升实战安全性的具体路径，但真正的安全，源于对这套体系和其中每一个配置项背后原理的深刻理解，以及将其融入日常运维血液中的习惯。每次变更前多问一句“这安全吗？”，每次告警后多查一步“根本原因是什么？”，你的系统就会在攻防的拉锯中变得越来越稳固。