关于数据库安全，你该怎么办？

ZDNET安全频道 07月12日 综合消息： 一家有着多个分支机构的大型企业，IT信息化建设已是走在同行业的前列。企业的日常费用报销、合同审批等流程均是通过企业自建的工作流系统完成，其后端核心数据库是SQL Server。

两件泄密事件

该公司曾遭遇两次较严重的泄密事件，一次是对一项服务项目进行采购和招标后，确定了意向的公司，并且在工作流中进行了相关审批。按公司规定，此事暂时还处于保密阶段，但是相关信息很快便被泄露出去了,泄露原因却无人知晓。还有一次，公司人员的工资明细莫名其妙的被极个别的人员知道，并在小范围内传播。

虽然公司在暗中进行了调查(包括行政和技术的层面)，却没有明显的证据表明是哪个人的行为，以及通过哪些途径窃取了数据。

痛定思痛，公司下决心部署了数据库安全审计解决方案，之后再没有发生过类似的泄密事件，而且也反推出了之前泄密事件发生的根源——和数据库相关，而且是内部人员对数据库进行查询操作所为。

探寻数据库安全风险

从上述事例中可以看出，作为公司核心数据信息的存储载体，数据库的安全和审计尤为重要，一般企业的数据库管理面临如下的风险或挑战：

1. 管理风险

内部员工的日常操作不够规范;第三方维护人员的操作监控缺失;离职员工可能在系统中留有后门等等。

2. 技术风险

• 数据库是一个庞大而复杂的系统，出于稳定性的考虑，往往对补丁的跟进非常延后，更主要的是企业内部人员可以通过应用层注入攻击等将使数据库处于一种受威胁的状态，而网络层设备很难阻止此类攻击。
• 对一些重要或敏感数据的误操作，会带来较大的风险及损失，如何阻断操作或警告是很大的挑战。

3. 审计风险

•  现有的依赖于数据库日志文件的审计方法，存在诸多弊端，如数据库审计功能的开启会影响数据库本身的性能。同时，数据库日志文件本身存在被篡改的风险，自身的日志审计也难以体现审计信息的有效性和权威性。
• 通过域组策略等的审计方法，亦不能满足对审计的细粒度要求以及对操作者的记录等。
• 有效的行为审计分析和灵活的审计策略缺失等。

再回头来看第一部分的两起泄密事件，或多或少均和管理风险、技术风险、审计风险有关联。如果这家公司在数据库方面的操作流程规范，数据库管理人员的职责明确，操作有监控记录的话，就可以实现对数据库进行操作维护时要审批，且只有具备相应权限的管理人员才能完成，同时也会对操作行为进行监控记录。

如果对一些重要的、敏感的数据进行操作时(如查询工资表、如重要人名)，有报警或是阻断，在很大程度上也可以避免以上事件的发生。另外，如果有对全部或是部分的操作有记录，且利于查询或回放，就可以更好的定位原因及责任人。

魔高一尺道高一丈

那么，关于数据库安全，到底要防范些什么，又该怎么去防呢?

1.管理制度及流程

制定相关的数据库管理流程，不同的人员对数据库的操作职责不一样，所有人员对数据库的操作均需要事前审批，对一些非常重要的操作需要二级以上审批。

申请操作时，需明确在什么人，什么时间，因为何事，对哪个数据库(或表)，进行什么样的操作，可能有什么样的风险及采取的补救措施等。

2. 技术手段和审计手段

一般可以采取业界已存在的且比较成熟的数据库审计解决方案来实现：

• 实时记录用户对数据库系统的所有操作(如：插入、删除、更新、用户自定义操作等)，并还原SQL操作命令包括源IP地址、目的IP地址、访问时间、用户名、数据库操作类型、数据库表名、字段名等，如此，可实现对数据库安全事件准确全程跟踪定位。

• 实时检查数据库不安全配置、数据库潜在弱点、数据库用户弱口令、数据库软件补丁层次、数据库潜藏木马等。
• 进行全方位的多层(应用层、中间层、数据库层)的访问审计，通过多层业务审计，实现数据操作原始访问者的精确定位。
• 针对于数据库的操作行为进行实时检测，并预设置风险控制策略，结合对数据库活动的实时监控信息，进行特征检测，任何尝试性的攻击操作都将被检测到并进行阻断或告警;并支持通过邮件、短信、SYSLOG、SNMP、屏幕等方式告警。

真实生产环境中的数据库安全风险不止这些，同样的针对性解决方案也不少。当然，完全使用自创的解决方案也是一种方法，如数据库系统本身的安全加固。

数据库安全极其重要，不能仅仅满足于事后解决问题，更应当做到以事前预防为主。