深度解析 3GPP TS 33.514:4.2.7 & 4.2.8 安全策略下发 (UDM如何为特殊业务“授权”)

本文技术原理深度参考了3GPP TS 33.514 V18.3.0 (2024-06) Release 18规范中,关于“4.2.7 User plane security procedures”与“4.2.8 User plane security procedures (for 5G LAN service)”的核心章节(注意:规范中章节标题存在重复,我们按其内容进行区分)。本文将聚焦于UDM作为签约数据中心的核心职责之一:如何根据用户的签约,为TSC(时间敏感通信)和5G LAN等特殊业务,下发正确的用户面安全策略,从而在网络层面实现差异化的安全服务。

“保险库”的高级业务:签发“特殊通行证”

在前面的章节中,新人工程师小王和导师陈姐已经为“IdentiCore-UDM”构建了坚固的门禁系统(SUCI解密)和可靠的安保日志(认证状态存储)。现在,“保险库”的核心身份验证功能已经基本就绪。陈姐决定,是时候让小王接触更高级的业务了——数据管理与策略授权

“小王,我们的保险库不仅要能识别客户身份,还要能管理他们的‘账户等级’和‘特殊业务权限’,”陈姐说道,“想象一下,我们的客户中,有两位特殊的访客。一位是**‘急救先锋’医疗无人机,它传输的远程手术数据,要求绝对的端到端加密和完整性保护**,一刻都不能中断。另一位是**‘智慧工厂’的AGV车队,它们在厂区内组成一个局域网,要求组内所有成员之间的通信都采用统一的安全策略**。我们的UDM,作为签约数据的最终权威,必须能够为这两位特殊的访客,准确地签发他们的‘特殊安全通行证’。这就是我们今天要学习的——用户面安全策略的配置与下发。”

这个场景让小王意识到,UDM的安全职责,远不止于“认证”,更在于“授权”。它决定了不同用户的PDU会话,能享受到何种等级、何种模式的安全保护。

1. 为时间敏感通信(TSC)签发“强制加密”通行证 (4.2.7.1)

时间敏感通信(Time-Sensitive Communication, TSC)是5G URLLC场景的典型应用,如远程驾驶、远程手术、工业自动化控制等。这些业务对数据的可靠性和安全性要求达到了极致。

1.1 威胁:当最高优先级的业务“裸奔”

陈姐向小王描述了一个致命的威胁场景:“假设‘急救先锋’医疗无人机正在向医院实时回传一位事故现场伤员的生命体征和高清内窥镜影像,用于指导远程急救。SMF在为这条生命攸关的数据流建立PDU会话时,向UDM查询了它的安全策略。如果我们的UDM因为配置错误或软件缺陷,返回了一个‘用户面安全可选’的策略,会怎么样?”

小王立刻明白了:“SMF可能会据此指示UPF和gNB,不对此数据流强制启用加密和完整性保护。这等于让救命的数据在空中‘裸奔’!任何有能力的攻击者都可以窃听伤员的隐私,甚至篡改生命体征数据,比如把心率从120改成60,这将直接导致医生误判,造成医疗事故!”

1.2 规范原文

4.2.7.1 UP Security enforcement configuration for TSC service Requirement Name: UP security enforcement configuration Requirement Reference: TS 33.501, clause L.3, TS 23.501, clause 5.10.3. Requirement Description: … “The UP security enforcement information shall be set to “required” for data transferred from gNB to a 5GS TSC-enabled UE…” “The SMF determines at PDU session establishment a User Plane Security Enforcement information for the user plane of a PDU session based on:

  • subscribed User Plane Security Policy which is part of SM subscription information received from UDM; and
  • …” Threat References: TR 33.926.

Test Case: Test Name: TC_UP_SECURITY_ENFORCEMENT_CONFIGURATION Purpose: Verify that UP security enforcement information is set to “required” for dedicated TSC service.

1.3 深度解读与测试实践

需求解读 (The “What” and “Why”)

  • 核心要求:当一个用户(或设备,如TSC无人机)签约了TSC服务时,其签约数据中必须包含相应的用户面安全策略(User Plane Security Policy)。当SMF为该用户的TSC业务(通过特定的DNN/S-NSSAI识别)请求签约数据时,UDM必须返回一个明确指示**用户面安全保护为“必需”(required)**的策略。
  • 为何重要? 这个“必需”(required)的策略,是整个安全链条的“扳机”。SMF收到它之后,就会在其后续与AMF、gNB和UPF的交互中,强制要求为该PDU会话的数据无线承载(DRB)和N3隧道启用加密(机密性保护)和完整性保护。UDM是这个决策链的源头,它的准确性至关重要。

