SQL Server等保测评实战：从身份鉴别到安全审计的完整命令指南

1. 项目概述：从合规要求到实战命令

在信息安全领域，等级保护测评（简称“等保测评”）是每个系统管理员和数据库管理员都必须面对的一道“必答题”。它不是一次性的安全检查，而是一套持续性的合规框架，旨在通过技术和管理手段，保障信息系统安全稳定运行。当测评对象是承载着核心业务数据的 SQL Server 数据库时，这项工作就变得尤为关键和具体。

很多 DBA 或安全工程师在初次接触 SQL Server 等保测评时，往往会感到无从下手：测评要求文档洋洋洒洒，但具体到数据库层面，到底要查什么？用什么查？标准答案是什么？这份指南的目的，就是为你提供一套可直接用于实战的 SQL Server 测评命令集，并深入解释每条命令背后的安全逻辑和合规要求。我们不止于罗列命令，更会拆解等保2.0中关于数据库安全的相关控制点，告诉你为什么需要执行这些检查，以及如何根据检查结果进行加固。无论你是正在准备测评，还是希望日常提升数据库安全水位，这些命令和思路都将成为你工具箱里的利器。

2. 等保2.0中与SQL Server相关的核心控制点解析

等保2.0将安全要求分为安全通用要求和安全扩展要求。对于 SQL Server 这类数据库系统，我们主要关注安全通用要求中的部分控制点，它们直接映射到数据库的配置、访问和审计层面。

2.1 身份鉴别与访问控制

这是等保测评的基石。对应到 SQL Server，核心是确保“谁”能“以何种方式”访问“哪些数据”。测评重点包括：

1. 口令复杂度与生存周期：检查是否启用了密码策略，密码长度、复杂性是否满足要求，是否有强制修改周期。
2. 登录失败处理：是否设置了账户锁定策略，例如连续失败登录多少次后锁定账户，锁定时间多长。这是防止暴力破解的关键。
3. 权限最小化原则：检查用户和角色的权限分配是否遵循最小权限原则，特别是sa等内置高权限账户的使用情况，以及是否有多余的默认账户被启用。
4. 远程连接管理：检查是否禁用了不必要的协议（如命名管道），是否对远程连接地址进行了限制。

注意：很多老旧系统为了方便，常常使用弱密码或空密码，或者让应用程序直接使用sa账户连接，这在等保测评中是严重扣分项，必须整改。

2.2 安全审计

“无审计，无安全”。等保要求安全事件应可追溯。对于 SQL Server，这意味着：

1. 审计功能启用：是否启用了 SQL Server 审计或更细粒度的服务器/数据库审计规范。
2. 审计内容覆盖：审计日志是否记录了关键事件，如成功的和失败的登录尝试、对敏感数据表（如包含用户信息、交易记录的表）的访问（SELECT、UPDATE、DELETE）、权限变更（GRANT、DENY）、架构更改（CREATE、ALTER、DROP）等。
3. 日志保护与存储：审计日志是否被妥善保护，防止非授权删除或篡改，是否有足够的存储空间和归档策略。

2.3 入侵防范与恶意代码防范

数据库服务器本身也应具备一定的防御能力。

1. 补丁管理：SQL Server 实例是否安装了最新的安全补丁？已知的高危漏洞（如某些版本的远程代码执行漏洞）是否已被修复？
2. 禁用危险功能：是否禁用了xp_cmdshell、OLE Automation Procedures等可能被利用来执行操作系统命令或发起攻击的扩展存储过程？
3. 端点安全：数据库服务器所在的主机是否安装了防恶意代码软件，并定期更新？

2.4 数据安全与备份恢复

这是数据库的“生命线”。

1. 数据完整性：是否使用了约束、触发器等方式保障业务数据的完整性？
2. 敏感信息保护：对于身份证号、手机号、密码等敏感数据，是否进行加密存储（如使用 Always Encrypted）或脱敏处理？
3. 备份与恢复：是否有完整的备份策略（全备、差异备、日志备）？备份周期是否满足业务恢复时间目标（RTO）和恢复点目标（RPO）？是否定期进行恢复演练？

理解了这些控制点，我们接下来的命令集就有了明确的靶心。每一条命令都是为了验证或获取上述某个或某几个控制点的当前状态。

3. 实战测评命令全集与深度解读

