这不是我遇到的具体问题,但我必须澄清一些事情,因为我对这个项目有很多利害关系.
我正在创建一个网络应用程序,将部署到英国的一些大公司,如果我们弄错了,它可能会花费我们巨大的成本！
我需要保持每个公司的数据非常安全,所以我想知道为每个组织创建一个新的数据库是一个好主意,这样他们的数据是完全独立的,如果一个数据库被破坏了所有组织的数据不受影响 – 这会让我们有时间在所有数据受到损害之前对安全问题作出反应.我的问题是：
>这有什么短期和长期利益(如果有的话)
>这有什么短期和长期的缺点(如果有的话)
>这是好习惯吗？
>它会以我预期的方式解决安全问题吗？
提前致谢
解决方法:
我假设这是一个关于为“软件即服务”风格的应用程序构建“多租户架构”的问题.
第一个问题是分离你的数据库可能是一个好主意,也可能不是一个好主意 – 但这不是第一个要问的问题.能够在重要级别访问您的数据库的人已经以非常具有破坏性的方式渗透到您的应用程序中 – 他们几乎可以肯定地在您的数据库服务器上执行任意命令.这意味着您不仅要处理一个帐户的损坏,还要处理整个基础架构的损坏.这是一个“熄灯”时刻,你必须在恢复时关闭整个系统.
如果他们没有在您的数据库服务器上建立shell,则意味着存在应用程序层安全问题 – sql注入,或者某种方式在您的身份验证方案中升级权限.再次,两者都是“熄灯”时刻.
因此,确保所有内容完全覆盖.在开发生命周期中包含安全测试;考虑使用自动渗透测试工具作为持续集成系统的一部分.确保基础设施人员强化整个环境,并考虑在接近候选版本时进行第三方安全审核.考虑一个专注于安全问题的代码审查流程,并就特定安全考虑事项商定编码标准.告诉所有开发人员有关跨站点脚本,sql注入和其他应用程序级漏洞的信息.
一旦你完成了所有这些,你就锁上门并用螺栓固定窗户;您的数据库策略相当于如何保护珠宝安全.
单独的数据库提供了一些额外的安全性 – 但前提是您有相应的用户管理策略.在大多数Web应用程序中,只有两种类型的用户：“admin”和“web app”. “Admin”可以创建/修改数据库(创建数据库,表,视图等),通常也可以修改数据. “Web应用程序”应该只具有数据修改权限,但没有权限来修改数据库对象.
要将数据库分割为有意义,您必须确保：
>可以访问您的Web应用程序文件系统的攻击者无法访问有效的用户名和密码,或者只能访问一个客户端.
>攻击者永远无法访问“管理员”凭据
但是,还有其他原因(超出安全性)分割数据库是有意义的.它降低了人为错误的风险,它允许您在更细粒度的级别扩展您的系统,它允许您提供不同级别的托管(“黄金”用户获得他们自己的服务器,“银”他们自己的数据库,“青铜“抓住机会”.
实现这一目标必须解决的最大问题是部署 – 如何通过更改数据库来部署新版本的代码？这反过来可能使测试过程复杂化.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
