Добровольный реестр цифровых платформ: новые возможности и скрытые риски для российского ритейла
Минэкономразвития инициирует реформу, в рамках которой цифровые платформы получат возможность добровольно входить в специальный государственный реестр. По данным New Retail, ведомство планирует отказаться от обязательных критериев включения, что кардинально меняет подход к регулированию IT-активностей в сфере электронной коммерции.
Что произошло
Текущая регуляторная модель предполагает принудительное включение крупных онлайн-площадок в реестр на основе объективных метрик — количества пользователей, объёма транзакций или доли на рынке. Новый законопроект предлагает сменить парадигму с «обязательной регистрации по достижении порога» на «добровольную аккредитацию». Это означает, что любая платформа, независимо от её масштаба, сможет подать заявку на включение в реестр Минэкономразвития. Основной мотив ведомства — стимулировать развитие малого и среднего бизнеса, предоставляя небольшим игрокам те же преференции, которые сейчас доступны только признанным «системно значимым» агрегаторам. Фактически это открывает двери реестра для нишевых маркетплейсов, корпоративных B2B-порталов сетей и даже внутренних приложений лояльности, если они соответствуют формальным требованиям к платформе. При этом добровольный статус не отменяет необходимости соблюдать базовые нормы законодательства о защите прав потребителей и персональных данных (152-ФЗ), но даёт доступ к государственным мерам поддержки и участию в федеральных программах цифровизации.
Почему это важно
Для ИТ-руководителей розничных сетей эта инициатива создаёт двойственный эффект. С одной стороны, появляется легальный механизм вывода внутренних разработок во внешний контур без риска быть внезапно признанными «крупной цифровой платформой» со всеми вытекающими обязательствами. Если ваша сеть разрабатывает собственное приложение для курьеров (собственная служба доставки) или платформу для поставщиков (SRM-система), вы можете заранее включить её в реестр на своих условиях. Это фиксирует ваш правовой статус и позволяет претендовать на гранты РФРИТ или льготное кредитование, что особенно актуально при импортозамещении ПО.
С другой стороны, возникают серьёзные вызовы в области управления мобильным парком. Как только внутренняя платформа получает официальный статус из реестра, требования к безопасности обрабатываемых ею данных резко возрастают. Рассмотрим практические сценарии:
1. Парк ТСД и смартфонов. Курьеры и сотрудники торгового зала используют мобильные устройства для доступа к порталу поставщика или приложению сборки заказов. Если этот портал теперь является «зарегистрированной цифровой платформой», компрометация мобильного канала становится инцидентом национального уровня. Простого MDM-решения будет недостаточно; потребуется внедрение строгих политик соответствия (Compliance Policies).
2. Интеграция с отечественными ОС. Для работы с госсубсидиями многие компании переводят корпоративные смартфоны на Аврору или РЕД ОС М. Добровольный вход в реестр должен сопровождаться сертификацией приложения под эти системы. В контексте Aurora OS это означает использование встроенного криптопровайдера (КриптоПро CSP) и настройку через централизованный сервер управления QUIK. Любая уязвимость в вашем приложении-витрине может стать причиной отзыва статуса из реестра.
3. Соответствие 152-ФЗ. Реестр Минцифры и реестр цифровых платформ Минэка тесно связаны. Платформа в реестре априори считается оператором ПДн повышенного класса. Это требует настройки мобильных устройств на уровне ядра: запрета снятия скриншотов (FLAG_SECURE), блокировки копирования данных между рабочим профилем и личным (в Android Enterprise), а также обязательного использования сертификатов ГОСТ Р 34.10-2012 для шифрования трафика внутри VPN-туннеля до вашего ЦОД.
Аналогичный кейс мы наблюдали с маркировкой товаров: когда система "Честный ЗНАК" стала обязательной, тысячи мелких ИП столкнулись с необходимостью закупать сертифицированные ТСД и настраивать их через MDM, так как ручной ввод стал нелегитимен. Добровольный реестр работает похожим образом, но для программной части бизнеса.
Что делать
Реагировать на эту инициативу нужно проактивно, используя окно возможностей до вступления поправок в полную силу. Вот конкретный план действий для департамента ИТ розничной сети:
1. Проведите аудит собственных цифровых активов. Составьте список всех веб-порталов и мобильных приложений, которые связывают вас с внешними контрагентами (поставщики, самозанятые курьеры, пункты выдачи). Определите, какие из них технически попадают под определение «цифровой платформы» (наличие поиска, корзины, агрегации предложений) и могут быть внесены в реестр добровольно для получения субсидий на разработку.
2. Актуализируйте политики Mobile Device Management (MDM). Не дожидаясь инцидента, внедрите следующие технические ограничения для устройств, имеющих доступ к вашей платформе:
* Версия ОС: Установите минимальный порог minSDK 33 (Android 13) для всех корпоративных устройств. Более старые версии не поддерживают современные протоколы аттестации SafetyNet/Play Integrity API, что недопустимо для платформы из реестра.
* Целостность системы: Через консоль MDM заблокируйте загрузчик (OEM unlocking) и запретите установку пакетов из неизвестных источников (android.settings.SECURITY_SETTINGS) на системном уровне.
* Сетевая безопасность: Настройте обязательное подключение через корпоративный Always-on VPN с проверкой сертификата сервера (certificate pinning). Используйте ADB-команду для форсирования этого правила на тестовых устройствах: adb shell settings put global always_on_vpn_app com.your.vpn.client.
* Изоляция профилей: Для сотрудников-курьеров используйте рабочий профиль (Android Work Profile). Через политику /docs/policies запретите экстеншн com.android.intent.action.MAIL для передачи данных за пределы контейнера.
3. Подготовьте инфраструктуру к SCIM-интеграции. Регистрация в реестре подразумевает прозрачность пользовательской базы. Синхронизируйте вашу платформу с Active Directory или Keycloak по протоколу SCIM (System for Cross-domain Identity Management). Это позволит автоматически блокировать доступ уволенных сотрудников к платформе прямо из кадровой системы (1С:ЗУП), что является стандартом де-факто для compliance. Детали реализации смотрите в нашей документации /docs/scim.
4. Сертифицируйте мобильный клиент под Аврору. Если вы претендуете на государственные льготы, ваше мобильное приложение должно работать на отечественных ОС. Начните тестирование дистрибутива .rpm или .apk (для AuroraOS используется совместимый слой) в среде виртуализации ГК Астра. Убедитесь, что приложение корректно запрашивает разрешения через PolicyKit и использует защищенное хранилище ключей вместо стандартной SharedPreferences.
5. Оцените экономическую целесообразность. Рассчитайте стоимость владения собственным реестропригодным стеком. Часто затраты на сертификацию ФСТЭК внутренней разработки превышают выгоду от грантов. В таких случаях выгоднее использовать готовые SaaS-решения, уже находящиеся в реестре отечественного ПО и имеющие подтвержденную совместимость с российскими MDM. Оценить бюджет можно на странице /pricing.
Источник: https://new-retail.ru/novosti/retail/v_reestr_tsifrovykh_platform_razreshat_vkhodit_dobrovolno
---
Источник: https://new-retail.ru/novosti/retail/v_reestr_tsifrovykh_platform_razreshat_vkhodit_dobrovolno/