Question

我一直在努力探索SQL Server中与安全相关的问题。我们正在开发一个面向SQL Server 2008的.NET应用程序，我们希望使用FileStream。

现在我发现如果使用集成安全性，SQL Server只允许FileStream通过Win32 API。问题是我们有大约80％的应用程序已完成，但它完全基于SQL身份验证。因此，我们在应用程序中直接执行INSERT，并且不对每个CRUD操作使用存储过程。

这是相对安全的，因为我可以以加密形式存储SQL用户名和密码。我知道密码是以明文形式传输的，但我愿意接受。

我们希望最终用户能够通过Crystal Reports等工具连接到数据库，并且我们还有一个额外的SQL登录名，只有SELECT权限被授予。

现在，如果我们改为集成安全性，我们必须为个人用户（通过AD组等）提供执行应用程序可以执行的操作的权限。否则应用程序将无法完成它的工作。但是当最终用户直接连接到数据库时，他们也会拥有这些权利。

我看到有人说你应该为每个CRUD操作使用存储过程，并且只将EXEC权限授予AD组，但是我该怎么做呢？我没有看到用户在直接连接或通过应用程序连接时如何获得不同的授权......任何人都可以在此处启发我。

奖励积分的额外问题：据我所知，综合安全性不会对工作组起作用。那么人们如何让FileStream在工作组中工作呢？或者这被认为是不可能的？

Answer 1

试试这个：

NET USE \\DBSERVER /USER:DOMAIN\USERNAME

系统将提示您输入密码。这将与数据库服务器建立NetBIOS会话。完成后，您应该能够在数据库服务器上看到共享文件夹和共享打印机。

一旦在客户端计算机和数据库服务器之间建立了netbios会话，您就可以在不提示输入密码的情况下使用集成安全性。

你可能必须指定“命名管道”作为usem的网络协议，如果它不能用于TCP（但我认为它会）。命名管道继承了您现有的NetBIOS会话，因此您可以列出可能很适合的共享。

您还可以使用带有NetUseAdd（级别2）信息的Windows API函数USE_INFO_2建立登录会话，该信息包含密码。

我想简短的回答是，您可以为您的应用程序进行特殊的Windows登录，并让用户使用该登录。但请注意，它们也不能使用自己的用户名和密码连接到同一服务器。