为应用程序的每个用户使用不同的数据库帐户是一种很好的做法吗？

Question

我习惯使用的应用程序是基于服务器的，并为许多用户使用一个数据库帐户，应用程序代码控制用户可以做什么，或者是单用户。

是否有任何成功的复杂业务应用程序，其中每个人都需要自己的数据库帐户，并且依赖数据库服务器来强制执行有关每个用户应该允许和不允许做什么的策略规则？

我正在考虑多个人为一个数据库中的信息做出贡献的应用程序，并且可以访问其他人存储的信息 - 例如，组织中的同事都需要访问客户记录。

还有这种类型的设置的名称吗？

Answer 1

如果您需要在数据级别实施非常严格的控制。例如广泛的审计。如果多个用户共享同一个帐户，则审计效果不佳。如果您有一些用户需要直接访问数据数据库。

如果安全性如此严格，您通常甚至不会直接公开数据库。你有一个服务，客户端必须从服务中获取数据。

在 Web 应用程序中，数据库（例如端口 1433）通常不会直接暴露，因此您具有一定的安全级别。即使 Web 应用程序直接访问数据库，用户仍然无法直接访问数据库。

如果登录名和密码在客户端应用程序中，那么它可能会被黑客入侵。如果一个域可以使用集成安全。

在数据库中，您可以进行非常精细的控制。但是行级控制需要一些工作。数据库不是业务规则的好工具。业务规则和详细的安全性通常在应用程序级别实施。

您可以使用混合模式，其中有一些由管理员使用的存储过程，并且您想要跟踪哪个管理员。您可以为直接生成报告的用户授予只读访问权限。

Answer 2

这里的挑战是您的数据库访问是由抽象管理的。他们不是作为自己连接的用户，而是本质上承担某些通用应用程序角色的身份。您不仅失去了对个人连接的可见性，而且失去了为所有个人用户定义不同类型访问的粒度。

使用这种方法的主要原因是简单。许多应用程序的设计使得应用程序的用户不了解数据库。他们真的不需要它，特别是如果应用程序管理自己的内部安全。大多数个人用户永远不会直接连接到数据库，因此没有必要为他们定义显式登录。

您应该考虑让数据库管理您的安全性的唯一时间是如果您的用户将直接连接到您的数据库。这意味着它们正在绕过您的应用程序，并且它无法再自行实施安全性。这里的优点是您可以更细化地定义安全性。缺点是管理用户及其权限的开销较高。

如果您确实需要这种访问权限，则希望使用基于角色的访问控制。您应该根据数据库中所需的权限类型定义角色，然后将各个用户分组到这些角色下。这使您可以更好地审核和控制您的安全模型，在管理直接访问时可能会迅速失控。

对此有一种混合方法。如果您希望数据库部分管理您的安全性，您可以创建多个应用程序用户，每个用户由他们的角色定义，并根据他们履行的角色明确授予这些用户访问权限。这意味着您可以将数据库引擎用于您的某些安全模型，但您仍然必须在应用程序中进行一些管理。它增加了应用程序用户模型的复杂性，但为您提供了更精细的使用中不同登录的粒度。