九游老哥云
关于云原生应用 ，这些清静危害相识一下
2021-08-05
摘要：云原生应用事实和古板应用有何差别 ，清静危害上有何转变？本文将从古板应用危害、应用架构厘革带来的危害、云盘算模式带来的危害三个维度举行先容 。
一. 概述
随着云盘算手艺的一直生长 ，上云已经不再是一种选择 ，而是一种共识 ，是企业数字化转型的须要条件 。在响应实践历程中 ，古板应用保存升级缓慢、架构臃肿、无法弹性扩展及快速迭代等问题 ，于是近年来云原生的看法应运而生 ，依附着云原生弹性、迅速、资源池和服务化等特征 ，解决了营业在开发、集成、分发和运行等整个生命周期中遇到的问题 。
云原生情形中 ，应用由古板的单体架构转向微服务架构 ，云盘算模式也响应的从基础设施即服务（Infrastructure as a Service ，IaaS）转向为容器即服务（Container as a Service ，CaaS）和函数即服务（Function as a Service ，FaaS） 。应用架构和云盘算模式的厘革是否会导致进一步的危害 ，这些危害较之古板应用危害又有哪些区别？在讲述云原生应用详细危害前 ，首先枚举以下三个看法 ，这些看法有助于各人更好地明确本文所讲述的内容 。
看法一 云原生应用继续了古板应用的危害和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滥用的危害
针对此类危害 ，通常指的是攻击者对营业系统的薅羊毛操作 ，危害成因则是由于营业频率异常所致 ，这里以电商系统举例说明 。
营业频率异常主要指针对一个或一组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平台自身认真云情形地清静治理 ，主要包括数据、存储、网络、盘算、操作系统等 。
4.4 Serverless被滥用的危害
Serverless被滥用详细是指攻击者通过恶意构建Serverless函数并使用其充当整个攻击中的一环 ，这种方法可在一定水平上规避清静装备的检测 。导致Serverless被滥用的缘故原由主要包括以下几点：
1. 云厂商提供Serverless函数的免费试用
近些年 ，各大云厂商为了用户体验 ，均对用户提供免费的Serverless套餐 ，包括每月免费的函数挪用额度 ，这种方法虽然吸引了更多的用户去使用Serverless函数, 但也使得攻击者的攻击本钱大幅降低 。
2. 用户安排Serverless函数的本钱低
由于Serverless服务端托管云厂商的机制 ，故用户只需实现函数的焦点逻辑 ，而无须体贴函数是怎样被安排及执行的 ，使用这些特点 ，攻击者可以编写对其有利的Serverless函数并能省去安排的本钱 。
3. Serverless函数会见域名可信
当用户安排完Serverless函数后 ，需要通过触发器去触发函数的执行 ，通常用户使用云厂商提供的API网关作为触发器 ，建设API网关触发器之后 ，云厂商会为用户提供一个公网的域名 ，用于会见用户编写的Serverless函数 。需要注重的是 ，该公网域名通常是云厂商域名相关的子域名 ，因而是相对可信的 ，鉴于此 ，攻击者可以使用函数会见域名的可信去隐藏其攻击资产 ，逃避清静装备的检测 。
五. 总结
本文详细剖析了云原生应用面临的危害 ，可以看出 ，云原生应用相比古板应用面临的危害主要为应用架构厘革及新的云盘算模式带来的危害 ，而针对应用自己的危害并无较大转变 ，因而对云原生应用架构和无服务器盘算模式的深度明确将会有助于相识整个云原生应用清静 。
参考文献
[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] https://github.com/apache/openwhisk
[6] https://github.com/kubeless/kubeless
[7 https://github.com/openfaas/faas
[8] https://github.com/fission/fission
