保护敏感数据对付恶意内部人员的九大妙招（一）

有意或无意的内部人员威胁一直都大量存在。在经济困难时期，其恶尤甚。由于数字信息的激增，将信用卡数据、个人身份信息和知识产权变成现金、财产的手段，以及由此造成的风险都与日俱增。我们不再对受到信任的内部人员窃取敏感数据的行为感到惊奇。企业日益发现，最大的威胁来自内部。
　　如今，许多企业同意最有价值的IT资产存在于应用程序和数据库中。多数企业还承认应用程序和数据库的安全水平最低，这就使其成为系统管理员、数据库管理员、顾问、合伙人、客户的恶意活动的首要目标。
　　本文将探讨保护敏感数据免受访问数据的人员的损害的多种方法。虽然内部威胁难以应对，但只要利用适当的工具，也并非不可能。
　　一、知道敏感数据存在于哪些数据库
　　看一下最近的安全类文章，你会发现解决特定安全问题的居多。原因在于全面安全，即平等地保护一切的观念过于昂贵，并且不易衡量。虽然这个观念很容易理解，但确认关键的资产却绝非易事。对于数据库及其包含的敏感数据而言，尤其如此。此类数据可能是信用卡号、个人身份信息、雇员、医疗记录、研究报告、业务计划、绝密文件等。实际上，每家企业都有需要保护的敏感信息，但往往并不知道信息在哪里。
　　首先需要确认数据库自身。但此任务未必如像乍看起来那么简单。面向服务架构（SOA）可能很庞大且复杂。例如，企业可能对包含敏感数据的数据库进行了某种测试，此外，还有可能存在一些未经验证的数据库。
　　一旦确认了数据库，对敏感数据进行分类并确认其包含的对象就显得至关重要了。必须对分类进行验证，其目的是为了减少一些“似是而非”的情况。验证过程应当是自动化的，并支持多次执行，而且还要随着时间的推移而支持可扩展性，并保证准确性。
　　二、勿轻信本机的数据库工具
　　如果是拥有特权的内部人员作案，如数据库管理员和系统管理员，再相信受到其攻击的系统的安全信息将毫无意义。如果恶意的内部人员可以访问数据库并可能操纵本地的审计日志，这些日志就毫无用处。这就像让犯罪份子成为现场调查员一样。因而必须实施责任分离：安全和操作必须分离。不能相信那些存在于受攻击的数据库系统中的审计信息或由这种数据库创建的审计信息。此外，本地的数据库审计日志还会带来一些技术问题。例如：
在很多情况下，并没有启用本地数据库审计。
本地审计的启用靠手工完成，容易出现错误；数据库管理员可能启用了并不充分的审计。
本地审计会对被审计的服务器带来高昂的费用。启用本地审计有可能耗尽数据库主机资源，影响系统的效率。
不同的数据库提供了不同的审计功能。在异构环境中对每个数据库版本和类型启用审计会耗费大量的资源，因为其输出是不同的，有可能不完整，而且对于并不精通每种数据库的人员来说，这种输出结果也难以解析。
许多数据库并不能捕获被变造的SQL查询。
　　在捕获数据库的审计日志时，应当独立于数据库工具：强化责任分离、增强数据库的性能、确立用户责任等。
　　三、监视善意的、恶意的和有特权的用户
　　需要访问敏感数据的用户也是能够给这种数据带来威胁的用户。设计DMZ、业务流程外包以及SOA等，目的都是为了改善访问，提高运营效率，促进信息共享等。但事物总有其两面性。
　　监视善意人员：怀有恶意的人有可能伪装成善人。监视内部和外部的好人，特别是那些接触“敏感数据”的人。
　　监视恶意人员：这是因为来自不可信的外部人员的多种风险仍然存在，所以你无法在没有传统网络安全控制的情况下就进行操作。但利用这些机制来保护敏感数据并非根本解决之道。网络安全的根本设计目的并不是为了解决数据安全。
　　监视特权人员：这是因为这些人掌握着关系到企业存亡的大权。在许多情况下，他们不但负责运营，在很多情况下，还负责安全。颇具讽刺意味的是，特权人员还被要求保障系统的安全。
　　不管对可信用户、不可信用户还是特权用户，对敏感数据的保护需要时时刻刻地进行。要假设每个人都可以访问数据，假设每个人都想窃取数据。
　　由于Web服务器是外部攻击者用以窃取数据的典型攻击媒介，传统的网络安全控制对于减轻数据攻击的效率是很低的，需要实施应用程序防火墙来检测和防止基于Web的攻击，如SQL注入攻击、跨站脚本攻击、cookie投毒、会话劫持等。确保“数据安全”控制能够监视所有的特权用户活动，以及应用程序的用户通信。所实施的控制必须包括事件阻止、警告、报告、审计等。最后，确保这些安全控制独立于操作人员，从而能够高效地监视特权用户对数据的使用。
 
