如何保护 C# 应用程序访问的 sql 服务器答案

【问题标题】：How do you secure your sql servers accessed by C# applications如何保护 C# 应用程序访问的 sql 服务器
【发布时间】：2011-10-26 22:45:19
【问题描述】：

简单而做作的例子：

C# 桌面应用程序与 SQL Server 数据库对话。所有订单都存在于 Orders 表中。

应用程序查看、创建和修改订单。在此示例中，用户只能修改自己的订单。

关注点：

如果使用专用 sql 凭据，则存储连接字符串。即使使用了用户凭据，也可以通过直接通过 Excel 或 Access 连接来绕过应用程序安全性。

解决方案：

仅通过 Web 服务/中间件提供对 SQL 的访问。很好，但在这种情况下不一定可行。

在某处的应用程序中加密连接字符串。不是非常安全，通过默默无闻的安全。

通过授予对特定存储过程、视图等的访问权限而不是对实际表的访问权限来保护数据库。 SP 和视图考虑了用户的权限/凭证。相当可怕。好的，简单的例子（选择 where user ，一旦你在不同的组中介绍用户，经理关系等就变得复杂了。

替代方案：

你会如何处理这个问题？

谢谢

【问题讨论】：

记得清理您的数据输入：xkcd.com/327

标签： c# sql-server security

【解决方案1】：

即使使用了用户凭据，应用程序的安全性也可以通过直接通过 Excel 或 Access 连接绕过

什么意思？您不应允许用户直接或使用 Excel 或 Access 连接到 SQL Server。他们不应该知道 sa 或其他密码。

在此之后，您当然可以加密您的应用程序的某些部分，配置以便没有人可以看到其内容。

我真的会认为用户只能在应用程序级别修改他/她自己的订单。我猜也可以在存储过程中完成，但这取决于并且应该了解更多细节以提出最佳或最合适的方法。

【讨论】：

我同意，但如果他们掌握了凭据，或者如果他们被设置为通过他们的 NT 凭据授予访问权限，他们就可以获得访问权限。
我认为这是对我来说最有意义的路径。该应用程序使用 SQL auth（web.config 中的连接字符串），并且只能通过某些 DAL 访问，该 DAL 根据 UserID 过滤结果。那里有一些不必要的漏洞吗？
嗨，nycdan，是的，如果用户可以访问未加密的连接字符串，他们可以连接到数据库并执行该帐户有权执行的任何操作。如果连接是通过集成安全性进行的，则他们只需要服务器名称。它不会是 web.config，因为它不是 Web 应用程序，因此配置文件存在于本地计算机上。我猜如果我们不使用集成，加密将对此有所帮助。

【解决方案2】：

使用 windows 身份验证而不是 sql 身份验证。

要允许用户仅查看他们的数据，您可以使用 SYSTEM_USER 创建基于当前登录用户的视图和过滤数据，以仅获取当前用户的数据并拒绝对表本身的选择权限。

【讨论】：

是的，我也想建议，但我认为他的问题是，在这种情况下，用户可以连接 Access 或其他工具并修改与自己无关的订单。如果我的问题当然是正确的......
那是戴维德。如果我们授予他们 NT 权限，理论上他们可以在 Excel 或 Access 中打开一个连接并读取（并可能写入）他们想要的任何旧数据。
谢谢乔治。我遇到的问题之一是有时编辑权限也可能取决于用户的组访问权限。现在我也可以在 sql 中定义这些组关系，我们实际上可能最终还是会这样做，但是如果我们最终使用 ActiveDirectory，那么事情会变得更加复杂。

【解决方案3】：

您不能在 SQL Server 中进行行级安全（好吧you can，但这并不简单）。因此，确保完全安全的唯一选择是通过控制访问的数据层。您可以加密存储您的凭据，但正如您所说，这并不完全安全。这取决于你需要什么。

【讨论】：

只是在寻找其他人是如何处理这个问题的。通常我会选择服务层，但在这种情况下，它是一个直接从桌面访问数据库的单体应用程序。

【解决方案4】：

在我们处理的应用程序中，我们将加密的连接字符串存储在文件中。所以用户不能直接访问这个文件。我们也只使用 sql 连接到我们的数据库，并仅授予用户此功能。

如果您使用 Windows 凭据访问它并希望防止任何操作，您可以禁止对表的写访问。要读取数据，您可以构建查询或访问表。

对于写入/添加/操作数据，您可以创建存储过程。其中一个参数是用户名。在您构建业务逻辑的过程中，模拟具有写入权限以最终写入/更新数据的用户。 SQL 服务器中有你的“层”。但我不建议这样做:) 这是可能的，但对于数据库内的许多业务逻辑恕我直言。所以最安全的方法是在你的语言中找到一个好的加密类，只使用 sql auth 并将这些数据存储在你的代码中。

【讨论】：

谢谢，非常感谢。我完全同意，我讨厌在 sql server 本身中有那个“层”，感觉太晚了 90 年代 :)