本文目录导读：
- 第一阶段：基础加固（先排查，后修正）
- 第二阶段：核心配置加固（身份与权限）
- 第三阶段：运行时安全加固（防注入与泄露）
- 第四阶段：审计与监控（事后能追溯）
- 第五阶段：数据本身的安全（防泄漏）
- 总结的检查清单
- 最后，给操作顺序的建议：
数据库安全加固是一个系统工程,不能仅仅通过安装一个软件或设置一个密码就完成，它需要从网络、主机、数据库本身、权限、数据、审计等多个层面进行纵深防御。
以下是一份标准的企业级数据库安全加固操作指南,涵盖了MySQL、Oracle、SQL Server、PostgreSQL等主流数据库的通用原则。
第一阶段：基础加固（先排查，后修正）
网络层隔离与访问控制
- 最小化监听：禁止数据库监听在
0.0.0（所有网卡），只监听业务需要的特定内网IP。- MySQL：
bind-address = 192.168.1.100 - SQL Server：配置管理器 -> 启用 TCP/IP -> IP地址 -> 设置为指定IP。
- MySQL：
- 防火墙策略：使用操作系统防火墙（iptables/firewalld/Windows Firewall）或云安全组，仅允许应用服务器IP访问数据库端口（如3306、1433、1521）。
- 端口变更：将默认端口（如MySQL的3306）改为非标准的高位端口（如53306），可以规避大量的自动化扫描攻击。
操作系统与文件系统加固
- 最小权限用户：不要用root（Linux）或Administrator（Windows）运行数据库服务，创建一个专用的系统用户（如
mysql、oracle）来运行数据库进程。 - 文件权限：数据库数据目录（
/var/lib/mysql）、配置文件（my.cnf）、日志文件的拥有者应为数据库运行用户，且权限设置为700或600。 - 禁用危险功能：如果不需要远程管理，建议禁用操作系统的
telnet、rlogin等不安全服务。 - 定期打补丁：确保操作系统和数据库软件的版本是厂商仍在提供安全支持的最新稳定版。
第二阶段：核心配置加固（身份与权限）
这是最容易被忽视但最关键的一步。
账号与认证
- 清理默认/僵尸账号：
- 删除或锁定数据库安装后自带的匿名用户（如MySQL的
''@'localhost'）。 - 删除默认的测试数据库（如
test）。 - 禁用或重命名内置超级管理员（如SQL Server的
sa、MySQL的root）。
- 删除或锁定数据库安装后自带的匿名用户（如MySQL的
- 密码策略：
- 开启密码过期和复杂度验证（需安装Validity插件，如
validate_password）。 - 密码长度严格要求20位以上,包含大小写、数字、特殊字符，无纯键盘序列。
- 开启密码过期和复杂度验证（需安装Validity插件，如
- 远程登录控制：
- 禁止超级管理员账号从远程登录。
- MySQL：
UPDATE mysql.user SET Host='localhost' WHERE User='root'; - 业务账号的Host应限定为具体的应用服务器IP,而非。
权限最小化（重中之重）
- 按需授权：遵循最小权限原则。
- 普通业务账号只需要
SELECT、INSERT、UPDATE、DELETE权限，绝不给DROP、CREATE、ALTER、FILE、GRANT OPTION。 - 错误示例：
GRANT ALL PRIVILEGES ON *.* TO 'app_user'@'%'; - 正确示例：
GRANT SELECT, INSERT, UPDATE, DELETE ON db_name.* TO 'app_user'@'192.168.1.50';
- 普通业务账号只需要
- 回收PUBLIC权限：在Oracle和SQL Server中，检查并回收授予PUBLIC角色的不必要权限（如创建表的权限）。
- 分离职责：DBA（管理员）、开发人员、运维人员的数据库账号应隔离，不能共用高权限账号。
第三阶段：运行时安全加固（防注入与泄露）
SQL注入防御（SQL Injection）
- 最佳方案：必须使用参数化查询（PreparedStatement），禁止通过拼接字符串构建SQL。
- 补充方案：启用数据库自带的SQL审计或WAF（Web应用防火墙）进行规则拦截。
- 数据库层面限制：
- 禁用
xp_cmdshell（SQL Server）等危险扩展存储过程。 - 禁用
LOAD_FILE和INTO OUTFILE（MySQL）等文件读写功能，除非业务明确需要。 - 限制
UTL_FILE（Oracle）包的使用权限。
- 禁用
传输加密
- 启用TLS/SSL：对于跨数据中心、跨公网（即使是VPN内）的数据库连接，务必启用SSL加密，防止数据在传输过程中被嗅探。
- 配置：在客户端和服务端配置证书，强制要求加密连接（
require-ssl）。
第四阶段：审计与监控（事后能追溯）
开启审计日志
- 记录谁、在什么时间、从哪来、做了什么。
- MySQL企业版：审计日志插件。
- MariaDB：
server_audit插件。 - PostgreSQL：
pgaudit扩展。 - Oracle：
Audit Vault或开启标准审计。 - SQL Server：SQL Server Audit。
- 重点审计：DDL操作（建表、删表）、DCL操作（赋权）、失败的登录尝试（检测暴力破解）。
日志保护
- 数据库审计日志应发送到独立的、仅追加写入的日志服务器（如ELK、Splunk）。
- 禁止普通DBA随意删除或修改本地审计日志。
第五阶段：数据本身的安全（防泄漏）
静态数据加密（TDE）
- 透明数据加密（TDE，Transparent Data Encryption）：对数据库物理文件（.mdf、.ibd、.dbf）进行加密，即使磁盘被盗，没有密钥也无法读取文件。
- 适用场景：存储信用卡、身份证、护照等强监管数据。
动态数据脱敏
- 在开发、测试、分析环境中，不应使用生产环境的真实数据。
- 使用SQL Server Dynamic Data Masking或Oracle Data Redaction等特性，或借助第三方工具进行脱敏处理，避免敏感信息泄露到非生产环境。
备份安全
- 备份文件同样需要加密存储。
- 备份数据应异地或跨区域保存。
- 定期进行备份恢复演练，确保备份文件不仅存在，而且可用。
总结的检查清单
| 加固项 | 检查点 | 高危配置示例 | 加固后配置示例 |
|---|---|---|---|
| 网络 | 监听地址 | 0.0.0:3306 |
0.0.1:3306 或 特定IP |
| 认证 | 默认账号 | 存在空密码root、匿名用户 | 删除/锁定，强密码 |
| 权限 | 业务账号 | GRANT ALL ON *.* |
GRANT SELECT,INSERT ON db.* |
| 资源 | 危险功能 | xp_cmdshell 开启 |
关闭 |
| 审计 | 登录记录 | 未开启 | 开启失败登录/DDL审计 |
| 传输 | 加密 | 明文连接 | SSL/TLS |
| 备份 | 加密 | 明文备份文件 | 加密备份文件 |
给操作顺序的建议：
- 先评估，后动手：先梳理出当前数据库有哪些账号、有哪些开放端口、权限情况如何。
- 先备份，后修改：在修改任何配置文件（my.cnf）或执行高危SQL（如
DROP USER）前，务必先做全量备份。 - 先测试，后生产：所有加固操作先在测试环境验证，确认不影响业务逻辑后再上线生产。
- 最小变更原则：每次只修改一个配置项，观察业务是否正常，逐步推进。
如果你们是云上数据库（RDS），云服务商已经帮你完成了操作系统、防火墙、补丁等底层加固，你需要重点做的是账号权限、审计、SSL加密和备份加密。
