在使用共享数据库的多租户应用程序中,保护和分离敏感数据的最便宜和PaaS无关的方法是什么?
一些背景信息和更具体的问题:
我们是一家小型创业公司.我们已成功为客户启动了Intranet Web应用程序项目,现在我们已准备好为类似客户提供云解决方案.
由于我们使用的是Microsoft BizSpark计划,因此我们正在调查Azure App Services.我们稍后可能会迁移到云服务,但目前似乎App Services已经足够了.尽管如此,我们还是不想过多地将自己绑定到Azure,以防我们以后想要转移到其他SaaS提供商.
我们的应用程序将存储一些应受到保护的敏感信息.为每个租户单独加密(Azure提供透明加密)数据库将提供最大的安全性,但我们没有这种解决方案的预算,并且很难自动管理.
目前我们的计划是,我们将为客户提供在我们的通配符域下注册子域,然后在内部将子域映射到将在每个表中使用的租户ID.
对于初创公司来说,这似乎是最具成本效益的解决方案,因为每个额外的租户都没有额外的管理,注册可以完全自动化.我知道我们必须非常小心地在每个SQL请求中强制使用租户ID(使用SQL视图和带有内置租户ID查询的存储过程将有所帮助),但这显然是不够的.我们需要一些机制来用一些加密密钥来保护每个租户的敏感数据.
然后有些问题来了:
我们应该为所有租户的所有敏感数据使用单个加密密钥吗?或者我们应该为每个租户分别设一个钥匙?
如果我们选择单独的密钥(在注册时随机生成,所以即使对我们来说也不会知道密钥),那么谁应该如何存储和保护租户加密密钥呢?我们是否应该向租户提供密钥,然后要求其员工在每次通过网络浏览器登录时提供每个员工的登录名和密码以外的密钥?
考虑到我们以后可能需要分片或"弹性"数据库扩展,因为一些PaaS提供商称之为,并且我们可能会从Azure和Microsoft SQL Server转移到其他方面,哪种方法最有效?
如果有人有多租户和数据库保护方面的经验,我真的很感激一些建议,有些建议,有些建议和可能的警告.我已经阅读了一些关于该主题的文章,但它们通常对PaaS平台过于具体,或者没有解释可能的后果和困难,但这些知识仅来自日常经验和试验与错误.