开发人员和管理员总是被迫重新考虑其应用程序的——事后才加入保护很显然不再能够被接受。安全从一开始就必须是一个重点，从设计过程一开始就是。在你下一次负责开发SQL数据库的时候，请按照下面的指导方针，从一开始就为开发一个更加安全的应用程序作好准备。
基础知识 如果你还不了解SQL安全的基本概念，那么现在就先停下来，仔细研究一下这些基本概念；不了解这些概念，你就无法正确地保证数据库的安全。它可以让你把安全机制看作是一辆汽车。你有一个引擎、一把钥匙，并了解在转动钥匙点火到引擎轰鸣之间所有的步骤。如果你不知道这些步骤，那么成功解决这些问题的几率就会非常低。你当然可以把自己的车送到机械师那里（去修理），但是为了保证应用程序的安全，你自己就要成为（维护）数据库的机械师。
在一开始，你可以在两种安全模式中选择一种：
验证模式（ Authentication Mode）：用户通过已有的Windows用户帐号连接到服务器上。当用户尝试连接到服务器的时候，SQL服务器就会验证用户的Windows帐号名和密码。用户不必同时登录进网络和SQL服务器；这需要登录一次就行了。这种方式也叫做受信连接（trusted connection）。
混合模式（Mixed Mode）：这种模式结合了Windows验证和SQL服务器的验证。用户可以通过Windows的帐号连接，就像在Windows验证模式里一样。但是你也可以直接在SQL服务器里创建自己的帐号，而且它们不需要同Windows帐号有任何关系。每个SQL服务器帐号保存有用户名和密码。
我们建议在可能的时候都使用Windows验证模式。但是，在使用SQL服务器7.0（或者更早版本）的时候，必须要用混合模式。SQL服务器验证（混合模式）是为了向后兼容SQL服务器的更早版本而提供的。Windows验证同Windows安全系统集成在一起，这就提供了比SQL服务器验证更多的特性，而且更容易使用，更有效，更安全。你需要在设计过程的早期就决定要使用哪种模式。
密码 不论你使用哪种（验证）模式，总是要记住为SQL服务器自带的系统管理员（sa）用户设置一个密码。在你安装SQL服务器的时候，它会自动地使用SQL服务器的登录名sa和空白密码创建一个管理员用户。如果你不管这个用户而使用混合安全模式，那么任何具有SQL服务器基本知识的人，都可以轻易地登录进你的数据库，并做他们想做的事。如果你正在使用Windows验证模式，从理论上讲，你不需要为sa用户设置一个密码，因为SQL服务器登录不会被接受。但是设置一个密码总是个好习惯，以防止你在被迫转到混合模式的时候出问题。
如果把安全模式比作引擎，那么登录就是启动引擎的钥匙。你必须有正确的钥匙才能够启动你的引擎。登录的方式都是一样的——如果没有输入正确的用户名和密码，你就无法连接到网络上，继而无法连接到SQL服务器上。
作为管理员，一旦点火开动了引擎，你就准备好把车开走了。通过定义以下的属性，你就可以这样做了。
● 用户（帐号）：这是一个代表单个用户的SQL服务器安全帐号。用户拥有一个Windows帐号，或者一个SQL服务器的登录，后者和数据库里的一个用户帐号相对应。
● 组（帐号）：每个用户都可以属于一个或者多个组，组需要根据你的验证模式在Windows或者在SQL服务器里定义。每个组都有特定的许可。作为组的成员，你可以获得该组所有的许可。
● 对象所有权：所有权归创建该对象的用户。所有者可以将访问权赋予其他用户。例如，如果你拥有一个查看表，你可以决定哪些用户能够通过这个查看表看到数据。
● 许可：许可代表执行某个操作的能力，例如打开一个查看表，或者修改一个过程。SQL服务器能够识别许可的三种状态：GRANT赋予用户访问权；REVOKE删除访问权；DENY拒绝用户访问对象。
● 角色：这是SQL服务器的一个安全帐号，它在管理许可的时候将帐号的集合当作一个单位来对待。简而言之，角色定义了用户在特定数据库里能够做什么以及不能够做什么。
安全设计 设计过程是定义需要保护什么以及如何保护的最好时候。在这一过程的初期你就要注意两个方面的内容：
● 敏感数据
● 谁可以看到敏感数据
敏感数据可以是任何数据，包括所有的数据。有些数据库太敏感了，以至于对所有数据的访问都需要受到限制——但是这种程度的安全对于我们中的大多数人来说是很罕见的。你的任务就是保护在商业和数据库环境下，被定义为敏感数据的内容。
你所选择的验证模式以及你创建的登录方式，都会通过限制进入数据库的用户来加强第一道安全措施。有时候，这是数据库需要的唯一安全措施。
下一步是列出应该访问数据库的所有用户，然后决定是不是所有的数据都能向所有的用户开放。你经常会有想要保护的数据，比如薪水或者其他个人信息。这就意味着只允许特定的用户访问和查看该数据。你还需要决定谁能够修改该数据，这就形成了两个（权限）差别很大的用户组。
要紧记的一个重要原则是“最小权限”的概念。如果某人在其工作中不需要特定的数据，那么就不要让他们拥有这些数据。应该避免所有的用户都具有同sa用户相同的权限，不要因为它会让你开发工作更容易而打破这一原则。只有在业务需要的时候，用户才可以看到和更改数据。
具体的建议 在谈到安全的时候，经验是最好的老师，但是还是有一些通行的指导方针适用于所有的数据库：
● 从一开始就要取得数据库和对象的所有权。当你创建了一个新的数据库，你就成为了数据库的所有者，而且能够控制发生在数据库里的所有事情。在理想的情况下，你应该为实现这个目的而（专门）保留一个管理员的登录帐号，而不能让任何用户都具有这个权限。类似的，对象归其创建者所有。尽管所有权的转移是可能的，但是确保用一个专用的管理员登录帐号来创建所有的项目会更容易一些。
● 理解所有权链。这个安全特性会防止用户创建他们自己的查看窗获得不属于他们所有的敏感数据。例如，假设你创建了一个查看表，它会将两个表格里的数据集中到一起。如果你是这两个表格的所有者，那么在你赋予其他人权限来使用这个查看表的时候，SQL服务器就不会检查表格的许可。但是如果另外一个开发人员拥有其中一个表格，那么SQL服务器除了检查查看表的许可之外，还要检查表格的许可。
● 应该使用查看表和过程来赋予用户对数据的访问权，而不要强迫他们编写直接访问表格的特定查询。如果采取这种方式的话，你就不需要赋予用户访问底层表格的许可。查看表和存储过程还会限制用户可以看到的数据。例如，如果你的雇员表格包含保密的薪水信息，你就可以创建一个没有薪水栏的查看表。
● 如果用户通过某些应用程序来使用你的数据库，你可能想要创建应用程序的角色。一个应用程序的角色就像是被分配给某个应用程序的用户，而且能够被赋予它自己的权限。有了应用程序角色，用户就不用直接到数据库里验证；相反，他们对其自己的应用程序进行验证，这会决定哪个应用程序角色会被用来代表服务器。
● 打上最新的服务包。无可否认的是，服务包是一个混合的（修复）包。服务的发布、补丁和其他更新常常会带来新的问题。但是不管怎么说，坚持使用最新的服务包可能是你保护数据不受外界干扰的最佳和最简单的步骤。访问微软的SQL服务包页面可以找到当前最新的服务包。
底线 安全是每个开发人员的职责。不要等到数据库设计好了和实际使用了才想到了安全——安全是设计过程中不可分割的一部分。此外，不要随意应用安全（策略）就期望能够获得最好的效果。要学会安全模型并正确应用它们。
【责编:admin】
--------------------next---------------------
