云攻击的速度和复杂性意味着安全团队必须能够比攻击者更快地检测和响应云攻击。

因此，组织需要一个现代基准来衡量他们检测和响应云攻击的速度。要想在云中超越攻击者，安全团队必须满足 5/5/5 基准，该基准规定了 5 秒的检测时间、5 分钟的会审时间以及 5 分钟的威胁响应时间。

常见的云安全风险与资源共享和数据保护有关

云中最大的安全风险包括云计算特有的风险（涉及资源共享和远程数据访问）以及第三方风险。

共享资源和远程访问风险

共享资源模型增加了面临三个主要风险的风险：

1. 共享相同计算资源的恶意共同租户可能会影响客户对资源的访问，从而导致数据和声誉损失。
2. 当提供者无法在共享资源模型的租户之间分离内存、路由和存储时，就会发生隔离失败。这可能使组织容易受到针对其他租户的攻击。
3. 当服务提供商未能正确删除没有增加业务价值或已失去其用处的数据时，可能会发生无效的数据删除（与业务部门不愿放弃数据不同，这是一个并非云所独有的常见问题）。

第三方风险

一些第三方风险是特定于云的。他们包括：

• 安全程序冲突——当提供商和客户的安全控制冲突时，可能会给日常运营带来问题。
• 服务可移植性——与可移植性有关的技术可行性和成本问题是风险来源之一，部分原因是缺乏云计算监管标准。

除了与云相关的安全风险外，组织还应考虑影响外包数据的传统第三方风险，例如：

• 资源限制——提供商不准确的建模和规划可能会导致资源供应不足，从而导致服务不可用或质量受损的可能性更高。
• 远程访问漏洞——数据的远程访问增加了云和主机系统之间传输过程中遭受攻击的可能性。
• 服务黑客攻击——恶意方的黑客攻击给云带来了很大的风险。
• 缺乏合规性保证——云服务提供商可能无法满足所有行业标准和安全要求，如果提供商不允许审核，风险就会增加。
• 云供应链缺乏透明度——如果提供商将其服务的专业方面外包给第三方提供商，则该服务链中的任何中断都可能产生直接影响。
• 知识产权 (IP) 保护——在 PaaS 和 IaaS 等模型中，提供商和组织必须采取适当的措施来保护通过公共共享接口创建的新产品的知识产权。
• 失去治理——没有任何规定来检查数据是否驻留在服务提供商或第三方，或者这些提供商是否合规。这可能会对数据机密性和完整性保证产生负面影响。
• 提供商端滥用特权——云提供商的高技术角色可以访问敏感的客户信息，他们可能会在用户组织不知情的情况下滥用这些信息。
• 业务连续性 (BC) 规划和灾难恢复 (DR) — 提供商负责云中的数据，因此必须制定自己的 BC 和灾难恢复计划。缺乏透明度可能会阻碍业务连续性和灾难恢复策略。

公共云安全漏洞非常罕见

使用云不会导致更高的安全性或连续性故障。事实似乎恰恰相反。客户错误是大多数违规行为的原因。如果使用得当，云计算是安全可靠的。

云服务提供商 (CSP) 提供的强大安全性归功于：

• 规模——向多个组织提供服务使云提供商能够投资于弹性和安全性。
• 动态分配资源的能力——云提供商可以在其服务中提供加密、身份验证和过滤。
• 供应商之间的竞争——强大的安全性是供应商在竞争激烈的市场中脱颖而出的一个因素。
• 安全流程标准化——随着提供商的成熟并获得 ISO27001 等认证，客户组织有可能取代旧的安全技术，而不会产生资本支出。

全球活跃的 CSP 不到 20 个，提供全球大部分云处理服务。“一级”CSP 的特点是十多年来的可靠服务和市场主导地位。在安全方面，他们提供世界一流的水平。

近年来影响客户组织的多起数据泄露和勒索软件事件就证明了二线和三线 CSP 的风险较高。

这并不是说使用云没有风险。相反，这些风险不仅限于云安全。许多都与放弃对治理和合规性的控制有关。按影响程度排序，最重要的风险包括：

• 浪费员工时间
• 超支
• 敏捷性风险/技术债务
• 缓慢的时间和停机时间
• 安全暴露和数据泄露
• 合规性和审计复杂性
• 项目风险

要开始评估云安全性，组织应考虑以下因素：

• 内部或外部— 组织数据的物理位置。
• 专有或开放——云技术、服务和接口的所有权以及它们之间的互操作性和可传输性程度。
• 边界化或非边界化——安全保护是在数据级别还是通过传统的、基于基础设施的边界实施。
• 内包还是外包——无论是第三方还是您自己的员工提供云服务。

Sysdig 威胁研究团队发布了《2023 年全球云威胁报告》

主要发现

• 云自动化武器化。云攻击发生得很快。侦察和发现速度更快。自动化这些技术允许攻击者在发现目标系统中的漏洞时立即采取行动。侦察警报是出现问题的第一个迹象;发现警报意味着蓝队为时已晚。
• 10分钟疼痛。云攻击者速度快，投机取巧，只需花费 10 分钟即可发起攻击。根据 Mandiant 的说法，在本地的停留时间中位数为 16 天，这突显了云的速度。
• 90%安全的供应链还不够安全。10% 的高级供应链威胁对标准工具来说是不可见的。规避技术使攻击者能够隐藏恶意代码，直到部署映像。识别这种类型的恶意软件需要运行时分析。
• 65% 的云攻击针对电信公司和金融科技公司。电信和金融公司拥有丰富的宝贵信息，并提供了快速赚钱的机会。这两个行业都是欺诈计划的诱人目标。

不同账号下的互通

从一个安全研究员角度看，企业在逐步上云使用云原生的便捷时，也带来了不少基于云场景下的风险面。云上安全风险实则难以面面俱到，我们从与传统 IDC 部署和运营差异最大的「账户」、「应用」、「网络」三点来看

风险面剖析

企业上云一方面是将业务由传统的硬件服务器迁移到云服务商中，可通过网络便捷地按需使用资源(包括计算资源、存储资源、应用软件、服务及网络等)，且高度可扩展、灵活易管理的业务模式，具有大规模、虚拟化、高可靠及弹性配置等属性。另一方面将业务逐渐微服务化，将业务应用打包进集群，使业务更加稳定流畅运行。随之产生了以下几个方面问题：

在以往的内外部渗透测试突破过程中：

• 在配置云服务过程中，泄漏云账号（ak/sk）可直接控制云上资源；
• 在使用k8s过程中，未能对API做鉴权，集群证书在外部泄漏，都会导致整个集群被接管；
• 在集群使用中，除了漏洞外，错误的配置pod会让容器逃逸的风险变大；
• 在集群内部对pod进行横向移动扫描，无适配云架构的hids无法检测；
• 在企业内网中，存在API跨传统网络区域访问，可管理不同区域的pods，打破网络边界

云上账户体系风险

账号风险

随着上云步伐的加快，寻找云平台密钥（ak/sk）成了攻击者关注的点之一，由于开发测试人员粗心，在使用ak/sk时不规范，导致此类攻击事件逐渐增加。

Access Key Secret泄漏

子账号权限过大

当我们通过COS存储桶获取到ak/sk时，可大胆尝试此账号是否可以「创建机器」，「修改机器配置」。由于云账号体系权限配置稍有不当，就会导致权限放开过大， 预期是COS存储桶权限但有可能为主账号权限。

可通过官方api接口对获取到的ak/sk进行测试，以防止在渗透过程中错过重要信息。

账户存储

攻击者进入内网之后，一定会首先瞄准重要基础设施，如「云控制台」、「内网管理平台」、「密钥管理平台」等，一旦被攻击者发现核心存储云账户数据数据库，即可控制云上全部资源，造成不可挽回的损失。

账户存储db未设置防范措施，如：

• 连接db时，未限制db连接来源
• 数据存储时，未对数据做加密处理，直接明文存储

租户环境下网络配置风险

高危端口对外开放

如今高危服务基数越来越大，安全上木桶效应越来越明显，百密一疏则可能导致全线崩盘，云上租户在测试或者部署生产环境时，高危端口时常暴露到外部，导致被攻击者、黑产分子入侵。所以在开设对外端口时，一定要遵循最小化原则，只开放业务端口，其他端口限制访问来源。

vpc未隔离

企业租户对云上环境如果不加隔离限制，测试环境和正式环境未进行隔离，一旦通过漏洞获取到测试环境权限即进入到“生产网”。所以将云上核心机器设置单独vpc，使用唯一堡垒机进行登陆，可有效避免这类测试服务导致整个云上服务沦陷情况。

安全组设置出现错误

如上两点所讲，当高危端口以及内网核心业务都限制来源访问时，可能有些安全组没有配置对，也会使我们直接突破，进入内网。常见安全组配置错误：

• 开放了192.0.0.0/8段导致遭受公网192段服务器恶意攻击
• 开放172.0.0.0/8段导致遭受公网172段服务器恶意攻击

（注意：仅172.16.0.0–172.31.255.255 、192.168.0.0–192.168.255.255为内网地址。）

云上应用服务风险

k8s架构中api风险

kubernetes架构下角色分类清晰，api种类繁多，如下图：

各个API负责部分如下表：

利用以上api进行攻击

集群内pod应用

容器逃逸

拿到pod之后，如何更近一步扩大战果，是攻击者经常思考的问题，比较有吸引力的就是拿到pod之后进行逃逸，对逃逸手法进行总结如下：

容器投毒

容器投毒可作为供应链攻击一种，近两年供应链攻击打的很是火热，从传统的软件供应链到脚本依赖库，再到容器供应链投毒。目前根据近期发布的《容器安全在野调查》中，发现容器投毒已经使用了越来越多高级技术，包括：无文件攻击、rootkit等。

由于容器中检测木马难度较大，黑产利用这一点通过容器投毒，黑产可利用容器进行挖矿，谋取利益。

云上网络架构风险

网络隔离风险

集群api跨区域访问

防火墙隔离失效

传统oa网络与IDC网络是存在各种网络设备进行隔离的，但上云的引入，方便管理集群以及二次开发集群控制界面，可能就会出现打破网络隔离限制，使得防火墙对idc隔离失效，直接通过API访问控制idc集群，进而进入idc环境。

1) 数据泄露和云存储配置错误

我们可以从最近的 S3 存储桶泄漏中学到什么？错误配置很常见，它们会发生并且可以轻松修复。如果我们不解决它，灾难就会发生。许多情况是由于访问控制列表的配置错误或配置薄弱造成的。无论您是管理 Amazon S3 存储桶、Azure blob 还是 Google 云存储，组织都必须接管其所有权，以保护存储在云存储单元中的敏感信息。通过这样做，您可以确保正确的人员拥有正确的访问凭据，以阻止恶意黑客和任何其他未经授权的用户（包括第三方供应商）。

2) 检查是否有被遗忘的子域

黑客可以在外部服务的帮助下接管子域。2014 年，Detectify 安全研究人员团队发现了一种严重的攻击媒介，该攻击媒介允许人们因 DNS 配置错误而以一种域名所有者无法察觉的方式控制子域名。由于这项研究，我们进行了自动化测试来检查这种情况，称为表面监测。如果您不使用我们的扫描仪，您仍然可以通过查看所有 DNS 条目并删除所有活动和未使用的条目或指向您不再使用的外部基于云的服务来手动修复此问题。

3) 身份、凭证和访问管理薄弱

使用双因素身份验证、密码或身份控制以及适当的员工离职是确保信息不会落入坏人之手的简单措施。不仅鼓励使用强密码协议，而且通过实施SSL/TLS 证书和设置安全电子邮件协议（如 SPF 和 DMARC 记录）来加密信息流量也很重要。当员工离开公司时，应立即停用他们的访问帐户，以确保他们不会被遗忘和受到攻击。

4) 认证失效

至关重要的是，用户不应该能够在云服务上执行他们无权执行的功能。一个例子是拒绝未经身份验证的人将文件上传到“受保护”的云存储桶中。这是由具有一系列要求的上传策略定义的，不幸的是，这些存在控制薄弱的风险，如 Frans Rosén 的研究绕过和利用存储桶上传策略和签名 URL所示。建议专门为每个文件上传请求或每个用户创建上传策略。

5) 检查用户详细信息和 API 密钥是否未公开

分享伴随着责任，但你不能分享太多。不幸的是，包括UBER和Slack在内的几家知名公司已经吸取了惨痛的教训，因为他们不小心将代码上传到了 Github，而没有注意敏感用户信息的细节。GitHub 和其他开源编码平台的普遍使用通过知识和最佳实践共享使开发人员社区受益。但是，安全性仍然适用于此，并且应检查上传的代码（尤其是遗留代码），确保没有泄露密码、用户令牌或 API 密钥等敏感信息。也不应依赖默认设置，因为它们通常设置为“公共”。

6) 日志记录和监控

围绕服务器上的日志记录和监控活动的良好实践对于密切关注云安全状态至关重要。通过足够的日志记录和监控实践，您可能会更好地了解任何恶意活动，并可以回答以下问题：“我们是否有足够的兴趣来进行黑客攻击？”__ 然而，仅收集信息还不够，还需要立即采取行动，以确保尽快减轻云面临的任何重大风险。

7）持续监控常见漏洞并进行修补

注入被列在OWASP 十大漏洞列表中是有充分理由的。云服务可以通过注入攻击来利用。如果您已经迁移到云端，尤其需要检查遗留代码中的安全状态。SQL 注入是一种流行的现代漏洞，一旦检测到，就应该毫不犹豫地进行修补。它很容易实现自动化，这使得风险更高。方便的是，它们可以通过自动扫描仪轻松检测到。这涉及到XML 外部实体 (XXE)和服务器端请求伪造 (SSRF)等漏洞。

8）不断更新你的技术

使用最新版本的技术对于安全至关重要。通常会发布修复错误的补丁，但并不是每个人都感到安装它们的紧迫性，从而使应用程序容易受到攻击。 “jQuery 就是一个很好的例子，尽管存在已知的漏洞，该框架的多个过时版本仍被使用，”Detectify 首席信息官 Johan Norrman 解释了缺乏更新的原因，“有人甚至开发了一个网站来方便地获取信息。”

9) 尽职调查和清理多余工具

即使您涵盖了云安全基础知识，您仍然可能面临违规风险，这意味着需要对事件响应例程进行尽职调查。您可以通过演练应急步骤、测试恢复并确保备份正常工作来做好准备。审核您的工具箱时，应用“使用它或丢失它” 规则。这样就无需更新未使用的工具或将其作为可预防的风险。正如CSA 所说，“无论公司是考虑迁移到云，还是合并或收购已经迁移到云或正在考虑迁移到云的公司，这都适用。” 他们去年发布了一份云安全风险列表，即“Treachery 12” 。

红队视角下的公有云基础组件安全

“公有云是为广大用户、个人或企业提供的云基础设施。公有云就是第三方公有云供应商为用户提供可通过互联网访问的虚拟环境中的服务器空间。然后，用户可以通过购买云服务器、数据存储和其他与云相关的服务等公有云服务来访问这些服务器。虽然用户可通过互联网访问公有云，但数据将通过虚拟化与其他用户的数据隔离，以提高安全性。公有云供应商还主动确保其服务器不受漏洞影响，并使用最新的软件补丁进行更新。但最终还是由使用者负责数据在云中的使用，包括访问、身份验证、加密和应用程序配置。”

随着越来越多的企业将应用、存储上云，各大公有云提供了各种 IaaS、PaaS、SaaS 服务，针对公有云各组件的攻击面也伴随而生。公有云厂商在尽可能保证组件安全的前提下，由于各种基础配置还是由用户决定，因此仍然存在很多安全风险。

本文主要从红队视角讲述公有云基本服务中一些因配置问题产生的安全风险。

编者注：以下所有内容仅供学习研究，严禁从事非法活动，任何后果由使用者本人负责。

目录

● 云存储

● 云计算

● 容器集群

● 中间件

云存储

至于为什么一上来就讲述云存储，是因为目前很多云厂商使用自己原生的云存储去操作其他基本组件，很多功能都是基于对象存储完成的，所以，首先讲述云存储的安全问题，为以下攻击面做准备。

在对象存储中，用户所上传的文件都是以对象形式存储在云端，以对象形式形式存在的文件不具备可执行权限，再加上提供无层次结构的分布式存储产品，为用户提供单价较低且快速可靠的数据存储方案，所以现在的大趋势下很多企业选择将自己所有的静态文件（图片、网站静态文件、视频等）搬迁至对象存储上，由于对象存储一般都是托管在第三方，企业在自身安全建设时往往会忽视掉这一点，殊不知不安全的配置，也会带来很多安全问题。

国内常见的几家云厂商的对象存储如下：

腾讯COS：

https://cloud.tencent.com/product/cos

阿里OSS：

https://www.aliyun.com/product/oss
百度BOS：

https://cloud.baidu.com/product/bos.html
华为OBS：

https://www.huaweicloud.com/product/obs.html

七牛Kodo：

https://www.qiniu.com/products/kodo
又拍云USS：

https://www.upyun.com/products/file-storage

访问控制

创建空间时，可设置为公开空间或私有空间。

●公开空间：可通过文件对象的 URL 直接访问。

