【摘 要】 本文主要针对云原生架构下的微服务安全现状进行了研究，提出了基于微服务的安全风险评估模型，给出了云原生架构下的微服务安全解决方案。

【关键词】 云计算 微服务 网络安全

1 引言

在为企业提供边缘计算、节点安全、自动化以及智慧数据服务方面，基于云计算构建的网络架构模型存在诸多优点，如能够实现规模经济效应，有效整合、配置资源，具有高可用性等。云计算集成了各种计算技术，为终端用户提供微服务（Micro Services）。然而，在云计算与微服务发展的同时，也存在着一些安全隐患。

2 云原生架构下的微服务安全现状及面临的问题

为了理解与云计算相关的安全问题，首先要理解云计算的概念。美国国家标准技术研究院（NIST）将云计算视为服务提供的三重模型，其中包括基本特征、服务模型和部署模型。NIST对云计算的定义如图1所示。

云计算的特征和模型提供了改进、优化的解决方案，并能为客户降低成本。然而各种技术的实现（如虚拟化和多租户）也产生了云计算所特有的安全风险和漏洞，如容器基础设施安全、容器编排平台安全、微服务安全、服务网格安全、无服务器计算安全等。本文介绍了云原生架构下的微服务安全问题，具体细分为微服务应用程序编程接口（API）安全、微服务应用安全。其中，微服务API安全主要包括云原生API网关、API脆弱性评估；微服务应用安全主要包括认证授权、API安全、通信安全、凭证管理、日志审计、监控追踪等。

云原生架构下的微服务是一个通过消息进行交互的内聚、独立的过程。例如，一个用于计算的微服务框架，它能够提供可通过消息请求的算术运算，但不能提供其他如绘图和可视化等功能。从技术角度来看，微服务是概念上部署的独立组件隔离并配备专用内存持久性工具（如数据库）。微服务架构是一种分布式应用程序，它的所有模块都是微服务。由于微服务体系结构的所有组件都是微服务，因此个体活动源自其组件通过消息的组合和协调。图2是一个微服务架构的示例图，假设存在2种微服务：计算器和显示器。第一个是上文提到的计算器微服务，第二个是渲染和显示图像。为了实现研究目标，我们可以引入一种新的微服务，称为绘图仪，它协调计算器进行计算图形的形状，调用Displayer渲染计算的形状。

微服务的概念源于工业实践，它将大型单片应用程序划分为更小的协同服务，从而实现更大规模的可维护、可扩展和可测试，以适应云环境。使用微服务架构开发和部署云应用程序越来越流行。尽管微服务架构的开发和部署在云生产环境中有一些优势，但安全性仍是企业和客户优先考虑的，因此我们首先要确定微服务面临的主要安全问题。如图3所示，云计算开发人员应注意微服务常见安全问题。

2.1 云原生架构下的微服务容器安全

首先，容器的存在为微服务提供了一个完美的环境。使用容器包装或集装箱化分布式微服务的优势明显。例如，容器消除了对底层基础设施服务的依赖，从而减少了对接不同平台的复杂性。因此，微服务架构可以利用Docker容器来测试和跨可用的计算机网络与其他计算设备在单独的容器中部署单个服务。此外，容器可以提供标准化建设和持续整合与交付服务。简而言之，容器的存在、发展与微服务联系紧密，它们结合在一起，形成一个生态系统。当Docker容器出现安全问题时，可能会引起连锁反应。

云原生架构下的微服务容器主要有2类攻击者：直接攻击者和间接攻击者。直接攻击者瞄准内部的核心服务容器，销毁或修改网络和系统文件。例如，攻击者可以从面向互联网的容器服务中获得相关容器中的根权限。进而从被攻击的容器对运行在同一主机操作系统上的其他容器发起攻击，并获得对关键主机操作系统的访问权限系统文件。间接攻击者与直接攻击者具有相同的能力，但他们的目标是容器生态系统，如代码和图像存储库，到达软件环境。容器攻击面包含整个部署工具链。部署工具链包括映像概念、映像分发过程、自动构建、映像签名、主机配置和第三方组件。图像分发中的漏洞源于容器中心（如Docker hub）和容器生态系统中的其他注册表。此外，容器图像分布的设置增加了几个外部步骤，从而增加了全局攻击面。例如，一旦容器中的黑客程序启动有效的逃逸攻击可以获得主机的根权限，这将影响其他容器或整个系统的可靠性。