测试用例解读 (The “How to Verify”)

这是一个典型的“配置-查询-验证”测试。

  • 前提条件 (Pre-Conditions)
    1. 配置UDM:首先,必须在UDM/UDR的签约数据库中,为某个测试SUPI配置一条与TSC服务相关的签约数据。这条数据中要明确包含一个用户面安全策略,并将其设置为**“必需”(required)**。
    2. 定义TSC业务:需要定义一个专用的DNN/S-NSSAI组合,用来唯一标识这个TSC服务。
  • 执行步骤 (Execution Steps)
    1. 测试工具模拟SMF,向UDM的Nudm_SDM_Get(签约数据管理-获取)服务接口发送一个请求。
    2. 这个请求必须包含那个预先配置好的测试SUPI,以及用于标识TSC业务的DNN/S-NSSAI。
    3. 捕获UDM返回的Nudm_SDM_Get Response消息。
  • 预期结果 (Expected Results)
    • 在UDM返回的响应消息中,必须包含smSubscriptionData(会话管理签约数据)。
    • 在该数据结构中,必须能找到userPlaneSecurityPolicy字段。
    • 该字段的值必须明确为**“必需”(required)**。
    • 任何其他结果(如未返回该字段、或返回的值是“可选”或“不需要”)都意味着测试失败。

2. 为5G LAN签发“统一安全”通行证 (4.2.8.1)

5G LAN/Virtual Network (VN) Group 是一项允许一组UE(如工厂里的AGV车队、一个办公室的员工)形成一个二层局域网,彼此之间可以直接通信的功能。为了保证这个“虚拟局域网”的内部安全,所有成员都应该遵循统一的安全策略。

2.1 威胁:当“内网”成员的安全等级参差不齐

陈姐提出了第二个威胁场景:“‘智慧工厂’的AGV车队,被划入同一个5G LAN组。其中,负责运输精密仪器的AGV-01,签约了最高等级的用户面加密。而负责运输普通物料的AGV-02,签约的只是普通策略。当SMF分别为它们建立PDU会话时,如果UDM根据它们各自的签约,下发了两种不同的安全策略,会发生什么?”

小王思考后回答:“这会造成5G LAN组内部安全策略的不一致。AGV-01发出的数据是加密的,但AGV-02发出的可能是明文的。这不仅会造成管理上的混乱,更会形成安全短板。攻击者可以轻易地攻击安全等级最低的AGV-02,并以此为跳板,在‘内网’中进行嗅探和攻击,整个车队的安全防护将形同虚设。”

2.2 规范原文

4.2.8.1 UP security policy configuration for 5G LAN service Requirement Name: UP security enforcement configuration Requirement Description: “To reduce incremental complexity added by security, all PDU sessions associated with a specific 5G LAN group should have the same UP security policy…”

Test Case: Test Name: TC_UP_SECURITY_ENFORCEMENT_CONFIGURATION_FOR_5G_LAN Purpose: Verify that UP security policy is set to the same for all the 5G LAN UEs.

2.3 深度解读与测试实践

需求解读 (The “What” and “Why”)

  • 核心要求:为了降低复杂性和保证一致性,属于同一个5G LAN组的所有UE,其用户面安全策略必须是相同的。UDM作为签约数据的提供方,有责任保证这一点。
  • 为何重要? 这确保了一个虚拟局域网内部有一个统一的安全基线。通常,这个统一的策略会遵循该组中安全要求最高的那个成员的策略(“木桶理论”的长板原则),确保整个组的安全性取决于其最强的成员,而不是最弱的。

测试用例解读 (The “How to Verify”)

这个测试用例通过对组内不同成员的两次查询来验证策略的一致性。

  • 前提条件 (Pre-Conditions)
    1. 配置UDM:在UDM/UDR中,创建两个不同的测试SUPI(SUPI1, SUPI2)。将这两个SUPI都配置为属于同一个5G LAN组,并为该组的5G LAN服务(由一个专用的DNN/S-NSSAI标识)配置一个统一的用户面安全策略。
  • 执行步骤 (Execution Steps)
    1. 第一次查询:模拟SMF,为SUPI1和指定的5G LAN业务(DNN/S-NSSAI)向UDM发起一次Nudm_SDM_Get请求。记录下UDM返回的用户面安全策略,我们称之为policy1
    2. 第二次查询:模拟SMF(可以是同一个或另一个SMF实例),为SUPI2和同一个5G LAN业务(DNN/S-NSSAI)向UDM发起第二次Nudm_SDM_Get请求。记录下UDM返回的用户面安全策略,我们称之为policy2
  • 预期结果 (Expected Results)
    • policy1policy2必须完全相同
    • 测试的证据就是包含这两次API交互流程的.pcap文件,通过对比两次响应消息中的userPlaneSecurityPolicy字段,可以直观地证明其一致性。

