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

Question

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

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

您建议使用哪种.net技术和最佳做法？

提前谢谢你！

Answer 1

根据用户对数据库的访问类型，您可能会看到一场重大的艰难战斗。在开始为中介机构添加额外的安全性之前，首先要深入了解您允许用户使用其凭据的内容：

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

如果您觉得自己的设计非常扎实，那么您可以开始考虑将数据库包装在代理/外观中以便访问。请注意，这在性能，部署和安全性方面可能成本很高，并且不是一件容易的事情。关于模式的一些建议：

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

Answer 2

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

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

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