Netwrix 1Secure 提供跨数据和身份的统一可见性——免费试用14天,享有完全访问权限。开始免费试用

资源中心博客

如何启用 SQL Server 审计并查看审计日志

如何启用 SQL Server 审计并查看审计日志

Aug 12, 2025

对 Microsoft SQL Server 进行审计对于识别安全问题和入侵至关重要。此外,对 SQL Server 的审计也是满足 PCI DSS 和 HIPAA 等法规要求的必要条件。

第一步是明确要审计的内容。例如,你可以审计用户登录、服务器配置、架构变更以及审计数据的修改。接下来,你需要选择要使用的安全审计功能。以下是一些有用的功能:

  • C2 审计
  • 通用合规准则
  • 登录审计
  • SQL Server 审计ing
  • SQL 跟踪
  • 扩展事件(Extended Events)
  • 更改数据捕获(Change Data Capture)
  • DML、DDL 和登录触发器(DML, DDL, and Logon Triggers)

本文面向正在考虑使用 C2 审计(C2 auditing)、Common Compliance Criteria 和 SQL Server Auditing 的数据库管理员(DBA)。我们不会讨论任何第三方审计工具,尽管它们在更大规模的环境以及受监管行业中可能非常有帮助。

启用 C2 审计并符合通用准则(Enabling C2 Auditing and Common Criteria Compliance)

如果您目前还没有对 SQL Server 进行审计,最简单的起步方式是启用 C2 审计。C2 审计是一种在 SQL Server 中可以启用的、国际上公认的标准。它会审计诸如用户登录、存储过程以及对象的创建和移除等事件。但它是“全有或全无”——您无法选择审计哪些内容,而且可能会生成大量数据。此外,C2 审计处于维护模式,因此很可能会在未来版本的 SQL Server 中被移除。

Common Criteria Compliance 是一项更新的标准,用来取代 C2 审计。它由欧盟制定,并且可以在 SQL Server 2008 R2 及更高版本的 Enterprise 和 Datacenter 版本中启用。但如果您的服务器配置不足以应对额外的开销,可能会导致性能问题。

以下是在 SQL Server 2017 中启用 C2 审计的方法:

1. 打开 SQL Server Management Studio。

2. 连接到您希望启用 C2 审计的数据库引擎。在“连接到服务器(Connect to Server)”对话框中,确保 Server type 设置为 Database Engine,然后单击 Connect

3. 在左侧的 Object Explorer 面板中,右键单击顶部的 SQL Server 实例,然后选择 Properties 菜单中的选项。

4. 在“Server Properties”窗口中,点击 Security(位于 Select a page 下方)。

5. 在“Security”页面中,您可以配置登录监控。默认情况下,只记录失败的登录。或者,您也可以只审计成功的登录,或同时审计失败和成功的登录。

SQL Server Audit Configuring Access Auditing

图 1. 配置访问审计

6. 在 Options 下勾选 Enable C2 audit tracing。

7. 如果要启用 C2 Common Criteria 合规性审计(auditing),请勾选 Enable Common Criteria compliance

Common Criteria(CC)合规性是一项灵活的标准,可通过从 1 到 7 的不同 Evaluation Assurance Level(EAL)来实现。EAL 越高,验证过程要求越严格。当你勾选 Enable Common Criteria compliance 后,即在 SQL Server 中启用了 CC 合规性 EAL1。也可以为 EAL4+ 手动配置 SQL Server。

启用 CC 合规性会改变 SQL Server 的行为。例如,表级 DENY 权限将优先于列级 GRANT,并且成功和失败的登录都会被审计。此外,还启用了 Residual Information Protection(RIP),它会在新资源使用之前,用一组比特模式覆盖内存分配。

8. 点击 OK

9. 根据所选选项,你可能会被提示重新启动 SQL Server。若看到此消息,请在警告对话框中点击 OK 。如果已启用 C2 Common Criteria 合规性,请重启服务器。否则,请再次在对象资源管理器(Object Explorer)中右键单击你的 SQL Server 实例,然后选择 Restart 。在警告对话框中,点击 Yes 以确认你要重新启动 SQL Server。

启用 SQL Server 审计

可以启用 SQL Server 审计来替代 C2 审计;您也可以选择同时启用两者。SQL Server Audit 对象可以配置为在服务器级别或 SQL Server 数据库级别收集事件。

创建服务器审计对象

