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标准
基本上就这些。安全加固不是一次性的“上线前检查”，而是嵌入日常运维的持续动作——权限每季复核、配置每月扫描、日志每日抽检。不复杂但容易忽略。
