51学通信

深度解析 3GPP TS 33.501：14-15 安全相关服务与网络切片管理安全

21分钟阅读

好的，我们继续深入解读3GPP TS 33.501规范。

深度解析 3GPP TS 33.501：14-15 安全相关服务与网络切片管理安全

本文技术原理深度参考了3GPP TS 33.501 V18.9.0 (2025-03) Release 18规范中，关于“14 Security related services”和“15 Management security for network slices”的核心章节，旨在为读者系统性地梳理5G核心网中各个“安全专家”（如AUSF, UDM）所提供的标准API服务，并深入探讨网络切片这一5G革命性功能的管理平面安全。

在前面的系列文章中，我们已经深入探讨了5G安全的“how”——即各种具体的安全流程是如何执行的。今天，我们将把视角提升一个维度，来审视这些流程背后的“what”和“who”——这些安全服务具体是什么，以及由谁来提供。同时，我们将首次接触一个全新的领域：网络切片的管理安全。

本篇文章将深入解读规范的第14章和第15章，这两章共同描绘了5G安全的服务化抽象和管理层面的安全保障：

  • 第14章 安全相关服务：这一章像一本“API参考手册”，它将我们在第六章学习的复杂认证流程，抽象为一个个标准化的、由AUSF、UDM、NRF等NF提供的API服务。理解这一章，是理解5G核心网SBA（服务化架构）本质的关键。
  • 第15章 网络切片管理安全：我们之前讨论的切片安全（NSSAA），是保障用户“使用”切片的安全。而本章关注的是更上游的——**“创建”和“管理”**网络切片这个动作本身的安全。

为了让这些高度抽象的服务和管理概念变得具体，我们将引入一个全新的、更宏大的场景。运营商的“李工”今天不再是简单的网络监控者，他将扮演两个新角色：首先，作为NF服务开发者，他需要调用标准的认证服务来构建一个新的安全应用；然后，作为网络规划工程师，他将为即将到来的大型体育赛事，创建一个专用的“超高清直播”网络切片。他的这两项工作，将完美地诠释14章和15章的核心内容。

1. 第14章 安全相关服务 - 5G安全的“API市场”

第14章将前面章节中描述的、嵌入在各种流程中的安全功能，进行了“服务化”的封装和定义。它告诉我们，每一个安全相关的核心功能，都是一个可以被其他NF调用的、具有明确输入输出的API服务。

1.1 AUSF提供的服务 (14.1) - “认证专家”的API

AUSF是主认证的“最高法官”，它提供的API服务都围绕着“认证”这一核心职责。

14.1.2 Nausf_UEAuthentication service Service operation name: Nausf_UEAuthentication_Authenticate Description: Authenticate the UE and provides related keying material. Input, Required: One of the options below.

  1. In the initial authentication request: SUPI or SUCI, serving network name.
  2. In the subsequent authentication requests…: Authentication confirmation message with RES*…

Nausf_UEAuthentication_Authenticate 服务 这是AUSF最核心的API。当AMF/SEAF需要认证一个UE时，它调用的就是这个服务。

  • 功能：执行主认证（5G AKA或EAP-AKA’）。
  • 输入：
    • 初始认证时：SUCI和serving network name。
    • 后续步骤中：UE的响应值RES*。
  • 输出：
    • 认证挑战（EAP-Request/AKA'-Challenge或5G SE AV）。
    • 最终认证结果（成功/失败）和锚点密钥K_SEAF。

14.1.3 Nausf_SoRProtection service 14.1.4 Nausf_UPUProtection service Description: The AUSF calculates the SoR-MAC-IAUSF / UPU-MAC-IAUSF… using UE specific home key (KAUSF)…

Nausf_SoRProtection / Nausf_UPUProtection 服务 这两个服务是我们之前讲过的“漫游引导”和“参数更新”安全机制的核心。当UDM需要下发SoR或UPU数据时，它会调用这两个服务。

  • 功能：使用K_AUSF为SoR/UPU数据计算MAC值，提供端到端完整性保护。
  • 输入：SUPI、需要保护的数据、SoR/UPU Counter等。
  • 输出：计算出的MAC值。

1.2 UDM提供的服务 (14.2) - “档案与凭证中心”的API

UDM是用户数据的“终极源头”，它提供的安全服务围绕着“获取认证凭证”和“确认认证结果”。

14.2.2 Nudm_UEAuthentication_Get service operation Description: Requester NF gets the authentication data from UDM. Inputs, Required: SUPI or SUCI, serving network name. Outputs, Required: Authentication method. Outputs, Optional: … AKA authentication vector…

Nudm_UEAuthentication_Get 服务 这是认证流程中，AUSF向UDM请求“考卷”时调用的API。

  • 功能：为指定用户获取认证方法和认证向量。
  • 输入：SUCI（AUSF无法解密，直接透传）和serving network name。
  • 输出：UDM决策出的认证方法，以及为该方法生成的认证向量（如5G HE AV）。

14.2.3 Nudm_UEAuthentication_ResultConfirmation service operation Description: Requester NF informs UDM about the result of an authentication procedure with a UE.

