在Server中应用程序角色而不是Server身份验证的好处是什么？

Question

我有一个应用程序使用的数据库。这个应用程序实现了所有的业务逻辑，并控制用户可以根据其特权所做的事情。

我希望避免用户可以使用Management等其他应用程序访问数据库，因此我已经读到，我可以使用应用程序角色只允许应用程序访问数据库。

这似乎是一个很好的选择，但是它需要在客户端应用程序中存储密码，所以我有一个如何保护这个密码的问题。

如果我使用Server身份验证，也会出现同样的问题。如果我使用Server身份验证，我可以创建一个带有密码的用户MyApplication，在如何存储密码方面也会遇到同样的问题。但在实践中，我认为我拥有与应用程序角色相同的功能，我有一个用户的凭据，没有人知道与数据库交互所需的权限，是应用程序控制了用户可以执行的操作。

总之，使用应用程序角色而不是Server身份验证的优势是什么？

Answer 1

戴维斯指出了一个很好的答案，我只是从一个稍微不同的角度发帖：

您是否需要跟踪谁在做什么，使用Server意味着什么？或者谁是目前的连接者？

如果你100%确定你没有，那么让所有的用户使用相同的登录是可以的。

如果这一需求现在存在，或者可能在不久的将来存在，那么您应该为拥有单独登录的用户进行计划。这可以是每个具有不同SQL登录名的用户(管理起来并不有趣)，也可能是所有具有登录名的用户，这是AD中的Windows组。

现在你有了可追踪性。

如果您对上面的内容感到不舒服，让某人使用SSMS进行连接，并使用分配给上述登录/用户的权限，则应用程序角色可能适合您。

使用相同的(个人)登录，因此存在可追溯性。但是应用程序调用sp_setapprole传递密码，基本上用户上下文切换为应用角色的上下文(如果愿意，可以将应用角色看作用户)。您可能会这样做，以便应用程序角色的用户上下文比“终端用户登录”所连接的用户上下文具有更高的权限。

现在，您必须考虑密码管理。如果您有一个胖客户端，那么密码需要以某种形式从机器上访问。它可能是加密的，但密钥需要你的应用程序访问，并通过它你的最终用户。也就是说，你的最终用户可能很难获得应用角色的密码，但在技术上并不是不可能的。

如果您有一个应用服务器，那么当然，应用程序角色密码对于最终用户来说是遥不可及的。