Всё о получении статуса доверенного ПО: этапы, требования, сроки и наши услуги.
Материал давал точный архитектурный разбор доверенного статуса для мобильных приложений — с чёткой классификацией по типу архитектуры продукта и практическими рекомендациями. Портили его только вымышленный опыт, статистика и контакты. Оставляем весь технический анализ.
Главное: требование постановления №1937 о совместимости с доверенными операционными системами буквально не применимо к нативным iOS и Android приложениям — доверенные ОС представляют собой российские Linux-дистрибутивы для десктопных и серверных сред, на которых нативное мобильное приложение физически не запускается. Продукт, существующий исключительно как мобильное приложение без web-интерфейса или десктопной версии, практически не может получить доверенный статус в текущем виде. Но если у продукта есть работающий на доверенной ОС компонент — web-интерфейс, десктопный клиент или серверная часть, — именно он становится объектом проверки, а мобильное приложение рассматривается как дополнительный канал доступа.
| Утверждение из старой версии статьи | Реальное положение дел |
|---|---|
| «10 лет опыт работы с реестровыми процедурами Минцифры»; статистика «95% наших клиентов проходят экспертизу с первого раза» | Доверенный статус существует с марта 2026 года, многолетнего опыта и статистики по нему быть не может |
Центральная проблема: совместимость с доверенными ОС
Требование о совместимости с двумя доверенными операционными системами из перечня Минцифры буквально не применимо к нативным iOS и Android приложениям. Доверенные ОС — это российские Linux-дистрибутивы для рабочих станций и серверов, и нативное приложение под iOS или Android физически не может работать ни на Astra Linux, ни на РЕД ОС. Это не теоретическая проблема, а практическое препятствие, которое нужно либо обойти архитектурным решением, либо принять как ограничение. Ситуация принципиально различается в зависимости от архитектуры конкретного продукта.
Продукт, существующий исключительно как iOS-приложение или Android-приложение без web-интерфейса, десктопной версии или серверной части с самостоятельной функциональностью, не может выполнить требование о совместимости — доверенные ОС просто не являются мобильными платформами. Продукт с мобильным приложением и браузерным web-интерфейсом, доступным с любого устройства, находится в лучшем положении. Объектом доверенного статуса может выступать web-версия, работающая в доверенном браузере на доверенной ОС, а мобильное приложение остаётся вспомогательным каналом доступа. Продукт на кросс-платформенном фреймворке вроде Flutter или React Native теоретически допускает сборку под Linux, но на практике это требует отдельной технической работы и тестирования на доверенных ОС. Применимость зависит от конкретной конфигурации продукта. Продукт с полноценной десктопной или серверной версией в дополнение к мобильному приложению — самый благоприятный случай. Десктопная или web-версия работает на доверенных ОС, и статус получает продукт в целом с указанием поддерживаемых клиентов в реестровой записи.
Что проверяется при экспертизе мобильно-ориентированного продукта
Если у продукта есть компонент, работающий на доверенных ОС (web-интерфейс или десктопный клиент), именно он становится основным объектом проверки совместимости, а мобильная часть рассматривается как дополнительный канал доступа. Центр тестирования устанавливает доверенную ОС, запускает поддерживаемый браузер и проверяет web-интерфейс: вся функциональность, заявленная в реестровой записи как доступная через web, должна корректно работать в этой среде, а специфика конкретного браузера (версия движка, политики безопасности, поведение JavaScript-API) требует отдельного тестирования. Серверная часть продукта должна корректно разворачиваться на доверенной ОС штатным инсталлятором без ручного вмешательства, с документацией для Linux-среды, а для облачных продуктов — на тестовом экземпляре на российской инфраструктуре. Блок информационной безопасности охватывает серверную часть полностью: зависимости, сетевую активность, механизмы аутентификации. Для web-клиента дополнительно проверяется безопасность передачи данных между мобильным приложением и сервером, если такое взаимодействие заявлено в функциональности.
Как правильно сформулировать реестровую запись
Для продукта с мобильным и web-клиентами принципиально важно правильно описать функциональность в реестровой записи. Центр тестирования проверяет именно то, что заявлено. Если запись описывает продукт как «мобильное приложение для iOS и Android» без упоминания web-интерфейса, эксперт будет искать именно мобильное приложение на доверенной ОС и не найдёт ничего для проверки.
| Что описано в реестровой записи | Что проверяет центр тестирования | Результат |
|---|---|---|
| «Мобильное приложение для iOS и Android» | Ищет мобильное приложение на доверенной ОС | Несовместимость — замечание |
| «Программный комплекс с web-интерфейсом и мобильными клиентами для iOS и Android» | Проверяет web-интерфейс на доверенной ОС в поддерживаемом браузере | Корректная постановка задачи для экспертизы |
| «Система управления с десктопным клиентом и мобильным приложением» | Проверяет десктопный клиент на доверенной ОС | Корректная постановка при наличии рабочего десктопного клиента |
Особые случаи: приложения для российских мобильных ОС
Отдельного упоминания заслуживают мобильные операционные системы российского происхождения — на рынке присутствует несколько таких ОС, в частности Аврора ОС от «Открытой Мобильной Платформы». Если конкретная российская мобильная ОС входит в актуальный перечень доверенных ОС Минцифры, ситуация принципиально меняется: нативное мобильное приложение под неё теоретически может выступать объектом проверки совместимости.
Состав перечня доверенных ОС меняется — новые системы получают статус, существующие проходят переподтверждение, — поэтому перед планированием разработки мобильного приложения под российскую мобильную ОС именно ради доверенного статуса стоит проверить актуальный перечень непосредственно в ФГИС Минцифры, а не ориентироваться на данные, которые могли устареть за прошедшие месяцы.
Практические рекомендации для мобильных разработчиков
Если продукт представляет собой только мобильное приложение, получение доверенного статуса в текущем виде практически невозможно — доступные пути: разработать полноценный web-интерфейс с той же функциональностью, оценить возможность сборки под Linux через кросс-платформенный фреймворк, рассмотреть разработку клиента под российскую мобильную ОС, или честно оценить, является ли государственный сектор целевой аудиторией продукта вообще — если нет, статус попросту не нужен. Если продукт сочетает мобильное приложение и web, доверенный статус возможен при правильной подготовке: нужно убедиться, что web-версия имеет полноценную функциональность, достаточную для заявления в реестре, протестировать web-интерфейс в целевом браузере на доверенной ОС, скорректировать реестровую запись под корректное описание продукта и обеспечить корректное развёртывание серверной части на доверенной ОС. Если продукт написан на Flutter или React Native, нужна отдельная техническая оценка: поддерживает ли текущая конфигурация сборку под Linux, совместимы ли используемые плагины с такой сборкой, какие доработки нужны для работы на Astra Linux или РЕД ОС и целесообразно ли это по сравнению с разработкой отдельного web-интерфейса.
Вопросы и ответы
Короткие ответы на вопросы, которые чаще всего возникают при подготовке документов и подаче заявки.
Приложение работает на Android, а Android — это ведь Linux. Разве это не совместимость с Linux?
Android использует Linux-ядро, но это принципиально иная операционная среда по сравнению с российскими Linux-дистрибутивами из перечня доверенных ОС. Android-приложения работают в среде ART и используют Android SDK — они несовместимы с десктопными Linux-дистрибутивами и не запускаются на Astra Linux или РЕД ОС штатным образом. Совместимость ядра не означает совместимости приложений.
Нужен статус на мобильное приложение для государственных заказчиков — с чего начать?
С аудита архитектуры продукта и реальной аудитории. Если государственные заказчики используют продукт через мобильное приложение, стоит выяснить, есть ли у них требование работать именно с мобильного устройства, или web-интерфейс решил бы ту же задачу. Нередко разработка полноценного web-интерфейса одновременно открывает путь к доверенному статусу и расширяет доступность продукта для заказчиков, работающих с корпоративных устройств на доверенных ОС.
Продукт — PWA (Progressive Web App). Это мобильное приложение или web?
PWA — веб-приложение, доступное через браузер и при желании устанавливаемое на устройство как приложение. С точки зрения экспертизы доверенного статуса PWA ближе к web-приложению: его клиентская часть работает в браузере, в том числе в поддерживаемом браузере на доверенной ОС, — это значительно более благоприятная ситуация, чем нативное мобильное приложение, хотя конкретная оценка зависит от функциональности и от того, как продукт описан в реестровой записи. Если архитектура продукта неочевидна с точки зрения применимости требования, разумно начать с консультации по конкретной технической конфигурации — это быстрее прояснит реальные варианты, чем догадки по аналогии с чужими продуктами.
Источники
- КонсультантПлюс, порядок формирования перечня доверенного ПО: требование совместимости с доверенными ОС по постановлению №1937.
- Реестр российского программного обеспечения, Минцифры России: актуальный перечень доверенных операционных систем.
