责任共担模型

当一个文件“在云端”时,它其实存放在一台你从未见过、也永远不会造访的公司所拥有的服务器上。这种安排把安全责任分给了两方,而大多数人直到出事之前都不会去弄清楚分界线到底划在哪里。每一家主要的云服务商都会明确地记录这条分界线,因为无论朝哪个方向理解错——以为服务商包办了一切,或者去保护服务商本就已经处理好的部分——都会造成实实在在的事故。

一条线的两侧

亚马逊网络服务(AWS)把这种划分称为责任共担模型,分为“云的安全”和“云中的安全”两部分。AWS 负责前者:“运行 AWS 云服务的硬件、软件、网络和设施”——物理数据中心、基础设施的补丁维护,以及那些即便你想自己检查或配置也做不到的部分。客户负责后者,而对于云存储服务,AWS 明确列出了这具体包括什么:“管理自己的数据(包括加密选项)、对自己的资产进行分类,以及使用 IAM 工具”——也就是决定谁有权访问这些数据。

这条分界线会随你使用的服务而移动

微软的文档指出了一点,对任何在不同类型云服务之间做选择的人都很重要:这条分界线并非固定不变,而是随服务模式移动的。它的责任表把客户数据、账户身份和访问管理列为客户在任何模式下——无论是本地部署还是云端——都始终要承担的责任。但当你从基础设施即服务(自己配置一台租来的虚拟机)转向软件即服务(使用邮件或文件共享这类现成的应用)时,微软承担得越来越多:操作系统、应用代码和网络配置越来越成为微软的工作,而不是你的。用微软自己的话说,永远不会转移的是,“你始终保留”对自己的数据、账户、客户端设备和访问控制的责任。

为什么客户这一侧比听起来更重要

对于使用现成的文件共享或邮件服务——软件即服务,服务商承担最多的那种模式——的非政府组织来说,很容易以为服务商的安全措施就是全部故事。事实并非如此。分界线上服务商那一侧(他们的服务器、他们的网络、他们的补丁维护)对主流服务来说通常都做得非常出色;这也正是攻击者很少直接去攻击那一侧的原因。他们转而瞄准客户这一侧:一个薄弱或被重复使用的密码、一个分享范围超出预期的链接、一个没有开启第二重验证的账户。上面“始终是客户的责任”那份清单中的每一项,也恰好是本课程下一节课的主题,这并非巧合。

值得对你使用的任何云服务提出的一个问题

在把敏感材料托付给某个云服务之前,值得找到它自己发布的责任共担文档(所有主要服务商都会发布一份),并问两个问题:服务商默认实际保护了什么,以及明确留给我自己的是什么。答案通常会清楚地说明,这份数据的安全究竟依赖于你自己的哪些习惯——而这正是本课程其余部分要讲的内容。