Привет, Хабр! На связи команда архитекторов, разработчиков и тестировщиков Рунити, которые внедряли функцию «Мультидоступ» в личный кабинет Руцентра. В этой статье рассказываем, как добавляли ролевые проверки, перестраивали контур авторизации и дорабатывали существующую инфраструктуру личного кабинета доменного регистратора. Проект получился объемным, график — насыщенным, но обо всем по порядку :)
Надеемся, что эта статья пригодится командам, которые развивают большие продукты и внедряют в них новые контуры авторизации.
Навигация по тексту:
Задача на старте звучала просто: дать клиентам возможность передавать доступ к личному кабинету без необходимости делиться учётными данными основного аккаунта. Для управления доменными портфелями — особенно в крупном бизнесе — это важный аспект безопасности. Одна неверная операция может повлиять на работу сервисов и стоить слишком дорого. Поэтому требовалось решение, которое позволит разделять обязанности и при этом сохранять контроль над доступами. На практике это стало одним из самых глубоких обновлений в архитектуре ЛК за последние годы и важным изменением для всего доменного рынка в целом
Мы долго шли к этому обновлению и рады, что теперь клиенты могут безопасно распределять доступы внутри команд. Правда, это только начало: впереди много работы, чтобы постепенно расширять возможности ролевой модели.
Жизнь до Мультидоступа: один логин на всех
До запуска Мультидоступа схема была простой, но небезопасной: владелец аккаунта передавал свой логин и пароль бухгалтеру, маркетологу, администратору сайта. В ЛК не было ролевой модели, прав, ограничений и полноценного аудита. Получается, что любое неосторожное действие могло привести к неожиданным последствиям — от случайного удаления DNS-записи до блокировки сервера. А значит, компания могла остаться без активного сайта, что могло принести серьезные репутационные и финансовые потери для бизнеса.
После внедрения функции Мультидоступа владелец аккаунта теперь может назначать роли с разными уровнями прав, ограничивать операции и включать двухфакторную аутентификацию в интерфейсе личного кабинета. После создания роли пользователь получает для нее отдельный аккаунт — и уже его передает коллеге или подрядчику удобным ему способом. На уровне интерфейса это действительно похоже на стандартную ролевую модель, но под капотом — новый контур авторизации, ролевые проверки и значительный объем доработок в модулях ЛК.
Почему мы не могли оставить старую архитектуру
До проекта авторизация в ЛК опиралась на историческую схему входа под техническим паролем. В системе существовало разделение на основной (административный) аккаунт и технический аккаунт, который использовался для выполнения операций в личном кабинете. Логика доступа при этом была распределена: часть проверок находилась в биллинге, часть — в отдельных модулях. Это работало для физических лиц, но для корпоративных клиентов требовалась гибкая система, которая:
позволяет назначать разные группы прав;
не ломает существующие проверки;
работает на уровне API, а не в глубине биллинга;
расширяется без миграций и изменений состояния;
выдерживает нагрузку и дает возможность масштабирования.
Поэтому роли нельзя было просто добавить: нужно было ввести новый уровень авторизации поверх существующего и встроить его так, чтобы старая логика продолжала работать.
Мультидоступ: как работает новая архитектура
Сейчас после активации услуги владелец аккаунта становится главным администратором. Он создает роли, выбирает группы прав и перед��ет доступ сотрудникам или подрядчикам.
Технически модель выглядит так:
Пользователь проходит аутентификацию через identity provider.
Возвращается в ЛК.
Получает сессию в модуле аутентификации.
После аутентификации сервис ��вторизации возвращает данные о пользователе, включая его роли и параметры доступа. Эти данные используются в BFF для дальнейшей проверки прав.
Запросы идут в API-слой, который проверяет каждую операцию через единый движок проверки политик (policy engine).
BFF принимает решение, опираясь на ответ policy engine.
Проверки по ролям реализованы на уровне BFF: именно здесь происходит принятие решения, какие операции доступны пользователю в конкретном контексте. Такой подход позволяет применять единые правила доступа для всех сценариев, независимо от того, к какому разделу личного кабинета относится операция.
Виджетная архитектура и Backend for Frontend
В проекте Мультидоступа мы добавили отдельный слой Backend for Frontend (BFF) и перешли к виджетной архитектуре. В этом подходе страница личного кабинета собирается из независимых блоков-виджетов. Каждый виджет состоит из двух частей: компонентов интерфейса на фронтенде и набора API-методов в BFF.
Фронтенд отвечает за раскладку и взаимодействие виджетов, а BFF — за агрегацию данных из смежных сервисов и представление их в удобном для интерфейса виде. Такое разделение ответственности позволяет развивать интерфейс и серверную часть независимо: фронтенд-команда работала над виджетами и UX, а команда BFF — над консистентными данными и едиными сценариями доступа. Под Мультидоступ мы фактически поднимали новый контур личного кабинета, и этот же подход используем в следующих разделах ЛК.
Почему выбрали ABAC
Новая модель реализована на основе ABAC (Attribute-Based Access Control) — управления доступом по атрибутам. В такой модели решение принимается не только по роли, но и по набору атрибутов: объекту операции, типу действия, связанному договору и контексту запроса. Это делает систему гибкой и позволяет лучше контролировать доступ. Мы рассматривали и готовые решения, но стоимость внедрения и кастомизации была в разы выше, чем разработка собственного движка.
Хотя в основе новой модели лежит ABAC, роли не исчезают — они становятся удобным способом группировать атрибуты и описывать рабочие сценарии. Для пользователя это привычный инструмент, а для системы — способ быстрее собирать атрибуты доступа и передавать их в движок политик. Именно поэтому рядом с атрибутами появились предустановленные роли и шаблоны, которые упрощают работу в ЛК и помогают быстрее настроить доступы.
Предустановленные роли в Мультидоступе
Мы добавили предустановленные роли — готовые наборы прав, которые помогают быстрее настроить доступы в личном кабинете. Вместо того чтобы вручную проходить через весь перечень разрешений, владелец аккаунта может выбрать один из шаблонов и сразу получить рабочую конфигурацию. Эти роли отражают типовые сценарии: управление доменами, DNS, SSL, настройками уведомлений, оплатами. Такой подход уменьшает вероятность ошибок при назначении прав и ускоряет первые шаги в ролевой модели — особенно в командах, где нескольким сотрудникам нужны разные уровни доступа.
Кроме того, предустановленные роли упрощают масштабирование: ими удобно пользоваться, когда нужно выдать одинаковые разрешения нескольким специалистам или поддерживать единообразие доступа внутри команды. При этом шаблоны не ограничивают модель — их можно менять или создавать собственные роли, если требуется более точная настройка. Фактически это способ быстрее начать работу, сохраняя контроль над тем, какие операции доступны каждому участнику.
Роль «Индивидуальный менеджер» для премиальных клиентов
В ролевой модели есть отдельная предустановленная роль — «Индивидуальный менеджер». Она создана для тех случаев, когда у клиента есть персональный менеджер в Руцентре и часть операций удобнее передать ему напрямую. С этой ролью становится проще делегировать задачи, не передавая данные основного аккаунта и не создавая технические пароли. Клиент сам определяет набор действий, которые может выполнять менеджер, — от просмотра отдельных разделов до выполнения конкретных операций. Все изменения фиксируются в истории действий, что позволяет поддерживать прозрачность и контроль.
Архитектурный контур: как формировалась новая логика ЛК
Первая версия бизнес-требований появилась 16 декабря 2024 года. Документ постоянно обновлялся — к моменту релиза в нем было 266 изменений и 58 минут чтения. Задачу на архитектуру поставили 17 января 2025 года, а закрыли 24 июня. Почти четыре месяца команда архитекторов искала способ встроить новую логику доступа в личный кабинет без полного переписывания легаси.
В цифрах это выглядело так:
226 архитектурных документов;
105 контрактов, часть новых, часть измененных;
69 событий, из которых 78 % новых.
Почему так много? Потому что большинство операций ЛК развивались эволюционно, без единой карты. Ограничения и зависимости были зашиты глубоко в биллинг, DNS, домены, платежи, уведомления. При введении ролей каждая операция должна была быть описана и размечена, чтобы policy engine мог корректно проверить доступ.
От монолитного ЛК к виджетной архитектуре
Личный кабинет много лет развивался на Perl-модулях, вокруг которых строились биллинг, домены, DNS и уведомления. В Мультидоступе мы не стали переносить эту модель в новый контур. Вместо этого решили сделать некий конструктор, который позволит собирать страницу через набор конфигураций. Такой подход позволил развивать личный кабинет без переписывания всей инфраструктуры. BFF стал единым входом для фронтенда и точкой, где мы собираем и преобразуем данные из разных сервисов.
На архитектурном этапе мы зафиксировали два ключевых принципа:
Оценивать весь объем целиком, чтобы понимать реальную сложность.
Выкатывать изменения под фича флагами, чтобы проверять работу на проде без риска.
Оценка, декомпозиция и работа команд
После утверждения архитектуры проект перешел к декомпозиции:
29 эпиков;
2 новых сервиса;
изменения в 34 модулях;
общий объем — более 5000 человеко-часов.
Команда работала недельными спринтами, затрагивая в пике 57 репозиториев. Тестирование велось на stage, а после тестирование на stage задачи выкатывались под фича флагами.
Что происходит, когда оценка встречается с реальностью
К середине лета проявились недооцененные блоки:
около 1000 дополнительных часов;
более 300 часов на перенос зон старого стека;
подключение к��манды доменов для опции УПБД (услуга «Безопасность домена», включающая набор дополнительных механизмов защиты доменных имен) — 8 эпиков, 600+ часов, 9 разработчиков.
Ключевые зоны работы с новой моделью доступа
Мультидоступ затронул широкий спектр систем, с которыми работает личный кабинет, и для части из них потребовалась дополнительная адаптация под новую ролевую модель. Наиболее заметные изменения пришлись на:
системы уведомлений (Mail- и SMS-gate) — мы добавили новые сценарии отправки и согласовали их с обновленной логикой доступа;
старые части ЛК на Perl — здесь понадобилось расширить существующие сценарии и обеспечить корректную работу с новым контуром авторизации;
интеграции с рядом смежных сервисов — мы обновили контракты и описали дополнительные вызовы для поддержки проверки прав на уровне BFF.
Переписывать системы целиком не требовалось, но их адаптация стала заметной частью проекта: важно было встроить ролевую модель так, чтобы не нарушить текущую работу кабинета и сохранить предсказуемость поведения для клиентов.
Отдельный объем работы пришелся на интеграцию со смежными сервисами. За годы наша микросервисная архитектура серьезно разрослась: биллинг, SMS- и email-шлюзы, сервисы аутентификации, идентификации и другие компоненты используют разные форматы и контракты — от XML до собственных текстовых схем. Для поддержки Мультидоступа мы написали набор клиентов в BFF и вынесли их в общие библиотеки. Теперь при добавлении новых сценариев мы переиспользуем этот слой интеграции, не дублируя подключения к сервисам и не усложняя существующие модули.
Нагрузка и узкие места
После запуска Мультидоступа основной рост нагрузки пришелся не на BFF, а на смежные сервисы, к которым он обращается. На каждой странице ЛК мы запрашиваем сессию и данные пользователя, поэтому увеличилось число обращений к биллингу и модулям аутентификации.
Там, где это возможно, BFF запрашивает данные параллельно: обращается сразу к нескольким сервисам и агрегирует ответы. В сценариях, где нужен строгий порядок (например, сначала получить параметры договора, затем — статусы услуг), остается последовательная цепочка запросов. Для части «тяжелых» ответов мы закладываем кэширование и постепенную оптимизацию, чтобы удерживать время ответа в комфортных рамках для пользователя.
Событийная модель и задержки активации
Подключение Мультидоступа для клиента — это целая цепочка событий. Пользователь приобретает услугу или получает ее по в рамках тарифных опций, проходит идентификацию договора, настраивает второй фактор. Каждое действие уходит в шину событий и обрабатывается асинхронно: проверяются данные договора, создаются роли, настраиваются уведомления.
Из-за этого часть изменений появляется в интерфейсе с небольшой задержкой: услуга уже подключена, но отдельные статусы и напоминания обновляются не мгновенно. На продакшене эти задержки укладываются в допустимые значения, и мы учитываем их при проектировании сценариев — но как часть нормальной работы событийной модели, а не как ошибку.
Релиз за 2 мину��ы: почему у нас всё получилось
В августе стало очевидно, что три QA на 15 разработчиков — недостаточно для такого масштабного проекта. Поэтому ввели функциональные срезы — изолированные блоки системы, которые можно тестировать независимо. Это структурировало работу и снизило нагрузку.
Команда QA выросла до шести человек. Всего нашли 342 бага: от минорных до требующих архитектурных правок. Из-за уточнения объема и тестирования релиз переносили трижды: с сентября на начало октября, затем — на вторую половину октября. Финальный выкат занял меньше двух минут: фича флаги включили в 09:05 МСК, система работала без простоев. За первые пять часов активировано 18 000 услуг Мультидоступа, менее сотни — с ручной проверкой.
Почему получилось так быстро
все изменения шли под фича флагами;
не было тяжелых миграций и трансформаций данных;
сервисы деплоились независимо, без «одновременных» релизов;
policy engine не ломал старую авторизацию;
команды разработки, QA и эксплуатации работали в едином контуре.
Архитектура, которую мы заложили в Мультидоступе, стала базовой для следующих изменений в личном кабинете. На виджетном подходе и BFF сейчас развиваем DNS-мастер и мастер SSL/TLS — разделы, где клиент управляет зонами и сертификатами.
Параллельно выносим конфигурацию интерфейсов в отдельное хранилище: тексты, настройки виджетов, варианты для разных языков. Планируем хранить их в репозитории, чтобы продуктовая команда могла безопасно изменять конфигурацию и оперативно выкатывать правки без вмешательства в код BFF.
Выводы: что изменилось после проекта
Проект «Мультидоступ» стал для команды настоящим краш-тестом на устойчивость процессов. После релиза мы провели ретро и зафиксировали, что сработало, какие процессы нужно докрутить и каких инструментов нам не хватает.
1. Декомпозиция.
Главный вывод — бывает непросто тянуть 6500 часов разработки в одном этапе. Теперь крупные изменения планируем поэтапно, с возможностью изолированного релиза каждой части.
2. Подключение QA-инженеров на раннем этапе.
В стандартной практике мы подключаем тестировщиков на ранних этапах — они помогают уточнить сценарии, оценить риски и заложить реалистичные сроки на тестирование. По итогам проекта этот подход еще раз подтвердил свою эффективность, и мы закрепили его как обязательный для крупных изменений.
3. Функциональные срезы.
Срезы оказались одним из самых полезных решений. Они структурировали работу, снизили нагрузку на тестировщиков и ускорили коммуникацию. Разработчики и QA собирались по функциональным группам, разбирали срезы и закрывали их в полном составе. Для следующих проектов этот подход зафиксировали как обязательный.
4. Инструменты тестирования.
Проект показал ограничения текущего стека:
создание тестовых окружений требует ручных действий;
нет автоматизации для типовых сценариев.
В плане теперь — внедрить инструменты для быстрой сборки окружений и автоматизации тестов.
5. Метрики и прозрачность.
Все задачи проекта велись в Jira в ��тдельном датасете с использованием Jira Structure. В структуре фиксировались эпики, время в статусах, трудозатраты и изменения. Этот подход теперь принят по умолчанию — данные позволяют видеть узкие места и точнее планировать ресурсы.
6. Команда и стек.
Проект стал точкой перехода для части команды: разработчики, которые раньше поддерживали модули личного кабинета на Perl и PHP, начали работать с новым серверным стеком и постепенно развивать оба направления. Это уменьшило риски для проекта и позволило масштабировать команду BFF без отдельного долгого найма.
Мы понимаем, что впереди еще много улучшений: ролевую модель нужно развивать, сценарии — расширять, а личный кабинет — постепенно переводить на новый архитектурный контур. Это долгий процесс, и мы рады, что сделали первый шаг — Мультидоступ уже работает, приносит пользу клиентам и стал основой для следующих обновлений.
В сумме проект занял 10 месяцев, из них 5 месяцев активной разработки. Участвовало 35 человек, затронуто 57 репозиториев. Релиз занял меньше двух минут, и уже через несколько часов клиенты получили 18 000 активных услуг.
Проект «Мультидоступ» показал, что даже простая на вид идея «дать роли в ЛК» может потребовать пересборки архитектуры, пересмотра процессов и терпения всей команды. Но в итоге фича работает стабильно, а ее внутренняя механика стала основой для следующих изменений в личном кабинете.
Наверняка и в ваших проектах с бывало так, что с виду простая задача превращалась в десятимесячный рефакторинг? Расскажите в комментах, как спасали сроки, что помогало, а что — наоборот не сработало.