一、云计算发展的新阶段
云计算当前已经成为新型基础设施的关键支撑技术，在疫情期间，推动了大量远程办公、政务防疫、百姓生活等SaaS应用和移动应用。要回答云计算未来数年的发展，则需要回首云计算在过去的发展。需要注意到，云计算在国内发展具有鲜明的中国特色，跟国外同期是不同的，总体看分为三个阶段。
第一阶段主要是在2018年以前，主流的云计算场景多是虚拟化与私有云，部署在用户的内部环境中，基本上是将物理服务器替换为虚拟机。此类云计算应用可以理解为传统应用的虚拟化移植。
第二阶段主要在2018年至今，随着新型基础设施的快速发展，如5G、边缘计算和工业互联网等，容器技术的轻量、弹性等特性得到了重视，成为替代虚拟化的云计算重要支撑技术。同时，企业开发团队大量使用敏捷开发和开发运营一体化（DevOps）的模式，云原生（Cloud Native）技术栈已经广泛应用于各类云计算基础设施中，形成了庞大的云计算生态系统，其中微服务、无服务器等成为首选的开发运营模式。此类云计算应用可以理解为云计算的中心从基础设施转向了敏捷开发与云化应用交付本身。
第三阶段主要在2020年往后，随着后疫情时代的移动办公、应用云化产生的深远影响，部署在公有云的应用将成为主流。边缘侧安全接入（Secure Service Edge，SSE），管道侧的SDWAN，加上云端SaaS服务，会成为未来云计算的主流。公有云上丰富的云化应用和开放接口服务，将为大量第三方应用提供各类能力。
然而，公有云和SaaS服务的暴露面较私有网络中的云服务更大，其产生的攻击面和安全风险不容小视。
二、云计算安全从合规趋向于实战对抗
从驱动力的角度看，云计算安全也在发生巨大的变化。当前云计算安全的建设的驱动力主要是合规性要求。其中最大的动力是满足等级保护2.0标准中云计算安全的要求，以及相关主管机构所颁布的云计算安全条例，这期间的云计算安全主要是各类安全能力的建设。
然而能力建设只是过程，并非目标。事实上，安全的本质是对抗，安全能力的运营，抵御各类威胁，才是云安全的最终目标。云计算已经得到了广泛应用，可预见国家支持的威胁、大型攻防对抗活动，以及各种网络犯罪会瞄准部署在云计算平台之上的各类服务。从第三章所述的安全事件可见，云上的风险是真实存在的。
按照攻击链的理论，攻击者通常会首先收集各类软件版本和脆弱性的信息，构造相应的工具。因而，聚焦云计算的攻击者会收集互联网上暴露的云服务，进而发现其脆弱性并加以利用。因而，对云上攻击面进行发现与缓解是非常重要。
从暴露面和攻击面的角度看，无论是云计算平台，还是云计算应用都可能存在被攻击者所利用的脆弱性。主要有如下原因：
- 在DevOps中，开发团队大量使用第三方开源软件或软件库，或使用公开的容器镜像，以提升其开发效率，但这些开源软件或容器镜像可能存在安全漏洞，或遭到恶意污染，那么由这些镜像启动的服务，或使用了这些软件的服务，都存在安全风险。
- 传统的单体应用中，核心应用会直接读写数据库、消息队列，而公有云应用多采用读写公有云提供的存储服务或消息队列服务，以实现弹性或按需扩展，而这些原本内部的服务如今暴露在互联网上，任何人都可从互联网上发现这些服务。事实上，如果如果运维团队没有对这些服务做安全的配置，攻击者则可以直接或间接进行攻击。
- 很多开发者出于方便也会选择自己在互联网上搭建服务，但这些服务如果没有合理配置，也会存在安全风险。
- 很多大型机构有自己的研发团队开发软件，或委托第三方机构进行开发，无论是企业自己的员工，还是第三方企业的员工，都可能无意识地在互联网上部署或存放敏感代码或数据，导致出现安全风险。
三、云计算服务对外暴露的风险
云计算平台和应用均可能对外暴露，这些服务存在被攻击者发现并利用的风险。有些云计算应用本身是对外提供服务的，但如存在配置错误或凭证失窃，则容易被攻击者攻击；而有些云计算应用和系统本不应对外提供服务，但应该部署者无意识错误导致对外暴露。接下来我们介绍若干已发现云服务暴露导致的风险。
3.1存储桶服务暴露与用户错误配置导致数据泄露
主流公有云服务商都提供了对象存储服务，如Amazon AWS提供了S3存储桶服务，用于存储用户应用所需的文件、目录或数据，提升了应用的弹性能力，简化了用户部署系统的难度，例如用户可以在混合云环境中通过S3服务快速部署自己的Web站点[1]。
然而，由于有相当数量的用户缺乏安全意识，没有对存放的S3存储桶添加访问凭证，或使用弱口令账户，或将凭证存储在互联网公开位置（如下面我们提到的代码仓库），因而缺乏足够的认证授权和访问控制机制保护存储桶。咨询公司Gartner在2019年曾断言，到2022年，至少95%的云安全事故是因为用户的错误导致的[2]，而其中大部分是因为配置错误导致的。
我们统计了2017年以来发生的因S3存储桶造成的12次数据泄露事件，参见表1，其中10个事件涉及到的S3存储桶是公开访问的，甚至2018年的医疗数据泄露事件中，相关存储桶竟然被设置为任何人均可读写，可见隐私泄露风险之大，应引起足够注意。
表1 近五年S3存储桶数据泄露事件部分列表
对象存储服务是公有云提供的若干存储服务之一，其他如消息队列服务、数据库服务等均存在对外暴露和错误配置叠加的数据泄露风险。限于篇幅不再展开，读者可按需关注。
3.2 代码仓库暴露导致网站被攻破
从安全左移的角度看，代码仓库是介于开发阶段与运营阶段之间的重要边界，然而由于安全意识薄弱，或大企业软件供应链存在不可控的第三方参与，容易出现安全风险，最典型的是其系统所用的源代码仓库暴露在互联网上。一旦攻击者获取这些源代码，一方面可以分析程序的控制流与业务，找到脆弱处加以利用；另一方面可以发现代码中存在的硬编码凭证，进而访问后台系统、数据库等重要服务，堂而皇之地进入内部网络，或横向移动，或窃取数据。
我们在测绘时发现了有一些仓库存在着类似未授权访问的问题，除了源代码泄露可能造成的危险外，代码中还有许多敏感信息。如图1中的代码仓库的代码中出现“姓名”、“证书编号”、“身份证”之类的个人隐私数据，尽管是测试代码，但也说明了这种现象是存在的。即便开发者在新版本中将敏感信息删除，但git仓库具有历史版本的信息，攻击者是有可能检查历史版本去寻找，从而发现潜在的信息或凭证。总之，代码仓库暴露的巨大风险不可不察。
图1 代码仓库中存在的个人信息
更有甚者，这些风险可能被利用于地缘政治对抗中。2022年2月24日，俄罗斯针对乌克兰开展了特别军事行动，俄乌等多方势力在网络空间也进行了激烈较量。一个名为ATW境外黑客组织在攻击过程中发现了若干暴露的源代码仓库，他们不仅删除了仓库中所有项目的源代码，且添加了一个“slavaukraini”的用户，该名称具有强烈的政治色彩。顺藤摸瓜，我们在GitHub找到了疑似该黑客组织的项目，如图2所示。可见，云上的风险可被攻击组织用于宣示政治意图，做意识形态的对抗。
图2 疑似此境外黑客组织的发文
3.2 容器平台暴露导致计算资源被控制
2018年5月-7月，我们对全网的Docker管理服务的2375端口进行检索，发现这段时间暴露在互联网上的2375端口地址达337个。暴露主机的分布情况如图3所示，主机暴露数据覆盖多达29个国家，这个数据一方面说明了Docker已得到广泛的应用，但另一方面也说明了用户对于Docker的使用并不规范，进行了非常危险的配置。
针对这337个服务的IP地址，对地理区域进行统计可以看出，在全球范围内，互联网上暴露的Docker服务主要分布于中国、美国以及德国，其中中国有197个IP地址以52%位居第一，美国有65个IP地址以17%位居第二，德国有19个IP以7%位居第三。
图 3 在互联网上暴露的Docker服务的地理分布
前述暴露的337个Docker服务IP，我们对其域名服务分布情况进行了统计，其中不乏某些知名公有云厂商的IP地址，如图4所示。
图4在互联网上暴露的Docker服务的公有云IP分布
2018年7月，我们也分析了Kubernetes的服务暴露情况，对全网的6443端口（Kubernetes的API Server默认SSL端口）进行扫描分析，发现这段时间暴露在互联网上的Kubernetes服务达12803个。图5显示了Kubernetes服务暴露分布情况。其中美国以4886个暴露的服务占比38%位居第一，中国以2582个暴露的服务占比20%位居第二，德国以1423个暴露的服务占比11%位居第三。国内互联网上暴露的Kubernetes服务主机主要存在于北京、浙江以及广东等省市，这些服务大多部署在亚马逊、阿里云等公有云上。其中的几百个甚至都没有设置登录密码，一旦被恶意操作，后果将不堪设想。
图5 在互联网上暴露的Kubernetes服务的地理分布
3.3 TeslaMate暴露导致车辆被窃密或被控制
TeslaMate是一款可获取特斯拉数据和日志的开源项目，车主可自主部署在公有云或其他互联网服务器上，用于显示特斯拉轨迹、电量等信息[3]。虽然TeslaMate极大方便了特斯拉车主的生活，但如果车主在部署时没有启用认证，攻击者则有可能发现暴露的TeslaMate服务，从而窃取该特斯拉车辆的轨迹、充电等敏感数据，如图6所示。
图6 特斯拉车辆的行驶轨迹示意图
更危险的是，TeslaMate会在数据库中保存向特斯拉官方服务交互的凭证，如果攻击者获得了该凭证，则可通过该凭证向特斯拉服务发送控制指令，例如图7的远程启动请求，可能危害特斯拉车辆的行驶安全。
图7 Tesla的远程启动API说明
事实上，确实有安全研究人员发现全球有超过20辆特斯拉可被控制，如图8所示，但问题在于尚不知何人部署，如何通知这些车主所存在的风险尚不得知。
图8 Twitter上研究员宣称可控制特斯拉的截图
四、云上攻击面管理
从监管部门的角度，对云上风险进行治理，有助于确保重要数据和关键数据不外泄、重要基础设施（包括政府站点服务、智能网联车、工业互联网等）正常运行不造成社会危害，以及避免各类伴生网络攻击和地缘政治冲突，是非常必要的。但云上安全治理在未来一段时间内，涉及到云上资产与风险测绘、梳理云上资产归属，以及相关的治理体系和技术建设，将是一个较为长期、体系化的过程。
以上面的云上风险为例，特斯拉车主的身份定位是非常困难的，而如代码仓库、S3存储桶或容器平台，如果对其业务或数据，以人工智能或知识图谱等技术，是有可能发现敏感数据，以及涉事机构或人员的。从而配合治理体系和流程，根据风险级别和影响范围，逐步将相关系统或服务下线或改造。
从机构的角度，对自身相关的云上风险进行管理和缓解，则是非常必要和可行的。Gartner在云安全框架中将配置和管理面的安全统称为云安全态势管理（Security Posture Management， CSPM） [5]，其中最重要的是就是各类云服务对外暴露的管理面服务是否存在错误配置或弱访问凭证等风险。如果再把数据面服务暴露的风险防护加上，即云上的整体暴露的攻击面进行管理，Gartner又把这部分安全技术合称为外部攻击面管理（External Attack Surface Management， EASM)[4]，并将该技术列入了2022年安全与风险管理趋势中，可见其重要程度。而外部攻击面管理，主要就是持续测绘互联网上各类资产与服务的 暴露面，分析其面临的攻击面，特别是在攻击者利用之前，及时发现并缓解潜在的风险。
五、总结
随着后疫情时代的到来，云化战略成为各大机构获得商业成功的必经之路。而云计算趋势本身所带来的开发、运营模式变化，在带来巨大的机会的同时，也存在巨大的风险。只有对云化趋势有足够的技术洞察，在软件栈、运营体系上云后，发现并管理暴露的攻击面，持续进行治理和缓解风险，才能更好地防止各类安全事件或数据泄露，保证云上业务的安全性。
参考文献
[1] https://learn.hashicorp.com/tutorials/terraform/cloudflare-static-website
[2] https://securityboulevard.com/2019/04/most-cloud-breaches-are-due-to-misconfigurations-2/
[3] https://zhuanlan.zhihu.com/p/434370297
[5] https://www.gartner.com/en/documents/4001348
版权声明
本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司（“绿盟科技”）。作为分享技术资讯的平台，绿盟科技期待与广大用户互动交流，并欢迎在标明出处（绿盟科技-技术博客）及网址的情形下，全文转发。
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。