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角色
网络层认证	3GPP 5G AKA	UE ↔ 核心网	用户接入鉴权	不参与
运维层认证	OAuth 2.0/OIDC	运维人员 ↔ 网元	AMF/SMF/UPF网管	核心平台
设备层认证	mTLS证书	网元 ↔ 网元	SBI接口安全	证书签发配合

✅ 关键认知：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提供统一认证：

c 复制代码

// 伪代码：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为每个核心网元签发独立证书：

yaml 复制代码

# 核心网元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模型按网元和操作类型双重划分权限：

运维角色	可访问网元	可执行操作	认证强度
核心网运维	AMF/SMF/UDM	配置、排障、升级	UKEY+密码+OTP
边缘运维	UPF/MEC	会话管理、应用部署	UKEY+密码
安全审计	全部（只读）	日志查看、审计导出	UKEY+密码+OTP
只读监控	指定网元	状态查看	临时UKEY（限时）

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证书、操作审计三项。

实施步骤

部署ASP统一身份认证平台，与AMF/SMF/UPF的OAM系统对接（OAuth 2.0）；
为所有运维人员发放个人UKEY，配置RBAC权限；
通过CAS-KMS为9个核心网元签发SM2 SBI证书，配置mTLS；
部署集中审计平台，核心网运维操作全量留痕。

成效

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

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

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

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

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

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

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

文章作者：安当技术运营