Первые 60 минут MDM бесплатно, следующие 17 лет – за свой счёт

Но когда вы решили управлять >500 устройствами (а иначе зачем вы решили делать свой MDM?), добро пожаловать в ад разработку и валидацию. Кратко о процессе: чтобы получить промышленный доступ к API, нужно выбрать один или несколько feature set, реализовать все обязательные требования и за 180 дней доказать Google, что вы не верблюд сделали всё правильно. Причём там прилично работы даже на минималках – команды, политики, управление приложениями. На круг человеко-год затрат, как нефиг делать. А то и два.

Когда требования изменят или дополнят, вам снова дадут 180 дней на разработку и валидацию. Если не пройдёте, вы и ваши заказчики потеряете доступ к AMAPI. Ничего личного. Просто Google.

Какие ещё есть риски при использовании AMAPI:

• Не работает в закрытых инфраструктурах, откуда нет доступа к облаку Google.

• На устройстве нет Google Play (сертификация прошивки вообще то денег стоит) = сомнительно, что AMAPI на нём будет работать.

• Будет ли работать во всех  регионах – непонятно. 

• Будет ли работать в России  или  доступ заблокируют вслед за Gemini – неизвестно. 

Если какой-то из рисков для вас актуален, вам предстоит написать свой MDM клиент и свой магазин приложений. С учётом различий в версиях Android, устройствах, сценариях управления личными и корпоративными устройствами, смело множьте затраты на пять. А лучше на десять.

Тем временем у вас на сервере

Вы точно хотите управлять одним устройством?

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

Устройства объединяются в группы. Условия формирования групп бывают статические (серийные номера и другие неизменяемые параметры) и динамические – геолокация, установленный софт, какие-то кастомные или вычисляемые состояния устройств…

Устройства выдают пользователям. Пользователи работают в каких-то подразделениях (OU) и входят в какие-то группы. Пользователи перемещаются между OU и группами. Иногда их увольняют. Иногда им централизованно блокируют учётные записи. И теперь всё это – ваша головная боль, потому что всё перечисленное от OU до групп и атрибутов учётных записей при блокировке может быть условием для доставки на устройство каких-то настроек или приложений.

И весь этот механизм должен работать быстро – так, чтобы 10-100К устройств могли получить обновление настроек за управляемое время, не забивая весь входной канал и не приводя к “снежному кому” нагрузки, когда устройства, которые не дождались ответа, приходят на сервер снова и заваливают сервис, который и так уже еле дышит.

В общем логика назначения и применения разных настроек на мобильные устройства, это, наверное, самая сложная часть MDM системы. Мы переписывали её практически с нуля трижды и до сих пор что-то, да, подшаманиваем. 

RBAC или ABAC – вот в чём вопрос?

Мы тоже не знали этих сокращений ?

Коротко о том, что вас ждёт. Ролевая модель, прибитая “гвоздиком” не работает, даже если вы подтверждаете её должностными инструкциями. Эти инструкции разные у разных заказчиков, они меняются со временем. Короче, без конструктора ролей не обойтись. А это недешёвая штука.

Идём дальше. 

А вдруг у вас появится заказчик с филиалами по всей стране, где есть свои айтишники. И в каждом таком филиале админу нужно дать управлять только своими устройствами. При этом система должна быть единой. Добро пожаловать в славный мир мультиарендности, в котором у каждого объекта вашей системы появится владелец, с правами которого надо считаться! По нашим ощущениям эта фича в горизонте 3-5 лет даёт 10-15% дополнительных затрат.

Вот несколько практических ребусов, которые вас ждут, чтобы вы не думали, что я просто так сгущаю краски:

1. Должен ли нижестоящий админ видеть то, что сверху назначили на его устройства? А может ли он это менять?

2. А может ли кто-то сверху создать настройки и дать нижестоящему админу только назначать их на устройства, но сами настройки не трогать? 