以下命令均在 SQL Server Management Studio (SSMS) 中以具有相应权限的账户（通常需要VIEW SERVER STATE、VIEW ANY DEFINITION等权限）执行。我们将按检查类别组织命令。

3.1 身份鉴别与账户安全核查

这部分命令用于检查登录账户的安全配置。

命令1：检查登录账户及认证模式

SELECT name, type_desc, is_disabled, create_date, modify_date FROM sys.server_principals WHERE type IN ('S', 'U', 'G') -- S: SQL登录, U: Windows登录, G: Windows组 ORDER BY type_desc, name;

解读与操作意图：这条命令列出所有服务器级登录主体。is_disabled列为 1 表示账户已禁用，这是安全检查的第一步，应禁用所有测试账户、默认示例账户（如BUILTIN\Guests）以及不再使用的账户。同时，观察type_desc，等保通常建议优先使用 Windows 身份验证（‘WINDOWS_LOGIN’）而非 SQL Server 身份验证（‘SQL_LOGIN’），因为前者可以集成操作系统的账户管理策略。

命令2：检查密码策略与过期

SELECT name, type_desc, is_disabled, LOGINPROPERTY(name, 'IsMustChange') AS must_change, -- 下次登录是否必须改密 LOGINPROPERTY(name, 'DaysUntilExpiration') AS days_until_expire, -- 密码过期天数 LOGINPROPERTY(name, 'LockoutTime') AS lockout_time, -- 锁定时间 LOGINPROPERTY(name, 'BadPasswordCount') AS bad_password_count, -- 错误密码次数 LOGINPROPERTY(name, 'BadPasswordTime') AS bad_password_time -- 上次错误密码时间 FROM sys.server_principals WHERE type = 'S' -- 仅查看SQL登录 AND is_disabled = 0; -- 仅查看启用账户

解读与操作意图：这是等保“身份鉴别”要求的直接体现。你需要关注：

• must_change：是否为1，对于新建账户或强制改密后应为此状态。
• days_until_expire：应为一个合理的正数（如90），表示密码将在多少天后过期。为0表示已过期，NULL表示密码永不过期（不符合等保要求）。
• lockout_time：如果不为NULL，说明该账户因多次登录失败被锁定。结合bad_password_count可以分析攻击迹象。 测评时，需要确认 SQL Server 是否强制执行了操作系统的密码策略（在服务器属性-安全性中查看），或者对于独立部署，是否配置了类似的账户锁定阈值和锁定时间。

命令3：检查sa账户状态与远程连接

SELECT name, is_disabled FROM sys.server_principals WHERE name = 'sa'; -- 检查是否允许远程连接（需查看服务器配置） EXEC sp_configure 'remote access'; -- 已过时，但某些版本仍可参考 EXEC sp_configure 'remote admin connections'; -- 专用管理员连接(DAC)

解读与操作意图：sa是最高权限账户，是攻击的首要目标。等保测评中，通常会要求：1) 重命名sa账户；或 2) 禁用sa账户（is_disabled=1）。绝对禁止使用默认的sa账户和弱密码进行远程业务连接。remote admin connections通常只应在紧急故障排查时启用，日常应禁用。

3.2 权限与访问控制检查

权限泛滥是内部威胁和数据泄露的主要根源。

命令4：检查服务器角色成员

SELECT r.name AS role_name, m.name AS member_name FROM sys.server_role_members rm JOIN sys.server_principals r ON rm.role_principal_id = r.principal_id JOIN sys.server_principals m ON rm.member_principal_id = m.principal_id WHERE r.type = 'R' ORDER BY r.name, m.name;

解读与操作意图：重点检查sysadmin、securityadmin、processadmin等高级服务器角色的成员。任何非绝对必要的账户都不应属于sysadmin。一个常见的错误是，为了方便，将应用程序的登录账户直接加入sysadmin，这等同于赋予了该应用对数据库服务器的完全控制权，风险极高。

命令5：检查数据库用户及角色映射

-- 切换到具体业务数据库 USE [YourDatabaseName]; GO SELECT dp.name AS user_name, dp.type_desc, r.name AS role_name FROM sys.database_principals dp LEFT JOIN sys.database_role_members drm ON dp.principal_id = drm.member_principal_id LEFT JOIN sys.database_principals r ON drm.role_principal_id = r.principal_id WHERE dp.type IN ('S', 'U', 'G') -- SQL用户, Windows用户, Windows组 AND dp.name NOT IN ('dbo', 'guest', 'INFORMATION_SCHEMA', 'sys') ORDER BY dp.name;

