云安全责任共担往往意味着无人承担

对于没有明确责任的云安团体来说，“共担”或“共同”责任往往意味着，全责每个人都认为有其他人在解决问题，任共但实际上谁也没有去做。担往最终出现工作被耽误，往意味着无人或是承担出了事情没人负责的局面。

云服务的云安“共享责任”模型是这样的：云提供商保护低于某个级别（该级别通常是他们的软件）的所有事情，并对其安全性负责。全责把这个级别当做房子的任共地基的话，作为云租户的担往责任是保护地基上的一切，即房子。往意味着无人

这种看似非常清晰的承担界限，其实经不起检验。云安因为没有任何一条简单的全责线可以把地基和房子分开。地基是任共和房子连在一起的网站模板，两者之间的互连结构属于房子完整性的一部分。如同云平台及其上面运行的应用程序。

真实的情况是，客户如何配置云服务决定着应用程序的安全性。比如，是否公开了Lambda函数（无服务器的核心组件）？Lake Formation（AWS上构建数据湖的服务）的访问控制启用了吗？AzureSqlDBServer（微软云数据库）上的高级数据安全选项打开了吗？GCP（谷歌云）云函数是否具备了公共调用权限？在CDN网络中，往往有很多人忘记隐藏源站域名。整合SaaS应用时，API可被任意用户调用，而不是专有用户。

客户在云上的安全远不只是上述的问题，因此好的云平台会投入大量精力来尽量减少这些疏忽，高防服务器避免不安全的默认设置。但没有一家云提供商能够完美地提供所有的云服务，也不是所有的云平台都能保证其系统的使用安全。更加糟糕的是，这些云提供商不会主动告知客户各种不安全的配置选择，尤其是他们在这方面做得特别差的话。

具有讽刺意味的是，为客户提供最多安全服务的云平台往往在使用这些服务时造成了最大的复杂性。每个工具包都需要大量的知识来正确使用它，以至于出现了专门提供正确配置云服务的企业。也许，是时候采用第三方风险管理流程了。

最新评论