FileStream：T-SQL与Win32的区别

Question

我们的一个团队正在构建一个数据库（和应用程序），将使用SQL 2008的FileStream功能来存储文档。根据微软针对filestream的最佳实践，Win32 API是访问FileStream数据的首选方式，而不是使用T-SQL。

然而，使用Win32 API需要使用集成身份验证来连接到数据库。这让团队感到担忧，因为他们不想直接给用户访问数据库的权限。他们希望应用程序使用SQL用户名和密码进行连接。

使用Win32与T-SQL访问filestream数据有哪些优缺点？是否有任何因素使得使用T-SQL变得不可能？

- DCNYAM

Answer 1

T-SQL和Win32文件流访问之间的关键区别在于数据传输到客户端的方式-使用T-SQL检索Filestream数据意味着存储引擎必须在NTFS上打开文件，通过SQL引擎和TDS（SQL数据传输的标准方式）将数据流返回到客户端。如果使用Win32，则存储引擎仍然在打开文件操作期间，但是完成后，数据可以直接通过Win32流式传输从文件传输到客户端，完全绕过SQL引擎。

随着blob大小的增加，打开文件并通过引擎传输的开销成为完成数据传输所需总时间的较小百分比。最近进行的一个非常特定案例研究的基准测试将阈值设置为60KB用于内联（varbinary max storage），60KB-1.2MB用于T-SQL传输，> 1.2MB用于Win32传输。正如我所提到的，这是针对非常特定的情况，因此您的情况可能有所不同。

就安全性而言，我可以看到使用SQL安全性的许多问题，但是如果没有更多上下文，很难提出建议。通过仅通过T-SQL访问它，您真正受到从Filestream中受益的限制。

- MikeW

Answer 2

首先让我们分析这个问题：嵌入式用户名和密码比使用Windows身份验证更安全。这是一个令人尴尬的错误假设。它只会给人们一种虚假的安全感。事实上，不能将秘密隐藏在应用程序中。它总是可以被揭示出来。在当今时代，只需要一个勇敢、熟练的黑客就可以揭示嵌入式密码或检索密码的方法，而且由于谷歌和其他朋友的存在，所有感兴趣的人都将学到它，无论他或她有多么不熟练。在安全分析中，登录名和密码“隐藏”在用户工作站上应该被视为与将其以书面形式交给该用户一样安全。通过使用隐藏的登录名和密码来保护访问权限，您所实现的只是失去了问责制和“谁”在何时进行操作的记录。始终依靠适当的访问权限进行安全保护。永远不要依赖于在攻击者的机器上“隐藏”的混淆密码。

如果您想要一种保护方案，允许用户仅访问特定功能（即，他们只能以这种方式更新数据，而不是编写任意的UPDATE语句），请使用所有权链通过存储过程进行测试和验证，并仅授予true经过身份验证的用户执行访问权限。对于更好的解决方案，请使用代码签名。

至于T-SQL与Win32访问，FILESTREAM最佳实践文档包含以下措辞：

FILESTREAM API旨在提供Win32流式访问数据的功能。避免使用Transact-SQL读取或写入大于2 MB的FILESTREAM二进制大型对象（BLOB）。如果必须从Transact-SQL读取或写入BLOB数据，请确保在尝试从Win32打开FILESTREAM BLOB之前，已经消耗完所有BLOB数据。未能消耗所有Transact-SQL数据可能会导致任何后续的FILESTREAM打开或关闭操作失败。避免使用Transact-SQL语句更新、追加或插入数据到FILESTREAM BLOB中。这将导致BLOB数据被缓存到tempdb数据库中，然后再回写到一个新的物理文件中。

- Remus Rusanu

---

虽然我同意您的安全评估，但我也曾处理过这个团队正在服务的客户，并理解他们的顾虑。威胁在于客户将尝试通过使用SQL客户端直接访问数据库来绕过业务规则 - 相信我，他们会这样做。不过，我会查看您发布的链接。至于文件流，我在我的问题中指出了我已经阅读了最佳实践。我的问题是什么，从技术上讲，使Win32流比T-SQL更适合大型文件？使用T-SQL可能会产生多少性能损失？ - DCNYAM