3

使用 SQL Server 应用程序角色管理权限与使用标准登录名/用户并向所述用户授予必要权限相比有什么优势？

我们一直在使用需要以下场景的应用程序角色：

  1. 使用 SQL Server 登录名和密码连接到 SQL Server。
  2. 通过将角色名称和另一个密码传递给 sp_setapprole 来激活应用程序角色。

我看不出这比仅将应用程序角色的权限授予登录名/用户更好或更安全。应用程序必须可以使用这两个密码，并且任何可以访问登录密码的人都可以访问应用程序角色密码并从他们自己的程序或 SSMS 中调用 sp_setapprole。对？

编辑：正如 Ed Harper 推测的那样，应用程序的所有实例在我的场景中都使用相同的登录名。

4

3 回答 3

5

我从未使用过应用程序角色 ( CREATE APPLICATION ROLE)。
我真的看不出他们的意义

我使用了数据库角色并将用户添加为成员

CREATE ROLE WebUsers AUTHORIZATION dbo;
ALTER ROLE WebUsers ADD MEMBER Tom;
ALTER ROLE WebUsers ADD MEMBER Dick;
ALTER ROLE WebUsers ADD MEMBER Harry;

CREATE ROLE WebAdmins AUTHORIZATION dbo;
ALTER ROLE WebAdmins ADD MEMBER Tom;

角色有权限，而不是用户

GRANT EXEC TO WebAdmins;

GRANT EXEC On SCHEMA::WebCode TO WebAdmins;
于 2016-04-07T13:50:42.393 回答
4

从您的描述中并不完全清楚，但听起来您可能正在使用在应用程序级别分配的 SQL 登录名 - 即应用程序的所有实例（假设有多个实例）使用相同的登录名/密码。在这种情况下，使用应用程序角色几乎没有什么价值。

据我了解，应用程序角色旨在用于每个用户在 SQL Server 中都有自己的登录名的情况（可能在 AD 身份验证授予对数据库的访问权限的情况下），但您不想授予用户相同的权限作为他们使用的应用程序的权利；这假设应用程序使用 AD 用户的身份连接到数据库，然后使用sp_setapprole. 我从未见过在生产系统中使用过这种方法。

于 2016-04-07T14:35:03.007 回答
0

使用常规登录，您的凭据和密码可能会在网络上传递。如果密码也保存在数据库中，则可以在数据库中完成应用程序角色切换。

于 2018-12-11T18:11:52.777 回答