Всё о получении статуса доверенного ПО: этапы, требования, сроки и наши услуги.
Материал давал глубокий технический разбор подготовки продукта к требованиям Минцифры — по архитектуре продукта, направлениям ИБ, документации, с проверочным чек-листом из 16 пунктов. Портили его фраза о десятилетнем опыте сопровождения, вымышленная статистика и цены. Оставляем техническую глубину, убираем недоказуемые цифры.
Главное: подготовка продукта к требованиям постановления №1937 — не разовое действие накануне подачи заявления, а системная работа на несколько месяцев, поскольку большинство коммерческих продуктов создавались без расчёта на эти требования, будь то Windows-среда, иностранные зависимости или отсутствие формализованной документации по безопасности. Проверка при получении статуса охватывает три независимых блока — юридический (права и российский контроль, проверяет Минцифры), совместимость с доверенными ОС и информационную безопасность (оба проверяет центр тестирования).
| Утверждение из старой версии статьи | Реальное положение дел |
|---|---|
| «10 лет опыт сопровождения реестровых процедур Минцифры» применительно к доверенному статусу; статистика «95% наших клиентов проходят экспертизу с первого раза»; цена «от 50 000 ₽» | Доверенный статус существует с марта 2026 года, десятилетнего опыта и статистики по нему быть не может; сумма не подтверждается официальными источниками |
Что именно проверяет Минцифры и центр тестирования
Юридический блок проверяет Минцифры: исключительные права на продукт принадлежат российскому лицу, компания находится под российским контролем, продукт включён в реестр российского ПО. Эти вопросы решаются до подачи заявления, центр тестирования юридическими вопросами не занимается. Технический блок совместимости с ОС проверяет центр тестирования: продукт корректно устанавливается и работает на двух выбранных доверенных ОС, вся заявленная функциональность воспроизводится в тестовой среде, установка производится штатным способом по документации без ручных вмешательств. Технический блок информационной безопасности тоже на стороне центра: отсутствие известных уязвимостей в компонентах, отсутствие недокументированных функций и скрытых каналов передачи данных, корректность механизмов аутентификации и разграничения доступа, применение российской криптографии при наличии криптофункций.
Предварительная оценка готовности
Прежде чем начинать доработки, нужно понять реальное состояние продукта по каждому из трёх блоков: без этой оценки невозможно составить реалистичный план и бюджет. Юридический аудит проверяет каждый компонент продукта на надлежащее оформление исключительных прав: трудовые договоры на условие о служебных произведениях, договоры с историческими подрядчиками на условие об отчуждении прав, корпоративную структуру на соответствие требованию российского контроля; типичный срок пять-десять рабочих дней. Технический аудит совместимости разворачивает тестовый стенд с выбранными доверенными ОС, проверяет продукт в этой среде, инвентаризирует компонентный стек на платформо-специфичные зависимости и анализирует сетевую активность; занимает пять-десять рабочих дней при готовом стенде. Аудит документации и реестровой записи проверяет актуальность записи в ФГИС, наличие и полноту технической документации, соответствие версии дистрибутива и документов; занимает два-три рабочих дня. По итогам всех трёх формируется перечень действий с оценкой трудоёмкости каждого: это основа для реалистичного плана с датами и ответственными.
Юридическая подготовка
| Задача | Содержание | Типичный срок |
|---|---|---|
| Закрытие пробелов в договорах с разработчиками | Дополнительные соглашения к трудовым договорам, оформление служебных заданий, договоры об отчуждении прав с историческими подрядчиками | 2–6 недель в зависимости от числа участников и их доступности |
| Урегулирование корпоративной структуры | При наличии иностранных участников — анализ и при необходимости реструктуризация: изменение состава участников, пересмотр корпоративного договора | 1–4 месяца при необходимости реструктуризации |
| Регистрация программы в Роспатенте | Не обязательна, но существенно упрощает подтверждение прав | 1–2 месяца |
| Актуализация реестровой записи | Если текущая запись не отражает актуальную функциональность — обновление через экспертный совет Минцифры | 1–2 месяца через стандартную процедуру |
| Расчёт правила 30% для госкомпаний | Подготовка справки о структуре выручки с разбивкой по аффилированным и внешним заказчикам | 1–2 недели |
Техническая подготовка: совместимость с доверенными ОС
Для большинства продуктов это самый трудоёмкий этап, и его продолжительность определяется архитектурными решениями, принятыми при создании продукта, нередко без какого-либо расчёта на работу в Linux-среде. Для кросс-платформенных продуктов на Java, Go или Python сценарий наиболее благоприятный: основная работа — разворачивание стенда, прогон функциональных тестов, устранение единичных несовместимостей, срок две-четыре недели; главный риск здесь — специфика конкретных доверенных дистрибутивов вроде политик Parsec в Astra Linux. Для веб-приложений серверная часть обычно кросс-платформенна, а клиентская проверяется в поддерживаемом браузере на доверенной ОС — риски связаны с устаревшими веб-стандартами и совместимостью конкретных версий браузеров; срок две-шесть недель. При частичной Windows-зависимости, когда продукт работает на Linux в целом, но отдельные модули используют Windows-специфичные компоненты, требуется замена COM/ActiveX-компонентов, адаптация системных вызовов, замена инсталлятора; срок четыре-десять недель. При глубокой Windows-интеграции через .NET Framework или WinAPI, с использованием реестра Windows, COM-объектов, Windows Service Manager, нужна значительная переработка архитектурных компонентов, часто с частичным переписыванием на кросс-платформенный стек; срок три-восемь месяцев разработки.
Практическая последовательность работ здесь такая же, независимо от сложности продукта: сначала полная инвентаризация платформо-специфичных зависимостей с оценкой по каждой — можно ли заменить кросс-платформенным аналогом или нужна переработка логики; затем развёртывание стенда с теми же доверенными ОС, что будут использоваться при официальной экспертизе, в конфигурации, максимально близкой к реальным условиям государственного заказчика; затем итеративная доработка с устранением несовместимостей по приоритету: сначала критические, без которых продукт не запускается, затем значимые, затем второстепенные, с полным прогоном тестов после каждого цикла; и наконец адаптация инсталлятора под штатную установку на доверенных ОС без ручных вмешательств, включая разработку Linux-пакетов для Windows-ориентированных продуктов.
Техническая подготовка: информационная безопасность
| Направление | Что нужно сделать | Типичные проблемы |
|---|---|---|
| Обновление зависимостей | Инвентаризация всего компонентного стека, сверка с CVE-базой, обновление уязвимых версий библиотек | Обновление одной библиотеки создаёт несовместимость с другой — требует итеративного подхода |
| Сетевая активность | Документирование всех сетевых соединений продукта, отключение телеметрии и недокументированных внешних обращений | Встроенная телеметрия разработчика, обращения к иностранным CDN, внешние зависимости времени выполнения |
| Криптография | Для продуктов с криптофункциями — интеграция российских алгоритмов ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012 | Переход на ГОСТ требует замены криптографической подсистемы, что затрагивает форматы хранения и передачи данных |
| Управление доступом | Проверка механизмов аутентификации, авторизации, ролевой модели на соответствие требованиям документации | Слабые пароли по умолчанию, отсутствие разграничения прав, незащищённые административные интерфейсы |
| Документация по безопасности | Подготовка описания архитектуры безопасности, модели угроз, описания механизмов защиты | Отсутствует полностью — один из самых частых пробелов при подготовке к экспертизе |
Подготовка технической документации
Документация — не приложение к продукту, а отдельный объект проверки: центр тестирования устанавливает продукт по руководству администратора, тестирует функции по руководству пользователя, оценивает безопасность по документации по ИБ, и несоответствие документации реальному продукту становится самостоятельным основанием для замечаний экспертов. Руководство пользователя должно актуально описывать все функции заявленной версии с пошаговыми инструкциями и скриншотами, соответствующими текущей версии продукта. Руководство администратора нужно писать именно для Linux-среды, а не адаптировать из Windows-инструкций — с описанием настройки, управления пользователями, резервного копирования, а для серверного ПО ещё и кластерных конфигураций. Документация по информационной безопасности оформляется отдельным документом, а не разделом руководства пользователя: архитектура безопасности, модель угроз и нарушителей, механизмы защиты данных, управление ключами при наличии криптофункций. Перечень компонентов и зависимостей должен включать полный список сторонних библиотек с версиями и лицензиями, включая транзитивные зависимости, — центр сверяет этот список с базой CVE, а неполный перечень запрашивается дополнительно.
Чек-лист готовности к подаче заявления
| Блок | Пункт проверки |
|---|---|
| Юридический | Реестровая запись в ФГИС актуальна и отражает текущую версию продукта |
| Юридический | Исключительные права на все компоненты продукта оформлены на компанию-заявителя |
| Юридический | Корпоративная структура соответствует требованию российского контроля |
| Юридический | Для госкомпаний: доля аффилированной выручки не превышает 30% |
| Технический: ОС | Продукт протестирован на двух выбранных доверенных ОС и работает корректно |
| Технический: ОС | Установка производится штатным способом по документации |
| Технический: ОС | Вся заявленная в реестровой записи функциональность воспроизведена на стенде |
| Технический: ОС | Продукт не использует Wine или другие слои эмуляции Windows-среды |
| Технический: ИБ | Компонентный стек проверен на CVE, уязвимые версии обновлены |
| Технический: ИБ | Вся сетевая активность продукта задокументирована, телеметрия отключена или задокументирована |
| Технический: ИБ | Для криптофункций применены российские алгоритмы ГОСТ |
| Технический: ИБ | Механизмы аутентификации и разграничения доступа соответствуют требованиям |
| Документация | Руководство пользователя актуально для текущей версии продукта |
| Документация | Руководство администратора содержит инструкции для доверенных ОС |
| Документация | Документация по информационной безопасности подготовлена |
| Документация | Полный перечень компонентов и зависимостей с версиями составлен |
Вопросы и ответы
Короткие ответы на вопросы, которые чаще всего возникают при подготовке документов и подаче заявки.
С чего начать, если непонятно, насколько продукт готов?
С предварительного аудита — технического и юридического одновременно. Это семь-десять рабочих дней и конкретный ответ: какие блоки готовы, какие требуют доработки, сколько времени и ресурсов займёт каждая задача. Без этой отправной точки сложно ни планировать сроки, ни оценивать бюджет предстоящей подготовки.
Можно ли вести техническую доработку и юридическую подготовку параллельно?
Да. Юридический аудит и оформление документов по правам — задачи для юристов, техническая доработка продукта под доверенные ОС — задачи для команды разработки, и оба трека логично вести одновременно: суммарный срок подготовки сокращается на несколько недель по сравнению с последовательным ведением.
Продукт активно развивается, новые версии выходят каждые 2-3 месяца — как это влияет на процедуру?
Центр тестирования проверяет конкретную версию продукта — ту, что указана в реестровой записи и передана с дистрибутивом, и после получения статуса эта версия фиксируется. При выходе существенно обновлённой версии потребуется актуализация реестровой записи, а при значительных изменениях в безопасности или функциональности — переподтверждение статуса. Для активно развивающихся продуктов важно выбрать момент для подачи, когда текущая версия достаточно стабильна, а следующее крупное обновление ещё не на горизонте.
Нужно ли готовить продукт по-разному для разных доверенных ОС?
Отчасти да: разные доверенные дистрибутивы имеют собственную специфику — Astra Linux SE использует мандатный механизм управления доступом Parsec, РЕД ОС отличается версиями системных компонентов, и продукт должен корректно работать на каждой выбранной ОС в её стандартной конфигурации. На практике для большинства кросс-платформенных продуктов подготовка под одну доверенную Linux-среду охватывает основную часть работы, а доработка под вторую занимает заметно меньше времени, но тестировать каждую ОС всё равно нужно отдельно.
Источники
- КонсультантПлюс, порядок формирования перечня доверенного ПО: требования к продукту и правообладателю по постановлению №1937.
- Реестр российского программного обеспечения, Минцифры России: актуализация реестровой записи как условие подготовки к экспертизе.
