c# / SQL Server中的客户端/服务器安全性
本文关键字：客户端 服务器 安全性 SQL Server | 更新日期: 2023-09-27 18:03:27
我有一个SQL Server在Windows 2008 R2机器上运行，需要有基本的查询在它上面运行(SELECT/INSERT/UPDATE)。这些操作由客户端直接执行，客户端是一个用c#编写的应用程序，安装在不同位置的一台计算机上，因此连接是通过互联网进行的。
由于在DB上运行的操作的本质是如此简单，我宁愿不在SQL Server上编写后端。所以安全设置:
1)用户名和密码写入客户端并提交。
2)在服务器上运行(参数化)查询，并将密码散列和盐返回给客户端。
3)添加密码和盐，使用SHA_512进行哈希，并与密码哈希进行比较。
4)如果两者匹配，您将获得创建和发送查询的工具集的访问权限。
在研究了这个主题之后，我觉得这个系统有一些安全漏洞，但我不能准确地指出这些漏洞是什么。
根据您的场景，我会考虑为应用程序的每个用户创建SQL帐户。当用户登录到您的应用程序时，在构造SQL Server连接字符串时使用这些凭据，并允许服务器执行凭据验证。这通常被称为直通身份验证。
更好的是，如果你的应用程序将由与SQL Server在同一个Active Directory域中的用户执行，你可以使用更安全的Windows集成安全(你目前用于本地测试)，用户根本不需要登录。连接将简单地使用他们当前的AD凭据。有关使用Windows域凭据在SQL Server中设置用户帐户的更多信息，请参阅此链接:https://msdn.microsoft.com/en-us/library/dd787978.aspx
另外，无论使用哪一种选项，您仍然需要使用TLS保护的连接(Encrypt=true)来帮助防止在线上窥探凭证。
如果我理解正确的话，那么整个密码检查是在客户端完成的。对吗?如果是这样，它似乎可能不安全。
你是否完全信任客户端?如果一个未经授权的人可以访问客户端，或者创建另一个客户端来模仿您的客户端，那么这将大大增加他们访问您的服务器端的机会。
这绝对听起来像你会更安全创建一个后端系统，即使它只是一个非常简单的代理服务，只是检查用户名和密码，然后转发查询本身。
这样，密码散列和salt就永远不会离开服务器。
客户端直接连接到SQL Server是不安全的。如果客户端在本地硬盘上，那么它可以被黑客入侵。
你没有为你想做的事情找到工具，因为它不是一个好的设计。
不要理解你的逻辑:"既然在DB上运行的操作本质是如此简单，我宁愿不在SQL Server上写一个后端。"如果它很容易，那么这是一个建立后端的理由。
。NET为它提供了完整的基础设施。Windows通信基础。