本博客地址：https://security.blog.csdn.net/article/details/129303616

一、传统风险

传统风险主要是注入、敏感数据泄露、跨站脚本、配置错误等等，这些传统的安全风险在云原生应用中也是存在的，这里就不具体展开说了。

二、云原生应用架构的风险

2.1、【机密性】信息泄露风险

1、应用漏洞导致的信息泄露

微服务应用架构中，单体应用被拆分为若干个服务，这些服务会根据业务情况进行相互访问，若某服务存在API漏洞，攻击者可能就会看到应用内部的流量。因此对于数据泄露的风险程度而言，微服务架构比传统单体应用架构带来的风险更大。此外，随着服务数量达到一定规模，API数量将不断递增，从而扩大了攻击面，增大了数据泄露的风险。

2、密钥管理不规范导致的信息泄露

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

3、应用间通信未加密导致的信息泄露

在微服务应用架构中，网络拓扑相对复杂，具有分布式的特点，应用间的通信不仅采用HTTP/HTTPS，还采用gRPC等协议，而gRPC协议默认不加密，将会导致攻击面增多，带来更多的数据泄露风险。

2.2、【完整性】未授权访问风险

1、应用漏洞导致的未授权访问

应用漏洞是造成未授权访问的一大因素。众所周知，未授权访问漏洞非常多，Redis、MongoDB、Jenkins、Docker、ZooKeeper、Hadoop等常见的应用都曾曝光过相关漏洞。在微服务应用架构下，其包含的所有服务均须对各自的访问进行授权，从而明确当前用户的访问控制权限。此外，服务的访问来源除了用户外还包含内部的其他服务，因而在微服务架构下，应用的认证授权机制更为复杂，为云原生应用带来了更多的攻击面。

2、访问权限配置错误导致的未授权访问

在微服务应用架构下，访问权限除了涉及用户对服务的访问权限，还涉及服务对服务这一层面，因而权限映射关系变得更加复杂，相应的权限配置难度也在同步增加。例如一个复杂应用被拆分为100个服务，运维人员需要精密地对每个服务赋予其应有的权限，如果因疏忽为某个服务配置了错误的权限，攻击者就有可能利用此缺陷对服务展开攻击。若该服务中包含漏洞，就可能会导致单一漏洞扩展至整个应用。

2.3、【可用性】遭受拒绝服务攻击的风险

1、应用漏洞导致的拒绝服务

应用漏洞可以导致应用被拒绝服务攻击，以ReDoS漏洞为例。ReDoS为正则表达式拒绝服务，一般表现为应用程序为用户提供了正则表达式的输入类型但又没有对具体的输入进行有效验证，那么攻击者便可通过构造解析效率极低的正则表达式作为输入，在短时间内引发100%的CPU占用率，最终导致资源耗尽甚至应用程序崩溃。

2、访问需求与资源能力不匹配导致的拒绝服务

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

三、云原生应用业务的风险

3.1、未授权访问风险

1、业务参数异常导致的未授权访问

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

2、业务逻辑异常导致的未授权访问

该风险一般是攻击者采用某些方法使API调用的逻辑顺序出现异常，包括关键调用步骤缺失、颠倒等。例如，攻击者可以利用漏洞绕过支付步骤，直接提交订单，这样就会出现业务逻辑关键步骤缺失的情况，进而会使业务系统受到损失。例如验证码绕过异常就属于业务逻辑异常的一种。

3.2、业务频率异常风险

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

四、Serverless风险

4.1、输入源的不确定性

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

4.2、Serverless应用风险

Serverless应用属于云原生应用，云原生应用又源于传统应用，两者唯一的区别是Serverless应用代码编写需要参照云厂商提供的特有代码模板，而传统应用通常没有这个限制。因此，传统应用面临的风险Serverless应用也一样要面临。

4.3、Serverless平台风险

Serverless平台主要指FaaS平台。目前主流的FaaS平台分为两种类型：一种是面向公有云提供商的FaaS平台，常见的有AWS Lambda、Microsoft Azure Functions、Google Cloud Functions等；另一种则是面向私有云的FaaS平台，此类以开源项目居多，且均支持在Kubernetes上进行部署，常见的有Apache OpenWhisk、Kubeless、OpenFaaS、Fission等。

类似在IaaS平台上运行虚拟机、在PaaS平台上运行操作系统和应用，FaaS平台上运行的是一个个Serverless函数。FaaS平台自身负责云环境的安全管理，主要包括数据、存储、网络、计算、操作系统等。同IaaS平台、PaaS平台一样，FaaS平台也面临未授权访问和数据泄露的风险，同时，Serverless还面临FaaS平台账户的风险。

1、未授权访问风险

在FaaS平台中，随着部署函数的增多，函数对资源的访问及可以触发函数执行的事件也在逐渐增多，进而函数间的权限映射关系将会变得复杂，并且函数通常在短时间内执行完成，因此，FaaS平台中的访问权限配置更容易出错，攻击者往往以超特权函数为目标，通过不安全的权限配置以获取对资源的未授权访问。 此外，对于公有云FaaS平台，如AWS Lambda，由于其函数运行时环境存在缺陷，因此当函数代码含有漏洞（如命令注入漏洞）时，攻击者可以利用函数运行时缺陷并结合已知函数漏洞对平台账户的资源进行未授权访问。

2、数据泄露风险

攻击者对函数发起未授权访问，造成的后果往往是数据泄露，同样的，访问权限错误配置也会引起数据泄露的风险。此外，FaaS平台自身的漏洞也会导致数据泄露的风险。

3、FaaS平台账户风险

众所周知，开发者需要承担FaaS平台运行其函数的费用。通常来说，开发者需要注册FaaS平台账户，并将账户与银行卡进行关联，最后按照函数执行的次数向云厂商付费，如果FaaS平台未对账户单位时间内的支付频次进行一定限制，那么在函数含有已知漏洞的前提下，攻击者就可以利用以上缺陷对FaaS平台账户展开攻击。这类攻击统一称为拒绝钱包服务攻击（DoW），为拒绝服务攻击的变种，目的为耗尽账户账单金额。

4.4、Serverless被滥用风险

Serverless被滥用指攻击者通过恶意构建Serverless函数并利用其充当整个攻击中的一环，这种方式可在一定程度上规避安全设备的检测。举个场景，攻击者通过在受害者的主机上投放木马，来实现对受害者主机的控制，其中攻击者为实现攻击资产的隐蔽性，采用了公有云Serverless函数作为请求中转。

这个攻击流程分为四个步骤：

1）受害者主机中的木马程序被执行，该木马会向攻击者主机发起请求以建立连接。
2）攻击者通过构造Serverless函数作为受害者主机和攻击者主机间的中转机，该Serverless函数负责将木马中的上线包发送至攻击者主机。
3）攻击者主机收到来自Serverless函数的请求，与受害者主机成功建立连接，并在响应中附带控制受害者主机的命令。
4）公有云Serverless函数收到攻击者主机的响应，并将执行命令发送至受害者主机的木马程序中，从而实现对受害者主机的远程操作。

通过利用Serverless函数作为请求中转，受害者只能看到与公有云Serverless函数的通信，而无法轻易看到与攻击者主机的通信，且公有云函数的访问域名通常为可信域名，这样一方面可以使受害者放松警惕，另一方面可以隐藏攻击者主机的IP，实现攻击资产的隐秘。此外，依托云厂商服务器的稳定性，也可以在一定程度上避免由网络问题导致的受害者机器下线。