在我最近撰写的一本书中，我尝试着为菜鸟SQL Server管理员解释SQL Server的安全性。必须承认的一点是，很少有应用程序是以SQL Server安全所希望的方式来进行编写的。我把问题归咎于懒惰的数据库开发人员。
不 足为奇的是，这本书早期的评审就是几个开发人员，而且对我的评论表现出了反感。有一个人写到，“SQL Server 并非唯一的数据库，我编写的代码还必须要与Oracle相匹配。”换句话说，要取代对每个数据库平台安全的特定考量，他只要采用最低标准即可，因为它简单 易行，而且不用考虑对用户产生的影响。
你需要意识到数据库开发人员和厂商的态度，而且你需要与其抗争。
class='fit-image' onload='javascript:if(this.width>498)this.width=498;' onmousewheel = 'javascript:return big(this)' width="481" height="296" border="0" alt="当心懒惰的程序员降低你的数据库安全" src="http://s3.51cto.com/wyfs02/M02/5B/BC/wKioL1USRXaBQmlPAACBAKzTJrM044.jpg" />
数据库安全技术最低的标准是在数据库中只创建一个用户账户，然后让每个应用程序副本都使用此单一用户账户登录。此应用程序会实现其自身的“安全性”，对于微软，Oracle以及其他平台公司数以百记专家开发出来的平台安全性，我是确信它是健壮的。
此方法的问题主要体现在以下几个重要方面：
审计：当只有一个用户账户可以访问数据的时候，你无法知道到底是谁在操作。当然，应用程序可以实现其自身的审计跟踪，但是任何有相关知识的用户如果拥有账户名和密码都可以绕过审计跟踪。
安全性：将用户名和密码嵌入进一个连接字符串使其不易让人发现信息。现成的工具可以在几秒钟内反编译常见的企业应用程序，这使得连接字符串和其密码都采取了明文的方式。
故障排除：由于你不能将一个单独的数据库连接指定给某个人，因此很难对性能和操作问题进行故障排除。当一个用户抱怨运行缓慢的时候，管理员也无法准确定位问题。这就意味着问题会持续更长的时间。
而 对于一个开发人员来说，换做让他的应用程序使用SQL Server自带安全几乎是不费吹灰之力。只需要对主连接字符串做出更改，移除用户名和密码并让用户的Windows登录凭证加以通过。在大多数环境中， 除了授权服务器端的权限让人们可以读写必要的数据之外，这都是数据库管理员所需要做的。你会利用SQL Server自己的审计功能，更好的进行故障排除，并且对于每个应用程序副本中嵌入的全能用户不提供明文密码来提升安全性。
那么你要如何与 最低标准的数据库安全技术相对抗呢?很简单。建立采购标准。确保新应用程序使用SQL Server的Windows身份验证机制。改变现有的应用程序。你可能需要和厂商制定一个时间表或是让他们了解到丰厚的“维护费用”收入不是那么好赚 的。掌控你的环境——有些人可以为你提供最好的安全性但这对他们而言一切都很简单，不要把公司交给这种人。
相关文章
