SQL 系统安全加固需围绕“谁在访问、访问什么、如何访问”构建分层防护，涵盖身份认证与权限最小化、网络通信加密、细粒度审计监控、配置与补丁常态化管理，并强调持续运维而非一次性检查。
SQL 系统安全加固不是堆砌 工具，而是围绕“谁在访问、访问什么、如何访问”三个核心问题建立分层防护。重点不在禁用所有功能，而在精准控制权限、减少攻击面、及时发现异常。
身份认证与权限最小化
很多风险源于过度授权。数据库账号不应沿用默认密码，更不能多个应用共享同一高权限账号。
- 禁用或重命名默认账户（如 MySQL 的 root、SQL Server 的 sa），生产环境避免使用本地管理员组映射登录
- 按角色分配权限：例如只读报表用户仅授予 SELECT，ETL 任务账号仅限目标表的 INSERT/UPDATE，不赋予 DROP 或 EXECUTE 权限
- 启用强密码策略（长度≥10 位、含大小写字母 + 数字 + 符号），并定期轮换；对敏感库启用双因素认证（如 SQL Server 支持 Windows Hello 或证书登录）
网络与通信层收紧
数据库不该暴露在公网，也不该依赖应用层“自觉过滤”。通信加密和访问控制必须由数据库自身强制执行。
- 关闭非必要 端口 和服务（如 MySQL 的 3306 仅监听内网 IP，禁用 skip-networking 以外的远程访问配置）
- 强制 TLS 加密连接：MySQL 配置 require_secure_transport=ON；PostgreSQL 设置ssl=on + ssl_cert_file；SQL Server 启用强制加密并部署有效证书
- 配合 防火墙 或安全组，限制数据库端口仅允许应用服务器 IP 段访问，拒绝全网 0.0.0.0/ 0 开放
审计与行为监控落地
没有记录就等于没发生。关键操作不留下痕迹，等于给入侵者提供“隐身通道”。
- 开启细粒度审计：MySQL 企业版用 Audit Log 插件，开源版可结合 general_log+ 脚本过滤；PostgreSQL 启用 pg_audit 扩展；SQL Server 启用 C2 审计或 Server Audit
- 重点关注高危行为：如 schema 变更（CREATE/DROP/ALTER）、特权切换（SET ROLE、EXECUTE AS）、大量数据导出（SELECT INTO OUTFILE、bcp）、失败登录暴增
- 日志统一收集到 SIEM 系统（如 ELK、Splunk），设置告警规则——例如 1 小时内同一 IP 连续 5 次登录失败，自动触发通知
配置与补丁常态化管理
默认配置是为兼容性设计，不是为安全性。未更新的版本往往存在已知漏洞，比如 CVE-2021-44228 影响 Log4j 的 Java 应用连库场景。
- 关闭危险选项：MySQL 禁用 local_infile、secure_file_priv 设为非空目录；PostgreSQL 禁用 dblink、citext 等非必需扩展；SQL Server 关闭 xp_cmdshell、OLE Automation Procedures
- 建立补丁响应机制：订阅官方安全通告（如 Oracle Critical Patch Update、Microsoft Security Update Guide），测试环境验证后 2 周内完成生产升级
- 定期扫描配置合规性：用 OpenSCAP、Lynis 或厂商提供的基准检查工具（如 MySQL Enterprise Monitor 合规报告）比对 CIS 标准
基本上就这些。安全加固不是一次性的“上线前检查”，而是嵌入日常运维的持续动作——权限每季复核、配置每月扫描、日志每日抽检。不复杂但容易忽略。