解读与操作意图：这条命令查看在特定数据库内，每个用户属于哪些数据库角色（如db_owner,db_datareader,db_datawriter）。等保要求权限最小化，因此需要逐一审查：

• 普通业务用户是否被赋予了db_owner权限？这通常是不必要的。
• 只读报表用户是否仅属于db_datareader角色？
• 是否存在权限过大的自定义角色？

命令6：检查直接对象权限

USE [YourDatabaseName]; GO SELECT USER_NAME(grantee_principal_id) AS grantee, OBJECT_NAME(major_id) AS object_name, permission_name, state_desc FROM sys.database_permissions WHERE class_desc = 'OBJECT_OR_COLUMN' AND minor_id = 0 -- 对象级权限 ORDER BY grantee, object_name;

解读与操作意图：除了角色权限，用户或角色可能被直接授予了表、视图、存储过程上的权限（如SELECT,UPDATE,EXECUTE）。这条命令能列出所有直接授权。测评时需要关注是否有过于宽泛的授权，例如将UPDATE权限授予了整个表，而不是通过存储过程来间接更新。

3.3 安全配置与漏洞防范检查

命令7：检查扩展存储过程状态

EXEC sp_configure 'show advanced options', 1; RECONFIGURE; GO EXEC sp_configure 'xp_cmdshell'; EXEC sp_configure 'Ole Automation Procedures'; -- 其他如 `sp_send_dbmail` 等也应根据业务需要检查 GO EXEC sp_configure 'show advanced options', 0; RECONFIGURE;

解读与操作意图：xp_cmdshell允许在 SQL Server 内执行操作系统命令，是攻击者梦寐以求的跳板。Ole Automation Procedures同样可能带来安全风险。在等保测评中，除非业务有明确且经过审批的需求，否则这些选项的run_value应为0（禁用）。启用它们需要强有力的理由和严格的操作审计。

命令8：检查SQL Server版本与补丁

SELECT @@VERSION AS sql_server_version;

解读与操作意图：输出结果包含了 SQL Server 的完整版本号、内部版本号和补丁级别。你需要将此信息与微软官方安全公告进行比对，确认是否已安装最新的安全更新。运行不受支持的旧版本（如 SQL Server 2008 R2 已结束扩展支持）在等保测评中会被视为高风险项。

命令9：检查数据库引擎配置

EXEC sp_configure;

解读与操作意图：这条命令返回所有服务器配置选项。除了上述高级选项，还需关注：

• cross db ownership chaining：是否启用？通常应禁用以防止权限提升。
• scan for startup procs：是否扫描自动执行的存储过程？需确认这些存储过程的安全性。
• clr enabled：是否启用了 CLR 集成？如果未使用，建议禁用。

3.4 安全审计功能检查

命令10：检查服务器审计规范

SELECT audit_id, name, status_desc, create_date, modify_date FROM sys.server_audits; SELECT audit_id, action_id, class_desc, is_group, containing_group_name FROM sys.server_audit_specifications_details AS sd JOIN sys.server_audit_specifications AS s ON sd.server_specification_id = s.server_specification_id;

解读与操作意图：第一句查看定义了哪些服务器审计。status_desc应为ON。第二句查看审计规范的具体细节，关注是否审计了SUCCESSFUL_LOGIN_GROUP和FAILED_LOGIN_GROUP（成功/失败登录）、LOGOUT_GROUP（注销）、SERVER_ROLE_MEMBER_CHANGE_GROUP（服务器角色变更）等关键事件组。

命令11：检查数据库审计规范

USE [YourDatabaseName]; GO SELECT audit_id, name, status_desc FROM sys.database_audit_specifications; SELECT audit_id, action_id, class_desc, schema_name, object_name, column_name FROM sys.database_audit_specification_details AS dd JOIN sys.database_audit_specifications AS d ON dd.database_specification_id = d.database_specification_id;

解读与操作意图：数据库级审计更细粒度。检查是否对关键表的SELECT、INSERT、UPDATE、DELETE操作进行了审计（action_id对应SL、IN、DL、UP）。等保三级以上通常要求对重要数据的访问行为进行审计。

