这不是我遇到的具体问题，但我必须澄清一些事情，因为我对这个项目有很多利害关系。
我正在创建一个将部署到英国一些大公司的网络应用程序，如果我们做错了，我们可能会付出巨大的代价!
我需要确保每个公司的数据都非常安全，所以我想知道为每个组织创建一个新数据库是否是个好主意，这样他们的数据就完全独立了，如果一个数据库被破坏了所有组织都不会受到影响——这将使我们有时间在所有数据受到威胁之前对安全问题使用react。我的问题是:
- 这样做的短期和长期利益是什么(如果有的话)
- 这个的短期和长期缺点是什么(如果有的话)
- 这是好的做法吗？
- 它是否会以我预期的方式解决安全问题？
提前致谢
最佳答案
我假设这是一个关于为“软件即服务”风格的应用程序构建“ Multi-Tenancy 架构”的问题。
第一个问题是，分离您的数据库可能是也可能不是一个好主意——但这不是要问的第一个问题。可以在重要级别访问您的数据库的人已经以极具破坏性的方式渗透了您的应用程序 - 他们几乎可以肯定地在您的数据库服务器上执行任意命令。这意味着您不仅要处理一个帐户的损坏，还要处理整个基础架构的损坏。这是一个“熄灯”时刻，您必须在恢复时关闭整个系统。
如果他们没有在您的数据库服务器上建立 shell，则意味着存在应用层安全问题 - SQL 注入(inject)，或在您的身份验证方案中以某种方式提升权限。同样，两者都是“熄灯”时刻。
所以，确保所有这些东西都被完全覆盖。在您的开发生命周期中包括安全测试；考虑使用自动化渗透测试工具作为持续集成系统的一部分。确保基础架构人员强化整个环境，并在接近发布候选版本时考虑进行第 3 方安全审计。考虑以安全问题为重点的代码审查流程，并就编码标准与特定的安全考虑达成一致。告诉您的所有开发人员有关跨站点脚本、SQL 注入(inject)和其他应用程序级漏洞的信息。
完成所有这些操作后，您就已经锁上了门并用 bolt 固定了 window ；您的数据库策略等同于您如何确保珠宝安全。
单独的数据库提供了一些额外的安全性 - 但前提是您有相应的用户管理策略。在大多数网络应用程序中，只有两种类型的用户:“管理员”和“网络应用程序”。 “管理员”可以创建/修改数据库(创建数据库、表、 View 等)，通常也可以修改数据。 “Web 应用程序”应该只有数据修改权限，但没有修改数据库对象的权限。
为了使数据库拆分有意义，您必须确保:
- 可以访问您的 Web 应用程序文件系统的攻击者无法访问有效的用户名和密码，或者即使可以，也只能访问一个客户端。
- 攻击者永远无法访问“管理员”凭据
但是，出于其他原因(安全之外)拆分数据库是有意义的。它降低了人为错误的风险，允许您在更精细的级别扩展系统，并允许您提供不同级别的托管(“金牌”用户拥有自己的服务器，“银牌”用户拥有自己的数据库，“铜牌”用户“捕获机会。”
要实现这一点，您必须解决的一个大问题是部署 - 您将如何部署新版本的代码，并对数据库进行更改？这反过来可能会使测试过程复杂化。
关于php - 保持数据库安全，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10449898/