关于应用程序层和数据库层之间身份验证的意见答案

【问题标题】：Opinions about authentication between application and database tiers关于应用程序层和数据库层之间身份验证的意见
【发布时间】：2011-11-21 16:19:21
【问题描述】：

我对一个技术难题感到困惑，我们团队中的两个人推荐两种不同的安全模型，每种模型各有利弊。

绿地看起来像这样：我们有一个 asp.net Web 应用程序，与业务层、数据库通信。

*其中一个要求是能够让更高级别的用户将业务层权限委托给其他用户。

其中一个人正在游说互联网用户能够将他们的凭据一直传递到数据库中，以便连接可以使用实际的 sqlserver 帐户进行查询等。（我喜欢这方面的某些方面 - 审计例如能力）

现有的替代方法是简单地使用数据库中的用户、密码、角色、资源表套件，并在业务层中管理安全性。

这可能是因为我从 java 到 oracle 背景，在大多数情况下，您使用的连接池提供已经使用服务类型帐户进行身份验证的连接。我们的互联网客户从来没有实际的数据库帐户。

我认为在 mssql 服务器提供的内置内部凭据存储中管理可委派的安全性（由互联网用户）似乎充满了安全隐患？

大家有什么推荐的吗？

【问题讨论】：

【解决方案1】：

在大多数 Web 应用程序中，您的安全模型是在业务逻辑层而不是数据层定义的。

例如，我在 Stack Overflow 上编辑帖子的能力不受我对“帖子”表的读取/写入能力的控制 - 事实上，您甚至可能无法设计一个允许您实现的数据库架构此级别的数据库级别安全性。相反，有一个业务逻辑层将我的权限与我试图采取的行动进行比较（我假设）；安全性在业务逻辑层实现。

坦率地说，我认为将凭据传递给数据库层几乎没有任何好处——如果我绕过了控制谁可以编辑 SO 帖子的业务逻辑，数据库“读/写”控件不会阻止它，并且审核不会真正帮助您。

我看到很多缺点 - 尤其是您将授权逻辑分成两部分（业务逻辑和数据库），并引入各种有趣的失败模式，在业务逻辑层和数据库层同步帐户（用户更改密码或离开网站）。我无法开始想象您将如何明智地测试和调试所有这些 - 如果最终用户收到与他们的数据库权限相关的错误会发生什么？

【讨论】：

【解决方案2】：

您可以拥有多少潜在用户以及这些用户中有多少可以同时活跃？

例如，如果您有 100,000 个用户，并且可以同时在线数千个，那么您将需要打开 1000 个数据库连接来为所有用户提供服务，因为每个用户只能使用自己的连接。为每个事务设置和断开连接非常昂贵，并且会使应用程序变慢。

就我个人而言，我会选择一个连接池，并且不会为每个互联网用户提供一个数据库用户帐户。这就是通常构建 Web 应用程序的方式。

像 Oracle Fine Grained Access Control 之类的东西可能会给你一个安全的中间立场，你可以在会话中设置“互联网用户”，然后数据库确保互联网用户只能根据规则访问允许访问的内容数据库。

【讨论】：