让我们创建一个服务器级别的 SQL Server 审计对象:

1. 在左侧的对象资源管理器面板中,展开 Security

2. 右键单击 Audits ,然后选择 New Audit… 。这将为服务器级审计创建一个新的 SQL Server Audit 对象。

3. 在“Create Audit(创建审计)”窗口中,在 Audit name

4. 使用 On Audit Log Failure 指定如果 SQL Server 审计失败应执行的操作。您可以选择 Continue ,也可以选择关闭服务器或停止要进行审计的数据 库操作。如果选择 Fail operation ,未被审计的数据 库操作将继续正常工作。

SQL Server Audit Creating a server-level SQL Server audit object

图 2. 创建服务器级 SQL Server 审计对象

5. 在 Audit destination 下拉菜单中,您可以选择将 SQL 审计跟踪写入文件,或在 Windows 安全日志或应用程序事件日志中审计事件。如果选择文件,则必须指定该文件的路径。

请注意,如果要写入 Windows Security 事件日志,则需要为 SQL Server 授予相应权限。为简化操作,请选择 Application 事件日志。此外,你还可以将筛选条件作为审计对象的一部分,以缩小结果范围;筛选条件必须使用 Transact-SQL(T-SQL)编写。

6. 点击 OK

7. 现在,你可以在 Object Explorer 中位于 Audits 下方找到新的审计配置。右键单击新的审计配置,然后从菜单中选择 Enable Audit

8. 在 Enable Audit 对话框中,点击“Close”。

创建数据库审计对象

要创建用于数据库级审计的 SQL Server 审计对象,流程会有些不同,你需要先创建至少一个服务器级审计对象。

1. 在对象资源管理器中展开 Databases,并展开你要配置审计的数据库。

2. 展开 Security 文件夹,右键单击 Database Audit Specifications,然后选择 New Database Audit Specification… (来自菜单)。

SQL Server Audit Creating a server audit specification for database-level auditing

图 3. 为数据库级审计创建服务器级审计规范

3. 在“属性”窗口中“操作(Actions)”下,使用下拉菜单配置一个或多个审计操作类型,选择你要审计的语句(例如 DELETE 或 INSERT)、执行该操作的对象类等。

4. 完成后,单击 OK,然后通过右键单击该审核对象并选择 Enable Database Audit Specification 来启用审核对象。

查看 SQL Server 审核日志

C2 审核 SQL Server 的审核日志存储在 SQL Server 实例的默认数据目录中。每个日志文件的最大容量为 200 MB。到达上限时会自动创建新文件。

建议使用名为 Log File Viewer 的原生解决方案来查看 SQL Server 审核日志。要使用它,请执行以下步骤:

1. 在 SQL Server Management Studio 中,在“对象资源管理器”(Object Explorer)窗格里展开 Security

2. 右键单击要查看的审核(audit)对象,然后选择 View Audit Logs 菜单中的选项。

3. 在 Log File Viewer 中,日志将显示在右侧。无论日志是写入文件还是写入 Windows 事件日志,Log File Viewer 都会显示这些日志。

4. 在 Log File Viewer 的顶部,您可以点击 Filter 以自定义显示哪些日志条目。SQL Server 文件日志以 .sqlaudit 格式保存且不可读,因此 Log File Explorer 允许您点击 Export 将日志保存为逗号分隔的 .log 文件格式。

SQL Server Audit Reviewing SQL Server audit logging in the Log File Viewer

图 4. 在 Log File Viewer 中查看 SQL Server 审核(audit)日志

常见问题解答

如何检查 SQL Server 审计是否已启用?

要验证 SQL Server 审计是否已启用,可以查询 sys.dm_server_audit_status 动态管理视图(dynamic management view),或检查 SQL Server Management Studio(SSMS)中的 Security 文件夹。在 SSMS 中,展开 Security > Audits 以查看所有已配置的审计及其当前状态——已启用的审计会显示绿色图标,而已禁用的审计会显示红色图标。你还可以运行下面的查询来以编程方式检查审计状态:

      SELECT name, is_state_enabled FROM sys.server_audits
      

请记住,要实现完整的审计覆盖范围,必须同时启用服务器审计和数据库审计规范(database audit specification)。Data security 要从身份(identity)开始,就需要全面了解谁在访问哪些数据;在正确配置并验证之后,SQL Server 审计能够提供这一基础。

为什么我的 SQL Server 审计文件会迅速变得很大?

