Microsoft® SQL Server™ 中的安全系统在最低级别,即数据库本身上实现。无论使用什么应用程序与 SQL Server 通讯,这都是控制用户活动的最佳方法。但是,有时必须自定义安全控制以适应个别应用程序的特殊需要,尤其是当处理复杂数据库和含有大表的数据库时。
此外,可能希望限制用户只能通过特定应用程序(例如使用 SQL 查询分析器或 Microsoft Excel)来访问数据或防止用户直接访问数据。限制用户的这种访问方式将禁止用户使用应用程序(如 SQL 查询分析器)连接到 SQL Server 实例并执行编写质量差的查询,以免对整个服务器的性能造成负面影响。
SQL Server 通过使用应用程序角色适应这些要求。应用程序角色与标准角色有以下区别:
应用程序角色不包含成员。
不能将 Microsoft Windows NT® 4.0 或 Windows® 2000 组、用户和角色添加到应用程序角色;当通过特定的应用程序为用户连接激活应用程序角色时,将获得该应用程序角色的权限。用户之所以与应用程序角色关联,是由于用户能够运行激活该角色的应用程序,而不是因为其是角色成员。
应用程序角色允许应用程序(而不是 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 实例。所有连接都使用同一登录,相关权限授予该登录。