何时在数据库中使用应用程序角色？

Question

在SQL Server中选择数据库角色和应用程序角色时，我应该考虑哪些事项？

我理解每种类型的角色是如何工作的，但是我很难理解应用程序角色何时适合用于数据库角色。

到目前为止，我刚刚在我的应用程序中使用了数据库角色。我基本上为每个用户创建了一个帐户，然后使用GRANT语句将它们分配给他们需要访问的任何角色。有问题的应用程序只是一个简单的数据输入/报告应用程序。

使用应用程序角色会有什么好处吗？如果有，我该如何使用它们？具体来说，我如何确保给定用户无法访问他们无法访问的对象。我需要多个应用程序角色还是有其他方式？

Answer 1

应用程序角色的既定目的是将一组安全性附加到“应用程序”。这个想法是，只有应用程序知道授权密码，并且实际上是在其中定义的（以适当的混淆方式）

如果您的用户具有使用特定应用程序时需要不同安全级别的固定数据库安全级别，那么您可能希望使用应用程序角色。否则不要打扰

例如，Joe使用他的数据库凭据登录数据库，但应该只读取（不更改）表中的数据

Joe通过财务应用程序使用相同的数据库。应用程序碰巧使用相同的凭据（Joe）进行连接

然而，通过该应用程序，他还需要也允许插入/更新表。

在这种情况下，您将使用应用程序角色通过在应用程序中调用sp_setapprole来覆盖Joe的安全性

（如果他知道密码是什么，乔可以自己称之为sp ......但他不应该知道密码）

应用程序会在前端进行一些验证，阻止他对数据进行愚蠢的操作。

这是一个非常具体的案例。

Answer 2

通常，当我们创建应用程序角色时，它们适用于那些喜欢管理自己的安全性并希望独立于SQL Server安全性的应用程序，并且我们希望它们访问数据库中的某些表可能不是全部对象。这些是针对User来做一些事情的静态应用程序的，该用户将使用这些应用程序角色来更改数据库

Answer 3

应用程序角色在以下情况下很有用：

• 一个数据库在 >1 个应用程序之间共享，并且
• 同一用户可能使用 1 个以上的应用程序，并且
• 任一应用程序都具有“特定于该应用程序”的数据，并且
• 授予用户访问该数据的权限是没有意义的（因为他们可能会从不同的应用程序中处理这些数据），并且
• 让应用程序拥有自己的登录名来维护这些数据是没有意义的

注意：

• 上述情况只会出现在企业中，应用程序来来去去，但数据是永远的，并且使用数据库角色尽可能将访问控制决策“下推到数据库”。在这种情况下，根据一个人可以使用的应用程序“总结”一个人对数据的访问的策略是不够的。
• 旨在由不同应用程序根据用户身份访问的数据不会受到“应用程序角色”的保护。
• 为了维护自己的数据，为应用程序提供自己的登录信息几乎总是可以的。两个例外可能是： ** 其中审计或访问控制由数据库级触发器执行，这些触发器需要区分当前执行的应用程序角色和调用应用程序角色的用户；要么 ** 非常严格的安全策略不允许应用程序拥有自己的登录名，但只能在特定用户的更广泛上下文中在数据库中操作

在什么超现实的领域中需要应用程序角色？一个现代（2020 年）用例是存储 OAuth 令牌和刷新令牌。这些需要存储在数据库中，但“授权”已专门授予一个应用程序……而不是所有访问数据库的应用程序。为了允许应用管理自己的 app1.oauth_tokens 表，并且在用户通过其他应用访问数据库时不向用户授予对 app1.oauth_tokens 表的权限，应用角色是一种可能的策略。

遗憾的是，没有更好地考虑应用程序角色功能：表达访问控制会很好，例如：“A 组中的用户可以查看该数据；A 组中的用户从应用程序访问它X 可以另外修改它”。但这不是我们得到的:-(