对应用程序的每个用户使用不同的数据库帐户是否曾经是一种好习惯？

我曾经使用的应用程序是基于服务器的，并为多个用户使用一个数据库帐户，而应用程序代码控制用户或单用户的工作。

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

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

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

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

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

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

如果登录名和密码在客户端应用程序中，则可以对其进行黑客入侵。如果是域，则可以使用集成安全性。

在数据库中，您可以有很好的控件。但是行级控制有些麻烦。数据库不是业务规则的好工具。业务规则和详细的安全性通常在应用程序级别执行。

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

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

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

只有当您有直接连接到数据库的用户时，才应考虑让数据库管理安全性。这意味着它们将遍历您的应用程序，并且它不再能够独自实施安全性。这样做的好处是您可以更精细地定义安全性。缺点是管理用户及其权限的开销较高。

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

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

您应该尽快以最细化的级别开始实施安全性。角色在这方面有所帮助-让人们一次访问多个表并不是一场噩梦。

每个人的单一帐户在这里和其他地方都是一个很好的问题来源-“记录x被删除，我怎么知道是谁做的？” -答案是不能-没有个人账户和审计。

通过“审核”，我的意思是尽管对每个人都有一个很好的帐户，但这并不意味着您拥有真正的安全性。例如，如果删除了HR表中的一条记录，那么您所能知道的是，可以访问HR表的某人做到了-那就是人数的x。

您的系统中需要触发器来记录操作，以便能够跟踪执行操作X的个人级别（除非您拥有Oracle这样的RDBMS，可以将其自动化）。

无论如何，您都应该始终使安全性尽快地变得更细-使人们仅在“需要知道”的基础上访问表。而且，请始终包括对表进行操作的时间戳记-人们经常将其ID给其他人-如果您可以说：“吉米，您是办公室里唯一的17:49 ...”-再一次，这并不是铁定的，只是箭袋中的另一个箭头。

也许如果您给我们您的RDBMS，您可以获得与您的情况更具体/相关的建议？

是的。以一个强大的用户身份从应用程序连接到数据库违反了最小特权原则。这是大多数SQL注入攻击的根本原因。

通常出于无知，出于简单性或有时出于性能的考虑而执行此操作。

数据库通常是长期存在的，并且随着时间的推移同时被多个应用程序使用。您可以通过在数据库中而不是在多个应用程序上集中访问控制来节省资源。

您想选择一个支持行安全性，列安全性和模拟/代理身份验证的数据库服务器（该数据库服务器支持实际的数据库用户+连接池）

对于诸如Wordpress之类的基于“插件”的应用程序来说，这也将更加安全，在这种情况下，由于熟练的插件作者而很难避免SQL注入。每个插件都具有数据库登录名，而不是整个应用程序。