3. А если владелец объекта уволился, как передать владение другому?

Эти ребусы мы уже разгадали и реализовали ответы в коде. Теперь готовимся выйти на новый уровень: 

1. Фича флаги для ограничения доступа к функциям системы до RBAC. Например, чтобы продавать разные редакции продукта в зависимости от количества функций.

2. ABAC, когда разные админы видят разный набор атрибутов одного и того же объекта. Например, чтобы не показывать каким-то админам персональные данные пользователей.

Интеграции

Со временем вы поймёте, что ваш продукт не существует в воздухе – у заказчика могут быть десятки разных информационных систем и продуктов, с которыми ваша система должна будет работать.

Далее типовой джентльменский набор.

Служба каталогов

Чаще всего это мастер-система с данными о сотрудниках, группах и OU. Она же провайдер для их аутентификации и авторизации. Начав работать с ней, вы узнаете много нового о её быстродействии и особенностях исполнения LDAP запросов. Если вам повезёт также, как повезло нам, и вы встретите заказчика с  промышленным доменом с 2М пользователей и 500К групп, вы сначала не сможете подняться (не вы, конечно, а ваш продукт – но кому от этого легче?). Потом за несколько лет итеративно подберете формулу, по которой всё довольно шустро работает….

Размечтались! Вам так не повезёт, пока мы живы-здоровы. ?

А потом заказчики начнут переходить с Active Directory на другие службы каталогов и вы узнаете много нового о том, какие разные они бывают и как же вам будет не хватать мелкомягких атрибутов… Но это уже другая история.

Удостоверяющий центр

Многие заказчики строят авторизацию в корпоративных Wi-Fi сетях, почте и других информационных ресурсах на клиентских сертификатах. В этом случае задача MDM – выпустить нужные сертификаты, безопасно доставить их на устройства и, при необходимости, отозвать их, когда устройство выводится из-под управления. Сложность этой интеграции аналогична домену – раньше у всех был Microsoft CA, а теперь кто во что горазд ?

SIEM

MDM много чего знает про мобильные устройства и много чего с ними делают. Да и внутри самой MDM системы возникают типовые события безопасности – попытки несанкционированного доступа, изменение прав, политик безопасности и т.д. Поток таких событий принято сгружать в SIEM по Syslog.

А ещё…

У заказчиков бывают ITSM, порталы самообслуживания, свои разработчики, которые хотят накатывать новые сборки приложений без обращения к админам MDM и куча других кейсов, под которые вам придётся непрерывно разрабатывать разнообразные API. 

И это ещё не всё

А вы уверены, что у заказчика только Android?

Сегодня мы бегло прошлись по управлению Android. А ещё есть iOS, Аврора, Linux, да и устройств Windows прилично осталось. И всем этим надо управлять. И желательно при помощи одного решения. А деталей и нюансов у каждой клиентской платформы не на одну статью…

Как вы думаете, сколько релизов вам придётся поддерживать?

Вы выпустили новый релиз и надеетесь все на него быстро обновятся все ваши клиенты. Ага, щаз. Планета B2B живёт на других скоростях. Чтобы продать продукт крупному клиенту и внедрить его, нужен минимум год. Чтобы обновить версию, нужно от полугода – поставить на тест, испачкать тонну бумаги. Поэтому первая мысль заказчика об обновлении – “а оно мне ваще надо?” 

Мы регулярно сталкиваемся с обращениями по релизам, которые мы выпустили три и более лет назад. За это время проблемные места уже могли переписать, авторы могли уволиться, а заказчик может быть не готов обновляться. Короче, лучше сразу думайте, как будете делать бэкпорты, когда планируете архитектуру своего ПО. 

Часть команды, часть корабля

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

Чтобы не оплакивать деньги на код, который никто не знает и не может развивать и поддерживать, вам нужно, чтобы сотрудники адекватно описали принятые технические решения. Да-да, нужно беззастенчиво документировать костыли. Это тоже стоит денег, но лучше начать этим заниматься заранее, а не когда ведущий разработчик подал заявление на увольнение.

