Мобильный суверенитет в российском ритейле: от AOSP к управляемому парку
По данным Digital Russia, отраслевой эксперт Дмитрий Алтухов в своей новой статье анализирует, почему за четыре года инициативы по достижению мобильного суверенитета не принесли ожидаемого системного результата. Для российского ритейла, где тысячи смартфонов и ТСД (терминалов сбора данных) управляют товародвижением и кассами, этот вопрос трансформируется из геополитического в сугубо операционный. Зависимость от глобальных вендоров и сервисов Google напрямую влияет на непрерывность бизнес-процессов, стоимость владения парком и соответствие требованиям регуляторов.
Что произошло
В основе дискуссии лежит концепция построения независимой мобильной инфраструктуры на базе AOSP (Android Open Source Project). Идея заключается в отказе от сервисов Google Mobile Services (GMS), включая Google Play, Firebase Cloud Messaging (FCM) и SafetyNet Attestation, в пользу отечественных или открытых альтернатив. За последние годы были предприняты значительные усилия: созданы отечественные мобильные операционные системы (например, на базе AOSP), сформированы реестры программного обеспечения, разработаны концепции импортозамещения. Однако, как отмечает эксперт, ожидаемого массового перехода не случилось. Проблема оказалась не в создании самой ОС, а в экосистеме: отсутствии привычных приложений, сложности их адаптации, проблемах с доставкой push-уведомлений и, что критично для бизнеса, в отсутствии бесшовных инструментов централизованного управления парком устройств, не завязанных на Android Enterprise и инфраструктуру Google. В результате многие компании оказались в промежуточном состоянии: формально используя «суверенную» ОС, они сохраняют зависимость от отдельных проприетарных компонентов или сталкиваются с деградацией функциональности бизнес-приложений.
Почему это важно
Для ИТ-директора федеральной розничной сети проблема «чистого AOSP» распадается на несколько конкретных бизнес-рисков.
1. Разрыв в управлении устройствами. Стандарт де-факто для корпоративного Android — это Android Enterprise и протоколы, завязанные на сервисы Google. При переходе на «чистый» AOSP (без GMS) перестают работать привычные режимы Work Profile и Fully Managed Device в их классическом виде. Это означает, что MDM-решение теряет возможность применять политики безопасности, блокировать настройки, управлять паролями и, главное, осуществлять Zero-Touch Enrollment. Ручная настройка каждой единицы из парка в 5000+ ТСД и смартфонов кассиров экономически нецелесообразна.
2. Отказ push-уведомлений. Большинство кассовых (front-office) и складских (back-office) приложений используют FCM для мгновенной доставки данных: обновление цен, отмена чека, назначение задачи на сборку. На AOSP без GMS этот канал отсутствует. Разработчикам приходится внедрять «автостарт» и long-polling соединения, что катастрофически сказывается на заряде батареи устройств (критично для ТСД) и стабильности связи в условиях нестабильного Wi-Fi на складах.
3. Проблемы с аттестатцией и безопасностью. Механизмы SafetyNet и Play Integrity API, которые используют банковские приложения (например, для проверки подлинности устройства кассира перед авторизацией платежа) и приложения с защитой контента, на «голом» AOSP не проходят проверку. Это блокирует использование мобильных банков для юридических лиц, корпоративных мессенджеров с функциями DRM и защищенных клиентов VDI.
4. Жизненный цикл 152-ФЗ. Устройства сотрудников, работающих с персональными данными клиентов (программы лояльности, оформление кредитов), должны соответствовать требованиям регуляторов. Отсутствие централизованного MDM, способного гарантировать контроль над всем стеком ОС (включая системные компоненты AOSP), создает риски невыполнения требований приказа ФСТЭК №21 и Постановления Правительства №1119. Практический кейс — невозможность доказать отсутствие несанкционированного ПО на устройстве курьера без логов MDM, интегрированного с системой на уровне ядра ОС.
Что делать
Переход к управляемому мобильному парку на базе отечественных реалий требует архитектурного подхода, где MDM-система становится центральным элементом, компенсирующим отсутствие GMS.
- Выбор MDM с поддержкой кастомных прошивок. Необходимо решение, которое поддерживает прямое управление через AOSP Management API и проприетарные агенты, способные работать без GMS. Система должна уметь выполнять OEMConfig-подобные настройки через прямое взаимодействие с системными API производителя устройства (например, для ТСД Urovo или АТОЛ), минуя Google. Это позволяет настраивать сканеры штрихкодов, порты и поведение аппаратных кнопок централизованно. Документация по политикам (/docs/policies) должна описывать создание профилей для Kiosk Mode, которые блокируют не только выход из приложения, но и доступ к системным настройкам AOSP (включая Developer Options), даже если Google Settings отсутствуют.
- Организация собственного канала уведомлений. Вместо FCM следует развернуть альтернативный push-сервис. Практический сценарий: MDM-агент на устройстве держит постоянное TLS-соединение с сервером управления (или корпоративным MQTT-брокером). Все бизнес-приложения (касса, курьерский клиент) подписываются на локальный брокер. При получении команды от сервера MDM ретранслирует ее приложениям. Это требует доработки SDK приложений, но обеспечивает доставку уведомлений за 1-2 секунды при сохранении энергоэффективности.
- Внедрение режима Kiosk Mode на уровне прошивки. Для кассиров и курьеров необходимо использовать Single App Kiosk или Multi-App Kiosk. В MDM (/docs/) настраивается политика, которая после Enrollment устройства выполняет ADB-команду (или ее аналог через OEM API) для установки приложения администратором устройства (Device Owner).
> Пример команды для закрепления пакета com.retail.cashier:
> dpm set-device-owner com.retail.mdm/.admin.DeviceAdminReceiver
> adb shell am start -a android.intent.action.MAIN -n com.retail.cashier/com.retail.ui.MainActivity
Далее MDM-политика блокирует кнопку «Домой», шторку уведомлений и установку APK из неизвестных источников на уровне системного компонента PackageManager.
- Реестр доверенных приложений и Whitelisting. Поскольку Google Play Protect отсутствует, контроль за целостностью ПО ложится на MDM. Необходимо создать внутренний репозиторий приложений. MDM настраивается на политику «белого списка» (Application Allowlist), где разрешен запуск только пакетов с конкретными хэшами SHA-256. Любая попытка запустить стороннее приложение или модифицированный APK блокируется агентом. Это напрямую решает задачу комплаенса с 152-ФЗ (/docs/152-fz), обеспечивая контролируемую среду.
- Синхронизация с IdM/AD через SCIM. Для управления доступом сотрудников к корпоративным приложениям на мобильных устройствах следует использовать протокол SCIM (/docs/scim/). При создании/блокировке учетной записи кассира в Active Directory или отечественном IdM-решении, SCIM-шлюз автоматически передает команду в MDM на назначение/отзыв профилей и приложений. Это исключает человеческий фактор и задержки при увольнении персонала.
- Работа с вендорами ТСД. При закупке нового парка устройств необходимо в ТЗ прописывать требование на предоставление OEM SDK для интеграции с MDM и возможность подписания прошивки корпоративным сертификатом. Это позволит реализовать Verified Boot с доверенным ключом компании, гарантируя, что устройство загрузит только немодифицированную системную сборку, одобренную ИТ-департаментом.
Источник: https://d-russia.ru/na-chestnom-slove-i-na-odnom-aosp.html