Включение промышленной продукции в реестр Минпромторга - важная процедура для российских производителей.
Подготовка программного продукта к требованиям Минцифры — это не разовое действие накануне подачи заявления, а системная работа, которая нередко занимает несколько месяцев. Большинство коммерческих продуктов создавались без расчёта на требования постановления № 1937: под Windows-среду, с иностранными зависимостями, без формализованной документации по безопасности. Разрыв между тем, каким продукт является сейчас, и тем, каким он должен быть для успешного прохождения экспертизы в центре тестирования, — это и есть содержание подготовки. Правильно оценить этот разрыв и спланировать его преодоление — задача предварительного аудита.
Что именно проверяет Минцифры и центр тестирования
Понимание того, что именно будет проверяться, позволяет сосредоточить подготовку на действительно важных направлениях, а не тратить ресурсы на избыточные улучшения. Проверка охватывает три независимых блока.
⚖️
Юридический блок
Минцифры проверяет: исключительные права на продукт принадлежат российскому юридическому или физическому лицу, компания находится под российским контролем, продукт включён в реестр российского ПО. Эти вопросы решаются до подачи заявления — центр тестирования юридическими вопросами не занимается.
🖥️
Технический блок: совместимость с ОС
Центр тестирования проверяет: продукт корректно устанавливается и работает на двух выбранных доверенных ОС, вся заявленная функциональность воспроизводится в тестовой среде, установка производится штатным способом по документации без ручных вмешательств.
🔐
Технический блок: информационная безопасность
Центр тестирования проверяет: отсутствие известных уязвимостей в компонентах продукта, отсутствие недокументированных функций и скрытых каналов передачи данных, корректность механизмов аутентификации и разграничения доступа, применение российской криптографии при наличии криптофункций.
Этап 1: предварительная оценка готовности
Прежде чем начинать любые доработки, нужно понять реальное состояние продукта по каждому из трёх блоков. Без этой оценки невозможно составить реалистичный план и бюджет подготовки.
1.1
Юридический аудит прав и корпоративной структуры
Проверка каждого компонента продукта на предмет надлежащего оформления исключительных прав. Анализ трудовых договоров с разработчиками — наличие условий о служебных произведениях. Проверка договоров с историческими подрядчиками — наличие условий об отчуждении прав. Анализ корпоративной структуры на соответствие требованию российского контроля. Типичный срок: 5–10 рабочих дней.
1.2
Технический аудит совместимости
Развёртывание тестового стенда с выбранными доверенными ОС и проверка продукта в этой среде. Инвентаризация компонентного стека на предмет платформо-специфичных зависимостей. Анализ сетевой активности продукта. Типичный срок: 5–10 рабочих дней при наличии доступа к продукту и готового стенда.
1.3
Аудит документации и реестровой записи
Проверка актуальности реестровой записи в ФГИС — соответствие текущей версии и функциональности. Оценка наличия и полноты технической документации: руководство пользователя, руководство администратора, документация по безопасности. Проверка соответствия версии дистрибутива и документации. Типичный срок: 2–3 рабочих дня.
По итогам аудита формируется перечень действий с оценкой трудоёмкости каждого. Это основа для реалистичного плана подготовки с конкретными датами и ответственными.
Этап 2: юридическая подготовка
Юридическая подготовка решает вопросы, которые нельзя проигнорировать — они проверяются Минцифры при регистрации заявления и могут стать основанием для возврата пакета без рассмотрения.
Задача Содержание Типичный срок Закрытие пробелов в договорах с разработчиками Дополнительные соглашения к трудовым договорам, оформление служебных заданий, договоры об отчуждении прав с историческими подрядчиками 2–6 недель в зависимости от числа участников и их доступности Урегулирование корпоративной структуры При наличии иностранных участников — анализ и при необходимости реструктуризация: изменение состава участников, пересмотр корпоративного договора 1–4 месяца при необходимости реструктуризации Регистрация программы в Роспатенте Не обязательна, но существенно упрощает подтверждение прав. Свидетельство Роспатента — весомый документ при рассмотрении заявления 1–2 месяца Актуализация реестровой записи Если текущая запись не отражает актуальную функциональность — обновление через экспертный совет Минцифры 1–2 месяца через стандартную процедуру Расчёт правила 30% для госкомпаний Подготовка справки о структуре выручки с разбивкой по аффилированным и внешним заказчикам 1–2 недели
Этап 3: техническая подготовка — совместимость с доверенными ОС
Для большинства продуктов это самый трудоёмкий этап. Его продолжительность определяется архитектурными решениями, принятыми при создании продукта — и нередко эти решения принимались без какого-либо расчёта на работу в Linux-среде.
✅ Кросс-платформенные продукты (Java, Go, Python)
Наиболее благоприятный сценарий. Основная работа — разворачивание стенда с доверенными ОС, прогон функциональных тестов, выявление и устранение единичных несовместимостей. Срок: 2–4 недели. Главный риск — специфика конкретных доверенных дистрибутивов (версии компонентов, политики SELinux/Parsec в Astra Linux).
⚠️ Web-приложения
Серверная часть обычно кросс-платформенна. Клиентская часть проверяется в доверенных браузерах — Яндекс Браузер на доверенной ОС. Основные риски: использование устаревших web-стандартов, несовместимость с конкретными версиями браузеров. Срок: 2–6 недель.
⚠️ Частичная Windows-зависимость
Продукт работает на Linux в целом, но отдельные модули или функции используют Windows-специфичные компоненты. Замена COM/ActiveX-компонентов, адаптация системных вызовов, замена Windows-специфичного инсталлятора. Срок: 4–10 недель.
🔴 Глубокая Windows-интеграция (.NET Framework, WinAPI)
Продукт использует Windows-специфичные API, реестр, COM-объекты, Windows Service Manager. Требуется значительная переработка архитектурных компонентов, часто — частичная переписка на кросс-платформенный стек. Срок: 3–8 месяцев разработки.
3.1
Инвентаризация платформо-специфичных зависимостей
Полный список компонентов, использующих Windows-специфичные механизмы. Для каждой зависимости — оценка: можно ли заменить кросс-платформенным аналогом, требует ли замена переработки логики, или зависимость настолько глубокая, что требует архитектурного решения.
3.2
Развёртывание стенда с доверенными ОС
Установка тех же доверенных ОС, которые будут использоваться при официальной экспертизе. Для серверного ПО — серверная конфигурация. Конфигурация стенда должна максимально точно воспроизводить реальные условия использования продукта государственными заказчиками.
3.3
Итеративная доработка и тестирование
Устранение несовместимостей в порядке приоритетности — сначала критические (без которых продукт не запускается), затем значимые (неработающие основные функции), затем второстепенные. Каждый цикл доработки завершается полным прогоном функциональных тестов на стенде.
3.4
Адаптация инсталлятора
Инсталлятор должен корректно работать на доверенных ОС штатным способом без ручных вмешательств. Для Windows-ориентированных продуктов — разработка Linux-пакетов (RPM, DEB) или универсального инсталлятора. Документирование процедуры установки под доверенные ОС в руководстве администратора.
Этап 4: техническая подготовка — информационная безопасность
Блок информационной безопасности при подготовке нередко недооценивают — и обнаруживают замечания по нему в центре тестирования, когда времени на исправление уже мало. Этот блок требует отдельной целенаправленной работы.
Направление Что нужно сделать Типичные проблемы Обновление зависимостей Инвентаризация всего компонентного стека, сверка с CVE-базой, обновление уязвимых версий библиотек Обновление одной библиотеки создаёт несовместимость с другой — требует итеративного подхода Сетевая активность Документирование всех сетевых соединений продукта, отключение телеметрии и недокументированных внешних обращений Встроенная телеметрия разработчика, обращения к иностранным CDN, внешние зависимости времени выполнения Криптография Для продуктов с криптофункциями — интеграция российских алгоритмов ГОСТ R 34.10-2012, ГОСТ R 34.11-2012 Переход на ГОСТ требует замены криптографической подсистемы, что затрагивает форматы хранения и передачи данных Управление доступом Проверка механизмов аутентификации, авторизации, ролевой модели на соответствие требованиям документации Слабые пароли по умолчанию, отсутствие разграничения прав, незащищённые административные интерфейсы Документация по безопасности Подготовка описания архитектуры безопасности, модели угроз, описания механизмов защиты Отсутствует полностью — один из самых частых пробелов при подготовке к экспертизе
Этап 5: подготовка технической документации
Документация — это не приложение к продукту, а отдельный объект проверки. Центр тестирования работает по документации: устанавливает продукт по руководству администратора, тестирует функции по руководству пользователя, оценивает безопасность по документации по ИБ. Несоответствие документации реальному продукту — самостоятельное основание для замечаний.
📖 Руководство пользователя
Актуальное описание всех функций заявленной версии с пошаговыми инструкциями для типовых сценариев. Скриншоты интерфейса должны соответствовать актуальной версии продукта. Все упомянутые функции должны реально работать на доверенных ОС.
⚙️ Руководство администратора
Инструкции по установке на доверенных ОС — написанные именно для Linux-среды, а не адаптированные из Windows-инструкций. Описание настройки, управления пользователями, резервного копирования, обновления. Для серверного ПО — описание кластерных конфигураций.
🔐 Документация по информационной безопасности
Описание архитектуры безопасности продукта, модель угроз и нарушителей, механизмы защиты данных, управление ключами при наличии криптофункций. Это отдельный документ — не раздел руководства пользователя.
🧩 Перечень компонентов и зависимостей
Полный список сторонних библиотек и фреймворков с указанием версий и лицензий. Включая транзитивные зависимости. Центр тестирования сверяет этот список с CVE-базой — неполный список будет запрошен дополнительно.
Чек-лист готовности к подаче заявления
Перед подачей заявления в Минцифры каждый пункт должен быть проверен и подтверждён. Это не формальный список — это фактические требования, несоответствие которым выявится либо при регистрации заявления, либо в ходе экспертизы.
Блок Пункт проверки Статус Юридический Реестровая запись в ФГИС актуальна и отражает текущую версию продукта ✓ / ✗ Исключительные права на все компоненты продукта оформлены на компанию-заявителя ✓ / ✗ Корпоративная структура соответствует требованию российского контроля ✓ / ✗ Для госкомпаний: доля аффилированной выручки не превышает 30% ✓ / ✗ / н/п Технический: ОС Продукт протестирован на двух выбранных доверенных ОС и работает корректно ✓ / ✗ Установка продукта на доверенных ОС производится штатным способом по документации ✓ / ✗ Вся заявленная в реестровой записи функциональность воспроизведена на стенде ✓ / ✗ Продукт не использует Wine или другие слои эмуляции Windows-среды ✓ / ✗ Технический: ИБ Компонентный стек проверен на CVE, уязвимые версии обновлены ✓ / ✗ Вся сетевая активность продукта задокументирована, телеметрия отключена или задокументирована ✓ / ✗ Для криптофункций применены российские алгоритмы ГОСТ ✓ / ✗ / н/п Механизмы аутентификации и разграничения доступа соответствуют требованиям ✓ / ✗ Документация Руководство пользователя актуально для текущей версии продукта ✓ / ✗ Руководство администратора содержит инструкции для доверенных ОС ✓ / ✗ Документация по информационной безопасности подготовлена ✓ / ✗ Полный перечень компонентов и зависимостей с версиями составлен ✓ / ✗
Вопросы о подготовке ПО к требованиям Минцифры
С чего начать, если непонятно, насколько продукт готов?
Начать нужно с предварительного аудита — технического и юридического одновременно. Это 7–10 рабочих дней и конкретный ответ: какие блоки готовы, какие требуют доработки, сколько времени и ресурсов займёт каждая задача. Без этой отправной точки невозможно ни планировать сроки, ни оценивать бюджет. Мы проводим такой аудит как самостоятельную услугу — и по его итогам вы получаете конкретный план, а не общие рекомендации.
Можно ли вести техническую доработку и юридическую подготовку параллельно?
Да, и именно так мы рекомендуем организовывать работу. Юридический аудит и оформление документов по правам — задачи для юристов. Техническая доработка продукта под доверенные ОС — задачи для команды разработки. Оба трека идут одновременно, и суммарный срок подготовки сокращается на несколько недель по сравнению с последовательным ведением. Параллельно с этим мы начинаем переговоры с центром тестирования.
Наш продукт активно развивается — новые версии выходят каждые 2–3 месяца. Как это влияет на процедуру?
Центр тестирования проверяет конкретную версию продукта — ту, что указана в реестровой записи и передана с дистрибутивом. После получения доверенного статуса версия фиксируется. При выходе существенно обновлённой версии потребуется актуализация реестровой записи, а при значительных изменениях в безопасности или функциональности — переподтверждение статуса. Для активно развивающихся продуктов важно выбрать правильный момент для подачи: когда текущая версия достаточно стабильна, а следующее крупное обновление ещё не на горизонте.
Нужно ли готовить продукт по-разному для разных доверенных ОС?
Отчасти да. Разные доверенные дистрибутивы имеют собственную специфику: Astra Linux SE — мандатный механизм управления доступом Parsec, РЕД ОС — иные версии системных компонентов. Продукт должен корректно работать на каждой из выбранных ОС в её стандартной конфигурации. На практике для большинства кросс-платформенных продуктов подготовка под одну доверенную Linux-среду охватывает основную часть работы, а доработка под вторую занимает значительно меньше времени. Но тестировать на каждой ОС нужно отдельно.
Подготовка — это управляемый проект с предсказуемым результатом
Реестр Гарант сопровождает подготовку программных продуктов к требованиям Минцифры с момента введения процедуры доверенного статуса. Мы проводим технический и юридический аудит, составляем конкретный план доработки с датами и ответственными, координируем параллельное ведение юридического и технического треков. Результат — продукт, который проходит экспертизу в центре тестирования с первого раза. Именно это происходит в 95% наших проектов.
7–10 дн. срок предварительного аудита готовности от 50 000 ₽ стоимость комплексного аудита готовности 95% наших клиентов проходят экспертизу с первого раза 10 лет опыт сопровождения реестровых процедур Минцифры
Оценить готовность продукта и составить план подготовки
Расскажите об архитектуре продукта и текущей ситуации с документами — проведём аудит и дадим конкретный план с реалистичными сроками и бюджетом.
Телефон / WhatsApp / Telegram: +7 920-898-17-18
Email: reestrgarant@mail.ru
Первичная консультация бесплатная в рабочее время.
Оригинальная статья
Полная версия статьи на нашем сайте: https://vnesenie-v-reestr.ru/news/kak-podgotovit-po-k-trebovaniyam-mintsifry-dlya-polucheniya-doverennogo-statusa
Мы занимаемся включением в реестр Минпромторга
📞 Телефон: +7 920-898-17-18
✉️ Email: reestrgarant@mail.ru