sqlserver browser无法启动_等保测评2.0：SQLServer安全审计

一、说明

本篇文章主要说一说SQLServer数据库安全审计控制点的相关内容和理解。

二、测评项

a)应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计；

b)审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息；

c)应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等；

d)应对审计进程进行保护，防止未经授权的中断。

三、测评项a

a)应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计；

SQLServer默认开启着错误日志，在服务器-管理-SQL Server日志中：

错误日志大概记录的内容：

2.1 日志自动记录的信息大概有如下：

(1) SQL SERVER 的启动参数，以及认证模式，内存分配模式。

(2) 每个数据库是否能够被正常打开。如果不能，原因是什么?

(3) 数据库损坏相关的错误

(4) 数据库备份与恢复动作记录

(5) DBCC CHECKDB记录

(6) 内存相关的错误和警告

(7) SQL调度出现异常时的警告。一般SERVER Hang 服务器死机会伴随着有这些警告

(8) SQL I/O操作遇到长时间延迟的警告

(9) SQL在运行过程中遇到的其他级别比较高的错误

(10) SQL内部的访问越界错误(Access Violation)

(11) SQL服务关闭时间

(12) SQL SERVER版本，以及windows和processor基本信息。　　

2.2 日志开启跟踪能看到的信息

(1) 所有用户成功或失败的登入

(2) 死锁及其参与者的信息。跟踪标志1222 或1204　　

2.3 日志不能记录的问题

(1) 阻塞问题。只要阻塞还没有严重到影响线程调度，日志里是不会体现的。

(2) 普通性能问题,超时问题。

(3) windows层面异常。

错误日志可以配置的内容有：

从上面可以得知，SQLServer默认虽然开启着错误日志，对一部分事件进行了记录。

但是错误日志记录的事件的范围不够大，并没有达到对重要的用户行为和重要安全事件进行审计这个要求，比如记录更改关键数据的语句等，所以只能算是部分符合。

如果想要达到符合，需要自创审核规范和审核对象，SQLServer是具备这个功能的，在服务器的安全性和数据库的安全性中可以查看：

至于具体如何实现其中的规则，这里我就不详细写了，网上写得很清楚：SQLSERVER2008新增的审核/审计功能

(之所不写是因为大部分情况下被测评方要么就没有采取任何措施，要么就使用数据库审计系统来实现了，通过数据库本身的功能来实现的概率很小)

哦，对了，这是SQLServer2008和之后版本才具备的功能，在之前的版本中，实现相关功能的方法有：

四、测评项b

b)审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息；

这里是指至少应该包括最关键的数据，也就是日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息，默认情况下SQLServer仅存在错误日志，测评项a无法满足，测评项b肯定就不应该判定为符合，而且错误日志本身确实也未存在足够多的字段，仅存在日期、源、消息、日志类型、日志源这些字段。

这里想要符合，也只能是自创审核规范和审核对象。

另外，这里应该也要判断下日志中的日期和时间是否准确，SqlServer日志中的时间应该是引用的本机时间，所以就要看一看数据库所在的操作系统是否做了这方面的措施，具体哪些措施可以看：等保测评2.0：Windows安全审计中的测评项b。

五、测评项c

c)应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等；

5.1. 要求1

也即仅某些账户可删除、修改审计记录。

在默认状况下，SQLServer仅存在错误日志，对于错误日志，默认状态下会存在7个，分别是：

ERRORLOG

ERRORLOG.1

ERRORLOG.2

ERRORLOG.3

ERRORLOG.4

ERRORLOG.5

ERRORLOG.6

可以用以下命令进行错误日志的的清除：

exec sp_cycle_errorlog

执行一次sp_cycle_errorlog就会产生一个新的 errorlog，然后原来errorlog重命名为errorlog1，原来的errorlog1重命名为errorlog2，最后的errorlog6删除。
而执行sp_cycle_errorlog该命令的权限，仅服务器角色sysadmin才具有。

如果从操作系统的层面来说的话，也就是错误日志的文件的权限：

默认情况下，也就这些操作系统账户存在权限。

而如果是对于自建的审核规范和审核对象，大概率不会碰到，这里就不怎么说了。

反正涉及到权限，如果纪录存在表中，那么就要去看表的权限、表所在架构的权限、架构所在数据库的权限的权限等。

如果记录存在文件中，那么就要去看文件的权限。

5.2. 要求2

对日志进行定期备份，这里要明确一点，要看对方将数据库的记录文件存放在了什么地方。

如果是默认的错误日志，是存放在文件中的，其存储路径为：C:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\LOG。

对于将记录存放在文件中的，备份就是要备份这个文件。

如果将记录存在在数据库表中的，那么就要对这个表或者这个表所在的数据库进行备份。

六、测评项c

d)应对审计进程进行保护，防止未经授权的中断。

如果针对错误日志，似乎也没办法禁止错误日志的记录，所以也没什么好说的。

七、数据库审计系统

大部分情况下，被测评方都是使用数据库审计系统来实现相关的要求。

数据库审计系统应该都是基于流量解析来进行审计，所以数据库本身的审计设置就无所谓了(不用关注了)，因为数据库审计系统本身就是由于数据库自身的审计功能不够强大而出现的产品。

7.1. 测评项a

a)应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计；

数据库审计系统的功能一般足够强大和专业，对于测评项a而言，虽然数据库审计系统在可以自创规则，但是大部分情况下，也会存在一个默认模板，这个默认模板包含的规则基本上至少能满足测评项a的要求了，除非特殊要求，基本不需要用户自己创建规则。

当然，测评的时候也还是要看一看到底使用了什么规则：

7.2. 测评项b

b)审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息；

同测评项a，肯定也至少满足了测评项b的要求，而且一般都会远远超过(包含足够多的字段)

测评时看一看具体的记录即可：

7.3. 测评项c

c)应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等；

这里应该看数据库审计系统中是否对账户的权限进行了分离，即仅某一个或某一类账户可以对审计记录进行操作。

至于备份，要看数据库审计系统中是否设置了相关的备份策略：

7.4. 测评项d

这里其实也是看数据库审计系统中是否对账户的权限进行了分离，仅某一个或某一类账户可以对审计策略进行操作。

*本文原创作者：起于凡而非于凡，本文属于FreeBuf原创奖励计划，未经许可禁止转载

精彩推荐