2

我希望获得一些关于我为我的应用程序提出的安全模型的最佳实践反馈。我首先尝试使用 Amazon 的 RDS 将 Microsoft Access 前端/后端升级到 .NET WinForms/SQL Server。应用程序将是多用户、多站点（不同域）并包含敏感的健康信息。

这是2周研究的总结：

  1. 使用混合身份验证和 SSL 存储在应用程序中的加密连接字符串。不理想，但我想我已经找到了一种方法，如果连接字符串被盗，它就可以了（见下面的#5）。

  2. SQL Server 只接受来自选定 IP 地址的连接（全部都是静态的）。

  3. 分配给一个具有仅执行权限的 SQL Server 用户的应用程序连接字符串。所有数据库交互都将使用过程完成。架构权限用于将应用程序用户限制在某些过程中。

  4. 具有 SHA 256 加盐和散列密码的用户表。这提供了第一层应用程序安全性。

  5. 这是我不确定的部分：只有在查找作为 exec 变量之一发送的用户名和密码的 IF 语句 = True 时，每个过程才会完全执行。UN/PW 将为应用程序的每个会话临时存储。我的理由是，这可以防止使用连接字符串以某种方式从允许的 IP 地址登录的用户在没有有效密码的情况下获取/更改任何数据。

  6. 使用 AES_256 对称密钥加密的敏感列，由使用数据库主密钥的证书加密。应用程序用户有权使用对称密钥和证书。

  7. 用户密码必须遵循规则（长度、大小写混合、特殊字符）。

任何人都可以看到其中的任何漏洞或有好的选择吗？#5 是否解决了 Windows 应用程序无法使用 Windows 身份验证的固有连接字符串安全漏洞？

4

1 回答 1

2

总体而言，您的设计让我印象深刻，因为您不信任内置功能，而是尝试复制内置功能（身份验证、授权、权限控制）。

使用 SQL 用户/密码进行身份验证/授权。不要建立用户和哈希表。不要在每个 exec 请求（！）中发送用户和密码。

使用 SQL Server 权限进行访问控制。使用代码签名来精细控制执行（签名过程）。不要尝试构建并行的、重复的访问控制基础设施，不要为每个会话存储临时用户/密码。

使用 AWS 防火墙基础设施来控制访问 IP。不要重新发明你自己的。

如果您使用列级加密，请了解您要保护什么以及您的目标是什么。意外媒体丢失？然后使用数据库主密钥（即穷人的 TDE）进行加密。数据保密？然后让用户在每个会话中输入证书解密密码。

解决固有的连接字符串安全漏洞

让用户在启动应用程序时输入密码，这样您就不会在静态文件 (.config) 中公开密码。这里的所有都是它的。SQL Server 很久以前就停止在线交换 SQL 身份验证密码。

于 2012-12-04T18:36:53.350 回答