SQL Server 安全性Word文档下载推荐.docx
《SQL Server 安全性Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《SQL Server 安全性Word文档下载推荐.docx（39页珍藏版）》请在冰豆网上搜索。
可以从本书的网站下载学习所需要的东西。
是的，为了运行本章的示例，我不得不让你创建一个工作数据库——很抱歉。
这里将使用的是旧的Northwind数据库，只不过要删除所有对权限的修改。
我们将在整个这一章中使用的NorthwindSecure数据库，它是一种更典型的数据库场景——即是说，除了随着创建表和对象自然带来的权限外，绝对没有添加任何权限（即没有）。
随着本章讲述的深入，我们将学习如何处理权限，以及如何明确添加想要的权限。
22.1
安全性基础
我相信，就我们将在本节中查看的内容而言，有相当一部分似乎极为愚蠢——我的意思是，这些东西难道不是尽人皆知的吗？
然而，即便是这些规则中最简单的一个，违背它的情形也屡屡发生，从这些频繁发生的对规则的违反来判断，我要说，“不，显然它们不是。
”所有我能做的就是请你耐心一些，不要跳过这里的内容。
这里的某些内容看起来似乎很显而易见，但令人吃惊的是，它们常常被忘记或者被忽略。
在种种基础知识中，这里要讨论的是：
一个人，一个登录名，一个密码；
密码过期；
密码长度和组成；
尝试登录的次数；
用户ID和密码信息的存储。
22.1.1
一个人，一个登录名，一个密码
不断让我感到震惊的事情是，无论我到哪里，几乎总能发现机构中至少有一个“全局的”用户——网络或者特定的应用程序中的某个登录，该登录经常被部门或者甚至整个公司里几乎所有的人所知道。
通常，这个“全局的”用户拥有全权的（换言之，完全的）访问权。
对于SQLServer来说，安装甚至不把sa的密码设置为非空白的密码，这在过去是很平常的。
在SQLServer2000之前，sa账户的默认密码是空密码——即是说，它没有密码。
谢天谢地，SQLServer2000不仅改变了这种默认情况，而且，现在SQLServer还会预先告知，如果你坚持让该密码为空白，那你一定是不折不扣的白痴——这对开发团队十分有益。
需要当心的事情是，在进行开发时，还是会将它设置得很“简便”，这确实是很普遍的现象。
在投入生产之前，你还必须记住对它进行修改，或者，如果开发服务器将直接暴露在因特网上或暴露给其他不可信的访问，则必须从一开始就将它设置得很困难。
即使现在，当多数的安装都的确有了非空的密码时，许多人知道密码是什么的情形也极为普遍。
那么，第一个基础知识是，如果所有的人都能访问某个用户ID，则该用户ID本质上是匿名的（如果所有的人都知道它，则任何人都有可能使用它），并且能访问任何事情，那么，你已经彻底击败了你的安全模型。
同样，如果给每一个用户一个在所有事情上拥有完全访问权限的登录名，则也已经严重破坏了安全前景。
剩下的唯一真正的好处是，对于任何时刻谁有关联的问题，能够说出显著的人（假设他们确实使用了他们个人的登录名，而不是使用全局的登录名）。
应当把拥有全权访问权限的用户限制为仅仅一、两个人。
理想的情况是，如果需要这种全权访问的密码，那么，你会想要不同的登录名各自拥有这样的访问权，而对于每一个登录名来说，只会有一个人知道其密码。
你将发现，用户常常与其他人共享他们的密码，以便让某人临时获得某种级别的访问（通常，这是由于该登录ID的所有者要么在休假，要么在那时没有时间，以致无法亲自去完成此事）——如果可能的话，应当严禁这样做。
由共享密码导致的问题是多方面的。
第一，一些用户获得了对某些事物的访问权，而这种访问权最初是决定不给予他们的（否则，为什么他们自己没有这种必要的权限呢？
）——如果以前不准备让他们访问，现在为什么又想让他们访问了呢？
第二，不允许进行访问的用户现在可能暂时拥有了访问权。
由于用户几乎从不更换他们的密码（除非强迫他们这样做），被给予密码的人员多半能不定期地使用那个登录ID——并且，我向你保证，他们一定会的！
第三，你再次失去了审核。
你可能有一些基于登录ID来跟踪哪一个用户做了什么的东西。
如果有不止一个人有那个登录ID的密码，如何分辨在某个时候是哪一个人用那个登录ID登录进来的呢？
这就意味着，如果有人在某个时候将不在办公室，这或许是因为此人生病了，或者在度假，那么，将由另外的人临时接替此人去完成其工作，于是，应当明确为那个接替的人创建新的登录ID和密码（或者，应当修改其现有登录ID的访问权限），然后，一旦原来的人返回工作岗位，则应当删除新的登录ID。
总之，尽量别碰全局的用户账户。
如果必须使用它们，则要把它们的使用限制在尽可能少的人之中——通常，应当保持在仅仅两个人（一个是主要的使用者，而另一个是在第一个人无法完成任务的情况下作为候补之用）。
如果确实必须让不止一个人有重要的访问权，那么，可以考虑创建多个具有必要的访问权限的账户（一人一个账户）。
遵照这些简单的步骤，就能为系统的安全性和审核做出大量的贡献。
22.1.2
密码过期
密码过期的使用往往倾向于要么被滥用，要么被忽视。
因为它是一个很好的主意，但常常会变得不利。
密码过期背后的原理是：
对系统进行设置，使密码经过一段特定的时间后会自动过期。
在到达时间期限后，用户必须更改密码才能继续访问账户。
这一概念已经存在了许多年，如果你在较大的公司里工作，来自会计师事务所的审计师很可能已经在强调：
必须实现某种形式的密码过期。
从SQLServer2005开始，如今，你甚至可以为SQLServer专用密码强制使用Windows安全策略机制。
或者，你也可以只使用基于Windows的安全性（下一节中将有更多有关的内容）。
1．做这些努力，收益是什么
那么，密码过期能让你得到什么？
还记得我在前一节的最后说过，一旦密码被共享，用户将始终拥有那种访问权吗？
好吧，这里是例外的情况。
如果让密码过期，那么，就更新了安全级别——至少暂时如此。
为了让用户重新得到访问权，可能必须再次共享密码。
尽管这远远不算完美（该登录ID的拥有者经常会很乐意再次共享它），但当密码的共享确实只为了一次性的使用时，这的确处理了这种情况。
通常，数月之后，共享他们密码的用户甚至不会意识到共享了密码；
而另外的用户手里依然有密码，并且，可能间或会使用一下这个密码，以获得他们自身的安全级别所不应拥有的访问权。
2．下面是不利之处
好事做过了头，很可能变成坏事。
我在前面说过，许多会计师事务所都希望他们的客户实现这样的模式：
用户的密码会有规律地过期，例如，每30天——实际上，这是很糟的主意。
在我见过的所有这样做了的SQLServer安装中（无一例外），执行了30天过期的策略后，安全性变得更糟了。
正如你可能想象的那样，问题本质上是多方面的。
第一，技术支持的需求大大增多了。
当用户如此频繁地更改密码时，他们完全不能记住所有这些密码。
他们无法记住应该使用哪一个月的密码，由于忘记了密码是什么，因而经常需要技术支持来重置密码。
第二，这一点更为重要，用户对于想出新密码并记住它们感到厌烦。
经验显示，在使用了30天过期策略的安装中，90%以上的用户把他们的密码改成具有惊人的可预测性的（因而是可被入侵的）单词或者单词和数字的组合。
事实上，这常常发展到这种程度：
50%或者更多的用户使用相同的密码——他们都使用类似MMMYY的东西作为密码，其中MMM是月份，而YY是年份。
例如，在1996年一月，他们可能使用JAN96作为密码。
很快，这里的所有人都会做这样的事情。
我曾见过一些公司试图通过实施密码嗅探器（当要更改密码时，它会检查密码）来应对这种情况。
嗅探进程寻找混合了姓名或以月份前缀开头的密码。
这种机制再好，其作用也是很微弱的。
用户远比你想象的聪明。
多数用户大约用一星期就能规避第一个嗅探器——他们只不过把密码更改为以“X”为前缀，这样就能继续使用以前所用的MMMYY格式了。
简言之，嗅探器最终所起的作用微乎其微。
这里的实质问题并非要避免使用过期策略。
应当使密码过期的时间足够短，以获得合适的新旧更替并应对共享或窃取密码的情况，但是，又不能太频繁，否则会导致用户产生抗拒心理并开始使用弱密码。
我个人建议过期的时间要多于90天但少于180天。
22.1.3
密码长度和组成
在这一领域，应为SQLServer感到欢欣鼓舞。
在以前的版本中，如果使用SQLServer安全性，则实际上对这一方面做不了多少控制。
现在，能够让SQLServer使用Windows密码策略（可以通过Windows中的实用工具进行调整）。
1．密码长度
要知道，用户每在密码中包含进一个可能的字母数字位，可能的密码数量就将至少增加36倍（实际上，倘若包含特殊的字符则会更多一些，但是，在这里，即使36倍也足以说明问题）。
这意味着，对于一个字符的密码来说，仅有36种可能性，但两个字符的密码将有1296种可能性。
如果密码包含的字符数增加到3个，可能性将增长到46656。
当向密码中加入第4个字符时，可能性将超过一百万种。
随着要求密码包含的字符数越来越多，排列的方式也不断增加。
当然，如果处处都要求超过5或6个字符，那么，终端用户将产生极大的反感。
2．密码组成
是的，我已经指出过，如果要求使用至少4位字母数字的密码，则在这种情况下，将有超过百万种可能的密码组合。
其实，人们不会使用所有这些组合（他们将使用熟悉的单词或者名字），当你意识到这一点时，问题就来了。
考虑到一般人经常使用的单词只有5000个左右，因而对于想要入侵的人来说，并不需要尝试太多的单词即可得逞。
如果你实施的不是默认的Windows密码策略，那么，要考虑要求至少一个字符是字母的（不是数字，只是字母），同时，至少一个字符是数字的。
简单的数字（实际上，人们喜欢使用他们的社会安全号、电话号码或生日）以及完全的单词都很容易被猜到，这排除了这种可能性。
用户依然能够创建对于他们来说很容易记住的密码——如“77pizzas”，但是，这样的密码不可能从字典里找出。
为了尝试并入侵，任何黑客都不得不真正尝试每一种组合。
22.1.4
尝试登录的次数
无论物理上如何存储用户和密码信息，登录界面都应当与之有联系，从而限制某人尝试登录的次数。
当用户超过了登录限制时，做出反应的程度可以是不同的，但是，要确保有某种方法，让用程序的方式尝试所有密码的做法变得很困难。
只要允许的登录尝试的次数是比较小的数值，究竟允许多少次其实并不是那么重要——我通常使用3次，但是，我也在一些地方见过用4和5次的，而那样也是不错的。
如果执行的是Windows密码策略，那么SQLServer将相对于错误密码限制来检查登录尝试并强制该策略。
22.1.5
用户和密码信息的存储
显然，仅当你使用自己的安全系统而不是使用内置的Windows和（或）SQLServer安全系统时（但许多Web应用程序将会这样做），这才适用，而且，在大多数时候，如何存储用户配置和密码信息并不是什么高深的学问。
尽管如此，这里还是有几件事情需要考虑：
由于需要能在最初获得信息，你必须做如下三件事情之一：
编译密码到客户端应用程序或组件中（然后，确保在你安装应用程序的服务器上创建了正确的登录名和密码）。
利用SQLServer新的加密技术在数据库中加密和解密数据。
要求某种双密码的情形——一个让用户到达常规的密码信息，而另一个让用户到达真正的应用程序。
通常，迫使用户两次登录让人无法接受，因而，在大多数情况下，你会返回到其他两种选择之一。
如果处于要使用双密码的场景中，可能的话，将会想要把第一个登录的访问限制在只能执行存储过程上。
通过这样做，能够允许第一个登录获得其所需要的验证，但不会把任何东西暴露给试图通过ManagementStudio登录的任何人。
使你的存储过程（sproc）接受用户ID和密码，并且，只传回布尔值（能够登录真或假）或者传回一个记录集，记录集中列出了用户能够在客户端看到什么窗口和函数。
如果使用原始的SELECT语句，则无法对用户能够看到的事情进行限制。
我曾实现过的类似这种场景的方案是，用一个视图把当前SQLServer登录映射到其他登录信息。
在这种情况下，应用程序角色用来让应用程序获得对所有事情的完全访问权——应用程序必须知道用户能够和不能够做什么。
该存储过程如下所示：
如果你准备把密码信息存储在系统中——请加密密码！
！
这一点我无论强调多少次也不过分。
多数用户会把密码用在不止一件事情上——当需要记住的事情较少时，生活会容易得多。
通过在数据被放入到数据库中之前对数据进行加密，确保了没有人会知晓用户的密码信息——即使是偶然得到。
他们可能会看到它，但是，如果没有解密的密钥，他们所看到的没有任何用处。
22.2
安全性选项
就内置选项来说，关于如何在SQLServer中设置安全性的问题，你有两个选择。
Windows集成安全性——用户登录到Windows中而非SQLServer中。
身份验证是通过Windows以可信的连接来完成的。
标准的安全性——与登录到Windows中分离开，用户单独登录到SQLServer中。
身份验证是使用SQLServer来完成的。
我们来看看这两种选择。
22.2.1
SQLServer安全性
先从SQLServer的内置登录模式谈起。
在SQLServer2005中，这方面变得更加健壮。
尽管依然可以使用相对简单的模式，但是，现在你可以做大量其他的事情，以便增加服务器和数据库的安全。
在使用SQLServer安全性时，是完全脱离开网络登录信息来创建登录ID的。
使用SQLServer安全性的有利之处包括：
用户不必为了访问到系统而成为域用户；
更容易对用户信息进行程序化的控制。
一些不利之处是：
用户可能必须登录两次或者更多次——一次是登录到他们拥有访问权的网络中，而一次是针对用户从单独的应用程序所创建的每一个连接，登录到SQLServer中；
两次登录意味着DBA要做更多的维护；
如果需要多个密码，则它们很容易变得不一致，这会导致大量的登录失败和密码遗忘。
（这听上去耳熟吗，“现在我们来看看，哪一个密码才是用于这个登录的？
”）
用SQLServer安全性进行登录的一个例子是使用sa账户的情形，在本书的大部分地方可能都会使用该账户。
使用SQLServer安全性进行登录时，你是如何登录到网络中的并不重要，可以使用sa登录ID和单独的密码登录到SQLServer中（希望该密码设置得非常安全）。
实际上，从经常性看，你不会日复一日地以sa来登录。
为什么呢？
或许，只花一、两分钟想一想就能想出，当使用sa账户时，在纯粹意外的情况下能够发生多少可怕的事情。
使用sa意味着对任何事情都有完全的访问权，这就是说，当你在错误的数据库中执行DROPTABLE语句时，事实上，将按照你告知的那样去执行——删除那个表！
对此，你只剩下说“哎呀！
”了。
而你的老板可能会说出完全不同的事情。
即使你确实需要总是拥有完全访问权，也应该只用sa账户让你的用户账户成为sysadmins服务器角色中的一员。
那样做不仅赋予了你sa的权力，而且，单独的密码以及对当前是谁登录到系统中的审核跟踪（在跟踪工具Profiler中或者当查看系统活动时），使你获得了额外的安全性。
22.2.2
创建和管理登录
目前，要在SQLServer中创建登录名，有4种方式：
使用CREATELOGIN；
使用ManagementStudio；
SQL管理对象（SMO）；
使用一些其他的选项，这些选项完全是为了向后兼容性而保留下来的。
1．CREATELOGIN
CREATELOGIN是SQLServer2005中新增的语句，是微软为了让用来创建数据库和服务器对象的语法标准化所做的努力的一部分。
不赞成使用sp_addlogin，在以前的版本中，sp_addlogin是用来添加登录名的过程化的方式，它看起来类似我们多次在SQL中见过的CREATE<
object>
<
objecttype>
语法，只是这里有一些额外的选项要求，这些选项要求是我们在诸如存储过程见过的。
最基本的语法是很简单明了的，但是，这些选项能够如何混合在一起，这一点则可能有些难于理解。
整个语法如下所示：
CREATELOGIN<
登录名>
[
{WITH
PASSWORD='
<
密码>
'
[HASHED][MUST_CHANGE]
[,SID=<
SID>
|DEFAULT_DATABASE=<
数据库>
|DEFAULT_LANGUAGE=<
语言>
|CHECK_EXPIRATION={ON|OFF}
|CHECK_POLICY={ON|OFF}
[CREDENTIAL=<
凭据名>
[,...<
下一选项>
]]
}|
{FROM
WINDOWS
[WITHDEFAULT_DATABASE=<
]
|CERTIFICATE<
证书名>
|ASYMMETRICKEY<
不对称密钥名>
}
]
紧接着登录名后，是选择FROM子句还是选择WITH子句，这是决定整个事情基调的关键部分，因此，我们结合属于FROM或WITH子句的选项来查看这些内容。
●CREATELOGIN...WITH
WITH子句直接让你进入到与基于登录名的SQLServer身份验证有关的选项定义中，而非任何其他的验证方法。
当激活了SQLServer安全性（相对于只是Windows安全性）时，它才是有关联的。
这里的选项数量很多，看上去有些令人生畏，因此，把它们拆开来讲述。
这些选项中的大多数是真正全新的。
好吧，当然，你会说：
“我以为这整个命令都是新的？
”是的，它的确是新的，但是，CREATELOGIN...WITH本质上是CREATELOGIN中取代了旧的sp_addlogin的部分。
在SQLServer2005中，即使是针对基于SQLServer的安全性，我们也极大改进了安全性选项，这反映在CREATELOGIN...WITH中不存在于sp_addlogin里的选项上。
选
项
说
明
PASSWORD
显然，该选项正像它听上去那样。
这里要小心处理的地方是下面的问题：
密码是明文的（在这种情况下，SQLServer将在添加密码时对密码进行加密），还是已经经过散列运算（在这种情况下，需要提供HASHED关键字，后面将讲述该关键字）
HASHED
该选项跟在密码后面，并且，仅当密码已经经过散列运算（加密）时才使用它。
在那种情形下，SQLServer添加密码时不会再次对密码进行加密
MUST_CHANGE
这又是一个可以“顾名思义”的选项。
简言之，如果提供了该选项，那么，在用户首次登录时，将提示他们更改密码
SID
你可以手工指定SQLServer使用什么GUID来验证这一登录名。
如果未指定该选项（我认为这样做是一种极端的情况），则SQLServer将为你生成一个
DEFAULT_DATABASE
这是该用户每次登录时的当前数据库
DEFAULT_LANGUAGE
这是在给用户发送错误或者其他系统消息时所使用的语言
CHECK_EXPIRATION
设置SQLServer是否强制实施密码过期策略。
默认情况下，密码不会过期。
若将该选项设置为ON，将强制密码过期策略
CHECK_POLICY
设置SQLServer是否强制实施密码策略（长度、字符要求，等等）。
默认情况下，密码必须满足Windows密码策略。
如果把该选项设置为OFF，实际上将允许使用任何密码
CREDENTIAL
指定该登录名将映射到的凭据名称（关于这是什么的问题，在后面将有更多的了解）。
简言之，该选项把登录名映射到一组许可上，从而允许在SQLServer之外执行操作（如网络访问之类）
所有这些选项都可以不提供，并且，仅在使用HASHED和MUST_CHANGE时（如果要使用它们，必须跟随在PASSWORD选项之后使用），提供选项的顺序才是要紧的。
●CREATELOGIN...FROM
FROM子句表明，该登录名不是SQLServer专用的。
FROM子句指定登录名的来源。
来源分为几种不同的类别：
WINDOWS——在这种情况下，我们把登录名映射到现有的windows登录名或组上。
基本上，这是表示，“获取这个现有的Windows用户或组，并赋予它们访问SQLServer的权力。
”你可以把SQLServer登录名映射到Windows组上，这表明，将把到SQLServer的那种级别的访问授予该组中所有的成员。
实际上，这对于网络中的用户管理非常方便。
例如，如果想要会计部门中的所有人在SQLServer中都拥有一组特定的权力，可以创建一个名为Accounting的Windows组，并把该组映射到一个SQLServer登录名。
假如你新近雇用了某人，那么，一旦把他们加入到Accounting组中，他们不仅将获得Accounting组所拥有的Windows资源的访问权，而且，还将拥有Accounting组所拥有的所有SQLServer许可权限。
如果用Windows作为FROM的来源，那么，与基于SQLServer的登录名类似，你也可以提供一个WITH子句，只是这里局限于默认的数据库和语言。
CERTIFICATE——这种登录名是基于X.509证书的，你已经通过CREATECERTIFICATE命令将证书与服务器相关联。
可以用几种不同的方式来使用证书，但最终，在本质上，它们将作为已认可的安全加密密钥。
SQLServer有它自己的“证书颁发机构”，或者，也可以导入从其他的源产生的那些。
本质上，需要提供证书作为登录到SQLServer中的授权。
ASYMMETRICKEY——非对称密钥与证书只是同一概念的两种方式。
实质上，如果所给出的密钥是SQLServer信任的，则允
升级会员 