二、云原生应用架…本博客地址https://security.blog.csdn.net/article/details/129303616

一、传统风险

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

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

微服务应用架构中单体应用被拆分为若干个服务这些服务会根据业务情况进行相互访问若某服务存在API漏洞攻击者可能就会看到应用内部的流量。

因此对于数据泄露的风险程度而言微服务架构比传统单体应用架构带来的风险更大。

此外随着服务数量达到一定规模API数量将不断递增从而扩大了攻击面增大了数据泄露的风险。

应用的开发过程中安全意识不高的开发者常疏于对密钥的管理导致数据泄露的风险。

例如开发者将密钥信息、数据库连接密码等敏感信息硬编码在应用程序中从而增大了应用程序日志泄露、应用程序访问密钥泄露等风险。

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

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

应用漏洞是造成未授权访问的一大因素。

众所周知未授权访问漏洞非常多Redis、MongoDB、Jenkins、Docker、ZooKeeper、Hadoop等常见的应用都曾曝光过相关漏洞。

在微服务应用架构下其包含的所有服务均须对各自的访问进行授权从而明确当前用户的访问控制权限。

此外服务的访问来源除了用户外还包含内部的其他服务因而在微服务架构下应用的认证授权机制更为复杂为云原生应用带来了更多的攻击面。

在微服务应用架构下访问权限除了涉及用户对服务的访问权限还涉及服务对服务这一层面因而权限映射关系变得更加复杂相应的权限配置难度也在同步增加。

例如一个复杂应用被拆分为100个服务运维人员需要精密地对每个服务赋予其应有的权限如果因疏忽为某个服务配置了错误的权限攻击者就有可能利用此缺陷对服务展开攻击。

若该服务中包含漏洞就可能会导致单一漏洞扩展至整个应用。

应用漏洞可以导致应用被拒绝服务攻击以ReDoS漏洞为例。

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

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

3.1、未授权访问风险

API调用过程中往往会传递相关的参数根据业务场景的不同参数会有不同的取值范围。

若API对相应参数的监测机制不完善那么攻击者便可通过输入异常参数使业务系统受到损失。

例如若商品价格只在商品介绍服务中进行校验而未在订单管理和支付服务中进行校验那么攻击者就可以通过直接调用订单管理和支付服务的API将订单价格修改为0元或者负值使业务系统受到损失。

该风险一般是攻击者采用某些方法使API调用的逻辑顺序出现异常包括关键调用步骤缺失、颠倒等。

例如攻击者可以利用漏洞绕过支付步骤直接提交订单这样就会出现业务逻辑关键步骤缺失的情况进而会使业务系统受到损失。

例如验证码绕过异常就属于业务逻辑异常的一种。

3.2、业务频率异常风险

业务频率异常主要指针对一个或一组API的频繁调用举个例子业务系统往往通过图形验证码的方式来避免机器人刷单的操作。

而如果攻击者可以绕过验证码所对应的服务直接对订单进行操作就可以实现机器刷单从而进行薅羊毛了。

四、Serverless风险

在传统应用程序开发中开发者根据自身实践经验在数量有限的可能性中可判定出恶意输入来源而在Serverless模式下函数调用由事件源触发输入来源的不确定性限制了开发者的判定。

例如当函数订阅一个事件源后该函数在该类型的事件发生时被触发这些事件可能来源于FaaS平台也可能来源于未知的事件源可以将来源未知的事件源标注为不受信任。

在实际应用场景中如果开发者没有养成良好的习惯不对事件源进行分类则会导致将不受信任的事件错认为是FaaS平台事件进而将其视为受信任的输入来处理最终带来风险。

4.2、Serverless应用风险

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

因此传统应用面临的风险Serverless应用也一样要面临。

4.3、Serverless平台风险

Serverless平台主要指FaaS平台。

目前主流的FaaS平台分为两种类型一种是面向公有云提供商的FaaS平台常见的有AWS

Lambda、Microsoft

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实现攻击资产的隐秘。

此外依托云厂商服务器的稳定性也可以在一定程度上避免由网络问题导致的受害者机器下线。