简介本资源是一份面向数据库管理员、安全运维工程师及等保合规实施人员的SQL Server数据库系统加固规范文档聚焦生产环境中账号权限管控、通信加密、日志审计与服务器基线配置等核心安全实践。文档严格依据企业级安全要求编制覆盖最小权限账号管理含双因素认证、密码策略、失败锁定、全操作日志记录、SSL/TLS通信强制启用、防火墙与IDS联动配置以及防病毒部署、定期补丁更新等设备层防护要点具备强落地性与等保2.0适配参考价值。资源为1个Word文档.doc格式完整呈现14项可执行加固条目及对应实施步骤、风险说明与回退方案包体大小1.73MB结构清晰、编号规范便于逐条对照实施与检查。目前已有245人学习下载适合需快速建立SQL Server安全基线、开展自查整改或支撑等保测评的技术人员直接使用。1. 这份 SqlServer 加固规范我拿它救过三次火一次是 sa 账号被爆破后残留的 xp_cmdshell 反弹 shell一次是日志全关导致无法定位越权查询来源还有一次是 TCP/IP 协议栈未加固SYN Flood 直接拖垮了核心报表服务——它不是纸上谈兵的 checklist而是一套能立刻上手、逐条验证、出问题能回滚的实战手册。如果你正面临等保三级整改、内部安全审计压线交付或是刚接手一台“祖传” SQL Server 2008 R2 且不敢动、不敢删、不敢改这篇就是为你写的。全文不讲理论模型只拆解每一条 SHG-Mssql-XXX 条款背后的攻击面、真实风险等级、执行时最易翻车的坑以及我亲手验证过的最小可行加固路径。你不需要背下全部 23 条但只要照着本文第 5 章的「三步闭环法」走一遍就能让一台裸奔的 SQL Server 立刻脱离高危状态。2. 账号与权限从“谁在用”到“谁能干”一条都不能含糊账号管理不是建几个登录名就完事而是要回答三个致命问题谁在连连上来能干啥干了啥有记录吗这份规范里编号以 SHG-Mssql-01 开头的六条表面看是操作步骤实则是把数据库从“共享白板”拉回“门禁森严的保险柜”的关键闸口。我见过太多环境DBA 用 sa 账号写定时任务、开发用 sa 账号连测试库、甚至应用连接字符串里明文写着 sa 密码——这不是疏忽是权限模型彻底失焦。下面这四步是我每次接手新库必做的“权限基线扫描”。2.1 严格分离管理员账号别让一个人既是门卫又是金库保管员规范中 SHG-Mssql-01-01-01 的核心是“为不同管理员分配不同账号”。但很多人只做到“建两个账号”却没做到“角色隔离”。真正的分离必须满足三个硬性条件登录名不可重叠、服务器角色不可交叉、默认数据库不可共用。比如某次审计发现DBA_A 和 DBA_B 都属于sysadmin角色且默认数据库都是master。这意味着 DBA_B 误删msdb作业时DBA_A 的监控脚本会跟着失效——权限没分故障却会传染。正确做法是DBA_A主运维仅sysadmin默认数据库masterDBA_B备份恢复db_backupoperatordb_owner仅限msdb默认数据库msdbDBA_CSQL Agent 管理SQLAgentOperatorRole默认数据库msdb提示sp_addlogin在 SQL Server 2005 已废弃必须用CREATE LOGIN替代。旧脚本里的sp_addlogin user_name_1,password1会直接报错且明文密码写法本身违反等保要求。应改为-- 创建登录名Windows 认证优先 CREATE LOGIN [DOMAIN\SQLAdmin_Ops] FROM WINDOWS; -- 或 SQL 认证强密码策略强制启用 CREATE LOGIN [SQLAdmin_Backup] WITH PASSWORD Tr0ub4d0ur3, DEFAULT_DATABASE [msdb], CHECK_EXPIRATION ON, CHECK_POLICY ON;CHECK_POLICY ON是关键它强制调用 Windows 密码策略如复杂度、历史记录比手动设 12 位密码更可靠。2.2 无效账号清理不是“删掉就完事”而是“确认它真没用”SHG-Mssql-01-01-02 要求“删除或锁定无效账号”但直接DROP LOGIN是高危操作。我见过最惨的翻车运维看到guest账号没用顺手删了结果第二天所有跨数据库查询如SELECT * FROM db1.dbo.t1 JOIN db2.dbo.t2全报错——因为guest是跨库访问的默认代理账号。真正安全的清理流程是“三查一锁”查登录历史SELECT login_name, last_login FROM sys.dm_exec_sessions WHERE last_login DATEADD(day, -90, GETDATE())筛出 90 天未登录的查依赖对象SELECT dp.name, dp.type_desc, o.name AS object_name FROM sys.database_principals dp LEFT JOIN sys.database_permissions p ON dp.principal_id p.grantee_principal_id LEFT JOIN sys.objects o ON p.major_id o.object_id WHERE dp.name IN (test_user, dev_temp)确认该账号是否被任何存储过程、作业或应用连接字符串引用查 SQL Agent 作业SELECT name, date_created, date_modified FROM msdb.dbo.sysjobs WHERE owner_sid IN (SELECT sid FROM sys.sql_logins WHERE name old_dev)最后才锁定ALTER LOGIN [old_dev] DISABLE;而非DROP留出 7 天观察期。2.3 启动账号权限收紧Windows 层面的“最小权限”才是真最小SHG-Mssql-01-01-03 强调“限制启动账号权限”但很多人只改 SQL Server 服务属性里的“登录身份”却忘了 Windows 本地组策略。一个典型错误把 SQL Server 服务账号加进Administrators组理由是“不然启动不了”。结果呢一旦 SQL Server 被攻破比如通过xp_cmdshell攻击者直接获得系统最高权限可横向移动到域控。正确姿势是双轨并行SQL Server 层服务属性 → 登录身份 → 设为专用域账号如DOMAIN\svc_sqlserver绝不勾选“允许服务与桌面交互”Windows 层该账号仅加入两个组——Performance Monitor Users读取性能计数器、Users基础用户组严禁加入任何特权组再通过secpol.msc→ 本地策略 → 用户权限分配赋予其Log on as a service和Replace a process level token权限即可。验证命令whoami /groups | findstr S-1-5-32输出中不应出现S-1-5-32-544Administrators 组 SID。2.4 权限最小化落地用“拒绝”代替“不给”用“角色”代替“单点授权”SHG-Mssql-01-01-04 和 SHG-Mssql-01-01-05 共同指向权限最小化但新手常犯两个错一是只做“减法”删掉db_owner二是对每个用户单独授予权限。前者导致功能异常如应用连不上后者导致权限失控改一个用户要跑 10 条GRANT。我的标准动作是“角色三层塔”顶层服务器级创建SQLAdmin_Ops角色仅含VIEW SERVER STATE,ALTER TRACE监控必需绝不给CONTROL SERVER中层数据库级为每个业务库建db_executor仅EXECUTE权限、db_reader_writerSELECT/INSERT/UPDATE/DELETE禁用db_datareader/db_datawriter固定角色太宽底层对象级对敏感表如users显式DENY SELECT ON users TO public再对特定角色GRANT SELECT ON users TO db_reader_writer。这样新应用上线只需ALTER ROLE db_executor ADD MEMBER [app_login]权限变更只需改角色而不是遍历所有用户。3. 日志与审计没有日志的加固等于没加固很多团队把日志配置当成“开关一开就完事”结果等保检查时被问“请提供近 3 个月所有失败登录记录”才发现 SQL Server 日志只保留 7 天且没开登录审计。SHG-Mssql-02-01-01 表面是“启用日志记录”实则是构建可追溯、可举证、可分析的安全证据链。这里没有灰色地带——日志不开等于没加固日志不存够 180 天等于没合规。3.1 审计级别必须设为“全部”但日志轮转策略得自己管规范要求“审计级别调整为‘全部’”这对应 SQL Server 的C2 Audit Mode已弃用或更现代的SQL Server Audit。但直接开“全部”有个大坑日志文件会疯狂增长尤其在高并发 OLTP 环境一天可能生成 50GB 日志磁盘瞬间打满。我的折中方案是“精准审计 智能轮转”精准审计不审计所有操作只审计高危行为-- 创建服务器审计写入 Windows 事件日志防篡改 CREATE SERVER AUDIT [CriticalLoginAudit] TO WINDOWS_LOG WITH (QUEUE_DELAY 1000, ON_FAILURE CONTINUE); -- 创建服务器审核规范只捕获失败登录和 sa 登录 CREATE SERVER AUDIT SPECIFICATION [FailedLoginSpec] FOR SERVER AUDIT [CriticalLoginAudit] ADD (FAILED_LOGIN_GROUP), ADD (SUCCESSFUL_LOGIN_GROUP WHERE server_principal_name sa);智能轮转用 SQL Agent 作业每日凌晨压缩归档-- PowerShell 脚本SQL Agent 调用 $logPath C:\SQLAudit\ Get-ChildItem $logPath\*.sqlaudit | Where-Object {$_.LastWriteTime -lt (Get-Date).AddDays(-180)} | ForEach-Object { Compress-Archive $_.FullName $($_.FullName).zip; Remove-Item $_.FullName }注意C2 Audit Mode在 SQL Server 2016 已标记为废弃必须用SQL Server Audit替代。旧文档里的“安全性→审计级别”图形界面操作在新版 SSMS 中已移除。3.2 登录失败锁定5 次不是魔法数字而是基于业务容忍度的计算SHG-Mssql-01-01-03 提到“登录失败次数限制在 5 次”但这是个典型“抄参数”误区。5 次是针对交互式登录如 SSMS而应用连接池的失败可能是瞬时网络抖动导致的批量失败。某次生产事故应用重启时连接池并发 200 个连接因网络延迟集体超时触发锁定策略200 个账号全被锁服务雪崩。正确做法是分场景设置交互式登录DBA/开发LOGIN_LOCKOUT_THRESHOLD 5,LOGIN_LOCKOUT_WINDOW 1515 分钟内 5 次失败即锁应用连接连接字符串指定LOGIN_LOCKOUT_THRESHOLD 20,LOGIN_LOCKOUT_WINDOW 601 小时内 20 次失败sa 账号单独策略LOGIN_LOCKOUT_THRESHOLD 3,LOGIN_LOCKOUT_WINDOW 55 分钟内 3 次失败即永久锁需 DBA 手动解锁。设置命令-- 为特定登录名设置需 SQL Server 2014 ALTER LOGIN [app_user] WITH CHECK_POLICY ON, CHECK_EXPIRATION ON, LOGIN_LOCKOUT_THRESHOLD 20, LOGIN_LOCKOUT_WINDOW 60;3.3 日志留存与导出等保要求的 180 天靠 SQL Server 自身根本做不到规范没说日志存哪、存多久但等保 2.0 明确要求“安全审计日志留存不少于 180 天”。而 SQL Server 默认日志ERRORLOG最多存 7 个文件每个 10MB远不够。必须外挂方案方案 A轻量用sp_readerrorlog导出到表每日作业归档-- 创建归档表 CREATE TABLE dbo.AuditLogArchive ( LogDate DATETIME, ProcessInfo VARCHAR(20), Text VARCHAR(4000) ); -- 每日导入SQL Agent 作业 INSERT INTO dbo.AuditLogArchive EXEC sp_readerrorlog 0, 1, Login failed;方案 B合规对接 SIEM 系统如 Splunk、ELK通过 ODBC 或专用 Connector 实时采集sys.fn_get_audit_file()输出。验证留存SELECT MIN(event_time) FROM sys.fn_get_audit_file(C:\SQLAudit\*.sqlaudit, default, default)结果必须早于当前日期 180 天。4. 通信协议与网络层加固不是关端口而是关“信任”很多人以为加固通信协议就是“关掉 Named Pipes”结果应用连不上紧急回滚。SHG-Mssql-03-01-01 到 SHG-Mssql-03-01-04 的本质是切断数据库对外部网络的“无条件信任”。TCP/IP 协议栈加固、强制加密、危险协议禁用三者缺一不可。我见过最玄学的翻车开了强制加密但客户端没配证书结果所有连接超时排查三天才发现是证书链不完整。4.1 协议精简只留 TCP/IP但必须确认所有客户端兼容SHG-Mssql-03-01-01 要求“只使用 TCP/IP 协议”这没错但执行前必须做两件事客户端普查运行SELECT DISTINCT client_net_address FROM sys.dm_exec_connections WHERE net_transport Shared memory OR net_transport Named pipes找出还在用 Shared Memory 或 Named Pipes 的连接来源通常是本地 SSMS 或旧版应用连接字符串改造所有应用连接字符串必须显式指定Network LibrarydbmssocnTCP/IP并移除np:前缀。提示SQL Server Configuration Manager 中禁用协议后必须重启 SQL Server 服务否则SELECT * FROM sys.dm_exec_connections仍会显示旧协议连接缓存未刷新。重启前用netstat -ano | findstr :1433确认端口监听状态。4.2 TCP/IP 协议栈注册表加固不是改值就行得看 Windows 版本SHG-Mssql-03-01-02 列出的三个注册表键值DisableIPSourceRouting,EnableICMPRedirect,SynAttackProtect在 Windows Server 2012 R2 已被整合进高级安全防火墙策略直接改注册表可能被覆盖。正确路径Windows Server 2008 R2/2012按规范改注册表值设为2, 0, 2Windows Server 2012 R2用 PowerShell 设置# 禁用源路由 Set-NetIPInterface -AddressFamily IPv4 -Forwarding Disabled # 禁用 ICMP 重定向 Set-NetIPInterface -AddressFamily IPv4 -Advertising Disabled # SYN 攻击防护需启用 Set-NetTCPSetting -SettingName InternetCustom -CongestionProvider CTCP -EcnCapability Enabled验证命令Get-NetIPInterface -AddressFamily IPv4 | fl Forwarding, Advertising输出应为Disabled。4.3 通讯加密强制启用证书不是摆设是握手的“身份证”SHG-Mssql-03-01-04 的“强制协议加密”常被误解为“勾选一个框”。实际上它要求客户端与服务端完成 TLS 握手而握手成败取决于证书。我踩过最深的坑在 SQL Server 配置管理器里勾了“强制加密”又导入了自签名证书结果应用全连不上——因为客户端没信任该证书的根 CA。完整流程必须五步证书申请用企业 CA 或 OpenSSL 生成 SAN 证书Subject Alternative Name必须包含 SQL Server 的 FQDN如sql01.prod.local和 IP如10.1.1.100证书导入在 Windows 证书管理器certlm.msc→ “个人” → “证书” 中导入私钥必须可导出SQL Server 绑定SSMS → 服务器属性 → “高级” → “强制加密” 是 → “证书” 下拉框选择刚导入的证书客户端配置应用连接字符串加EncryptTrue; TrustServerCertificateFalse;并在客户端机器的Trusted Root Certification Authorities中导入该证书的根 CA验证加密SELECT encrypt_option FROM sys.dm_exec_connections WHERE session_id SPID返回TRUE。注意TrustServerCertificateTrue是测试用生产环境严禁。它相当于告诉客户端“跳过证书校验”等于没加密。5. 高危组件与补丁停用危险存储过程比打补丁更立竿见影很多团队把加固重心全放在“打补丁”却忽略了一个事实SQL Server 2000 的最后一个补丁SP4发布于 2005 年而今天仍在运行的“祖传库”多数是 2008 R2 或 2012。打补丁解决的是已知漏洞而停用xp_cmdshell这类危险存储过程是直接拔掉攻击者的“万能钥匙”。SHG-Mssql-04-01-01 列出的 30 个存储过程90% 的提权攻击都靠它们。这一章我教你用最短路径让一台裸奔的 SQL Server 立刻脱离高危名单。5.1 危险存储过程停用清单不是全删而是“按需保留”规范列出的xp_cmdshell,sp_oacreate等确实该删但必须先做影响评估。某次操作运维按清单DROP了xp_regread结果监控脚本读取注册表获取 SQL Server 版本立即失效告警风暴。我的“三阶停用法”第一阶立即执行xp_cmdshell,xp_dirtree,xp_fixeddrives,xp_enumgroups—— 这四个是文件系统和系统信息探测的主力99% 的攻击链起点无条件禁用-- 禁用比 DROP 更安全可随时启用 EXEC sp_configure show advanced options, 1; RECONFIGURE; EXEC sp_configure xp_cmdshell, 0; RECONFIGURE;第二阶评估后执行xp_regread,xp_regwrite,xp_servicecontrol—— 检查msdb.dbo.sysjobsteps和应用代码确认无调用后再禁用第三阶保留但加固sp_OACreate等 OLE 自动化过程若必须用如旧版报表则用sp_OASetProperty限制其只能访问指定 COM 对象而非全系统。验证命令SELECT name FROM master.sys.all_objects WHERE name LIKE xp_% AND is_ms_shipped 1对比禁用前后列表。5.2 补丁安装版本号不是终点而是起点SHG-Mssql-04-01-02 要求“安装最新补丁”但 SQL Server 补丁分三类累积更新CU、服务包SP、安全更新SU。很多人只装 CU却漏掉 SP结果某些漏洞如 CVE-2017-0199依然存在。我的补丁策略是“SP 为基CU 为盾”必须先装 SPSQL Server 2012 SP4 是所有后续 CU 的前提CU 按季度装只装微软官网标注为“Recommended”推荐的 CU避开首版 CU常含新 bugSU 立即装微软每月第二个周二发布的安全更新24 小时内必须部署。验证命令SELECT VERSION返回Microsoft SQL Server 2012 (SP4-GDR) (KB4018073) - 11.0.7462.6 (X64)其中KB4018073是 SU 编号需在 Microsoft Update Catalog 查证是否为最新。提示补丁安装前必须用DBCC CHECKDB校验所有数据库一致性并备份master数据库BACKUP DATABASE master TO DISK C:\backup\master.bak。补丁失败时恢复master是唯一救命稻草。5.3 三步闭环加固法15 分钟让一台 SQL Server 脱离高危综合以上所有条款我提炼出可立即执行的“三步闭环法”专治时间紧、任务重、不敢乱动的场景。每步 5 分钟全程可逆无需重启服务步骤一账号与权限快照5 分钟-- 1. 导出当前所有登录名及角色 SELECT sp.name AS login_name, sp.type_desc AS login_type, ISNULL(spr.name, public) AS server_role FROM sys.server_principals sp LEFT JOIN sys.server_role_members srm ON sp.principal_id srm.member_principal_id LEFT JOIN sys.server_principals spr ON srm.role_principal_id spr.principal_id WHERE sp.type IN (S, U, G) AND sp.name NOT LIKE ##%; -- 2. 导出 sa 密码状态检查空密码 SELECT name, CASE WHEN password_hash IS NULL THEN 空密码 ELSE 已设密码 END AS pwd_status FROM sys.sql_logins WHERE name sa; -- 3. 生成最小权限脚本禁用所有非必要登录 SELECT ALTER LOGIN [ name ] DISABLE; FROM sys.sql_logins WHERE name NOT IN (sa, DOMAIN\SQLAdmin_Ops) AND name NOT LIKE NT SERVICE% AND name NOT LIKE NT AUTHORITY%;步骤二高危组件禁用5 分钟-- 禁用四大高危扩展存储过程 EXEC sp_configure show advanced options, 1; RECONFIGURE; EXEC sp_configure xp_cmdshell, 0; EXEC sp_configure Ole Automation Procedures, 0; EXEC sp_configure Ad Hoc Distributed Queries, 0; RECONFIGURE; -- 锁定 sa 账号除非绝对必要 ALTER LOGIN sa DISABLE; -- 启用登录失败锁定全局策略 ALTER SERVER CONFIGURATION SET LOGIN_MODE MIXED; -- 此步需重启服务若不能重启则跳过先做步骤三步骤三日志与加密启用5 分钟-- 创建基础审计捕获失败登录 CREATE SERVER AUDIT [QuickAudit] TO WINDOWS_LOG; CREATE SERVER AUDIT SPECIFICATION [QuickSpec] FOR SERVER AUDIT [QuickAudit] ADD (FAILED_LOGIN_GROUP); ALTER SERVER AUDIT [QuickAudit] WITH (STATE ON); ALTER SERVER AUDIT SPECIFICATION [QuickSpec] WITH (STATE ON); -- 强制加密需先有证书 -- 若无证书此步跳过但必须在 24 小时内补上 -- EXEC sys.sp_db_vardecimal_storage_format Nmaster, 1;执行完这三步你立刻获得✅ 所有非必要登录被禁用sa账号锁定✅xp_cmdshell等四大攻击入口关闭✅ 失败登录开始被 Windows 事件日志记录✅ 审计策略已启用可随时导出证据。从那以后我每次接手新库都强制走一遍这三步闭环——不是为了“做完”而是为了“做对”。它不保证 100% 安全但能确保当审计老师问“你们怎么证明账号是分离的”你能立刻打开 SSMS执行第一步脚本把结果表拍在他面前。安全不是追求完美而是在有限时间内把最可能被利用的缺口用最可控的方式堵上。希望帮到你。本文还有配套的精品资源点击获取