数据库安全漏洞可谓层出不穷，各公司的数据库遭受损害的“好戏”仍在不断上演。数据库的安全问题未必是由数据库本身引起的，来自其它网络角落的漏洞也会给数据库带来风险，如终端和第三方供应商。本文将总结这些风险和威胁，并提供规避风险的新技巧和见解。

　　端点受害影响数据库的安全性

　　虽然许多数据库安全专家担心内部威胁和特权访问，但如果一个端点感染了恶意软件，就会对敏感数据的存储带来威胁。看似平常的端点有可能成为黑客入侵敏感数据库的入口。黑客可依赖简单的社交工程在端点上建立立足点，从而为进一步的数据库攻击找到出路。

　　例如，一位粗心的员工访问了一个不该访问的网站或收到了一个看似来自某个朋友的邮件，单击了其中的一个链接，然后该链接又引导他下载了一个恶意的恶意程序或间谍软件。

　　此后，恶意软件包分几个不同的阶段被安装到电脑上，并且是从Web的多个位置组装的。员工先下载了某个并不了解的恶意程序组件，然后此组件又通过访问Web，进一步从其它服务器下载其它不同组件，重新组合，甚至在受害者电脑中重新编译，最终形成极危险的恶意软件。危险的恶意软件可以先从网络内部进行探测，查找易受攻击的数据库和信息存储。

　　为对付这种攻击，数据库活动的行为分析在检测端点的异常行为方面更有效，因为一般情况下这种端点访问数据库信息的数量是有限的。

　　但是，今天的黑客都有一套自动化的方法来慢慢地透露信息，所以其行为与普通用户非常类似。

　　当心第三方带来的数据损害

　　云计算似乎无所不能，并日益流行，而作为外包服务的用户却应当对安全感到忧心忡忡。如果一家公司要与另一家在线服务供应商进行贸易，它应该检查对方的安全。

　　许多公司对于将认证交给云仍感到不踏实，除非公司对于供应商及其安全性感到非常满意。不幸的是，关于供应商是否安全，并没有什么权威性或学术性的标准，所以公司需要自己努力。

　　虽然要求处理信用卡和金融数据的公司都要遵循支付卡行业数据安全标准（PCI DSS），但我们却没有一套保护个人身份信息的标准。即使是使用与PCI相同标准的公司也未必能保证真正的安全。

　　如何应对这种风险？关键的一点是，维持客户数据的公司应当使用WEB应用防火墙，并使用安全方法来开发软件，对于关键服务器还要坚决使用白名单技术。

　　此外，处理信用卡数据和个人信息的公司还应当限制能够接触数据的服务器和雇员的数量。通过将关键信息存储到自己的服务器上，而不是将其交给第三方，公司就可以控制数据的保护。这里涉及的是Web2.0模式和整个云模式的问题，也许最佳的做法就是要把“好钢用在刀刃上”，要减少控制范围。

　　我们应该学到什么？

　　为什么数据库的安全损害常常一波未平，一波又起？原因很多，没有打补丁、启用不必要的数据库功能、失效的配置管理、缓冲区溢出、特权升级、错误的加密策略、选择了错误的第三方厂商等等。根据近年来的案例，我在这里总结几个典型的数据库安全教训。

　　首先，企业需要努力理解其数据库的存储位置，其中也包括测试数据库，并且理解数据库的配置情况。必须确保不能随便地把最机密的信息连到网络上。

　　其次，要不遗余力地监视服务器和数据库，这样做有助于及早向管理员发出警告，并在数据库遭到非法访问时能够提供更好的证据。

　　第三，检查所使用的加密方法是否过于陈旧，特别是存储在数据库中的用户口令是否使用了强加密，否则在数据库遭到非法访问后，用户口令将被轻易破解。

　　第四，任何单位必须审查处理其数据的其它单位，看其如何处理数据库和敏感信息。千万不能把机密数据随意交给并不了解其安全状况的供应商。

　　第五，任何单位都必须彻底清除共享口令，关闭前任雇员的账户，并监视现有账户的异常行为。

　　当然，这些建议并不全面，要想真正解决数据库的安全问题，关键是建立、实施一套健全的安全保障体系，特别是采取综合治理、全面设防的方法。下面谈的问题就与此有关。

　　改善安全：将数据库的活动监视（DAM）信息纳入到安全信息和事件管理(SIEM)中

　　从过去上看，数据库活动监视（DAM）和安全信息及事件管理（SIEM）技术是分开工作的。但由于安全技术不断改进,各种威胁不断变化，这两项技术之间的城墙开始消除。

　　为完整地洞察数据库活动及其周边环境，任何单位都需要将其数据库活动监视信息纳入到一种安全信息及事件管理工具中。

　　如果一个客户所做的事情只不过是监视一个数据库，那么，很明显，没有必要大张旗鼓地使用SIEM（安全信息及事件管理）。但是多数公司关注的问题很多，不仅仅是数据库。其实，将数据库活动监视（DAM）与SIEM集成起来的最大好处是它提供的环境。

　　数据库攻击通常是更广泛攻击的一个方面。数据库活动监视无法监视网络通信、服务器配置、渗透企图、用户活动等诸多问题。而SIEM却可以在这些广泛的数据集中找到攻击模式，当然，这需要对其进行配置，而数据库信息就是一种数据源。

　　这种环境对于通过应用程序监视数据库的访问是相当重要的，显然这要求应用程序要与数据存储进行绑定。

　　DAM产品的常见问题是多数客户并没有能够直接与数据库对话的应用程序。虽然他们拥有某种应用程序服务器，这个服务器运行着能够与数据库对话的应用程序，而这种应用程序服务器一般拥有一个与数据库的连接。通过此连接，传输所有的应用程序用户请求。所以，这意味着应用程序也许可以看到某个用户登录进入，并请求了一些客户清单，但就数据库所理解的而言，用户只不过是称为“应用程序服务器”的东西。

　　将DAM信息与SIEM结合起来，有助于单位更容易地把某用户在前端应用程序上的操作与由应用程序服务器直接发送给数据库的查询请求联系起来。

　　单位调用应用程序日志，将应用程序日志发送给SIEM，将DAM日志也发送给SIEM，而SIEM将这两者关联起来。在同一时间点上，应用程序记录了用户“张三”做了什么操作，而后DAM记录了某个用户执行了一种查询，查找了某类信息。所以SIEM可以将这两者关联起来，并得出结论认为“张三”做了什么操作。

　　将DAM整合到SIEM中的最大挑战并非技术，因为DAM和SIEM的厂商们在过去的几年不乏合作，其困难主要由内部矛盾引起。

　　在将DAM与SIEM整合起来时，需要记住的是，DAM一般属于数据库团队，而SIEM属于安全小组。必须看到，让这两个团队协同工作要比集成数据更为困难。其中一个老生常谈的问题就是性能与安全的矛盾。为了让整合更为平滑，单位必须做出折衷。

　　为什么会有整合问题？最重要的原因在于不同的部门负责人拥有不同的动机。数据库管理员管理着数据库，其任务就是确保数据库快速运行，不发生故障。那么，如果你需要将来自外部安全或审计组织的软件加载到数据库内存中，并要求它提供日志，这势必会影响数据库的性能和稳定性。此时，单位需要做出决策：要否要将其安装到数据库中呢？有没有更好的数据库安全方案？