●私有空间：文件对象的访问则必须获得拥有者的授权才能访问。

如果设置为公开空间，则任何知道URL链接的人都能访问，此类空间适合存放公共文件，如网站静态资源、用户头像等公开资源（理论上你的文件名设置得足够复杂，在一定程度上也能保证安全性，但还是不建议这样做），针对敏感文件，尽量还是选择私有空间，私有空间在访问时一般要加上签名信息才能访问。

目前大部分云厂商会提供类似https://bucket.s3-china-region.cloud.com/?ak=xxxx&sgin=xxxx&time=16xxxx的类似AWS S3 签名URL形式，或者直接兼容S3协议，以提供下载、上传、管理API，具体参数意义如下：

● AK用于控制用户权限

● Sign用于验证签名，一般的云厂商都会把AK、domain、URI、Query、Header等请求特征、身份特征以及时间戳拼接在一起，然后使用SK做为盐值进行hash，来生成最后的Sgin，用于校验此数据包是否合法。

● time是时间戳，用户标识此URL过期时间

上传风险

通过查阅相关文件，我们可以知道使用表单上传文件到 OSS的技术方案里，有三种实现方式：

1、在客户端通过JavaScript代码完成签名，然后通过表单直传数据到OSS。

2、在服务端完成签名，然后通过表单直传数据到OSS。

3、在服务端完成签名，并且服务端设置了上传后回调，然后通过表单直传数据到OSS。OSS回调完成后，再将应用服务器响应结果返回给客户端。

密钥泄露

在对象存储的SDK中，一般都会存在JavaScript的SDK，也就是支持用户前端上传的组件。

https://github.com/ali-sdk/ali-oss

一般来说，在安全的配置下，前端上传会使用子用户、或者临时密钥（STS token）的方式来进行，但是由于不严谨的开发，前端js文件、APK文件硬编码AK / SK的情况还是司空见惯，一般来说只需要在burpsuite里面搜索对应云AK的名字，例如AccessKey、SecretKey等。

拿到了AccessKey、SecretKey就可以实现对OSS的完全控制，常见的方法有利用官网提供的API或者开源工具等对OSS进行管理操作，这里介绍两个常用的开源管理工具。

● https://github.com/TruthHun/CloudStore

● https://github.com/willnewii/qiniuClient

任意文件覆盖

在某些业务场景下，可能会存在如下流程：

1、首先结合时间戳生成一个随机文件名

2、通过此文件名信息在后端获取该文件的上传签名

3、最后通过PUT或者POST上传

这个时候，由于上传的路径是我们控制，所以我们可以通过修改签名路径的形式，来进⾏签名，从⽽去覆盖此存储桶下的任意⽂件：

我们可以看到已经成功上传了⼀个新⽂件覆盖原来的⽂件。

能达到⽂件覆盖的⽬的后，就可以对储存桶资⾥原有的资源进⾏修改，可能会带来XSS⻛险，严重还可能造成供应链投毒攻击。

1

XSS风险

在文件覆写条件成立后，先假设一个场景，某企业主站里面的静态js文件均放在OSS的云储存配合CDN进行加速，现在已知js文件的路径和名称，那么我们就可以在原有js里插入一段恶意js代码进行文件覆盖，从而达到xss甚至长期信息窃取的风险。

2

供应链投毒

在文件覆写条件成立后，先假设一个场景，某企业为软件提供商，为了节省服务器带宽，将软件/源码上传到OSS进行分发，因为配置不当正好存在任意文件覆盖，导致软件或源码中被插入恶意代码。

任意文件上传

部分公有云厂商默认配置了已存在的文件禁止覆盖，这种情况下文件覆盖是没办法了，但是可以控制文件的key进行任意文件上传。

一般来说国内各大云厂商的OSS都支持html解析，当OSS配置了企业域名后，再配合任意文件上传，也相当于控制了一个子域名的权限，可以用来XSS和钓鱼。

上传时将⽂件路径从upload更改为attack，获取此次上传的STS（Security Token Service），将拿到的STS带⼊上传，修改key（⽂件名），即可实现任意⽂件/任意⽬录上传。

STS Token

由于前端使用SDK上传，会减少很多前后端交互API的编写，所以很多开发总是会选择前端上传，所以云厂商开发了STS（Security Token Service）的模式，有关STS的介绍如下：

查看完整的说明请访问：

https://help.aliyun.com/document_detail/32122.html

由于STS token是对针对API接口而不是大范围的云产品的，有的时候在存在AK、SK、STS都返回以后，上传有限制，只允许在特定目录下传文件的时候，不妨试一试带上STS访问ECS、SLB等其他同样支持STS的服务，对于AWS S3标准的STS，我们还可以通过BASE64解码来获取对应的权限。

PUT ACL接管存储桶

这是某云厂商关于PUT ACL的说明：

即然能覆盖原ACL，那就说明如果配置不当，就可能存在一定的安全问题。

如果是前端请求签名，并且前端上传的话，如果后端对路径没有做限制，我们就可以通过请求SDK获得根目录的写入权限，接着配合PUT ACL进行覆盖。

GET /get_put_sgin?uri=/ HTTP/1.1
Host: 192.168.20.31:80
Accept: /
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close

详细文档参考：

https://cloud.tencent.com/document/product/436/7737来对根目录进行ACL的写入，但是要注意的是PUT bucket写入是一个覆盖操作，会覆盖原有业务的ACL导致业务无此bucket权限，导致业务中断，所以如果发现此问题不要贸然测试。

下载时产生的安全问题

对象存储为什么可以保证存储文件的安全？在私有读的存储桶里，读取任意文件都需要授权签名，签名过期后就无法读取，这样就会导致一张图片必须每次读的时候都去请求权限，在请求权限时，业务最常用的接口就是：

GET /download?uri=file HTTP/1.1
Host: 192.168.20.31
Accept: /
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close

发送这个请求就会返回一个加参数的url，但是如果我们的url设置为空，例如这样。

GET /download?uri= HTTP/1.1
Host: 192.168.20.31
Accept: /
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close

那么就会访问到对象存储的管理节点信息，从而获取整个桶里的文件信息，再拿得到的key去构造访问链接，从而造成储存桶的文件遍历。

MinIO的安全问题

目前可选的资源服务器挺多，比如FastDFS，MinIO，AWS/S3等，云服务器供应商也提供资源服务器OSS租用，某些企业为了数据安全的考虑，可能会选择用MinIO在企业内部自建一个OSS服务。

数据泄露

简单说，就是如果你想要提供永久性的资源下载链接，就需要把Bucket(桶)的BP设置为Read&Write。

当你用 http://minio_out_url/bucket_path/ 访问时，会得到一个超大的XML，里面就会出现这样的情况，其中key字段就是文件名。

MinIO的桶有一个listObjects的功能，默认最多1000条记录，这就意味着如果你打开永久下载链接模式，那么任何人可以通过桶路径来获取你保存的所有资源的信息，从而造成桶遍历。

CVE-2021-21287

参见PHITHON的文章，这里就不多介绍了。

https://www.leavesongs.com/PENETRATION/the-collision-of-containers-and-the-cloud-pentesting-a-MinIO.html

云计算

云服务器

目前，基本上所有公有云都支持使用自定义镜像，并且镜像导入的方式比较统一，基本上都使用由对象存储导入，输入 oss-key 地址，然后公有云服务进行下载导入。所以，可以考虑劫持用于导入镜像的 oss-bucket，直接污染镜像，实现“供应链攻击”。

此外，一些公有云还支持由其他服务器创建的镜像，新建的服务器会与原服务器完全相同。从攻击者视角来看，相同系统环境以及应用意味着相同的攻击方式。

批量计算

一些公有云厂商都提供了批量计算的服务，该服务为 SaaS 服务，只需配置参数，即可调用服务器资源进行计算，大多云厂商目前都选择使用 oss 去控制输入以及输出参数。从攻击者视角来看，同以上所说的服务镜像一样，若该 oss-bucket 可控，则可直接控制批量计算的服务命令等。

容器集群

不同公有云在容器集群服务方面出入较大：

阿里云针对不同的需求提供了 5 种不同版本的集群：ACK 托管版、ACK 专有版、ASK 集群、ACK 边缘托管版、注册集群等；

腾讯云针对资源类型分为TKE容器集群、EKS弹性容器集群与边缘集群；

华为云区分为容器引擎CCE 与实例CCI。

每个厂商的容器服务不同，所以从攻击者视角来看，攻击利用某一厂商的容器服务需对其进行特殊处理。

容器集群服务

敏感目录被挂载

某厂商在创建容器集群服务时提供了一个接口，可以修改容器存储路径。

若此处被运维人员修改，如改为 /root，那新建容器另外的运维人员挂在了 /root 进容器中，则该节点的所有容器都会被控制。

复现过程

创建集群时修改容器目录为 /docker

开启外网访问

新建 pod，并挂载 /docker 目录

进入 pod 内部 /mount/docker 目录，可控制所有容器。

所有节点使用相同 kube-config

所有的节点使用了相同的 kube-config，皆为 k8s master 权限，若有容器存在逃逸问题，则在任意节点都可控制整个 k8s 集群。

该云厂商 k8s 配置自动解决了组件未授权等问题，但是 docker 用户逃逸问题未能避免，若容器发生逃逸或 /root/.kube/config 泄露，则可控制整个容器集群。

以下演示挂载 /root 导致整个集群被控制的过程：

新建pod，挂载 root

获取 kube-config

上传 kubectl，控制整个集群

容器镜像服务

所有提供容器服务的公有云皆提供了容器镜像服务。

存储劫持

有些云厂商为了方便操作，直接使用对象存储，创建镜像仓库时会自动创建 Bucket，镜像的资源都会储存在对象存储中。此时镜像服务相当于一个中间件，封装了 sdk，对镜像的所有操作相当于调用 sdk 去操作 oss。

● Bucket 默认为私有读写，若配置为公有读写/公有读，则也可对镜像仓库进行读取/控制。

● 若控制了 Bucket，则相当于控制了镜像仓库，可通过设置回源造成镜像仓库控制服务器 SSRF。

Token 泄露

大多数云厂商使用两种认证方式登录仓库，永久访问凭证或者临时访问凭证。

若访问凭证泄露，则可对仓库进行增删改查，完成“供应链攻击”。

中间件

是为应用提供通用服务和功能的软件。数据管理、应用服务、消息传递、身份验证和 API 管理通常都要通过中间件。我们这里中间件只说API网关和消息队列的内容。

消息队列

当前主流的消息队列有RocketMQ、Kafka、Pulsar、RabbitMQ等。

● RocketMQ是阿里巴巴研发的一款低延迟、高可靠、可伸缩、易于使用的消息中间件。

● Kafka是由 LinkedIn 公司开发的一个高吞吐量的分布式消息系统， 开发它的目标是为处理实时数据提供一个统一、高通量、低等待的平台。

● Pulsar是由Yahoo开发的 Pub-Sub 模式的分布式消息平台，在 2016 年开源，并于2018年9月毕业成为 Apache 基金会的顶级项目。

● RabbitMQ是一个基于高级消息队列协议实现的消息系统，其服务器端用 Erlang 语言编写，支持多种客户端，如 Python、.NET、PHP、 Java、JMS 等。

某些云厂商在启动消费者订阅普通消息时需要设置相关参数其中包括AccessKey等云身份验证的参数需要注意防止泄露。

某云厂商的一款应用中在准备配置阶段明确说明了使用Log4j，这里需要注意下。

角色密钥

有些产品的消息队列需要配置角色，每个角色的建立都会有密钥的生成，这个密钥是作为管理员身份的认证，如果角色的密钥泄露那么绑定这个角色队列数据存在泄露的风险。

消息队列开通需要进行一些配置新建集群会显示接入点

在其中新建命名空间，并新建Topic

针对空间进行权限配置，需要提前新建一个角色

角色建立时会配置权限

消息队列中每个集群可以建立多个命令空间，接入地址可以选择开放公网，但是打开之后就不能再关闭

每个空间需要绑定角色，并且多个空间可以绑定一个角色，如果这一个角色的密钥泄露那所有空间的队列数据可读

API网关

API 网关将各系统对外提供服务的微服务聚合起来，所有要调用这些服务的请求都需要通过 API 网关进行，基于这种方式网关可以对API进行统一管控，例如：认证、鉴权、流量控制、协议转换、 监控等等。

鉴权

API的鉴权设置不当的话会让任意用户调用相关API

API创建的时候，会有鉴权的类型选择，如果不选默认为免认证，意味着谁都可以调用

鉴权选择应用认证，这个涉及到调用API的凭证，密钥类似于登录密码，密钥泄露他人可以任意调用API

应用密钥也是一种签名方式，可以对请求内容签名计算

鉴权为密钥对是只有使用正确密钥发起的访问才能够通过API网关的校验，不携带或者错误都不能通过鉴权，这种方式是历史功能官方会提示不建议使用，密钥的泄露一样会造成任意调用

云原生网关

某厂商有个产品叫云原生网关是基于Kong网关的，我们可以借助这个达到隐藏ip的目的。

利用的前提是需要开通云原生网关（目前白嫖）、并且有一台和网关属于同一个地区、同一VPC下的云服务器

通过配置安全组添加规则放通VPC的网段10.0.0.0/8 、192.168.0.0/16、172.16.0.0/12三个VPC内网网段

访问创建的云原生网关可以看到网关的详细信息包括Kong 管理控制台的地址和管理员账号、密码

第一次进入需要启用连接，使用默认的就好

在左侧进入服务列表并新建一个服务，创建时在url中填写云服务器在VPC的地址

创建成功点击服务进入详情创建一个路由，在Paths中填写/，回车确定，然后点击最下面的提交

cs马配置为kong提供的公网代理地址，需要使用无阶段的马

目标成功通过kong上线

---

总结

根据以上分析，本文涉及到的公有云基础组件安全风险总结如下：

• 从云存储角度看，包括访问控制风险，文件上传中的密钥泄露、任意文件覆盖风险，STS Token的未授权访问风险，PUT ACL接管存储桶配置不当，以及文件下载、MinIO等资源服务器也容易出现安全问题。
• 从云计算角度看，云服务器易出现镜像污染和因服务器环境相同带来连环攻击的风险；批量计算服务命令遭恶意控制等。
• 从容器集群角度看，容器集群服务易发生敏感目录被挂载的情况；容器镜像服务存在存储劫持、Token泄露等风险。
• 从中间件角度看，消息队列可能存在角色密钥、云身份验证参数泄露等问题；API网关存在鉴权配置不当引起恶意调用、密钥泄露风险，云原生网关权限泄露等问题。

参考文献

1. https://www.alibabacloud.com/zh/knowledge/what-is-public-cloud

2. 云原生中间件白皮书（2020 年）

3. 文件上云 - 对象存储的攻击方式

实战中通过AccessKey与AccessSecret接管文件存储服务的攻击场景

原创 L@2uR1te HACK学习呀 2022-06-05 11:23 发表于__广东

0X00 前言

互联网的时代正在高速发展。在互联网的发展中，数据存储技术的各种应用方式也在经历不断地变换。在如今，OSS对象储存已经成为一种被广泛采用的存储模式，很多企业都习惯将大量的数据都通过云储存的形式为商户实现便捷服务。

所谓对象存储OSS，是在云上提供无层次结构的分布式存储产品，为用户提供单价较低且快速可靠的数据存储方案。用户可通过云服务器实例或互联网使用Web API接口存储和检索数据。在OSS上的数据，用户使用指定域名的URL地址，通过HTTP/HTTPS协议存储和检索每个独立的数据对象内容。简单理解，类似AI停车。我们（前端应用）把车停进去，换来一张卡片（对象的标识符）。我们不用关心车（数据）具体停在车库（存储）的哪个车位，这样省事儿、省时间。

使用OSS进行文件的存储是有非常多的好处的，它可拓展性高、效率高、安全性高、成本低、访问方便。

如今主流的公有云厂商有这些：亚马逊（AWS S3），腾讯云（COS），阿里云（OSS），华为云（OBS），百度云（BOS）,网易（NOS），快快云（OSS）。虽然各厂商的产品还是有些区别的，但是在利用方式上仍然大同小异

0X01 实战利用

AccessKey ID与AccessKey Secret之于OSS服务的重要性

关于OSS存储的诸多技术细节不再赘述，我们只关心在实战中如何针对各类OSS服务进行攻击，针对OSS的攻击，绕不开的一点就是AccessKey ID与AccessKey Secret的获取（各大厂商对其的命名略有不同，但它们的功能是类似的）。下面通过阿里云和AWS两家厂商对AccessKey ID（下文简称AK）、AccessKey Secret（下文简称AS）的描述来简要介绍其功能。

简单来说，AK与AS就是一种调用服务API的凭据，可以简单理解为在这种特殊场景下的“账号”与“密码”，我们想要使用OSS的各种功能，也是无法离开AK与AS的。换句话说，如果攻击者设法找到了AK与AS，是否意味着对OSS云存储服务的直接接管呢？

0X02 实战场景中AK与AS的寻找方法

