简介一份面向数据库运维与安全管理技术人员的数据库安全加固手册围绕 MySQL、Oracle、SQL Server、PostgreSQL、Redis 五种主流数据库逐项梳理用户与密码配置、权限管理、通信加密、日志审计、文件权限等关键安全控制点并给出可执行的操作步骤与配置建议。资源包内含单个 docx 文档大小约四点七八兆字节内容按数据库类型分章编写兼备查询手册、自检清单与加固实施指引三种用途。已有二百三十二人学习下载。文档除了说明每类数据库的加固要点还专门设置了问题复现、异常信息与查询结果对照的案例模块例如禁止 root 远程登录、限制 guest 账户访问、配置密码策略等依据这些案例运维人员可在生产环境中有针对性地开展安全评估、风险排查与加固落地整体是一份注重实战操作的数据库安全参考资料。1. 数据库安全加固手册先想清楚五项基础再动手这份《数据库安全加固手册》把 MySQL、Oracle、SQL Server、PostgreSQL、Redis 五类库的安全加固项全部列了一遍。我的阅读方式是先用它定位风险点再生成具体执行命令最后回归生产环境逐步验证。它的价值在于把等保里那些抽象要求——身份鉴别、访问控制、安全审计、资源控制——翻译成了一条一条可以直接执行的配置覆盖面到 MySQL root 远程登录、SQL Server guest 账户、Redis 高危命令重命名这种颗粒度适合数据库运维、安全管理岗的从业者是那种放工位上随时能翻的“操作底稿”。阅读中有一点很实用每条加固都有“预期结果”执行完可以直接核对不用靠猜确认。2. MySQL 十七条加固项把权限边界和明文风险一起堵住2.1 先处理命令行历史和 test 库把最容易漏的入口封住手册第一部分就直接指向.mysql_history这个隐蔽文件。MySQL 客户端在交互模式下会把 SQL 语句写入该文件密码若是在命令行里直接拼进-p后面的明文等于把密码留在磁盘上。手册给的解法很干脆删除历史文件把MYSQL_HISTFILE重定向到/dev/null再做一个软链接兜底。我一般会做成三步find / -name .mysql_history 2/dev/null rm -f /root/.mysql_history echo export MYSQL_HISTFILE/dev/null /etc/profile ln -s /dev/null /root/.mysql_history这里有一个关键点软链接只对当前用户生效如果你有多个运维账号需要为每个账号执行第三步。2/dev/null是防止 find 在无权限目录报错刷屏但注意如果服务器上存在多个实例或多个用户家目录这条命令会把所有历史文件找出来需要逐个清理只处理$HOME路径会漏。接着要清理的是默认安装自带的 test 库和匿名账号。这一点在生产环境很容易被忽略。手册里给的命令组合是DROP DATABASE IF EXISTS test; SELECT user, host FROM mysql.user WHERE user ; DROP USER localhost;注意DROP USER这一步删匿名用户前先做查询确认防止误删了某个实际被业务使用的账号虽然正常业务不应该用匿名账号但有些历史系统就是这么干的。我在执行这类操作前会先做一次mysqldump全量备份不是因为它有风险而是 DROP 类的操作不支持回滚备份是唯一的后悔药。2.2 root 账号远程登录、old_passwords 与 secure_auth手册第 6 条是禁止 root 远程登录操作核心是把 root 的 host 从%改成localhostUSE mysql; UPDATE user SET host localhost WHERE user root AND host %; FLUSH PRIVILEGES;这里必须提醒一句如果业务上确实有跨机连接 MySQL 的需求先创建一个专用账号再执行这条 SQL否则应用会直接断连。手册后面也写了最小权限分配把 DML/DDL 操作授权收窄到具体库和表这是配套动作不能只堵 root 不建专用账号。接着是密码生命周期相关。old_passwords表示是否允许旧版 16 位密码哈希格式这个参数在 MySQL 5.6 以后基本默认关闭。我通常执行如下命令检查SHOW VARIABLES LIKE old_passwords; SHOW VARIABLES LIKE secure_auth;只要两处值分别是OFF和ON即可判定为合规。secure_auth开启后客户端如果走老密码认证协议会被拒绝。这个参数在 5.7 之后已经强制开启但在 5.6 时代是真正的翻车点有些老监控脚本用的是旧驱动一开secure_auth全部连不上。所以执行前先排查客户端版本尤其是跑在 Windows 上的旧应用。2.3 secure_file_priv 参数为什么 SELECT INTO OUTFILE 报 1290手册里专门写了问题复现执行SELECT * FROM user INTO OUTFILE d:/ent.txt时返回错误 1290。这类报错我在日常运维中见过太多次根因就是secure_file_priv限制了导入导出路径。MySQL 8.0 在 Windows 安装时默认值形如C:\ProgramData\MySQL\MySQL Server 8.0\UploadsLinux 下经常是空的或指向某个 upload 目录。关键点在于这个参数不能用SET GLOBAL在线修改必须改配置文件重启实例。[mysqld] secure_file_priv /var/lib/mysql-files参数值有三种语义NULL表示完全禁止导入导出具体路径表示只允许操作该目录下文件不设置表示不限制。从等保合规角度建议配置为具体路径。但如果业务有临时导出数据的需求要先把导出目录指向业务约定路径再设置secure_file_priv否则第二天业务就会来敲门。另外目录权限要控制不能是 777一般给 mysql 用户可读写即可。还有一个容易忽略的细节secure_file_priv只影响LOAD DATA INFILE、SELECT ... INTO OUTFILE和LOAD_FILE()不影响mysqldump和 binlog所以很多人以为导出报表没问题就等于安全这是个黑匣子误区。2.4 中继日志与主从信息relay_log_info 明文存储问题手册第 10 条的关注点比较专业MySQL 主从复制里master 状态和 relay log 状态默认以文件形式存储relay-log.info是明文文件存在被读取的风险。手册建议把这两个仓库改成表存储[mysqld] master_info_repository TABLE relay_log_info_repository TABLE relay_log_recovery ON这个配置解决的是日志文件被篡改或泄露的问题但会有一个副作用mysql库下会多出两个表slave_master_info和slave_relay_log_info备份脚本要确认是否包含了这两个表。relay_log_recovery开启的作用是slave重启后自动丢弃未同步的 relay log避免崩溃恢复时回放错位。手册特意标注了一句话“有的数据库不支持这些参数改的时候要慎重”。MySQL 5.6 以下版本不识别这些选项配置文件里写上会导致实例启动失败。所以改之前先看版本。2.5 监听地址、binlog 清理与 local_infile三个容易被放过的默认值监听地址这条规则直指默认配置的风险bind_address不设置时默认值为*等于对所有网络接口开放。加固要求改成具体业务 IPbind-addressServerIP。这里有一个运维上的坑如果服务器有多块网卡只绑定一个 IP 会导致从另一个内网 IP 访问被拒绝。我的做法是如果业务只走内网网卡就绑定该网卡 IP不要把公网 IP 配进来。binlog 清理策略对应expire_logs_days参数等保要求不能为0。手册原文建议[mysqld] expire_logs_days 7但注意 8.0 及以上推荐使用binlog_expire_logs_seconds替代过期天数参数单位是秒。我一般写binlog_expire_logs_seconds 604800与 7 天对应。两个参数同时在低版本就是只认expire_logs_days高版本两个都认但如果两个都设置了MySQL 5.7 会报参数冲突警告得先查版本再动手。local_infile这条默认值为ON在 MySQL 官方文档中也存在手册强调要改为0防止加载客户端本地文件到表中。这个参数对老业务有影响某些报表系统从本地导入文件依赖它改之前先确认业务是否有此类需求常见做法是单独给报表库保留这个开关核心业务库直接关闭。[mysqld] local_infile 0另外通信加密这一条查看have_opensslYES是前提如果编译时没带 SSL 支持客户端认证信息仍然以明文走网络。我一般会用SHOW VARIABLES LIKE ssl%检查证书配置并在 my.cnf 的[client]段设置ssl_verify_server_cert。3. SQL Server 与 Oracle身份鉴别、角色最小化和加密传参3.1 SQL Server 登录名属性先查空密码和弱口令手册针对 SQL Server 2008 给的第一条加固就是身份鉴别关键操作在 SSMS 管理界面打开“安全性”“登录名”逐一查看属性勾选“强制实施密码策略”。这项操作的直接作用是让 Windows 密码策略作用于 SQL 登录名。但有一个细节很多运维直接手动建账号忘了密码过期策略导致数据库账号永不过期。用 T-SQL 可以更彻底地检查所有登录名的is_policy_checked和is_expiration_checked状态SELECT name, is_policy_checked, is_expiration_checked FROM sys.sql_logins;如果查询结果出现0需要用 ALTER LOGIN 补齐ALTER LOGIN [sa] WITH CHECK_POLICY ON, CHECK_EXPIRATION ON;这里的CHECK_EXPIRATION要依赖CHECK_POLICY开启后才能生效。仅勾选策略但密码本身过于简单也没有意义所以先在一个测试实例上验证策略组合是否生效再批量处理。3.2 通讯协议加密远程管理时防止鉴别信息被窃听手册要求在 SQL Server 配置管理器里把“强行加密”ForceEncryption设为“是”。这一步的准确操作路径是SQL Server 配置管理器 → SQL Server 网络配置 → MSSQLSERVER 的协议 → 右键属性 → 标志 → 强制加密。设置完成之后实际效果是所有客户端连接都被 TLS 加密。这里有个连环问题证书不是自动颁发默认情况下 SQL Server 2008 会使用自签名证书如果客户端机器不信任该证书连接会直接失败。生产环境更稳妥的做法是先把 CA 签发的证书装上再开启强制加密否则应用大面积连不上时回滚配置还要重启 SQL Server 服务。还有一个参数容易被忽略登录名属性里的“强制更改密码”。新账号默认勾选但有些脚本化创建的账号会把它取消掉这类账号存在被“开着原密码一直用”的风险。3.3 访问控制guest 账户与数据库角色降权实操手册第二条访问控制核心是 guest 账户权限。guest 账户默认存在于每个用户数据库中但在 master 和 tempdb 之外的其他数据库上通常应该禁用。执行逻辑如下USE [业务数据库]; REVOKE CONNECT FROM GUEST;这里有个常见的“权限反弹”问题某些数据库里存在映射到 guest 的孤立用户比如从其他实例迁移过来时登录名和数据库用户映射丢失应用恰好是通过 guest 账户在访问数据库。所以加固前用下面这条 SQL 检查每个库的孤立用户EXEC sp_change_users_login Action Report;查到孤立用户后先修正映射再降 guest 权限。顺序错了业务会先挂掉然后你才知道有孤立用户。数据库角色最小权限的检查手册建议在“数据库角色允许”里逐个取消不需要的角色。用 T-SQL 实现效率更高以db_owner为例USE [业务库] EXEC sp_rolemember db_owner, 应用账号反过来可以先查询现状SELECT DP1.name AS DatabaseUser, DP2.name AS DatabaseRole FROM sys.database_role_members AS DRM JOIN sys.database_principals AS DP1 ON DRM.member_principal_id DP1.principal_id JOIN sys.database_principals AS DP2 ON DRM.role_principal_id DP2.principal_id WHERE DP2.name db_owner;如果业务账号出现在结果里但业务并不需要建表、改表结构权限就应该移除或降级为db_datareaderdb_datawriter。注意存储过程如果用了EXECUTE AS或者动态 SQL 会绕开显式授权这种情况只降角色还不够还要检查数据库的TRUSTWORTHY属性是否开启。3.4 Oracle 加固删除冗余账号、限制远程登录与密码策略手册在 Oracle 部分首先强调“删除无用多余的账号”。清理之前先查有哪些账号存在SELECT username, account_status, created FROM dba_users ORDER BY created;如果看到SCOTT、HR这类示例账号还在且是OPEN状态基本可以确认是默认安装的存量。删除前要做两件事一是确认没有应用引用这些账号二是检查审计记录里是否有该账号的登录记录。口令为空的账号这类属于高危对象只要存在就相当于数据库裸奔。限制超级管理员远程登录Oracle 的做法和 MySQL 不同。MySQL 是把 root 的 host 改成 localhostOracle 是靠sqlnet.ora里的SQLNET.AUTHENTICATION_SERVICES和REMOTE_LOGIN_PASSWORDFILE配合控制。常见的做法是SQLNET.AUTHENTICATION_SERVICES (NONE, NTS) REMOTE_LOGIN_PASSWORDFILE EXCLUSIVEREMOTE_LOGIN_PASSWORDFILE NONE可以禁止远程 sysdba 登录但本地 ASM 实例或某些备份工具会受影响。需要先确认备份软件是用普通账号连库还是用 sys 账号如果是后者这个参数不能直接设成 NONE否则备份策略直接失效。根据账号分配最小权限Oracle 的原则是“不授予超过业务所需的系统权限和对象权限”。排查时用这条 SQLSELECT grantee, privilege, admin_option FROM dba_sys_privs WHERE grantee NOT IN (SYS,SYSTEM) ORDER BY grantee;如果发现业务账号拥有DROP ANY TABLE、DELETE ANY TABLE级别的权限基本可以判定为越权。回收权限的命令是REVOKE DROP ANY TABLE FROM 用户名;注意admin_option列如果为YES回收时要同时考虑级联影响该用户可能已经把权限转授给了其他账号。处理这种问题要先查dba_sys_privs有没有从属授权而不是直接执行 REVOKE。Oracle 密码策略配置集中在PROFILE中。默认的DEFAULTprofile 如果被改坏了会影响到所有账号。推荐的配置项如下ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LOCK_TIME 1 PASSWORD_LIFE_TIME 90 PASSWORD_GRACE_TIME 7 PASSWORD_REUSE_MAX 10 PASSWORD_REUSE_TIME UNLIMITED;这里几个参数的含义是FAILED_LOGIN_ATTEMPTS控制最大失败登录次数超过后账号锁定PASSWORD_LOCK_TIME指定锁定时长PASSWORD_LIFE_TIME控制密码有效期PASSWORD_GRACE_TIME是宽限期PASSWORD_REUSE_MAX和PASSWORD_REUSE_TIME防止重复使用旧密码。设置后检查SELECT * FROM dba_profiles WHERE profile DEFAULT AND resource_name IN (FAILED_LOGIN_ATTEMPTS,PASSWORD_LIFE_TIME);启动数据字典保护对应O7_DICTIONARY_ACCESSIBILITY参数等保要求设置为FALSE它的作用是禁止拥有ANY权限的非 sys 用户访问数据字典表。可以用SHOW PARAMETER O7_DICTIONARY_ACCESSIBILITY查看如果为TRUE要改。连接加密方面Oracle 从 12c 开始支持NETWORK_ENCRYPTION_ALGORITHM等高级选项老版本则依赖sqlnet.ora配置SQLNET.ENCRYPTION_SERVER REQUIRED SQLNET.ENCRYPTION_TYPES_SERVER (AES256, AES192)配置修改后需要重启监听和服务才能生效这一点经常被人忽略改完参数发现连接还是明文。4. PostgreSQL 与 Redis从 pg_hba 到高危命令重命名4.1 PostgreSQL 身份鉴别先看 pg_hba.conf 的 auth-methodPostgreSQL 的访问控制核心在pg_hba.conf也就是那个“谁可以从哪里以什么方式访问哪个库”的配置文件。很多运维初次接触会去改postgresql.conf里的listen_addresses改完发现外部还是连不上原因就是pg_hba.conf没放行。grep -E ^(local|host) $PGDATA/pg_hba.conf正常返回的记录auth-method列应该是scram-sha-256、md5或peer等。如果出现trust表示该网段可以免密登录这是绝对的高危项。以/0加trust的组合最典型基本上等同裸奔。先把所有非本地的trust改成scram-sha-256sed -i s/trust/scram-sha-256/g $PGDATA/pg_hba.conf这行命令不能直接在生产环境执行因为trust也可能出现在正常配置里有些单机环境用 trust。我在生产环境一般先备份再手动逐行修改不用 sed 一把梭。另外 PostgreSQL 10 之前用的是md5如果数据库里有老客户端依赖 md5 连接改成scram-sha-256会导致老驱动认证失败。正确做法是先在测试环境验证驱动兼容性。4.2 PostgreSQL 访问控制最小权限和对象属主手册里 PostgreSQL 加固部分也强调最小权限。我先列出所有角色的权限SELECT rolname, rolsuper, rolcreaterole, rolcreatedb, rolcanlogin FROM pg_roles;如果查出业务账号是rolsuper需要立刻调整。去掉超级用户属性的命令ALTER ROLE 业务账号 WITH NOSUPERUSER;为业务账号做最小授权时我通常的做法是只对指定 schema 授权GRANT USAGE ON SCHEMA 业务schema TO 业务账号; GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA 业务schema TO 业务账号; ALTER DEFAULT PRIVILEGES IN SCHEMA 业务schema GRANT SELECT ON TABLES TO 业务账号;这三条分别控制可用 schema、现有表权限、未来新建表的默认权限。很多人漏了第三条导致 DBA 新建表后业务账号没权限访问反过来又给账号加了过宽权限这是一个典型的“绕圈踩坑”场景。4.3 PostgreSQL 安全审计与连接控制开启 PostgreSQL 审计需要调整postgresql.conf中的log_destination stderr logging_collector on log_directory pg_log log_connections on log_disconnections on log_statement ddllog_statement ddl比all更实用。all会记录所有 SELECT 语句在高并发系统上会把日志目录写爆ddl能记录对结构的修改满足审计要求但不至于刷盘。参数修改后需要pg_ctl reload而不是重启reload 能加载多数配置但logging_collector这个参数必须重启才能生效需要把这两类参数分开处理。连接超时方面用idle_in_transaction_session_timeout控制事务中空闲连接idle_in_transaction_session_timeout 60000单位是毫秒这里设置为 60 秒。这个参数能防止应用开启事务后长时间不提交拖垮连接池。但注意长事务的业务比如批量导入会被它打断需要按业务调整。数据备份恢复部分要单独验证pg_dump的可行性和恢复流程不能只确认 crontab 里有备份脚本就觉得安全了。4.4 Redis 加固先从服务账号、密码认证和保护模式说起Redis 这一章手册从服务账号管理开始。Redis 官方手册建议不要以 root 运行但很多安装教程为了省事直接 root 启动。正确的做法是创建专用账号useradd -r -s /sbin/nologin redis chown -R redis:redis /var/lib/redis /var/log/redis su -s /bin/sh -c redis-server /etc/redis/redis.conf redisnologin这个 Shell 确保了该账号只能运行 Redis 进程不能交互登录。这比单纯“别用 root”更进一步是一个实用的最小权限设计。开启密码认证对应配置文件中的requirepassrequirepass 这里写长随机密码这个密码建议用openssl rand -base64 32生成不要自己编。服务重启后验证redis-cli -a 密码 ping但要注意redis-cli -a会在进程列表里暴露明文密码而且 bash history 里也会留下记录。更安全的方式是连接后用AUTH命令或者用环境变量配合-a。然后是protected-mode这是 Redis 3.2 引入的保护机制。当protected-mode yes且没有bind具体 IP、没有设置requirepass时Redis 只允许回环地址连接外部请求会被拒绝。这里有个拦路坑如果配置文件里protected-mode no同时又没配密码那 Redis 就基本暴露了。必须确认以下三者之一是安全的protected-mode yes、设置了requirepass、bind了内网 IP。三者都不满足就赶紧改配置。4.5 Redis 绑定监听 IP、端口与高危命令重命名绑定 IP 在配置文件中这样写bind 192.168.1.10 127.0.0.1这里有一个常见的细节多个 IP 用空格分隔不是逗号。配置文件改动后需要重启 Redis 服务。如果只改bind不重启不生效这个问题会让很多人误以为改了没用。检查当前生效配置用redis-cli CONFIG GET bind redis-cli CONFIG GET port修改默认端口 6379 为高位端口比如 16379能在扫描阶段减少被自动化工具命中的概率。这对内网自动化扫描是有效果的不过它不是安全边界只算基线防御真正兜底还是靠密码和网络隔离。高危命令重命名是 Redis 加固里操作感和效果最明显的一条。常见做法是在配置文件中加rename-command FLUSHALL rename-command FLUSHDB rename-command EVAL uuid替换字符串被留空字符串后该命令被完全禁用EVAL被替换成随机字符串后等于让扫描器找不到原命令名。有一个坑Redis Cluster 模式下EVAL等 Lua 相关命令被重命名可能导致集群节点间通信失败AOF 重放时如果 AOF 里记录的是原命令名同样会造成问题。所以对集群环境谨慎处理EVAL一般只禁FLUSHALL和FLUSHDB。重命名之后原EVAL命令不可用应用里如果用了 Lua 脚本会直接报错要先确认应用是否依赖EVAL。4.6 Redis 配置文件权限、日志目录与连接超时Redis 配置文件包含明文密码权限如果太大相当于把密码放在门口。加固chmod 640 /etc/redis/redis.conf chown redis:redis /etc/redis/redis.conf这里从 600 升级为 640 是考虑到 redis 组内有其他进程需要读取配置如果没这个需求用 600 更稳。手册里推荐配置本地日志存储目录做法是在配置文件中设置logfile /var/log/redis/redis-server.log dir /var/lib/redisdir参数决定持久化文件RDB/AOF的存放路径同时也会影响日志路径的相对解析平时很难注意出问题时才知道这个参数的含义。连接超时设置timeout 300单位是秒这里设置为 300 秒。Redis 的timeout参数是空闲连接关闭时间不是连接建立超时。如果应用有长连接需求300 秒可能会把空闲连接杀掉但连接池会自动重连一般影响不大。手册第 1.9 条的诉求在防止空闲连接长期占用资源。5. 加固后必看的几个坑参数不支持、版本差异与重启陷阱5.1 参数不支持MySQL 5.6 起不来Redis 集群 EVAL 被禁现象在 MySQL 5.6 实例上配置master_info_repositoryTABLE后执行mysqld start直接报错退出日志提示类似“unknown variable”或“unrecognized option”。原因MySQL 5.6 才开始支持master_info_repository更老版本5.5 及以下不识别这个参数配置文件里有未知参数时 MySQL 默认拒绝启动。Redis 集群里把EVAL重命名后节点同步或 failover 时相关命令执行异常。解决执行参数变更前置检查。MySQL 先查看版本SELECT VERSION();如果不确定参数是否支持在测试实例上先加参数再启动验证。Redis 集群环境只重命名FLUSHALL、FLUSHDB不碰EVAL相关命令必要时用命令行参数覆盖而不是直接改配置文件便于快速回滚。5.2 secure_file_priv 改了不生效业务还在报 1290现象在 my.cnf 添加secure_file_priv/var/lib/mysql-files后重启执行导入导出还是提示 1290 错误导出文件没有写入指定目录。原因三种常见情况。一是 MySQL 8.0 的配置项名拼写错多了下划线或少了字母导致配置读取失败但 MySQL 静默忽略。二是修改时用了SET GLOBAL secure_file_priv...这个参数不支持在线修改重启后又被配置值覆盖。三是文件系统权限不够mysql 用户对/var/lib/mysql-files没有写权限。解决先检查变量值是否生效SHOW VARIABLES LIKE secure_file_priv;如果还是旧值检查my.cnf的[mysqld]段是否有拼写错误。确认值已生效但报错检查目录属主ls -ld /var/lib/mysql-files确保属主是 mysql:mysql权限不低于 750。5.3 SQL Server 开了强制加密后所有应用连不上现象在 SQL Server Configuration Manager 中把 ForceEncryption 设为“是”后不到十分钟测试环境和部分生产应用连接全部失败报“SQL Server 未配置为允许加密连接”或证书相关错误。原因开启强制加密后服务端必须提供有效证书。开发或测试环境没有安装证书或者装了自签名证书但客户端不信任加密协商失败。解决先在实例上配置证书再开启强制加密顺序不能反。证书可以先用 Self-Signed CertificateWindows 自签名证书顶一阵但客户端机器要手动信任该证书适合测试环境。生产环境还是申请正式证书配置完成后用sqlcmd -S 实例名 -E手动验证一下连接。5.4 PostgreSQL 改 scram-sha-256 后老客户端认证失败现象修改pg_hba.conf把认证方式从md5改成scram-sha-256后部分应用连接报authentication method not supported但 psql 连接正常。原因应用使用的 PostgreSQL 客户端驱动版本过老不支持 SCRAM 认证。常见于 DBeaver、JDBC 驱动版本较旧或某些采集 Agent 内置的驱动比较老的环境。psql 本身用的新驱动所以命令行测不出来这个坑。解决先确认哪些客户端在报错优先升级驱动。升级前先保持md5认证逐台验证全部升级完再统一切换。如果确实有驱动无法升级比如老的监控组件改不了单独给该应用配一个访问条目走 md5其他全部走 scram-sha-256。但这只是过渡方案md5 条目尽量限制最小来源 IP 和最小权限。5.5 Redis protected-mode 开着配了 requirepass 但客户端还是连不上现象配置了requirepassprotected-mode yes客户端从内网其他机器访问报DENIED Redis is running in protected mode但本机redis-cli能正常连接。原因protected-mode的判断逻辑是如果未绑定bind指定 IPRedis 会拒绝外部来源的连接即使配置了密码也会先返回这个错误。解决显式配置bind指定内网网卡 IP然后重启 Redis。检查方法redis-cli CONFIG GET bind预期结果不应为空或只包含127.0.0.1应该包含实际内网 IP。配置完再验证一次从其他机器是否可以正常AUTH。6. 一个收尾技巧把加固项整理成可回滚的检查单加固做完最怕的不是配置本身而是三个月后忘了哪些参数是被改过的。我的习惯是每做完一次加固就生成一份“加固前后对照表”记录参数名、修改前值、修改后值、修改时间、影响范围。针对这个手册里的内容我整理了一个最小化验证流程可以直接在命令行里跑一遍-- MySQL确认核心加固项是否生效 SHOW VARIABLES LIKE secure_file_priv; SHOW VARIABLES LIKE local_infile; SHOW VARIABLES LIKE log_error; SELECT user, host FROM mysql.user WHERE userroot;# Redis确认进程参数、端口和监听地址 redis-cli CONFIG GET protected-mode redis-cli CONFIG GET bind redis-cli CONFIG GET timeout# PostgreSQL确认认证方式和日志 grep -E ^host $PGDATA/pg_hba.conf | grep -v ^# pg_ctl reload -D $PGDATA# SQL Server查看登录名密码策略状态在 SSMS 中执行 SELECT name, is_policy_checked, is_expiration_checked FROM sys.sql_logins;这套验证的妙处在于把手册里的“预期结果”变成了可以落地的检查命令。每个查询的返回值都能对应手册里某一条加固项。比如secure_file_priv有具体路径而非空值local_infile为 0root的 host 只有 localhost就说明这几个核心风险点已经关闭。要说教训我印象最深的是第一次给一个核心交易库做加固的日子。当时因为赶时间把local_infile从 ON 改成 0 之后没有等业务验证窗口就直接下班了结果第二天报表系统全挂在“导入临时文件”这一步业务方直接在群里点名。从那以后我每次改完配置都强制走一遍流程先在测试实例上验证参数语义再在生产实例做变更变更后立即执行上面这套查询确认现状最后在维护窗口观察至少二十分钟。整个过程必须能回滚——要么是配置文件有备份要么是命令行参数可以快速覆盖。这套手册给了加固项的完整清单但真正的落地能力还是靠“改前确认、改后验证、回滚兜底”这三板斧。希望帮到你。本文还有配套的精品资源点击获取