SQL系统安全加固核心是“权限最小化、通信可管控、行为可审计、漏洞不过夜”，需严格分离认证模式、按需授权、加密敏感数据、启用有效审计并定期验证。
SQL系统安全加固不是装个补丁或改个密码就完事，核心是“权限最小化、通信可管控、行为可审计、漏洞不过夜”。实际中很多单位把加固等同于“关掉sa账户”或“开启SQL Server身份验证”，结果留了高危后门却浑然不觉。
严格分离身份认证模式，禁用混合认证默认陷阱
SQL Server安装时默认启用Windows身份验证+SQL Server身份验证（混合模式），但多数生产环境其实只需Windows集成认证——它天然支持域控策略、密码复杂度、账户锁定，而SQL Server本地账户（如sa）一旦弱口令或长期未改，极易成为突破口。
- 若业务确实需要SQL登录（如第三方应用直连），必须关闭“SQL Server身份验证”，仅在明确需要的实例上单独启用，并为每个应用创建专用登录名，绝不用sa或db_owner角色
- 检查服务器属性 → 安全性 → 服务器身份验证，确认为“Windows 身份验证模式”；若必须保留混合模式，立即重置sa密码为32位以上随机字符串，并禁用该登录（ALTER LOGIN sa DISABLE）
- 禁用所有未命名或测试用途的SQL登录（如test、demo、admin123），用SELECT name, is_disabled FROM sys.sql_logins定期核查
按功能切分数据库角色，杜绝“一个账号走天下”
常见误区是给应用账号直接赋予db_owner或sysadmin，等于把数据库钥匙和保险柜密码一起交出去。加固的关键是“谁只做啥，就给啥权”。
- 应用账号只授予db_datareader + db_datawriter（查/写基础表），如需执行存储过程，单独授EXECUTE权限，而非整个db_owner
- 运维账号用Windows组（如SQL-DBA-Admin）统一管理，加入db_backupoperator或db_ddladmin等受限固定数据库角色，避免个人账号直连sysadmin
- 删除所有用户自建的“public”角色额外权限（如public被误加了VIEW SERVER STATE），运行SELECT * FROM fn_my_permissions(NULL, 'SERVER')自查当前会话实际权限
加密敏感链路与静态数据，别让抓包或盗盘白捡数据
明文传输连接字符串、备份文件裸放NAS、配置文件硬编码密码——这些不是“小问题”，而是攻击者最常利用的入口。
- 强制客户端加密：在SQL Server配置管理器中启用Force Encryption = Yes，并为SQL Server证书绑定有效TLS证书（勿用自签名证书应付）
- 连接字符串必须含Encrypt=True;TrustServerCertificate=False，禁止使用True（跳过证书校验）
- 对身份证号、手机号等字段启用Always Encrypted（列级加密），密钥由Windows证书或Azure Key Vault托管，SQL Server自身无法解密明文
- 备份文件用WITH ENCRYPTION选项加密（SQL Server 2014+），密钥密码不得写入脚本，交由运维平台统一调用
开启基础审计并验证日志有效性，不记录=没加固
很多单位开了SQL Server Audit，但日志存本地磁盘、7天自动覆盖、没配告警，等于装了监控摄像头却从不看回放。
- 审计目标必须设为Windows Security Log或File（远程SMB共享路径），禁用“Application Log”（易被本地管理员清除）
- 至少审计：FAILED_LOGIN_GROUP（撞库尝试）、DATABASE_OBJECT_ACCESS_GROUP（敏感表访问）、SERVER_ROLE_MEMBER_CHANGE_GROUP（提权操作）
- 每月手动触发一次sp_readerrorlog和sys.fn_get_audit_file，确认日志能读、时间戳连续、无ERROR报错；用PowerShell脚本每日校验最近2小时审计文件大小是否为0
基本上就这些——没玄学，重在每项都落地、每季度回头验。加固不是项目制任务，而是数据库生命周期里的日常呼吸。
