假设你是一家公司。你有一些敏感数据需要保护好，同时有一家云服务提供商在帮你保护这些数据。但你知道这种保护能延伸到什么程度，到什么程度就该轮到你接手了吗？
因人为错误，特别是数据库配置错误而导致的大量数据泄露事件表明，很多人并不知道，妥善保护所有数据的责任其实在自己身上，而不是在服务提供商那边（或者不知道该怎么去做）。
本文将探讨责任共担模型：它是什么、为何重要、其优势、局限性，以及企业如果不管它会出什么事。
什么是责任共担模型？
责任共担模型是一个安全与合规框架，它界定了云服务提供商（CSP）及其客户之间划分的责任。也就是说，双方在维护安全方面各管各的事。
简单来说，提供商负责保护底层云基础设施，但客户需要保护自己的数据、配置以及自己可能有的任何应用。
具体来说，提供商负责以下这些：
- 物理安全：保护物理数据中心和硬件。
- 主机基础设施：保护和维护网络、服务器及存储。
- 数据保护：为传输中的数据和存储状态的数据提供加密，但不保护客户的数据。
- 应用程序：可能提供应用托管平台或工具，但不保护客户的应用程序。
另一方面，客户要保护好自己所有的东西：
- 数据保护：妥善保护、分类、备份并加密自己存储的信息。
- 信息访问：管理对敏感数据的安全访问、用户账户、权限及多因素认证。
- 配置：正确设置防火墙和网络设置。
- 应用程序：开发、维护并配置应用程序以及应用的安全代码。
第一步是定义它——先来了解一下你的提供商
如果这些规则和分工能标准化，事情就简单多了——你搞懂了一家提供商的规定，就等于搞懂了所有提供商的。可惜，情况并非如此。
上述指南是通用性的，因为不同提供商之间的模式有所差异，这种缺乏统一性导致了提供商与客户之间的安全隐患。
尽管如此，请确保您了解自己对所使用的每个提供商应承担的全部责任。例如，AWS 表示：“客户应仔细考虑他们选择的服务，因为他们的责任因所使用的服务、这些服务集成到其IT环境中的方式以及适用的法律法规而异。”
AWS对这些责任做了明确的区分，称客户全权负责管理来宾操作系统，包括更新和安全补丁。他们还必须配置AWS提供的安全组防火墙，并管理他们拥有的任何其他应用软件。
微软进一步解释称，工作负载的托管位置不同，责任也不同：软件即服务（SaaS）、平台即服务（PaaS）、基础设施即服务（IaaS）或本地数据中心。
然而，“对于所有云部署类型，您的数据和身份归您所有，”它表示。“您有责任保护您的数据和身份、本地资源以及您所控制的云组件的安全。”
谷歌云采用了第三种方式，将其他提供商的共享模式与自己的“共同信念”区别开来：
鉴于正确理解共享责任模式以保护数据安全可能具有挑战性，“谷歌认为，共享责任模式不足以帮助云客户实现更好的安全效果，”它写道。“我们相信的不是共享责任，而是共同信念。”
这种方法的解释侧重于提供商与客户之间的“伙伴关系”，以增强安全性，并提供支持和资源来帮助企业在自身一侧保障数据安全。
提供商表示：“共同命运的关键一环在于我们提供的资源，帮助您在Google Cloud中以安全的配置起步。从安全配置开始有助于减少配置错误——而配置错误正是大多数安全漏洞的根本原因。”
共同责任模型旨在对安全、合规和道德责任进行划分。首要目标是覆盖所有方面，确保所有安全控制都得到管理，从而防止安全缺口和潜在的入侵。
一旦发生安全事件，理论上这套共享控制体系旨在更快、更高效地控制事态。我说“理论上”是因为安全漏洞确实存在，正如我们稍后将看到的。
此外，该模型旨在确保提供商和客户都不会不必要地重复安全步骤，浪费时间和精力。
最后，安全和基础设施成本远低于自建云，部署速度也高得多。
总体而言，该模型既有公共云的优势，又不必自己维护基础设施。
AWS 表示，这种共享模型“可以帮助减轻客户的运营负担，因为 AWS 运营、管理和控制从主机操作系统、虚拟化层，到服务所在设施的物理安全，所有这些组件。”
但不管什么原因，只要没按这个模型来，风险都很大：
- 数据泄露
- 网络攻击
- 财务损失（勒索软件、监管罚款、补救成本）
- 法律责任和潜在诉讼
- 声誉损害。
第一项是你最该担心的：它一旦发生，后面几个全跟着来。
一个简单的配置失误就能导致数据泄露，而且不幸的是，这种事一直在发生。
模型本身的漏洞
说到这里，正好可以聊聊这套模型存在的问题，第一个问题当然是理解上的偏差，这会导致责任被忽视，进而让客户的数据库出现安全缺口，提供商和客户之间也因此产生安全缺口。
这一问题会导致配置错误——这是大多数云安全泄露事件的直接罪魁祸首。
在不断变化的环境中搞清楚责任划分是很难的。有时候企业想照着做，却漏掉了某些环节。有时候他们甚至不知道自己有这个责任，想当然地觉得一切都该由提供商来管。而且他们往往忽略了对某些看似不太重要的数据的保护，比如备份文件。
无论哪种方式，最终结果都是一样的：数据库未受保护，暴露在外，任何人都能查看和下载。
这根本不是理论上的问题，几乎已经成了常态。就在最近，安全研究员Jeremiah Fowler 发现了又一个未受保护的数据库，其中包含666,369条记录，包括翠贝卡电影节员工和参与者的姓名、电子邮件地址、电话号码、IP地址和哈希密码。
潜在后果对未能保护数据的组织和数据被暴露的个人来说都是巨大而深远的。
共享模型系统中的其他问题包括：难以全面掌握云环境的情况、缺乏能维持和改善协作的有效集成方案、工具和平台的集成也面临挑战等。
如果你在多云环境中管理安全，那要应对的问题就更大了。
结语
保护数据不只是云服务提供商的事，也不只是公司的事。相反，这项工作分为“我的”和“你的”。一般来说，提供商保护他们创造的东西，打个比方，就是他们自己的房子。客户则负责确保自己租用空间里的所有数据和相关服务得到妥善保护。
说起来容易做起来难，因为尽管分担责任有很多好处（包括显著节省时间和成本），但由于多种原因，错误还是经常出，客户的数据库最后还是被暴露了。这是这种模式要长期成功运作必须解决的关键问题。
热门跟贴