命令12：查看默认跟踪（Default Trace）

SELECT * FROM fn_trace_getinfo(default);

解读与操作意图：SQL Server 默认跟踪会记录一些关键事件，如对象创建/删除、权限更改等。虽然它不是等保要求的正式审计手段，但可以作为辅助信息来源。检查其是否运行（property=2的value=1）以及日志文件路径。

3.5 数据安全与备份状态检查

命令13：检查数据库备份历史

USE msdb; GO SELECT TOP 50 bs.database_name, bs.type, -- D: 数据库, I: 差异, L: 日志 bs.backup_start_date, bs.backup_finish_date, bmf.physical_device_name, bs.backup_size / 1024 / 1024 AS backup_size_mb FROM backupset bs INNER JOIN backupmediafamily bmf ON bs.media_set_id = bmf.media_set_id WHERE bs.database_name = N'YourDatabaseName' ORDER BY bs.backup_start_date DESC;

解读与操作意图：这是验证备份策略是否有效执行的最直接证据。你需要确认：

• 备份类型是否完整（全备、差异备、日志备）？
• 备份周期是否符合既定的 RPO 要求（例如，每天一次全备，每小时一次日志备）？
• 备份文件是否存储在安全、独立的位置（physical_device_name）？

命令14：检查数据库加密状态

USE [YourDatabaseName]; GO SELECT db_name(database_id) AS db_name, encryption_state_desc, key_algorithm, encryptor_type FROM sys.dm_database_encryption_keys;

解读与操作意图：加密是保护静态数据（Data at Rest）的重要手段。encryption_state_desc显示了加密状态（如ENCRYPTED,UNENCRYPTED）。等保对三级及以上系统的重要数据有加密存储要求。这里检查的是透明数据加密（TDE）状态。对于列级加密（如 Always Encrypted），需要检查具体的表列属性。

4. 测评实操流程与结果分析框架

有了命令集，我们还需要一个系统的执行流程和分析方法，让测评工作有条不紊。

4.1 测评前准备与环境确认

在运行任何命令前，必须做好准备工作：

1. 获取授权：确保你拥有对目标 SQL Server 实例进行安全评估的正式授权。未经授权的扫描和探测可能违反法律或公司政策。
2. 明确范围：与项目负责人确认需要测评的 SQL Server 实例列表和数据库列表。一个应用系统可能使用多个数据库。
3. 选择工具：主要使用 SSMS。对于批量检查多个实例，可以考虑使用 PowerShell 脚本（如Invoke-Sqlcmd）或第三方安全评估工具，但需注意工具的稳定性和对生产环境的影响。
4. 制定检查清单：将上述命令分类整理成检查清单（Checklist），并为每项检查预设符合等保要求的“预期结果”或“合规标准”。

4.2 分阶段命令执行与记录

不建议一次性运行所有命令。建议分阶段进行：

• 第一阶段：信息收集：运行命令1、8、9，了解实例概况、版本和基础配置。
• 第二阶段：账户与权限深度检查：运行命令1-6，这是核心，需要仔细核对每个账户和权限分配。
• 第三阶段：安全配置审计：运行命令7、10-12，检查安全功能和审计状态。
• 第四阶段：数据安全与备份验证：运行命令13、14。

关键操作：记录与截图。对每一条命令的执行结果，尤其是发现问题的结果，进行截图保存。同时，将结果整理到 Excel 或专门的测评管理平台中，记录“检查项”、“命令”、“结果”、“是否符合”、“证据位置（截图路径）”、“风险等级”、“整改建议”。

4.3 结果分析与风险定级

不是所有发现的问题风险等级都一样。你需要根据等保要求和业务影响进行分析：

4.4 报告撰写与整改跟进

测评的最终产出是《等保测评报告（数据库部分）》。报告应包含：

1. 测评概述：时间、人员、被测实例信息。
2. 测评方法：简述采用的工具和命令集。
3. 详细发现：以表格形式列出所有检查项、结果、风险等级和证据索引。
4. 综合风险分析：从整体上评估该 SQL Server 实例的安全状况。
5. 整改建议：针对每个中、高风险项，提出具体、可操作的整改步骤、责任人和建议完成时限。