在实战中要如何寻找AS与AK是我们要面临的重要问题，笔者以对某厂商的一次测试为例，抛出第一种寻找方法——敏感文件的泄露。这里的敏感文件是广义的，可以是各种内存的泄露、可以是某些数据库里存储的信息、甚至可以是运维人员图方便而写的一些备忘文本。本案例是通过找到Spring泄露的heapdump文件进行分析的。

通过一款heapdump自动化分析工具，我们可以方便快捷的分析heapdump中泄露的各种敏感信息，如下图，工具找到了泄露的AK与AS

于是我们通过该AK与AS，成功接管了该OSS服务，并且找到了海量的数据（进一步说明，对于这种文件存储服务，只要被攻击者接管，所泄露的数据量将会是巨大的）

值得注意的是，某些情况下phpinfo等探针文件也会抛出AS与AK（如下图），攻击队在找到探针类文件后，可以尝试搜寻AccessKEY、AK、OSS、SECRET等字样来分析是否存在AK与AS的泄露

还有一种比较偏门的地方是通过各种报错进行泄露，比较可能的情况有ThinkPHP的Debug模式，以及其他的一些因配置不当报错而泄露AK与AS

类似下图这种就是比较典型的报错泄露：

如图，直接抛出了AWS的AK与AS。但是通过报错来寻找AK与AS在实战中具有相当大的不可控性，属于是可遇不可求的一种发现方法

实战中还有一种可能性较大的寻找方法就是从github等开源平台入手（适用于体量较大的目标），有些开发者可能关注到员工账密、员工个人信息等敏感信息的脱敏，但是忘记了对AK与AS进行脱敏，在通过github查询目标的各种信息时，要留意一下有没有泄露AK与AS。如下图，就是从github上发现了相关信息

我们最后介绍一种实战中容易碰见的，并且也是危害性最大的——在JS文件甚至是文件上传数据包中发现AK与AS。在介绍这种情况之前，可以简单的了解一下文件上传到OSS服务器过程中的三种经典验证方式。

① 在客户端通过JavaScript代码完成签名，然后通过表单直传数据到OSS。② 在服务端完成签名，然后通过表单直传数据到OSS。③ 在服务端完成签名，并且服务端设置了上传后回调，然后通过表单直传数据到OSS。OSS回调完成后，再将应用服务器响应结果返回给客户端。

当我们在文件上传处看到下图类似的字样时，基本可以判断这是使用OSS进行文件存储（还有一个常见特征是OSS文件存储分多步进行，一个文件上传操作会产生好几个数据包，普通的文件上传操作基本只用一个数据包即可完成）。当看到这个特征时，攻击者要马上反应过来——到JS文件中尝试寻找AK与AS

为什么呢？我们不难看出，上文提到的第一种方式是非常危险的。因为AK与AS写死在前端文件了，这意味着我们只需要花点时间就可以找到他。如下图就是在JS文件中分析出的明文AK与AS。攻击者也可以自己动手，开发工具来尝试读取JS中的这类关键词从而节省人工寻找的时间！

还有一些粗心的开发人员甚至直接在数据包中明文传递AK与AS，这无疑是为攻击者提供了便利，注意OSS上传数据包中传递的这些数据，它们也很有可能是明文的AK与AS！

0X03 如何利用AK与AS

上文总结了常见的AK与AS泄露情况，那么攻击方人员如果拿到了AK与AS，应该如何去利用？其实获得这两个信息之后允许攻击者做出非常多危险的操作。上至命令执行，下至文件泄露，本文也着重介绍一下这两种攻击手法。

Github上有相当多的AK与AS利用工具，基本上覆盖了所有主流的云厂商，足够满足我们正常攻击中的各种需求，本文就以阿里云AK与AS泄露来演示其利用。使用下图的这款工具

可以以root权限执行任意命令，在这种情况下等于直接拿下目标服务器的权限。据了解AWS提供的OSS服务一旦泄露AK与AS，也可以造成类似的命令执行问题，笔者未对其它主流厂商提供的服务进行了解与实践，各攻击队可以自行研究尝试。

以上便是AK与AS最具威胁性的一种利用方式。下面介绍一种威胁性稍小的，就是任意文件的上传下载。上文提到了笔者使用AK与AS进入了OSS服务并且完成了任意文件的上传下载。这其中我们借助的就是这个MinIO Browser，攻击队如果在资产搜集的过程中遇到了类似的、使用AK与AS进行验证的资产，应该也可以使用类似的方式登陆进去并对其接管。

当然，通过OSS Browser、行云管家之类的现成的工具，攻击者也可以方便快捷的对OSS服务进行接管

0X04 攻击层面上的一些小思考

上文主要介绍了两种对OSS的攻击方式，但是在利用方法上，还是能衍生出非常多有意思的点的。比方说命令执行来说，既然我们可以用root方式进行命令执行，那么我们拿下一台低权限机器的时候，是否可以通过寻找AK与AS实现提权？再比如说任意文件上传下载，虽然OSS服务上的文件不支持解析，但是我们是否可以通过替换一些文件（比方说目标网站支持下载文件之类的功能），从而实现投毒？在利用层面上，OSS服务也可以衍生出许多“异想天开”的攻击方法，值得攻击者深入思考！

0X05 结语

随着中国互联网的不断进步，OSS存储服务这类相较于传统上传方式有大量优点的云存储模式毫无疑问会逐渐成为主流，这是互联网发展的大势所趋。因此在往后的攻防演练、渗透测试中，攻击者会遇到越来越多的OSS服务以及相关的云服务，深入研究分析其攻防技术是必不可少的，本文以实战中遇到的案例为引，简单总结了实战中关于OSS服务攻击的一些常见情况，希望能起抛砖引玉之效用！

多云问题

多云与混合IT环境安全

看来多云、混合IT架构在国外已相当普遍，对安全确实提出了更迫切的挑战。

同时由于云和容器的广泛流行，也催生了更复杂的混合IT环境，包括裸金属服务器、VM和容器多种形态的工作负载。混合IT环境则要求安全产品必须适配这样的环境。

多云环境其实是用户出于业务安全、经济等考虑下的无奈选择，而混合IT环境又加大了管理的复杂性。多云环境下的管理很复杂，造成运营成本非常高，例如多云环境下的资源管理、配置管理、编排、账号权限甚至可视化需求等等，尤其是Devops落地到多云环境下，会面临非常大的挑战。

云上安全的热点向云上应用安全和数据安全转移，Trust是重要控制点

公有云的基础设施安全由公有云服务商来负责。国内由于私有云的大量存在，云基础设施安全留给安全厂商很大空间，但限于复杂度，能有整体能力的厂商不多

而随着用户将越来越多的应用迁移到云上，云上数据安全越来越重要。这其中身份认证、访问控制和数据安全是最重要的控制点。

云原生安全问题非常值得关注

容器技术被广泛认可和大量应用，为容器安全孕育了较大的潜在市场空间。本次不管是session还是参展厂商，都有很多涉及容器安全的内容，容器安全尚未有很完整的体系，技术思路也有待实际验证。但市场不等人，容器已经在广泛应用，runc漏洞被广泛关注就是一例。

容器生命周期安全

容器和Devops的融合非常紧密

根据近期一项由谷歌委托IDG所作的调研，在2000名来自全球各地的IT领导中，约有85%的受访者表示他们对云端安全的信赖程度，等于或已经超过其对本地数据基础设施的信赖程度。

这个结论有点违背直觉，但现实就是这样：多数情况下，数据异地存储会更加安全。云计算可以消除诸多本地威胁风险，如员工桀骜不驯、窃贼破门而入、发生自然灾害、出现紧急事件，以及其他风险。此外，云厂商越来越倾向于采用更加积极主动的手段对云端安全措施进行修复和更新，其安全等级远远高于组织的自有标准。

云安全的变化

越来越多的企业应用、数据和过程迁移到云端，最终用户也越来越倾向于将自己的安全外包给云提供商。

行业调查表明，很多企业都认为需要自己掌控安全，而不是将最终责任交托给云提供商。咨询了241位行业专家后，云安全联盟（CSA）在其调查报告“Egregious 11”中列出了11个重大云安全问题。

这份调查报告的编撰者指出，今年很多紧迫问题的安全责任都推到了最终用户公司身上，而不是依赖服务提供商解决。“我们注意到，云服务提供商负责的传统云安全问题的排名有所下降。上一份‘Treacherous 12’报告中出现的问题，例如拒绝服务、共享技术漏洞、云服务提供商（CSP）数据丢失和系统漏洞等，现在的排名都低到直接排除在本次报告之外了。这些问题的缺席表明，由CSP负责的传统安全问题似乎不再那么令人担忧。与之相反，高级管理层决策导致的安全问题，也就是技术栈更高层次上的的安全问题，则更有待我们解决。”

CSA的研究结果与Forbes Insights和VMware最近的另一项调查结果相符：积极主动的公司纷纷忍住将安全托付给云提供商的诱惑——仅31%的主管将很多安全措施交托给云提供商。但仍然有94%的受访者采用云服务来处理某些安全事务。

最新的CSA报告凸显了今年的主要问题

1. 数据泄露。“网络攻击的主要目标逐渐指向数据。对拥有数据或处理数据的企业而言，确定数据的商业价值和数据丢失的影响至关重要。此外，数据保护正演变成谁有权访问数据的问题。加密技术有助于保护数据，但会对系统性能造成不利影响，同时还会降低应用的易用性。”

2. 错误配置和变更控制不足。“云资源不仅相当复杂，而且高度动态，因而配置难度颇高。在云环境中，传统的控制措施和变更管理方法不再有效。公司应积极实现自动化，采用各项技术持续扫描资源错误配置情况并实时修复问题。”

3. 缺乏云安全架构和策略。“确保安全架构符合业务目标。开发并实现安全架构框架。”

4. 缺乏身份、凭证、权限和密钥管理。“采用双因素身份验证和限制使用root账户等方式保护账户安全。对云用户和云身份采取最严格的身份和访问控制措施。”

5. 账户劫持。这是个必须严阵以待的威胁。“深度防御和身份与访问管理（IAM）控制措施是缓解账户劫持的关键。”

6. 内部人威胁。“采取措施尽可能地减少内部疏忽有助于缓解内部人威胁造成的影响。为公司安全团队提供培训，使其掌握正确安装、配置和监测计算机系统、网络、移动设备和备份设备的技能。此外，普通员工也需要进行安全意识培训，要教会他们如何处理安全风险，比如怎样应对网络钓鱼，以及如何保护他们存在笔记本电脑和手机上带出公司的企业数据。”

7. 不安全的接口和API。“保持良好的API安全状态。在这方面，可采取的良好实践包括尽职监督库存、测试、审计和异常活动防护等项目。此外，不妨考虑采用标准的开放API框架（例如，开放云计算接口（OCCI）和云基础设施管理接口（CIMI））。”

8. 弱控制平面。“云客户应该进行尽职调查，确定自己打算使用的云服务是否拥有足够的控制平面。”

9. 元结构和应用结构故障。“云服务提供商必须提供可见性并公开缓解措施，从而消解云计算固有的租户透明度缺乏问题。所有云服务提供商都应执行渗透测试并向客户提供测试结果。”

10. 云使用可见性有限。“风险缓解始于自上而下的完整云可见性。要求在全公司范围内就公认的云使用策略及其实施进行培训。所有未核准云服务必须经过云安全架构师或第三方风险管理人员的审核和批准。”

11. 云服务滥用及恶意使用。“企业应监控其云端员工行为，因为传统机制无法缓解云服务使用带来的风险。”

日志文件和审计报告

许多组织会惊讶地发现，没有NIST标准规定日志文件应保留30天以上。考虑到日志中存在的大量信息，30天的保留期太短，对于组织，尤其是大型企业而言，这对于安全报告来说是一个重大的挑战。

考虑到企业平均需要四个月以上的时间才能检测到数据泄露，因此当前的30天限制根本无法满足需要。扩展的审核日志保留功能可确保IT团队拥有调查安全事件溯源所需的取证数据，也是遵守GDPR等数据隐私法规的关键一步。

共同责任

云（数据）安全的问责是个十分让人头疼的问题，尤其是在使用多云或混合云环境的企业中。

SaaS之类的高级云平台需要大量IT驱动的安全职责。在PaaS和SaaS解决方案中，身份和访问管理是一项共同的职责，需要有效的实施计划，其中包括身份提供者的配置、管理服务的配置、用户身份的建立和配置以及服务访问控制的实现。

随着全球企业数字化转型计划的推进和大流行期间远程办公的流行，越来越多的组织将业务应用迁移到云托管环境中。尽管云计算责任分担模型明确规定了云提供商及其用户的安全义务以确保问责制度，但可见性和安全监控应用程序仍存在空白，需要解决。

随着越来越多的企业选择云计算节省成本和改进业务，企业比以往任何时候都更需要弥合可见性和安全监控的差距以实现最高安全性。

管理员角色和规则

微软应用管理员（Microsoft Application Administrator）包含大约有75个属性，但是几乎没有人（无论微软还是企业IT人士）确切了解它们的含义。如果授予用户Application Administrator权限，则几乎不可能确切知道该用户具有哪种访问权限，从而带来不必要的安全风险。

尽管IT员工在工作中经常需要执行某些功能，例如创建新的用户账户和更改密码，但是这些“流动性”较强的功能并不容易归属到某个特定的角色。这种流动性使传统安全方法（例如基于角色的访问控制）的效力被削弱。

值得注意的是，NIST在管理员角色和规则方面也并非毫无作为，功能访问控制（FAC）就是其中之一。RBAC是实现最低特权访问的一种方法，而功能访问控制（FAC）是实现RBAC的一种方法。

作为NIST认可的方法，FAC为IT管理员的功能权限提供了一种更细粒度的分配方法，使企业能够调整特定用户访问权限的大小，从而改善安全性。

云安全联盟发布了一份关于云计算面临的最大威胁的报告，

提出云服务提供商存在 11 项安全问题：

1. 数据泄露；

2. 配置错误、变更控制不足；

3. 缺乏云安全架构和策略；

4. 身份、凭证、访问和密钥管理不足；

5. 账户劫持；

6. 内部威胁；

7. 接口、API不安全；

8. 控制面弱；

9. 元结构和应用结构失效；

10. 云使用可见性有限；

11. 滥用、恶意使用云服务。

众多公有云上的企业用户正在面临：

一缺安全工具；

二缺运维能力；

三缺系统管理流程。

此运营现状下，如何保障自身云上业务安全？如何以较低成本获取专业的安全服务？如何从纷繁复杂的公有云云市场中找到对症良药？如何满足等保、合规等行业要求？

云安全确实存在缺失，要填补这些缺失第一步就需要我们有能力对其加以识别。

本地安全与合规模式无法复制到云端

如果您是在云端经营业务，就相当于您在别人的地盘上玩耍，你将不得不遵循人家制定的各项规则。另外，尽管云厂商已经部署了相当高效的安全解决方案，但与我们投入了大量时间和努力所构建的本地安全相比，云端安全解决方法很少有与本地安全解决方案有完全相同的情况。那么问题来了，当我们迁移到云端后，我们原来的安全投资会遇什么样的情况呢？上云后，风险消失了，但对我们来说异常重要的数据可视化也没有了。

对可视化的担心，也扩展到了合规模式上来。随着新的法规不断颁布，以及更多法规正在制定之中，主管部门正在采取更为主动的方式来确保数据实践的安全和道德。数据合规从来没有像今天这样重要过。如果在合规性方面与法规所规定的相左，将会招致非常严重的后果，包括罚款、领导被送监，甚至是涉事企业被依法注销。但很不幸的是，对于云数据合规我们很难去完全定义它。即便是您将数据完全托管于云厂商，对于数据可靠性您也必须承担一定的责任。如果您没有能力决定采用何种合规模式，您对结果的控制力就会相当有限。

很难通过改进云端英语来满足安全控制要求

云端安全性的缺失也会延展至云端应用。对于云应用，一方面组织离不开它，另一方面在安全性方面可能并不满足组织的安全标准。当然，我们可以对应用进行改进，或者提升某些应用的安全性，但要实现这些却是耗时耗力、花费不菲且异常复杂。如果您没有一定的资源、人力以及资金的支持，就无法完成对云端应用的改进，也就无法满足组织对安全控制的要求，最终将不得不转向其他解决方案寻求帮助。

很多情况下（或者说绝大多数情况下），数据托管于云端要比托管于本地更加安全，您的商誉也能受到更好地保障。但即便如此，云端安全的缺失也是不争的事实。要实现对云数据的最佳保护，你需要实现云端可视化

预测1：无服务器采用将推动云安全自动化

随着组织越来越多地转向无服务器架构，他们也发现了更多的云安全自动化用例，因为无服务器功能提供了一种启动安全逻辑作为云计算事件响应的方法。其示例包括：当服务滥用、拒绝服务攻击或加密时，云帐户计费开支出现峰值或异常;当有人试图在正常部署管道之外部署新的云计算资产/服务或代码时;或作为部署管道的一部分对新代码或云资源运行合规性检查。

预测2：云计算提供商将在安全方面发挥重要作用

随着2018年无服务器的采用激增，更多的团队选择从基于容器的架构切换到无服务器，或者简单地一起跳过容器。原因?现在越来越多的系统组件被抽象，随后，它们需要更少的管理。云计算安全也是如此。无服务器体系结构是迄今为止云计算的最高抽象，这使得应用程序所有者只负责应用程序层和云配置中的安全性。结果，组织的大部分安全责任现在都交给了云计算提供商。这包括物理安全、操作系统安全配置和补丁、网络安全以及虚拟机或容器安全。

