«Правило двух ОС» для реестра Минцифры: год отсрочки и новая реальность для ритейл-ИТ
По данным D-Russia.ru, Минцифры опубликовало проект постановления, который переносит на один год срок вступления в силу требования о совместимости реестрового программного обеспечения с двумя доверенными операционными системами. Документ также вносит изменения в правила ведения реестра отечественного ПО и перечня доверенного ПО, что напрямую затрагивает планы цифровой трансформации в российском ритейле.
Что произошло
Опубликованный для общественного обсуждения проект постановления Минцифры вносит несколько ключевых изменений в регулирование реестра отечественного ПО. Главное из них — перенос на один год даты, с которой программное обеспечение должно быть совместимо как минимум с двумя доверенными операционными системами для включения в реестр. Ранее это требование создавало жёсткий дедлайн для вендоров, вынуждая их в срочном порядке портировать и тестировать свои решения.
Помимо отсрочки, проект корректирует и сами правила ведения реестра. Хотя полный текст документа требует детального изучения, изменение касается фундаментального критерия «отечественности». Ранее фокус был в основном на бенефициарах и месте разработки, теперь же техническое требование к совместимости становится центральным элементом. Это означает, что для сохранения статуса «реестрового» разработчикам недостаточно просто заявить о планах по портированию — им необходимо будет предоставить доказательства работоспособности своего ПО на двух и более доверенных платформах. Список этих платформ, в свою очередь, регулируется правилами ведения перечня доверенного ПО, которые также обновляются данным проектом. Таким образом, ведомство создаёт более сложную, но, по замыслу, более устойчивую экосистему, где статус в реестре подтверждает не только юрисдикцию разработчика, но и реальную техническую независимость продукта.
Почему это важно
Для ИТ-руководителей в российском ритейле эта новость имеет двойственное значение. С одной стороны, годовая отсрочка — это снятие немедленного давления. С другой — это сигнал о неизбежном ужесточении требований, к которому нужно готовиться уже сегодня. Ритейл является одним из самых технологичных секторов, и парк мобильных устройств (ТСД, смартфоны для курьеров, кассы самообслуживания) напрямую зависит от экосистемы прикладного ПО.
1. Влияние на цепочку поставок и парк устройств
Крупные ритейлеры активно используют специализированное ПО для управления складом (WMS), транспортом (TMS) и торговым залом. Значительная часть этих решений, особенно от крупных международных вендоров, сейчас находится в процессе миграции на отечественные рельсы или использования через партнёров. Если ваше мобильное приложение для сборщика заказов или курьерской доставки не будет работать на доверенных ОС (например, на платформе Аврора или РЕД ОС М), вы не сможете использовать устройства под их управлением в рамках проектов, требующих импортозамещения. Отсрочка даёт время, чтобы не экстренно менять весь парк ТСД, а планомерно провести пилотные проекты. Это напрямую связано с требованиями 152-ФЗ, так как доверенные ОС обеспечивают более предсказуемую и контролируемую среду для обработки персональных данных клиентов и сотрудников.
2. Риски для MDM-стека и смежных систем
Проблема не только в самом приложении, но и в средствах его управления. Ваша MDM-система (включая Komendant MDM) должна полноценно поддерживать целевые ОС. Это включает:
- Корректную работу агентов на платформе.
- Поддержку специфичных для ОС API для политик (например, управление сертификатами в системном хранилище, настройка VPN на уровне ядра).
- Совместимость с системами учёта (например, через /docs/scim) и каталогами пользователей.
Если разработчик вашего основного ритейл-софта не успеет к новому дедлайну, а вы уже начали закупку устройств на «новой» доверенной ОС, вы рискуете получить неуправляемый и небезопасный кусок инфраструктуры.
3. Финансовое и операционное планирование
Отсрочка позволяет пересмотреть бюджеты на 2027 год. Вместо массовой, рискованной и дорогостоящей замены всего ПО и «железа», средства можно направить на:
- Аудит существующего парка приложений на предмет совместимости.
- Закупку ограниченной партии устройств под целевые ОС для тестирования.
- Доработку внутренних систем (включая backend), которые могут иметь скрытые зависимости от Google Mobile Services (GMS), отсутствующих на многих доверенных ОС.
Что делать
Действовать нужно системно, используя выигранный год для подготовки, а не для паузы.
1. Проведите инвентаризацию мобильного парка и ПО
Необходимо составить матрицу соответствия. Для каждого критичного бизнес-приложения (кассовое ПО, мобильный клиент для WMS, курьерское приложение) укажите:
- Текущую версию и разработчика.
- Статус в реестре Минцифры (проверить можно на официальном портале).
- Заявленную поддержку доверенных ОС (Аврора, Astra Linux Mobile, РЕД ОС М).
- Наличие критичных зависимостей (например, использование Google Maps SDK, HMS Core, специфичных библиотек SafetyNet).
Особое внимание уделите приложениям, работающим с персональными данными, в контексте /docs/152-fz.
2. Актуализируйте требования к MDM-политикам
Подготовьте шаблоны конфигураций для новых ОС. Если вы используете Komendant MDM, изучите /docs/policies на предмет поддержки платформ Аврора и других. Сформируйте базовые «золотые образы» политик:
- Настройка Wi-Fi (корпоративная сеть, WPA2-Enterprise).
- Управление жизненным циклом сертификатов (прокси на SSL/TLS инспекции).
- Блокировка системных функций (запрет на установку из неизвестных источников, отключение камеры/Bluetooth по геозоне).
- Настройка рабочего профиля или kiosk-режима для ТСД.
3. Запустите пилотный проект на доверенной ОС
Не ждите финального утверждения постановления. Выберите некритичный, но показательный процесс (например, внутренняя логистика между складами, а не фронт-энд выдачи заказов) и разверните его на 10–20 устройствах под управлением одной из доверенных ОС.
- Проверьте работу не только целевого приложения, но и стека: сканирование штрихкодов, печать на мобильные принтеры, обмен данными по API.
- Протестируйте сценарии обновления ПО через ваш MDM. Убедитесь, что команды ADB (если применимо) или нативные механизмы ОС позволяют удалённо обновлять пакеты без физического доступа к устройствам.
- Проверьте потребление батареи и стабильность канала связи, так как оптимизации в доверенных ОС могут отличаться от стандартного Android.
4. Взаимодействуйте с вендорами
Направьте официальные запросы вашим ключевым поставщикам ПО с просьбой предоставить дорожную карту (roadmap) портирования на доверенные ОС. Используйте факт обсуждения проекта постановления как рычаг: их планы должны быть синхронизированы с новым, пусть и отложенным, дедлайном. Запросите у них тестовые сборки (APK или пакеты для целевой ОС) для вашего пилота.
Источник: https://d-russia.ru/vstuplenie-v-silu-pravila-dvuh-os-dlya-reestrovogo-po-perenositsya-proekt-postanovleniya.html