报告提交后，安全工作的重点就转移到整改跟进。你需要与系统所有者和运维团队紧密合作，推动整改措施落地，并在整改完成后进行复测，形成安全闭环。

5. 常见问题、避坑指南与进阶技巧

在实际测评和加固过程中，你会遇到各种预料之外的情况。下面分享一些从实战中总结的经验。

5.1 命令执行中的常见报错与处理

• 权限不足：执行某些命令（如查询系统视图、执行sp_configure）需要较高权限。确保你使用的登录账户拥有VIEW SERVER STATE、VIEW ANY DEFINITION以及ALTER SETTINGS（用于修改配置）等权限。实操心得：可以创建一个专门用于安全审计的 SQL 登录账户，并赋予其必要的权限，而不是直接使用sa。
• 对象名无效：在用户数据库执行sys.server_xxx视图查询时会报错。记住，服务器级视图（sys.server_principals，sys.server_audits）需要在master数据库或任何数据库的上下文中用sys.前缀访问。而数据库级视图（sys.database_principals）必须在目标用户数据库上下文中执行。
• 配置选项不存在：不同版本的 SQL Server 支持的配置选项略有差异。sp_configure显示高级选项后，如果找不到xp_cmdshell，可能是因为该版本已废弃或更名，需查阅对应版本的文档。

5.2 测评过程中的典型“坑”与对策

1. “开发/测试环境随便配，上生产再改”的思维：这是最大的坑。很多不安全的配置（如弱密码、宽权限）在开发测试环境形成习惯，部署生产时被遗忘。对策：将安全配置脚本化、基线化，并纳入 CI/CD 流水线，确保从开发到生产的环境一致性。
2. 只查不改，报告了事：测评发现了风险，但业务部门以“影响稳定性”、“没时间”为由拒绝整改。对策：在项目初期就明确安全责任，将等保合规要求写入运维合同或 SLA。用真实的攻击案例（如因弱密码导致的勒索事件）说明风险，而不仅仅是条款。
3. 忽略“默认”和“隐式”权限：除了显式授予的权限，还要注意public服务器角色和数据库角色的权限，以及架构（SCHEMA）的ALTER、CONTROL权限。进阶检查：使用EXECUTE AS USER = ‘xxx’;模拟用户上下文，再执行SELECT * FROM fn_my_permissions(NULL, ‘SERVER’);和SELECT * FROM fn_my_permissions(NULL, ‘DATABASE’);来查看该用户实际拥有的所有有效权限，这比单独查看授权更全面。
4. 审计日志成为“摆设”：启用了审计，但日志存储在数据库文件所在的磁盘，磁盘满了导致实例卡死；或者日志从未有人查看。对策：将审计日志文件路径指向专用、容量充足的磁盘。定期（如每天）编写自动化脚本分析审计日志，提取异常事件（如非工作时间的大量失败登录、敏感表的异常访问）并发送告警。

5.3 让安全更高效的进阶技巧

• 使用策略管理（Policy-Based Management）：对于需要批量管理多个 SQL Server 实例的场景，可以定义安全策略（如“禁止启用xp_cmdshell”），并定期对所有实例进行评估和强制实施，这比手动检查高效得多。
• 利用漏洞评估（Vulnerability Assessment, VA）：如果你使用的是 Azure SQL Database 或 SQL Server 2012+（需配置），可以启用内置的漏洞评估功能。它能自动执行许多安全检查，并生成带有整改脚本的报告，与等保测评要求高度重合，是极佳的辅助工具。
• 建立安全基线镜像：为不同用途（OLTP、报表）的 SQL Server 构建标准化的安全加固镜像。新实例从基线镜像创建，能确保初始状态就是合规的。
• 关注动态管理视图（DMV）：除了上述命令，像sys.dm_exec_sessions（查看当前会话）、sys.dm_exec_connections（查看连接信息）也能在实时监控和事件调查中发挥重要作用。例如，定期查询sys.dm_exec_sessions可以及时发现异常的长连接或来自异常 IP 的登录。

测评和加固不是一劳永逸的，而是一个持续的过程。将这些命令和检查点集成到你的日常巡检或自动化监控平台中，变被动合规为主动防御，才能真正提升 SQL Server 乃至整个业务系统的安全水位。安全没有终点，每一次认真的检查和加固，都是在为系统的稳定运行增添一块基石。