预测3：期待看到更多的云原生指南和研究

2018年，一些行业分析师发布了有关云原生技术的研究论文和建议，Gartner公司的NeilMacDonald通过研究安全注意事项和保护无服务器PaaS的最佳实践，引领无服务器领域。我预计分析师将在2019年更加关注云原生安全性，特别是无服务器安全性，因为组织继续对其应用程序进行现代化并寻求帮助来确定正确的安全策略。

预测4：多云部署中对安全支持的需求下降

在2017年和2018年，云计算供应商锁定主题备受关注。因此，云计算安全供应商需要回答有关他们对多云部署的支持的问题。在2018年末，云计算行业的一些思想领袖呼吁云供应商锁定主要是恐惧，不确定和怀疑(FUD)。正如英国前缘论坛研究员兼WardleyMaps的首席执行官SimonWardley,所说：“拥有一个竞争环境，可以在不同的供应商之间切换，这将是一件好事。但这是次要的功能和功能。我们预计会看到越来越少关注此主题，云安全供应商将看到支持多云部署的需求减少。”

预测5：安全性将向左移动更多

随着越来越多的系统组件成为云计算提供商的责任，应用程序所有者将发现自己在基础设施、操作系统和网络安全方面的交易较少。安全责任的这种转变在无服务器架构中最大化，其中应用程序所有者的唯一责任在于应用程序层。因此，组织将看到内部转变，传统企业IT安全团队在企业范围内的高级安全策略中的参与程度要低得多。另一方面，期望开发团队更多地参与并负责安全性，这将推动DevSecOps运动的采用。

预测6：传统安全厂商将转向云原生安全

2018年，传统安全供应商开始进行战略性工作，以实现其安全产品的现代化并适应云原生环境。最近的例子包括收购了Evident.io和RedLock的PaloAltoNetworks，以及最近收购了Dome9的CheckPoint。这种趋势预计将在2019年继续，因为供应商意识到云计算不仅仅是创业公司的领域，而且还被大公司、金融服务、医疗保健甚至政府机构采用。底线：组织现在认识到公共云基础架构的安全性不低于内部部署，云计算供应商将提供高级别的安全性。

虚拟化安全问题

云原生安全问题

应用架构和云计算模式的变革是否会导致进一步的风险，这些风险较之传统应用风险又有哪些区别。在讲述云原生应用具体风险前，笔者首先提出以下三个观点，这些观点有助于各位读者较好的理解本文所讲述的内容。

观点一：云原生应用继承了传统应用的风险和API的风险

云原生应用源于传统应用，因而云原生应用风险也就继承了传统应用的风险。此外，由于云原生应用架构的变化进而导致应用API交互的增多，可以说云原生应用中大部分交互模式已从Web请求/响应转向各类API请求/响应 ，例如RESTful/HTTP、gRPC等，因而API风险也进一步提升。

观点二：应用架构变革将会带来新的风险

由于应用架构变革，云原生应用遵循面向微服务化的设计方式，从而导致功能组件化、服务数量激增、配置复杂等问题，进而为云原生应用和业务带来了新的风险。

观点三：计算模式变革将会带来新的风险

随着云计算的不断发展，企业在应用的微服务化后，会进一步聚焦于业务自身，并将功能函数化，因而出现了无服务器计算（Serverless Computing）这类新的云计算模式，进而引入了Serverless应用和Serverless平台的新风险。

综上，我们可以看出云原生应用带来的风险是不容小觑的，本文笔者将从传统应用风险、应用架构变革带来的新风险、云计算模式变革带来的新风险三个维度为各位读者分别进行介绍，希望可以引发大家更多的思考。

传统应用面临的风险

由于云原生应用也是应用，因而云原生应用风险可以参考传统应用风险，传统应用风险则以Web应用风险为主，主要包含注入、敏感数据泄露、跨站脚本、使用含有已知漏洞的组件、不足的日志记录和监控等风险。

此外，云原生环境中，应用的API交互模式逐渐由“人机交互”转变为“机机交互”，虽然API大量出现是云原生环境的一大特点，但本质上来说，API风险并无新的变化，因而其风险可以参考现有的API风险，主要包含安全性错误配置、注入、资产管理不当、资源缺失和速率限制等风险。

有关传统应用风险和API风险的更多细节可以分别参考OWASP组织在2017和2019年发布的应用十大风险报告[1]和API十大风险报告[2]。

应用架构变革带来的新风险

3.1 云原生应用带来的新风险

云原生应用面临的新风险主要“新”在哪里，笔者看来“新”主要体现在新应用架构的出现，我们知道，新应用架构遵循微服务化的设计模式，通过应用的微服务化，我们能够构建容错性好、易于管理的松耦合系统，与此同时，新应用架构的出现也会引入新的风险，为了较为完整地对风险进行分析，本文我们将以信息系统安全等级三要素，即机密性（Confidentiality）、完整性（Integrity）、可用性（Availability）作为导向为各位读者介绍应用架构变化带来的新风险。

• 机密性受损的风险

典型的如信息泄露风险，攻击者可通过利用资产脆弱性和嗅探、暴力破解等攻击方式窃取用户隐私数据，从而造成信息泄露风险。

• 完整性受损的风险

典型的如未授权访问风险，攻击者可通过利用资产脆弱性和中间人攻击等行为绕过系统的认证授权机制，执行越权操作，从而造成未授权访问的风险。

• 可用性受损的风险

典型的如系统被拒绝服务的风险，一方面，攻击者可通过畸形报文、SYN泛洪等攻击方式为目标系统提供非正常服务，另一方面，系统供不应求的场景也会导致系统遭受拒绝服务风险。

本小节接下来的内容，将以“信息泄露”、“未授权访问”、“拒绝服务”为例，分别介绍上述三类风险。

3.1.1 数据泄露的风险

云原生环境中，虽然造成应用数据泄露风险的原因有很多，但都离不开以下几个因素：

应用漏洞：通过资产漏洞对应用数据进行窃取。

密钥不规范管理：通过不规范的密钥管理对应用数据进行窃取。

应用间通信未经加密：通过应用间通信未经加密的缺陷对传输中数据进行窃取，进而升级到对应用数据的窃取。

3.1.1.1 应用漏洞带来的风险

我们知道，应用中存储的数据多是基于API进行访问，若应用中某API含有未授权访问漏洞，例如Redis未授权访问漏洞，攻击者便可利用此漏洞绕过Redis认证机制，访问到内部数据，进而导致了敏感信息泄露的风险。

传统单体应用架构下，由于API访问范围为用户到应用，攻击者只能看到外部进入至应用的流量，无法看到应用内部的流量，所以针对恶意使用API漏洞进行数据窃取造成的损失范围通常是有限的。

反观微服务化应用架构，当单体应用被拆分为若干个服务后，这些服务会根据业务情况进行相互访问，API访问范围变为服务到服务（Service to Service），若某服务因API漏洞导致攻击者有利可图，那么攻击者将会看到应用内部的流量，这无疑为攻击者提供了更多的攻击渠道，因而针对数据泄露的风险程度而言，微服务架构相比传统单体应用架构带来的风险更大。此外，随着服务数量达到一定规模，API数量将不断递增，进而扩大了攻击面，增大了数据泄露的风险。

3.1.1.2 密钥不规范管理带来的风险

在应用的开发过程中，开发者常疏于对密钥的管理从而导致数据泄露的风险，例如开发者将密钥信息、数据库连接密码等敏感信息硬编码在应用程序中，从而增大了诸如应用程序日志泄露、应用程序访问访问密钥泄露的风险。

传统单体应用架构中，开发者常将配置连同应用一起打包，当需要修改配置时，只需登录至服务端进行相应修改，再对应用进行重启便可实现，这种单个集中式配置文件的存储方式从密钥管理风险的角度上讲是相对可控的。

微服务应用架构中，应用的配置数量与服务数量的逐渐增多是成正比的，例如微服务应用中会存在各种服务、各种数据库访问、各种环境变量的配置，且各配置支持动态调整。同时，微服务应用架构对服务的配置管理也提出了更高的要求，例如代码与配置可分离、配置支持分布式、配置更新的实时性、配置可统一进行治理等，因而微服务下的配置管理更加复杂，对运维人员的要求更高，密钥管理的难度也在不断提升，最终会造成更大的数据泄露风险。

3.1.1.3 应用通信未经加密带来的风险

如我们所知，如果应用采用HTTP协议进行数据传输，那么HTTP页面的所有信息将都以纯文本形式进行传输，默认是不提供任何加密措施的，因而在数据传输过程中易被攻击者监听、截获和篡改，典型的攻击流程为攻击者通过Fiddler、Wireshark等抓包工具进行流量监听，之后截获传输的敏感信息，例如数据库密码，登录密码等，最后攻击者根据自身意图对敏感数据进行篡改并发送至服务端，进而导致数据泄露的风险。

传统单体应用架构中，由于网络拓扑相对简单，且应用通信多基于HTTP/HTTPS，因而造成的数据泄露风险多是因为采用了HTTP协议。微服务应用架构中，网络拓扑相对复杂，因遵循分布式的特点，应用间的通信不仅采用HTTP/HTTPS协议，还采用gRPC等协议，由于gRPC协议默认不加密，因而将会导致攻击面的增多，为数据泄露带来了更多的风险。

3.1.2 未授权访问的风险

云原生环境中，应用未授权访问的风险多是由于应用自身漏洞或访问权限错误的配置导致。

3.1.2.1 应用漏洞带来的风险

应用漏洞是造成未授权访问的一大因素，如我们所知，未授权访问漏洞非常之多，较为常用的如Redis、MongoDB、Jenkins、Docker、Zookeeper、Hadoop等应用都曾曝光过相关漏洞，例如Docker曝出的Docker Remote API未授权访问漏洞，攻击者可通过Docker Client或HTTP请求直接访问Docker Remote API，进而对容器进行新建、删除、暂停等危险操作，甚至是获取宿主机shell权限。再如MongoDB未授权访问漏洞，该漏洞造成的根本原因在于MongoDB在启动时将认证信息默认设置为空口令，从而导致登录用户可通过默认端口无须密码对数据库进行任意操作并且可以远程访问数据库。

从漏洞成因的出发点来看，认证及授权机制的薄弱是其主要原因，在单体应用架构下，应用作为一个整体对用户进行认证授权，且应用的访问来源相对单一，基本为浏览器，因而风险是相对可控的，微服务应用架构下，其包含的所有服务均需对各自的访问进行授权，从而明确当前用户的访问控制权限，此外，服务的访问来源除了用户外还包含内部的其他服务，因而在微服务架构下，应用的认证授权机制更为复杂，为云原生应用带来了更多的攻击面。

3.1.2.2 访问权限错误配置带来的风险

由于运维人员对用户的访问权限进行了错误配置，进而会增大被攻击者利用的风险。例如，运维人员对Web应用访问权限进行相应配置，针对普通用户，运维人员应只赋予其只读操作，若运维人员进行了错误的配置，例如为普通用户配置了写操作，那么攻击者便会利用此缺陷绕过认证访问机制对应用发起未授权访问攻击。

传统应用架构中，应用由于设计相对单一的特点，其访问权限也相对单一，几乎只涉及用户对应用的访问权限这一层面，因此对应的访问权限配置也相对简单，诚然，也因访问权限配置简单的特点，用户身份凭据等所有敏感信息常存储在应用的服务端，一旦攻击者利用配置的缺陷对应用发起未授权访问入侵，就有可能拿到所有保存在后端的数据，从而造成巨大风险。

微服务应用架构下，由于访问权限还需涉及服务对服务这一层面，因此将会导致权限映射关系变得更加复杂，相应的权限配置难度也在同步增加，例如一个复杂应用被拆分为100个服务，运维人员需要精密地对每个服务赋予其应有的权限，如果因疏忽导致为某个服务配置了错误的权限，攻击者就有可能利用此缺陷对服务展开攻击，若该服务中包含漏洞，进而可能会导致单一漏洞扩展至整个应用的风险。所以如何对云原生应用的访问权限进行高效率管理成为了一个较难的问题，这也是导致其风险的关键因素。

3.1.3 被拒绝服务的风险

被拒绝服务是应用程序的面临的常见风险，笔者看来，造成拒绝服务的主要原因包含两方面，一方面是由于应用自身漏洞所致，例如ReDoS漏洞、Nginx拒绝服务漏洞等。另一方面是由于访问需求与资源能力不匹配所致，例如某电商平台的购买API由于处理请求能力有限，因而无法面对突如其来的大量购买请求，导致了平台资源（CPU、内存、网络）的耗尽甚至崩溃，这种场景往往不带有恶意企图，而带有恶意企图的则主要以ACK、SYNC泛洪攻击及CC（Challenge Collapsar）等攻击为主，其最终目的也是应用资源的耗尽。

3.1.3.1 应用漏洞带来的风险

应用漏洞可以导致应用被拒绝服务，那么具体是如何导致的呢？以ReDoS（Regular expression Denial of Service）漏洞为例，ReDoS为正则表达式拒绝服务，攻击者对该漏洞的利用通常是这样的一个场景，应用程序为用户提供了正则表达式的输入类型又没有对具体的输入进行有效验证，那么攻击者便可通过构造解析效率极低的正则表达式作为输入进而在短时间内引发100%的CPU占用率，最终导致资源耗尽，甚至应用程序崩溃的风险。

3.1.3.2 访问需求与资源能力不匹配带来的风险

此处笔者以CC攻击举例，其攻击原理通常是攻击者通过控制僵尸网络、肉鸡或代理服务器不断地向目标主机发送大量合法请求，从而使正常用户的请求处理变得异常缓慢。

传统Web场景中，攻击者利用代理服务器向受害者发起大量HTTP GET请求，该请求主要通过动态页面向数据库发送访问操作，通过大量的连接，数据库负载极高，超过其正常处理能力，从而无法响应正常请求，并最终导致服务器宕机。

在微服务应用架构下，由于API数量会随着服务数量的递增而递增，因而可能将会导致单一请求生成数以万计的复杂中间层和后端服务调用，进而更容易引起被拒绝服务的风险，例如若微服务应用的API设计未考虑太多因单个API调用引起的耗时问题，那么当外部访问量突增时，将会导致访问需求与资源能力不匹配的问题，使服务端无法对请求作出及时的响应，造成页面卡死的现象，进而会引起系统崩溃的风险。

3.2 云原生业务带来的新风险

在之前的概述小节中，笔者提到应用架构的变革也会为云原生应用业务带来新的风险，说到此处，读者们可能会产生疑问，云原生应用业务风险和上一小节提到的云原生应用风险有何区别，笔者看来，云原生应用风险主要是Web应用风险，即网络层面的风险，而云原生应用业务风险无明显的网络攻击特征，多是利用业务系统的漏洞或规则对业务系统进行攻击来牟利，从而造成一定的损失。

此外，与传统应用架构中的业务风险不同，微服务应用架构中，若服务间的安全措施不完善，例如用户授权不恰当、请求来源校验不严格等，将会导致针对微服务业务层面的攻击变得更加容易，例如针对一个电商应用，攻击者可以对特定的服务进行攻击，例如通过API传入非法数据，或者直接修改服务的数据库系统等。攻击者可以绕过验证码服务，直接调用订单管理服务来进行薅羊毛等恶意操作。攻击者甚至可以通过直接修改订单管理和支付所对应的服务系统，绕过支付的步骤，直接成功购买商品等。

综上，笔者认为，应用微服务化的设计模式带来的业务风险可包含两方面，一方面是未授权访问风险，典型场景为攻击者通过权限绕过对业务系统的关键参数进行修改从而造成业务损失，另一方面则是API滥用的风险，典型的是对业务系统的薅羊毛操作。

3.2.1 未授权访问的风险

云原生业务环境中，笔者针对造成未授权访问风险的原因进行了分析，可以大致分为业务参数异常和业务逻辑异常两方面，为了更为清晰的说明上述异常如何导致未授权访问的风险，笔者以一个微服务架构的电商系统举例说明。如图1所示：

图1 某电商系统流程图

3.2.1.1 业务参数异常带来的风险

API调用过程中往往会传递相关的参数。参数的取值根据业务场景的不同会有不同的取值范围。例如商品数量必须为非负整数，价格必须大于0等。若API对相应参数的监测机制不完善，那么攻击者便可通过输入异常参数导致业务系统受到损失。例如在图1所示的电商系统中，若商品价格只在商品介绍服务中进行校验，而未在订单管理和支付服务中进行校验，那么攻击者则可以通过直接调用订单管理和支付服务的API将订单价格修改为0元或者负值，从而给业务系统造成损失。

3.2.1.2 业务逻辑异常带来的风险

相比于前一类异常，此类异常一般较为隐蔽。攻击者采用某些方法使API调用的逻辑顺序出现异常，包括关键调用步骤缺失、颠倒等。例如在图1所示的电商系统中，攻击者可以利用漏洞绕过支付的步骤直接提交订单。这样就会出现业务逻辑关键步骤缺失的情况，进而会为业务系统带来损失，例如验证码绕过异常就属于业务逻辑异常的一种。

