Кратко

  • Итоговый доклад NIST IR 8625 посвящён безопасности интеллектуального контроллера радиосети (RIC). 8 октября институт объявил о нём вместе с отдельным проектом профиля для федеральных ведомств, внедряющих O-RAN.
  • В O-RAN взаимный TLS используется для аутентификации компонентов, а OAuth2 — для авторизации. Однако O-RAN ALLIANCE не определила формат и уровень детализации OAuth2 scope. Оператор решает, распространяется ли право на ресурс целиком, API или отдельное действие.
  • Центральная точка принятия решений упрощает обновление политик, но ставит каждый запрос на авторизацию в зависимость от этой службы и может усложнить доступ приложений из другого административного домена.

Может ли xApp читать политику радиосети, не имея права её менять или удалять? Итоговый доклад NIST по безопасности использует такую границу как пример настройки OAuth2 scope, оставляя степень детализации организации, которая эксплуатирует сеть.

8 октября NIST объявил о двух документах по O-RAN с разными задачами. В итоговом IR 8625 рассматриваются требования безопасности к Near-RT RIC и его приложениям. IR 8623 — отдельный проект профиля для федеральных ведомств. Эта статья не повторяет вопрос об институциональной ответственности за риск из проекта: речь идёт о том, кто определяет разрешённые действия приложения внутри программируемой радиосети.

RIC даёт приложениям среду для мониторинга и управления ресурсами сети радиодоступа. По описанию NIST, Near-RT RIC работает с частью сот и рассчитан на время реакции в эксплуатации менее одной секунды. Non-RT RIC собирает более широкий набор данных и управляет сетью в более медленном темпе. xApps работают на стороне Near-RT, rApps — на стороне Non-RT. Например, rApp может проанализировать измерения нескольких сот и передать xApps политику или правило настройки для оперативной коррекции.

Эта гибкость расширяет и круг программ, влияющих на работу сети. В анализе угроз NIST отмечает, что сторонние приложения могут собирать сведения о RAN и передавать их другим компонентам, в том числе за пределы сети. Поэтому подмена личности, избыточные привилегии, изменение данных или неверная настройка приложения могут затрагивать больше, чем его собственный процесс. Это перечень классов угроз, а не сообщение об атаке или вывод о конкретном операторе.

В докладе описаны взаимный TLS с сертификатами X.509 для аутентификации и токены доступа OAuth2 для авторизации. Scope токена определяет полномочия для ресурса; ресурс или точка применения политики проверяет допустимость запрошенного действия. Запрашивающая сторона, ресурс и сервер авторизации должны одинаково понимать scope. Однако O-RAN ALLIANCE пока не задаёт его формат. В примерах NIST уровень прав можно определить для всего ресурса, отдельного API или конкретного вызова — например, разрешить чтение политики, но запретить её создание и удаление.

Организация, разворачивающая сеть, выбирает детализацию исходя из своей политики нулевого доверия и операционной зрелости. У этого решения есть практические последствия. Широкое разрешение упрощает подключение приложения, но может открыть действия, не нужные ему для работы. Точные права ограничивают доступ, однако требуют общего словаря, согласованной ответственности и понятного срока действия полномочий у запрашивающего, ресурса и службы авторизации. Доклад не утверждает, что все операторы применяют одну модель, и не сертифицирует конкретную реализацию.

В облачно-ориентированной архитектуре аутентификацию и авторизацию можно вынести из бизнес-логики приложений в компоненты платформы, например в сервисную сетку. Это помогает унифицировать контроль. NIST также описывает централизованную точку принятия решений: она упрощает обновление политик и сбор данных о характере доступа и состоянии безопасности. Но есть и обратная сторона. Если точка недоступна, запросы доступа в RAN не смогут получить через неё разрешение. Из этого не следует, что сама радиосвязь прекратится: доклад указывает на зависимость авторизации, а не на отказ сети.

Граница становится сложнее, если приложение принадлежит другому административному домену. В качестве примера NIST приводит rApp, предоставляемую как услугу. Централизованная точка одного оператора может не располагать контекстом для оценки внешнего субъекта. Токен также не всегда содержит все сведения о текущем состоянии безопасности и поведении запрашивающей стороны. Кто подтверждает личность приложения, кто вправе менять его scope и какая организация видит доказательства для решения — вопросы архитектуры конкретного развёртывания.

Отдельно NIST различает защиту канала и защиту данных. Взаимный TLS защищает связь между компонентами. В облачном процессе между создателем политики или измерения и её потребителем могут находиться общее хранилище или брокер сообщений. Подпись или шифрование самого объекта данных способны сохранить его происхождение, целостность либо конфиденциальность на пути через посредников, но требуют от создателей и потребителей управления ключами и проверки объектов. IR 8625 называет это направлением для дальнейшего анализа, а не требованием заменить защиту каналов.

Вывод доклада ограничен: стандартизованные протоколы предоставляют механизмы для контроля нулевого доверия, но не определяют смысл разрешений, выбранных оператором, и не снимают с него ответственность за непрерывность авторизации и доверие между доменами. Источники не называют конкретное развёртывание, вторжение, сбой политики или измеренное влияние на доступность.

Источники