上次说到，G公司发生了客户信息外泄的情况，公司信息化部经过排查，从数据库日志中发现了重要线索——7月中旬的批量客户信息查询是个异常信号，但是内部员工谁也不承认7月中旬进行了这个查询。经过公安机关层层排查，事故经过渐渐浮出水面。原来，在2010年6月份，客户关系管理系统曾经上线过一个业务模块，由第三方公司开发，在模块测试和试运行期间，第三方的开发人员小孙协助G公司运维负责人小董进行系统的运维，小董为了处理问题方便，将自己的权限短暂授予了小孙。一次小孙与朋友聊天，对方无意中提及出售客户信息可获得可观收入，小孙联想到自己正在G公司工作，可以利用业务之便获取一些信息。于是，他偷偷在客户关系管理系统中为自己创建了一个操作员账号，利用此账号登录客户关系管理系统，查询了大批的客户信息，然后将此账号删除。自以为神不知鬼不觉的他，将盗取的客户信息分别卖给了几个买家，获取了一笔不小的收入。没想到的是，等待他的将是牢狱之灾。
到此，事情水落石出，G公司上上下下松了一口气，但是另一个问题被提出来：虽然查出盗密者，但是事故已经发生，损失也已经造成，如何防止同类事故再次发生？小孙的一连串操作都不具备攻击特性，不会对业务系统造成损坏，因此一般的信息安全设备都不会报警，但因为身份不对，属于越权操作，从而导致了严重的后果。这种正常访问行为背后的违规本质，如何才能彻底杜绝？
COO指出，首先，要强化公司内部管理，提高员工的保密意识，严格权限划分制度，不能随意授权给外来人员，此事由保密办负责。另外，也要提升业务信息系统的安全性，及时预防违规行为给公司带来损失，这个工作自然落到了信息化部的头上。万部长给出两项整改措施。第一，对目前的业务系统进行全面测试，增强业务系统健壮性和保密性，防止因为攻击导致业务系统崩溃或者信息泄露。第二，采购审计产品，加强对业务网内部的操作行为审计，违规行为一旦发生，能及时进行告警，并迅速定位事故责任人。
技术员小李负责调研一款适合G公司的审计产品，根据G公司现状，小李分析出对审计产品的3个要求：
首先，数据库中存储着公司核心资产，审计产品要在数据库审计能力上表现突出，要能够审计到对数据库的各种关键操作，并进行及时报警。
其次，审计产品不能不加筛选的将所有的网络互访行为都记录下来，这样的记录对于审计人员来说参考意义不大，要能根据公司业务现状定义重点监控的行为，并且在事后检索的时候，能迅速的从海量审计日志中检索到有价值的信息。
最后，审计产品要能做到对同一个自然人对于业务资源的不同访问阶段的关联。G公司内部的各个业务系统，与客户关系管理系统一样，多为B/S架构，一般情况下，虽然操作员在浏览器上的登录账号各不相同，但是业务服务器对数据库的访问均使用同一账号。如果仅记录业务服务器访问数据库的操作，或者仅记录浏览器对业务服务器的访问，在有多个操作员并发访问业务系统时，就无法明确数据库发生事故的责任人，只有将前后台的访问行为关联起来，才能准确定位是哪个操作员的访问导致了数据库事故。另外，对于通过其他协议跳转访问数据库，或者数据库的嵌套访问等行为，也需要通过审计产品进行准确定位。
说起来简单，可要想同时满足上面三个要求，谈何容易，仅最后一点——前后台实时关联审计，市面上就没有几款审计产品能做到，于是，技术员小李又开始了漫长的产品调研之路……