安全的数据库连接。 DAL .net 架构最佳实践

Question

我们有多个应用程序安装在多个部门中，通过内联网与数据库进行交互。用户倾向于使用弱密码或将登录名/密码存储在一张纸上，让每个人都可以看到。我担心登录名/密码泄露&想要尽量减少后果。通过隐藏数据库服务器以防止 Intranet 访问来最小化数据库服务器的攻击面也是一个好主意。

我正在考虑基于中间数据访问服务方法的安全性。它似乎比基于表或基于连接的数据库服务器更灵活。这种方法还允许对公共 Intranet 隐藏数据库服务器。

您会建议哪种 .net 技术和最佳实践？

预先感谢您！

Answer 1

根据用户对数据库的访问类型，您可能会面临一场重大的艰苦战斗。在开始对中介层提供额外的安全性之前，首先要深入了解您允许用户使用其凭据执行的操作：

1. 用户在数据库计算机上是否拥有用户帐户？如果可能，请删除这些
2. 用户是否被授予了最低权限访问权限？使用您认为适当的任何机制尽可能多地删除用户 [exec] 权限。我在极端情况下看到的一件事是存储过程实际上具有适当的执行权限，而用户仅对过程具有执行权限。
3. 您是否删除了运行任何表更改命令的用户权限？包括运行系统存储过程的能力。这可以大大减少事件（意外和恶意）
4. 用户是否可以直接访问原始业务数据？如果是这样，请考虑将访问权限转移到视图和 sps 中，并删除表本身的用户权限。它还解决了一些维护难题。
5. 您是否进行了适当的审核？表级或自定义。

如果您觉得自己有一个可靠的设计，那么您可以开始考虑将数据库包装在代理/外观中以进行访问。请注意，这在性能、部署和安全性方面可能代价高昂，而且并不是一件容易做到的事情。关于此模式的一些建议：

1. 研究服务代理：WSO2 例如，它们是其他可以用于通过向关键业务应用程序提供缓存和代理服务来隐藏关键业务应用程序（尽管其目的是发布对它们的访问权限）。它可能会减少一些攻击面，但配置和管理将很容易抵消任何收益。
2. 您可以推出自己的代理服务（基于 WCF 等），您需要确保充分考虑负载和预计增长，但如果您真的想这样做并且拥有是时候正确设计它了。

Answer 2

我认为没有必要通过将数据库移动到外部网络来保护数据库。相反，您可以通过限制帐户本身的权限来解决这些做法。数据访问不应是特定于用户的，而应利用具有在 Web 或应用程序配置文件中配置的加密连接字符串的系统帐户。

用户身份验证和授权应与数据库访问分开处理。

系统数据库帐户本身应该仅具有执行操作系统所需任务的权限。这意味着仅授予对应用程序执行的过程的访问权限，并可能授予对通过 LINQ to SQL 读取的任何表或视图的读取访问权限。