2.2 云原生架构下的微服务数据安全

微服务由于其精细的粒度，需要更复杂的通信。因此，消息数据不仅可能被拦截，也可能被竞争对手利用而推断出具体业务运营明细情况。因为微服务通常部署在云环境中，除了消息传输之外，微服务还存在隐私安全问题，云消费者也担心他们存储的信息可能被泄露或不当使用。微服务部署在许多分布式容器中，因此，客户可能会对其私人信息的安全性产生怀疑。如何防止传输的消息泄露仍然是一个严峻的问题。

为了确保数据的保密性、完整性和可用性，微服务提供商必须提供最低限度的数据安全保障，包括通过加密保护共享存储环境中的所有数据，严格访问控制以防止未经授权访问数据，并定时备份数据等。

2.3 云原生架构下的微服务权限安全

微服务体系结构应该验证每个服务的真实性，因为如果单个服务由攻击者控制，该服务可能会恶意影响其他服务。此外，当服务接收到消息时，它需要确定消息的真实性和有效性。

2.4 云原生架构下的微服务网络安全

在网络安全领域，传统的典型威胁主要包括地址解析协议（ARP）欺骗、中间人攻击（MITM）、DoS攻击等。ARP欺骗涉及构建伪造目标物理地址的ARP回复，通过发送伪造的ARP回复，主机无法与目标主机正确通信。

2.5 云原生架构下的其他微服务安全风险

一般来说，保护单一服务比保护微服务相对容易。单一服务有明确的边界且通信是内部的。然而，在基于微服务的光纤陀螺系统中，任何功能的实现都可能需要通过部署的光纤陀螺网络在多个微服务之间进行通信。因此，这将暴露更多的数据和信息或系统端点，从而扩大了攻击面。没有网络保护，就无法实现安全的服务通信。

底层基础设施也起着至关重要的作用。新兴网络架构软件定义网络（SDN）等范例为云管理提供了灵活性和高效率等优势特性。然而，SDN还引入了以前不存在的、在传统网络中更难利用的新威胁，可能使网络更容易被渗透。SDN的主要威胁是网络应用程序的身份验证和授权。控制器模块必须进行一系列测试和验证，以确保其可靠并适合在生产环境中使用。然而，这对于保证第三方应用程序的可靠性和可信性来说是困难的。控制器模块是集中式的，因此，如果恶意应用程序接管控制器，结果可能会导致不同类型的攻击，严重影响整个微服务架构。因此，信任冲突是一种主要威胁，存在于控制器之间及应用程序之中。SDN网络的设计策略明确允许网络应用程序在网络中更改应用，但没有行使验证技术或语义，以评估这些应用程序的可信度。恶意应用程序可以滥用这些权限并危害网络运营。

除SDN安全问题外，大量微服务带来的网络复杂性大大增加了监控整个应用程序安全的难度；单一微服务的中止也可能会导致整个应用程序的崩溃。

3 云原生架构下的微服务安全风险评估模型

3.1 STRIDE威胁模型

微软公司的STRIDE是一种流行的威胁建模方法，如表1所示。类似的安全威胁建模模型还有DREAD框架。识别和分类威胁事件有助于评估其影响和应对措施。

3.2 Prasad Saripalli风险评估模型

虽然STRIDE是一个经过测试的较好的传统软件框架系统，但微服务安全风险评估模型Prasad Saripalli明确包括特定于云的安全性目标，更适合于云安全风险评估。美国《联邦信息安全管理法案》（Federal Information Security Management Act，FISMA）为信息系统定义了3个安全目标：保密性（Confidentiality），完整性（Integrity）和可用性（Availability）。Prasad Saripalli在基于云平台的信息安全系统基础之上，又增加了3个安全目标：多方信任（Multiparty Trust）、相互审计（Mutual Auditability）和可用性（Usability）。为每个威胁事件建立适当的安全目标需要先确定其潜在影响。Prasad Saripalli表示安全类别的通用格式信息类型为：

