Asp.net Intranet应用程序的数据库身份验证

我正在寻找一种针对数据库层的内部Web应用程序的端到端身份验证的最佳实践

我见过的最常见的场景是使用单个SQL帐户，并将权限设置为应用程序所需的权限。所有应用程序调用都使用此帐户。然后，当人们需要通过查询工具访问数据库或使用查询访问权限创建这样一个单独的组时，人们可以访问该组

我看到的另一个场景是使用完整的Windows端到端身份验证。因此，用户本身被添加到设置了所有权限的组中，以便用户能够在应用程序参数之外进行更新和更改。这通常涉及到将人们保护到适当的存储过程，这样他们就不会直接更新表

第一个场景似乎相对容易维护，但是如果应用程序中存在安全漏洞，那么整个数据库就会受到威胁，这会引起关注

---

第二种场景似乎更安全，但与之相反的是，在数据库的存储过程中必须包含大量的业务逻辑。这似乎限制了一些非常酷的技术的使用，比如Nhibernate和LINQ。然而，在这个时代，人们可以以我们无法预见的许多不同方式使用数据，例如混搭等，这是最好的方法。

就个人而言，我不希望数据库中有正常的最终用户。对于intranet应用程序（尤其是驻留在域上的应用程序），我将提供一个应用程序访问数据库的单一帐户，该帐户仅具有应用程序正常运行所需的权限

然后通过用户的域帐户控制对应用程序的访问（关闭IIS中的匿名访问等）

---

如果用户需要直接访问数据库，并且可以证明这一点，那么他们的域帐户将被授予访问数据库的权限，并且他们可以使用适当的工具登录到DBMS。

在过去一年中，我负责开发几个内部web应用程序

我们的解决方案是使用Windows身份验证（Active Directory或LDAP）

我们的目的仅仅是允许使用现有的公司ID/密码进行简单的登录。我们还希望确保现有部门仍将负责验证和管理访问权限

---

虽然我不能回答关于Nhibernate或LINQ的争论，除非你有一个特定的杀手特性，这些东西可以实现，Active Directory或LDAP的实现和维护非常简单，值得一试。

Stephen-让普通的最终用户远离数据库是件好事，但我想知道，在这个时代，这么多有经验的计算机用户从大学/学院出来，这条路是否正确。如果有人想自动化他们工作的一部分，包括对数据库的VBA更新，我允许他们通过正常的应用程序来完成，那么通过这种方式限制他们的访问，我们会失去收益吗

我想这里暗示的另一个途径是，您可以通过服务打开应用程序，然后通过组保护这些服务，并且仍然保持用户与数据库的分离

---

然后，根据乔纳森的帖子，通过授权，你可以允许部门通过小组控制对自己账户的访问。

我同意斯蒂芬·赖顿的观点。域安全是一条必由之路。如果您想使用mashup什么的，您可以通过机器可读的RESTful接口公开部分数据库。有一个。

戴尔-就是这样。如果您希望向这些用户提供对底层数据存储的访问，那么可以通过服务来实现。根据我的经验，大学毕业的那些有经验的电脑用户对事物的破坏最大。俗话说，他们知道的只是危险

如果他们想自动化部分工作，并且他们可以显示他们具备必要的知识，那么就继续，授予他们的域帐户对后端的访问权限。这样一来，他们通过小小的VBA自动化所做的任何事情都与他们的帐户相关联，当数据被冲洗时，你确切地知道该去看谁

我的基本观点是，数据库是众所周知的应用程序的圣杯。在那个馅饼上，你需要尽可能少的手指

作为一名顾问，每当我听到有人允许普通用户进入数据库时，我的眼睛都会亮起来，因为我知道当我接到电话修复数据库时，它最终会成为我的一大笔收入