有意或无意的内部人员威胁一直都大量存在。在经济困难时期，其恶尤甚。由于数字信息的激增，将信用卡数据、个人身份信息和知识产权变成现金、财产的手段，以及由此造成的风险都与日俱增。我们不再对受到信任的内部人员窃取敏感数据的行为感到惊奇。企业日益发现，最大的威胁来自内部。

　　如今，许多企业同意最有价值的IT资产存在于应用程序和数据库中。多数企业还承认应用程序和数据库的安全水平最低，这就使其成为系统管理员、数据库管理员、顾问、合伙人、客户的恶意活动的首要目标。

　　本文将探讨保护敏感数据免受访问数据的人员的损害的多种方法。虽然内部威胁难以应对，但只要利用适当的工具，也并非不可能。

　　一、知道敏感数据存在于哪些数据库

　　看一下最近的安全类文章，你会发现解决特定安全问题的居多。原因在于全面安全，即平等地保护一切的观念过于昂贵，并且不易衡量。虽然这个观念很容易理解，但确认关键的资产却绝非易事。对于数据库及其包含的敏感数据而言，尤其如此。此类数据可能是信用卡号、个人身份信息、雇员、医疗记录、研究报告、业务计划、绝密文件等。实际上，每家企业都有需要保护的敏感信息，但往往并不知道信息在哪里。

　　首先需要确认数据库自身。但此任务未必如像乍看起来那么简单。面向服务架构（SOA）可能很庞大且复杂。例如，企业可能对包含敏感数据的数据库进行了某种测试，此外，还有可能存在一些未经验证的数据库。

　　一旦确认了数据库，对敏感数据进行分类并确认其包含的对象就显得至关重要了。必须对分类进行验证，其目的是为了减少一些“似是而非”的情况。验证过程应当是自动化的，并支持多次执行，而且还要随着时间的推移而支持可扩展性，并保证准确性。

　　二、勿轻信本机的数据库工具

　　如果是拥有特权的内部人员作案，如数据库管理员和系统管理员，再相信受到其攻击的系统的安全信息将毫无意义。如果恶意的内部人员可以访问数据库并可能操纵本地的审计日志，这些日志就毫无用处。这就像让犯罪份子成为现场调查员一样。因而必须实施责任分离：安全和操作必须分离。不能相信那些存在于受攻击的数据库系统中的审计信息或由这种数据库创建的审计信息。此外，本地的数据库审计日志还会带来一些技术问题。例如：

• 在很多情况下，并没有启用本地数据库审计。
• 本地审计的启用靠手工完成，容易出现错误；数据库管理员可能启用了并不充分的审计。
• 本地审计会对被审计的服务器带来高昂的费用。启用本地审计有可能耗尽数据库主机资源，影响系统的效率。
• 不同的数据库提供了不同的审计功能。在异构环境中对每个数据库版本和类型启用审计会耗费大量的资源，因为其输出是不同的，有可能不完整，而且对于并不精通每种数据库的人员来说，这种输出结果也难以解析。
• 许多数据库并不能捕获被变造的SQL查询。

　　在捕获数据库的审计日志时，应当独立于数据库工具：强化责任分离、增强数据库的性能、确立用户责任等。

　　三、监视善意的、恶意的和有特权的用户

　　需要访问敏感数据的用户也是能够给这种数据带来威胁的用户。设计DMZ、业务流程外包以及SOA等，目的都是为了改善访问，提高运营效率，促进信息共享等。但事物总有其两面性。

　　监视善意人员：怀有恶意的人有可能伪装成善人。监视内部和外部的好人，特别是那些接触“敏感数据”的人。

　　监视恶意人员：这是因为来自不可信的外部人员的多种风险仍然存在，所以你无法在没有传统网络安全控制的情况下就进行操作。但利用这些机制来保护敏感数据并非根本解决之道。网络安全的根本设计目的并不是为了解决数据安全。

　　监视特权人员：这是因为这些人掌握着关系到企业存亡的大权。在许多情况下，他们不但负责运营，在很多情况下，还负责安全。颇具讽刺意味的是，特权人员还被要求保障系统的安全。

　　不管对可信用户、不可信用户还是特权用户，对敏感数据的保护需要时时刻刻地进行。要假设每个人都可以访问数据，假设每个人都想窃取数据。

　　由于Web服务器是外部攻击者用以窃取数据的典型攻击媒介，传统的网络安全控制对于减轻数据攻击的效率是很低的，需要实施应用程序防火墙来检测和防止基于Web的攻击，如SQL注入攻击、跨站脚本攻击、cookie投毒、会话劫持等。确保“数据安全”控制能够监视所有的特权用户活动，以及应用程序的用户通信。所实施的控制必须包括事件阻止、警告、报告、审计等。最后，确保这些安全控制独立于操作人员，从而能够高效地监视特权用户对数据的使用。