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

Question

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

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

您会建议什么样的 .net 技术和最佳实践？

提前感谢您！

Answer 1

根据您的用户对数据库的访问类型，您可能会面临一场重大的艰苦战斗。在开始对中介进行额外的安全保护之前，首先要深入了解您允许用户使用他们的凭据做什么：

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

如果您觉得那里的设计可靠，那么您可以开始考虑将您的数据库封装在代理/外观中以供访问。请注意，这在性能、部署和安全性方面可能代价高昂，而且不是一件容易的事。对此模式的一些建议：

1. 查看服务代理：例如WSO2，它们是其他可用于通过向它们提供缓存和代理服务来隐藏关键业务应用程序（尽管其目的是发布对它们的访问权限）的方法。它可能会在一定程度上减少您的攻击面，但配置和管理很容易超过那里的任何收益。
2. 您可以推出自己的代理服务（基于 WCF 等），您需要确保充分考虑负载和预计的增长，但如果您真的想这样做，这并非不可能，甚至无法实现并有时间正确设计它。

Answer 2

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

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

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