В сервисно-ориентированной архитектуре 5G функция AMF может обнаружить конечную точку SBI функции UDM или SMF, однако само обнаружение не предоставляет права получать данные абонента или создавать PDU-сеанс. Сервисное взаимодействие делает связи между сетевыми функциями более гибкими, но одновременно открывает более широкий набор API ядра сети. Если производитель NF-сервиса обрабатывает любой доступный запрос без проверки авторизации, он не может надежно определить, является ли вызывающая сторона легитимной, зарегистрированной и имеющей право использовать запрошенный сервис.
5GC решает эту задачу с помощью модели авторизации на базе OAuth 2.0. Потребитель NF-сервиса сначала запрашивает у NRF токен доступа, а затем предъявляет его при обращении к целевому производителю NF-сервиса. Производитель выполняет запрошенную операцию только после проверки токена и содержащихся в нем авторизационных утверждений. В этой модели NRF выступает не только как реестр и функция обнаружения, но и как сервер авторизации для защищенного доступа к SBI.
Риски незащищенных вызовов SBI
Автономные сети 5G используют сервисно-ориентированную архитектуру, в которой такие сетевые функции, как AMF, SMF, UDM и AUSF, предоставляют один или несколько сервисов через интерфейсы на базе HTTP/2. Потребитель может вызывать эти сервисы через стандартизированные HTTP API, что уменьшает жесткие зависимости «точка-точка» и позволяет динамически формировать сервисные связи.
Например, при регистрации UE функция AMF может вызвать сервис Nudm_SDM функции UDM для получения данных подписки. При установлении PDU-сеанса AMF может вызвать сервис Nsmf_PDUSession функции SMF для создания контекста управления сеансом. Оба процесса затрагивают конфиденциальные данные абонента или критически важные ресурсы ядра сети.
Если UDM возвращает данные подписки только потому, что запрос поступил на правильный URI, у нее нет подтверждения, что вызывающая сторона является авторизованной AMF. Аналогично SMF, создающая сеанс без проверки инициатора, может принять вызов от недоверенной или неправильно настроенной сетевой функции. Доступность конечной точки подтверждает лишь техническую возможность связи, но не удостоверяет личность и не подтверждает полномочия.
В облачно-нативных развертываниях риск возрастает. Экземпляры NF могут создаваться, масштабироваться, обновляться, перемещаться или удаляться по мере изменения эксплуатационных требований. Потребитель сервиса также может выбирать разные экземпляры производителей через обнаружение на базе NRF. Поэтому статических адресов и фиксированных конфигураций одноранговых узлов недостаточно для контроля каждого отдельного сервисного запроса.
5GC разделяет обнаружение сервисов и их авторизацию. Обнаружение отвечает на вопрос, где доступен подходящий сервис. Авторизация определяет, разрешено ли текущему потребителю использовать его. До обработки прикладного запроса потребитель должен получить учетные данные, связанные с нужным сервисом, а производитель обязан их проверить.
NRF как сервер авторизации
OAuth 2.0 — это общий механизм авторизации для контролируемого доступа между приложениями, не ограниченный мобильными сетями. Его стандартная модель определяет три основные роли: клиент, запрашивающий доступ; сервер авторизации, выдающий токен; и сервер ресурсов, защищающий запрашиваемый ресурс или сервис.
В модели безопасности SBI для 5GC эти роли напрямую сопоставляются с поведением сетевых функций:
| Роль OAuth 2.0 | Сущность 5GC | Основная ответственность |
|---|---|---|
| Клиент | Потребитель NF-сервиса | Запрашивает токен доступа и инициирует вызов сервиса |
| Сервер ресурсов | Производитель NF-сервиса | Предоставляет SBI-сервис и проверяет предъявленный токен |
| Сервер авторизации | NRF | Оценивает запрос и выдает токен доступа с заданной областью действия |
Когда AMF требуется вызвать сервис UDM, AMF выступает потребителем NF-сервиса, UDM — его производителем, а NRF обеспечивает авторизацию. Перед вызовом Nudm_SDM функция AMF получает токен. Затем UDM проверяет его действительность и удостоверяется, что содержащиеся в нем утверждения разрешают доступ к запрошенному сервису.
Для поддержки этого процесса NRF предоставляет сервис Nnrf_AccessToken. Запрос токена может включать идентификатор потребителя, имя требуемого сервиса, тип целевой NF, тип NF-потребителя и идентификатор клиента. После оценки запроса NRF возвращает токен доступа вместе с такими параметрами, как тип токена и срок его действия.
NRF не выполняет запрошенную прикладную операцию. Он определяет контекст авторизации и выдает учетные данные для доступа. Получение данных абонента, создание сеанса и другие операции конкретного сервиса остаются обязанностью соответствующего производителя NF-сервиса.
Поток доступа к сервису на основе токена
Процедуру доступа к NF-сервису, определенную для 5GC, можно разделить на два этапа. Сначала потребитель получает токен доступа от NRF. Затем он предъявляет его целевому производителю при запросе фактического сервиса. Такое разделение не позволяет непроверенному запросу сразу перейти к прикладной обработке.
Запрос токена доступа
Потребитель NF-сервиса должен сначала иметь действительную идентичность и контекст регистрации, доступные NRF. Затем он вызывает Nnrf_AccessToken и указывает сервис, к которому хочет получить доступ, тип целевой NF и собственные сведения как потребителя.
NRF оценивает запрос на основании имеющихся регистрационных данных и политики авторизации. Если доступ разрешен, NRF создает токен и возвращает его потребителю. На этом этапе еще не выполнены ни запрос данных абонента, ни создание сеанса, ни другая прикладная операция. Потребитель получил лишь разрешение попытаться вызвать защищенный сервис.
Вызов защищенного сервиса
Потребитель отправляет прикладной запрос производителю NF-сервиса и включает токен доступа в HTTP-заголовок Authorization. До обработки запроса производитель проверяет целостность токена, срок его действия и авторизационные утверждения. Запрошенный сервис выполняется только при успешном прохождении всех проверок.
Рассмотрим установление PDU-сеанса. Сначала AMF отправляет HTTP/2 POST-запрос к сервису Nnrf_AccessToken функции NRF, указывая, что ей требуется доступ к сервису Nsmf_PDUSession функции SMF. После авторизации NRF возвращает токен в ответе HTTP 200 OK.
Затем AMF отправляет запрос Nsmf_PDUSession выбранной SMF и прикладывает токен. 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. Действительный токен доступа не следует считать заменой шифрованной передаче.