Лучшее, что может с вами случиться – если вы сформируете команду на долгие годы.  Нам и здесь повезло. В команде SafeMobile люди работают и по пять, и по десять лет. Огромное им спасибо за продукт и терпение! 

Что интересного есть у Samsung для MDM

Knox Mobile Enrollment (KME)

Представьте. Вы купили устройство, выдали его своему сотруднику. Он достал устройство из коробки, включил его и … оно автоматически подключилось к MDM. Фантастика? Нет, так уже давно работает.

У Google есть своя технология Zero Touch Enrollment, но чтобы ей воспользоваться, нужно выйти с AMAPI в прод (вернитесь в начало статьи и посмотрите – чего это стоит…). У Samsung есть аналогичная технология Knox Mobile Enrollment (KME) – ей можно пользоваться без регистрации и SMS. Точнее с регистрацией, но без обязательной валидации в течение полугода. 

Knox Service Plugin (KSP)

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

Samsung одним из первых производителей сделал такой плагин Knox Service Plugin (KSPI). Более того, последние несколько лет новые фичи сперва выкатываются в него, а уже потом становятся доступными MDM-агентам через библиотеки Knox SDK.

Спросите – а зачем эти плагины вообще делать? Потому что производители, гхм, утомились выпускать новые функции, которые никто не использует. Поставьте себя на место Samsung – запилили вы какую-то новую фичу, чтобы ваши устройства лучше продавались. Эта фича классно работает вместе с MDM. Вот только зачем производителю MDM инвестировать время и деньги в эту фичу? Он же с продажи ваших устройств не зарабатывает. Чтобы свести эти затраты в ноль, и придумали эту тему с плагинами. 

Может показаться, что при наличии плагинов не нужно дальше развивать MDM-клиентов. Мы считаем, что скорее нет, чем да. Плагины хороши, чтобы дать заказчику попробовать фичи, которых не умеет твоей агент. Но использование плагина создаёт риск, что заказчик настроит его так, что это отменит какую-то важную блокировку или запрет – случайно или нарочно. 

За этим нужно внимательно наблюдать, потому что два приложения, которые управляют одним устройством – это путь к коллизиям. А ведь админу нужно знать, какие именно настройки в результате применены на устройстве. Иначе разобраться что тут вообще, блин, происходит с этим, раз его так, устройством в уездном городе N за тысячу вёрст от ближайшего айтишника, нереально. 

В общем, тут тоже есть над чем подумать, чтобы сделать что-то юзабельное вместо ещё одного способа выстрелить себе в ногу. Есть такой анти-паттерн “да админ сам во всём этом должен разобраться”. Нет, никому он ничего не должен. Это продукт не должен представлять из себя минное поле.  

Выводы, которые сами к нам пришли

Мир MDM – бескрайний и интересный. В нём каждый год происходит что-то новое. Но, увы, этот океан краснее Красного моря. Мировой рынок поделен компаниями, которые занимаются MDM и системным администрированием 10+ лет. Рынок стабильный, но достаточно консервативный – в нём редко случаются прорывы. Поэтому нам неизвестно ни одного случая, когда из табакерки выпрыгивало новое модное решение и клало всех конкурентов на лопатки. 

Мы сами классно забустились только за последние три года, когда на российском рынке появилась возможность, которой мы воспользовались. Мы смогли занять свою нишу, только потому что за 10++ лет не растеряли экспертизу, команду и к 2022 году имели лучший базовый продукт из доступных на рынке. Но главное: мы бежим по плану уже 17 лет, а остальные по вдохновению ?.

P.S. Если интересно, как MDM выглядит со стороны инвестора, налетайте на свежую статью нашего фаундера. Короткий вывод: если хотите в 2026 создать MDM и заработать, лучше обратите внимание на облигации федерального займа.