3.2.2 滥用的风险

针对此类风险，通常指的是攻击者对业务系统的薅羊毛操作，风险成因则是由于业务频率异常所致，这里笔者依然以电商系统举例说明。

业务频率异常主要指针对一个或一组API的频繁调用，如我们所知，业务系统往往通过图形验证码的方式来避免机器人刷单的操作。例如在图1所示的电商系统中，攻击者可以绕过验证码所对应的服务，直接对订单进行操作，进而实现机器刷单，对电商进行薅羊毛。

云计算模式变革带来的新风险

作为一种新的云计算模式，Serverless具备许多特性，典型的主要有输入源的不确定性、服务器托管云服务商、供应商锁定等，这些特性可能会给Serverless带来新的风险。

此外，由于Serverless最终呈现的还是多个函数组成的应用，且被Serverless提供的服务端运行，因此Serverless风险还应包括Serverless应用的风险及Serverless平台的风险。

最后Serverless因购买、部署成本低、函数访问域名相对可信等将会使Serverless面临被滥用的风险。

本节笔者将针对以上提到的风险进行一一分析。

4.1 Serverless特征带来的风险

4.1.1 输入源不确定带来的风险

在讲述输入源的不确定性可以带来什么风险前，可能会有读者想了解为什么输入源的不确定性会带来风险，我们知道，Serverless函数是由一系列事件触发的，如云存储事件（S3,Blobs和其他云存储）、流数据处理（如：AWS Kinesis）、通知（如：SMS、电子邮件、IoT）等，鉴于此特性，我们不应该把来自API调用的输入作为唯一攻击面。此外，我们不再控制源到资源间的这条线，如果函数被邮件或数据库触发，将无处可设置防火墙或任何其他控制措施来验证事件源[4]。可见输入源的不确定性将可能导致一定的风险。

在传统应用程序开发中，开发者根据自身实践经验，在数量有限的可能性中可判定出恶意输入来源，但Serverless模式下函数调用是由事件源触发，输入来源的不确定性限制了开发者的判定。例如当函数订阅一个事件源后，该函数在该类型的事件发生时被触发，这些事件可能来源于FaaS平台，也可能来源于未知的事件源，对于来源未知的事件源可以被标注为不受信任。在实际应用场景中，如果开发者没有良好的习惯对事件源进行分类，则会经常导致将不受信任的事件错认为是FaaS平台事件，进而将其视为受信任的输入来处理，最终带来了风险。

具体地，输入来源的不确定性会为Serverless应用带来注入的风险，与传统应用相同的是，注入攻击过程与并无太大区别，不同的是攻击向量得变化，传统应用中用于注入攻击的向量通常指攻击者可以控制或操纵应用输入的任何位置，但Serverless应用由于输入得不确定性因而带来了更大的攻击面。

4.1.2 服务托管云服务厂商带来的风险

传统应用中，例如Web应用常部署在本地/远程服务器上，关于服务端的操作系统漏洞修补、网络拓扑的安全、应用在服务端的访问日志及监控等均需要特定的运维人员去处理，而Serverless的服务器托管云服务商的特点将导致开发者无法感知到服务器的存在，实际上开发者也无须对服务器进行操作，只需关注应用本身的安全即可，服务器的安全则交由云厂商管理，所以在我们也可以认为Serverless的这一特征实际上降低了安全风险。

4.1.3 供应商锁定带来的风险

“供应商锁定”是指用户依赖特定供应商提供的产品及服务，并且在不产生实质性转换成本或运营影响的情况下无法使用其他供应商的云服务，在Serverless中，“供应商锁定”是目前存在的一大问题，例如用户选择AWS作为应用的运行环境，由于一些原因，该应用需迁移至Microsoft Azure平台，但“供应商锁定”的问题导致无法轻易得将之前运行的应用及使用的相应资源如S3存储桶等平滑迁移至Microsoft Azure平台中，进而导致企业面临应用转换成本的风险。

4.2 Serverless应用风险

Serverless应用属于云原生应用，其应用本身与传统应用基本是相同的，唯一区别是应用代码编写需要参照云厂商提供的特有代码模版，而传统应用通常没有这个限制。

Serverless应用属于云原生应用，云原生应用又源于传统应用，因而传统应用面临的风险几乎可以全面覆盖Serverless应用风险，关于风险分析部分我们可以参考之前传统应用风险的内容，更详细的内容可以参考OWASP组织在2017年发布的Serverless应用十大风险报告[4]。

4.3 Serverless平台风险

Serverless平台主要指FaaS平台，目前主流的FaaS平台分为两种类型，一种是面向公有云提供商的FaaS平台，常见的有AWS Lambda、Microsoft Azure Functions、Google Cloud Functions等，另一方面则是面向私有云的FaaS平台，此类以开源项目居多，且均支持在Kubernetes上进行部署，常见的有Apache OpenWhisk[7]、Kubeless[8]、OpenFaaS[9]、Fission[10]等。类似在IaaS平台上运行虚机、PaaS平台上运行操作系统和应用，FaaS平台较之上述平台的主要区别为其运行的是一个个Serverless函数。FaaS平台自身负责云环境地安全管理，主要包括数据、存储、网络、计算、操作系统等。

如IaaS平台，PaaS平台一样，FaaS平台也面临未授权访问和数据泄露的风险。例如AWS Lambda平台由于自身函数运行时的脆弱性将会导致攻击者轻易拿到运行时shell，结合脆弱的访问权限错误配置可以最终达到攻击目的，这一部分的详细内容可以参考笔者之前在绿盟研究通讯公众号发表的《【云原生攻防研究 】针对AWS Lambda的运行时攻击》文章。

此外，与其他云计算模式不同的是，Serverless为FaaS平台引入了新的攻击源，例如针对FaaS平台账户的拒绝钱包服务攻击，因而Serverless将面临FaaS平台账户的风险，针对此特定类型的攻击解析可参考笔者之前在绿盟研究通讯公众号发表的《Serverless安全研究 — Serverless安全风险》文章。

4.4 Serverless被滥用的风险

Serverless被滥用指具体是指攻击者通过恶意构建Serverless函数并利用其充当整个攻击中的一环，这种方式可在一定程度上规避安全设备的检测，导致Serverless被滥用的原因个人认为主要包括以下几点：

• 云厂商提供Serverless函数的免费试用

近些年，各大云厂商为了用户体验，均对用户提供免费的Serverless套餐，包括每月免费的函数调用额度，这种方式虽然吸引了更多的用户去使用Serverless函数, 但也使得攻击者的攻击成本大幅降低。

• 用户部署Serverless函数的成本低

由于Serverless服务端托管云厂商的机制，故用户只需实现函数的核心逻辑，而无须关心函数是如何被部署及执行的，利用这些特点，攻击者可以编写对其有利的Serverless函数并能省去部署的成本。

• Serverless函数访问域名可信

当用户部署完Serverless函数后，需要通过触发器去触发函数的执行，通常用户使用云厂商提供的API网关作为触发器，创建API网关触发器之后，云厂商会为用户提供一个公网的域名，用于访问用户编写的Serverless函数。需要注意的是，该公网域名通常是云厂商域名相关的子域名，因而是相对可信的，鉴于此，攻击者可以利用函数访问域名的可信去隐藏其攻击资产，躲避安全设备的检测。

可以看出，云原生应用相比传统应用面临的风险主要为应用架构变革及新的云计算模式带来的风险，而针对应用本身的风险并无较大变化，因而对云原生应用架构和无服务器计算模式的深度理解将会有助于理解整个云原生应用安全。

CSA 云计算11大威胁报告 2020

01

数据泄露

数据泄露威胁在去年的调查中继续保持第一的位置，也是最严重的云安全威胁。数据泄露行为可能会严重损害企业的声誉和财务，还可能会导致知识产权（IP）损失和重大法律责任。

CSA关于数据泄露威胁的关键要点包括：

• 攻击者渴望窃取数据，因此企业需要定义其数据的价值及其丢失的影响；
• 明确哪些人有权访问数据是解决数据保护问题的关键；
• 可通过互联网访问的数据最容易受到错误配置或漏洞利用的影响；
• 加密可以保护数据，但需要在性能和用户体验之间进行权衡；
• 企业需要可靠、经过测试的事件响应计划，并将云服务提供商考虑在内。

02配置错误和变更控制不足

这是CSA云安全威胁榜单中出现的新威胁，考虑到近年来越来越多的企业都因为疏忽或意外通过云公开泄露数据，该威胁上榜不足为奇。例如，报告中引用了Exactis事件，其中云服务商因配置错误公开泄露了一个包含2.3亿美国消费者的个人数据的Elasticsearch数据库。另外一个灾难性的错误配置案例来自Level One Robitics，由于备份服务器配置错误暴露了100多家制造公司的知识产权信息。

报告指出，让企业担心的不仅仅是数据丢失，还包括通过篡改或者删除资料导致的业务停顿。报告将大多数配置错误归咎于变更控制实践欠佳。

配置错误和变更控制不充分的关键点包括：

• 云端资源的复杂性使其难以配置；
• 不要期望传统的控制和变更管理方法在云中有效；
• 使用自动化和技术，这些技术会连续扫描错误配置的资源。

03缺乏云安全架构和策略

这是个云计算与生俱来的“古老”问题。对于很多企业来说，最大程度缩短将系统和数据迁移到云所需的时间的优先级，要高于安全性。结果，企业往往会选择并非针对其设计的云安全基础架构和云计算运营策略。这一问题出现在2020年云安全威胁清单中表明，更多的企业开始意识到这是一个严重问题。

云安全架构和策略的要点包括：

• 安全体系结构需要与业务目标保持一致；
• 开发和实施安全体系结构框架；
• 保持威胁模型为最新；
• 部署持续监控功能。

04身份、凭证、访问和密钥管理不善

威胁清单中的另一个新威胁是对数据、系统和物理资源（如服务器机房和建筑物）的访问管理和控制不足。报告指出，云计算环境中，企业需要改变与身份和访问管理（IAM）有关的做法。报告认为，不这样做的后果可能导致安全事件和破坏，原因是：

• 凭证保护不力；
• 缺乏密码密钥，密码和证书自动轮换功能；
• 缺乏可扩展性；
• 未能使用多因素身份验证；
• 未能使用强密码。

身份、凭证、访问和密钥管理的关键要点包括：

• 安全账户，包括使用双重身份验证；
• 对云用户和身份使用严格的身份和访问控制-特别是限制root账户的使用；
• 根据业务需求和最小特权原则隔离和细分账户、虚拟私有云和身份组；
• 采用程序化、集中式方法进行密钥轮换；
• 删除未使用的凭据和访问特权。

05账户劫持

今年，账户劫持仍然是第五大云威胁。随着网络钓鱼攻击变得更加有效和更有针对性，攻击者获得高特权账户访问权的风险非常大。网络钓鱼不是攻击者获取凭据的唯一方法。他们还可以通过入侵云服务等手段来窃取账户。

一旦攻击者可以使用合法账户进入系统，就可能造成严重破坏，包括盗窃或破坏重要数据，中止服务交付或财务欺诈。报告建议对用户就账户劫持的危险性和特征进行安全意识教育培训，以最大程度地降低风险。

CSA关于账户劫持的主要建议包括：

• 账户凭证被盗时，不要只是重置密码，要从源头解决根本问题。
• 深度防御方法和强大的IAM控制是最好的防御方法。

06内部威胁

来自受信任内部人员的威胁在云中与内部系统一样严重。内部人员可以是现任或前任员工，承包商或可信赖的业务合作伙伴，以及无需突破公司安全防御即可访问其系统的任何人。

内部威胁者未必都是恶意的，很多员工疏忽可能会无意间使数据和系统面临风险。根据Ponemon Institute的2018年内部威胁成本研究，64%的内部威胁事件是由于员工或承包商的疏忽所致。这种疏忽可能包括配置错误的云服务器，在个人设备上存储敏感数据或成为网络钓鱼电子邮件的受害者。

治理内部威胁的关键要点包括：

• 对员工进行充分的安全意识和行为准则的培训和教育，以保护数据和系统。使安全意识教育常态化，成为一个持续的过程；
• 定期审核和修复配置错误的云服务器；
• 限制对关键系统的访问。

07不安全的接口和API

“不安全的接口和API”从去年的第三名跌至第七名。在2018年，Facebook经历了一次严重的数据泄露事件，影响了超过5000万个账户，问题的根源就是新服务View中不安全的API。尤其是当与用户界面相关联时，API漏洞往往是攻击者窃取用户或员工凭据的热门途径。

报告指出，企业需要清醒地认识到，API和用户界面是系统中最容易暴露的部分，应当通过安全设计方法来强化其安全性。

参考阅读：糟糕的UX设计也是一种安全威胁

治理不安全的接口和API的关键点：

• 采用良好的API做法，例如监督库存、测试、审计和异常活动保护等项目；
• 保护API密钥并避免重用；
• 考虑采用开放的API框架，例如开放云计算接口（OCCI）或云基础架构管理接口（CIMI）。

08控制面薄弱

控制平面涵盖了数据复制、迁移和存储的过程。根据CSA的说法，如果负责这些过程的人员无法完全控制数据基础架构的逻辑、安全性和验证，则控制平面将很薄弱。相关人员需要了解安全配置，数据流向以及体系结构盲点或弱点。否则可能会导致数据泄漏、数据不可用或数据损坏。

关于弱控制面的主要建议包括：

• 确保云服务提供商提供履行法律和法定义务所需的安全控制；
• 进行尽职调查以确保云服务提供商拥有足够的控制平面。

09元结构和应用程序结构故障

云服务商的元结构（Metastructure）保存了如何保护其系统的安全性信息，并可通过API调用。CSA将元结构称为云服务提供商/客户的“分界线”。这些API可帮助客户检测未经授权的访问，同时也包含高度敏感的信息，例如日志或审核系统数据。

这条分界线也是潜在的故障点，可能使攻击者能够访问数据或破坏云客户。糟糕的API实施通常是导致漏洞的原因。CSA指出，不成熟的云服务提供商可能不知道如何正确地向其客户提供API。

另一方面，客户也可能不了解如何正确实施云应用程序。当他们连接并非为云环境设计的应用程序时，尤其如此。

防范元结构和应用程序结构失败的关键要点包括：

• 确保云服务提供商提供可见性并公开缓解措施；
• 在云原生设计中实施适当的功能和控件；
• 确保云服务提供商进行渗透测试并向客户提供结果。

10云资源使用的可见性差

安全专业人员普遍抱怨云环境导致他们看不到检测和防止恶意活动所需的许多数据。CSA将这种可见性挑战分为两类：未经批准的应用程序使用和未经批准的应用程序滥用。

未经批准的应用程序本质上是影子IT，即员工未经IT或安全或技术支持或许可使用的应用程序。任何不符合公司安全性准则的应用程序都可能会招致安全团队未意识到的风险。

经许可的应用程序滥用包含很多场景，可能是授权的人员使用批准的应用程序，也可能是外部攻击者使用被盗的凭据。安全团队应当能够通过检测非常规行为来区分有效用户和无效用户。

提高云安全资源可见性的要点：

• 人员、流程和技术各个环节都注重云可见性的提升；
• 在公司范围内对云资源使用策略进行强制性培训；
• 让云安全架构师或第三方风险管理人员查看所有未经批准的云服务；
• 投资云访问安全代理（CASB）或软件定义的网关（SDG）来分析出站活动；
• 投资Web应用程序防火墙以分析入站连接；
• 在整个组织中实施零信任模型。

11滥用和恶意使用云服务

攻击者越来越多地使用合法的云服务来从事非法活动。例如，他们可能使用云服务在GitHub之类的网站上托管伪装的恶意软件，发起DDoS攻击，分发网络钓鱼电子邮件、挖掘数字货币、执行自动点击欺诈或实施暴力攻击以窃取凭据。

CSA表示，云服务提供商应有适当的缓解措施，以防止和发现滥用行为，例如付款工具欺诈或滥用云服务。对于云提供商而言，拥有适当的事件响应框架以应对滥用并允许客户报告滥用也很重要。

CSA关于云服务滥用的主要建议包括：

• 监控员工的云服务滥用情况；
• 使用云数据丢失防护（DLP）解决方案来监视和停止数据泄露。

微软 Azure TOP20漏洞快速清单

1.可从Internet访问的存储账户

2.允许不安全转移的存储账户

3.特权用户缺乏多因素身份验证

4.缺少用于加入设备的多因素身份验证

5.免费基础版Azure安全中心缺少很多必要安全功能

6.具有基本DDoS保护的Azure虚拟网络

7.未加密的操作系统和数据磁盘

8.安全中心中缺少电子邮件通知

9.Azure Monitor中缺少日志警报

10.Azure NSG入站规则配置为ANY

11.公共IP地址配置为Basic SKU

12.面向公众的服务使用动态IP地址

13.可匿名读取访问的Blob存储

14.Azure AD中的访客用户数量过大

15.Azure AD中不安全的访客用户设置

16.对Azure AD管理门户的无限制访问

17.Azure身份保护功能默认被禁用

18.Azure Network Watcher默认被禁用

