一、概述

企鹅今天想分享云原生应用安全防护系列，本文笔者主要针对微服务架构下的应用安全、Serverless安全提出一些防护见解及思考。文章篇幅较长，内容上与之前笔者发表的若干文章有相互交叉对应的部分，希望能为各位读者带来帮助

二、微服务架构模式

数字时代的微服务安全

微服务架构已经成为构建现代应用程序的默认方式。要从微服务中获得最大的收益，需要清楚地了解微服务安全及其架构设计。微服务安全的设计应是预设安全，需要站在微服务架构角度进行安全治理，结合数字化时代及业务特性，保证业务价值实现。

这里CSA发布《微服务架构模式》，给出了 CSA 的最佳实践与总结，通过 CSA 微服务安全参考架构以及安全控制措施叠加的新思路，保证了微服务在架构层面的安全性。

成功地开发基于微服务架构的应用软件，需要掌握一系列全新的架构思想和实践。[2] 在这本独特的书籍中，微服务架构的先驱、Java 开发者社区的意见领袖 Chris Richardson 收集、分类并解释了 44 个架构设计模式，这些模式用来解决诸如服务拆分、事务管理、查询和跨服务通信等难题。

（1）数字化时代的网格管理

数字化转型是全球的热门话题，是组织应用新兴技术从根本上提高组织的业绩及创新的新兴方法。在云计算、大数据、物联网(IoT)、人工智能、5G（6G），和移动应用等新兴技术的应用，加速了整个社会及组织形态的变化。这些新兴技术已经改变了传统的工作流程，并使组织成为数字化时代网格模式与网格管理。

数字化时代网格模式在数字化转型中无处不在，在每个行业都在发生。网格模式影响组织的所有活动、功能和流程，也影响着组织每个部门，因为它可以影响业务模型本身。数字化时代的网格管理是指在数字转型背景下，业务、功能、流程、安全等都是相互关联的，网格管理模式是数字化的核心表现。

网格管理模式下组织的生存离不开效率，效率是敏捷性最重要的指标。组织级敏捷转型的终级目标是把敏捷应用到整个组织中，给业务带来创新与收益。组织采用敏捷建模可以提升响应能力，微服务架构是敏捷建模（AM）的应用体现。

（2）微服务安全是数字化成功的重要基石

数字化转型成功的重要基石之一是业务与IT的关系，需要缩小两者之间的差距，专注于相同的目标。这也是微服务可以在数字转型过程中发挥作用的地方。

微服务可谓当下一大热门词汇，与之并驾齐驱的包括物联网、容器化与区块链等新兴技术。微服务提供敏捷性、可靠性、可维护性、可扩展性和可部署性，帮助组织完成数字化转型过程。微服务架构越来越多地用于设计和实现基于云部署的基础设施、大型应用程序和服务中的应用程序系统。

在应用微服务架构时需要解决许多安全挑战，这也刺激着组织思考微服务安全性在数字化转型中的价值实现，即业务放到云基础设施上并不等于走入数字化时代，业务放到云基础设施必须保证架构的安全性，微服务安全是数字化转型必守之城。

2.如何设计微服务成为可信安全系统

（1）CSA 微服务安全参考架构

DevSecOps模式成为DevOps最新的演进路线，帮助组织在数字化转型过程中实现云原生的安全性。通过将架构的使用、架构模式和安全控制措施叠加成为一个整体，在技术上实现了网格模式，确保了组织应用的机密性、完整性和可用性（CIA）。

无论组织领导者倾向于购买现成解决方案还是 “内部构建”，微服务和API消费的集成都会是一种常见的系统集成预期。随着组织继续对流程数字化，安全团队必须应对增加的攻击矢量和更复杂的管理，同时还要与越来越复杂的攻击者保持同步。面对这一巨大的挑战，安全团队必须评估和更新他们的遗留安全过程、工具和技能集，以适应新的、可适应的组织安全方法。