四、对数据库的使用进行分析
　　许多人员认为恶意内部用户的焦点问题是，用户在哪里与敏感数据交互。传统的网络安全控制，如防火墙（使用签名匹配方法），专注于检测和阻止特定的事件，在应对人员和数据时就显得太简单了。如果一家企业能够决定正常的活动是怎样的，就可以根据用户活动的源头（源用户、源应用程序、源位置）、目的（目标数据库和数据库对象）、用户活动的环境（时间、经常性的用法、成功及失败的活动等）来对使用情况进行分类。可以检测缺乏签名的数据使用的异常情况。一个证明分析的价值的例子是业务逻辑攻击。业务逻辑攻击可以使web应用程序的功能用来对付业务，它破坏的是业务逻辑而不是应用程序。
　　分析应用程序和数据库的交互也很重要。这样做可以更好地防御SQL注入攻击，并确认由于应用程序的设计缺陷而造成的异常数据库活动。以这种方式分析应用程序还可以揭示：在一个不合适的环境中使用后将会显得不正常的各种合法应用：
　　1) 在单个设备与多个设备通信时，有可能被看成是恶意软件的传播和漫延，而实际上有可能是一台备份服务器或一台代理服务器。
　　2) 在非运营时间进行的大量数据传输有可能被认为是信息窃取，而实际上有可能是合法的数据库备份。
　　3) 还可以发现潜在的恶意模式，例如：
过度的文件下载
在可疑的时间发现了用户活动
非授权用户企图访问保密数据，例如，开发人员试图访问人力资源部门的系统
可疑的无效活动（如大量的非法登录企图）
　　分析并不像一次性的扫描。因为应用程序和数据库属于连续变化的动态环境，因而对应用程序及数据库的使用情况进行不断分析和更新是很重要的，这应当成为一个成熟的数据安全策略的不可缺少的一部分。
　　五、协调Web应用程序和数据库之间的活动
　　监视用户的全部任务就是跟踪用户并让其为自己的活动负责。确认网络活动的责任人可能很困难。在使用连接池的多数现代应用程序中，并没有在本地记录Web应用程序和数据库之间的用户会话。连接池通过再次使用已打开的数据库连接而不是为每个用户打开数据库连接，从而改善了应用程序的性能。虽然应用程序的性能得到了提高，但连接池也掩盖了每个请求活动的用户身份，这意味着确实没有方法可以将数据库活动与特定用户关联起来。
　　企业可以重新编写客户应用程序和数据库代码来支持此功能。不过，这是一个昂贵的建议，需要为企业中应用程序和数据库的每个版本都这样做，而且增加的代码可能会带来漏洞。
　　Web应用程序和数据库活动的关系协调必须在这两者之外实现，而且要独立于厂商、版本等。以这种方式跟踪用户会话可以更好地控制会话记录，而不会额外地耗用Web和数据库应用程序的资源，也不会使宝贵的开发资源偏离其它项目。可以在Web应用程序、数据库之间有效地协调用户会话，不但可以捕获查询，还可以捕获作为结果而返回的数据。
　　六、以人类的直觉来强化基于机器的分析
　　预防性的安全控制的可升级性总是有限的，如果没有人的分析，纯粹从技术中获得的价值总是有限的。实时的警告一般源自纯技术分析得到的结论。报告可以从两方面来强化这个过程。首先，报告可以更长远地检测趋势，如几个月都在滥用资源的方式。其次，报告利用人类的直觉来强化基于机器的分析。
　　对内部人员而言，拥有一套使人能够根据结果做出结论的简易而有效的方法是至关重要的。这是因为人可以考虑更多的因素，而不仅仅通过应用程序和数据库的分析所捕获的数据。例如，某用户表现不佳，并且有传言说他要离开公司到某竞争对手那里去。因为IT安全团队不可能拥有公司每个人的“全面情况”，因而，这份报告能使公司的各种人员都能使用是很重要的，如非技术经理、人力资源部门、法律部门等。这种由现实分析与应用程序和数据库的详细证据的组合，可以生成比单纯一个方面更多的精确结果　七、通过日志分析对犯罪情况进行取证调查
　　警告、报告、个别事件分析在发现恶意内部人员时都扮演着重要的角色。但高效的内部人员调查要求更多的灵活性。详细检查可能缺乏有力审计线索的多个异构数据库，借以调查内部人员是不足取的。企业利用Perl、grep、SED、awk等工具来搜索审计数据，查找特定的已知恶意条目也是不可取的。这种方法是不可升级的，而且对于查找未知的威胁也没有什么用处。
　　在涉及审计日志时，一张图片比一万个日志可能更有说服力。与审计数据的可视化交互会形成一种因果关系，如果不使用可视化工具，就很难注意到这种关系。例如，分析人员可以根据用户、登录、被监视的资产（如服务器等）来搜索信息。通过使用这些搜索，分析人员就可以访问底层的事件细节。这种信息有可能会促使分析人员查找新的以前没有注意的趋势。在多数内部人员调查中，一旦确认了恶意活动的迹象，就可以问三个问题：内部人员还做了什么？这种状况持续了多长时间？谁还牵涉到类似的活动中了？
　　在调查中，必须考虑下面的事件顺序：
检测到SQL错误——但并非所有的SQL错误都是在生产环境中发现的。
分析人员可以轻易地利用可视化工具，过滤并且不选择非生产环境中的资源。
下一步，从与SQL错误相关的用户方面进一步调整其分析，进一步更新数据。
某特定用户的错误比其它用户更多。
确认该用户为一位开发人员，而且他所访问的系统属于生产环境中的。
进一步挖掘此数据，发现该用户试图访问的信息位于信用卡和工资表中。
其它细节还有可能显示出该用户访问这些数据的成功和失败的企图。
趋势报告可显示出，此事件发生了多长时间，还有谁牵涉到类似的活动中了。
　　八、保护数据库中的敏感数据
　　数据库安全是保护敏感数据免受内部人员危害的最关键的领域之一，因为数据库中存储着恶意内部人员需要的信息。这些数据库一般十分复杂且动态变化，难以锁定。更糟的是，数据库管理员一般重视正常的运行时间和可用性，而安全则是以后才会想到的事情。以往，这造成了IT安全和数据库管理员之间的分离。有两种解决方案可以很好地适应数据库管理员和IT安全的需要，即数据库防火墙和数据库活动监视解决方案。
　　数据库防火墙：正如传统的网络防火墙解决以网络为中心的攻击一样，数据库防火墙可以阻止以攻击形式或数据窃取形式直接针对数据库的恶意活动。数据库防火墙可以提供的一些关键功能有：
阻止数据库攻击和欺诈活动
提供敏感数据的实时、自动化的保护
洞察用户访问数据的方式
利用灵活的视图和审计分析进一步调查被审计的事件
通过有效的补丁来透明地保护数据库
　　借助于数据库防火墙，虚拟补丁可用于解决通过漏洞评估解决方案发现的漏洞，而不必重写代码、应用补丁、经历冗长而昂贵的漏洞修补过程。数据库防火墙可以阻止这种企图：利用已经打上了虚拟补丁的漏洞进行攻击，或对此攻击发出警告，从而使企业更安全地运营，直至其有时间和资源直接解决漏洞。
　　数据活动监视：数据库防火墙在数据库层提供了类似于传统网络防火墙的功能，而数据库活动监视能够捕获独立于数据库和数据库管理的用户和数据库之间的双向通信，从而提供了强健的审计。数据库活动监视有助于解决五个关键的数据库审计问题：
　　1、审计过程独立于被审计的数据库系统吗？不要依赖于数据库的审计信息。
　　2、审计线索能够确立用户责任吗？特定的事件需要与特定的用户责任相关联。
　　3、审计线索包括适当的细节吗？审计系统必须收集足够有用的细节。如果有问题的审计系统是数据库的本地方案，答案一般是否定的。
　　4、审计线索能够确定与标准的正常活动的本质差异吗？决定正常活动和异常活动之间的差别是至关重要的。
　　5、审计线索的范围足够吗？
　　必须监视整个数据库系统，其范围包括：数据库软件、操作系统软件、数据库协议。注意，数据库协议并不遵循某个开放标准而且经常变化，因而常常是攻击者的切入点。
　　数据库防火墙和数据库活动监视一起提供数据库的保护、监视、警告，并且提供审计质量数据，能够调查并对针对数据库的恶意活动进行报告。
　　九、保护用户用于访问数据库的Web应用程序
　　虽然敏感数据存在于数据库中，但多数用户是通过一个Web应用程序来访问数据库的。因而，除了要保护数据库层，还需要保护Web应用程序层。保护在线应用程序和数据使其免受复杂的应用程序级攻击需要“双管齐下”的方法，既要考虑开发又要考虑生产。
　　开发：在保护Web应用程序时，在应用程序进入生产前可以采取几个步骤来改善安全。向应用程序的开发人员培训安全编码，并利用安全开发生命周期（SDLC）来改善安全代码的开发。还有几种可以测试并分析代码的模式，如静态代码测试、动态代码测试、架构风险分析、测试滥用情况、黑盒测试、白盒测试等。
　　许多企业在开发阶段还使用Web应用程序防火墙。在此情况下，Web应用程序防火墙并不提供防火墙功能，但监视除外。更准确地说，Web应用程序防火墙向开发人员提供了一种检查其应用程序操作的更好视图。在beta测试阶段，对于动态客户和客户数据而言，这更为有效。Web应用程序防火墙可以提供：
透明地监视Web应用程序和通信
监视客户如何使用Web应用程序及应用程序的工作方式
监视所期望的和真实的用户行为
关于Web应用程序参数的细节，如长度和类型
Web连接的性能结果
监视数据库活动（如果结合使用数据库活动监视和数据库防火墙）
　　生产：所有的安全编码、测试及最佳方法已经锁定。由于威胁不断演变，而且代码绝不会完美或100%的安全，因而需要在生产阶段强化Web应用程序的安全。Web应用程序防火墙能够提供多种好处，例如阻止恶意活动、监视、警告、报告等。另一个关键方面是解决Web应用程序的漏洞。Web应用程序防火墙能够执行虚拟补丁，但这种工作是在Web应用程序层完成的。
　　Web应用程序防火墙提供的其它功能包括：
在多个应用程序和版本之间的操作
警告或阻止恶意事件
Web应用程序的入侵检测
管理应用程序风险的深度防御
　　Web应用程序防火墙在开发和生产阶段可以提供增强安全性的高效机制。通过在Web应用程序层提供事件防御和检测，可以减轻源自内部或外部的对敏感数据的攻击，而敏感数据就会更安全。
　　总结
　　到目前为止，业界已经找到了大量的方法和技术来减轻恶意的内部人员威胁。然而，还需要一种统一的技术。数据安全需要一种透明性。通过将应用程序和数据库信息关联起来，对企业全面的数据安全形势形成一种整体的观点，同时又强化防止、检测、审计内部人员活动，这是可能的。
　　当今的攻击伎俩利用了数据库和应用程序之间的诸多弱点。从侦察阶段到实际的攻击阶段，非常关键的一点是，将数据库和应用程序之间的信息与真正理解用户和数据的交互方式关联起来，并且将合法的活动与潜在的或已知的恶意活动隔离开来。
　　内部人员的威胁分析，可以从以数据为中心的多个信息源中获得好处，这是因为单个源提供的信息可能并不完整。发现和分类应当用于确认关键的资产及其包含的信息。利用Web应用程序防火墙来保护应用程序，利用数据库防火墙来保护数据库，并应当利用数据库活动监视来提供数据库的审计。可以将这些方案一起用于减轻内部人员的威胁，即使对于极复杂的运行着关键任务的分布式环境，也不应当影响Web应用程序和数据库操作的性能
 
 
TechTarget中国原创内容