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

Question

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

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

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

谢谢你提前！

Answer 1

根据用户对数据库的访问类型，你可能会寻找一个显著一场艰苦的战斗。你开始对中介分层额外的安全性之前，通过采取长期在深入了解您允许用户使用自己的凭据做什么开始：

1. 用户是否需要数据库机器上的用户帐户？如果可能，删除它们
2. 用户是否授予最小权限访问权限？使用您认为合适的任何机制尽可能多地删除用户[exec]权利。我在最后看到的一件事是存储了实际具有适当的执行权限的procs，并且用户只对proc具有exec权限。
3. 您是否删除了用户权限来运行任何表更改命令？包括运行系统存储过程的能力。这可以大幅减少事故（意外和恶意）
4. 用户是否可以直接访问原始业务数据？如果这样考虑将访问权限移入视图，并在表格上自行删除和删除用户权限。它也解决了一些维护难题
5. 你有审计吗？表级别或自定义。

如果你觉得你有一个坚实的设计，那么你可以开始寻找包装你的数据库在一个经纪人/外观访问。请注意，这在性能，部署和安全性方面可能很昂贵，并且不是一件容易的事情。关于模式的一些建议是：

1. 寻找到一个服务代理：WSO2例如，他们有其他可以用来隐藏关键业务应用程序（虽然其本意是要发布对它们的访问）提供缓存和代理服务。它可能会减少你的攻击面，但配置和管理很容易超过那里的任何收益。
2. 您可以推出自己的经纪商服务（基于WCF或类似的），以确保您充分考虑到负载和预计的增长，但如果您真的想要这样做并非不可能或甚至无法实现并有时间正确地设计出来。

Answer 2

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

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

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