SQL系统安全加固需围绕“谁在访问、访问什么、如何访问、出了问题怎么发现”四问，落实最小权限、加密通信、IP限制、实时监控及可验证备份。
SQL系统安全加固不是堆砌工具或盲目改配置，而是围绕“谁在访问、访问什么、如何访问、出了问题怎么发现”这四个核心问题，做有逻辑、可验证、可持续的防护。重点不在功能多全，而在关键环节有没有被绕过。
最小权限原则必须落地到每个账号
很多团队只给应用账号一个db_owner或sysadmin角色，等于把数据库大门钥匙交给了所有服务。真正有效的做法是：应用账号只赋予它实际需要的表级SELECT/INSERT/UPDATE权限，禁用DROP、ALTER、EXECUTE（除非明确调用存储过程）；DBA账号与应用账号物理隔离，禁止共用；临时账号（如开发调试用）设置自动过期时间，超时即失效。
- 用CREATE ROLE app_reader建专用角色，再GRANT SELECT ON dbo.orders TO app_reader
- 禁用guest用户（尤其在master和tempdb中），避免未授权用户通过空用户名接入
- 定期用sys.database_permissions视图审计权限分配，导出比对历史快照
连接层与传输层不能只靠默认设置
SQL Server默认允许明文登录、弱加密协议、任意IP连接——这些在内网看似无害，实则是横向移动的跳板。加固不是“开个SSL就完事”，而是分层拦截：
- 强制启用TLS 1.2+加密通信，禁用SSL 3.0/TLS 1.0（注册表或SQL Server配置管理器中关闭）
- SQL Server配置为仅Windows身份验证模式，若必须用SQL登录，则启用密码策略强制（复杂度+过期+历史记录）
- 防火墙规则限制仅允许业务服务器IP段访问1433端口，拒绝0.0.0.0/0或内网全通
关键对象与行为必须实时监控
没有监控的安全策略等于没做。重点不是记录所有操作（日志爆炸），而是盯住高危动作：
- 开启SQL Server Audit，捕获FAILED_LOGIN_GROUP、DATABASE_OBJECT_CHANGE_GROUP、SERVER_ROLE_MEMBER_CHANGE_GROUP
- 用Extended Events轻量监听sql_batch_completed事件，过滤出执行时间超5秒、返回行数超10万的异常查询（可能是拖库或暴力探测）
- 对xp_cmdshell、sp_oacreate等高危扩展存储过程，直接REVOKE EXECUTE并从sys.configurations中禁用
备份与应急响应要能真跑通
安全加固最后防线是“出事了能不能快速止损”。很多团队备份存在但从未验证恢复流程，或应急账号密码已失效。
- 每周执行一次RESTORE VERIFYONLY，每月至少一次完整恢复演练（含时间统计）
- 准备离线应急账号（如sa_bak），密码写入保险箱，权限仅限VIEW SERVER STATE和KILL DATABASE CONNECTION
- 把关键加固操作（如禁用guest、开启Audit）写成幂等脚本，存入Git，每次变更前先本地diff再执行
基本上就这些。不复杂，但容易忽略细节。真正提升实战能力的关键，是把每一条加固项对应到一个具体攻击路径上想一遍：“如果攻击者现在就在我面前，这条措施能不能卡住他？”
