SQL Server 2005安全性.docVIP

SQL Server 2005安全性 IT Tech 2008-07-17 15:59:37 阅读356 评论0 ??字号：大中小?订阅 关于安全性首先要理解的一点是，没有彻底安全的应用程序。如果你能够让应用程序安全，就必定在某处有某人能挫败你的努力并“偷偷潜入”系统中。然而，即便有这样的认识，为了把讨厌的入侵者阻挡在系统之外，依然要努力实现这一目标。好消息是，大多数情况下，你能够很容易地让事情变得十分费劲，以致99.999％的人不想为此劳神。至于另外的那0.001%的人，我只能鼓励你去确信你所有的雇员都热爱生活，这使得他们属于99.999％的那类人。这0.001%的人有望访问到其他一些地方。 在SQL Server 2005中，微软对于SQL Server的安全性非常重视。这里有大量的新特性，并且，尽管以前已经有专门针对SQL Server安全性的书籍，但是现在，我可以想见，它们将是更加庞大的长篇大论——在这个版本中，该主题的内容大大增加了。 本章中，我们将讲述下面的内容： l??? 安全性基础； l??? SQL Server安全性选项； l??? 数据库和服务器角色； l??? 应用程序角色； l??? 凭据； l??? 模式管理； l??? XML集成安全性问题； l??? 更高级的安全性。 我们将发现，这里有大量不同的方法来处理安全性问题。安全性不仅仅是给某人一个用户ID和密码——你会看到有许多问题需要考虑。 在开始本章的任何示例之前，需要载入并执行名为NorthwindSecure.sql脚本。这个脚本会创建一个特别的数据库，我们将在本章使用该数据库。可以从本书的网站下载学习所需要的东西。 是的，为了运行本章的示例，我不得不让你创建一个工作数据库——很抱歉。这里将使用的是旧的Northwind数据库，只不过要删除所有对权限的修改。我们将在整个这一章中使用的NorthwindSecure数据库，它是一种更典型的数据库场景——即是说，除了随着创建表和对象自然带来的权限外，绝对没有添加任何权限（即没有）。随着本章讲述的深入，我们将学习如何处理权限，以及如何明确添加想要的权限。 22.1? 安全性基础 我相信，就我们将在本节中查看的内容而言，有相当一部分似乎极为愚蠢——我的意思是，这些东西难道不是尽人皆知的吗？然而，即便是这些规则中最简单的一个，违背它的情形也屡屡发生，从这些频繁发生的对规则的违反来判断，我要说，“不，显然它们不是。”所有我能做的就是请你耐心一些，不要跳过这里的内容。这里的某些内容看起来似乎很显而易见，但令人吃惊的是，它们常常被忘记或者被忽略。 在种种基础知识中，这里要讨论的是： l??? 一个人，一个登录名，一个密码； l??? 密码过期； l??? 密码长度和组成； l??? 尝试登录的次数； l??? 用户ID和密码信息的存储。 22.1.1? 一个人，一个登录名，一个密码 不断让我感到震惊的事情是，无论我到哪里，几乎总能发现机构中至少有一个“全局的”用户——网络或者特定的应用程序中的某个登录，该登录经常被部门或者甚至整个公司里几乎所有的人所知道。通常，这个“全局的”用户拥有全权的（换言之，完全的）访问权。对于SQL Server来说，安装甚至不把sa的密码设置为非空白的密码，这在过去是很平常的。 在SQL Server 2000之前，sa账户的默认密码是空密码——即是说，它没有密码。谢天谢地，SQL Server 2000不仅改变了这种默认情况，而且，现在SQL Server还会预先告知，如果你坚持让该密码为空白，那你一定是不折不扣的白痴——这对开发团队十分有益。需要当心的事情是，在进行开发时，还是会将它设置得很“简便”，这确实是很普遍的现象。在投入生产之前，你还必须记住对它进行修改，或者，如果开发服务器将直接暴露在因特网上或暴露给其他不可信的访问，则必须从一开始就将它设置得很困难。 即使现在，当多数的安装都的确有了非空的密码时，许多人知道密码是什么的情形也极为普遍。 那么，第一个基础知识是，如果所有的人都能访问某个用户ID，则该用户ID本质上是匿名的（如果所有的人都知道它，则任何人都有可能使用它），并且能访问任何事情，那么，你已经彻底击败了你的安全模型。同样，如果给每一个用户一个在所有事情上拥有完全访问权限的登录名，则也已经严重破坏了安全前景。剩下的唯一真正的好处是，对于任何时刻谁有关联的问题，能够说出显著的人（假设他们确实使用了他们个人的登录名，而不是使用全局的登录名）。 应当把拥有全权访问权限的用户限制为仅仅一、两个人。理想的情况是，如果需要这种全权访问的密码，那么，你会想要不同的登录名各自拥有这样的访问权，而对于每一个登录名来说，只会有一个人知道其密码。 你将发现，用户常常与其他人共享他们