简介《Sql Server数据库系统加固规范》面向数据库管理员、安全运维与等保合规人员聚焦 SQL Server 实例的基线加固与安全检查落地。文档按账号管理与认证授权、日志配置、通信协议、设备其他安全要求四个章节组织逐条给出 SHG-Mssql 编号、实施目的、问题影响、系统当前状态、配置步骤、回退方案、判断依据、实施风险与重要等级便于对照排查和整改。压缩包仅含1个 doc 文件约1.73MB结构紧凑适合打印或随查随用。已有245人学习下载可作为内部加固模板和审计参考。读者可据此梳理最小权限、口令策略、登录失败锁定、双因素认证等账号要求也能获取日志全量记录、SSL/TLS 加密通信、防火墙与入侵检测、防病毒及定期检查更新等配置思路并借助回退方案和风险等级评估变更影响形成可执行的加固清单。1. 拿到一份Sql Server加固规范先别急着照抄这份编号化的清单到底解决什么问题很多团队做数据库等保整改时最头疼的不是不会敲命令而是根本不知道该查哪些项、查到什么程度算合格。这份《Sql Server数据库系统加固规范》给出的不是教程而是一套带编号、带判定依据、带回退方案的核查清单——账号管理、认证授权、日志配置、通信协议、设备其他安全要求四大类每条都写明了实施目的、问题影响、当前状态核查方法、实施步骤、回退方案、判断依据和风险等级。它的价值在于把加固从凭经验拍脑袋变成可对账、可验收、可回溯的流程。适合谁看手上管着几台到几十台 SQL Server 实例、要做安全基线核查的运维和 DBA正在准备等保测评或内部审计材料的安全工程师以及被要求一个月内把数据库安全整改做完却不知道从哪下手的项目负责人。它默认面向 SQL Server 2000 时代的实例但绝大多数思路对 2005 以上版本仍然成立只是落地命令要换。2. 账号与认证授权六条基线怎么落到具体实例上账号这一块是整份规范里条目最多、风险标注最重的部分六条编号全挂着实施风险高、重要等级★★★这不是吓唬人。账号改动的翻车率恰恰最高——删错一个登录名业务连接池整片报错改错一个角色报表系统第二天全白屏。所以这里的关键不是照做而是先摸清现状再按可回退的方式改。2.1 先跑一遍现状盘点别上来就改规范里每条都要求先记录系统当前状态这一步很多人嫌麻烦跳过结果改完出问题连回退到哪都不知道。SQL Server 的登录名和用户信息分布在两套系统视图里早期版本用 syslogins / sysusers2005 以后建议改用 sys.server_principals 和 sys.database_principals。下面这段盘点脚本我一般会作为整改第一步固定执行输出留档。-- 盘点实例级登录名名称、类型、是否启用、创建时间、默认库 SELECT name, type_desc AS 登录类型, -- SQL_LOGIN / WINDOWS_LOGIN / WINDOWS_GROUP is_disabled AS 是否禁用, create_date AS 创建时间, default_database_name AS 默认数据库 FROM sys.server_principals WHERE type IN (S,U,G) -- SSQL登录 UWindows登录 GWindows组 ORDER BY name; -- 盘点服务器角色成员找出谁拥有 sysadmin / securityadmin SELECT r.name AS 角色名, m.name AS 成员名 FROM sys.server_role_members rm JOIN sys.server_principals r ON r.principal_id rm.role_principal_id JOIN sys.server_principals m ON m.principal_id rm.member_principal_id WHERE r.name IN (sysadmin,securityadmin,serveradmin) ORDER BY r.name, m.name;第一段查出所有能登录实例的身份重点看三件事有没有已经不用却还启用的账号、有没有不该存在的 SQL 登录尤其在只做 Windows 认证的环境里、默认数据库是不是乱指。第二段查高权限角色成员sysadmin 的成员数量是硬指标正常业务库里这个数字应该能一只手数过来超了就要逐个问清楚用途。提示盘点结果务必导出一份到工单或配置库里存档这份文件就是后面所有回退操作的地图。2.2 一账号一用户别让多人共用 sa规范 01-01-01 要求为不同的管理员分配不同的账号实施步骤给的是 sp_addlogin。这个存储过程在新版本里虽然还能用但已不推荐标准做法是 CREATE LOGIN。核心诉求只有一个任何操作都能追溯到具体的人而不是永远看到 sa 在跑。-- 为每个管理员建独立登录名强制密码策略 CREATE LOGIN dba_zhang WITH PASSWORD N强口令, CHECK_POLICY ON, CHECK_EXPIRATION ON; -- 只授予必要的服务器角色不要直接给 sysadmin ALTER SERVER ROLE securityadmin ADD MEMBER dba_zhang; -- 按需映射到具体业务库并只给 db_datareader 这类低权限角色 USE SalesDB; CREATE USER dba_zhang FOR LOGIN dba_zhang; ALTER ROLE db_datareader ADD MEMBER dba_zhang;CHECK_POLICY ON 让登录名继承 Windows 的密码复杂度与锁定策略这是性价比最高的一个参数比手工写密码规则可靠得多。CREATE USER 那一步决定了这个账号在库内的身份很多新手只建了登录名却忘了映射用户结果人连得上实例却看不到任何库误以为权限给错了。2.3 空密码与弱口令一条查询就能筛出来规范 01-01-06 要求清理空密码账号给的是Select name,Password from syslogins where password is null。这条在 2005 以后要改写因为密码哈希已经不在 syslogins 里了判断空密码要看 sys.sql_logins 的 password_hash 是否为空。-- 找出密码为空的 SQL 登录2005 及以上 SELECT name, is_disabled, create_date FROM sys.sql_logins WHERE password_hash IS NULL; -- 找出从未改过密码、创建时间很早的可疑账号人工复核 SELECT name, create_date, modify_date FROM sys.sql_logins WHERE create_date 2020-01-01 ORDER BY create_date;password_hash 为空基本等同于空密码可登录这种账号要么立刻改密要么直接禁用。第二段查老古董账号是个土办法但很有效长期不动的登录名往往对应已离职人员或早已下线的系统。改密码统一走ALTER LOGIN 名称 WITH PASSWORD N新口令注意这个操作会让该账号已缓存的连接在下次重连时失效改之前确认没有长连接业务依赖。2.4 权限最小化与角色化管理规范 01-01-04 讲权限最小化01-01-05 讲用角色管理对象权限。这两条其实是一件事的两面不要给具体的人逐个授对象权限而是先建角色、给角色授权、再把人塞进角色。这样人员变动时只需增删角色成员不用满库翻权限。-- 建一个只读报表角色授予 SELECT 权限 USE SalesDB; CREATE ROLE rpt_reader; GRANT SELECT ON SCHEMA::dbo TO rpt_reader; -- 建一个只允许执行指定存储过程的角色 CREATE ROLE app_executor; GRANT EXECUTE ON OBJECT::dbo.usp_GetOrder TO app_executor; -- 人员入角色而不是逐个授权 ALTER ROLE rpt_reader ADD MEMBER report_user01;这里有个容易忽略的边界GRANT SELECT ON SCHEMA::dbo 会给该 schema 下所有现存和将来新建的对象都授权如果库里混着敏感表和普通表就得改成按对象授权。我见过的翻车案例是一个只读账号因为这个 schema 级授权拿到了人事表的查询权审计时被点名。稳妥做法是先按 schema 划清业务边界跨边界的敏感表单独收紧。2.5 启动账号与服务账户的权限收敛规范 01-01-03 要求限制启动 SQL Server 服务的账号权限建议把服务账号从 Users 组移除、不加入 Administrators 组。这条的现实意义是服务进程被攻破时攻击者继承的是服务账号权限账号权限越大横向移动的空间越大。落地检查在 Windows 侧打开服务管理器找到 SQL Server 服务看登录页签用的是哪个账户再用whoami /groups在该账户上下文里确认它不在 Administrators 组。改服务账号是个高风险动作必须停机窗口内做改完要验证 SQL Server Agent 作业、备份目录、数据库文件目录的 ACL 都对新账号可读写,否则会出现服务能起但备份作业全失败的情况。3. 日志、通信协议与危险存储过程容易被跳过的三类加固相比账号这一块的条目少但技术含量不低而且特别容易看着做了其实没生效。审计开启后没验证、协议改了没测连接、存储过程删了没留恢复手段是三个高频失误点。这三类操作的共同特征是影响面隐蔽往往要等下一次故障或审计才暴露。3.1 登录审计把全部打开只是第一步规范 02-01-01 要求把审计级别调到全部、身份验证改为SQL Server 和 Windows 混合模式并验证登录被记录。图形界面改完只是配置生效真正的验证要靠日志读取。-- 确认当前审计级别0无 1仅成功 2仅失败 3成功和失败 EXEC sp_configure show advanced options, 1; RECONFIGURE; EXEC sp_configure audit level;返回值是 3 才算达标。改完配置后故意用错误密码登录几次、再用正确密码登录一次然后去错误日志里核对是否同时出现失败和成功记录。很多实例开了审计但日志文件轮转策略缺失几十 GB 的 ERRORLOG 堆在系统盘上最后把盘撑满导致实例异常这是比没开审计更常见的现场问题。建议配置日志文件数量上限并纳入磁盘监控。注意混合认证模式意味着 SQL 登录可用如果业务全部走 Windows 认证维持仅 Windows其实更安全规范里的混合模式是给需要 SQL 登录的场景用的不要机械照搬。3.2 协议收敛与传输加密改完必须回连验证规范 03-01-01 建议只保留 TCP/IP、禁用其他协议03-01-04 要求开启强制协议加密。前者在 SQL Server 配置管理器的协议列表里操作后者在 TCP/IP 属性或服务器网络配置工具里勾选。# 改完协议后从客户端侧验证连通性先测端口再测登录 # 默认实例 1433命名实例需先查 SQL Browser 或直接指定端口 telnet 10.0.0.21 1433 # 用 sqlcmd 显式加 -N 参数走加密连接验证强制加密是否真的生效 sqlcmd -S 10.0.0.21,1433 -U app_user -P 口令 -N -Q SELECT VERSION-N 参数强制客户端使用加密如果服务端已开启强制加密而客户端不加参数仍能连上说明配置没落到实际监听上常见于集群或改了注册表但没重启服务。另一个坑是强制加密后老客户端驱动不支持 TLS 版本应用侧直接报连接错误所以这条必须放在变更窗口里做并且提前确认所有应用的驱动版本。3.3 危险扩展存储过程的停用与恢复规范 04-01-01 给了一长串 sp_dropextendedproc涵盖 xp_cmdshell、xp_reg* 系列、sp_OACreate 系列等。删除前必须想清楚业务里有没有人用 xp_cmdshell 做定时导出、用 sp_OACreate 调 COM 组件发邮件。这类祖传脚本在中小系统里极其常见。-- 删除前先确认哪些扩展存储过程存在且被引用 SELECT name, dll_name FROM sys.extended_procedures ORDER BY name; -- 确认无人使用后逐个删除xp_cmdshell 建议改用 sp_configure 关闭 EXEC sp_configure show advanced options, 1; RECONFIGURE; EXEC sp_configure xp_cmdshell, 0; RECONFIGURE; -- 若必须删除先导出 DLL 名字以便恢复 EXEC sp_dropextendedproc xp_dirtree;xp_cmdshell 优先用 sp_configure 关闭而不是直接 drop因为关闭是可逆的、一条命令能开回来而 drop 掉的扩展存储过程要恢复得重新注册 DLL路径和版本对不上就会失败。这就是规范里回退方案那一栏经常被无视的代价。上线前把这些删除操作写成带注释的脚本入库是我个人的硬性习惯。4. 加固实施避坑五条血泪经验4.1 现象改完认证模式应用集体连不上原因把仅 Windows改成混合模式通常不影响原有 Windows 登录但反过来把混合改成仅 Windows 会立刻踢掉所有 SQL 登录。规范只写了调整为混合没说反向操作的风险。解决改认证模式前先查SELECT name FROM sys.sql_logins WHERE is_disabled 0有启用的 SQL 登录且应用在用就不能往仅 Windows方向改。变更前把这条查询结果和应用连接串配置一起核对。4.2 现象删了无效账号第二天作业全红原因某些 SQL 登录被 SQL Server Agent 作业的 owner 引用着删掉登录名后作业执行身份失效报无法获取有关 Windows NT 组/用户的信息。解决删登录名之前先查作业归属SELECT j.name, p.name AS owner FROM msdb.dbo.sysjobs j JOIN sys.server_principals p ON p.sid j.owner_sid。有作业挂在待删账号上的先把 owner 改到服务账号再删登录名。4.3 现象开启强制加密后备份还原和复制链路断掉原因强制加密只作用于客户端连接但复制、日志传送、链接服务器这些组件使用的是各自的连接配置证书不受信任时握手失败。解决先在所有参与节点上验证证书链把实例证书导入到对端受信任存储镜像和可用性组场景还要确认端点证书没有过期。这类变更必须整链路一起做不能一台一台推。4.4 现象删了 xp_cmdshell某个历史遗留的定时任务静默失败原因任务通过 xp_cmdshell 调外部批处理删除后作业仍显示成功因为错误被 TRY/CATCH 吃掉或未检查返回码数据实际没导出去。解决删除前用扩展事件或 SQL 审计抓一周的module_start事件筛出对目标存储过程的调用来源。确认无人调用再动手动手后一周内每天抽查一次相关作业的实际产出文件。4.5 现象审计日志把系统盘撑满导致实例挂起原因只开了审计没配日志轮转上限ERRORLOG 无限增长。解决在实例属性里限制错误日志文件数量一般 6 到 10 个足够并把日志目录迁到数据盘。同时给磁盘加阈值告警别等实例自己报错才发现。5. 把清单变成可重复执行的核查脚本一个判定表加一段巡检 SQL规范最大的价值是判断依据那一栏——每条都写了怎么验证是否达标。但人工逐条核对着实低效我的做法是把所有条目压成一张判定表再写一段巡检 SQL 自动产出当前值/期望值/是否达标三列每周跑一次。第一步先把规范条目整理成如下结构字段固定方便脚本消费编号检查项判定方式期望值风险01-01-01一账号一用户统计非系统登录名数量并与人员名单比对无共享账号高01-01-02无效账号清理查 90 天无登录记录的 SQL 登录0 条高01-01-03启动账号权限whoami /groups 查服务账号组不含 Administrators高01-01-05角色化管理统计直接授对象权限的用户数尽量为 0中01-01-06空密码账号查 password_hash 为空0 条高02-01-01登录审计查 audit level3高03-01-01协议收敛查协议列表仅 TCP/IP中03-01-04强制加密客户端 -N 连接测试成功高04-01-01危险存储过程查 sys.extended_procedures无高危项高第二步把能自动化判定的项写成一条巡检 SQL输出统一的结果集方便直接贴到周报里。-- 加固基线巡检一条语句输出多项检查结果 SELECT 01-01-06 空密码账号数 AS 检查项, CAST(COUNT(*) AS VARCHAR(10)) AS 当前值, 0 AS 期望值 FROM sys.sql_logins WHERE password_hash IS NULL UNION ALL SELECT 01-01-02 90天未登录SQL账号数, CAST(COUNT(*) AS VARCHAR(10)), 0 FROM sys.sql_logins WHERE is_disabled 0 AND name NOT IN (sa) AND (modify_date IS NULL OR modify_date DATEADD(DAY,-90,GETDATE())) UNION ALL SELECT 高权限角色成员数(sysadmin), CAST(COUNT(*) AS VARCHAR(10)), 3 FROM sys.server_role_members rm JOIN sys.server_principals r ON r.principal_id rm.role_principal_id WHERE r.name sysadmin UNION ALL SELECT 存在高危扩展存储过程数, CAST(COUNT(*) AS VARCHAR(10)), 0 FROM sys.extended_procedures WHERE name IN (xp_cmdshell,xp_regwrite,xp_regread,sp_OACreate);这段脚本的逻辑是把查什么和合格线是多少放在同一行输出一眼就能看出哪一项没达标。参数上要注意 DATEADD 的 -90 是按登录名最后一次修改时间估算活跃度属于近似判断真正精确要看登录审计日志sysadmin 成员数给3是个经验阈值实例规模大的环境可以放宽但必须逐个有说明。第三步把没法 SQL 化的项服务账号权限、协议列表、强制加密写进人工核查单每季度过一遍并留签字记录。自动化管住能管住的人工兜住剩下的这套组合比一次性整改完就撒手要靠谱得多。从那以后我每次接手新实例都强制先跑一遍这段巡检把结果存档再谈整改——没有基线数据后面所有改好了都是口头声称审计一问就露馅。这份规范本身不复杂复杂的是把它变成你自己环境里可重复执行的流程希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/27 3:05:31 · 阅读 1.2k SQL Server数据库加固规范：账号权限、审计加密与基线巡检实战
简介《Sql Server数据库系统加固规范》面向数据库管理员、安全运维与等保合规人员聚焦 SQL Server 实例的基线加固与安全检查落地。文档按账号管理与认证授权、日志配置、通信协议、设备其他安全要求四个章节组织逐条给出 SHG-Mssql 编号、实施目的、问题影响、系统当前状态、配置步骤、回退方案、判断依据、实施风险与重要等级便于对照排查和整改。压缩包仅含1个 doc 文件约1.73MB结构紧凑适合打印或随查随用。已有245人学习下载可作为内部加固模板和审计参考。读者可据此梳理最小权限、口令策略、登录失败锁定、双因素认证等账号要求也能获取日志全量记录、SSL/TLS 加密通信、防火墙与入侵检测、防病毒及定期检查更新等配置思路并借助回退方案和风险等级评估变更影响形成可执行的加固清单。1. 拿到一份Sql Server加固规范先别急着照抄这份编号化的清单到底解决什么问题很多团队做数据库等保整改时最头疼的不是不会敲命令而是根本不知道该查哪些项、查到什么程度算合格。这份《Sql Server数据库系统加固规范》给出的不是教程而是一套带编号、带判定依据、带回退方案的核查清单——账号管理、认证授权、日志配置、通信协议、设备其他安全要求四大类每条都写明了实施目的、问题影响、当前状态核查方法、实施步骤、回退方案、判断依据和风险等级。它的价值在于把加固从凭经验拍脑袋变成可对账、可验收、可回溯的流程。适合谁看手上管着几台到几十台 SQL Server 实例、要做安全基线核查的运维和 DBA正在准备等保测评或内部审计材料的安全工程师以及被要求一个月内把数据库安全整改做完却不知道从哪下手的项目负责人。它默认面向 SQL Server 2000 时代的实例但绝大多数思路对 2005 以上版本仍然成立只是落地命令要换。2. 账号与认证授权六条基线怎么落到具体实例上账号这一块是整份规范里条目最多、风险标注最重的部分六条编号全挂着实施风险高、重要等级★★★这不是吓唬人。账号改动的翻车率恰恰最高——删错一个登录名业务连接池整片报错改错一个角色报表系统第二天全白屏。所以这里的关键不是照做而是先摸清现状再按可回退的方式改。2.1 先跑一遍现状盘点别上来就改规范里每条都要求先记录系统当前状态这一步很多人嫌麻烦跳过结果改完出问题连回退到哪都不知道。SQL Server 的登录名和用户信息分布在两套系统视图里早期版本用 syslogins / sysusers2005 以后建议改用 sys.server_principals 和 sys.database_principals。下面这段盘点脚本我一般会作为整改第一步固定执行输出留档。-- 盘点实例级登录名名称、类型、是否启用、创建时间、默认库 SELECT name, type_desc AS 登录类型, -- SQL_LOGIN / WINDOWS_LOGIN / WINDOWS_GROUP is_disabled AS 是否禁用, create_date AS 创建时间, default_database_name AS 默认数据库 FROM sys.server_principals WHERE type IN (S,U,G) -- SSQL登录 UWindows登录 GWindows组 ORDER BY name; -- 盘点服务器角色成员找出谁拥有 sysadmin / securityadmin SELECT r.name AS 角色名, m.name AS 成员名 FROM sys.server_role_members rm JOIN sys.server_principals r ON r.principal_id rm.role_principal_id JOIN sys.server_principals m ON m.principal_id rm.member_principal_id WHERE r.name IN (sysadmin,securityadmin,serveradmin) ORDER BY r.name, m.name;第一段查出所有能登录实例的身份重点看三件事有没有已经不用却还启用的账号、有没有不该存在的 SQL 登录尤其在只做 Windows 认证的环境里、默认数据库是不是乱指。第二段查高权限角色成员sysadmin 的成员数量是硬指标正常业务库里这个数字应该能一只手数过来超了就要逐个问清楚用途。提示盘点结果务必导出一份到工单或配置库里存档这份文件就是后面所有回退操作的地图。2.2 一账号一用户别让多人共用 sa规范 01-01-01 要求为不同的管理员分配不同的账号实施步骤给的是 sp_addlogin。这个存储过程在新版本里虽然还能用但已不推荐标准做法是 CREATE LOGIN。核心诉求只有一个任何操作都能追溯到具体的人而不是永远看到 sa 在跑。-- 为每个管理员建独立登录名强制密码策略 CREATE LOGIN dba_zhang WITH PASSWORD N强口令, CHECK_POLICY ON, CHECK_EXPIRATION ON; -- 只授予必要的服务器角色不要直接给 sysadmin ALTER SERVER ROLE securityadmin ADD MEMBER dba_zhang; -- 按需映射到具体业务库并只给 db_datareader 这类低权限角色 USE SalesDB; CREATE USER dba_zhang FOR LOGIN dba_zhang; ALTER ROLE db_datareader ADD MEMBER dba_zhang;CHECK_POLICY ON 让登录名继承 Windows 的密码复杂度与锁定策略这是性价比最高的一个参数比手工写密码规则可靠得多。CREATE USER 那一步决定了这个账号在库内的身份很多新手只建了登录名却忘了映射用户结果人连得上实例却看不到任何库误以为权限给错了。2.3 空密码与弱口令一条查询就能筛出来规范 01-01-06 要求清理空密码账号给的是Select name,Password from syslogins where password is null。这条在 2005 以后要改写因为密码哈希已经不在 syslogins 里了判断空密码要看 sys.sql_logins 的 password_hash 是否为空。-- 找出密码为空的 SQL 登录2005 及以上 SELECT name, is_disabled, create_date FROM sys.sql_logins WHERE password_hash IS NULL; -- 找出从未改过密码、创建时间很早的可疑账号人工复核 SELECT name, create_date, modify_date FROM sys.sql_logins WHERE create_date 2020-01-01 ORDER BY create_date;password_hash 为空基本等同于空密码可登录这种账号要么立刻改密要么直接禁用。第二段查老古董账号是个土办法但很有效长期不动的登录名往往对应已离职人员或早已下线的系统。改密码统一走ALTER LOGIN 名称 WITH PASSWORD N新口令注意这个操作会让该账号已缓存的连接在下次重连时失效改之前确认没有长连接业务依赖。2.4 权限最小化与角色化管理规范 01-01-04 讲权限最小化01-01-05 讲用角色管理对象权限。这两条其实是一件事的两面不要给具体的人逐个授对象权限而是先建角色、给角色授权、再把人塞进角色。这样人员变动时只需增删角色成员不用满库翻权限。-- 建一个只读报表角色授予 SELECT 权限 USE SalesDB; CREATE ROLE rpt_reader; GRANT SELECT ON SCHEMA::dbo TO rpt_reader; -- 建一个只允许执行指定存储过程的角色 CREATE ROLE app_executor; GRANT EXECUTE ON OBJECT::dbo.usp_GetOrder TO app_executor; -- 人员入角色而不是逐个授权 ALTER ROLE rpt_reader ADD MEMBER report_user01;这里有个容易忽略的边界GRANT SELECT ON SCHEMA::dbo 会给该 schema 下所有现存和将来新建的对象都授权如果库里混着敏感表和普通表就得改成按对象授权。我见过的翻车案例是一个只读账号因为这个 schema 级授权拿到了人事表的查询权审计时被点名。稳妥做法是先按 schema 划清业务边界跨边界的敏感表单独收紧。2.5 启动账号与服务账户的权限收敛规范 01-01-03 要求限制启动 SQL Server 服务的账号权限建议把服务账号从 Users 组移除、不加入 Administrators 组。这条的现实意义是服务进程被攻破时攻击者继承的是服务账号权限账号权限越大横向移动的空间越大。落地检查在 Windows 侧打开服务管理器找到 SQL Server 服务看登录页签用的是哪个账户再用whoami /groups在该账户上下文里确认它不在 Administrators 组。改服务账号是个高风险动作必须停机窗口内做改完要验证 SQL Server Agent 作业、备份目录、数据库文件目录的 ACL 都对新账号可读写,否则会出现服务能起但备份作业全失败的情况。3. 日志、通信协议与危险存储过程容易被跳过的三类加固相比账号这一块的条目少但技术含量不低而且特别容易看着做了其实没生效。审计开启后没验证、协议改了没测连接、存储过程删了没留恢复手段是三个高频失误点。这三类操作的共同特征是影响面隐蔽往往要等下一次故障或审计才暴露。3.1 登录审计把全部打开只是第一步规范 02-01-01 要求把审计级别调到全部、身份验证改为SQL Server 和 Windows 混合模式并验证登录被记录。图形界面改完只是配置生效真正的验证要靠日志读取。-- 确认当前审计级别0无 1仅成功 2仅失败 3成功和失败 EXEC sp_configure show advanced options, 1; RECONFIGURE; EXEC sp_configure audit level;返回值是 3 才算达标。改完配置后故意用错误密码登录几次、再用正确密码登录一次然后去错误日志里核对是否同时出现失败和成功记录。很多实例开了审计但日志文件轮转策略缺失几十 GB 的 ERRORLOG 堆在系统盘上最后把盘撑满导致实例异常这是比没开审计更常见的现场问题。建议配置日志文件数量上限并纳入磁盘监控。注意混合认证模式意味着 SQL 登录可用如果业务全部走 Windows 认证维持仅 Windows其实更安全规范里的混合模式是给需要 SQL 登录的场景用的不要机械照搬。3.2 协议收敛与传输加密改完必须回连验证规范 03-01-01 建议只保留 TCP/IP、禁用其他协议03-01-04 要求开启强制协议加密。前者在 SQL Server 配置管理器的协议列表里操作后者在 TCP/IP 属性或服务器网络配置工具里勾选。# 改完协议后从客户端侧验证连通性先测端口再测登录 # 默认实例 1433命名实例需先查 SQL Browser 或直接指定端口 telnet 10.0.0.21 1433 # 用 sqlcmd 显式加 -N 参数走加密连接验证强制加密是否真的生效 sqlcmd -S 10.0.0.21,1433 -U app_user -P 口令 -N -Q SELECT VERSION-N 参数强制客户端使用加密如果服务端已开启强制加密而客户端不加参数仍能连上说明配置没落到实际监听上常见于集群或改了注册表但没重启服务。另一个坑是强制加密后老客户端驱动不支持 TLS 版本应用侧直接报连接错误所以这条必须放在变更窗口里做并且提前确认所有应用的驱动版本。3.3 危险扩展存储过程的停用与恢复规范 04-01-01 给了一长串 sp_dropextendedproc涵盖 xp_cmdshell、xp_reg* 系列、sp_OACreate 系列等。删除前必须想清楚业务里有没有人用 xp_cmdshell 做定时导出、用 sp_OACreate 调 COM 组件发邮件。这类祖传脚本在中小系统里极其常见。-- 删除前先确认哪些扩展存储过程存在且被引用 SELECT name, dll_name FROM sys.extended_procedures ORDER BY name; -- 确认无人使用后逐个删除xp_cmdshell 建议改用 sp_configure 关闭 EXEC sp_configure show advanced options, 1; RECONFIGURE; EXEC sp_configure xp_cmdshell, 0; RECONFIGURE; -- 若必须删除先导出 DLL 名字以便恢复 EXEC sp_dropextendedproc xp_dirtree;xp_cmdshell 优先用 sp_configure 关闭而不是直接 drop因为关闭是可逆的、一条命令能开回来而 drop 掉的扩展存储过程要恢复得重新注册 DLL路径和版本对不上就会失败。这就是规范里回退方案那一栏经常被无视的代价。上线前把这些删除操作写成带注释的脚本入库是我个人的硬性习惯。4. 加固实施避坑五条血泪经验4.1 现象改完认证模式应用集体连不上原因把仅 Windows改成混合模式通常不影响原有 Windows 登录但反过来把混合改成仅 Windows 会立刻踢掉所有 SQL 登录。规范只写了调整为混合没说反向操作的风险。解决改认证模式前先查SELECT name FROM sys.sql_logins WHERE is_disabled 0有启用的 SQL 登录且应用在用就不能往仅 Windows方向改。变更前把这条查询结果和应用连接串配置一起核对。4.2 现象删了无效账号第二天作业全红原因某些 SQL 登录被 SQL Server Agent 作业的 owner 引用着删掉登录名后作业执行身份失效报无法获取有关 Windows NT 组/用户的信息。解决删登录名之前先查作业归属SELECT j.name, p.name AS owner FROM msdb.dbo.sysjobs j JOIN sys.server_principals p ON p.sid j.owner_sid。有作业挂在待删账号上的先把 owner 改到服务账号再删登录名。4.3 现象开启强制加密后备份还原和复制链路断掉原因强制加密只作用于客户端连接但复制、日志传送、链接服务器这些组件使用的是各自的连接配置证书不受信任时握手失败。解决先在所有参与节点上验证证书链把实例证书导入到对端受信任存储镜像和可用性组场景还要确认端点证书没有过期。这类变更必须整链路一起做不能一台一台推。4.4 现象删了 xp_cmdshell某个历史遗留的定时任务静默失败原因任务通过 xp_cmdshell 调外部批处理删除后作业仍显示成功因为错误被 TRY/CATCH 吃掉或未检查返回码数据实际没导出去。解决删除前用扩展事件或 SQL 审计抓一周的module_start事件筛出对目标存储过程的调用来源。确认无人调用再动手动手后一周内每天抽查一次相关作业的实际产出文件。4.5 现象审计日志把系统盘撑满导致实例挂起原因只开了审计没配日志轮转上限ERRORLOG 无限增长。解决在实例属性里限制错误日志文件数量一般 6 到 10 个足够并把日志目录迁到数据盘。同时给磁盘加阈值告警别等实例自己报错才发现。5. 把清单变成可重复执行的核查脚本一个判定表加一段巡检 SQL规范最大的价值是判断依据那一栏——每条都写了怎么验证是否达标。但人工逐条核对着实低效我的做法是把所有条目压成一张判定表再写一段巡检 SQL 自动产出当前值/期望值/是否达标三列每周跑一次。第一步先把规范条目整理成如下结构字段固定方便脚本消费编号检查项判定方式期望值风险01-01-01一账号一用户统计非系统登录名数量并与人员名单比对无共享账号高01-01-02无效账号清理查 90 天无登录记录的 SQL 登录0 条高01-01-03启动账号权限whoami /groups 查服务账号组不含 Administrators高01-01-05角色化管理统计直接授对象权限的用户数尽量为 0中01-01-06空密码账号查 password_hash 为空0 条高02-01-01登录审计查 audit level3高03-01-01协议收敛查协议列表仅 TCP/IP中03-01-04强制加密客户端 -N 连接测试成功高04-01-01危险存储过程查 sys.extended_procedures无高危项高第二步把能自动化判定的项写成一条巡检 SQL输出统一的结果集方便直接贴到周报里。-- 加固基线巡检一条语句输出多项检查结果 SELECT 01-01-06 空密码账号数 AS 检查项, CAST(COUNT(*) AS VARCHAR(10)) AS 当前值, 0 AS 期望值 FROM sys.sql_logins WHERE password_hash IS NULL UNION ALL SELECT 01-01-02 90天未登录SQL账号数, CAST(COUNT(*) AS VARCHAR(10)), 0 FROM sys.sql_logins WHERE is_disabled 0 AND name NOT IN (sa) AND (modify_date IS NULL OR modify_date DATEADD(DAY,-90,GETDATE())) UNION ALL SELECT 高权限角色成员数(sysadmin), CAST(COUNT(*) AS VARCHAR(10)), 3 FROM sys.server_role_members rm JOIN sys.server_principals r ON r.principal_id rm.role_principal_id WHERE r.name sysadmin UNION ALL SELECT 存在高危扩展存储过程数, CAST(COUNT(*) AS VARCHAR(10)), 0 FROM sys.extended_procedures WHERE name IN (xp_cmdshell,xp_regwrite,xp_regread,sp_OACreate);这段脚本的逻辑是把查什么和合格线是多少放在同一行输出一眼就能看出哪一项没达标。参数上要注意 DATEADD 的 -90 是按登录名最后一次修改时间估算活跃度属于近似判断真正精确要看登录审计日志sysadmin 成员数给3是个经验阈值实例规模大的环境可以放宽但必须逐个有说明。第三步把没法 SQL 化的项服务账号权限、协议列表、强制加密写进人工核查单每季度过一遍并留签字记录。自动化管住能管住的人工兜住剩下的这套组合比一次性整改完就撒手要靠谱得多。从那以后我每次接手新实例都强制先跑一遍这段巡检把结果存档再谈整改——没有基线数据后面所有改好了都是口头声称审计一问就露馅。这份规范本身不复杂复杂的是把它变成你自己环境里可重复执行的流程希望帮到你。本文还有配套的精品资源点击获取