保护SQL服务器的安全-用户识别的问题

在我们关于SQL服务器安全系列的这文章里，我们的目标是向你提供安全安装SQL服务器所需要的工具和信心，这样的话，你有价值的数据就会受到保护，避免无意或者有意的破坏或者窃取。在本文里，我们会深入一些基础的概念，在保护数据库安全的时候，你需要利用下面这些概念：登录、用户、角色，以及组。确定谁在请求访问数据或者SQL服务器里其他信息等看上去很简单的过程，都需要用到所有这些概念。

登录登录规定了哪些用户能够连接到安装好的SQL服务器上——这不是某个特定的数据库，而是而是整个服务器。登录有两种不同的形式：

Windows集成的登录，它会授权特定的Windows用户或者组使用它们的Windows信任书进行连接。
SQL服务器登录，它会授权用户使用由SQL服务器保存的用户名和密码进行连接。

你应该使用哪一种？
Windows集成登录肯定要比SQL服务器登录更加高效和更方便，因为用户只需要登录一次——在网络这一层。单独登录到服务器是没有必要的，因为SQL服务器会自动地处理（在后台）Windows登录，从而允许到服务器的访问。只有在服务器运行在Windows NT或者2000上的时候，对Windows登录的支持才有效；安装在Windows 98上的服务器必须要依赖SQL服务器登录。如果你正在运行Windows 2000，而且最终需要支持原有的应用程序，那么就要记住，SQL服务器登录只有在混合模式下才可用。

设计上的考虑在设计自己数据库的时候，你需要考虑登录的方法——而且要在你真正开始保证最终产品的安全之前。你应该知道服务器使用的是哪种授权方式。那些还在Window 98上使用服务器的人可能现在就要考虑升级，如果安全是一个很重要的问题的话；那样的话，他们就可以使用Windows集成的安全（策略）。

另外一个设计问题是知道谁拥有访问权，他们能够访问什么数据，以及他们是否能够对对象和数据进行更改。你不用真的列出其名字；你只需要利用工具有效地帮助用户就行了。最后，你应该使用系统的存储过程来管理安全。SQL服务器提供了两种存储过程，用于登录的管理：

[i]sp_addlogi——在使用SQL服务器验证保护你服务器安全的时候要使用这个存储过程。具体的说，这个存储过程会创建一个新的SQL服务器登录，它允许用户使用SQL服务器验证连接到SQL服务器的实例上。
[i]sp_grantlogin——这个存储过程允许Windows 2000的用户或者组帐号使用Windows验证连接到微软的SQL服务器上。

只有sysadmin或者securityadmin固有服务器角色的成员能够执行这两个存储过程。