不同于以往所有过分宣传的数据库漏洞，以及几十个隐私和安全规范，新出现了一个让SQL Server开发人员和数据库管理员们陷入了不得不面对强势用户的尴尬境地。他们问：
·你如何保护数据库中的敏感数据?
·你对你的数据库使用了什么加密方法?
·你如何将我们的数据与其他人的分离开来?
·我们有很多不同的客户——你能加密每个数据集吗?(这是以上最坏的问题。)
虽然这些问题看上去很古怪，但是他们问出来了，你就需要知道如何应对，无论你是一个独立的软件开发人员，还是给一家大公司工作，或者是在两者之间。
许多人都这样盲目地要求数据库分离和加密。他们受到来自审计员、经理们、销售人员，或者那些不懂得数据库安全措施工作方式的客户们的压力。许多人都认为分离数据集并且采用数据库加密就像电闸开关一样简单。他们不知道数据库管理员和开发人员面临着什么。这里有性能的需求，代码重新编写，必要的系统升级，第三方控制的实现，系统维护等等内容。更不必说，所有这些的价格对于需要它们的人来说通常就像是一片难以下咽的药片。
我从来不是一个大惊小怪的人，如果说到数据库分离和加密，没有人会拒绝这样的事实：数据库里面有黄金，坏人都希望在攻击你的系统的时候有最大的收获。如果数据库没有被充分保护，这就任凭攻击者的处置了。
对于数据库分离和加密，你有很多的选项。你可以升级到SQL Server 2005，编写你自己的加密机制，或者部署一个第三方的加密系统，你还可以：
·为每个用户创建一个唯一的数据库(天啊!)
·为每个客户建立一个唯一的应用程序和数据库服务器(你能说什么?)
·为不同的数据库和表建立(并管理)不同的用户账号(讨厌!)
·为每个用户建立唯一的加密密钥，这样他们就可以访问他们存放在数据库中的自己的数据了(说起来容易做起来难!)
但是所有这些都没有完成整个画面。这里有太多的变数了。大多数数据库安全技术的问题是，如果前端应用程序或者经过授权的SQL Server账号可以访问并且解密敏感数据，那么那些进行SQL注入的攻击者或者破解了弱密码的人也可以做。最大多数情况中，无论你是在服务器上有一个单独的数据库，还是有多个数据库分散在多个系统中，这一点都是适用的。底线——如果你的前端应用程序虚弱的话，那么你的数据库中的敏感数据仍然是有风险的。
我想要说的是，数据库安全控制，例如分离和加密都不轻松或者便宜。尽管有一件事情是必然的——如果你把敏感数据和私人数据放在了你的数据库里面，那么它基本上是安全的，人们会开始问，你做了什么来保护它。你不会让它离开你的视线的。
看看实现这些额外的数据库安全控制需要涉及多少方面。把你的方式解释给他们听，你如何分隔每个数据库，加密敏感信息等。胡，给他们一个你不能做的理由。按照你已经部署的其它控制，减少数据库分离和加密的需求，例如，输入过滤，强有力的认真，甚至是所有磁盘的加密，以防你的整个数据库服务器或者硬盘被偷去。还有，不要忽视利用好工具和人工评估进行的渗透测试。还有正式的利用一些工具的数据库安全审计，例如AppDetective 和NGSSQuirreL，甚至是源代码分析工具，例如Compuware, Ounce Labs, Fortify Software, SPI Dynamics, 和 Klocwork公司提供的针对你的应用程序的分析工具