Nudm_UEAuthentication_ResultConfirmation 服务 这是实现“增强的归属地控制”的关键API。

  • 功能：AUSF向UDM“备案”一次认证的结果。
  • 输入：SUPI、认证结果（成功/失败）、时间戳、服务网络名等。
  • 输出：无（仅为一次通知）。

1.3 NRF提供的服务 (14.3) & NSSAAF提供的服务 (14.4)

  • NRF：提供Nnrf_AccessToken_Get服务，即标准的OAuth 2.0令牌获取服务，为SBA的授权框架提供支持。
  • NSSAAF：提供Nnssaaf_NSSAA_Authenticate等服务，作为AMF与外部AAA服务器之间的“代理”，中继切片特定认证的EAP消息。

场景代入： 李工正在开发一个内部的安全审计应用（一个特殊的NF）。这个应用需要定期检查某个高价值物联网设备的认证状态。

  1. 李工的应用无需自己实现复杂的认证逻辑。
  2. 它只需要作为一个标准的NF Consumer，向NRF申请一个访问UDM服务的Access Token。
  3. 然后，它可以定期调用Nudm_UEAuthentication_Get服务（虽然通常是AUSF调用，但这里作为例子），来模拟一次认证请求的发起，并分析UDM返回的策略。
  4. 更重要的是，它可以订阅UDM的事件通知，当Nudm_UEAuthentication_ResultConfirmation被调用时，UDM可以主动将认证结果推送给李工的应用，实现实时的安全监控。

第14章的意义在于，它将5G安全从一系列固化的、嵌入式的流程，解放为一套模块化、可组合、可调用的API服务。这为未来引入新的安全功能、实现更智能的安全运维和编排，提供了无限的可能性。

2. 第15章 网络切片管理安全 - “创造世界”本身的安全

我们之前在16章（将在后续解读）会详细讨论用户如何使用网络切片。而第15章，关注的是一个更上游、更宏观的问题：当运营商自己需要创建、修改或删除一个网络切片实例（NSI）时，这个“创世”级别的管理操作，其本身的安全如何保障？

The creation, modification, and termination of a Network Slice Instance (NSI) is part of the Management Services provided by the 5G management systems. A management service is accessed by management service consumers via standardized service interfaces given in 3GPP TS 28.533. … These management services are securely protected through mutual authentication and authorization below.

核心场景： 网络切片的管理者（Management Service Consumer），可能是运营商内部的网络规划部门，也可能是购买了切片服务的垂直行业客户（如“飞驰物流”的IT部门）。他们通过管理接口，向运营商的5G管理系统（Management Service Producer，如NFVO/NSMF）下发指令，如“请为我创建一个覆盖全市、保证1ms时延、1Gbps带宽的URLLC切片”。

这个管理接口的安全至关重要，一旦被非法利用，攻击者就可以随意创建、删除网络资源，造成灾难性后果。

2.1 管理接口的“外交三部曲”

与第12章的NEF安全模型非常相似，第15章也为网络切片的管理接口定义了严格的“外交三部曲”。

15.2 Mutual authentication If a management service consumer resides outside the 3GPP operator’s trust domain, mutual authentication shall be performed between the management service consumer and the management service producer using TLS.

  1. 双向认证：管理方（如“飞驰物流”的IT系统）与运营商的管理系统之间，必须通过**基于证书或预共享密钥的双向认证TLS（mTLS）**来建立连接，确认彼此的合法身份。

15.3 Protection of management interactions… TLS shall be used to provide mutual authentication, integrity protection, replay protection and confidentiality protection for the interface…

  1. 接口保护：建立的TLS隧道，必须为后续所有的管理指令提供强制性的机密性、完整性和抗重放保护。

15.4 Authorization of management service consumer’s request After the mutual authentication, the management service producer determines whether the management service consumer is authorized to send requests… using the one of the following two options: 1) OAuth-based authorization mechanism…; 2) based on the local policy…

  1. 请求授权：对于每一条管理指令（如“创建切片”），运营商的管理系统都必须进行授权检查。授权方式可以是：
    • OAuth 2.0：与SBA和NEF类似，使用标准的令牌机制进行授权。
    • 本地策略：对于内部管理系统，也可以基于更简单的本地访问控制列表（ACL）等策略进行授权。

场景代入： 李工接到了为大型体育赛事创建“超高清直播”切片的需求。

  1. 他登录到运营商的网络编排器（Management Service Consumer）。
  2. 编排器与网络管理功能（Management Service Producer）之间，通过mTLS建立了一条安全的HTTPS连接。
  3. 李工在编排器界面上设计了切片的拓扑、资源需求（带宽、时延等）和覆盖范围。
  4. 他点击“部署”按钮。编排器生成了一个创建切片实例（NSI）的API请求。在这个请求中，包含了李工的身份凭证生成的OAuth 2.0 Token。
  5. 网络管理功能收到了这个API请求。它首先验证Token，确认这个请求确实来自有权限的“网络规划”角色。
  6. 授权通过后，管理功能才开始在底层的云基础设施和网络设备上，自动化地创建和配置这个全新的网络切片。