为了便于指导安全控制措施叠加对微服务的施用，通用微服务架构模式通过两个分支形成了两个不同的视角。第一个视角着眼于组织层面。组织层面包含了可协助实现微服务架构治理的信息技术资产。组织期望减少控制措施状态的变数。自定义编码、生产状态变通方案和一次性修改都会增加开发成本。第二个视角着眼于软件层面。分布式微服务应用的分解图，这种状况存在于软件层面，是最接近软件代码的表现方式。

2）安全控制措施叠加

安全叠加概念：是指运用裁剪标准及指南的方法裁剪控制基线后得出的一个全套特定控制措施、控制措施强化和补充指南集，帮助组织实现安全管控

安全控制措施叠加可通过执行相关业务和安全策略把风险降至一个可接受水平。控制挑选是在业务需要、投放市场时间和风险容忍度之间平衡的结果。安全叠加包装了一种软件模式，尽管它可能会带来更大的安全控制覆盖范围，但是，适合于一种模式的，只会有一个安全叠加。在微服务架构内的不同位置和层级发挥作用的控制措施，会产生形成软件深度防御的累加效应。

三、微服务应用安全

认证服务

由于攻击者在进行未授权访问前首先需要通过系统的认证，因而确保认证服务的有效性非常重要，尤其在微服务应用架构下，服务的不断增多将会导致其认证过程变得更为复杂。

授权服务

授权服务是针对未授权访问风险最直接的防护手段，微服务应用架构下，由于服务的权限映射相对复杂，因而会导致授权服务变得更难。

数据安全防护

与《云原生应用安全风险思考》一文中分析数据安全防护的必要性一样，但微服务应用架构下，服务间通信不仅使用HTTP协议，还会使用gRPC协议等，这是我们需要注意的地方。

其它防护

除了上述防护方法之外，微服务治理框架与API网关/WAF可以结合以进行深度防护，例如可以在一定程度上缓解微服务环境中被拒绝服务攻击的风险。

1.认证服务

微服务架构下，服务可以采用JWT或基于Istio的认证方式

（1）基于JWT(JSON Web Token)的认证

微服务架构下，每个服务是无状态的，传统的session认证方式由于服务端需要存储客户端的登录状态因此在微服务中不再适用。理想的实现方式应为无状态登录，流程通常如下所示：

客户端请求某服务，服务端对用户进行登录认证；
认证通过，服务端将用户登录信息进行加密并形成令牌，最后再返回至客户端作为登录凭证；
在2步骤之后，客户端每次请求都需携带认证的令牌;
服务端对令牌进行解密，判断是否有效，若有效则认证通过，否则返回失败信息；

为了满足无状态登录，我们可通过JWT实现，JWT是JSON风格轻量级认证和授权规范，也就是上述流程中提到的令牌，主要用于分布式场景，

JWT交互流程与上述提到的理想流程基本上是相似的，需要注意的是，JWT令牌中会包含用户敏感信息，为防止被绕过的可能，JWT令牌采用了签名机制。此外，传输时需要使用加密协议。

（2）基于Istio的认证

Istio的安全架构

Istio的认证和授权两部分，Istio的安全机制涉及诸多组件，控制平面由核心组件Istiod提供，其中包含密钥及证书颁发机构（CA）、认证授权策略、网络配置等；数据平面则由Envoy代理、边缘代理（Ingress和Egress）组件构成。借助控制平面Istiod内置的CA模块，Istio可实现为服务网格中的服务提供认证机制，该认证机制工作流程包含提供服务签名证书，并将证书分发至数据平面各个服务的Envoy代理中，当数据平面服务间建立通信时，服务旁的Envoy代理会拦截请求并采用签名证书和另一端服务的Envoy代理进行双向TLS认证从而建立安全传输通道，保障了数据安全。

2.授权服务

微服务架构下，授权服务可以通过基于角色的授权以及基于Istio的授权实现

（1）基于角色的授权服务

基于角色的授权服务为RBAC（RoleBased Access Control），通过角色关联用户，角色关联权限的方式间接赋予用户权限。在微服务环境中作为访问控制被广泛使用，RBAC可以增加微服务的扩展性，例如微服务场景中，每个服务作为一个实体，若要分配服务相同的权限，使用RBAC时只需设定一种角色，并赋予相应权限，再将此角色与指定的服务实体进行绑定即可。若要分配服务不同的权限，只需为不同的服务实体分配不同的角色，而无需对服务具体的权限进行修改，通过这种方式不仅可以大幅提升权限调整的效率，还降低了漏调权限的概率。