19.并非对所有Web应用程序流量都强制执行HTTPS

20.Azure安全中心中的监视策略

01

可从互联网访问的存储账户

Azure存储账户的默认设置是允许从任何地方（包括互联网）进行访问。这样的设置自然会带来潜在的未经授权的数据访问、数据泄漏、泄露等风险。

始终采用最小特权原则，并仅从选定的IP地址，网络范围或VNet（Azure虚拟网络）子网限制对每个存储账户的访问。

02

存储账户的不安全传输

通过此设置，可以强制执行向存储的安全（加密）数据传输。这意味着任何通过不安全协议（例如HTTP或SMB）但未加密的请求都将被拒绝。

Azure存储账户的默认设置是接受任何协议，这不可避免地使云存储容易受到窃听攻击。位置良好的攻击者可能会窃听通信，并获得对敏感或私人信息的访问权。

显而易见，应该为所有存储账户启用加密数据传输。

03

特权用户缺乏多因素身份验证

对任何Azure资源具有管理或写入权限的任何用户都应该要求多因素身份验证（MFA），包括以下角色：

·管理员

·服务共同管理员

·订阅所有者

·贡献者

使用MFA保护这些高特权账户非常重要，因为它们极有可能成为对手的攻击目标。

启用MFA后，攻击难度大增，从而大大降低了风险。

请注意，Microsoft Azure支持各种MFA解决方案和选项，其中一些是免费的，其中一些是根据高级计划按订阅提供的，例如：

·Azure多重身份验证

·条件访问策略

无论如何，至少应对所有管理用户强制执行某种MFA。

04

缺少针对新加入设备的多因素身份验证

应该要求所有用户提供第二种身份验证方法，然后才能将设备加入Active Directory。

这是为了确保防止恶意设备通过被入侵账户被添加到目录中。

风险在于，攻击者可能将不受管控、不合规的恶意设备加入企业网络，然后用于访问企业的应用程序和其他资源。

05

免费版Azure安全中心

与免费（基础）版相比，付费增强版Azure安全中心增加了以下一些重要的安全功能：

·威胁检测和威胁情报源

·异常检测，行为分析和安全警报

·能识别新型攻击和零时差攻击的机器学习功能

·整个基础架构的漏洞扫描和漏洞管理

·高级访问和应用程序控制可阻止恶意软件和其他网络攻击

上述这些功能无疑可以帮助抵御某些网络攻击，尽管成本增加，但在每个生产环境中都应启用这些功能。

06

虚拟网络的基础DDoS保护

与基础DDoS保护相比，增强的标准DDoS（分布式拒绝服务）保护提供了以下附加防御措施：

·近实时遥测和交通监控

·持续的攻击警报和通知

·自适应调整和流量分析

·详细的攻击分析

以上措施可以帮助防御基于网络的DDoS攻击。在每个生产环境中的所有重要VNet上都应启用标准DDoS防御服务。

唯一的缺点是，这是一项高级功能，因此需要额外付费。

07

未加密的操作系统和数据磁盘

不用说，磁盘加密应该成为每个生产环境、工作站、服务器以及云环境的标准配置。

在云环境中，有时将其称为“静态加密”，Azure支持Windows和Linux VM的磁盘加密：

·在Windows环境，使用BitLocker

·在Linux环境，使用DM-Crypt

根据Azure文档，磁盘加密不应影响性能，也不会增加任何成本，因此，没有任何理由不为所有磁盘启用加密，这包括：

·操作系统磁盘

·数据盘

·未连接的磁盘

08

安全中心中缺少电子邮件通知

在Azure云上运行生产环境而不在Azure安全中心中配置电子邮件通知可算得上是一个重大安全事故。

Azure安全中心应始终配置有电子邮件地址和/或电话号码，以便接收有关事件的通知，尤其是，当特定资源受到威胁时。

邮件通知应当在每个环境中都配置，并始终以很高的优先级进行监视。

09

Azure Monitor中缺少日志警报

Azure的监控和警报服务允许创建自定义警报，以针对Azure云中部署的服务的特定需求量身定制。

如果使用相关的警报条件对其进行了适当的配置，则它可以提供环境中问题的早期指示，而不是依赖于内置的Azure安全功能。

因此，在Azure体系结构审阅中，总是希望看到与环境相关的定义明确的自定义警报列表。

以下是我们可以使用Azure监控警报发出警报的示例列表：

·指标值

·记录搜索查询

·活动日志事件

·基础Azure平台的运行状况

·测试网站可用性

10

Azure NSG入站规则配置为ANY

在NSG（网络安全组）中定义防火墙规则时，常见的错误配置是协议、源或目标配置为“ ANY”。

这种做法可能会导致流量超出预期流量的风险。对于攻击者而言，这些看似良性的配置常常他们入侵的突破口。

最佳做法是始终坚持最小特权的原则。仅允许具有明确定义的源和目标地址的特定协议的方式定义防火墙规则。

请注意，强烈建议在具有应用程序感知能力的Azure中启用第7层防火墙。第7层防火墙在整个Azure网络（包括应用程序）中提供增强的安全功能。

11

公共IP地址配置为Basic SKU

与基础（Basic）SKU相比，在Azure中将公共IP地址配置为标准SKU（库存单位）具有以下优点：

·真正的静态IP地址

·默认安全，对入站流量不开放

·允许区域冗余和分区（区域，地理等）

·支持将来的扩展

对于基础SKU，主要的安全问题是总体开放性。除非由防火墙特别保护，否则默认情况下，分配有基础SKU的公共IP地址的系统将完全暴露给外界。

不用说，这在任何生产环境中都是大忌。在生产环境中，所有公共IP地址都应配置为Standard SKU，并应充分理解其网络流量。

请注意，一旦以任何一种方式配置了IP地址，就无法更改此设置。因此，解决此问题可能需要规划停机和迁移时间。

12

面向公众的服务的动态IP地址

这本身并不是真正的安全漏洞，但是对于任何面向公众的系统，这都是一个严重的错误配置。

如果IP地址是动态的，则意味着它可以在任何时间更改，例如在重新启动或DHCP租约续订之后。而且，当它出现在公开可用的系统上时，它可能会破坏很多东西，例如：

·DNS记录

·监控和日志警报

·系统集成和互操作性

这可能会导致不必要的可用性问题（例如DoS）。因此，始终强烈建议对任何面向公众的服务使用静态IP地址。

13

可匿名读取访问的Blob存储

Azure Blob存储是在云上共享数据的强大而便捷的方式。它支持以下3个访问控制（级别）选项：

1.私人（无匿名访问）

2.Blob（仅针对Blob的匿名读取访问权限）

3.容器（容器和Blob的匿名读取访问权限）

将访问级别配置为后两个选项（匿名读取访问）会带来未经授权访问数据，数据泄漏，渗漏等安全风险。

在生产环境中，应将所有Blob存储都设置为私有，禁止任何匿名访问。

14

Azure AD中的访客用户数量很高

Azure Active Directory（AD）中的访客用户通常是外部用户（例如供应商、承包商、合作伙伴、客户和其他临时角色）创建的账户。

他们只是外部人士，因此，请尽量减少他们的数量。

问题在于，随着时间的流逝，一些企业的访客用户不断堆积，往往导致一些访客失效后忘记撤消其访问权限，这是非常危险的。

访客账户往往会成为攻击者在网络环境中的立足点，可能导致特权提权以及Azure云环境中的其他问题。

因此，应始终检查访客账户的数量。实际上，CIS Benchmark甚至建议完全不使用访客用户。

这是我们使用Azure CLI查找所有来宾用户的方法：

az ad user list --query “[?additionalProperties.userType==‘Guest’]”

15

Azure AD中不安全的访客用户设置

在Azure Active Directory中拥有访客账户是一回事，为他们提供高特权是另一回事。

默认情况下，与完整功能的内部成员用户相比，访客的特权非常有限，但是在Azure AD中，也可以将访客配置为具有与成员用户相同的特权！

通过外部协作设置（例如上图所示）进行配置。上面描述的配置将授予访客用户以下权限：

·枚举所有其他用户和组（包括成员）

·读取所有已注册的企业应用程序的属性

·从外部邀请其他用户加入组织

从安全的角度来看，这当然是非常不安全的，应该尽快更改，除非有非常强硬的理由。

最后，建议完全取消访客账户。

16

对Azure AD管理门户的无限制访问

Azure AD管理门户包含大量敏感信息，默认情况下，Azure AD下的任何用户都可以访问它。

这意味着可以作为标准（成员）用户登录到https://portal.azure.com/并浏览，查看几乎所有设置，其他用户的详细信息、组成员身份、应用程序等。

这是一个重大安全风险，因此应加以限制。

17

Azure身份保护功能被禁用

Azure身份保护为Active Directory中的用户账户增加了一层额外的保护，以减轻登录（登录）风险，例如：

·用户的异常行径

·恶意软件链接的源IP地址

·用户账户泄漏

·密码喷射攻击尝试

·匿名源IP地址（例如Tor）

这些都是是有助于保持Azure AD环境更安全的功能，因此强烈建议启用此功能。

唯一的缺点是，这是一项高级功能，会增加额外的费用。

18

Azure Network Watcher被禁用

Azure Network Watcher提供了至关重要的诊断和可视化工具，用于了解和解决Azure网络中的网络问题。

它还为NSG（网络安全组）Azure防火墙提供网络流分析，包括与特定VM之间的数据包捕获以及许多其他诊断功能。

默认情况下此功能被禁用，建议用户对所有区域都启用此功能。

我们还可以通过以下方法使用Azure CLI检查Network Watcher的状态：

az network watcher list

19

未对所有Web应用程序流量强制执行HTTPS

从安全的角度来看，对于内部和外部（公开）的所有Web应用程序，都应仅接受安全（加密）HTTPS连接，这也是当今的安全标准。

HTTPS提供了非常必要的安全性，机密性和私密性。

启用上述设置后，对给定Azure Web服务的每个传入的不安全（纯文本）HTTP请求都将重定向到其HTTPS端口。

应该为所有Azure Web服务进行HTTPS配置。

对于Azure中的数据库，应实施相同的策略，例如：

·MySQL服务器

·PostreSQL服务器

所有服务器都应启用“强制SSL连接”选项。

现在，您可能想知道应该选择哪个TLS？

NIST（美国国家标准技术研究所）和PCI（支付卡行业）都不再建议TLS版本1.0和1.1版本。因此，应始终至少选择TLS 1.2版。

20

Azure安全中心中的监视策略

CIS基准建议启用Azure安全中心的以下监控策略：

计算和应用程序

·系统升级

·操作系统漏洞

·端点保护

·磁盘加密

·漏洞评估

·自适应应用程序控件

网络

·网络安全组（NSG）

·Web应用程序防火墙（WAF）

·下一代防火墙（NGFW）

数据

·储存加密

·SQL审核

·SQL加密

在每个生产环境中都应启用所有这些策略（将其设置为“ AuditIfNotExists”）。这些策略提供了对Azure云组件的基本安全监视。

启用这些策略时，还应同时启用“自动设置监视代理程序”：

这将确保在环境中部署的所有现有虚拟机以及将来创建的任何新虚拟机上预配置Azure监视代理。

云水坑攻击

根据Accurics的最新报告，伴随托管基础设施的云服务快速增长，“云水坑攻击”呈现爆发式增长。

所谓水坑攻击就是黑客利用平台弱点，预先“蹲点埋伏”，向使用平台服务（例如网站等公共网络资源）的最终用户分发恶意软件，未经授权访问其生产环境、数据或完全破坏目标环境。

根据报告，在已经发现的所有“云水坑攻击”事件中，有23％针对配置不当的托管服务产品，所谓的配置不当，主要指使用默认安全配置或提供过多权限的错误配置。

研究人员指出，在云环境中，水坑攻击可造成更大的破坏，因为托管的云中开发流程暴露于互联网中，而不是像内部环境中的开发流程那样被隐藏在组织内部。

当不法分子成功利用云端开发管道中的错误配置时，不仅会给公司造成灾难，还会给客户造成灾难。为缓解此风险，企业应假定整个开发过程都易于被非法访问，并遵循最小化权限原则，将访问权限限制为仅向需要它的用户开放。

开发上云已经是不可逆转的趋势，越来越多的团队正在加速采用托管服务，这肯定会提高生产力并提升开发速度。但不幸的是，这些团队的安全意识和能力无法跟上相关的风险——例如使用默认的安全配置文件和过度授权。

报告指出：根据历史经验，就像几年前存储桶业务所经历那样，消息服务和FaaS也正进入网络安全问题集中爆发的危险阶段，这些服务的不安全配置将导致更多的违规行为。

甚至随着时间的流逝，那些在配置基础设施时已经建立安全基准的组织也会产生偏离，一个广为人知的案例是亚马逊AWS S3存储桶。2015年AWS S3存储桶被添加到云环境时的配置是正确的，但五个月后，为解决问题而进行的配置更改在工作完成后并未正确重置，直到近五年后，这种偏离才被发现并得到解决。

**
**云基础架构面临的主要风险：

• 尝试部署基于角色的访问控制（RBAC）的Kubernetes用户往往未能以适当的粒度定义角色。这增加了账户重用和滥用的机会。实际上，有35％的企业和机构在这方面表现糟糕。
• 在Helm图表中，有48％的问题是由不安全的默认值引起的。最常见的错误是对默认名称空间的不正确使用（在其中运行系统组件），这可能使攻击者可以访问系统组件或机密。
• 报告首次在生产环境中发现通过基础结构即代码（IaC）定义的身份和访问管理，并且此报告中检测到的IAM偏离中有超过三分之一（35％）源自IaC。这表明IAM即代码（IAM as Code）正在快速流行，但可能导致角色配置错误的风险。
• 硬编码的机密信息几乎占违规行为的10％，其中23％是因为用户错误配置了托管服务产品。
• 在接受调查的企业中，有10％实际上为从未启用付费购买高级安全功能。
• 虽然修复基础设施配置错误的平均时间约为25天，但基础设施中最关键的部分通常需要花费最多的时间来修复。例如，负载平衡服务平均需要149天的时间才能修复。由于所有面向用户的数据都需要流经负载均衡服务，因此理想情况下，应该优先以最快的速度修复此类资产。

云化数据中心的安全问题：

1.网络边界消失导致基于网络边界防护的措施无法实施

2.安全策略无法适应云内的动态环境

3.虚拟化层的引入导致被攻击面扩大

4.东西向流量不可见

5.租户间的隔离、攻击溯源困难等等，

**企业业务上云之后带来一系列新的安全挑战: **

1.云内虚机无保护：虚机间缺乏威胁 隔离机制，网络威胁一旦进入云平台内部，可以肆意蔓延 。

2.流量流向不可视：多种应用部署在同一台物理服务器上运行，使网络流量产生叠加，流量模型更加不可控， 用户无法直观感受到虚机之间数据流量大小、流向变化。

3.威胁攻击无感知：用户无法感知自有业务虚机是否在遭受攻击、遭受何种类型的攻击

4.安全策略无差异：面对众多业务系统不同的安全需求，安全策略需要差异化的按需部署

5.虚机位置不固定：服务器虚拟化技术的应用必然伴随着虚拟机的迁移，使得安全策略的部署变得复杂和无助，需要一个动态的机制来对数据中心进行防护

6.关键数据被窃取：相较于外部攻击:恶意的内部人员利用自身权限进行数据窃取等内部攻击行为造成的危害风险更大。

难点一：数字资产多、租户多

在传统数据中心物理服务器与被保护目标数量比是1:1，但是在云计算数据中心，一台高性能服务器与被保护虚机的数量比可达1:100。虚拟化放大了传统安全域规模，维护工作量巨大。

难点二：海量会话日志，难查找

边界防火墙的海量日志会话、排查难度大、内部不可视，导致攻击发现难；难辨别的内部NAT策略、难识别的伪造IP地址，导致攻击定位难；进而导致策略阻断难以落实。

难点三：协作难度大

正因为“多”和“变”，导致不同部门、厂家之间的协作难度加大。当云平台管理出现异常时、出现安全风险时，责任又该如何界定？

云内流量不可见

云内的流量对于管理人员来说，更像一个“黑盒”。我们能够看到每天都有流量进出，却不清楚“盒子”里面究竟发生了什么。“盒子”小的时候尚可，但当“盒子”里的“小球”超过100个，这种“无序”就可能给管理人员带来麻烦。

Nginx是不是只访问了APP，而没有去访问DB；内部是否有利用跳板的恶意连接；勒索病毒、挖矿病毒是否在内部传播？

策略量大增

看看小区里面的“纵深防御”：小区门口的保安，楼下的门禁，家里的防盗门。很多管理人员同样在云数据中心中考虑了这样的方案，但虚拟机数量太多让他们打了退堂鼓。

“难道让我把每个虚拟机设置一个安全组？然后每个安全组还要设置来源ip以及其可以访问的服务、端口？每次业务调整，我再手动调整策略？哦，不，这不是我想要的生活。北京奥运会唱的好，我家大门常打开……“

1. 安全责任边界界定不清

