2. SBA核心网元与接口安全：NRF、AMF、SMF、UPF、AUSF、UDM等网元功能与安全职责，N1-N15接口安全特性
2.1 从传统到SBA：架构变了，安全思路也得变
说实话，我刚接触5G核心网时，第一反应是「这不就是把网元拆得更碎了吗？」。但干了一段时间才发现，事情没那么简单。
传统4G的EPC里，MME、SGW、PGW都是紧耦合的。你攻破一个MME，基本就能控制一大片区域。但5G的SBA架构不一样——每个网元都是独立的服务，通过HTTP/2接口互相调用。这就像把一个 monolithic 的城堡拆成了几十个独立的小房子，每个房子都有自己的门锁和保安。
好处很明显：灵活、可扩展、便于部署。但坏处呢？攻击面变大了。以前你只需要守住几个大门，现在每个小房子的窗户、烟囱、甚至狗洞都得盯着。
我个人习惯把SBA的安全分为三层：网元自身安全、服务间通信安全、接口协议安全。咱们一个一个聊。
2.2 核心网元功能与安全职责
先看一张我画的SBA核心网元关系图，方便你理解它们之间的调用关系：
嗯，这张图基本把SBA的核心网元串起来了。下面我逐个说说每个网元的安全职责。
2.3 NRF：核心网的「黄页」与「门卫」
NRF（Network Repository Function）是SBA架构的基石。说白了，它就是核心网的服务注册中心。每个网元上线时都要向NRF注册自己的服务能力，其他网元要调用服务时，先问NRF「谁提供这个服务？」。
安全职责方面，NRF承担了三个关键角色：
- 服务授权：不是谁都能注册服务的。NRF要验证请求方的身份，确保只有合法的NF才能注册或发现服务。
- 访问控制：NRF可以配置策略，限制某些NF只能发现特定的服务。比如，外部的第三方应用不能随便发现核心网内部的服务。
- 心跳监控：NRF会定期检查已注册NF的健康状态。如果一个NF失联了，NRF会把它标记为不可用。
重点：NRF是SBA安全的第一道防线。如果NRF被攻破，攻击者可以注册恶意服务、劫持服务发现、甚至让核心网瘫痪。我在项目中遇到过一起案例，攻击者通过伪造NRF响应，把流量引到了恶意SMF上，导致用户会话被劫持。
2.4 AMF：接入层的「守门员」
AMF（Access and Mobility Management Function）是UE接入核心网的第一站。所有NAS信令都要经过AMF。它的安全职责很重：
- 接入认证：AMF负责触发AUSF进行UE认证，确保只有合法用户才能接入网络。
- NAS安全：AMF与UE之间的NAS消息需要加密和完整性保护。AMF负责协商安全算法和密钥。
- 移动性管理：AMF跟踪UE的位置，处理切换、注册更新等流程。这些信令如果被篡改，可能导致UE被跟踪或服务中断。
我建议重点关注AMF的NAS安全处理。你想想看，如果AMF的NAS加密密钥被泄露，攻击者就能解密所有NAS消息，包括用户的身份信息、位置信息、甚至业务请求。这可不是闹着玩的。
2.5 SMF：会话管理的「大脑」
SMF（Session Management Function）负责PDU会话的建立、修改和释放。它控制着UPF如何转发用户数据。安全方面：
- 策略执行：SMF从PCF获取策略，然后下发给UPF执行。如果SMF被篡改，攻击者可以绕过计费策略或QoS限制。
- UPF选择：SMF根据用户位置、业务类型等因素选择合适的UPF。如果SMF被恶意控制，可能把用户流量导向恶意的UPF。
- N4接口安全：SMF与UPF之间的N4接口使用PFCP协议。PFCP消息需要完整性保护，防止会话被劫持。
避坑指南：我曾经在测试中发现，有些厂商的SMF实现没有对N4接口的PFCP消息做严格的序列号校验。攻击者可以重放旧的PFCP消息，导致UPF执行错误的转发规则。嗯，这个坑我踩过，后来我们在安全规范里明确要求了序列号校验机制。
2.6 UPF：用户面的「高速公路」
UPF（User Plane Function）是唯一处理用户数据的网元。所有用户流量都经过UPF转发。它的安全职责更偏向数据面：
- 数据转发安全：UPF需要确保用户数据不被窃听或篡改。对于敏感业务，UPF可以触发端到端加密。
- 策略执行：UPF根据SMF下发的规则进行包检测、QoS控制、计费信息收集等。如果UPF被攻破，攻击者可以绕过所有策略。
- N3/N9接口安全：UPF与gNB之间的N3接口、UPF之间的N9接口使用GTP-U协议。GTP-U隧道需要加密和完整性保护。
说实话，UPF的安全往往被忽视。很多人觉得UPF只是「傻傻地转发数据」，没什么好保护的。但你想过没有？如果UPF被植入恶意代码，攻击者可以复制所有经过的用户数据——包括明文传输的密码、银行卡号等。我在运营商项目中见过一次，攻击者通过UPF的漏洞获取了GTP-U隧道的密钥，然后对用户数据进行了中间人攻击。
2.7 AUSF与UDM：认证与数据的「保险柜」
AUSF（Authentication Server Function）和UDM（Unified Data Management）是核心网中最敏感的两个网元。一个管认证，一个管数据。
AUSF的安全职责：
- 执行5G-AKA或EAP-AKA'认证流程
- 生成和分发认证向量
- 管理密钥层次结构（Kausf、Kseaf等）
UDM的安全职责：
- 存储用户签约数据（SUPI、签约服务、QoS配置等）
- 生成认证向量（与AUSF协作）
- 管理用户位置和状态信息
警告：UDM存储了所有用户的SUPI（永久身份标识）。如果UDM被攻破，攻击者可以获取所有用户的真实身份，这比4G时代的IMSI泄露更严重。因为5G中SUPI是永久性的，不像4G的IMSI可以通过TMSI临时隐藏。我建议对UDM实施严格的访问控制，所有对UDM的访问都必须经过NRF授权，并且使用TLS双向认证。
2.8 N1-N15接口安全特性
SBA架构中，接口安全是重中之重。每个接口都有不同的安全需求。我整理了一个表格，方便你对照：
| 接口 | 连接双方 | 协议 | 安全要求 | 常见攻击 |
|---|---|---|---|---|
| N1 | UE ↔ AMF | NAS (5GMM/5GSM) | 加密+完整性保护 | NAS重放、身份窃取 |
| N2 | gNB ↔ AMF | NGAP (SCTP) | IPSec/TLS + 完整性 | 信令注入、DoS |
| N3 | gNB ↔ UPF | GTP-U (UDP) | IPSec + 加密 | GTP隧道劫持、数据窃听 |
| N4 | SMF ↔ UPF | PFCP (UDP) | 完整性保护 + 序列号 | PFCP重放、会话劫持 |
| N5 | PCF ↔ AF | HTTP/2 (TLS) | TLS双向认证 | API滥用、策略篡改 |
| N6 | UPF ↔ DN | IP/GRE/VxLAN | 取决于DN安全策略 | 数据泄露、DDoS |
| N7 | SMF ↔ PCF | HTTP/2 (TLS) | TLS + OAuth 2.0 | 策略注入、权限提升 |
| N8 | AMF ↔ UDM | HTTP/2 (TLS) | TLS双向认证 + 授权 | 用户数据泄露 |
| N10 | SMF ↔ UDM | HTTP/2 (TLS) | TLS双向认证 + 授权 | 签约数据篡改 |
| N11 | AMF ↔ SMF | HTTP/2 (TLS) | TLS + OAuth 2.0 | 会话劫持、信令注入 |
| N12 | AMF ↔ AUSF | HTTP/2 (TLS) | TLS双向认证 | 认证绕过 |
| N13 | AUSF ↔ UDM | HTTP/2 (TLS) | TLS双向认证 + 授权 | 认证向量泄露 |
| N14 | AMF ↔ AMF | HTTP/2 (TLS) | TLS + 完整性 | 移动性信令篡改 |
| N15 | AMF ↔ PCF | HTTP/2 (TLS) | TLS + OAuth 2.0 | 策略注入、权限提升 |
从表格可以看出，SBA接口的安全核心是TLS双向认证和OAuth 2.0授权。TLS保证通信的机密性和完整性，OAuth 2.0保证只有授权的NF才能调用特定服务。
我个人习惯把接口安全分为两类：
- 传统参考点接口（N1-N6）：这些接口沿用4G的协议（NAS、NGAP、GTP-U、PFCP），安全机制相对成熟，但要注意协议实现的漏洞。
- 服务化接口（N7-N15）：这些接口基于HTTP/2，安全机制更灵活，但也引入了新的攻击面——比如API滥用、JWT伪造、OAuth令牌泄露等。
核心观点：服务化接口的安全是SBA架构中最容易被忽视的环节。很多厂商在部署时只配置了TLS，但没有启用OAuth 2.0授权。这意味着只要TLS连接建立成功，任何NF都可以调用其他NF的服务。这相当于把核心网的大门敞开了。我建议在部署SBA时，必须启用NRF的OAuth 2.0授权服务，并且为每个NF颁发独立的客户端凭证。
2.9 实战中的安全配置示例
说了这么多理论，咱们来点实际的。下面是一个NRF的OAuth 2.0配置示例（简化版）：
# NRF OAuth 2.0 配置示例
nrf:
oauth2:
enabled: true
token_endpoint: https://nrf.example.com/oauth2/token
authorization_endpoint: https://nrf.example.com/oauth2/authorize
clients:
- client_id: "amf-001"
client_secret: "amf-secret-key-2024"
scopes: ["nnrf-nfm", "nausf-auth", "nudm-sdm"]
grant_types: ["client_credentials"]
- client_id: "smf-001"
client_secret: "smf-secret-key-2024"
scopes: ["nnrf-nfm", "nudm-sdm", "npcf-smpolicy"]
grant_types: ["client_credentials"]
token_lifetime: 3600 # 令牌有效期1小时
refresh_token_lifetime: 86400 # 刷新令牌有效期24小时这个配置里，每个NF都有独立的client_id和client_secret，并且只能访问被授权的服务范围。比如AMF只能访问NRF、AUSF和UDM的服务，不能直接调用PCF的策略服务。
小技巧：我在项目中习惯把client_secret存储在硬件安全模块（HSM）中，而不是明文写在配置文件里。这样即使配置文件泄露，攻击者也拿不到密钥。另外，令牌有效期不要设太长，1小时是比较合理的值。太短了影响性能，太长了增加泄露风险。
2.10 本章小结
嗯，这一章内容不少。咱们从头捋一遍：
- SBA架构把核心网拆成了多个独立的服务，每个服务都有自己的安全职责
- NRF是核心网的安全中枢，负责服务注册、发现和授权
- AMF、SMF、UPF、AUSF、UDM各有各的安全职责，但都离不开认证、授权和加密这三个基本要素
- N1-N15接口的安全核心是TLS双向认证和OAuth 2.0授权
- 服务化接口的安全是SBA架构的新挑战，需要特别关注
说实话，SBA的安全比传统EPC复杂得多。但换个角度想，这也给了我们更多的控制手段。只要配置得当，SBA可以比EPC更安全。关键是要理解每个网元和接口的安全职责，然后针对性地部署防护措施。
下一章咱们聊聊NRF的安全攻防实战，包括服务注册劫持、令牌伪造、服务发现欺骗等攻击手法和防御方案。到时候我会分享一些我在实际项目中遇到的案例，保证让你大开眼界。
公众号:蓝海资料掘金营，微信deep3321