数据库往往是网络犯罪的首要目标，在保护其中的数据时，企业绝对不能掉以轻心。本文将关注***者作为***目标的漏洞，探查其如何进入，在进入后的操作等。此外，文章还将建议如何关闭漏洞，并建立一种包含产品、过程、持久警惕等方面的分层次的安全方法。

企业越来越将重要的数据存放到服务器和数据库上，数据库的安全绝对不仅仅是解决SQL注入那么简单。它包括口令管理、对用户配置的方法、花费适当的时间对补丁进行部署等。恶意***和安全阵营之间的斗争将会继续进行。要在数据库的“大门口”阻止这些***需要“多管齐下”和持久的耐心和警惕。
规划好强健的防御意味着很好地理解***，即，要理解***需要什么、***会做什么。从SQL注入漏洞到用户配置，再以漏洞百出的数据库配置，***者将会使用其得到的任何工具来绕过或攻克安全机制。本文将探查***在企业的数据库防御体系中打通漏洞的方法，并探讨企业如何打出技术与策略的组合拳，将其***阻止在数据库的大门之外的方法。
应用程序、数据、SQL注入
并不是所有的***都要用企业的数据来赚钱；有些***只想把企业的数据公开到互联网上。***可能由于贪婪、愤怒或出于某种政治立场而攻克企业的数据库，占有其数据。这可能意味着***要找到敞开数据库大门的密钥（或称为弱口令），或者通过在数据库系统中查找漏洞，从而非法访问数据库。然而，***也可以使用所谓的“侧窗”，即当今的许多***借助有漏洞的Web应用程序来实施SQL注入。
SQL注入***仍是Web应用程序开发者、安全专家、数据库管理员的难题。这种***利用未经验证的用户输入，通过一个应用程序将命令发送到后端的数据库。***者喜欢做的事情之一就是查看应用程序如何处理错误。搜寻易受***站点的另一种方法是通过“利用谷歌搜索引擎进行非法侵入”。该方法通过利用其索引的海量数据，借助搜索引擎来发现安全漏洞。***者首先进入一个搜索查询，其设计目的是为了查找可能会提供易受***的网站的线索。***者可利用这种搜索查询来搜索SQL注入漏洞。例如，***者可利用诸如“allinurl:index.php?id= and allinurl:article.php?id=.”
从企业的观点来看，如何应对“利用谷歌搜索引擎进行非法侵入”是一件棘手的事情。保障网站免受种这种***的根本解决方案是保障网站的安全。 安全管理员可以尝试将“利用谷歌的搜索引擎***”作为***测试一部分，检查其公司网站。不过，精明的***者都知道，“利用谷歌搜索引擎进行非法侵入”仅能在局部起作用。要判定一个网站是否易于遭受SQL注入***，需要进一步的测试。
幸运的是，防御SQL注入漏洞还是相对容易的。其种的一种策略是对用户输入进行净化。另一种方法是使用参数化查询和存储过程。开发人员应当考虑使用参数化查询（预定义的语句），将占位符用于在运行时才提供值的参数。虽然利用这种方法可能会影响性能，但却可以阻止***。
使用存储化过程拥有同样的效果，虽然如果没有正确地对用户输入进行净化，在存储过程中的动态SQL仍易受***。应对SQL注入问题的一种终极解决方法是，在用户提交查询之前首先对查询进行分解。
虽然安全专家和开发人员可以封堵SQL注入***进入公司系统的漏洞，但对于熟练的***者而言，找到并利用SQL注入漏洞并非难事。
***并不缺乏工具。事实上，有些工具可帮助道德***进行***测试。其中一个较受欢迎的就是sqlmap，这是一个开源的测试工具，其功能很多，其中包括SQL注入检测引擎、数据取回功能、穷举数据库的功能等。专用于解决SQL注入的其它工具包括sqlninja、Havij、Priamos等。这些工具未必功能全面，但却提供了***利用数据库漏洞并访问数据的特性。
打开数据库的大门
不过，***数据库绝非仅仅依靠SQL注入。除了Web应用程序，***者还常常通过损害企业网络来对数据库发动***。***者可以从使用Nmap等工具开始，扫描查找开放的端口并映射目标网络，从而***公司网络。这些端口扫描可以提示***者，企业正在使用何种类型的数据库。例如，微软的SQL Server的默认端口是1433，而Oracle数据库的监听器一般使用1521端口。
在损害了网络之后，***者就可以转而使用口令破解工具。其原因在于，在整个IT界，使用弱口令甚至空口令仍然是一个严重的安全问题。
在许多公司，在不同数据库之间共享口令的情况简直是司空见惯。例如，对于Oracle数据库来说，你要为每一个实例选择不同的口令。如果你有几百或几千个实例，就需要管理大量的口令。许多管理员对不同的数据库使用完全相同的口令。如果***者可以访问某个数据库，他就可以访问更多的数据库。
共享口令可能很方便，但在***者成功地破解或攻克了一个数据库的口令之后，他就可以访问多个数据库。因而，企业应当更换默认口令，并确保数据库管理员和用户遵循关于口令复杂度的最佳方法。企业还应当考虑使用“在用户经过多次失败的登录尝试后”的超时功能或锁定功能。
然后就是真正的数据库漏洞问题了。正如其它软件一样，数据库也会存在一些可被***者利用的漏洞。漏洞扫描产品可以发现数据库中未打补丁的安全漏洞。此类产品很多，但是关注企业数据库和IT环境中底层安全问题是非常重要的：补丁的部署。
在给数据库打补丁问题上，许多企业常常疏忽大意，其中有合理的也有不合理的原因。数据库是现代企业信息系统的核心部分。对这种软件的改变绝不可掉以轻心。对一个生产系统组件的任何改变都要求在环境中进行分阶段的测试，并注意维护。由于这种关键组件往往会影响大量的应用程序，而且其副作用有可能无法预测，所以许多企业对数据库打补丁总是“姗姗来迟”。
事实上，企业可能会认为，在打补丁问题上，业务的连续性可能要高于安全性，但这样做却可能使数据遭受损失。因而，对企业来说，制定并实施一套补丁管理策略并至少优先处理关键的数据库更新是极为重要的。
滥用错误配置和访问特权
网络和安全工具的错误配置与没有打补丁的软件一样对数据库的安全都是致命威胁。安全工具中的错误配置可以完全敞开数据库的大门。企业必须关注目前没有使用的数据库特性和没有必要启用的特性。企业必须确保这些软件包不会在无意间增加***面。
数据库的配置错误也在授予用户过多特权和将过多特权交给访问数据库的应用程序过程中扮演着重要角色。分配适当的权利要求理解特定用户或用户组的业务需要。以此为依据，管理员就可以制定用户需要访问什么，也可以规定需要部署哪些控制。如果不能遵循最少特权原则就会导致***攫取企业的机密信息。
总体上讲，最少特权意味着不能给任何人访问超过其为完成工作而需要的资源。对一个访问数据库的应用程序而言也是同样的道理。例如，如果要求一个应用程序只能查看数据，它就不应当拥有改变信息的能力。如果不采取最少特权原则，就会增加***者盗用账户并利用受害者的访问权进行破坏的机会。
管理员应当在身份管理周期的开始阶段就决定用户的权利。虽然有人认为已经给身份管理很多的关注了，但身份管理正是许多企业做得不及格的领域。
例如，有许多企业在雇员离职时并没有对其相应的账户进行清理，结果形成了许多“遗留账户”，即隶属于某个不再担任任何企业角色的用户，例如被企业开除的任何人。还有许多企业并没有办法判定某个当前的或以前的雇员是否使用“遗留账户”来访问信息。
但许多企业并没有认识到到底有多少遗留账户。企业通常对雇员的辞职或其角色的改变都有一套健全的策略，保障禁用主要的账户，如活动目录、Windows的桌面登录、×××登录等。但许多企业却往往忽略了数据库的访问。
超级用户账户和职责分离这两个方面都与最少特权原则密切相关。许多企业并没有监视所有的特权用户在数据库上的活动，这也给外部***和内部威胁带来了可乘之机。
反击
从近几年的数据库***事件来看，恶意***将会继续推陈出新。除了本文讨论的这些策略和技术之外，讨论和重视数据库安全的企业都应当关注数据库活动监视这种关键技术，即所谓的DAM。DAM产品可以为关注合规要求的企业提供审计线索，并常常可以提供由异常的访问请求所激发的预警机制。来自DAM系统的信息应当提供给安全信息和事件的管理工具，用以提供对IT环境正在发生的问题的全面监视。
此外，企业还可部署数据库防火墙。这种产品可以过滤恶意通信，并可用于阻止SQL注入***和非授权的访问。另外，企业应当考虑其加密方法和数据屏蔽技术。要想知道哪些数据需要保护，IT就必须理解企业的需要，并知道哪些是机密数据。