我所在公司的一位客户决定将文件存储在 SQL（很可能是 mySQL）数据库中。据我所知，这是可行的，只需将二进制文件或文件内容存储在其中即可。但这不是问题所在。
主要方案是网页存储在一台服务器上，数据库和上传文件存储在另一台服务器上，或者网页存储在一台服务器上的数据库中，上传文件存储在数据库中。以下解决方案是我们存疑的。
主要原因是安全。在这种情况下，您能提供什么最佳安全解决方案？我担心通过破坏 SQL Server，他们会获取文件，因为 SQL 注入破坏比服务器更常见，而且服务器在公司内部，只有真正的安全连接可用，而且如果 SQL Server 崩溃，恢复所有内容将非常麻烦，因为 SQL 转储会很重。
我正在针对这种情况寻求论据和其他解决方案。
答案1
将文件存储在数据库中意味着添加自定义代码来处理对文件的访问。虽然这提供了实现底层操作系统不直接支持的复杂安全模型的机会，但添加的代码越多，注入漏洞的可能性就越大，从而损害数据的安全性/完整性。
虽然我必须承认我不是 SQL Server 方面的专家（但我对 mysql 略知一二），但这种方法要求代码在数据域内以超级用户的权限执行；与普通文件访问不同，没有权限分离。因此，如果系统受到损害，则完全受到损害。与操作系统用户帐户受到损害的情况不同 - 风险大大降低。将此与 Microsoft 平台上的病毒问题与 Unix 平台上的病毒问题进行比较 - 为 Unix 编写病毒并不困难 - 但直到最近，大多数 Microsoft 系统都不需要权限分离。
服务器在公司内部，仅提供真正的安全连接
这不是一个很大的优势 - 看看数据泄露的统计数据 - 无论如何大多数都是内部的。
恢复所有内容将非常麻烦，因为 SQL 转储会造成很大的负担
确实，虽然在数据库上进行分区/增量备份比在文件系统上容易得多 - 但这又意味着添加更多代码 = 增加更多错误。最大的问题是，这是一种非标准的工作方式。虽然您可以放心，初级员工可以带着文件系统备份出现在您的灾难恢复站点并能够轻松恢复数据，但对应用程序备份执行相同操作则是另一回事。当然，您在选择用于自动访问文件的工具（备份、AV 扫描、重复数据删除、归档……）方面受到的限制要多得多。
此外，通过 HTTP 传送文件，您将失去对文件的所有并发控制。
另一个考虑因素是，当然对于 mysql 来说，一旦表超出了单个磁盘上的空间，添加更多容量就不是一件容易的事。
通过将文件保留在文件系统上并提供基于 Web 的前端，可以减轻其中一些影响。如果操作正确，那么您仍然可以使用权限分离（通过将 Web 服务器作为浏览器和每个用户/会话之间的代理运行，以经过身份验证的用户的权限处理实际的 I/O）。但您仍然失去了并发控制，并且还有其他类型的漏洞可以利用。
作为一家 IT 服务公司，这是从客户那里赚钱的好办法——向客户出售他们不需要的东西，让他们用它来存储关键资产，然后向他们收取支持费用。但从客户的角度来看，这是一个非常糟糕的主意。