解密：“云”上的安全

作者：佚名 2016-07-13 15:20:55

云计算

云安全 如今，云安全成为云计算的一个核心问题，如何理解云上安全？如何做到云上安全呢？

 　　安全是一个多层级的话题，包括物理、硬件、引导、存储和其他方面。本文只探讨数据中心工作负载的访问控制。

　　几乎所有企业数据中心里都有很多防火墙/科学设备，但是Google的数据中心没有。Google是如何做到不部署传统的防火墙，还能对其数据中心应用做到访问控制的?

　　从技术方面得出的答案是Google将访问控制、身份验证和授权部署到应用层，而不是在网络层，Google通过这种方式有效的在应用程序中进行访问控制，而不是在网络层去实现。

　　Google的这种方式保证了访问控制的稳定性、可移植性、可伸缩性：app-to-app，service-to-service数据中心内部访问控制不再依赖于在正确的时间正确的地点的人类或者脚本。它是基于应用程序身份的控制，而不是网络代理的身份控制;也没有更容易出错的“after-thought”应用人员和运维人员的协调。

　　尽管有众多的好处，围绕应用级安全控制和网络级安全控制依然存在着辩论。从行业发展史上看，企业数据中心选择的是“after-thought”网络级安全模型，因为它对传统的环境有意义;大多数数据中心运行打包软件，工作负载信任他们的内部网络，并且实现了有责任的分离。

　　尽管以应用为中心的模式在过去不符合企业的需求，但是现在已经有了相当程度的改变，云本地的应用将改变企业数据中心安全工作负载的方式。

　　1、内部自定义软件将控制数据中心：传统上，企业数据中心运行大量的打包软件，企业可以采取实际的方式从包的外部软件来保护这种类型的工作负载。但是，企业将传统的打包软件转换成软件即服务(SaaS)消费，因此安全打包软件不再是内部网络的需求。企业将运行卓越的内部开发定制软件，对他们的业务进行差异化经营。对应用来说，“baked-in”安全是一个极其可行的方法，因为企业拥有这些应用的代码和设计。

　　2、内部安全与周边安全重要性等同：传统的企业工作负载通常有一个信任的内部网络，不需要对单个的工作负载做访问控制，因此传统的营销或微营销技术更适应应用案例。Google的安全需求是基于“零信任”的，它不能保证内部网络比公共网络更加安全，传统的基于网络的接入控制不能满足这种规模的需求。但是企业开始在内部安全和周边安全上投注更多的心力：究其原因是“内部”可能驻留在共有云或混合云上。基于应用的“baked-in”模型将更可取，因为它具备高可扩展性和可移植性。

　　3、企业广泛采用DevOps：传统上，开发和运维之间的职责是分离的，这就划清了开发与运维之间的界限，“after-thought”网络安全模型实际上更适应日常工作流程。尽管一些职责的分离会得到保留，DevOps将会促进开发人员参与安全保障。应用程序生命周期的变化率急剧增加，在Docker和微服务中可见一斑。基于网络的“after-thought”的方法跟不上变化的脚步，基于应用的安全就必须得到加强。

　　现在的网络采用的是“after-thought”安全模型，并且在过去的二十年中为整个行业提供良好的服务。随着云原生应用的出现，云计算被广泛采用，以及积极拥抱DevOps，企业将会寻求能与云计算原生波长相匹配的安全模式。从“after-thought”到“baked-in”的安全模式的转变不会一夜之间就实现，它是一个量变引起质变的过程，但是在云安全产业仍然有一些激动人心的变化。