SQL Server建立应用程序安全性和程序角色

　Microsoft® SQL Server™ 中的安全系统在最低级别，即数据库本身上实现。无论使用什么应用程序与 SQL Server 通讯，这都是控制用户活动的最佳方法。但是，有时必须自定义安全控制以适应个别应用程序的特殊需要，尤其是当处理复杂数据库和含有大表的数据库时。

　　此外，可能希望限制用户只能通过特定应用程序(例如使用 SQL 查询分析器或 Microsoft Excel)来访问数据或防止用户直接访问数据。限制用户的这种访问方式将禁止用户使用应用程序(如 SQL 查询分析器)连接到 SQL Server 实例并执行编写质量差的查询，以免对整个服务器的性能造成负面影响。

　　SQL Server 通过使用应用程序角色适应这些要求。应用程序角色与标准角色有以下区别：

　　◆应用程序角色不包含成员。

　　不能将 Microsoft Windows NT® 4.0 或 Windows® 2000 组、用户和角色添加到应用程序角色;当通过特定的应用程序为用户连接激活应用程序角色时，将获得该应用程序角色的权限。用户之所以与应用程序角色关联，是由于用户能够运行激活该角色的应用程序，而不是因为其是角色成员。

　　◆默认情况下，应用程序角色是非活动的，需要用密码激活。

　　◆应用程序角色不使用标准权限。

　　当一个应用程序角色被该应用程序激活以用于连接时，连接会在连接期间永久地失去数据库中所有用来登录的权限、用户帐户、其它组或数据库角色。连接获得与数据库的应用程序角色相关联的权限，应用程序角色存在于该数据库中。因为应用程序角色只能应用于它们所存在的数据库中，所以连接只能通过授予其它数据库中 guest 用户帐户的权限，获得对另一个数据库的访问。因此，如果数据库中没有 guest 用户帐户，则连接无法获得对该数据库的访问。如果 guest 用户帐户确实存在于数据库中，但是访问对象的权限没有显式地授予 guest，则无论是谁创建了对象，连接都不能访问该对象。用户从应用程序角色中获得的权限一直有效，直到连接从 SQL Server 退出为止。

　　若要确保可以执行应用程序的所有函数，连接必须在连接期间失去应用于登录和用户帐户或所有数据库中的其它组或数据库角色的默认权限，并获得与应用程序角色相关联的权限。例如，如果应用程序必须访问通常拒绝用户访问的表，则应废除对该用户拒绝的访问权限，以使用户能够成功使用该应用程序。应用程序角色通过临时挂起用户的默认权限并只对他们指派应用程序角色的权限而克服任何与用户的默认权限发生的冲突。

　　应用程序角色允许应用程序(而不是 SQL Server)接管验证用户身份的责任。但是，SQL Server 在应用程序访问数据库时仍需对其进行验证，因此应用程序必须提供密码，因为没有其它方法可以验证应用程序。

　　如果不需要对数据库进行特殊访问，则不需要授予用户和 Windows NT 4.0 或 Windows 2000 组任何权限，因为所有权限都可以由它们用来访问数据库的应用程序指派。在这种环境下，假设对应用程序的访问是安全的，则在系统范围内统一使用指派给应用程序角色的密码是可能的。

　　有几个选项可用于管理应用程序角色密码而无须将其硬编码到应用程序中。例如，可以使用存储在注册表(或 SQL Server 数据库)中的加密键，只有应用程序有加密键的解密代码。应用程序读取键，对其进行解密，并使用其值设置应用程序角色。如果使用多协议 Net-Library，则含有密码的网络数据包也可以被加密。另外，当角色被激活时，可以在发送到 SQL Server 实例前将密码加密。

　　如果应用程序用户使用 Windows 身份验证模式连接到 SQL Server 实例，则在使用应用程序时，可以使用应用程序角色设置 Windows NT 4.0 或 Windows 2000 用户在数据库中拥有的权限。这种方法使得当用户使用应用程序时，对用户帐户的 Windows NT 4.0 或 Windows 2000 审核及对用户权限的控制容易维护。

　　如果使用 SQL Server 身份验证，并且不要求审核用户在数据库中的访问，则应用程序可以更容易地使用预定义的 SQL Server 登录连接到 SQL Server 实例。例如，订单输入应用程序验证运行该应用程序的用户，然后用相同的 OrderEntry 登录连接到 SQL Server 实例。所有连接都使用同一登录，相关权限授予该登录。

　　说明 应用程序角色可以和两种身份验证模式一起使用。

　　示例

　　作为应用程序角色使用的示例，假设用户 Sue 运行销售应用程序，该应用程序要求在数据库 Sales 中的表 Products 和 Orders 上有 SELECT、UPDATE 和 INSERT 权限，但她在使用 SQL 查询分析器或任何其它工具访问 Products 或 Orders 表时不应有 SELECT、INSERT 或 UPDATE 权限。若要确保如此，可以创建一个拒绝 Products 和 Orders 表上的 SELECT、INSERT 或 UPDATE 权限的用户-数据库角色，然后将 Sue 添加为该数据库角色的成员。接着在 Sales 数据库中创建带有 Products 和 Orders 表上的 SELECT、INSERT 和 UPDATE 权限的应用程序角色。当应用程序运行时，它通过使用 sp_setapprole 提供密码激活应用程序，并获得访问 Products 和 Orders 表的权限。如果 Sue 尝试使用除该应用程序外的任何其它工具登录到 SQL Server 实例，则将无法访问 Products 或 Orders 表。

查看本文来源