Кратко

  • RIPE NCC переводит панель RPKI на OpenID Connect и начал заменять действующие API-ключи ключами на основе OIDC, связанными с RIPE NCC Access. Проект пока находится в работе.
  • Отдельный проект RPKI-маяка не был реализован: используемый API позволял бы редактировать ROA для всего пространства RIPE NCC. Надёжная идентификация не заменяет узкую ресурсную авторизацию.

У автоматизированного доступа есть как минимум два радиуса. Первый показывает, где принимают учётные данные. Второй — насколько далеко может распространиться разрешённое ими изменение. Современная система входа сужает первый радиус лишь при правильной настройке и ничего автоматически не говорит о втором.

В плане RPKI на четвёртый квартал 2026 года, обновлённом 17 сентября, RIPE NCC сообщает о переводе панели управления на OpenID Connect через RIPE NCC Access. Началась и замена нынешних ключей RPKI API на ключи на основе OIDC, встроенные в ту же систему единого входа. Для управления ими должна появиться отдельная секция панели. Детали реализации и сроки организация обещает представить на предстоящей встрече RIPE. Публичный статус — «в работе».

У направления есть очевидные достоинства. RIPE NCC Access требует двухфакторную аутентификацию. Опубликованные правила ограничивают жизнь API-ключа одним годом, связывают его с конкретной учётной записью и предусматривают деактивацию при отключении SSO-аккаунта или утрате пользователем роли сопровождающего в соответствующей системе. Общий жизненный цикл может снизить число забытых секретов.

Однако OIDC — это слой идентификации поверх OAuth 2.0. Он позволяет клиенту проверить аутентификацию, выполненную сервером авторизации, и получить сведения о пользователе. Само название протокола не разделяет чтение, подготовку и публикацию ROA и не ограничивает доступ конкретным LIR, сертификатом или набором префиксов.

В OAuth эти вопросы тоже распадаются на части. Resource Indicator указывает защищённый сервер, которому предназначен токен. Scope описывает запрашиваемый доступ. Рекомендации по безопасности требуют ограничивать аудиторию токена конкретным или небольшим набором серверов. Но токен, действующий только в RPKI-сервисе, всё равно может получить чрезмерные права внутри него. Граница ресурсов задаётся самим приложением.

Вторая часть квартального плана показывает практическую цену такого различия. Сообщество предложило известный маршрутный маяк с меняющейся RPKI-валидностью для исследований. RIPE NCC пока не добавил его, поскольку применяемый API позволял редактировать ROA для всего пространства организации. Такой охват был признан неприемлемым; альтернативу будут искать вместе с командой RIS.

Этот эпизод нельзя выдавать за доказательство слабости будущей схемы OIDC. API маяка — отдельный случай, а модель новых ключей ещё не опубликована. Зато решение устанавливает полезный стандарт: удобство функции не оправдывает несоразмерную область изменений.

Строгость объяснима природой ROA. Это подписанный объект RPKI, разрешающий исходной автономной системе объявлять префикс, при необходимости с максимальной длиной. В размещённом сервисе RIPE NCC одна конфигурация содержит исходную AS, префикс и максимальную длину; система подписывает, публикует и обновляет объекты. Текущий API позволяет добавлять и удалять несколько ROA одним запросом публикации.

В действующем сервисе уже есть полезные разграничения. Попытка создать ROA для не принадлежащего клиенту префикса, согласно документации, возвращает 403. Панель позволяет оставить изменения ожидающими, изучить затронутые BGP-анонсы и применить набор атомарно. API может заранее оценить эффект ещё не созданного ROA.

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

Редакционная рамка статьи основана на заметках Heng Lu о минимальной начальной спецификации, слоях реальности и агентской проблеме в управлении Интернетом. Для RPKI это означает узкие исходные полномочия и будущие решения рядом с затронутым ресурсом. Это аналитический подход, а не позиция RIPE NCC.

Источники