审计文件的过度增长通常发生在你审计了过多事件,或未配置合适的文件管理设置时。最常见的原因包括:启用所有(ALL)审计 action groups、对高访问量表的 SELECT 语句进行审计,或在不进行轮转(rotation)的情况下将文件增长设置为无限。要控制增长,请将审计重点放在合规(compliance)所真正需要的事件上——通常是 LOGIN_CHANGE_PASSWORD_GROUP, DATABASE_PERMISSION_CHANGE_GROUP 以及对敏感表执行特定的 DML 操作。配置最大文件大小限制,并使用 MAXSIZEMAX_ROLLOVER_FILES 选项启用文件轮转(file rollover)。对于高并发/高吞吐环境,可以考虑使用 APPLICATION_LOG 目标,而不是 FILE 目标;或者通过在 WHERE 子句中实现审计过滤,以减少不必要的事件捕获。智能审计意味着在不被数据噪声淹没的情况下,跟踪真正重要的内容。

SQL Server 审计(audit)无法启动时如何排查?

当 SQL Server 审计(audit)无法启动时,问题通常与文件权限、路径可访问性或配置冲突有关。首先,确认 SQL Server 服务帐户对审计文件目录具有写入权限——这是导致启动失败的最常见原因。检查 SQL Server 错误日志中的具体错误信息,通常会对问题提供清晰的指导。确保目标目录存在,并且从 SQL Server 实例可以访问,尤其是在群集环境中,因为共享存储路径必须在所有节点上都有效。若将 Windows Application Log 作为目标,请验证服务帐户具有适当的事件日志写入权限。诸如重复的审计名称或无效的文件路径等配置错误也会阻止启动。关键在于有条不紊的排查:先检查权限,再检查路径,最后检查配置语法。Netwrix 通过提供集中式审计管理,简化了这种复杂性,从而消除这些常见陷阱。

SQL Server 审计(auditing)的性能影响有多大?

SQL Server 审计(auditing)在正确配置的情况下对性能的影响很小,通常会在大多数环境中带来约 2%–5% 的额外开销(overhead)。实际影响取决于三个关键因素:你审计哪些事件、这些事件发生的频率,以及你的存储子系统的性能。在繁忙的 OLTP 系统上审计诸如 SELECT 语句之类的高频操作,会比聚焦与安全相关的事件(例如登录、权限变更,以及对敏感表的 DML 操作)产生更大的开销。异步审计目标(默认)通常比同步选项提供更好的性能,但会带来略微延迟的事件记录。为了尽量减少影响,请使用带 WHERE 子句的审计过滤,避免审计不必要的系统操作,并确保审计文件存储具备足够的 I/O 能力。在高吞吐场景中,Extended Events 通常比 SQL Server Audit 的开销更低,但 SQL Server Audit 提供更出色的合规功能和更易管理的能力。智能的审计设计重视安全价值而非全面记录——你需要的是在不拖累性能的情况下提供保护所需的可见性。

SQL Server 审计(audit) vs SQL Trace:应该使用哪一个?

SQL Server Audit 是新实现的现代选择,而 SQL Trace 已被弃用(deprecated),应避免用于新项目。与传统的 SQL Trace 功能相比,SQL Server Audit 提供更好的安全性、性能和管理能力。与 SQL Trace 不同,SQL Server Audit 事件不能被用户(包括 sysadmins)修改或删除,从而确保满足合规要求时的审计(audit)完整性。审计框架提供异步处理以获得更好的性能,内置过滤功能,并与 Windows Security Event Log 集成。SQL Trace 需要使用存储过程进行手动编码,并已标记为将在未来版本的 SQL Server 中移除。Extended Events 是对 SQL Trace 诊断能力的推荐替代方案,而 SQL Server Audit 负责安全性和合规性监控。如果你目前正在使用 SQL Trace 进行安全审计,请立即迁移到 SQL Server Audit——它提供真正数据安全所要求的、防篡改的审计追踪。Netwrix 解决方案基于这些原生审计能力,为你的整个数据环境提供集中式可视性。

分享到

了解更多

关于作者

Asset Not Found

Russell Smith

IT 顾问

专注于管理与安全技术的 IT 顾问和作者。Russell 拥有超过 15 年的 IT 经验,撰写过一本关于 Windows 安全的书籍,并共同撰写了 Microsoft 官方学术课程(MOAC)系列的相关教材。