Ie=[(C,0),(I,6),(A,8),(M,1),(A,1),(U,8)]

潜在影响的可接受值分为4个等级：较低、中等、高或不适用。风险是以上安全威胁事件及其后果的严重性影响因素的概率或频率的组合。微服务安全风险类别根据等式进行评估。给定应用程序的总体平台安全风险（RS）将是累积的平均值，映射到安全目标类别的n个威胁的加权总和：

具体的计算过程如表2所示。

4 云原生架构下的微服务安全架构及安全防御措施

4.1 云原生架构下的微服务安全架构

基于上述风险评估架构，本文提出了相应的基于云原生架构的微服务安全整体框架。图4为国内学者总结的云原生架构下的微服务安全架构。在此基础上，可以追加后台日志系统与本文中提到的风险评估告警体系。

   

4.2 基于云原生架构的微服务安全防御措施

（1）物理措施

微服务安全防御机制首先需要对物理设备进行有效管理，包括服务器、路由器、防火墙、交换机等网络关键设备的定期检查、更新，并且需要安装不间断电源（UPS）。

（2）数据加密

在数据安全中，数据源的保护也非常重要。数据源的保护主要是针对操作员恶意篡改或者泄露主要数据。因此需要确定数据源是否可验证并且具有与其自身相关联的信誉度，以及如何防止篡改或者泄露。

首先，需要确保管理系统能够验证与操作有关的参与者（或服务）相关的数据源，并且能够使参与者（或服务）对其在数据中的行为负责。另外，数据源的复现是应急响应的关键流程，因此数据的热备份至关重要。

其次，创建用于数据流认证的公私钥加密系统。并且基于密码学对源数据进行加密处理（如RSA或DES算法），结合密钥对保证云端数据传输的可靠性与完整性。另外，备份数据的加密存储能够有效预防数据的篡改与外泄。

（3）访问控制

针对微服务方面的权限访问保障，请求访问资源只能被分配最低限度的必要权利。将权限授予超出必要的范围可能导致用户以不正当的方式获取或更改信息。因此，权限访问控制可以限制攻击者破坏系统。

轻型目录访问协议（LDAP）是SaaS应用程序中使用的一种非常流行的授权协议，如图5所示。LDAP服务存储相对静态的授权信息，适用于一次记录、多次读取的场景。为了提供一种基于TCP/IP的轻量级网络，降低管理维护成本，LDAP简化了目录访问协议（DAP）并且可以轻松添加、修改、查询和删除用户目录信息。

  

   

OAuth77也是一种流行的授权协议，以确保REST API能够进行正常的授权访问。通过OAuth，授权服务器向受信任的客户端应用程序发出访问令牌，然后客户端应用程序可以代表最终用户访问API。此外，OpenID Connect是OAuth之上的一个身份验证层，它还允许服务读取基本用户信息。

（4）网络隔离与容器隔离

网络隔离通常是通过隔离卡与安全隔离网闸实现的。而云端的容器隔离可以通过Linux系统中的SELinux（Security Enhanced Linux）策略模块实现。SELinux是Linux中广泛使用的安全模块，其对安全策略模块的支持效果十分显著。对保护容器安全的SELinux策略模块允许为不同容器的镜像指定SELinux域，从而提高容器的安全性。除此以外，Gao等人提出了一种基于功率的命名空间方法，用于检测多租户容器云服务上的信息泄露。信息泄露主要是由于Linux系统中的系统资源隔离机制没有完全实现，基于功率的命名空间方法能够记录和监视每个容器的功率使用情况。对于每个容器的功率使用统计信息，所提出的方法可以动态限制已超过其容量的容器计算能力定义的功率阈值，进而实现有效的资源隔离。

5 结语

尽管云原生架构下的微服务体系有许多优点，但仍存在许多实际和潜在的安全问题。微服务是一种相对较新的软件体系结构，因此其研究在工业和学术领域都仍然有限。本文从容器、数据、权限和网络4个方面描述了用于服务通信的微服务的安全问题和当前解决方案。未来，可以考虑实施一个集成解决方案来保护基于云原生的微服务体系，使其在安全级别、应用程序性能和用户体验之间实现恰当平衡。

（原载于《保密科学技术》杂志2022年7月刊）