Привет, Хабр! Я Олег Ассур, технический директор SafeMobile. Управление мобильными устройствами или MDM – тема, мимо которой проходят не только лишь все, пока в компании не появляется сто, тысяча или пятьдесят тысяч корпоративных телефонов, которыми вдруг надо управлять централизованно. Я в ней с 2012 года: писал MDM клиент для джейлбрейкнутых iOS, поднимал управление iOS, Android и Windows, прошёл с заказчиками все пять стадий принятия российского ПО и дорос от разработчика до технического директора.
Эта статья выросла из моего прошлогоднего доклада на SysAdminConf (видеозапись будет в конце), но это не расшифровка, а отдельный разбор: как устроено управление телефонами под капотом, кто и зачем придумал нынешние технологии, почему все они до сих пор работают по правилам, заданным Apple в 2010, и почему собирать свой MDM в России в 2026 – затея на любителя. Если интересно, что происходит между «раздали сотрудникам телефоны» и «теперь ими кто-то управляет» – добро пожаловать под кат.
Рынок корпоративной мобильности 2010-х
Вернёмся в 2014 год – только-только вышли iPhone 5 и Android 4.4 KitKat (тогда Google ещё называл версии Android в честь сладостей). В этом же году проходят две сделки, по которым видно, сколько денег было в управлении телефонами.
VMware покупает AirWatch за полтора миллиарда (!) долларов (в сегодняшних деньгах это около 2,1 млрд), а MobileIron выходит на NASDAQ с оценкой порядка 800 миллионов. Откуда такие суммы в MDM?
Расчёт был такой: корпоративных мобильных устройств станет в разы больше, чем ноутбуков и десктопов, и ИТ-периметр под них надо перестраивать. За эту перспективу и платили. Причём покупали далеко не стартапы:
К 2014 AirWatch существовал уже 11 лет. Они начали в 2003 как система мониторинга Wi-Fi-сетей и развернулись в сторону управления устройствами на волне смартфонов позже.
MobileIron начали в 2007 и сразу строили продукт вокруг мобильности.
То есть к моменту появления реального рынка это были зрелые компании с историей.
В России тех же лет ни IPO, ни миллиардных сделок не было – были штучные, но показательные проекты:
2013, Газпром. Тендер на мобильное рабочее место Председателя Правления Газпрома. Доступ к ключевым показателям эффективности с планшетов. Проект обошёлся примерно в 115 миллионов рублей. Любо и дорого не из-за планшетов и MDM: удалённый доступ к чувствительным данным в такой закрытой структуре – это отдельная стойка оборудования, криптошлюзы и серверная обвязка, которые составляют основную сумму.
2016–2017, Сбербанк. Одна из крупнейших закупок мобильных устройств в стране: по разным тендерам приобрели несколько десятков тысяч iPad на сумму около полутора миллиардов рублей. За 2010-е Сбер дважды сменил MDM вендора и пришёл к нам только в 2023. Зато уже без иллюзий и с чётким пониманием, что именно ему нужно от MDM.
2016, Почта России. Около 8 тысяч Android смартфонов для почтальонов, преимущественно на Android 5.1. SafeMobile управляет этими устройствами до сих пор.
Конечно, масштабы и деньги не сравнить. Кроме того, в отличие от западного рынка, где требования формируются массовым спросом, у нас было фаталити: и рынок меньше, и клиенты «тяжелее».
Что делать, когда штатного управления ещё нет
Эту часть истории в индустрии российских мобильных решений вспоминать не любят.
Штатный способ управлять Android в корпоративной среде – это Android Enterprise. Но есть нюанс: Google выпустил его только в 2015. А если MDM нужен раньше?
Похожая проблема была с Apple. Управление iOS с самого начала требовало наличия в контуре управления облака Apple. И это с самого начала не нравилось крупным российским заказчикам.
Короче, если вы в 2014 году решили сделать MDM для Android или iOS в РФ – у меня есть плохие новости для вашей будущей репутации ?
Единственный способ управлять мобильными устройствами в 2014 в РФ – это рут и джейлбрейк. VPN с ГОСТ шифрованием, кстати, тоже работал только так. В своё оправдание могу сказать, что после взлома устройство не оставалось взломанным – мы делали всё возможное, чтобы убрать с устройства последствия взлома и не дать его сделать другим. Даже банковские приложения, которые отказывались работать при наличии джейла, на таких устройствах работали.
Джейлбрейк и рут давали нам возможность управлять устройствами с помощью приватных API. На практике это вечная гонка. Приватные API не документированы и меняются от версии к версии: что работало на прошлой версии ОС, на новой может отвалиться без предупреждения.
Выглядела гонка примерно так. Вышел новый iOS. Через 3–6 месяцев появляется непривязанный джейлбрейк (непривязанный – это который сохраняется после перезагрузки устройства). Ещё 3–6 месяцев уходит на то, чтобы подстроить решение и выпустить новую версию MDM. К этому моменту Apple выпускает следующий iOS, и всё начинается заново ?
Репутация от всего этого страдает. Даже через несколько лет после перехода на штатные Android Enterprise и Apple MDM нам ещё долго припоминали ошибки молодости. Отмыться от джейлбрейка оказалось куда сложнее, чем его внедрить. Но тогда другого выбора не было.
Технологии управления устройствами
Apple придумал в 2010, удивительно, кто первым повторил
Фундамент всей отрасли заложил Apple в 2010 году, и по этой схеме до сих пор работают почти все производители, по крайней мере на Западе.
Схема такая. В операционной системе есть один штатный агент управления – его пишет и поддерживает сам разработчик ОС. Наружу агент отдаёт стандартный протокол, по которому им управляет внешний сервер MDM. Сервер MDM пишет отдельный разработчик. Например, SafeMobile ?
Особенность iOS. Устройство на сервер управления по своей инициативе не приходит. Чтобы оно подключилось, сервер должен доставить ему уведомление через облако Apple – APNS (Apple Push Notification Service). В теле уведомления нет никаких MDM команд, только сигнал «эй ты, подключись к MDM серверу, там для тебя что-то есть». Подробнее механику управления iOS мы разбирали в одной из наших прошлых статей.
С APNS есть ещё такой прикол: чтобы отправить пуш, MDM серверу нужно открыть исходящий доступ к подсети Apple по маске /8 – это 16 миллионов адресов. Сетевики от такого, порой, седеют, но иначе пуши не ходят.
Подход Apple стал стандартом, потому что он удобен почти всем:
MDM вендорам не нужно разрабатывать и поддерживать клиентский софт для управления устройствами на разных платформах.
Производителям ОС может быть дешевле разработать свой эталонный MDM агент, чем поддерживать разнообразные комбинации вызовов MDM API, которые сделают у себя MDM вендоры.
Производителям ОС так проще доставлять заказчикам новые фичи. Тут объясню на примере. Допустим, вы – Apple, и вы решили, что ваши новые устройства будут лучше продаваться благодаря какой-то корпоративной фичи. Чтобы доставить эту функцию заказчикам, вам может быть нужно, чтобы её реализовали в MDM. В результате вам надо продавать фичу сразу двум категориям покупателей – заказчикам и MDM вендорам. Эталонный агент и стандарт, по которому любой нормальный MDM подхватывает новые фичи почти без доработок, снимают эту проблему. К этой мысли вернёмся на OEMConfig ниже по тексту ?
Удивительно, но факт – вторым, кто реализовал этот механизм, стал не Google, а Microsoft. В 2013 вместе с выходом Windows 8.1 (кто-то ещё помнит эту версию?) в мелкомягкой операционке появился встроенный MDM агент управления со своим протоколом управления. Логика его работы такая же, как у Apple, но с одним отличием: облако Microsoft не обязательно. Windows устройства умеют в поллинг – устройство само приходит на сервер с заданным интервалом за политиками и обновлениями, без облачных пушей.
Спасибо Samsung за Android Enterprise
В 2012 Samsung представляет SAFE (Samsung Approved For Enterprise): набор корпоративных функций поверх обычного Android – управление через сторонние MDM, аппаратное шифрование и всё такое, что потом стало Samsung Knox, когда в него в 2013-2014 докатили Knox контейнеры.
Samsung первым сделал внятный SDK для управления своими устройствами, когда у обычного Android для бизнеса почти ничего не было. Часть функций этого SDK (например, Knox контейнеры) требовали платной лицензии, на которой Samsung планировал заработать. Если бы не Google…
В 2015 Google на своём Google I/O благодарит Samsung за вклад в развитие Android на корпоративном рынке и заявляет о создании собственной платформы Android Enterprise практически с тем же набором функций, но бесплатно и на всех Android устройствах. С тех пор в Android есть Device Owner – это когда MDM управляет всем устройством, а в 2018 Google представил свой аналог Knox контейнеров – рабочие профили. Это привело к тому, что большинство функций Knox с 2021 года стали бесплатными.
Если проводить аналогию с Uber, который сначала монополизировал рынок такси с помощью низких цен, а потом вернул цены обратно, но забрал всю выручку себе, может показаться, что со временем использование функций Android Enterprise станет платным. Надеюсь, что этого не случится.
Но вернёмся к технологии эталонного MDM агента. В 2017 Google предлагает свою реализацию – облачный Android Management API. Особенность технологии Google: устройство не приходит на MDM сервер управления напрямую – команды идут через облако Google, и отвечает серверу MDM тоже облако, а не устройство. Может получиться ситуация как в мемах про Коневского: устройство потеряли, его надо сбросить, облако Google отчиталось о сбросе устройства, но … сбрасывать его, конечно, никто не собирался.
Технологии, которые облегчают админу жизнь
OOBE – Out-of-Box Experience
Во-первых, это прикольно звучит: «ууу-би».
Во-вторых, это удобно. Идея технологии такая: сотрудник достаёт устройство из коробки, включает и … оно автоматически регистрируется в MDM. Удалить MDM нельзя, а после сброса устройства к заводским настройкам восстанавливается опять. Красота.
Какие технологии в этом помогают:
Apple Business Manager (раньше – Device Enrollment Program). Доступен с 2014 года. В России не был доступен никогда.
Samsung Knox Mobile Enrollment. Доступен с 2015 года. В России доступен. Мы поддерживаем – нас даже Samsung проверил, вот наша страница на их портале.
Zero-Touch Enrollment от Google. Появился в 2018 году. Российским MDM недоступен ?
Все эти технологии работают примерно так:
Дистрибьютор устройств отмечает в облаке производителя, что такой-то пул устройств принадлежит такому-то заказчику.
Заказчик настраивает, к какому MDM эти устройства подключить и по какому адресу этот MDM расположен.
Устройство при включении обращается к своему облаку, узнаёт, что оно не просто так устройство, а устройство конкретного заказчика, устанавливает MDM, передаёт ему настройки и … Профит!
??Есть хорошие новости. Российские производители устройств начали повторять зарубежные практики OOBE! Расскажем об этом подробнее в одной из следующих статей.
Декларативное управление (DDM)
Раньше iOS устройства без пуша от APNS на связь с MDM не выходили. В 2021 Apple представил технологию декларативного управления (DDM, declarative device management), и это немного изменилось, но несильно.
Теперь устройства могут иногда подключаться к серверу сами, но только чтобы уведомить об изменениях. Доставка команд управления и новых политик всё так же требует APNS.
Главная польза от DDM – сложнее проворонить события с устройства. Раньше об изменениях можно было узнать только по результатам периодического опроса. Если на устройстве происходили обратимые события, MDM не мог о них узнать. Например, если пользователь переустановил какое-то приложение, пока сервер его не опрашивал. Теперь устройство само копит события и отправляет их на сервер.
В остальном DDM просто неминуем. Apple не очень быстро, но уверенно его насаждает. Например, в прошлом году Apple предупредил, что управление обновлениями iOS будет доступно только в DDM и, начиная с iOS 27, уже этой осенью это станет реальностью. Если ваш MDM не реализует DDM в этом году, управление обновлениями iOS станет вам недоступно. Мы планируем успеть ?
AppConfig
Объясню на примере: у вас тысяча устройств и корпоративное приложение с захардкоженным адресом сервера. Адрес поменялся. Что вы делаете? Правильно – собираете новый билд и раскатываете его на устройства. Тысяча устройств по 50 МБ – почти 50 ГБ трафика ради изменения одной строки. Можно по-другому? Можно.
В 2013 Apple предложил стандартный механизм, с помощью которого MDM может доставить настройки прямо в приложение. Приложению достаточно поддержать стандартный механизм, и тогда оно сможет получать настройки от любого MDM. В 2016 году Google реализовал аналогичный механизм в Android.
Эту технологию принято называть AppConfig по названию сообщества, которое организовали вокруг неё Google, Apple и несколько крупных поставщиков корпоративного мобильного софта.
OEMConfig
А что если производители устройств будут делать свои MDM плагины, которые позволят вам использовать новые функции без доработки ваших MDM решений? Читается как питч какого-то стартапа. Но это уже работает на практике.
Логика такая. MDM плагин принимает настройки от вашего MDM с помощью AppConfig и активирует дополнительные функции. Такие плагины есть у Samsung, Zebra, M3 Mobile и ряда других производителей.
Формат AppConfig для MDM плагинов обычно достаточно сложный. Для него даже отдельное название придумали – OEMConfig. Мы поддерживаем его, начиная с SafeMobile 16. Налетай, торопись ?
Стоит ли в 2026 делать свой MDM в России
Проведу аналогию. Помните, как из России уходил Miro? Сразу же появился десяток-другой сервисов-досок. Окупит ли хотя бы половина из них вложения создателей? Сомневаюсь – рынка такого размера у нас нет. Доску хотя бы можно встроить в платформу для совместной работы и так размыть затраты. С MDM сложнее, и причин не начинать его разработку немного – всего три. Но каких.
Кадры. Найти людей, которые умеют разрабатывать MDM, а не просто им пользоваться, тяжело. Область знаний узкая. Одно дело отлично внедрить Tesla в энтерпрайзе, другое – встать главным конструктором на завод и повторить её к концу года. Наша главная ценность – команда, которую удалось собрать и удержать. Многие работают с нами уже больше 10 лет.
Рынок схлопывается. В 2022 достижимый рынок расширился, но за четыре года основные крупные заказчики уже выбрали, на какое решение переходить. Пока добежишь со своим продуктом, свободных заказчиков может и не остаться.
Длинный цикл продаж. MDM – это не жвачка у кассы. Его не покупают импульсивно: его тестируют, пилотируют и внедряют иногда не один год. И чем крупнее заказчик, тем дольше. Для нового игрока это прямой риск кассового разрыва.
Два честных контрпримера:
Инхаус-продукт. Когда у компании несколько тысяч разработчиков, MDM могут написать «до кучи». История рабочая, но вывести такой продукт на рынок обычно сложно – он соткан из кастомных бизнес-процессов одного заказчика, и наружу фактически продаются эти процессы, а не продукт. А процессы-то у всех разные…
Нишевое решение. Например, сделай режим киоска только для Android и продавай его в два раза ниже рынка. Сколько-то на этом заработать можно, но дальше нужно масштабироваться и закрывать больше болей заказчика, иначе есть риск, что не хватит денег на поддержку действующих клиентов.
Взгляд в будущее
Если бы меня спросили, что будет с рынком MDM в России в течение пяти лет, я бы, наверное, ответил так:
Кто-то соберёт российский AirWatch. Импортозамещение с 2022 года – это купить вместо одного продукта несколько российских, которые не дружат между собой и плохо интегрируются в общую ИТ-инфраструктуру. Это общая боль, а не конкретно MDM. За прошедшие четыре года лидеры рынка смогли достаточно развиться, чтобы задуматься над сложными болями заказчиков, утолить которые могут только несколько продуктов вместе. Например, VPN для мобильных устройств, который обеспечивает доступ в корпоративную сеть только для разрешённых приложений и только при успешной проверке соответствия устройств с помощью MDM. Неужели я о многом мечтаю?
ИИ-помощники снимут рутину с администраторов. Например, такую. Администраторы решают задачи бизнеса. Когда бизнес ставит задачи, он не задумывается об ограничениях. Поэтому первая задача админа – это разобраться, можно ли в принципе решить задачу. Для этого нужно почитать документацию на MDM и на Android / iOS / Аврору (нужное подчеркнуть), спросить MDM вендора, поругаться с ChatGPT. Бывает, этот процесс нужно повторять несколько раз. В горизонте пяти лет такая рутина перейдёт с Федота на ИИ-копилота.
Вместо вывода
За последние четырнадцать лет смартфоны и технологии управления ими прошли длинный и ухабистый путь. Мы были рядом, поэтому нам есть что вспомнить и что рассказать, и мы готовы делиться этой экспертизой.
Если вам нужен трезвый и практичный взгляд на корпоративную мобильность – от выбора схемы управления до подводных камней внедрения, напишите нам на sales@safe-mobile.ru с ключевым словом «вернитемой2012», и мы поможем разобрать вашу задачу. А вот запись исходного доклада – для тех, кто хочет посмотреть, как он звучал вживую.