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

【问题标题】：When to use an application role in a database?何时在数据库中使用应用程序角色？
【发布时间】：2015-09-11 09:16:57
【问题描述】：

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

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

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

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

【问题讨论】：

标签： sql-server security roles

【解决方案1】：

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

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

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

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

但是通过应用程序还需要允许他插入/更新表。

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

（如果乔知道密码是什么，他实际上可以自己调用这个 sp……但他不应该知道）

应用程序会在前端进行一些验证，阻止他对数据做傻事。

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

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

一个数据库在 >1 个应用程序之间共享，并且
同一用户可能使用多个应用程序，并且
任一应用程序都有“特定于该应用程序”的数据，并且
授予用户访问该数据的权限是没有意义的（因为他们可能会从不同的应用程序中弄乱它），并且
为应用程序提供自己的登录名来维护该数据是没有意义的

注意：

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

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

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

【讨论】：