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ベースのサービスベースインターフェースを通じて1つ以上のサービスを公開します。コンシューマは標準化されたHTTP APIを介してこれらのサービスを呼び出せるため、固定的なポイントツーポイント依存を減らし、サービス関係を動的に構築できます。
例えばUE登録時、AMFは加入情報を取得するためにUDMのNudm_SDMサービスを呼び出すことがあります。PDUセッション確立時には、AMFがSMFのNsmf_PDUSessionサービスを呼び出してセッション管理コンテキストを作成することがあります。どちらの手順も、機密性の高い加入者情報または重要なコアネットワークリソースを扱います。
UDMが、要求が正しいURIに到達したという理由だけで加入データを返す場合、呼び出し元が認可されたAMFである保証はありません。同様に、要求元を検証せずにセッションを作成するSMFは、信頼できない、または誤って設定されたネットワーク機能からの呼び出しを受け入れる可能性があります。エンドポイントに到達できることは、通信が技術的に可能であることを示すだけで、IDや認可を証明するものではありません。
クラウドネイティブ環境では、このリスクがさらに高まります。NFインスタンスは、運用要件の変化に応じて作成、スケール、アップグレード、移動、削除されることがあります。また、サービスコンシューマはNRFベースの検出を通じて異なるプロデューサインスタンスを選択できます。そのため、静的アドレスや固定ピア設定だけでは、個々のサービス要求を十分に制御できません。
5GCはサービス検出とサービス認可を分離します。検出は、適切なサービスがどこで利用できるかを示します。認可は、現在のコンシューマがそのサービスを利用できるかどうかを決定します。業務要求を処理する前に、コンシューマは対象サービスに関連付けられた資格情報を取得し、プロデューサはその資格情報を検証しなければなりません。
認可サーバとしてのNRF
OAuth 2.0は、アプリケーション間の制御されたアクセスに使用される一般的な認可フレームワークであり、モバイルネットワーク専用ではありません。標準モデルでは、アクセスを要求するクライアント、トークンを発行する認可サーバ、要求対象のリソースまたはサービスを保護するリソースサーバという3つの主要な役割を定義しています。
5GCのSBIセキュリティモデルでは、これらの役割がネットワーク機能の動作に直接対応します。
| OAuth 2.0の役割 | 5GCエンティティ | 主な役割 |
|---|---|---|
| クライアント | NFサービスコンシューマ | アクセストークンを要求し、サービス呼び出しを開始する |
| リソースサーバ | NFサービスプロデューサ | SBIサービスを提供し、提示されたトークンを検証する |
| 認可サーバ | NRF | 要求を評価し、スコープが限定されたアクセストークンを発行する |
AMFがUDMサービスを呼び出す必要がある場合、AMFはNFサービスコンシューマ、UDMはNFサービスプロデューサとして動作し、NRFが認可機能を提供します。AMFはNudm_SDMを呼び出す前にトークンを取得します。その後、UDMはトークンが有効か、またそのクレームが要求されたサービスへのアクセスを許可しているかを確認します。
この処理を支えるため、NRFはNnrf_AccessTokenサービスを公開します。トークン要求には、コンシューマID、要求するサービス名、対象NFタイプ、コンシューマNFタイプ、クライアント識別子などの情報を含めることができます。NRFは要求を評価した後、アクセストークンとともに、トークン種別や有効期間などの関連情報を返します。
NRFは要求された業務処理を実行しません。認可コンテキストを定義し、アクセス資格情報を発行します。加入者データの取得、セッション作成、その他のサービス固有処理は、該当するNFサービスプロデューサの責任です。
トークンベースのサービスアクセスフロー
5GCで定義されるNFサービスアクセス手順は、2つの段階に分けられます。コンシューマは最初にNRFからアクセストークンを取得し、その後、実際のサービスを要求する際に対象プロデューサへそのトークンを提示します。この分離により、未検証の要求がそのまま業務処理へ進むことを防ぎます。
アクセストークンの要求
NFサービスコンシューマは、NRFが参照できる有効なIDと登録コンテキストをあらかじめ持っている必要があります。その後、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ベースの認可は関連していますが、別個の機能です。検出は、利用可能なプロデューサインスタンスと、それらがサポートするサービスを特定します。認可は、特定のコンシューマがそのサービスの1つを呼び出せるかどうかを決定します。検出が完了しても、適切なトークンを取得する必要はなくなりません。
アクセストークンは業務データの代替でもありません。NRFはトークン発行時にUDMの加入情報を取得したり、SMFセッションを作成したりしません。定義されたスコープ内でコンシューマが認可されたことを示す証拠を提供するだけです。要求の処理と応答の生成は引き続きプロデューサが担当します。
安全な実装には、プロデューサ側での強制的な検証が必要です。コンシューマにトークンを要求させても、プロデューサがサービス実行前にトークンの完全性、期限、クレームを検証しなければ、十分な保護にはなりません。そのため、コンシューマ、NRF、プロデューサは互換性のあるトークン処理ルールに従う必要があります。
認可はスコープと時間によっても制限されます。あるSBIサービス向けに発行されたトークンが、他のネットワーク機能が公開するすべてのインターフェースへの無制限アクセスを自動的に許可するわけではありません。期限切れのトークンや、クレームが対象サービスと一致しないトークンを有効な資格情報として扱ってはいけません。
したがってNRFは、5Gコアでセキュリティに関する2つの異なる機能を提供します。NFプロファイルを管理し、サービス検出を支援して、コンシューマが適切なプロデューサを見つけられるようにします。またNnrf_AccessTokenを通じて、コンシューマが保護されたSBIサービスを呼び出す権限を持つかどうかも制御します。
よくある質問
アクセストークンでNF登録を置き換えられますか？
いいえ。NF登録はインスタンスのIDとサービスプロファイルを確立します。アクセストークンは、定義されたサービスアクセスコンテキストに対する認可を提供します。登録とトークン発行は目的が異なります。
1つのトークンを複数のNFインスタンスで使用できますか？
トークンのクレーム、対象NFタイプ、サービススコープ、適用される認可ポリシーによって異なります。各プロデューサは、単に有効期限内であるという理由で受け入れるのではなく、現在の要求に対してトークンが有効かを確認する必要があります。
NRFが利用できなくなると、既存のトークンは直ちに無効になりますか？
動作は、トークン形式、有効期間、プロデューサ側の検証方法、導入ポリシーによって異なります。NRFの一時的な障害によって、発行済みのすべてのトークンの状態が自動的に決まるわけではありませんが、新しいトークン要求には影響する可能性があります。
OAuth 2.0はSBIメッセージ内容を暗号化しますか？
いいえ。OAuth 2.0は主に認可とアクセス制御を提供します。SBIの伝送保護はTLSなどの別個のセキュリティ機構によって行われます。有効なアクセストークンを暗号化伝送の代替として扱ってはいけません。
