编辑手记:安全永远是第一重要的问题,无论是在本地还是在云端。
我们的安全团队的宗旨在于保护用户的数据。当我们开始实施将数据迁移到云Google的云服务的基础设施上时,我们一直在思考,如何在迁移的整个过程中保障数据的安全。考虑的方面主要包含以下几点:
我们有一个内部供应商审核流程,包括我们的法律和安全团队。 我们跟这些团队一起审查在使用新的服务提供商可能带来的隐私和安全风险,这样我们才能在数据迁移的过程中发挥应有的价值,避免可能出现的问题。
当我们审查一个供应商,涉及安全和隐私我们会通过60多个不同方面的指标来评估。 这与我们平时内部审核程序的结构一致,通过审查,能够发现供应商是否偏离了我们的期望。 审核的指标可能涉及以下一些方面:
我们与Google一起协同审查他们的审计报告,并一起探讨相关的技术问题。 最终发现在所有方面,他们都很符合我们的期望。
接下来,我们将评估工作的重点放在他们是否给予我们确保客户数据所需的控制。
安全控制第一步:查看现有基础架构中保护客户数据的所有控制措施。这些控制包括保护功能,如具有双指标身份验证的远程访问V**和允许我们执行流量过滤的防火墙。 还包括许多物理安全控制,如一个良好的物理外围,生物识别身份验证,监控和报警系统,防止物理数据窃取。 针对这些基础设施安全保护,我们经常与安全小组探讨交流。
同时我们构建了一个矩阵,来回答关于如何将数据从数据中心迁移到云基础平台的问题。 下面是以抽样的方式展示一下我们关注的一些领域:
我们还考虑到在多租户云环境中运行会引入新的告警模型。与之前不同的是,我们现在需要关心内存和存储的重用问题, 我们还需要考虑其他用户在同一个虚拟机管理程序上的威胁。 幸运的是,Google已经考虑了这些威胁模型,并经过讨论处理了大部分。
对于大多数控件,我们找到了云平台上等效的功能。 而静态数据加密,则没有经过自己设计获得了新的安全控制。而一些控件,如IP白名单,不得不调整原来的安全架构,不能依赖于传统的网络控制。 我们通过使用Google托管密钥的GCP服务帐户来完成此操作。
当将数据迁移到云上之后,以前的静态CIRD块将会在静态、临时的共有IP中消失。IP的白名单操作会变得很昂贵。这一特性,在Google的其他云平台上都不存在。
我们通过建立安全控制,保证在互联网和客户数据之间至少有两层安全保障。 在以前的架构中,有一个定义明确的网络外围,我们将所有内部服务都包含在内。 这些内部服务使用API密钥进行相互通信。 通过安全的方式存储和分发这些密钥,但我们意识到密钥可能泄漏或被盗。 如果确实发生了,我们仍然有第二层的控制,因为用户不能在生产环境之外使用这个密钥。 这样访问生产环境就需要双因素身份验证。
在Google中,每个GCP服务都是互联网服务,用户不能通过面向客户的白名单控制访问Google Compute Engine(GCE)项目之外的计算机。 而我们需要找到一种方法,在被盗的API密钥和客户数据之间添加另一层安全性。
我们通过使用GCP服务帐户解决了这个问题。 每个GCE项目都会获得默认服务帐户,用户在GCE中启动的任何实例都可以模拟该服务帐户以访问其他服务。 在后台,Google管理公钥/私钥对,并且每24小时自动轮换这些密钥。 他们对自定义服务帐户执行相同的操作。 你可以为每个计算机角色创建自定义服务帐户,并配置虚拟实例设置以使用相应的服务帐户。 现在,使用GCP软件开发工具包(SDK)在该虚拟实例上运行的任何应用程序都可以使用内置的Google自管理的轮换密钥。
但我们的操作工程师没有必要访问这些密钥对。 由于Google每天自动轮换这些密钥一次,比较现实的办法就是通过深入基础架构来访问这些密钥对,因为对基础架构我们目前有足够的控制措施来防范。
总体而言,我们对目前已经实施的云安全平台充满信心,并将继续寻求扩展该平台,以进一步增强安全性并保持领先于不断变化的威胁环境
If you have any followup questions please join us on the Evernote forums.
如果您有任何问题,欢迎您访问印象笔记论坛,技术团队的成员将会给您专业的解答。