传统环境中网络边界十分明确，安全责任的界定可以通过运维合同中的条款进行规定，一般遵循谁主管谁负责、谁运行谁负责的原则，信息安全责任相对清楚。但在云计算环境下，不同的服务和部署模式增加了云租户和云平台交互的复杂性，同时增加了云上信息系统与云计算平台的安全责任界定难度。随着云计算技术和应用的不断发展，伴随着业务需要，客户需要定制化的、完全可控的安全服务，实时了解掌握自身业务系统运行的安全状态，并根据自身需要和安全风险调整安全策略。同时，安全责任方面的要求也在网络安全等级保护等相关国家标准中明确提出。

2. 数据缺乏安全有效的监管措施

云计算环境下，云租户业务系统、运营数据等都存放于云端，用户对业务系统和运营数据失去了直接的物理控制。如何保证云租户业务和数据的安全可靠？如何发现对业务和数据的非法访问或恶意破坏？如何对云服务商运维人员非授权访问用户数据的行为进行监督和震慑？都是当前云平台租户非常重视的问题。

3. 虚拟化带来的安全难题

对于传统的数据中心，通过电缆、光缆可以将安全设备直接接入到物理网络中对信息系统形成安全防护。云计算平台通过引入虚拟化技术形成网络、计算和存储资源池，有效提高了资源利用率。但网络的虚拟化导致传统的安全设备被旁路，网络流量可以不经过物理链路在虚拟机之间直接传递，安全设备完全失去了作用。

IT 面临的三大挑战是：

1. **缺少对所有流量的可视性，因而无法确保它们是否成为针对性攻击的目标：**针对性攻击穿透私有云环境的方式与穿透传统的数据中心不同。安全架构师需要了解它们的不同之处，知道什么地方需要查看，拥有可视性，然后才能在新环境中击败针对性攻击，因为他们无法保护那些看不到的地方。
2. **需要以云的速度提供安全：**安全团队最不希望看到的一件事是他们因为拖慢应用程序、计算时间或服务的速度而受到责备。随着 IT 团队转向更加动态和敏捷的计算技术，他们的安全需求也需要快速地转变。
3. **缺乏有效管理安全策略并确保强有力的服务等级协议 (SLA) 以支持业务需求的能力：**缺乏足够的人力资源来有效且高效地管理多个私有云安全，甚至是当某个虚拟机 (VM) 从私有云的某部分转向另一部分时也无法做到有效管理。此外，对于将传统现场部署的网络扩展至软件定义数据中心 (SDDC) 的虚拟化网络，您也需要一款易于部署的安全解决方案。

为了能够帮助企业 IT 部门应对这些挑战，您需要集成且自动化的解决方案，而不是单点的安全产品。尤其是当 IT 部门希望看到如下成果时：

1. **针对所有私有云工作负载的安全可视性：**将安全植入部署中将有助于实现这一目标。将它们的私有云安全系统与其它 IT 安全系统相整合将会加快防御针对性攻击的速度。鉴于私有云的弹性计算特质，借助动态架构保持可视性和控制至关重要。
2. **借助能够适应不断变化环境的安全系统来保护私有云环境的安全：**将安全植入部署中也有助于实现这一目标。安全不应当是“事后诸葛亮”。
3. **简化安全管理，使之能够满足现有的人员现状；使他们在保护业务安全的同时能够按照 SLA 提供：**拥有强大的管理工具和监控安全策略的能力，以及提供必需的可视性是成功的关键之一。IT 必需有相应的管理工具能够提供这些报告。

大量CIO表示业务上云之前会综合考虑上云后的安全问题；同时，一部分的CIO由于对云的不信任导致上云失败，因此，安全已然成为阻碍企业向云迁移的公认事实。

云内安全风险综述

围绕安全这个话题，我们永远绕不开GRC（Governance、Risk、Compliance），即治理、风险和合规。从某种程度上来说，合规也是安全风险。本节将以此为出发点，集中讨论云内的各类安全风险。

云内风险涵盖面非常广泛，为了便于阅读，笔者将云内风险按照不同类别进行分类，并分别阐述各个类别下需要注意的安全风险。

2.1基于部署模型的风险

（1）私有云风险

私有云是数据中心的传统形态，企业控制所有基础架构，因此，相对于传统数据中心可能出现的安全风险，私有云数据中心也均有可能出现。例如：

• 人员威胁：包括无意和恶意的威胁，如云架构师错误的Hypervisor配置导致隔离失效、恶意管理员“删库跑路”。

• 外部攻击：如未经授权的访问、窃听和DDOS攻击、恶意软件等

• 监管不合规：相对于公有云、社区云，私有云中的监管合规问题相对来说容易解决，因为一切尽在自己的控制之下。

• 自然灾害：洪水火灾泥石流等。

（2）社区云风险

在社区云中，企业之间共享和分散资源，这种共享和分散资源在为社区提供便利的同时也带来了下述风险：

• 分散的决策风险：由于社区云由整个社区共同出资、共同所有、共同维护，网络所有权和运营也分散在了各个社区成员之间。因此，每个节点都有自己的入口，任一节点中的漏洞都可能导致对其他节点的入侵。同时，几乎无法实现统一的配置管理、统一的基线。很明显，由于社区云属于大家共同维护，这种分散的运营维护将导致策略和管理方面巨大的困难。

• 访问控制难以实现：由于社区成员分担基础架构的开销和成本，访问控制策略措施难以做到统一满足各个组织的需要。

• 性能和检测的集中化管理缺失：各个社区成员无法实现质量标准统一的集中化性能和安全检测带来的可靠性。

（3）公有云风险

这是企业上云最常使用的部署模式。私有云和社区云中所有的风险在公有云中均存在，当然，本文将讨论除此以外的公有云特有风险。

• 云服务供应商Lock-in：想象三种场景，（1）如果企业没有做好尽职调查（Due Diligence），云服务商很可能使用专有的数据格式存储企业的各类数据；（2）企业是个零售机构，受理全球订单，云内主要处理订单支付，因此需要满足PCI-DSS支付卡行业标准要求，而目前国内能够满足合规要求的云服务商寥寥无几；（3）业务已经在云内运行5年，且产生了海量数据合同期满后需要迁移到其他云供应商。这三个常见的场景将会带来三个相同的安全风险：（1）数据格式专有，导致无法更换新的云服务商；（2）假使国内仅有一家云服务提供商满足PCI-DSS合规要求，在合同期满后，云服务供应商增加使用成本，企业将失去谈判能力且无法变更云供应商；（3）产生的海量数据迁移需要足够的带宽和时间，同时短期大量的迁移流量根据云服务商的阶梯式流量费率，可能导致迁移费用大增而放弃迁移。

上述情况均会导致企业上云后被云服务商绑死（Lock-in）。

• 云服务商Lock-out：想象两种场景，（1）云服务商被收购、破产重组（2）云服务商由于违法导致受到制裁停止运营。笔者不将穷举所有可能导致云服务商无法提供服务的原因，但是这导致企业上云后的确面临Lock-out的风险：云服务商停止运营后如何保护我们的业务和数据持续运行？这里需要综合考虑云服务提供商的生命周期、核心竞争力、司法管辖权、供应链依赖性和适用的立法环境，在前期尽量做好云供应商的选择。

• 多租户风险：进入公有云意味着进入多租户环境，多租户带来的风险包括：（1）利益冲突，想象和你运营相同业务的竞争对手的虚拟机和你在同一朵云中，会发生什么？如果云数据库管理员与竞争对手的关系非常好呢？你的数据很有可能被数据库管理员泄露给竞争对手。很明显，从安全的角度来说，这种风险并非不存在，但是使用Brewer-Nash（也叫中国墙）访问控制模型可以有效解决这个风险；（2）特权提升，Vm Escape和Host Escape，即虚拟机逃逸和主机逃逸，可以在云中轻松实现特权提升，并访问同一Host不同Vm或者不同Host中的虚拟机；（3）信息泄露，侧信道攻击方式可以通过多种方式判断、检测到同一Host不同云客户的活动迹象信息，如客户处理数据的时长等，这并非无害，这可能帮助别有用心的人判断你选择的数据处理产品，进而有针对性的进行漏洞利用；（4）法律活动，想象由于触犯法律导致和你处于同一Host中的客户硬盘被司法部门取证没收用以调查，很明显，由于分布式存储的特性，你的数据可能也在那块被取证没收的磁盘中，风险不言而喻。

（4）混合云风险

混合云风险包含私有云、社区云、公有云的所有风险，这里不再赘述。

2.2基于服务模型的风险

（1）IaaS模型风险

• 人员威胁

• 外部威胁

• 缺乏特定技能：企业管理员不一定精通云计算环境的配置和部署，业务的运营可能面临巨大的风险。

（2）PaaS模型风险

• 互操作性风险：PaaS模型中操作系统OS由云服务提供商进行管理和更新，所以当环境有调整时，企业自己部署的软件由于兼容性不一定能正常运行在云服务商的OS上。

• 后门风险：PaaS常用于软件开发和DevOps，这些软件产品发布后开发人员常常忘记把前期自己留的后门删除，导致后期出现0day漏洞。

（3）SaaS模型风险

• 专有格式：SaaS意味着使用云提供商的应用，他们可能使用自己的专有格式收集、存储和现实数据，这可能导致可移植性的降低。

• Web应用安全：大多数SaaS产品依赖于浏览器访问，通过web的访问导致Owasp Top10中所有风险均存在于SaaS云环境中。

2.3基于虚拟化类型的风险

（1）Type1类型风险

Type1类型即裸金属架构，采用虚拟化管理软件Hypervisor作为虚拟化实例和主机资源之间的接口和控制器。恶意黑客认为Hypervisor是一个潜在的攻击目标，因为系统中较低层提供了更大的控制。通过破坏Hypervisor，可以控制已安装的VM、物理系统和托管应用程序。

常见攻击包括超级劫持（安装可以完全控制服务器的流氓虚拟机管理程序），例如SubVir，Blue Pill（使用AMD安全虚拟机[SVM]的hypervisor rootkit），Vitriol（使用Intel VT-x的Hypervisor rootkit），以及直接内核结构操作（DKSM）。

（2）Type2类型风险

Type2类型即宿主架构，它具有Type1类型的所有风险，同时相比于Type1类型，Type2类型多了一层OS，从安全的角度来看，新加入的OS引入了更多的攻击面，这个OS比VMM更复杂，可能含有更多的漏洞。

2.4其他类型的风险

上述根据不同分类列举的风险难以囊括云环境中企业可能面临的所有安全风险，笔者也不打算将所有云内风险全部罗列出来，本文仅讨论以下重要的云内风险内容。下面简单阐述每个所列举风险的基本含义，有时间再进行详细说明。

1、隐私风险：云内数据大集中意味着风险大集中，隐私安全作为数据安全的一部分在国内外均格外受到重视。云存储中可能包含众多的公民隐私PII数据，这些PII数据如果没有得到有效的保护，将会受到法律的制裁。国际上，欧盟GDPR立法对公民隐私保护提出了现有最高要求，各国处理、存储、采集欧盟成员国公民PII数据均需要满足GDPR或者签署具有同等效力的合同约束，或者制定专门法律以满足GDPR要求，如美国的安全港协议和隐私保护盾协议。除了欧盟，美国GAPP、国际ISO 27018、OECD均对公民个人隐私保护提出了安全保护要求，在考虑云环境时需要考虑业务环境是否面临满足上述隐私安全合规风险。同时，隐私保护也不仅仅时为了合规，合规只是下线，如何确保业务数据中的隐私信息能够满足实际生产需求，可能需要更多考虑，这里可以考虑匿名化、加密、脱敏、hash、去标签化、屏蔽等各种隐私数据模糊化技术手段。

2、审计风险：云环境导致数据全球化存储、地域分散式存储，云技术导致数据高度动态存储，多数据中心导致数据位置与企业地理分离，这些因素都导致传统的审计无法或难以适用于云环境。

3、合规风险：云计算业务在国际上飞速发展，每个国家针对云计算业务安全性制定了专门的规章和标准，如国内等保2.0云计算安全扩展要求、美国FedRamp等，企业需要根据实际情况验证云供应商是否能够提供满足合规要求的安全能力。对于一些国际贸易公司、跨国企业，这里推荐采用CCSL、CSA STAR（包括CCM和CAIQ）两个工具交叉验证云供应商合规性满足能力。

同时，云计算导致企业更加难以应对合规性要求。尤其对于运行在公有云环境中的组织。国内企业可能在这一点上稍微好处理，对于跨国企业，企业数据分布在世界各地，可能面临各国合规性要求不同带来的违法违规风险。比如美国FIPS 140-2标准要求所有密钥存储设备均有硬件保护机制，很明显，云中运行的应用难以满足FIPS 140-2要求。

4、数据风险：数据从创建、传输、存储、共享、归档、销毁的各个生命周期均面临不同的安全风险，展开来讲可能需要20页的A4纸才能阐述清楚，这个不做过多介绍。

5、应用风险：应用迁移风险、应用开发文档缺失风险、传统应用不一定适用于云环境、应用隔离风险、API风险（未经验证的API和API供应链安全）、应用整合风险等对应用安全提出了较高的挑战，每一项都具有很大的威胁性。

6、运营风险：运营风险是指云内运营时候可能出现的各种风险状况。合理配置BIOS、合理使用TPM、正确配置存储控制器（Vlan隔离、kerberos/SRP/CHAP身份验证、IpSEC加密等）、网络控制器（端口及端口组隔离、管理网隔离、网络冗余、加密等）、对console-based访问严格控制均需要注意。尤其注意云内补丁维护，因为虚拟机镜像无法打补丁，所以自动化补丁管理可能需要注意以文件形式存储的虚拟机镜像实例的补丁更新问题。

7、取证风险：云技术的发展不仅带来了优越性，也导致云环境中的司法取证过程变得更加困难。虚拟机漂移导致无法定位待取证虚拟机位置，分布式存储带来的数据分散化导致取证需要涉及多个物理位置，多租户导致取证时可能侵犯其他租户隐私数据，这些都是云计算带来了特有安全风险。

8、供应链风险：不论采用公有云部署还是私有云部署，都可能遇到比传统环境更加复杂的供应链问题。国内大部分IaaS交付的云环境，其服务器、存储物理设备一般采用第三方专业厂商产品，或者白牌产品，这将导致我们除了衡量云服务提供商以外，还需要考虑云服务提供商采用的下游供应商；同样，PaaS和SaaS服务模型其操作系统、应用软件、应用软件代码库一般都可以有多个供应商可供选择，这些二级供应商都是需要严格考虑的安全风险，毕竟经济损失可以转移，安全责任是无法转移的。

三、第三方机构对云内风险的总结

目前国际上可以借鉴的云内风险报告包括2013年发布的Notorious 9、2016年发布的The Treacherous12和ENISA Top 8。

Notorious 9列出了9大云内安全风险，包括：数据泄露、数据丢失（当客户将加密信息上载到云环境时，加密密钥将成为确保数据不会丢失并保持可用的关键组件。因为丢失相关的加密密钥会导致数据丢失）、账户/服务流量劫持、不安全的接口和API、拒绝服务、恶意内部人员、滥用云服务、尽职调查不足、共享技术漏洞（所有租户共享相同底层架构，相同的漏洞导致一损俱损）。

云计算顶级威胁The Treacherous12列出了12大安全风险，包括：数据泄露、凭据或身份验证遭到攻击或破坏、接口和API被黑客攻击、利用系统漏洞、账户被劫持、来自企业内部的恶意人员、APT攻击、永久性的数据丢失、缺乏尽职调查、云服务的滥用、DoS攻击、共享技术漏洞。

这两份云环境安全风险调查报告有很多相同的部分，这里不再展开详述，读者可以自寻相同点，必定可以发现云内重要安全风险所在。

除了上述CSA发布的云内安全风险以外，欧盟ENISA也发布了云内8个顶级安全风险，本文列出以供参考：

ENISA Top 8：治理缺失、lock-in、隔离失效、不安全或不完整的数据删除、恶意内部人员、管理平面失效、合规风险和数据保护。

四、云内安全展望

从安全的角度来看，识别云计算风险只是风险管理的第一步，但只有识别清楚云内风险，才能进行下一步的风险分析、设计风险控制措施、判断残余风险和实行风险监督。

Palo Alto 2021上半年云威胁报告

原创武状元土儿飞虎行业观察

清明节和复活节后，还没等到劳动节，Palo Alto就发布了2021年上半年的云威胁报告。显然，数据不会涵盖2021年整个上半年，但有一点是肯定的，就是下一份报告要等到下半年了。总的来说，和从业者们期待的一样，安全事件还是那么多，一点也不令人惊讶，不然好像显得没有见过市面一样。

报告显示，以下十几种安全事件的频率大大地增加着：

基本上，这些事件表明了许多企业在云的治理和安全自动化方面做得不太行，云治理和安全的进度赶不上上云的进度。反正，要是云治理方面做得不太好的话，总是会被努力的攻击者们盯上的。不过许多这种配置不当是可以使用IaC模板来解决的，对IaC模板的持续扫描可以对云基础设施从开发到生产提供保护。

报告说，由于企业迅速上云导致了安全事件的增加。但只要在云计算公司工作过就会知道，不少云供应商的口号是云上更安全的，引用之前Oracle和KPMG合作的云威胁报告中的发现，也有可能是由于企业对于云责任共担模型的理解问题导致了事件的增加。毕竟，各种云的甲乙双方的责任是不同的。这就好像是门锁虽然换了个高级的，但是客户自己从来不关门，那所以也不能全怪门锁，虽说门锁也是可以做得更好的，比如提醒客户关门。

