Локальные приложения в RuStore: новые возможности и вызовы для MDM-стратегии ритейла
По данным [iXBT News](https://www.ixbt.com/news/2026/09/09/ot-kaliningrada-do-vladivostoka-cislo-regionalnyx-prilozenii-v-rustore-za-god-vyroslo-vtroe.html), за последний год количество приложений от региональных разработчиков в российском магазине RuStore увеличилось втрое, достигнув 9 тысяч. Наибольшая концентрация таких локальных сервисов наблюдается в Новосибирской области, Краснодарском и Приморском краях, а также в Калининградской и Иркутской областях, при этом по абсолютному числу лидируют Москва и Санкт-Петербург. Этот стремительный рост региональной разработки напрямую затрагивает ИТ-инфраструктуру федеральных розничных сетей, эксплуатирующих тысячи мобильных устройств на Android.
Что произошло
Трехкратный рост каталога до 9 тысяч приложений — это не просто статистика магазина, а качественное изменение ландшафта корпоративной мобильности. Речь идет о появлении множества узкоспециализированных инструментов: логистических агрегаторов для местных доставок, систем лояльности с привязкой к конкретным городам, приложений для управления выездными бригадами (монтажники, курьеры) и клиентских сервисов, интегрированных с региональными службами. Для крупной торговой сети это означает, что парк корпоративных смартфонов и планшетов все чаще будет сталкиваться с программным обеспечением, разработанным вне стандартных циклов крупных вендоров (vendor-циклов). Такие приложения могут иметь нестандартные требования к разрешениям, использовать проприетарные методы обмена данными или быть неоптимизированными с точки зрения потребления ресурсов устройства. Факт географической концентрации указывает на то, что региональные филиалы будут инициировать запросы на установку специфичного софта, создавая теневые ИТ-процессы (Shadow IT) внутри периметра компании.
Почему это важно
Для российского ритейл-ИТ, управляющего парком из тысяч Android-устройств через MDM/EMM, этот тренд несет как операционные выгоды, так и серьезные риски безопасности и управляемости.
Во-первых, возникает проблема фрагментации доверия. В отличие от глобальных решений, каждое из 9000 новых приложений имеет своего автора. Проверка их на наличие вредоносного кода, бэкдоров или несанкционированного сбора данных ложится на службу ИБ. Если сотрудник филиала в Новосибирске установит местный навигационный сервис, который требует доступ к журналу звонков и СМС для "улучшения качества обслуживания", это создаст прямую дыру в безопасности персональных данных клиентов и сотрудников, нарушая нормы 152-ФЗ. Использование несертифицированного ПО на устройствах, имеющих доступ к CRM или кассовому контуру, недопустимо.
Во-вторых, растет нагрузка на службы поддержки. Приложения от небольших команд часто нестабильно работают с новыми версиями ОС (например, Android 14/15), вызывая повышенное энергопотребление, конфликты с фирменными оболочками ТСД (Honeywell, Zebra) или некорректную работу с периферией (сканерами штрихкодов, мобильными принтерами). Это ведет к простоям полевого персонала.
В-третьих, усложняется соблюдение требований регуляторов. Если приложение регионального разработчика обрабатывает данные покупателей, компания должна убедиться, что серверная часть этого сервиса входит в реестр отечественного ПО Минцифры или соответствует требованиям по локализации данных. Игнорирование этого факта может привести к штрафам при проверке Роскомнадзором. Схожие кейсы уже наблюдались при внедрении отечественных ОС, где совместимость бизнес-софта была главной головной болью, что подробно разбирается в контексте перехода на Аврору /docs/aurora.
Наконец, существует риск неконтролируемого распространения. Без централизованной политики сотрудники начнут обмениваться APK-файлами полезных "местных" утилит через мессенджеры, полностью выводя свои устройства из-под контроля корпоративной системы управления.
Что делать
Реакция на экспансию региональных приложений должна быть проактивной и строиться на жестких политиках MDM и процессах безопасной доставки софта. Просто запретить установку всего извне нельзя — это ударит по операционной эффективности филиалов.
1. Формирование внутреннего частного репозитория. Необходимо поднять внутренний каталог одобренных приложений (Enterprise App Store). Вместо того чтобы разрешать сотрудникам искать софт в публичном RuStore, ИТ-департамент должен выстроить процесс:
- Заявка от филиала на нужное региональное приложение.
- Автоматизированный или ручной скан APK-пакета средствами вроде Tenable Nessus, Kaspersky Sandbox или встроенных антивирусных модулей MDM на предмет уязвимостей и трекеров.
- Юридическая проверка разработчика на соответствие 152-ФЗ и реестру Минцифры.
- При успешной проверке — подпись корпоративным сертификатом и публикация во внутреннем каталоге. Для автоматизации можно задействовать протокол SCIM /docs/scim для синхронизации списков доступа к приложениям с группами пользователей в Active Directory.
2. Настройка политик Managed Google Play и блокировок. На уровне MDM-политики (/docs/policies) необходимо реализовать сценарий Android Enterprise:
- Перевести устройства в режим Work Profile или Fully Managed.
- Включить «Белый список» (Allowlist) приложений. По умолчанию заблокировать установку из всех неизвестных источников (
adb shell settings put global install_non_market_apps 0). - Добавить RuStore в список разрешенных только если он прошел аудит и управляется через MDM как одобренный магазин. Однако предпочтительнее транслировать нужные пакеты через Managed Google Play, даже если они там неофициально присутствуют, используя функцию добавления частных приложений (Private Apps), которую поддерживает большинство современных UEM-решений.
3. Применение контекстных ограничений (Geofencing и Compliance). Используйте геолокацию для динамического изменения набора доступных приложений. Если курьер находится вне зоны своего региона (определяется по координатам или IP-адресу корпоративной VPN), MDM должен автоматически скрывать или отключать ресурсоемкие региональные сервисы, оставляя только базовый набор (навигация, связь, кассовый интерфейс). Настройте правила комплаенса: устройство получает доступ к внутренней сети только если установленная версия ОС >= 13 и отсутствуют привилегированные права (root/jailbreak).
4. Контроль разрешений на лету. Для критичных приложений (включая одобренные региональные) применяйте принудительную настройку разрешений через команды MDM. Например, для пакета com.local.logistics.app необходимо явно отозвать ненужные полномочия:
adb shell pm revoke com.local.logistics.app android.permission.READ_SMS
adb shell pm revoke com.local.logistics.app android.permission.READ_CALL_LOG
Эти команды должны быть частью скрипта пост-инсталляции в профиле MDM, гарантируя, что приложение не получит лишнего доступа после обновления.
5. Мониторинг производительности. Включите сбор телеметрии через MDM: уровень заряда, температура батареи, использование CPU каждым пакетом. Создайте алерт на аномальное поведение типовых рабочих инструментов. Если новое региональное приложение начинает потреблять более 15% батареи в фоне, система должна уведомить администратора для расследования конфликта версий или утечки памяти.
Источник: https://www.ixbt.com/news/2026/09/09/ot-kaliningrada-do-vladivostoka-cislo-regionalnyx-prilozenii-v-rustore-za-god-vyroslo-vtroe.html