我希望获得一些关于我为我的应用程序提出的安全模型的最佳实践反馈。我正在一头扎进使用 Amazon 的 RDS 将 Microsoft Access 前端/后端升级到 .NET WinForms/SQL Server。应用程序将是多用户、多站点(不同域)并包含敏感的健康信息。
这是两周研究的总结:
使用混合身份验证和 SSL 存储在应用程序中的加密连接字符串。不太理想，但我想我已经找到了一种方法，如果连接字符串被盗，它也可以正常工作(参见下面的#5)。
SQL Server 仅接受来自选定 IP 地址的连接(全部都是静态的)。
分配给一个仅具有执行权限的 SQL Server 用户的应用程序连接字符串。所有数据库交互都将使用过程完成。架构权限用于限制应用程序用户只能执行某些过程。
具有 SHA 256 加盐和散列密码的用户表。这提供了第一层应用程序安全性。
这是我不确定的部分:只有当查找作为 exec 变量之一发送的用户名和密码的 IF 语句 = True 时，每个过程才会完全执行。 UN/PW 将在应用程序的每个 session 中临时存储。我的理由是，这可以防止使用连接字符串从允许的 IP 地址登录的用户在没有有效密码的情况下获取/更改任何数据。
使用 AES_256 对称 key 加密的敏感列，并使用数据库主 key 通过证书加密。应用程序用户有权使用对称 key 和证书。
用户密码必须遵循规则(长度、大小写混合、特殊字符)。
任何人都可以看到其中的任何漏洞或有好的替代方案吗？ #5 是否解决了 Windows 应用程序无法使用 Windows 身份验证所存在的固有连接字符串安全漏洞？
最佳答案
总的来说，你的设计给我的印象是试图通过 self 复制来复制内置功能(身份验证、授权、权限控制)，只是因为你不信任内置功能。
使用 SQL 用户/密码进行身份验证/授权。不要构建用户和哈希表。不要在每个执行请求中发送用户和密码(!)。
使用 SQL Server 权限进行访问控制。使用代码签名对执行进行精细控制(签名过程)。不要尝试构建并行、重复的访问控制基础设施，不要为每个 session 存储临时用户/密码。
使用AWS防火墙基础设施来控制访问IP。不要重新发明你自己的。
如果您使用列级加密，请了解您要防范的内容以及您的目标是什么。介质意外丢失？然后使用数据库主 key 进行加密(即穷人的 TDE)。数据保密？然后让用户在每个 session 中输入证书解密密码。
solve the inherent connection string security holes
让用户在启动应用程序时输入密码，这样您就不会在静态文件 (.config) 中暴露密码。这里的所有都是它的。 SQL Server 早已停止在线交换 SQL 身份验证的密码。
关于.net - 使用 Amazon RDS SQL Server 的 .NET Windows 窗体应用程序的安全模型，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13708943/