【摘 要】 云原生场景下服务架构的变化，也会引发相关的安全机制出现变化。本文从微服务架构下的应用安全、无服务器计算安全提出了云原生安全防护见解及思考，以提升业界对云原生应用防护的认识。
【关键词】 云原生应用 API安全 无服务器运算安全微服务应用安全
1 引言
2022年4月，云安全联盟大中华区（CSA GCR）发布了《云原生安全技术规范》，针对云原生环境下面临的风险提出了体系化的安全能力要求。如图1所示，云原生应用安全不仅包括容器基础设施和容器编排平台安全，还包括上层的云原生应用安全。云原生场景下服务被拆分成众多微服务，有些通过服务网格形成了点对点（Ad-hoc）的连接模式，相关的安全机制也出现一些变化，而无服务计算（Serveless）作为云原生场景下的一种创新的计算模式，对应的安全机制与传统应用、微服务应用也有所不同，因此对应的防护方式相对传统应用需要做思路上的转变。
2 微服务架构下的应用安全
应用的微服务化带来的新风险主要包含数据泄露、未授权访问、被拒绝服务3种。
（1）数据泄露的风险
云原生环境中，虽然造成应用数据泄露风险的原因有很多，但都离不开以下几个因素。
应用漏洞：通过资产漏洞对应用数据进行窃取。
密钥不规范管理：通过不规范的密钥管理对应用数据进行窃取。
应用间通信未经加密：通过应用间通信未经加密的缺陷对传输中数据进行窃取，进而升级到对应用数据的窃取。
（2）未授权访问的风险
在云原生环境中，应用未授权访问的风险多是由于应用自身漏洞或访问权限错误配置而导致。
（3）被拒绝服务的风险
被拒绝服务是应用程序面临的常见风险。造成拒绝服务的主要原因包括两方面：一方面是由于应用自身漏洞所致，如ReDoS漏洞、Nginx拒绝服务漏洞等；另一方面是由于访问需求与资源能力不匹配所致，例如某电商平台的购买API由于处理请求能力有限，因而无法面对突如其来的大量购买请求，导致平台资源（CPU、内存、网络）的耗尽甚至崩溃，这种场景往往不带有恶意企图。而带有恶意企图的则主要以ACK、SYNC泛洪攻击及挑战黑洞（Challenge Collapsar ，CC）等攻击为主，其最终目的也是应用资源的耗尽。
针对以上提到的风险，相应的防护也应从以上3个方面去考虑，作者通过调研和实践发现使用传统的防护方法是可行的，但当服务随业务的增多而逐渐增多时，传统的防护方法由于需要开发人员进行大量配置而变得非常复杂。例如，用户的应用部署在K8s上，该应用包含上百个服务，做访问控制时可以依托K8s的基于角色的权限访问控制（Role-Based Access Control，RBAC）机制对目的服务进行授权，进而就需要依赖K8s的API以完成配置。每次配置都会耗费一定时间，因此需要大量服务授权时，开发者往往感到力不从心，为解决诸如以上服务治理带来的难题，可以使用微服务治理框架进行相应防护。
综上所述，面向微服务架构下的应用安全，可以采用传统的防护方式或微服务治理框架进行防护，具体的防护措施包含认证服务、授权服务、数据安全防护等。
2.1 认证服务
由于攻击者在进行未授权访问前首先需要通过系统的认证，因而确保认证服务的有效性非常重要，尤其在微服务应用架构下，服务的不断增多将会导致其认证过程变得更为复杂。微服务架构下，服务可以采用JSON Web令牌（JSON Web Token，JWT）或基于Istio的认证方式，下面作者将分别进行说明。
2.1.1 基于JWT的认证
微服务架构下，每个服务是无状态的，传统的服务状态认证方式（Session）由于服务端需要存储客户端的登录状态，因此在微服务中不再适用。理想的实现方式应为无状态登录，流程通常如下所示：
（1）客户端请求某服务，服务端对用户进行登录认证；
（2）认证通过，服务端将用户登录信息进行加密并形成令牌，最后返回至客户端，作为登录凭证；
（3）在步骤（2）之后，客户端每次请求都需携带认证的令牌;
（4）服务端对令牌进行解密，判断是否有效，若有效，则认证通过，否则返回失败信息。
为了满足无状态登录，我们可通过JWT实现。JWT是JSON轻量级认证和授权规范，也就是上述流程中提到的令牌，主要用于分布式场景，其使用流程如图2所示。