Промышленные смартфоны на «Гиперком-У» и ОС Аврора: что это меняет для MDM в российском ритейле
Российская компания «АИСА ИТ-Сервис» представила предсерийные образцы защищенных промышленного смартфона и планшета, построенных на отечественном процессоре К1892ВМ21Я «Гиперком-У» от НПЦ «ЭЛВИС». Устройства функционируют под управлением российской мобильной ОС «Аврора», а их ключевой целевой аудиторией являются предприятия с критической информационной инфраструктурой. По данным [iXBT News](https://www.ixbt.com/news/2026/09/29/439118-v-rossii-sozdali-neubivaemyi-smartfon-na-otecestvennom-processore-giperkom-u.html), появление таких аппаратно-программных платформ напрямую затрагивает стратегии управления мобильным парком (MDM) в крупных российских компаниях.
Что произошло
Событие заключается не просто в выпуске очередного гаджета, а в формировании законченной экосистемы доверенного мобильного рабочего места. В основе устройств лежит система-на-кристалле К1892ВМ21Я («Гиперком-У»), которая определяет базовый уровень производительности и периферийную совместимость. Программная составляющая — операционная система «Аврора», сертифицированная ФСТЭК России по высоким классам защиты информации. Это означает наличие встроенных механизмов контроля целостности, мандатного контроля доступа и изоляции данных, которые работают на уровне ядра системы.
Для интегратора или руководителя ИТ-отдела важно понимать технические границы этой платформы:
Аппаратный корень доверия: Процессор предоставляет аппаратную базу для хранения криптографических ключей и проверки загрузчика (Secure Boot*). Любая попытка модифицировать ядро ОС или системные разделы будет заблокирована еще до старта системы.
* Специфика ОС «Аврора»: Система использует собственный графический стек и API, отличные от Android Open Source Project (AOSP). Управление устройствами осуществляется через проприетарный протокол взаимодействия с сервером управления, который должен поддерживать нативный клиент Авроры.
Форм-фактор и защита: Смартфон и планшет заявлены как промышленные, что подразумевает соответствие стандартам ударопрочности (например, MIL-STD-810H) и пылевлагозащиты (IP67/IP68*). Для ритейла это снижает стоимость владения за счет уменьшения числа замен разбитых или залитых жидкостью терминалов сбора данных (ТСД).
Ключевым отличием является то, что платформа изначально проектировалась для работы в составе единого доверенного контура, где устройство, ОС и канал управления верифицированы производителем и регуляторами.
Почему это важно
Для российского ритейла, особенно сегмента FMCG, DIY и e-commerce, парк мобильных устройств исчисляется тысячами единиц. Традиционно эти задачи решались либо специализированными ТСД на базе урезанного Android, либо корпоративными смартфонами известных брендов. Появление отечественной связки процессор-ОС создает новую реальность, продиктованную требованиями безопасности и импортозамещения.
Смежные кейсы и риски 152-ФЗ
Ритейл оперирует огромными массивами персональных данных клиентов (программы лояльности, история покупок, биометрия в некоторых сценариях). Использование устройств на базе иностранных чипсетов и ОС всегда несет риск неконтролируемой передачи телеметрии или наличия недекларированных возможностей (НДВ). Переход на платформу «Гиперком-У» + «Аврора» позволяет выстроить контур обработки ПДн, соответствующий требованиям законодательства о локализации и защите критической информационной инфраструктуры (КИИ), к которой могут быть отнесены логистические хабы крупных сетей. Документация по настройке политик соответствия доступна в разделе /docs/152-fz нашего ресурса.
Реальные сценарии применения в ритейле
1. Работа курьеров последней мили. Устройство может выступать в роли защищенного средства связи и подписи документов. Благодаря поддержке отечественных крипропровайдеров (вроде КриптоПро CSP), курьер сможет подписывать акты приема-передачи усиленной квалифицированной электронной подписью (УКЭП) непосредственно на устройстве, используя ГОСТ-алгоритмы.
2. Складская логистика. Планшет на «Авроре» становится терминалом для WMS-систем. Отсутствие фоновых процессов Google Mobile Services (GMS) повышает автономность батареи и исключает несанкционированное потребление трафика обновлениями сервисов Google, что критично в зонах со слабым покрытием Wi-Fi/GSM.
3. Информационные киоски (Customer Assistance). Смартфон, закрепленный на стойке выдачи заказов, работает в режиме Kiosk Mode. На платформе «Аврора» этот режим реализуется жестче, чем на Android, блокируя доступ не только к шторке уведомлений, но и к любым сервисным меню на уровне прошивки.
Главный вызов для ИТ-руководителей сегодня — интеграция этих устройств в существующие ITSM/MDM процессы. Если ваша инфраструктура построена исключительно на классических решениях для Android/iOS без поддержки протокола SCEP/SCEP Gateway или SCIM для синхронизации пользователей из Active Directory, развертывание парка на «Авроре» потребует дополнительных шлюзов. Настройка сквозной аутентификации описана в документации по адресу /docs/scim.
Что делать
Интеграция новой аппаратной платформы требует пересмотра стандартных эксплуатационных процедур. Ниже приведен пошаговый план действий для подготовки инфраструктуры к приему первых партий промышленных смартфонов на «Гиперком-У».
Шаг 1. Аудит сервера управления (EMM/UEM)
Необходимо убедиться, что используемое вами решение класса Enterprise Mobility Management поддерживает управление устройствами под управлением ОС «Аврора». Это проверяется по наличию соответствующего плагина или профиля вендора EMM. Например, если вы используете Komendant MDM, следует проверить актуальную матрицу совместимости в общей документации (/docs/). Типичная ошибка — пытаться отправить стандартную ADB-команду (adb shell) на такое устройство; она будет отклонена, так как интерфейс отладки отключен на уровне политики сборки ОС.
Шаг 2. Проектирование профилей конфигурации (Policies)
Политики для «Авроры» пишутся иначе, чем JSON/XML-конфиги для Android Enterprise. Вам потребуется создать новые шаблоны:
* Wi-Fi Policy: Указание SSID, типа шифрования (WPA2/WPA3-Enterprise) и привязки к сертификату клиента (EAP-TLS). Пути к сертификатам в файловой системе Авроры обычно находятся в директории /data/system/users/0/cacerts/, но ручное копирование запрещено политикой.
* VPN Policy: Настройка отечественного VPN-шлюза (ViPNet, Континент) с использованием алгоритмов ГОСТ Р 34.10-2012.
* Application Policy: Белый список приложений. Поскольку установка APK невозможна, разрешать нужно только пакеты из репозитория Авроры или вашего внутреннего магазина приложений (App Store), интегрированного с EMM.
Шаг 3. Подготовка процесса выпуска цифровых сертификатов
Устройства должны проходить аутентификацию в корпоративной сети по сертификатам. Необходимо настроить службу сертификации (CA), например Microsoft AD CS, на выдачу сертификатов для проверки подлинности клиентов. Процесс автоматизации получения сертификата устройством настраивается через протокол SCEP (Simple Certificate Enrollment Protocol). В консоли MDM создается профиль, указывающий URL-адрес вашего NDES-сервера (Network Device Enrollment Service).
Пример логики запроса:
GET /certsrv/mscep.dll/pkiclient.exe?operation=GetCACert&message=...
Этот шаг гарантирует, что даже украденное устройство не сможет подключиться к внутренним ресурсам компании (почта, ERP, базы данных склада).
Шаг 4. Тестирование жизненного цикла устройства
Перед массовым закупом необходимо провести пилот на нескольких устройствах, эмулируя штатные инциденты:
* Потеря устройства: Отправка команды Remote Wipe. Важно проверить, очищается ли внутренняя память полностью, включая данные на уровне контроллера памяти, что характерно для доверенных исполнений.
* Компрометация пользователя: Отзыв сертификата пользователя в CA. Устройство должно мгновенно потерять доступ ко всем туннелям L2TP/IPsec или TLS-порталам.
* Обновление ОС: Проверка механизма доставки OTA-обновлений. В случае с «Авророй» обновления часто доставляются централизованно через сервер производителя ОС или ваш локальный прокси-сервер обновлений, минуя публичный интернет.
Шаг 5. Обучение персонала и изменение регламентов Helpdesk
Сотрудники первой линии поддержки должны знать, что комбинация клавиш для снятия скриншота или входа в Recovery mode на данном железе отличается от привычных Android-устройств. Следует обновить инструкции Service Desk, добавив туда специфические коды ошибок интерфейса «Аврора» и регламент первичной активации (provisioning) нового сотрудника.
Источник: https://www.ixbt.com/news/2026/09/29/439118-v-rossii-sozdali-neubivaemyi-smartfon-na-otecestvennom-processore-giperkom-u.html