5G 서비스 기반 아키텍처에서 AMF는 UDM 또는 SMF의 SBI 엔드포인트를 발견할 수 있지만, 발견만으로 가입자 데이터를 조회하거나 PDU 세션을 생성할 권한이 부여되지는 않습니다. 서비스 기반 통신은 네트워크 기능 간 상호작용을 더 유연하게 만들지만, 동시에 더 많은 코어 네트워크 API를 노출합니다. NF 서비스 제공자가 인가 확인 없이 도달 가능한 모든 요청을 처리한다면, 호출자가 정당한지, 등록되어 있는지, 요청한 서비스를 사용할 권한이 있는지를 신뢰성 있게 판단할 수 없습니다.
5GC는 OAuth 2.0 기반 인가 모델로 이 문제를 해결합니다. NF 서비스 소비자는 먼저 NRF에 액세스 토큰을 요청한 다음, 대상 NF 서비스 제공자를 호출할 때 해당 토큰을 제시합니다. 제공자는 토큰과 그 안의 인가 클레임을 검증한 후에만 요청된 작업을 수행합니다. 이 모델에서 NRF는 등록소와 검색 기능뿐 아니라 보호된 SBI 접근을 위한 인가 서버 역할도 수행합니다.
보호되지 않은 SBI 호출의 위험
5G 단독모드 네트워크는 서비스 기반 아키텍처를 사용하며, AMF, SMF, UDM, AUSF와 같은 네트워크 기능은 HTTP/2 기반 서비스 인터페이스를 통해 하나 이상의 서비스를 노출합니다. 소비자는 표준화된 HTTP API로 이러한 서비스를 호출할 수 있어, 강한 점대점 의존성을 줄이고 서비스 관계를 동적으로 구성할 수 있습니다.
예를 들어 UE 등록 과정에서 AMF는 가입 정보를 얻기 위해 UDM의 Nudm_SDM 서비스를 호출할 수 있습니다. PDU 세션 설정 과정에서는 AMF가 SMF의 Nsmf_PDUSession 서비스를 호출해 세션 관리 컨텍스트를 생성할 수 있습니다. 두 절차 모두 민감한 가입자 정보 또는 중요한 코어 네트워크 자원을 다룹니다.
UDM이 요청이 올바른 URI에 도달했다는 이유만으로 가입 데이터를 반환한다면, 호출자가 인가된 AMF인지 확인할 수 없습니다. 마찬가지로 요청자를 검증하지 않고 세션을 생성하는 SMF는 신뢰할 수 없거나 잘못 구성된 네트워크 기능의 호출을 받아들일 수 있습니다. 엔드포인트 도달 가능성은 통신이 기술적으로 가능하다는 사실만 확인할 뿐, 신원이나 인가를 증명하지는 않습니다.
클라우드 네이티브 배포에서는 위험이 더 커집니다. 운영 요구가 바뀌면 NF 인스턴스가 생성, 확장·축소, 업그레이드, 이동 또는 제거될 수 있습니다. 서비스 소비자는 NRF 기반 검색을 통해 서로 다른 제공자 인스턴스를 선택할 수도 있습니다. 따라서 정적 주소와 고정 피어 구성만으로는 개별 서비스 요청을 모두 통제하기 어렵습니다.
5GC는 서비스 검색과 서비스 인가를 분리합니다. 검색은 적합한 서비스가 어디에 있는지를 알려줍니다. 인가는 현재 소비자가 그 서비스를 사용할 수 있는지를 결정합니다. 업무 요청이 처리되기 전에 소비자는 대상 서비스와 연계된 자격 증명을 받아야 하며, 제공자는 이를 검증해야 합니다.
인가 서버로서의 NRF
OAuth 2.0은 애플리케이션 간 통제된 접근을 위한 범용 인가 프레임워크로, 이동통신망 전용 기술이 아닙니다. 표준 모델은 접근을 요청하는 클라이언트, 토큰을 발급하는 인가 서버, 요청된 자원 또는 서비스를 보호하는 리소스 서버의 세 가지 주요 역할을 정의합니다.
5GC SBI 보안 모델에서는 이러한 역할이 네트워크 기능 동작에 직접 대응합니다.
| OAuth 2.0 역할 | 5GC 엔터티 | 주요 책임 |
|---|---|---|
| 클라이언트 | NF 서비스 소비자 | 액세스 토큰을 요청하고 서비스 호출을 시작함 |
| 리소스 서버 | NF 서비스 제공자 | SBI 서비스를 제공하고 제시된 토큰을 검증함 |
| 인가 서버 | NRF | 요청을 평가하고 범위가 제한된 액세스 토큰을 발급함 |
AMF가 UDM 서비스를 호출해야 할 때 AMF는 NF 서비스 소비자, UDM은 NF 서비스 제공자 역할을 하며 NRF가 인가 기능을 제공합니다. AMF는 Nudm_SDM을 호출하기 전에 토큰을 발급받습니다. 이후 UDM은 토큰이 유효한지, 그리고 해당 클레임이 요청 서비스 접근을 허용하는지 확인합니다.
이 절차를 지원하기 위해 NRF는 Nnrf_AccessToken 서비스를 제공합니다. 토큰 요청에는 소비자 식별자, 요청 서비스 이름, 대상 NF 유형, 소비자 NF 유형, 클라이언트 식별자 등의 정보가 포함될 수 있습니다. NRF는 요청을 평가한 뒤 토큰 유형과 유효 기간 등의 정보와 함께 액세스 토큰을 반환합니다.
NRF는 요청된 업무 처리를 직접 수행하지 않습니다. 인가 컨텍스트를 정의하고 접근 자격 증명을 발급합니다. 가입자 데이터 조회, 세션 생성 및 기타 서비스별 작업은 해당 NF 서비스 제공자의 책임으로 남습니다.
토큰 기반 서비스 접근 흐름
5GC에 정의된 NF 서비스 접근 절차는 두 단계로 나눌 수 있습니다. 소비자는 먼저 NRF에서 액세스 토큰을 받은 뒤, 실제 서비스를 요청할 때 대상 제공자에게 해당 토큰을 제시합니다. 이 분리를 통해 검증되지 않은 요청이 곧바로 업무 처리 단계로 넘어가는 것을 막을 수 있습니다.
액세스 토큰 요청
NF 서비스 소비자는 먼저 NRF가 확인할 수 있는 유효한 신원과 등록 컨텍스트를 보유해야 합니다. 이후 Nnrf_AccessToken을 호출해 접근하려는 서비스, 대상 NF 유형, 자신의 소비자 정보를 지정합니다.
NRF는 사용 가능한 등록 데이터와 인가 정책을 기준으로 요청을 평가합니다. 인가가 승인되면 액세스 토큰을 생성해 소비자에게 반환합니다. 이 시점에는 가입자 조회, 세션 생성 또는 기타 업무 처리가 아직 수행되지 않았습니다. 소비자는 보호된 서비스 호출을 시도할 권한만 받은 상태입니다.
보호된 서비스 호출
소비자는 NF 서비스 제공자에게 업무 요청을 보내고 HTTP Authorization 헤더에 액세스 토큰을 포함합니다. 제공자는 요청을 처리하기 전에 토큰의 무결성, 유효 기간, 인가 클레임을 검증합니다. 이러한 검사가 모두 성공한 경우에만 요청된 서비스가 실행됩니다.
PDU 세션 설정을 예로 들면, AMF는 먼저 NRF의 Nnrf_AccessToken 서비스로 HTTP/2 POST 요청을 보내 SMF의 Nsmf_PDUSession 서비스에 접근해야 한다고 알립니다. 인가 후 NRF는 HTTP 200 OK 응답으로 토큰을 반환합니다.
그다음 AMF는 선택된 SMF에 Nsmf_PDUSession 요청을 보내면서 토큰을 포함합니다. SMF는 PDU 세션 관리 컨텍스트를 생성하기 전에 자격 증명을 검증합니다. 요청이 승인되고 컨텍스트가 성공적으로 생성되면 SMF는 HTTP 201 Created 응답을 반환할 수 있습니다.
이 순서는 업무 실행보다 인가를 먼저 수행하도록 합니다. SMF 주소와 API 경로를 알고 있는 것만으로는 충분하지 않습니다. 대상 서비스를 포함하는 유효한 토큰이 없다면 요청자가 일반적인 세션 생성을 계속하도록 허용해서는 안 됩니다.
범위와 설계 경계
NRF 기반 서비스 검색과 NRF 기반 인가는 서로 관련되어 있지만 별개의 기능입니다. 검색은 사용 가능한 제공자 인스턴스와 지원 서비스를 식별합니다. 인가는 특정 소비자가 그중 하나의 서비스를 호출할 수 있는지를 결정합니다. 검색을 완료했다고 해서 적절한 토큰을 받을 필요가 없어지는 것은 아닙니다.
액세스 토큰은 업무 데이터를 대신하지도 않습니다. NRF는 토큰을 발급할 때 UDM 가입 정보를 조회하거나 SMF 세션을 생성하지 않습니다. 정의된 범위 안에서 소비자가 인가되었다는 증거만 제공합니다. 요청 처리와 응답 생성은 계속해서 제공자가 담당합니다.
안전한 구현을 위해서는 제공자 측에서 검증을 강제해야 합니다. 소비자에게 토큰을 요청하도록 해도 제공자가 서비스 실행 전에 토큰 무결성, 만료 여부, 클레임을 검증하지 않으면 보호 효과가 거의 없습니다. 따라서 소비자, NRF, 제공자는 호환되는 토큰 처리 규칙을 따라야 합니다.
인가는 범위와 시간에도 제한됩니다. 하나의 SBI 서비스용으로 발급된 토큰이 다른 네트워크 기능의 모든 인터페이스에 대한 무제한 접근을 자동으로 허용하지는 않습니다. 만료된 토큰이나 클레임이 대상 서비스와 일치하지 않는 토큰은 유효한 자격 증명으로 취급해서는 안 됩니다.
따라서 NRF는 5G 코어에서 보안과 관련된 두 가지 독립 기능을 지원합니다. NF 프로파일을 유지하고 서비스 검색을 지원해 소비자가 적절한 제공자를 찾도록 돕습니다. 또한 Nnrf_AccessToken을 통해 해당 소비자가 보호된 SBI 서비스를 호출할 권한이 있는지 제어합니다.
자주 묻는 질문
액세스 토큰이 NF 등록을 대체할 수 있습니까?
아니요. NF 등록은 인스턴스 신원과 서비스 프로파일을 설정합니다. 액세스 토큰은 정의된 서비스 접근 컨텍스트에 대한 인가를 제공합니다. 등록과 토큰 발급은 서로 다른 목적을 가집니다.
하나의 토큰을 여러 NF 인스턴스에서 사용할 수 있습니까?
토큰 클레임, 대상 NF 유형, 서비스 범위, 적용되는 인가 정책에 따라 달라집니다. 각 제공자는 단순히 토큰이 만료되지 않았다는 이유로 승인해서는 안 되며, 현재 요청에 대해 유효한지 반드시 확인해야 합니다.
NRF를 사용할 수 없으면 기존 토큰이 즉시 무효화됩니까?
동작은 토큰 형식, 유효 기간, 제공자 측 검증 방식, 배포 정책에 따라 달라집니다. NRF가 일시적으로 중단되었다고 해서 이전에 발급된 모든 토큰의 상태가 자동으로 결정되는 것은 아니지만, 새로운 토큰 요청은 영향을 받을 수 있습니다.
OAuth 2.0이 SBI 메시지 내용을 암호화합니까?
아니요. OAuth 2.0은 주로 인가와 접근 제어를 제공합니다. SBI 전송 보호는 TLS와 같은 별도의 보안 메커니즘으로 처리됩니다. 유효한 액세스 토큰을 암호화 전송의 대체 수단으로 간주해서는 안 됩니다.
