数据库安全工具的用途异常广泛，提供了安全、合规、甚至运营等方面的好处。这些产品可从第三方获得，提供的数据库安全级别远高于关系数据库管理系统(RDBMS)厂商为客户提供的安全级别。
对数据库评估(又叫数据库安全漏洞评估)、加密、数据库合规和测试数据管理、标记化和数据屏蔽等领域的数据库工具来说，尤其如此。
下面是企业常常使用安全附件来加强数据库安全的几种典型的使用场合和方式。由于数据库用来支持企业内部几乎每一种应用程序和业务职能，你会发现数据库无处不在。正是由于具有如此多样的用途，我们发现对数据库安全的要求同样多样化。
第一种使用场合：合规
合规无疑是推动数据库安全开支的最大因素，这也是为什么大多数公司只把附加的安全技术部署到监管部门审查范围之内的那些数据库上。监管法规往往分为两个不同方面：受《萨班斯-奥克斯利法案》驱动的反欺诈和确保客户隐私的支付卡行业数据安全标准，后者受《金融服务现代化法》及诸多州隐私保护法规的驱动。
数据库安全还受与合规有关的第三个因素：成本削减的驱动。为数据库或数据库管理的数据确保安全常常比为与这些数据库相关联的所有应用程序和网络确保安全来得容易，而且省钱。
用来满足合规的数据库安全工具五花八门。比如：
•评估扫描工具可定期检测范围内的数据库，查找已知的安全漏洞和(内部)策略合规。一些监管法规要求定期评估数据库，以查找安全问题、策略(配置)合规或两者。
•权限审计，查明职务划分是否落实到位，并寻找权限申请过度的情况，这由各监管法规定义。虽然所有安全漏洞工具能在某种程度上评估数据库平台，但不是针对数据库的工具都无法执行这项任务：有资格地扫描和评估用户权限。现在某些监管法规要求这么做，确保用户无法在指定范围之外操作，并且发现用户被分配多个角色等问题，这会导致利益冲突。这可以手动评估，但是如果有工具可以使用，那么使用工具高效得多。
•数据库活动监控(DAM)以监控特权用户，这常常是在合规项目使用DAM产品的最大一个原因。这会生成登录/退出报告，还能跟踪所有的系统活动，并提醒管理员和一小部分特权用户何时查看了敏感信息。
•使用DAM用于综合的合规报告，覆盖多个数据库和应用程序。安全信息和事件管理(SIEM)平台并不收集必要的事件，内置的数据库工具并不提供跨数据库统一收集事件或策略执行这种功能。策略级报告表明，控制措施落实到位，而其他报告提供了验证控制措施必不可少的审计跟踪记录。大多数数据库安全工具包括这类报告，满足众多主要监管法规的需要，还有针对特定行业的定制格式。
•标记化和数据屏蔽，移除了敏感数据，因而将数据库从合规范围移除出去。如果敏感数据换成非敏感数据，合规需求同样被移除。
第二种使用场合：Web应用程序安全
SQL注入攻击是一种针对数据库发动的攻击。 虽然攻击通过应用程序进入，但这是一种数据库攻击，它仍是过去十年三种最常见的攻击途径之一。几乎所有的Web应用程序都由数据库来支持，但由于面向公众的是应用程序，应用程序开发人员常常事先并未考虑到数据库，对它未加保护。虽然Web应用防火墙可以阻止一些SQL注入攻击，但是一个主要局限是，它们未必明白所要保护的数据库，所以往往出现误报和漏报。
DAM产品和数据库防火墙可以解决这些问题，不需要劳命伤财地重写应用程序代码，即可排除SQL注入攻击和脚本安全漏洞。改写企业应用程序以处理安全问题的成本常常超过最初开发应用程序的成本;而在其他情况下，按照现有的人员数量，不可能在短时期内拿出修正版。这就是为什么许多公司寻找可应对这些攻击的附加工具。
比如说，只要新的查询或模式出现，查询白名单就会提醒管理员，或者明白应用程序应该发送什么数据、自动阻止之外的任何数据。市面上的一些工具甚至能将违规情况返回给Web应用程序防火墙，或者提醒，或者终止可疑会话，甚至阻止行为不端的IP地址。
第三种使用场合：变更管理和内部审计
关键数据库在补丁和升级过程中因糟糕的变更管理而出现故障比因攻击而出现故障更为常见。不像应用程序代码变更，管理员通常径直进入到生产数据库，直接处理数据，很容易引起停运。增添DAM支持的闭环变更管理(也就是故障单系统)可减少糟糕变更的可能性，并且大大加深了问责制，即便使用共享的登录信息。
评估工具可以扫描数据库，让安全团队和合规团队可以验证数据库管理员尽到了本职工作。DAM用于闭环验证：管理员的操作对应于特定的变更故障单，而监控机制表明了每个SQL命令的完整日志――还常常返回值。
DAM通常用于事件收集和分析，为合规报告和SIEM系统提供数据基础，那样审计团队拥有所需的事件数据。而越来越多的公司在使用DAM和动态屏蔽技术，保护这些系统远离恶意查询，那样不用更改应用程序或支持性数据库，就可以实施安全策略。
如果一些公司担心内部窃取和欺诈，这后一种验证让非数据库管理员能够全面了解数据库维护和补丁方面所做的工作。
第四种使用场合：遗留数据库安全
说实话，内部的许多数据库是在没人考虑数据或数据库安全软件的情况下就仓促设计和部署的。设计的这些数据库依赖危险的因素，比如外部存储的程序，或者使用社会保障号码作为主要的数据库密钥。但是这些数据库实例依然存在，因为它们支持关键的业务流程。问题在于，就算企业能找到仍非常清楚遗留系统的工作原理而改造遗留应用程序的人员，而且获得了这方面所需的预算，软硬件仍是太陈旧了，你只要碰一下系统，它们就出现故障。
数据库安全工具日益关注的方面之一是遗留数据库安全。这些尤其适合这种场合：企业因所需的变更会引起数据库停止运行而无法为数据库服务器确保安全。
谁会得益于数据库安全软件?
对大多数企业来说，它们根本不会询问自己是否需要保护关系数据库或RDBMS。毕竟，一连串的数据泄密事件和合规要求已解决了这个问题。
与此同时，企业组织还发现网络和端点安全产品并没有保护到数据库。他们还痛苦地发现，RDBMS厂商的普通的安全产品声称可保护到数据库，却提供了不够标准的策略和良莠不齐的事件收集功能。实际上，普通产品无法区别正常使用和恶意使用，也无法足够有效地评估配置和补丁级别，因为它们缺少数据和分析功能。
让这个问题复杂化的是，需要这些数据的利益相关方(比如安全团队和内部审计团队)缺少收集数据的技术经验。IT和数据库管理员又不愿改动应用程序或数据库，生怕破坏这些系统的稳定性。
数据库安全工具在这方面提供了实实在在的好处;它们让用户可以提供所需的安全和审计，又不用更改实际数据库，也不会给数据库的性能带来负面影响。真正的挑战在于，选择合适的数据库安全软件，以解决企业面临的问题，我们会在下一篇文章中探讨这方面。
英文：Four enterprise scenarios for deploying database security tools
