阅读： 15
一、概述
云原生技术的迅猛发展已经在全球各行各业产生积极的应用实践。根据Gartner在2019年的容器报告中预测，在2020年将有50%的传统老旧应用被云原生化改造，到2022年，全球75%的企业将会使用云原生的容器化应用。然而，由于应用架构的变革，在遵循面向微服务化的设计方式的前提下，功能组件化、服务API数量的激增，以及配置的复杂性等问题也随之而来。这些架构变化导致了传统Web请求/响应的服务交互模式向API请求/响应的服务交互模式的转变，如RESTful/HTTP、gRPC、GraphQL等。因此，在未来的云原生环境中，API将作为主要的服务交互载体被大规模企业用户使用。
另一方面，从近年的安全事件来看，API安全问题呈现上升的态势，严重威胁了用户的隐私和数据安全。一些典型的安全事件包括：2019年11月，国外安全人员发现超过2.67亿条Facebook ID、电话号码和姓名等信息被存储在某公开数据库中。相关研究显示，该数据库通过某未知API接口抓取，而非来自公开信息。2020年4月，视频会议服务厂商Zoom被爆出多项安全漏洞，其中包括Facebook Graph API滥用导致隐私数据泄露问题。2021年4月，Facebook 5亿用户数据泄露，据暗网上公布的数据截图，涉及到用户昵称、邮箱、电话等信息。2021年6月，国外社交网络服务网站LinkedIn爆发大规模数据泄露事件，近7亿用户信息在暗网上被售卖，据相关研究人员证实，攻击者最终是利用LinkedIn的某一API获取到用户的敏感数据。2021年12月，国内某证券公司的客户信息，包括用户姓名、手机号等敏感数据以每日1万条的量级在数据交易平台被售卖，经验证分析，证实为内部系统数据API管控疏忽导致。2022年4月，WordPress插件Rank Math爆出严重的API安全漏洞，借此漏洞可以直接修改用户数据库表信息。
根据云安全联盟（CSA）发布的云原生技术标准模型[2]（如图1所示），我们可以看出横轴是开发运营安全的维度，涉及需求设计、开发、运营阶段，细分为需求、设计、编码、测试、集成、交付、防护、检测和响应阶段。纵轴则按照云原生系统和技术的层次进行划分，包括容器基础设施安全、容器编排平台安全、微服务安全、服务网格安全、无服务器计算安全五个部分。安全机制（蓝色标注部分）基本上覆盖了全生命周期的云原生安全要求。
图1. 云安全联盟（CSA）发布的云原生技术标准模型
根据上图以及笔者的观察，容器安全产品在国内市场中，容器基础设施安全和容器编排平台安全的方案成熟度比较高，也得到广泛的应用和验证。而微服务安全、服务网格安全以及无服务器安全领域的成熟度则相对较低，这也是正常的，技术总是需要经历萌芽期、试探期、成熟期、衰败期等整个过程的。
未来，微服务间必然会使用大量API进行交互，这些API可能产生于FaaS函数、容器应用、Pod等载体中。相应地，云原生API安全风险将随着云原生环境的进一步发展而不断增加，因此API安全的需求也将逐渐增多。在这种背景下，API安全对于保护整个云原生环境的安全性至关重要，将成为云原生安全的下一个重要阶段。
本文将围绕云原生API所面临的安全风险以及相应的防护思路进行探讨，并介绍绿盟在云原生API安全防护上的一些思考与技术方案。希望这些内容能为各位读者带来一些启发与思考。
二、云原生API安全风险
笔者认为云原生API安全风险应当从缺乏可见性、应用架构变化、东西向流量难以防护这几个方面去考虑。
2.1 缺乏可见性导致的风险
云原生环境中，由于微服务数量增多，每个微服务包含多个API，因此微服务之间的API调用变得更加复杂。这种情况下，整个API系统的可见性变得缺乏，这可能导致以下几个问题：
首先，API资产存在不可见性，当API资产受到黑客攻击时，很难及时定位入侵位置，从而错过最佳处理时间，增加安全风险。
其次，API异常行为也缺乏可见性，例如高频访问某API或利用API的未授权访问漏洞进行大量数据下载等异常行为。这些行为可能导致接口不稳定或敏感数据泄漏的风险。
最后，随着微服务应用架构的普及，东西向流量交互增多导致API数量激增，API权限管理变得更为复杂，由API调用链组合导致的权限绕过问题成为API业务安全的防护难题。
2.2 应用架构变化导致的风险
我们知道，新应用架构遵循微服务化的设计模式，通过应用的微服务化，我们能够构建容错性好、易于管理的松耦合系统，与此同时，新应用架构的出现也会引入新的风险，本文笔者从数据泄露风险、未授权访问风险、被拒绝服务风险三方面进行介绍[1]。
2.2.1 数据泄露风险
当单体应用被拆分为若干个服务后，这些服务会根据业务情况进行相互访问，API访问范围变为服务到服务（Service to Service），若某服务因API漏洞导致攻击者有利可图，那么攻击者将会看到应用内部的流量，这无疑为攻击者提供了更多的攻击渠道，因而针对数据泄露的风险程度而言，微服务架构相比传统单体应用架构带来的风险更大。此外，随着服务数量达到一定规模，API数量将不断递增，进而扩大了攻击面，增大了数据泄露的风险。
传统单体应用架构中，由于网络拓扑相对简单，且应用通信多基于HTTP/HTTPS，因而造成的数据泄露风险多是因为采用了HTTP协议。微服务应用架构中，网络拓扑相对复杂，因遵循分布式的特点，应用间的通信不仅采用HTTP/HTTPS协议，还采用gRPC等协议，由于gRPC协议默认不加密，因而将会导致攻击面的增多，为数据泄露带来了更多的风险。
2.2.2 未授权访问风险
在单体应用架构下，应用作为一个整体对用户进行认证授权，且应用的访问来源相对单一，基本为浏览器，因而风险是相对可控的，微服务应用架构下，其包含的所有服务均需对各自的访问进行授权，从而明确当前用户的访问控制权限，此外，服务的访问来源除了用户外还包含内部的其他服务，因而在微服务架构下，应用的认证授权机制更为复杂，为云原生应用带来了更多的攻击面。
微服务应用架构下，由于访问权限还需涉及服务对服务这一层面，因此将会导致权限映射关系变得更加复杂，相应的权限配置难度也在同步增加，例如一个复杂应用被拆分为100个服务，运维人员需要精密地对每个服务赋予其应有的权限，如果因疏忽导致为某个服务配置了错误的权限，攻击者就有可能利用此缺陷对服务展开攻击，若该服务中包含漏洞，进而可能会导致单一漏洞扩展至整个应用的风险。所以如何对云原生应用的访问权限进行高效率管理成为了一个较难的问题，这也是导致其风险的关键因素。
2.2.3 被拒绝服务风险
在微服务应用架构下，由于API数量会随着服务数量的递增而递增，因而可能将会导致单一请求生成数以万计的复杂中间层和后端服务调用，进而更容易引起被拒绝服务的风险，例如若微服务应用的API设计未考虑太多因单个API调用引起的耗时问题，那么当外部访问量突增时，将会导致访问需求与资源能力不匹配的问题，使服务端无法对请求作出及时的响应，造成页面卡死的现象，进而会引起系统崩溃的风险。
2.3 东西向流量难以防护的风险
图2. 云原生环境下的东西向流量
云原生应用场景下的流量不仅包含传统基于边界的南北向流量，还包含集群节点间，微服务间访问的东西向流量，如果攻击者通过漏洞利用攻入集群内部，进而可能通过利用脆弱的认证机制横向移动入侵至其他微服务导致集群整体的瘫痪。
2.4 其他风险
在云原生环境中，由于API的类型种类繁多，包括影子API、僵尸API、东西向API、南北向API、公共API、内部API等，而且它们的迭代周期非常短，后端架构也更为复杂，因此管理起来更为困难。
此外，传统的安全设备很难适配API使用的其他协议，例如gRPC、SOAP、GraphQL等。这些协议的出现使得云原生环境下的API安全风险进一步上升。
三、云原生API安全防护思路
在讨论云原生API安全防护具体思路前，笔者想先提出云原生API安全防护的必要性，以下几个问题可能是读者普遍比较担忧的几个问题：
问题一. 我的容器基础设施已有安全保护了，但业务部门运行的是微服务、服务网格和无服务，这些新的服务的如何治理，安全性如何保证？
问题二. 我有硬件、虚拟化或其他南北向的WAF了，但东西向的微服务安全怎么办？
问题三. WAF能解决所有的API问题吗？
带着以上问题，笔者梳理一些防护思路，下文将做具体介绍。
API是微服务架构中通信的重要媒介，在云原生环境中，微服务通常以容器或Pod的形式出现，这些微服务在容器编排平台，例如Kubernetes或OpenShift中运行，或者运行在服务网格（Service Mesh）中。因此，在云原生API安全防护方面，需要考虑容器编排平台和服务网格两种场景下的安全防护措施。
3.1 Kubernetes场景
图3. Kubernetes场景防护方案
Kubernetes场景中，常有的防护方案是在Kubernetes Ingress Controller前串行部署API安全网关用于处理恶意流量， 此时，API安全网关核心能力为WAF的能力，开源的API网关如Ambassador、Gloo、Envoy Gateway等虽然也集成了一部分的安全能力，但缺陷是集成的防护规则相对较弱，许多传统安全厂选择将其WAF产品容器化，并充分利用K8S的负载均衡和自动扩缩容能力提升高可用性。
然而，以上提出的方案实际也存在着一些问题，笔者认为主要有以下几方面：
首先，安全网关部署位置实际仍处于集群边界处，与传统安全网关部署位置相同，仅能对微服务的南北向流量进行防护，无法进行全向流量防护；
其次，采用WAF进行防护仅能处理7层恶意流量，并且无法覆盖OWASP API Security Top 10中的所有风险。在云原生环境中，微服务间通信协议还包括各类RPC调用，如Google的gRPC、阿里的Dubbo、Facebook的Thrift RPC等，此外还存在GraphQL、SOAP等通信协议，这些都是WAF无法进行防护的；
最后，云原生环境下，如果微服务访问采用加密流量，由于其数量可能会很多，传统WAF的证书卸载功能因为缺乏证书统一管理模块，因而并不一定适用于云原生场景，因此笔者认为该方案在某种程度上无法处理微服务加密流量。
3.2 Service Mesh场景
3.2.1 安全能力容器化，通过引流将业务流量牵引至安全容器
图4.Istio安全架构图
图4为Istio的安全架构图，我们知道Istio的数据平面主要通过Envoy代理容器实现流量管理、安全能力以及可观测性能力，安全方面主要提供以下机制：
- 服务间及外部服务间多种认证授权机制；
- 证书管理机制、加密流量卸载机制；
- Envoy提供CSRF、外部授权服务器（ext_auth filter，连接如WAF设备）、限流等HTTP安全过滤器
图5.Envoy安全类Filter
由图5我们可以看出Envoy自有的安全能力并不够，可行的一种方案是通过Envoy的引流filter引流到外部的安全容器，那么这个时候将传统的WAF容器化是一个较好的选择，WAF也可以充分利用K8S的LB进行动态扩缩容。方案如图6所示：
图6. 通过Envoy引流Filter实现的方案
该方案通过Envoy容器进行流量牵引，使得所有集群服务的流量都经过了WAF的检测，具备了对东西向流量的检测优势。然而，这种方案也存在一些缺陷，其中最明显的就是Envoy引流插件的性能问题，即如何保证它能够承受大规模并发流量，并且防止服务宕机等问题。因此，针对这方面进行深入研究是非常有必要的。
3.2.2 安全能力集成至现有Sidecar容器
另一个思路是复用服务网格自身提供的扩展能力，如Envoy的扩展能力，实现将安全能力集成至现有的Sidecar容器，笔者将可以复用的Envoy扩展梳理为以下三种：
图7. Envoy扩展能力总结
3.2.3 安全能力Sidecar化
最后一种思路是将安全能力Sidecar化，我们知道Istio提供Sidecar自动注入能力，我们可以通过修改Istio注入模板，将安全能力作为Sidecar容器放置在现有Service数据平面中，如图8所示：
图8. 安全能力Sidecar化示意图
上述思路，通过一定的策略管理，Service Mesh可接管微服务的流量治理、监控及追踪甚至具备一定的基础防护能力，安全容器以轻量级安全伴生容器的方式透明注入至微服务中，并随着微服务资源的变化而变化，不仅可与现有服务网格治理框架高度兼容，也能进一步提升服务网格在流量侧的全向安全防护能力。此外，也能带来一些额外的优势，如：
- 爆炸半径更小 — 爆炸半径仅限于一个微服务，即使安全容器因各种因素停止运行，由于安全容器于微服务内部运行，因而不会影响其他业务的正常运行。
- 代理维护成本低 — 利用容器编排工具现有的滚动升级更新、灰度发布等机制，无需额外进行开发维护。
- 安全边界更清晰 — 安全容器仅对位于同一微服务中的业务应用进行防护，与应用具有相同的IP地址。
- 代理资源消耗依赖应用负载自身的变化 — 传统安全网关如WAF可能会存在不同站点流量抢夺的问题，即若有站点占用了较高的流量，消耗了WAF的所有资源，则其他站点流经的恶意流量将不会被处理，导致WAF无法正常工作，安全容器Sidecar化这种方式可通过配置微服务资源消耗占比有效应对此场景。
- 容器级别的隔离防护 — 安全容器的方式可以让内核在容器级别执行所有的安全防护能力
然而，该方案也存在一定的性能问题，比如高并发流量场景下，安全容器处理恶意流量会占用大量CPU和内存，导致超过节点承受最大阈值，即便安全网关容器不处理恶意流量也会占用一定内存和CPU，引起不必要的性能消耗；此外，针对Kubernetes集群容器数量有一定限制的场景下，会影响正常业务的运行（如100个容器中，单安全容器就占用50个），再如这种方式将会导致请求链路增加，最终导致吞吐量降低和延迟升高
四、云原生API安全解决方案
技术实现上，我们提供了两种解决方案，分别支持Kubernetes以及Service Mesh场景，如图9所示：
图左为适配于Service Mesh的微API安全网关方案，安全能力采用轻量级的方式，无感知地接入每个微服务应用中，根据集群具体业务不同，可采用不同的API安全模块进行精准防护。此方案与Service Mesh配合使用，能够快速将微API安全网关注入至每个微服务应用中，同时对集群中的每个微API安全网关运行数据进行管理面上统一分析，并通过安全编排层进行服务策略编排，实现基于微服务粒度的全向安全防护能力，
图右为适配于Kubernetes的节点API安全网关方案，该方案采用eBPF技术将集群微服务引流从用户空间offload至内核层实现，降低系统CPU消耗的同时，提升了处理性能，也同时支持全向流量安全防护及灵活的策略编排。
图9. 解决方案简要示意图
五、总结
Gartner早在2020年1月提出了CNAPP（Cloud Native Application Protection Platform 云原生应用防护平台）的术语，其集合了CWPP和CSPM的功能，重点强调了云应用安全防护的重要性，笔者认为，云原生API安全可有效针对微服务进行应用层面防护，是企业构建CNAPP过程的必经阶段，也是未来构建云原生应用安全（微服务安全、服务网格安全、FaaS安全）必不可少的一环。此外，云原生API安全不应仅具备基于网络层面的威胁检测能力，还应集成API业务安全能力，以应对通过微服务业务逻辑漏洞对微服务进行攻击的风险，减少经济损失。最后，我们常说可见才可防，API资产发现能力、分类分级能力和微服务可观测性等技术为API安全提供了有利的土壤，这些也是实现云原生API安全重要组成部分。
综上，本文较为系统的阐述了云原生API安全背景、态势、风险及防护思路，并介绍了绿盟在该领域的一些思考与实践，文章注重技术沟通，如有错误或不当之处，欢迎各位读者批评指正。
参考文献
[1] 云原生安全：攻防实践与体系构建，机械工业出版社，2021
[2] CSA云原生安全技术规范 https://c-csa.cn/u_file/photo/20220316/c96467f1bf.pdf
版权声明
本站“技术博客”所有内容的版权持有者为绿盟科技集团股份有限公司（“绿盟科技”）。作为分享技术资讯的平台，绿盟科技期待与广大用户互动交流，并欢迎在标明出处（绿盟科技-技术博客）及网址的情形下，全文转发。
上述情形之外的任何使用形式，均需提前向绿盟科技（010-68438880-5462）申请版权授权。如擅自使用，绿盟科技保留追责权利。同时，如因擅自使用博客内容引发法律纠纷，由使用者自行承担全部法律责任，与绿盟科技无关。