但是，先进的分析手段就意味着先进的政策，这些政策要针对你的环境，供应商没法为你事先设定。为了检测和阻止SQL注入攻击，你需要为你的应用程序定义合法的SQL查询语句。如果你不能及时地给数据库打补丁，那么你就需要编写一个政策，用于检测攻击，同时部署DAM阻止威胁。幸运的是，即便你的数据库供应商没有为你预设政策，你的DAM供应商也会帮助你自定义。
为实现行为监测，即发现异常的行为，你需要定义什么样的行为才是正常的。要识别特定应用程序用户——并不是通常地应用程序连接数据库的账户——你需要提供查询IP地址或者传递用户凭证的手段。如果检测到严重的威胁，你需要决定是否断开该用户，或者锁定账户禁止其访问系统。所有这些高级的功能都要求你进行自定义操作。DAM供应商只是提供模板和工具，帮助你针对自己的应用环境建立政策、监测和执行手段，但政策必须由你自己定制。
部署DAM
长期来看，如果要从一开始就节省时间、避免麻烦，管理DAM平台有几个方面需要注意。包括：
分离职责：基于安全和法规两方面的原因，撰写政策和审核报告的人不应该是监控数据库的管理员。同样地，一组数据库的DBA不应使用DAM工具窥探其他组的数据库。想法就是要检测舞弊、相互制约，所以应在DAM产品内区分角色和责任。
长期存储：数据库活动检测平台通常没有储存安全信息、事件管理SIEM）信息和日志管理信息的能力，但一般会提供一些相关的能力。这些产品注重语句级别的分析，而不是长期的存储和管理。事件很少能在DAM产品中保存超过30天。如果你想执行90天或者180天长的窗口期的分析，那就需要为DAM服务器或者日志管理系统提供额外的存储器。
可扩展性：DAM的可扩展性有三个关键问题：事务量、网络拓扑以及专用于监控的系统资源。DAM系统的架构要与本地的数据收集器、事件分析和警告产生设备、中央政策管理和报告设备相适应。你需要确保上述每一部分都能与其他部分进行可靠的沟通，并且你能从部署在虚拟环境中的数据库中收集事件信息。要最大程度地利用你在DAM上的投资，最好是要理解你需要分析的事件的类型，并过滤掉所有你担心的东西。更少的事件信息意味着更少的存储和处理开销。当需要监控每小时执行上百万条查询的数据库时，过滤能极大地降低设备或服务器投资。
数据库活动监测是一项成熟的技术，专注于数据库事务，提供了保护数据、阻止恶意操作的有效手段。但是，要体现监测平台的价值，你需要投资建立规则、警示和报告机制，从而解决你所面临的安全问题。
此外，为避免造成管理或性能问题，部署系统时需仔细斟酌安装选项。DAM的用途有很多，所以你需要清楚地知道你的优先工作是什么。在运用更高级的安全功能之前，你应首先让基本的系统工作起来。
编辑推荐】