关于应用程序层和数据库层之间认证的意见

Question

我对技术困境感到困惑，我们团队中的两个人推荐两种不同的安全模型，每种安全模型都有优缺点。

Greenfield看起来像这样： 我们有一个asp.net web应用程序，与业务层交谈，与数据库交谈。

*要求之一就是能有更高层次的用户委托业务层的权利给其他用户。

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

的另一种方法上的手是简单地与用户，密码，角色，资源数据库中的表浴室去，在业务层管理安全起来。

这可能是因为我来自一个Java到在大多数情况下，你使用连接池，提供其使用的服务类型的帐户已经验证连接Oracle后台。我们的互联网客户从来没有实际的数据库帐户。

我在我的思想是有缺陷的管理里面内置安全可委托（网民），内部凭证商店MSSQL服务器提供，似乎充满了危险的安全性是否明智？

任何人有任何建议吗？

Answer 1

在大多数Web应用程序中，安全模型是在业务逻辑层定义的，而不是数据层。例如，我在Stack Overflow上编辑帖子的能力不受我读写“posts”表的能力的控制 - 事实上，你甚至可能甚至不能设计一个数据库模式来允许你在此级别实施数据库级别的安全性。相反，有一个业务逻辑层将我的特权与我试图采取的行动（我假设）进行比较;安全性是在业务逻辑层实现的。我很坦率地认为将凭证传递给数据库层几乎没有任何好处 - 如果我以某种方式绕过了控制谁可以编辑SO帖子的业务逻辑，那么数据库“读/写”控件不会阻止它，和审计不会真的帮助你。

我看到了很多缺点 - 尤其是将您的授权逻辑分为两个（业务逻辑和数据库）的事实，并且介绍了各种令人愉快的故障模式，以便在业务逻辑层和数据库层同步帐户（用户更改密码或离开网站）。我无法想象如何对所有这些进行合理的测试和调试 - 如果最终用户获得与其数据库特权相关的错误，会发生什么情况？

Answer 2

您可能拥有哪些潜在用户以及这些用户可能同时处于活动状态？

举例来说，如果你有10万个用户，还有数千一次可以一直在线，那么你将需要开放为他们提供服务的所有数据库连接的1000的，因为每个用户只能使用自己的连接。为每个事务设置和拆除连接非常昂贵，并且会使应用程序变慢。

就我个人而言，我会去连接池，并且每个Internet用户都没有数据库用户帐户。这就是通常构建Web应用程序的方式。

像Oracle细粒度访问控制这样的东西可能会给您一个安全的中间地带，您可以在会话中设置“互联网用户”，然后数据库确保互联网用户只能访问允许基于规则的内容在数据库中。