3. 总结

本章我们深入解读了第14和15章，从“服务化”和“管理化”两个新的维度，审视了5G安全体系。

  • 安全即服务 (Security-as-a-Service) (14)：第14章将复杂的安全流程，成功地抽象和封装为一系列标准化的SBA服务。这使得安全能力不再是孤立的、嵌入式的代码，而是成为了核心网中可以被灵活调用、组合和编排的“微服务”。这不仅大大提升了系统的模块化和可维护性，更为未来的网络智能化、自动化安全运维奠定了基础。
  • 管理平面的安全基石 (15)：第15章将我们的视野从通信平面（C-Plane/U-Plane）提升到了管理平面（M-Plane）。它通过强制性的TLS双向认证和OAuth 2.0授权，为网络切片这一5G最核心的商业使能技术的“创生”过程，提供了与通信平面同等级别的、强大的安全保障。

这两章的内容，虽然不如主认证流程那样广为人知，但它们深刻地体现了5G作为一张“平台化”网络的设计哲学。安全，不仅要在每一次通话、每一次上网中得到保障，更要深度融入到网络的每一次“服务调用”和每一次“自我演进”（切片管理）的脉络之中。

FAQ

Q1：第14章定义了这么多安全服务，它们和第6章描述的安全流程是什么关系？ A1：是**“功能实现”与“服务封装”**的关系。

  • 第6章描述的是一个端到端的、完整的业务流程，它像一个“剧本”，详细说明了UE、AMF、AUSF、UDM等多个“演员”之间需要如何按时间顺序对话和互动，来共同完成“认证”这场大戏。
  • 第14章则是从每个“演员”的视角出发，将他们在剧本中的“台词”和“动作”，封装成一个个独立的API服务。例如，AMF在剧本中需要向AUSF请求认证，这个动作就被封装为Nausf_UEAuthentication_Authenticate服务。 这种服务化的封装，使得“剧本”的编排（即业务流程的实现）与“演员”的具体能力（NF的功能）实现了解耦，极大地提升了系统的灵活性。

Q2：为什么AUSF需要提供独立的SoR/UPU保护服务？UDM自己不能处理吗？ A2：这是密钥管理和职责分离原则的体现。SoR和UPU的安全保护，依赖于一个核心密钥——K_AUSF。根据5G的密钥体系，K_AUSF是由AUSF生成并安全保管的，它并不在UDM中存储。UDM只存储用户的长期密钥K和签约档案。因此，当UDM需要下发SoR/UPU数据时，它必须将数据和相关参数“委托”给唯一持有“加密工具”(K_AUSF)的AUSF来执行“签名/加密”操作。这种设计确保了密钥的最小化暴露，UDM负责数据管理，AUSF负责基于密钥的安全服务，职责非常清晰。

Q3：网络切片管理安全（第15章）和网络切片使用安全（第16章的NSSAA）有什么根本区别？ A3：它们的保护对象和作用层面完全不同。

  • 切片管理安全（第15章）：保护的是运营商或企业管理员对网络切片实例（NSI）本身进行创建、修改、删除等生命周期管理的操作。这是一个**管理平面（M-Plane）**的安全问题，确保的是网络资源本身不被非法操控。
  • 切片使用安全（第16章 NSSAA）：保护的是终端用户（UE）在尝试接入和使用一个已经存在的网络切片时的权限。这是一个**控制平面（C-Plane）**的安全问题，确保的是只有授权用户才能使用切片提供的网络服务。 简单比喻：第15章是确保只有“授权的建筑师”才能“修改大楼蓝图”，而第16章是确保只有“持有VIP卡的会员”才能“进入大楼的VIP楼层”。

Q4：为什么网络切片管理接口也要使用和SBA/NEF类似的TLS和OAuth 2.0技术？ A4：这是3GPP在5G时代全面拥抱云原生和IT化技术理念的体现。通过在不同的对外接口（对第三方应用的NEF、对切片管理者的M-Plane）和内部接口（SBI）上，采用一套统一的、基于现代Web技术（TLS, HTTPS, REST, JSON, OAuth 2.0）的安全框架，可以带来诸多好处：

  • 技术统一：降低了开发和运维的复杂性。
  • 生态成熟：可以充分利用IT领域成熟的开源工具、安全库和开发人才。
  • 易于集成：使得运营商的管理系统能更容易地与企业的IT运维系统（如OSS/BSS）进行API级别的集成。

Q5：第14章将安全能力“服务化”后，是否意味着未来运营商可以向第三方开放某些“安全API”？ A5：这是一个非常有前瞻性的问题。理论上是完全可能的。例如，运营商可以通过NEF，将一些经过抽象和脱敏的安全能力开放出来。比如，一个金融App可以调用一个“SIM卡认证强度查询”API，来确认当前用户是否正在使用一个安全的、不可克隆的eSIM在进行交易，从而动态调整其交易风险等级。第14章的服务化定义，正是实现这种“安全能力即服务（Security-as-a-Service）”商业模式的技术基础。

关系图谱