Кейс «Аврора Центр»: MDM против зоопарка версий ОС в 2026
PrimeCoder · 2026 · формат: tech
Разбор новинки простыми словами: что это, кому нужно и брать ли.
Кейс показывает, что корпоративный MDM нужен не для установки приложений, а для разграничения версий ОС, доверенных источников и прав публикации — это готовый шаблон для компаний с разнородным парком устройств.
Связанные услуги: каталог, AI Boost Team, стать клиентом.
Вендоры редко пускают внутрь своего парка. «Открытая мобильная платформа» (блог Ростелекома) выложила разбор от продакт-менеджера «Аврора Центра» Александра Конина: как компания управляет собственными устройствами на ОС Аврора. Ценность тут не в продукте, а в схеме. У вендора та же головная боль, что у среднего бизнеса с разнородным парком: части сотрудников нужна стабильная система, части — тестовые сборки, а ставить что попало нельзя.
Что это
«Аврора Центр» — платформа управления корпоративными устройствами (MDM/UEM). Распространяет приложения, рулит обновлениями, помогает пользователям. Внутри «Открытой мобильной платформы» её применяют в двух контурах. Первый — «Аврора офис»: сотрудники получают рабочие смартфоны, компания ставит на них софт и обновляет систему. Второй — бета-программа ОС Аврора, где участники пробуют новые сборки и приложения и отдают замечания команде. В сентябре программе исполнилось пять лет, к этому моменту сообщество выросло до 700 человек из 17 городов.
Офисный сценарий здесь важнее, чем кажется. Терминал решает одну задачу — там набор приложений фиксирован. Рабочий смартфон так не живёт: десяток приложений, у каждого свой график обновлений, у каждого сотрудника свои привычки. А значит, и требования к версии ОС разъезжаются.
Три замка вместо одной кнопки «установить»
Публичный кейс интересен тем, что показывает: MDM в 2026 году нужен ради разграничения. Установка приложений — побочный продукт, а не смысл.
Первый замок — источники. Корпоративный софт с лицензиями лежит в Аврора Маркете, остальное экосистемное — в RuStore для ОС Аврора. Политика управления перечисляет доверенные источники и блокирует пакеты без подписи доверенного источника. Проще говоря, скачанный из интернета APK-подобный файл на устройство не встанет.
Второй замок — подпись. Для своих приложений компания получила сертификат источника. Подпись клиента дополняет подпись разработчика, а не подменяет её, и выполняется прямо в Маркете — внешний SDK не нужен. Практический выигрыш скромный на вид, но реальный: сборка, подпись и раздача живут в одном окне, а не в трёх.
Третий замок — версии. Вот главное. Пользователя и устройство связывают через интеграцию с LDAP: политика цепляется к группе, которая соответствует подразделению. А для технических признаков есть динамические группы: администратор задаёт условие (например, установленную версию ОС), платформа сама набирает в группу подходящие устройства. Обновился аппарат — передал новое состояние — вышел из группы. Руками никого перебирать не надо.
В собственном парке мы решаем те же задачи, что и администраторы у наших заказчиков: распространяем рабочие приложения, управляем обновлениями и помогаем пользователям.
Что поменялось по сравнению с «классическим» MDM
Старое поколение таких систем отвечало на вопрос «какой пакет накатить на устройство». Список устройств был списком, а группа — папкой, которую кто-то ведёт вручную и забывает обновлять. Отсюда типовой бардак: на половине смартфонов висит версия, под которую новое приложение уже не собирается, и никто не знает, сколько таких.
Здесь группа превращается в запрос. Набор устройств вычисляется из их фактического состояния, а политика обновления указывает целевую версию ОС. Логика переворачивается: не «обновим всё до последнего», а «обновим тех, кому это нужно по рабочей задаче». Для бета-контура отдельно: сборка уходит на выбранные устройства, решение о старте тестирования команда принимает вместе с разработчиками ОС.
Третий слой — права публикации. Разработчики бета-программы работают в веб-консоли «Аврора Центра», но приложение после загрузки проходит модерацию администратора. Заявку на статус разработчика подают через координатора сообщества, дальше администратор регистрирует пользователя и выдаёт права в отдельном интерфейсе: человек видит нужные страницы и может сделать ограниченный набор действий. Ровно тот механизм, которого не хватает компаниям с подрядчиками на внешних устройствах.
Кому это нужно и как применить
Шаблон ложится на любой парк, где устройства различаются по задачам, а не только по модели. Типовые сценарии:
| Задача | Чем закрывается |
|---|---|
| Тестовые и рабочие устройства в одном парке | Политика обновления с целевой версией ОС + динамические группы |
| Запрет «софта с форумов» | Список доверенных источников, блокировка пакетов без подписи |
| Свои приложения без внешней подписи | Сертификат источника, подпись клиента в Маркете |
| Подрядчики и внешние разработчики | Веб-консоль с ограниченными правами + модерация публикации |
| Разные требования по подразделениям | Интеграция с LDAP, политики на группы |
Среднему бизнесу из этого ближе всего два пункта: контроль источников и разделение версий. Первый снимает половину обращений в поддержку, второй — половину сюрпризов при выкатке обновлений.
Где подвох
Кейс написан вендором про вендора. Все примеры относятся к ОС Аврора — перенести схему на смешанный парк Android и iOS по этому тексту не получится. Цифр экономии, сроков внедрения, стоимости лицензий и трудозатрат админа в публикации нет. Внедрение упирается в LDAP: если у вас нет каталога с группами, половина красоты потребует ручной сборки. Модерация публикаций — ручной шаг, и на большом потоке релизов он станет узким местом. И главное: динамические группы работают на данных, которые устройства передали на сервер. Задержка между обновлением аппарата и пересборкой группы — вопрос, на который в тексте ответа нет.
Брать или подождать
Брать, если у вас парк на ОС Аврора, есть LDAP и хотя бы десять устройств живут в тестовом режиме рядом с рабочими. Схема из кейса собирается почти без доработок.
Подождать, если парк разнородный по платформам или администрирование держится на одном человеке без каталога пользователей. Сначала каталог и учёт устройств, потом политики.
Не брать как замену инвентаризации. Платформа не расскажет, какие устройства у вас есть, если их никто не заводил.
Что сделать на этой неделе
- Выгрузите фактический список устройств и версий ОС. Без него любой MDM бесполезен.
- Разделите парк на два контура: рабочая стабильная версия и тестовая сборка.
- Составьте перечень доверенных источников приложений — по одному на категорию софта.
- Проверьте, есть ли в вашем каталоге (LDAP или аналоге) группы, совпадающие со структурой подразделений.
- Назначьте ответственного за модерацию публикаций и пропишите, кто выдаёт права разработчика.
- Заведите одно правило: пакет без подписи доверенного источника на устройство не попадает.
Вердикт
Кейс полезен не продуктом, а порядком действий. Вендор честно показал: сначала каталог и учёт, потом группы и политики, и только затем раздача приложений. Кто попробует наоборот, получит зоопарк версий с красивой консолью поверх.
FAQ
Это замена МДМ для Android? Нет. Всё описанное — про ОС Аврора.
Сколько стоит? В публикации цены нет. Считайте по числу устройств и нужным модулям, запрашивая коммерческое предложение.
Нужен ли свой отдел разработки? Нет, но нужен человек, который ведёт группы и модерирует публикации.
Что будет со старым устройством после сброса? Его придётся подключать заново — в бета-программе с такими обращениями и сталкиваются.
Если у вас в компании больше двух версий ОС на рабочих устройствах и никто не может назвать точное число — начните с первого пункта чек-листа. Остальное подождёт до понедельника.