针对数据库的许多黑客行为之所以发生，是因为与这些数据库连接的Web应用程序存在着漏洞。然而，企业越来越多地将最有价值的数据暴露给外部应用程序。在本文中，我们将讨论安全团队、数据库管理员和应用程序开发人员如何协同工作，从而改善前端Web应用程序和后端数据库的防御，防止恶意攻击，并关注最常见的源自Web的数据库攻击。
开放的代价
Web应用程序是攻击者最喜爱的目标：任何攻击者从任何地方都可以访问这些应用程序，而且这些程序往往是一个单位内部珍贵数据的网关。
很明显，企业需要工具和策略来帮助其Web应用程序开发者保护其后端数据库的完整性，而数据库的开发人员必须确保其Web接口要尽可能安全。然而，数据库常常被忽视，甚至被安全管理员和开发者所误解。很多情况下，我们仅专注于保障Web应用程序免受跨站脚本攻击（XSS）或认证中的漏洞，却忘记了数据库也需要受到重视。
其实，在多数情况下，Web应用程序自身对攻击者而言几乎毫无价值。相反，攻击者将应用程序用作访问数据库一种管道。首要的防御步骤是确保数据库管理员不仅要理解敏感数据的存储位置和访问方式，更要理解暴露数据的真实风险。

Web威胁
数据库除了遭受数据暴露的风险，在通过Web应用程序访问数据库时，还需要考虑和防护更多的威胁。为了对付由Web应用程序所带来的威胁，如SQL注入、认证漏洞、不安全的会话握手、特权提升等，给数据库打补丁、访问权限管理和连接访问控制等都是可以采用的标准化的数据库安全措施。我们将讨论这些威胁，但是，从这些风险中可得到的最大教训是，通过“净化”输入并建立安全连接，以及限制暴露给数据库服务器的程度，从而准许尽可能少的特权，保障访问方法的安全性。
SQL注入漏洞准许攻击者插入或修改SQL语句，以便于运行其自己的查询。其意图是控制数据库，使其返回攻击者需要的结果，如在窃取数据时，或在操纵应用程序时，使其认为返回的数据是合法结果，并进入下一个步骤，例如，欺骗应用程序无需输入口令即可登录。
不安全的会话处理：该漏洞可包括两方面，一是准许会话检查安全和不安全的状态，二是使得攻击者可以劫持或穷举授权用户。
认证漏洞：该漏洞使得攻击者可以绕过应用程序的认证过程，无需正确授权即可获得访问权。虽然这是一种应用程序缺陷，正确使用数据库可有助于防护这类攻击。
特权提升：它类似于认证漏洞，但是，攻击者只有使用合法账户通过认证后，才会出现该漏洞。然后，攻击者找到一种方法来欺骗应用程序提供超过许可范围的访问。同样地，这也是一种应用程序问题，但是数据库有助于我们对付这个问题。
在深入讨论技术修复和保护之前，应当清晰地理解数据库及能够访问数据库从而带来威胁的应用程序。
协同工作
安全绝对不仅仅是任何个人或团队的责任，在应用程序安全问题上尤其如此，信息安全人员、开发人员、系统管理员等都要参与其中。协作是关键。单位应当构建成熟的安全文化，并且利用安全标准库来实现数据库调用和数据验证，在数据库和应用程序之间拥有数据访问层，还必须确保所有的数据库访问许可受到严格的限制，不同技术团队的成员需要参与到数据库的安全规划和部署中，并理解数据库的高级应用。通过协同工作，每个人都可以更好地理解威胁，而且可以开发更好的方案来应对这些威胁。
别把非开发人员吓跑。要确保每个人都理解每种技术的传达方式以及应用程序的数据流。知道数据在哪里，它将流向哪里，它是否要流向多个方向。由此产生数据库的第一层保护。
安全设计的基础，亦称安全架构，是指如果我们以一种安全方式设计数据通道就可以减少威胁。如果攻击者无法直接访问数据库，就减少了他们攻击的机动性。给与攻击者的空间越多，其攻击就越容易，清理工作就越麻烦。这意味着，你应当保障对数据库的访问只能限于那些需要访问的系统，而且所有的访问都要经过认证并加密。保持网络和系统设计的安全可以更长远地保护数据库。再加上对数据库通道的限制，就可以进一步减少风险。
决定威胁的过程称为威胁建模。从历史上看，威胁建模已被用于应用程序安全，以决定应用程序的最高风险部分，从而使得安全人员专注于这些方面而非其它方面。
威胁建模涉及与了解应用程序的人员和其它相关技术领域的专家进行会晤，其目的是为了理解应用程序的不同部分及其功能和固有的威胁。通过花费时间来完全掌握应用程序及其相关的威胁，就可以调整保护和测试措施，从而节省时间，或者在时间和预算紧张的情况下能够在最大程度上减轻威胁。如果所有各方不能坐下来协同工作，威胁建模就是让安全人员理解安全局势的好方法，它可以确定风险领域，并与每一个小组进行合作，确保部署恰当的保护。
在针对多种应用程序或部署执行威胁建模时，要做好笔记。要找到应用程序的共同点。这些共同点应当用于检查内部发布的数据库访问标准、访问授权及访问方式。安全策略应当涉及到最常见的情形，并向开发人员和数据库管理员明确地提供指导，其目的是为了确保有一个参考指南。
一旦这些过程就位，就应当从基础阶段向前迈进，并向数据库环境增加保护。
数据库的配置是保护数据的最重要的要素之一。每种环境都各不相同，但有一些配置必须绝对到位：
确保对数据库连接进行加密：这样做可以防止数据库遭受网络嗅探或中间人攻击。
保证对所有应用程序实施认证：每个应用程序都应当使用自己的登录凭证。
尽可能精细地配置权限：在配置过程中，仅给每个应用程序所需的权限，这种策略常被称为最少特权。
安全措施
“保护贵重的东西。”很多人可能已经厌倦了这个说法，但这却是生存之道。数据库是保护“王冠”的保险箱。如果此保险箱不安全，王冠上的宝石就不会安全。单位应当采用网络分段和隔离系统，并将数据库服务器放在一层或多层保护之后，来保护数据库服务器。
在此可以使用很多新技术，如数据库活动监视软件和DLP（数据泄露防护）。但是别冷落了“老当益壮”的防火墙。将数据库服务器放在标准的网络防火墙后面，并限制访问，明确哪些系统可以访问数据库，因而可以减轻风险。然后根据数据分类或风险模型将数据库隔离到不同的系统上，从而可以确保安全等级较低的应用程序无法访问安全等级较高的数据库。例如，是否准许控制客户论坛的服务器去访问存储着信用卡持有者数据的数据库服务器呢？如果准许，那么攻击者就可以攻击肯定不会受到较多安全关注的论坛应用程序，并用它来窃取持卡人的数据。当然，这只是假设。
完全隔离包含敏感数据的系统是最佳的保护之道，但却并不可行。单位必须正确设置数据库认证，并确保较低安全等级的应用程序不会将风险带给更安全的数据存储。例如，假设你允许博客软件访问由电子商务应用程序存储的信用卡数据，将会出现何种情况呢？。
隔离与安全
在访问权限和账户的基础上，如果应用程序准许用户通过同一实例从多个单位登录，那么，应用程序就应当采取保护措施确保一个单位无法访问另外一个单位的数据。可以创建独立的数据库或数据表，从而在数据库水平上实现这种保护。通过这种方法，就可以使用不同的数据库账户来隔离和保护数据。应用程序可以仅使用一个账户去为没有经过验证的请求服务，然后，应用程序可以将数据库账户切换到与用户的公司有关的账户。单位可以防止普通账户访问任何公司的数据，从而正确地设置许可。此外，甲公司的数据库账户不能访问乙公司的数据。这样做能够防止渗透进入公司防御系统的攻击者扩大其范围。
必须关注应用程序的数据库账户的切换方式，因为攻击者有可能通过SQL注入攻击强迫应用程序改变其连接。
在有些单位中，开发人员自己编写SQL查询，而在另外一些公司中，由数据库管理员编写并优化查询，然后再提供给开发者。在最安全的环境中，这些查询是由数据库管理员作为存储过程而编写和实施的。存储过程是需要由应用程序执行的预定义语句，因而它可使SQL注入漏洞更难以被利用。开发人员和管理人员务必研究存储过程，以达到完全理解。
通常都编制并调用定制函数，而不是使用标准函数，其目的是为了保证能够采取某些行动。例如，定制函数常常用于确保启用日志或错误报告。重视安全的单位一般都会编制函数来替换内建函数。这些新编制的函数基本上都是包装在保护层中的本地函数。在数据库中，对定制函数的调用可以确保在执行数据库输入之前先对其进行“净化”。这样做还可以确保仅能调用存储过程，从而防止开发人员调用自己的SQL查询。开发者起初可能不愿意使用定制库，因为这会要求他们学习新函数，所以实施是关键。为便于过渡，在创建新函数时，在本地函数名中可以加上共同的前缀。例如，如果有一个函数称为“print”，那么，可以给新的安全函数起名为“S_print”。
在开发安全库时，安全人员必须执行测试，以确保这些库可以提供所需要的保护水平，并且不会带来新风险。使用标准库的关键问题在于所有的应用程序能够以同样的方式处理数据库的访问，而不是学习每个应用程序如何与数据库交互。
回到源头问题
限制访问权限、保护数据库连接、对服务器和网络进行分段、部署安全认证、安全库、数据库配置在保护重要数据方面可以长远地发挥作用，但却无法挫败所有的攻击企图。一旦将这些保护层部署完毕，安全人员需要专注于最常见的威胁：Web应用程序。
Web应用程序就像其它任何软件一样，由于开发者所犯的错误而存在缺陷。我们承认漏洞的存在但未必承认缺陷将导致损害。与开发人员协作，并确保安全开发方法是其过程的一部分，这对于部署Web应用程序的任何单位而言都是至关重要的。Web应用程序的安全测试对于确保数据库中数据的安全至关重要。
使用Web应用程序扫描器是测试这些应用程序安全性的方法之一。还有一种与保护数据和数据库更相关且更为彻底的方法，即执行源代码分析。这项工作是一个繁琐而冗长的过程，所以源代码分析软件（如Armorize 和Fortify）就显得很有价值了。
到目前为止，我们强调的都是预防性措施。在现实世界中，我们不可能不断地变更过程和环境，所以必须采用其它技术。这正是新型防火墙产生的原因。应用程序防火墙位于应用程序之前并监视通信，或执行运行时分析。这种防火墙可以确认攻击，或修改请求，以确保数据通信的安全性。由于付款卡行业数据安全标准（PCI DSS）的要求而产生了Web应用程序防火墙，但也存在着数据库防火墙（如GreenSQL的数据库防火墙）。这些防火墙位于数据库之前，并检查每个进入的请求。通常，这些防火墙比Web应用程序防火墙更易于部署，因为数据库的登录点以及可接受的变量更少。这种工具可执行其它有价值的功能，如错误报告、错误配置检测，因而可以为操作人员提供保护生产环境的有用信息。另外一种方法是使用来自厂商的软件来监视活动并实施一套准许或拒绝访问的规则。这类系统与数据库防火墙类似，但它是通过监视数据库内部的活动来解决问题的，而不是监视进入和转出的数据。
任何优秀的数据库安全策略都应当包括监视和审核，以确保所有的保护措施正在可靠运行。这可能是一个相当费时的过程。由于缺乏时间和工具，所以常常执行数据库的配置检查和日志检查。关键是执行某种复发率的评估，其目的是为了确保各种控制措施都能正常运行，并针对所发现的问题采取行动，确保在检测到风险后能够及时解决。
数据库的安全并非仅仅给数据库打补丁或确保操作系统的安全。还必须考虑应用程序的安全性，以及应用程序与数据库的交互方式，特别是在用高度动态化、交互性日益增多的Web应用程序进行工作时尤其如此。在保障数据安全时，理解应用程序和环境内部的数据库角色是最有价值的信息。凭借这种信息，就可以建立和实施分层的控制和风险减轻策略。
不管一个单位是否决定部署数据库防火墙、源代码审核，或在数据库管理系统内部严格地实施控制，其目标都是一样的：保护有价值的信息资产。

文章如转载，请注明转载自：http://www.5iadmin.com/post/862.html