（2）基于Istio的授权服务

提到的Istio认证机制作为基础，Istio还提供授权机制，其主要用于对服务进行授权。在Istio 1.4版本之前，其授权机制依赖于Kubernetes的RBAC策略，相比Kubernetes的原生RBAC策略，Istio对其进行了进一步的封装，可让用户直接通过Istio的声明式API对具体的服务进行授权，不过Istio为了更好地用户体验，在其1.6版本中引入了AuthorizationPolicyCRD[16]（Custom Resource Definition），相比1.4版本，AuthorizationPolicy CRD带来了更多的优势，一方面该CRD将RBAC的配置变得更为简化为从而大幅提升了用户体验，另一方面该CRD支持了更多的用例，例如对Ingress/Egress的支持，且同时不会增加复杂性。

（3）Istio授权策略：

apiVersion:security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata: 
name: httpbin
 namespace: foo
spec:
 selector: 
  matchLabels: 
    app: httpbin 
    version: v1 
rules: 
– from:   
– source:       principals:[“cluster.local/ns/default/sa/sleep”]  
 to: 
  – operation:      
 methods: [“GET”]  
 when:  
 – key: request.headers[version]    
 values: [“v1”, “v2”]

3.数据安全

传统应用架构中，我们可以通过安全编码、使用密钥管理系统和使用安全协议的方式防止数据泄露，在微服务应用架构中，我们可以考虑使用Kubernetes原生的安全机制或微服务治理框架的安全机制去进行防护。

针对Kubernetes原生的安全机制，例如Secret机制，我们可以使用其进行密钥存储，从而规避了敏感信息硬编码带来的数据泄露风险。

针对微服务治理框架的安全机制，如Istio支持服务间的TLS双向加密、密钥管理及服务间的授权，因而可以有效规避由中间人攻击或未授权访问攻击带来的数据泄露风险。

4.其他防护机制

采用微服务治理框架的防护方式可在一定程度上有效规避云原生应用的新风险，但其防护点主要针对的是微服务架构下应用的东西向流量，针对南北向的流量防护稍显脆弱，由于微服务架构下的应用防护应当是全流量防护，因而针对南北向所存在的问题，我们可以考虑将微服务治理框架与API网关和WAF相结合，从而提升南北向的防护能力。

（1）Istio和API网关协同的全面防护

针对应用的南北流量而言，Istio采取的解决方案为使用边缘代理Ingress与Egress分别接管用户或外界服务到服务网格内部的入/出站流量，Ingress与Egress实则为Istio部署的两个Pod，Pod内部为一个Envoy代理，借助Envoy代理的安全Filter机制，在一定程度上可对恶意Web攻击进行相应防护，但现有的Envoy安全Filter种类相对较少，面对复杂变化场景下的Web攻击仍然无法应对，可行的解决方案为在服务网格之外部署一层云原生API网关.

（2）Istio和WAF结合的深度防护

WAF作为一款抵御常见Web攻击的主流安全产品，可以有效对Web流量进行深度防护，并且随着云原生化概念的普及，国内外安全厂商的容器化WAF产品也在迅速落地，未来容器化WAF与Istio的结合将会在很大程度上提升微服务安全。

另一种解决方案是Radware提出的Kubernetes WAF方案，该方案基于Istio实现，其中WAF被拆分为Agent程序和后端服务两部分，Agent程序作为Sidecar容器置于Pod的Envoy容器和业务容器间，该Sidecar的主要作用为启动一个反向代理，以便将外部请求流量代理至Pod外部的WAF后端服务中。该套方案带来的好处是无需关心外部请求如何路由至Pod、与Istio结合的理念更接近云原生化、实现了以单个服务为粒度的防护。

四、总结

云原生大概念下，安全问题必然是最重要的问题之一，需要我们每一位开发者和测试者的努力。

版权声明：本文为CSDN博主「跳楼梯企鹅」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_50481708/article/details/126277058

云原生在网络安全领域的应用