总结:UDM,从“认证者”到“授权者”的角色升华

通过今天对4.2.7和4.2.8节的学习,小王对UDM的理解进入了一个全新的层次。他认识到,UDM不仅仅是一个被动地核验身份的“门卫”,更是一个主动地、基于签约数据进行精细化授权的“策略决策点”(PDP - Policy Decision Point)。

  • 对于TSC业务,UDM通过下发**“必需”策略,扮演了最高安全等级的守护者**,确保了关键业务的数据安全万无一失。
  • 对于5G LAN业务,UDM通过下发**“统一”策略,扮演了内部安全秩序的维护者**,确保了虚拟组网络的安全一致性。

UDM的这两个看似简单的策略下发功能,实际上是5G网络能够提供差异化、可定制化安全服务(Security as a Service)的基石。它将安全从一种“一刀切”的普适性配置,转变为一种可以按需分配、与业务紧密耦合的动态能力。而TS 33.514通过这两个测试用例,确保了UDM在扮演这个高级角色时,是准确、可靠且符合预期的。


FAQ 环节

Q1:用户面安全策略(User Plane Security Policy)中,除了“必需”(required),还有哪些其他的值? A1:根据TS 23.501的定义,用户面安全策略主要有三个值:“必需”(Required),意味着必须对用户面数据进行机密性和完整性保护;“可选”(Optional),意味着由网络(通常是SMF根据本地策略)来决定是否启用保护;以及“不需要”(Not Needed),意味着明确指示不应启用用户面保护。UDM根据用户的签约和业务类型,来决定返回哪一种策略。

Q2:SMF在决定最终的用户面安全策略时,只听UDM的吗? A2:不完全是。规范(TS 23.501)中明确指出,SMF决定最终策略时,会基于两个输入:1) 从UDM收到的签约策略(这是主要依据);2) SMF本地配置的策略。通常,当UDM没有提供策略时,SMF会使用本地策略作为默认值。在某些情况下,SMF的本地策略也可能比UDM的策略更严格。但对于TSC这类关键业务,UDM下发的“必需”策略具有最高的权威性。

Q3:测试用例中提到了DNN和S-NSSAI,它们是什么?为什么需要用它们来识别业务? A3:DNN(Data Network Name)标识了用户希望访问的数据网络,比如“internet”、“ims”、“enterprise.corp”等。S-NSSAI(Single Network Slice Selection Assistance Information)是网络切片的唯一标识符。通过DNN和S-NSSAI的组合,网络可以非常精确地识别出用户当前请求的是哪一种具体的业务。例如,“DNN=robot_control, S-NSSAI=URLLC_slice_1”就可以唯一地标识一个工业控制类的TSC业务。UDM正是依据这个组合,来从庞大的签约数据中,找到并返回与该特定业务相关的策略。

Q4:为5G LAN组配置统一的安全策略,是在UDM中手动为每个成员都配一遍吗? A4:在实际的运营商系统中,通常不会这么低效。UDM/UDR的签约数据模型会支持“组”的概念。管理员只需要创建一个“5G LAN Group Profile”,为这个Profile配置好统一的安全策略。然后,在为每个用户(SUPI)配置签约数据时,只需要将他们关联到这个Group Profile即可。这样,当SMF查询任何一个组成员的策略时,UDM都能从其关联的Group Profile中,获取并返回那个统一的策略,大大简化了配置和管理。

Q5:这些用户面安全策略,最终是如何在UPF和gNB上生效的? A5:这是一个完整的信令链条:1) UDM将策略告知SMF。2) SMF在PDU会话建立过程中,将这个安全要求(需要加密/完整性保护)传递给AMF。3) AMF再将该要求配置给gNB。4) gNB在为UE建立数据无线承载(DRB)时,就会在RRC信令中明确指示UE必须启用加密(UP Ciphering)和完整性保护(UP Integrity Protection)。同时,SMF也会通过N4接口,确保与UPF之间的N3隧道也相应地启用了IPsec保护。这样,就实现了从UE到UPF的端到端用户面安全。