据悉，企业上云导致的安全事件增加，已经到了让企业的DevOps和安全团队累成狗的地步。累成狗不要紧，就怕累成狗也搞不定。比如在零售业、制造业、和政府的安全事件数量分别增加了402%、230%、和205%。当然，对于从业者来说，这也并不令人惊讶，毕竟大家都是见过世面的。

当然，也有一些行业的企业是做得比较好的。比如媒体行业企业在更换密钥方面比其他行业的勤快，所以报告的研究分析人员认为，媒体行业由于要保护敏感数据就较多考虑了访问控制。但总的来说零售业在这方面就做得不太好。通信行业在密钥管理方面得分比较低，报告的研究分析人员认为有可能通信行业对监控的关注超过了访问控制。

另外云存储的版本控制也是一种安全措施，因为这表明了企业是否能在被攻击后恢复到某个版本。比如通信行业就有66%的企业实施了版本控制。而媒体和高科技行业只有48%的企业实施了版本控制。

所以啰嗦又不算是重复的再说一遍，看起来媒体行业更关注访问控制，而通信行业更关注数据不被破坏。

PA的研究表明，64%的云上数据是敏感信息。在这些敏感信息中，又有69%包含PII，34%包含知识产权信息。

除了敏感信息，云上还存储着恶意软件。PA研究发现，在存储在云上的恶意软件里，有92.9%以.exe或.dll的形式存在。不过好消息是，只有0.01%的云存储数据中发现有恶意软件。接下来就看谁能访问这0.01%了，毕竟它们已经上云了。

此外，PA还研究了挖矿趋势。趋势可能表明，和普通人一样，矿工在熊市抓紧挖矿，然后在门罗币高价的时候售出。趋势还表明在双旦期间的挖矿动作有所减少，毕竟谁都是要放假的。

研究还表明，尽管总的来说挖矿活动有所增加，但加密劫持在减少。

PA还给了一些安全建议，不过也并没有什么特别，就那几条，大家都知道。不说就好像有点神秘，说了就不稀奇了。另外，报告的图表色彩明快，散发着自由又不失严谨的气息，令地球人眼前一亮。

Hackmageddon2020年全球云安全威胁榜单

近年来，网络犯罪组织和黑客对云服务的滥用与日俱增，不仅因为云服务提供了可靠的弹性托管基础架构，能够绕过传统的安全控制，另外一个不容忽视的诱因是：用户盲目地，或者过度信任云服务的安全性。这也导致越来越多的废弃软件（例如GuLoader或BazaarLoader）被采用（在最近的Ryuk勒索软件攻击浪潮中被用来投放恶意软件）。

以下是Hackmageddon统计的2020年云安全威胁数据，虽然数据样本并不完整，但足以表明黑客对云服务的恶意利用和攻击频率正在越来越高，云原生安全的形势将越来越严峻。

企业信息主管们也应该意识到，云安全正在面临巨大威胁，这不仅表现为云服务自身的“云原生”安全问题，而且越来越多的黑客攻击也正在“数字化转型”和“上云”。

针对云服务的四大主流攻击手段：

被利用最多的23个云服务：

最常被用于恶意软件投放的云服务：

最常被用于部署命令与控制服务器的云服务：

最常被用于对象执行的云服务：

最常被用于C2和投放的云服务：

2020年云原生安全威胁事件时间轴（点击查看大图）：

参考资料

参考文献

[1] https://owasp.org/www-project-top-ten/

[2] https://owasp.org/www-project-api-security/

[3] https://netflixtechblog.com/starting-the-avalanche-640e69b14a06

[4] https://www.owasp.org/index.php/OWASP_Serverless_Top_10_Project

[5]【云原生攻防研究 】针对AWS Lambda的运行时攻击 https://mp.weixin.qq.com/s/duF1Z0EDC3n_G378Aq_XYA

[6] 《Serverless安全研究 — Serverless安全风险》

https://mp.weixin.qq.com/s/rbS0_42RBiFu8UFFQW4kew

[7] https://github.com/apache/openwhisk

[8] https://github.com/kubeless/kubeless

[9 https://github.com/openfaas/faas

[10] https://github.com/fission/fission

在此背景下，本文简单探讨了云内各类安全风险以及风险的部分应对措施，希望本文对读者有所帮助。

二、云内安全风险综述

围绕安全这个话题，我们永远绕不开GRC（Governance、Risk、Compliance），即治理、风险和合规。从某种程度上来说，合规也是安全风险。本节将以此为出发点，集中讨论云内的各类安全风险。

云内风险涵盖面非常广泛，为了便于阅读，笔者将云内风险按照不同类别进行分类，并分别阐述各个类别下需要注意的安全风险。

2.1基于部署模型的风险

（1）私有云风险

私有云是数据中心的传统形态，企业控制所有基础架构，因此，相对于传统数据中心可能出现的安全风险，私有云数据中心也均有可能出现。例如：

• 人员威胁：包括无意和恶意的威胁，如云架构师错误的Hypervisor配置导致隔离失效、恶意管理员“删库跑路”。

• 外部攻击：如未经授权的访问、窃听和DDOS攻击、恶意软件等

• 监管不合规：相对于公有云、社区云，私有云中的监管合规问题相对来说容易解决，因为一切尽在自己的控制之下。

• 自然灾害：洪水火灾泥石流等。

（2）社区云风险

在社区云中，企业之间共享和分散资源，这种共享和分散资源在为社区提供便利的同时也带来了下述风险：

• 分散的决策风险：由于社区云由整个社区共同出资、共同所有、共同维护，网络所有权和运营也分散在了各个社区成员之间。因此，每个节点都有自己的入口，任一节点中的漏洞都可能导致对其他节点的入侵。同时，几乎无法实现统一的配置管理、统一的基线。很明显，由于社区云属于大家共同维护，这种分散的运营维护将导致策略和管理方面巨大的困难。

• 访问控制难以实现：由于社区成员分担基础架构的开销和成本，访问控制策略措施难以做到统一满足各个组织的需要。

• 性能和检测的集中化管理缺失：各个社区成员无法实现质量标准统一的集中化性能和安全检测带来的可靠性。

（3）公有云风险

这是企业上云最常使用的部署模式。私有云和社区云中所有的风险在公有云中均存在，当然，本文将讨论除此以外的公有云特有风险。

• 云服务供应商Lock-in：想象三种场景，（1）如果企业没有做好尽职调查（Due Diligence），云服务商很可能使用专有的数据格式存储企业的各类数据；（2）企业是个零售机构，受理全球订单，云内主要处理订单支付，因此需要满足PCI-DSS支付卡行业标准要求，而目前国内能够满足合规要求的云服务商寥寥无几；（3）业务已经在云内运行5年，且产生了海量数据合同期满后需要迁移到其他云供应商。这三个常见的场景将会带来三个相同的安全风险：（1）数据格式专有，导致无法更换新的云服务商；（2）假使国内仅有一家云服务提供商满足PCI-DSS合规要求，在合同期满后，云服务供应商增加使用成本，企业将失去谈判能力且无法变更云供应商；（3）产生的海量数据迁移需要足够的带宽和时间，同时短期大量的迁移流量根据云服务商的阶梯式流量费率，可能导致迁移费用大增而放弃迁移。

上述情况均会导致企业上云后被云服务商绑死（Lock-in）。

• 云服务商Lock-out：想象两种场景，（1）云服务商被收购、破产重组（2）云服务商由于违法导致受到制裁停止运营。笔者不将穷举所有可能导致云服务商无法提供服务的原因，但是这导致企业上云后的确面临Lock-out的风险：云服务商停止运营后如何保护我们的业务和数据持续运行？这里需要综合考虑云服务提供商的生命周期、核心竞争力、司法管辖权、供应链依赖性和适用的立法环境，在前期尽量做好云供应商的选择。

• 多租户风险：进入公有云意味着进入多租户环境，多租户带来的风险包括：（1）利益冲突，想象和你运营相同业务的竞争对手的虚拟机和你在同一朵云中，会发生什么？如果云数据库管理员与竞争对手的关系非常好呢？你的数据很有可能被数据库管理员泄露给竞争对手。很明显，从安全的角度来说，这种风险并非不存在，但是使用Brewer-Nash（也叫中国墙）访问控制模型可以有效解决这个风险；（2）特权提升，Vm Escape和Host Escape，即虚拟机逃逸和主机逃逸，可以在云中轻松实现特权提升，并访问同一Host不同Vm或者不同Host中的虚拟机；（3）信息泄露，侧信道攻击方式可以通过多种方式判断、检测到同一Host不同云客户的活动迹象信息，如客户处理数据的时长等，这并非无害，这可能帮助别有用心的人判断你选择的数据处理产品，进而有针对性的进行漏洞利用；（4）法律活动，想象由于触犯法律导致和你处于同一Host中的客户硬盘被司法部门取证没收用以调查，很明显，由于分布式存储的特性，你的数据可能也在那块被取证没收的磁盘中，风险不言而喻。

（4）混合云风险

混合云风险包含私有云、社区云、公有云的所有风险，这里不再赘述。

2.2基于服务模型的风险

（1）IaaS模型风险

• 人员威胁

• 外部威胁

• 缺乏特定技能：企业管理员不一定精通云计算环境的配置和部署，业务的运营可能面临巨大的风险。

（2）PaaS模型风险

• 互操作性风险：PaaS模型中操作系统OS由云服务提供商进行管理和更新，所以当环境有调整时，企业自己部署的软件由于兼容性不一定能正常运行在云服务商的OS上。

• 后门风险：PaaS常用于软件开发和DevOps，这些软件产品发布后开发人员常常忘记把前期自己留的后门删除，导致后期出现0day漏洞。

（3）SaaS模型风险

• 专有格式：SaaS意味着使用云提供商的应用，他们可能使用自己的专有格式收集、存储和现实数据，这可能导致可移植性的降低。

• Web应用安全：大多数SaaS产品依赖于浏览器访问，通过web的访问导致Owasp Top10中所有风险均存在于SaaS云环境中。

2.3基于虚拟化类型的风险

（1）Type1类型风险

Type1类型即裸金属架构，采用虚拟化管理软件Hypervisor作为虚拟化实例和主机资源之间的接口和控制器。恶意黑客认为Hypervisor是一个潜在的攻击目标，因为系统中较低层提供了更大的控制。通过破坏Hypervisor，可以控制已安装的VM、物理系统和托管应用程序。

常见攻击包括超级劫持（安装可以完全控制服务器的流氓虚拟机管理程序），例如SubVir，Blue Pill（使用AMD安全虚拟机[SVM]的hypervisor rootkit），Vitriol（使用Intel VT-x的Hypervisor rootkit），以及直接内核结构操作（DKSM）。

（2）Type2类型风险

Type2类型即宿主架构，它具有Type1类型的所有风险，同时相比于Type1类型，Type2类型多了一层OS，从安全的角度来看，新加入的OS引入了更多的攻击面，这个OS比VMM更复杂，可能含有更多的漏洞。

2.4其他类型的风险

上述根据不同分类列举的风险难以囊括云环境中企业可能面临的所有安全风险，笔者也不打算将所有云内风险全部罗列出来，本文仅讨论以下重要的云内风险内容。下面简单阐述每个所列举风险的基本含义，有时间再进行详细说明。

1、隐私风险：云内数据大集中意味着风险大集中，隐私安全作为数据安全的一部分在国内外均格外受到重视。云存储中可能包含众多的公民隐私PII数据，这些PII数据如果没有得到有效的保护，将会受到法律的制裁。国际上，欧盟GDPR立法对公民隐私保护提出了现有最高要求，各国处理、存储、采集欧盟成员国公民PII数据均需要满足GDPR或者签署具有同等效力的合同约束，或者制定专门法律以满足GDPR要求，如美国的安全港协议和隐私保护盾协议。除了欧盟，美国GAPP、国际ISO 27018、OECD均对公民个人隐私保护提出了安全保护要求，在考虑云环境时需要考虑业务环境是否面临满足上述隐私安全合规风险。同时，隐私保护也不仅仅时为了合规，合规只是下线，如何确保业务数据中的隐私信息能够满足实际生产需求，可能需要更多考虑，这里可以考虑匿名化、加密、脱敏、hash、去标签化、屏蔽等各种隐私数据模糊化技术手段。

2、审计风险：云环境导致数据全球化存储、地域分散式存储，云技术导致数据高度动态存储，多数据中心导致数据位置与企业地理分离，这些因素都导致传统的审计无法或难以适用于云环境。

3、合规风险：云计算业务在国际上飞速发展，每个国家针对云计算业务安全性制定了专门的规章和标准，如国内等保2.0云计算安全扩展要求、美国FedRamp等，企业需要根据实际情况验证云供应商是否能够提供满足合规要求的安全能力。对于一些国际贸易公司、跨国企业，这里推荐采用CCSL、CSA STAR（包括CCM和CAIQ）两个工具交叉验证云供应商合规性满足能力。

同时，云计算导致企业更加难以应对合规性要求。尤其对于运行在公有云环境中的组织。国内企业可能在这一点上稍微好处理，对于跨国企业，企业数据分布在世界各地，可能面临各国合规性要求不同带来的违法违规风险。比如美国FIPS 140-2标准要求所有密钥存储设备均有硬件保护机制，很明显，云中运行的应用难以满足FIPS 140-2要求。

4、数据风险：数据从创建、传输、存储、共享、归档、销毁的各个生命周期均面临不同的安全风险，展开来讲可能需要20页的A4纸才能阐述清楚，这个不做过多介绍。

5、应用风险：应用迁移风险、应用开发文档缺失风险、传统应用不一定适用于云环境、应用隔离风险、API风险（未经验证的API和API供应链安全）、应用整合风险等对应用安全提出了较高的挑战，每一项都具有很大的威胁性。

6、运营风险：运营风险是指云内运营时候可能出现的各种风险状况。合理配置BIOS、合理使用TPM、正确配置存储控制器（Vlan隔离、kerberos/SRP/CHAP身份验证、IpSEC加密等）、网络控制器（端口及端口组隔离、管理网隔离、网络冗余、加密等）、对console-based访问严格控制均需要注意。尤其注意云内补丁维护，因为虚拟机镜像无法打补丁，所以自动化补丁管理可能需要注意以文件形式存储的虚拟机镜像实例的补丁更新问题。

7、取证风险：云技术的发展不仅带来了优越性，也导致云环境中的司法取证过程变得更加困难。虚拟机漂移导致无法定位待取证虚拟机位置，分布式存储带来的数据分散化导致取证需要涉及多个物理位置，多租户导致取证时可能侵犯其他租户隐私数据，这些都是云计算带来了特有安全风险。

8、供应链风险：不论采用公有云部署还是私有云部署，都可能遇到比传统环境更加复杂的供应链问题。国内大部分IaaS交付的云环境，其服务器、存储物理设备一般采用第三方专业厂商产品，或者白牌产品，这将导致我们除了衡量云服务提供商以外，还需要考虑云服务提供商采用的下游供应商；同样，PaaS和SaaS服务模型其操作系统、应用软件、应用软件代码库一般都可以有多个供应商可供选择，这些二级供应商都是需要严格考虑的安全风险，毕竟经济损失可以转移，安全责任是无法转移的。

三、第三方机构对云内风险的总结

目前国际上可以借鉴的云内风险报告包括2013年发布的Notorious 9、2016年发布的The Treacherous12和ENISA Top 8。

Notorious 9列出了9大云内安全风险，包括：数据泄露、数据丢失（当客户将加密信息上载到云环境时，加密密钥将成为确保数据不会丢失并保持可用的关键组件。因为丢失相关的加密密钥会导致数据丢失）、账户/服务流量劫持、不安全的接口和API、拒绝服务、恶意内部人员、滥用云服务、尽职调查不足、共享技术漏洞（所有租户共享相同底层架构，相同的漏洞导致一损俱损）。

云计算顶级威胁The Treacherous12列出了12大安全风险，包括：数据泄露、凭据或身份验证遭到攻击或破坏、接口和API被黑客攻击、利用系统漏洞、账户被劫持、来自企业内部的恶意人员、APT攻击、永久性的数据丢失、缺乏尽职调查、云服务的滥用、DoS攻击、共享技术漏洞。

这两份云环境安全风险调查报告有很多相同的部分，这里不再展开详述，读者可以自寻相同点，必定可以发现云内重要安全风险所在。

除了上述CSA发布的云内安全风险以外，欧盟ENISA也发布了云内8个顶级安全风险，本文列出以供参考：

ENISA Top 8：治理缺失、lock-in、隔离失效、不安全或不完整的数据删除、恶意内部人员、管理平面失效、合规风险和数据保护。

四、云内安全展望

从安全的角度来看，识别云计算风险只是风险管理的第一步，但只有识别清楚云内风险，才能进行下一步的风险分析、设计风险控制措施、判断残余风险和实行风险监督。

本文只是简单的罗列出云内可能出现的重要的安全风险，并进行了简单的概括性阐述，希望对读者有所帮助。