将应用程序最终用户映射到数据库用户的每种方法的优点是什么?

除了更简单的管理之外,选项3在web服务器上还有性能优势;这允许连接池-即少量物理数据库连接可以连续重复使用,以服务大量应用程序用户。这被称为 trusted subsystem USER_NAME() , SUSER_SNAME() 不再有用)-当然,这相对容易被欺骗。

它们之间的“每个角色”选项站点-但是角色之间真正互斥的情况很少,这使得这一点很难实现。

对于直接与数据库对话的客户端应用程序,选项1是最容易维护的,因为您不需要向客户端分发任何特殊帐户详细信息。池也不是问题,因为客户端的机器只充当1个用户。

N到1映射 被广泛使用可能是因为,

1. 在传统的软件开发中,数据库被认为仅仅是一个存储库,而不是其他存储库。

2. 程序员将数据库视为一个黑箱,访问权限被视为一次性活动。

3. 程序员乐于调试代码并解决问题,而不是担心数据库级别的安全角色定义和维护。

4. 在一个典型的应用程序中,如果有一个“用户/角色维护”屏幕提供给管理员用户,则很容易使用诸如用户、安全角色、用户安全角色等表来维护应用程序用户信息,而不是在数据库本身中创建用户、安全条目。

5. 如果业务模型中没有定义良好的角色(双重角色、可自定义的访问权限等),则很容易在应用程序级别而不是数据库级别实现安全性。

通过这种方式,您可以在DB上的权限较低(表访问方面)的帐户下运行面向Internet的应用程序服务器,并且内部用户可以使用其他访问权限访问单独的服务器。优点是,即使面向Internet的路由被完全破坏,它仍然没有权限处理内部用户需要访问的表。

如果您的身份验证系统支持委派(例如Windows身份验证、Kerberos),则选项1和2可以很好地工作,因为这样应用程序服务器就不需要保存或存储自己的凭据,只需模拟客户端即可。事实上,这比选项3要好得多(因为如果服务器受损,攻击者只能使用当前连接用户的权限,他们无法访问整个数据库)。但是,您很少有能力使用此功能。

编辑:所有这些选项都不妨碍您在应用层中对业务逻辑进行进一步的访问控制,因此,正如一些答案所建议的那样,说这是选项3的优势是不正确的。在所有情况下,应用层仍然知道其客户机是谁。

我更喜欢对应用程序的所有最终用户使用相同的db帐户,并在db之外实现应用程序角色和权限。

显然,对于一个用户可以自己注册的web应用程序来说,1)是不实用的。我有一个50万或更多用户的网站-我会想要那么多数据库帐户吗?我不这么认为!

在模式修改的开发过程中使用一个单独的帐户,该帐户具有必要的权限。

对于大多数应用程序来说,这似乎是最明智的#2.我觉得好像不对。在这种情况下,我会有组,用户可以加入到一个组中。

这一问题是“集成安全”这一术语引发的一种常见误解的结果,这种误解最终只意味着“单一登录”(即用户验证),也许还可以在AD中创建另一组角色和组,这样AD管理员就可以被分配数据库安全的责任——这通常不是他们训练有素的工作,尽管我相信也有例外。

Is SQL Server/Windows integrated security good for anything? .

我不知道Oracle的情况,但在SQL Server中,您希望共享连接,最好的方法是让单个用户连接。每个differant用户使用不同的连接字符串,这可能会降低速度,因为现有连接不能被池化并重新用于differant用户。

如果你正在做一个NTEIR应用程序,你的安全逻辑应该在中间TEIR。您不希望每次要检查某人是否具有某个区域的权限时都必须返回数据库。大多数应用程序中的权限通常比数据库安全性提供的权限更具体。