在医院数据库系统运行期间，需要对现有的数据库进行审计，确保对现有数据库系统的敏感操作都有记录。为了保证审计系统的正常高效运行，数据库审计系统的日常运维工作是必不可少的。
因为所有的数据操作都是在数据库中进行的，所以要想审计业务操作的具体情况，必须做数据库层面的操作审计。常用的数据库审计系统有两类：
（一）数据库内置的审计功能
这种审计系统利用数据库本身内置的审计功能，能够审计绝大多数数据库操作。但是审计的细粒度很低，而且也很难还原SQL操作本身。比如：对于一个数据删除操作：DELETE FROM EMP WHERE DEPTNO=10；假设表EMP满足条件DEPTNO=10的记录数有100条，那么在数据库审计系统中会有100条DELETE操作，而不是真正的SQL语句：DELETE FROM EMP WHERE DEPTNO=10。并且大多数现有的数据库无法准确审计DDL语句，如：ALTER TABLE XXX ADD （col...），个别数据库产品可以审计DDL语句，但是那都是靠创建数据库级别的触发器实现的。
总之，这类基于数据库产品本身的审计功能的审计系统的审计颗粒度和准确性都有限。而且由于数据库产品本身的审计功能是基于数据库引擎之上的，所以会消耗生产数据库系统本身的资源。如果全部打开所有会话的所有数据库操作审计，其生产数据库系统的CPU资源会有15% ~ 30%的额外消耗。所以，如果是使用这类数据库审计系统，通常只是有目的地针对个别数据或操作进行审计，不会审计整个业务数据库中所有的操作。
（二）外置旁路模式的数据库审计系统
外置旁听模式的数据库审计系统是一个独立于生产数据库的系统，其工作原理是通过网络旁听模式监听并收集所有客户端发送到生产数据库中的网络包，然后在审计系统内部将这些网络包进行解包还原里面的操作命令（即SQL语句）。将SQL语句捕获下来后，存入到数据库审计系统中，然后再根据用户设置条件进行告警或生成报告。相对于基于数据库产品自带的审计功能，外置旁听模式的数据库审计系统有以下几点优势：不占用生产系统的任何系统资源，由于是基于网络旁听的模式，所有的审计操作均是在审计系统上进行的，所以不会占用生产数据库系统的系统资源；能够准确还原SQL语句，因为所有的从客户端发往数据库服务器的SQL语句都是通过TCP/IP网络发出的，如果把这些TCP/IP网络包捕获下来，按照相应的数据库产品网络包格式进行解析，原则上可以得到所有的SQL语句代码。所以，网络旁听模式的数据库审计产品不仅能够审计DML操作，还能够很好地审计数据查询操作以及DDL操作；有良好的用户界面，能够根据用户需求定制告警条件，并且可以通过黑白名单方式减少日常告警数量。
目前，在医院信息系统中，多数使用的是这类网络旁听模式的数据库审计产品。不过，需要注意的是，如果用户直接登录上数据库系统所在的操作系统，或者直接在数据库系统主机的控制台上进行数据库操作的话，是不会产生数据库网络包的，此类网络旁听模式的数据库审计系统是无法审计这些数据库操作的。因此，如果要很好地针对生产数据库做全面的审计，不仅要部署网络旁听模式的审计系统，还要结合堡垒机系统、桌面管理系统等。
虽然内置式的数据库审计系统存在诸多不足，但是对于一些特定场景，比如：仅仅监控数据库超级管理员的操作，或只想审计某个数据库对象（表、序列号等）的使用情况时，还是可以开启数据库产品内置的审计功能的。对于内置式数据库审计系统，要做好审计策略、审计对象、审计操作、审计范围的取舍，确保在不影响系统性能的前提下实现审计目标。在日常运维时需要定期查询审计结果，及时发现敏感操作。
对于内置式数据库审计系统，由于审计结果是存放在数据库主机中的，故需要定时清理审计结果所占用的存储空间。这个过程容易被数据库管理员忽视，无论是把审计记录存放在数据库中，还是存放在文件系统中，审计记录占用的空间往往会比数据库管理员预想的要大。如果把审计记录放在文件系统中，当审计的范围大、颗粒度小，会产生大量的审计记录小文件。这些数以万计的小文件会极大地影响文件系统的性能。如果对这些空间不加以清理，不仅会因为空间爆满而不再记录新的审计记录，而且可能会影响生产系统的文件系统性能。所以必须定期清理存放审计记录的空间。
1. 监控系统运行状态 旁路数据库审计系统是独立于生产数据库之外的系统，如果该审计系统出现故障，不会影响生产数据库的正常运行，但是不会再记录客户端发往生产数据库的SQL指令了。如果在此期间发生了数据库安全事件，将无法查询相应时间段的审计记录。因此，要确保旁路审计系统处于正常工作状态。按以下过程确认审计系统是正常的：
首先，登录审计系统，检查系统的运行情况。然后从自己的客户端发出一条SQL指令给生产数据库。最后检查审计系统是否检查并记录下刚刚发出的测试SQL指令。如果最终能够在审计系统上看到刚刚发出的测试用的SQL指令，说明审计系统是运行正常的。
2. 设定审计告警策略 网络旁听模式的审计系统会记录所有的客户端发往生产数据库系统的SQL代码，并且不会对生产数据库产生任何影响，所以不必设定审计范围。但是需要设定审计告警策略，即：针对哪些数据库对象的哪些操作，审计系统会主动发出告警信息。主动发送告警信息是网络旁听模式数据库审计系统的一个重要功能，这个功能使得数据库管理员能够在安全事件发生后较短时间内被通知。数据库管理员需要在审计系统中设置需要对什么数据库对象/表的何种操作（查询、修改、删除）进行主动告警。
另外，还需要设置主动告警的方式。一般地，审计系统提供邮件和短信告警。如果要设置邮件告警，需要在邮件系统中专门开通一个用以发送告警邮件的信箱，然后设定SMTP的各种设置：SMTP 服务器、端口以及接收方的邮件地址等。短信告警设置比较简单，只需要把接收方的手机号码设好即可。
3. 调整黑白名单 仅仅是设置审计告警策略还是不够的，因为在实际运维过程中，满足告警条件的审计记录是非常多的。对于一个普通的三甲医院，每天对于关键表的查询操作可能有几千条之多。这些告警信息中绝大多数都是业务程序产生的。因此，审计系统都会提供黑白名单机制以进一步缩小告警范围。数据库管理员需要人工鉴别哪些告警信息是属于正常业务程序产生的，然后将其加入到白名单中。由于正常业务程序产生的数据库操作指令虽多，但是基本上都会是重复的SQL指令。经验表明，经过一个业务周期后，就基本上可以把正常业务程序产生的告警信息加入到白名单了。经过这样的白名单设置后，再次出现的告警信息不仅很少了，而且都是值得关注的审计信息。如果数据库安全管理做得完善的话，每天的告警信息应该可以被控制在10~50条之间。对于一个熟悉业务的数据库管理员来讲，每天甄别10~50条SQL语句只需要10多分钟时间。如果确信某条SQL语句是属于绝对违反信息安全管理规定的，可以把这类SQL语句设置到黑名单中。一旦在审计记录中发现符合黑名单条件的，就立即告警。
4. 分析审计结果 如果发现了告警信息，应立即登录审计系统检查详细的告警信息内容。经验表明，根据告警信息里面的客户端IP地址等信息可以很快定位到具体的终端，然后在半小时内可以找到具体的责任人。在分析审计结果的过程中，不仅要使用到审计系统本身，还需要借助终端管理工具定位到具体的物理终端。
