很少有比保护数据库及其存储的数据更加严峻的IT安全挑战了，尤其是针对最常用的数据库和Web应用程序的攻击：SQL注入。尽管关系型数据库管理系统(RDBMS)供应商、IT安全专家和应用程序开发人员都意识到了此类攻击，但问题依然存在，因为在不影响商业运作的前提下，这类攻击难以检测和阻止。

　　更严重的是，SQL注入是攻击者能够完全控制关系型数据库的攻击手段之一。关系型数据库结构复杂，允许多种应用程序同时读取或写入数据——每一种应用程序都支持多种业务功能——这使得我们难以比较关系型数据库的优劣。当攻击看起来就像是正常的数据库命令时，你需要做的就不仅仅是随意检查一下数据库操作事件了。

　　对于可能不熟悉这项技术的人来说，数据库活动检测(DAM)系统就是检测关系型数据库滥用的高级安全平台。DAM系统技术独特，能以近乎实时的速度分析数据库查询，区分正常的操作和攻击。DAM系统收集不同来源的信息，提供多种形式的高级分析和警告，甚至能直接中断恶意活动。没有其它的安全产品能以这种方式监测数据库的活动，或者提供DAM式的细化检查水平。

　　确定数据、事务的保护优先级

　　部署DAM的第一步是决定你想保护的内容。监测数据库有很多种方式，对每个事件都进行检测是不现实的，因为这样一来监测系统将比保护对象更加庞大。你需要了解什么样的数据或事务是重要的。有三种方法可以助你了解：

　　1、访问建立数据库的数据库管理员和应用程序开发者，因为他们通常都知道敏感数据的保存位置，也知道哪一类数据库支持关键业务功能。

　　2、使用数据发现和数据库检索器调查数据库内容。监测器最起码能够监测数据的写入和读取。作为附带功能，一些供应商还提供能够搜寻数据库内容的检索器。这些检测工具能够通过元数据和内容分析技术定位敏感数据，确定需要保护的数据。

　　3、观察SQL语句和数据库事务。大多数DAM系统在最开始的几周都是以“独立监测”(monitor-only)的模式运行的，因此公司能够逐渐了解数据库的运行状况。从本质上讲，你要给出应用程序使用数据库和常见查询样式的大概轮廓。然后你可以定义策略和实现方式，检测数据库滥用。

　　基于你的发现，你可以定义相关规则，允许哪些活动，并对可疑活动产生警告。

　　如何捕获数据库事件

　　现在你知道了何种事务是重要的，接下来你需要决定如何收集数据库事件。每一种数据库检测器都提供了多种收集数据的方法，每一种方法都各有优劣。

　　在数据库平台上安装代理很常见，因为代理能捕获所有SQL活动，在不影响数据库性能的前提下，有助于理解某次查询是否是恶意的。

　　本地审计功能可收集事件，但却不一定能收集到原始的SQL查询，开销也要大很多，影响数据库性能。

　　网络收集器则提供了一种更快更容易的收集SQL活动的方法，但会丢失管理员通过控制台进行的事务和活动。

　　代理是关键数据库事实上的安全工具。本地审计和网络监控则在非关键数据库上比较常见，但在特殊情况下使用得更多。

　　数据库安全的基本定义

　　现在，你已经在从关键数据库系统中收集事件，下一步是实现你的安全策略。DAM的工作方式是分析数据库查询，你可以通过很多选项设置对哪些语句进行检查，以及如何检查。数据库活动检测工具提供的基本功能有：

　　监测和查找

　　警告和报告

　　工作次序验证

　　捕获数据库滥用

　　SQL捕获(用于审计)

　　大多数政策执行的是数据库查询属性检查：用户是谁、用户正在浏览哪一列、用户使用何种应用程序、用户接触到的数据、操作时间等，这些通常都被用于定义安全策略。你为每一个属性分配特定值，当用户超过这些预定义的阈值时，监测系统就会产生警告。例如，你可能会想对这些情况产生警告：所有午夜之后的查询、三次失败的登录尝试、任何对信用卡资料的访问。

　　高级监控

　　数据库活动监测系统的能力在过去的几年里得到了极大的提高。过去只是纯粹的监测和警示，现在已经提供了一套可靠的阻止攻击、主动抵制滥用的方法。大多数DAM产品具有的高级功能有：

　　SQL注入监测

　　攻击阻止和虚拟补丁

　　特定应用程序用户认证

　　会话终止

　　行为监控和内部威胁检测

　　但是，先进的分析手段就意味着先进的政策，这些政策要针对你的环境，供应商没法为你事先设定。为了检测和阻止SQL注入攻击，你需要为你的应用程序定义合法的SQL查询语句。如果你不能及时地给数据库打补丁，那么你就需要编写一个政策，用于检测攻击，同时部署DAM阻止威胁。幸运的是，即便你的数据库供应商没有为你预设政策，你的DAM供应商也会帮助你自定义。

　　为实现行为监测，即发现异常的行为，你需要定义什么样的行为才是正常的。要识别特定应用程序用户——并不是通常地应用程序连接数据库的账户——你需要提供查询IP地址或者传递用户凭证的手段。如果检测到严重的威胁，你需要决定是否断开该用户，或者锁定账户禁止其访问系统。所有这些高级的功能都要求你进行自定义操作。DAM供应商只是提供模板和工具，帮助你针对自己的应用环境建立政策、监测和执行手段，但政策必须由你自己定制。

　　部署DAM

　　长期来看，如果要从一开始就节省时间、避免麻烦，管理DAM平台有几个方面需要注意。包括：

　　分离职责：基于安全和法规两方面的原因，撰写政策和审核报告的人不应该是监控数据库的管理员。同样地，一组数据库的DBA不应使用DAM工具窥探其他组的数据库。想法就是要检测舞弊、相互制约，所以应在DAM产品内区分角色和责任。

　　长期存储：数据库活动检测平台通常没有储存安全信息、事件管理(SIEM)信息和日志管理信息的能力，但一般会提供一些相关的能力。这些产品注重语句级别的分析，而不是长期的存储和管理。事件很少能在DAM产品中保存超过30天。如果你想执行90天或者180天长的窗口期的分析，那就需要为DAM服务器或者日志管理系统提供额外的存储器。

　　可扩展性：DAM的可扩展性有三个关键问题：事务量、网络拓扑以及专用于监控的系统资源。DAM系统的架构要与本地的数据收集器、事件分析和警告产生设备、中央政策管理和报告设备相适应。你需要确保上述每一部分都能与其他部分进行可靠的沟通，并且你能从部署在虚拟环境中的数据库中收集事件信息。要最大程度地利用你在DAM上的投资，最好是要理解你需要分析的事件的类型，并过滤掉所有你担心的东西。更少的事件信息意味着更少的存储和处理开销。当需要监控每小时执行上百万条查询的数据库时，过滤能极大地降低设备或服务器投资。

　　数据库活动监测是一项成熟的技术，专注于数据库事务，提供了保护数据、阻止恶意操作的有效手段。但是，要体现监测平台的价值，你需要投资建立规则、警示和报告机制，从而解决你所面临的安全问题。

　　此外，为避免造成管理或性能问题，部署系统时需仔细斟酌安装选项。DAM的用途有很多，所以你需要清楚地知道你的优先工作是什么。在运用更高级的安全功能之前，你应首先让基本的系统工作起来。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。