保护敏感数据对付恶意内部人员的六大妙招

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

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

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

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

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

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

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

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

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

　　在很多情况下，并没有启用本地数据库审计。

　　本地审计的启用靠手工完成，容易出现错误;数据库管理员可能启用了并不充分的审计。

　　本地审计会对被审计的服务器带来高昂的费用。启用本地审计有可能耗尽数据库主机资源，影响系统的效率。

　　不同的数据库提供了不同的审计功能。在异构环境中对每个数据库版本和类型启用审计会耗费大量的资源，因为其输出是不同的，有可能不完整，而且对于并不精通每种数据库的人员来说，这种输出结果也难以解析。

　　许多数据库并不能捕获被变造的SQL查询。

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

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

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

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

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

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

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

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

　　四、对数据库的使用进行分析

　　许多人员认为恶意内部用户的焦点问题是，用户在哪里与敏感数据交互。传统的网络安全控制，如防火墙(使用签名匹配方法)，专注于检测和阻止特定的事件，在应对人员和数据时就显得太简单了。如果一家企业能够决定正常的活动是怎样的，就可以根据用户活动的源头(源用户、源应用程序、源位置)、目的(目标数据库和数据库对象)、用户活动的环境(时间、经常性的用法、成功及失败的活动等)来对使用情况进行分类。可以检测缺乏签名的数据使用的异常情况。一个证明分析的价值的例子是业务逻辑攻击。业务逻辑攻击可以使web应用程序的功能用来对付业务，它破坏的是业务逻辑而不是应用程序。

　　分析应用程序和数据库的交互也很重要。这样做可以更好地防御SQL注入攻击，并确认由于应用程序的设计缺陷而造成的异常数据库活动。以这种方式分析应用程序还可以揭示：在一个不合适的环境中使用后将会显得不正常的各种合法应用：

　　1)在单个设备与多个设备通信时，有可能被看成是恶意软件的传播和漫延，而实际上有可能是一台备份服务器或一台代理服务器。

　　2)在非运营时间进行的大量数据传输有可能被认为是信息窃取，而实际上有可能是合法的数据库备份。

　　3)还可以发现潜在的恶意模式，例如：

　　过度的文件下载

　　在可疑的时间发现了用户活动

　　非授权用户企图访问保密数据，例如，开发人员试图访问人力资源部门的系统

　　可疑的无效活动(如大量的非法登录企图)

　　分析并不像一次性的扫描。因为应用程序和数据库属于连续变化的动态环境，因而对应用程序及数据库的使用情况进行不断分析和更新是很重要的，这应当成为一个成熟的数据安全策略的不可缺少的一部分。

　　五、协调Web应用程序和数据库之间的活动

　　监视用户的全部任务就是跟踪用户并让其为自己的活动负责。确认网络活动的责任人可能很困难。在使用连接池的多数现代应用程序中，并没有在本地记录Web应用程序和数据库之间的用户会话。连接池通过再次使用已打开的数据库连接而不是为每个用户打开数据库连接，从而改善了应用程序的性能。虽然应用程序的性能得到了提高，但连接池也掩盖了每个请求活动的用户身份，这意味着确实没有方法可以将数据库活动与特定用户关联起来。

　　企业可以重新编写客户应用程序和数据库代码来支持此功能。不过，这是一个昂贵的建议，需要为企业中应用程序和数据库的每个版本都这样做，而且增加的代码可能会带来漏洞。

　　Web应用程序和数据库活动的关系协调必须在这两者之外实现，而且要独立于厂商、版本等。以这种方式跟踪用户会话可以更好地控制会话记录，而不会额外地耗用Web和数据库应用程序的资源，也不会使宝贵的开发资源偏离其它项目。可以在Web应用程序、数据库之间有效地协调用户会话，不但可以捕获查询，还可以捕获作为结果而返回的数据。

　　六、以人类的直觉来强化基于机器的分析

　　预防性的安全控制的可升级性总是有限的，如果没有人的分析，纯粹从技术中获得的价值总是有限的。实时的警告一般源自纯技术分析得到的结论。报告可以从两方面来强化这个过程。首先，报告可以更长远地检测趋势，如几个月都在滥用资源的方式。其次，报告利用人类的直觉来强化基于机器的分析。

　　对内部人员而言，拥有一套使人能够根据结果做出结论的简易而有效的方法是至关重要的。这是因为人可以考虑更多的因素，而不仅仅通过应用程序和数据库的分析所捕获的数据。例如，某用户表现不佳，并且有传言说他要离开公司到某竞争对手那里去。因为IT安全团队不可能拥有公司每个人的“全面情况”，因而，这份报告能使公司的各种人员都能使用是很重要的，如非技术经理、人力资源部门、法律部门等。这种由现实分析与应用程序和数据库的详细证据的组合，可以生成比单纯一个方面更多的精确结果。