5G核心网安全认证实战：AMF/SMF认证与安全架构落地路径

引言：5G核心网安全的关键，不在"单点防护"，而在"认证链条闭环"

在5G核心网中，AMF（接入与移动性管理功能）和SMF（会话管理功能）是用户接入和会话管理的核心网元。它们的认证安全直接决定了用户面和控制面的可信边界。很多企业在5G专网建设中以为"运营商的5G AKA认证就够了"，但现实是：

5G AKA 解决的是**“UE与网络之间的身份互认”，不解决"运维人员与网元之间的访问认证"**；

核心网运维的认证缺口，恰恰是专网项目验收和安全审计中失分最集中的环节。

ASP（统一身份认证服务平台）正是为补上这一"人-网元认证缺口"而设计。它不替代3GPP的AKA协议，而是作为企业侧的认证中枢，让AMF/SMF等核心网元的运维操作、API调用、证书管理进入统一的受控状态。

本文将基于5G核心网的真实安全架构，详解"AMF/SMF认证 + 运维访问控制"如何落地。

一、明确分工：5G AKA管什么，ASP管什么

首先厘清5G核心网两类认证的边界：

✅ 关键认知：ASP 是"运维认证中枢"，不是"接入鉴权替代品"。它的价值在于——一旦AMF/SMF的运维入口接入ASP，即刻进入"双因素认证、最小权限、操作审计"的统一状态。

二、5G核心网安全架构

2.1 服务化架构的认证边界

5G核心网采用SBA（服务化架构），AMF/SMF通过SBI接口（基于HTTP/2）交互。完整的安全架构分为三个层次：

┌─────────────────────────────────────────────────────┐
│ 第1层：UE接入认证（3GPP 5G AKA） │
│ UE ──→ AMF: AUSF鉴权，NAS加密（NEA2/NEA3） │
└────────────────────┬────────────────────────────────┘
│ 用户面
┌────────────────────┴────────────────────────────────┐
│ 第2层：网元间通信（SBI接口安全） │
│ AMF ↔ SMF: mTLS双向证书认证（CAS-KMS签发） │
│ HTTP/2 + TLS 1.3，网元证书链验证 │
└────────────────────┬────────────────────────────────┘
│ 控制面
┌────────────────────┴────────────────────────────────┐
│ 第3层：运维访问认证（ASP统一认证） │
│ 运维人员 ──→ AMF/SMF网管: UKEY+密码双因素 │
│ API调用 ──→ OAuth 2.0令牌，最小权限角色 │
└─────────────────────────────────────────────────────┘

2.2 AMF/SMF网管的运维认证

AMF和SMF的网管系统（OAM）是运维人员与核心网交互的入口。ASP平台为OAM提供统一认证：

// 伪代码：AMF OAM运维登录认证（ASP集成）

typedef struct {
uint8_t oam_operator_id[8]; // 运维人员ID
uint8_t ukey_cert[512]; // UKEY证书
uint8_t pin_hash[32]; // PIN码SM3哈希
char target_network[16]; // 目标网元（AMF/SMF/UPF）
uint64_t timestamp;
} amf_oam_login_t;

bool authenticate_amf_operator(amf_oam_login_t *login) {
// Step 1: UKEY证书链验证（ASP CA签发，查CRL）
if (!verify_ukey_cert_chain(login->ukey_cert)) {
log_oam("AUTH_FAIL", "CERT_INVALID", login->oam_operator_id);
return false;
}

// Step 2: PIN码验证
if (!verify_pin_hash(login->ukey_cert, login->pin_hash)) {
log_oam("AUTH_FAIL", "PIN_MISMATCH", login->oam_operator_id);
return false;
}

// Step 3: 最小权限检查——运维人员只能操作授权网元
if (!check_operator_scope(login->oam_operator_id, login->target_network)) {
log_oam("AUTH_FAIL", "SCOPE_DENIED", login->oam_operator_id);
return false;
}

// Step 4: 生成OAuth 2.0令牌（限时，绑定网元范围）
log_oam("AUTH_OK", login->target_network, login->oam_operator_id);
return true;
}

2.3 SBI接口的mTLS证书管理

AMF/SMF之间的SBI接口通信需要双向TLS证书认证。CAS-KMS内置CA为每个核心网元签发独立证书：

# 核心网元SBI接口证书配置
sbi_mtls:
certificate_authority: "CAS-KMS内置CA（SM2/RSA双算法）"
certificates:
– network_element: "AMF-01"
algorithm: "SM2-P256"
validity: "365天"
rotation: "到期前30天自动预警"
– network_element: "SMF-01"
algorithm: "SM2-P256"
validity: "365天"
rotation: "到期前30天自动预警"
revocation:
crl_update: "≤24h"
emergency: "密钥泄露即时吊销"

三、安全架构落地的四大能力

3.1 统一运维身份：一个UKEY登录所有网元

ASP平台将AMF、SMF、UPF、UDM等多个网元的OAM系统统一接入。运维人员只需一个UKEY，即可在权限范围内登录全部网元——不需要为每个网元记住不同的密码。

✅ 效果：运维认证从"多网元多密码"收敛为"统一UKEY+SSO"。

3.2 最小权限：运维操作只到"该管的网元"

ASP的RBAC模型按网元和操作类型双重划分权限：

3.3 操作审计：核心网运维全程留痕

所有核心网运维操作（参数修改、配置变更、版本升级）都记录到集中审计平台，日志SM3签名链防篡改，留存≥180天。

AMF OAM操作日志示例：
2026-07-14 10:30:12 | 运维A | 修改AMF-01注册周期参数
2026-07-14 10:31:05 | 运维A | 触发SMF-01配置备份
2026-07-14 11:02:48 | 审计员 | 导出AMF-01近7日操作日志

3.4 应急响应：网元认证异常即时处置

ASP平台支持对异常认证行为的实时响应——连续认证失败自动锁定账号、UKEY丢失即时吊销、高风险操作（如核心网配置修改）触发二次审批。

四、真实案例：某制造企业5G专网安全架构落地

背景

某大型制造企业建设5G独立专网（SNPN），包含1套AMF、2套SMF、6套UPF。项目验收时被要求满足网管安全要求——运维认证、SBI证书、操作审计三项。

实施步骤

成效

• 网元运维认证从"单密码"升级为"UKEY+密码双因素"；
• SBI接口通信从"明文HTTP"升级为"mTLS双向证书"；
• 项目一次性通过验收，满足等保三级对核心网的要求。

五、未来方向：向"无口令运维"演进

ASP正在支持更先进的运维认证模型：

• FIDO2无密码认证：运维人员通过生物特征+UKEY，替代密码输入；
• Workload Identity：自动化运维通过K8s ServiceAccount绑定身份，无需共享账号；
• 硬件信任根：运维终端TCM/TPM芯片保护UKEY私钥。

结语：认证链条闭环，才是5G核心网安全的起点

5G核心网的安全不是"选一个贵的方案"就能解决。用户接入由5G AKA保证，网元间由mTLS保证，而运维访问必须由统一身份认证来兜底——三个层次闭环，才能真正建立可信的5G核心网安全体系。

ASP不承诺"替代运营商鉴权"，但它确保：每一个运维人员、每一次核心网操作、每一份SBI证书，都处于双因素认证、最小权限、全程审计的受控状态。

文章作者：安当技术运营