数据库安全审计之一——谁动了你的数据库？

　　2010年8月底的一个下午，G公司信息化部的会议室坐满了人，屋里却鸦雀无声。公司COO意外的现身在这次部门会议上，信息化部的万部长眉头紧锁，技术负责人小李脸色微白，其他人也都是满脸严肃，到底发生了什么事?原来，G公司近期发生了一起事故，大批客户的个人信息被泄露，姓名、联系方式甚至身份证号码全部曝光，一些客户一怒之下投诉了G公司。

　　G公司从事通信业务，因为管理有方，近几年的业务做的风生水起，尤其是凭借出色的服务质量，在业内树立了良好的口碑。出于客户管理和业务安全性的需要，客户办理部分业务时，需要留下身份证号码和联系方式等信息，G公司一直承诺对客户信息的保密性负责，不会发生信息外泄的现象。此次事故的发生，不仅导致大批客户资源的流失，支付巨额赔偿金，就连股票也一路下滑，如果不及时采取应对措施，G公司前途堪忧。

　　会上COO说的最多的一个字就是“查”，由信息化部牵头，一定要配合公安机关，查出罪魁祸首，对社会公布事故原因，挽救企业形象，杜绝此类现象的再次发生。万部长强调，公安机关主要从企业外部开始查起，信息化部要利用好已有的安全防范工具，尤其是已经部署的信息安全产品，从内部开始严查。小李提出一个思路：既然是客户信息泄露，必然跟客户业务信息系统有关。首先，要排查业务系统是否受到了黑客攻击，这是信息泄露最常见的渠道，然后，排查可能接触到业务信息系统的员工。这个思路被大家认可，排查工作开始了。

　　G公司深知业务信息的重要性，早在两年前就开始了信息安全的建设，公司在各个网络分支机构都部署了防火墙，在关键业务区域还部署了IDS、IPS等设备，本次排查，大家都希望这些设备能派上用场。两天过去了，小李带领技术攻关小组，逐项检查业务部门网络所部署的防火墙、IDS、IPS日志，想从这些信息安全设备上找到一些黑客入侵的蛛丝马迹，然而，结果让他失望。防火墙的策略非常严格，日志没看到有异常的访问流量;部署在业务网接入边界的IPS，日志显示近三个月有两起入侵事件，但是入侵行为被及时阻断，威胁尚未产生就已经被制止;监控业务网核心交换流量的IDS，日志中看到的攻击行为都是蠕虫类攻击，只能引起业务系统资源耗尽或者目标业务主机不响应，不会导致客户信息泄露。

　　如果没有受到来自外部的黑客攻击，那么，问题应该出在内部了，所有能接触到业务网尤其是数据库的员工立刻都变成了嫌疑人，公司内部的气氛陡然变得紧张起来。最先被怀疑的是两个数据库管理员(DBA)老滕和老宋，只有他们能最直接的接触到数据库的核心数据。不过，DBA对数据库的任何操作都必须经过严格的身份认证和监控机制，且经过检查数据库和操作系统日志，没看到DBA有什么违规操作。嫌疑暂时解除，老滕和老宋松了一口气，加入到排查问题的队伍中来。他们提出建议，G公司除了DBA，没有人能直接接触数据库服务器了，需要检查一下通过网络访问数据库的业务系统是否有异常。G公司能批量查询客户信息的主要业务系统是客户关系管理系统，系统为BS架构。操作员在PC上通过浏览器进行身份认证并登录客户关系管理系统(WEB服务)，系统的WEB服务器连接后台数据库服务器，WEB服务器到数据库的访问均采用同一数据库账号，此系统有管理员2人、运维人员2人、操作员若干。

　　又是三天的排查时间，客户关系管理系统相关的管理人员和操作人员没有被查出任何违规行为。不过在排查中发现了一个线索，在数据库日志中发现，WEB服务器在7月份发生过多次向数据库查询批量客户信息的操作，一部分查询集中在月初，那个时候公司会开展常规的客户关系维护活动，要查询客户信息比较正常。另一部分查询操作均在7月12日左右，正常来说，公司月中不会办理对批量客户的业务或者活动，这些查询显得有些莫名其妙，操作员均否认这个时间段查询过客户信息。公安机关的同志分析，问题应该就出在这里，这个时间距离客户信息被泄露的时间也比较近。经过层层排查，罪魁祸首终于被找到。那么，到底是谁偷盗了用户信息，内鬼还是外贼?答案即将揭晓。