Всё о получении статуса доверенного ПО: этапы, требования, сроки и наши услуги.
Требование совместимости с двумя доверенными операционными системами — одно из самых технически ёмких в процедуре получения доверенного статуса. На первый взгляд оно выглядит просто: выбери две ОС из перечня Минцифры, запусти на них продукт и зафиксируй результат. На практике это один из главных источников задержек и отрицательных заключений центров тестирования. Причина в том, что большинство коммерческих программных продуктов разрабатывались для Windows-среды, не думая о совместимости с отечественными Linux-дистрибутивами. Разрыв между «теоретически можно запустить» и «полноценно работает на уровне, достаточном для государственного заказчика» нередко оказывается значительным.
Что такое доверенные операционные системы
Доверенные операционные системы — это отдельная категория в реестре российского ПО, соответствующая специальным критериям постановления № 1937. Перечень доверенных ОС ведёт и обновляет Минцифры — он является частью ФГИС «Реестр программного обеспечения». Включение ОС в перечень означает, что она сама прошла или проходит процедуру получения доверенного статуса по тем же правилам, что и прикладное ПО.
Принципиально важно: перечень доверенных ОС — живой документ, который обновляется. Перед началом работ по совместимости необходимо проверить актуальную версию перечня на сайте Минцифры. ОС, которую вы планируете использовать для тестирования сегодня, должна оставаться в перечне к моменту экспертизы.
Основные доверенные ОС по состоянию на начало 2026 года
В перечень входят преимущественно отечественные дистрибутивы на базе Linux. Среди наиболее распространённых в государственном секторе — Astra Linux Special Edition (разработчик: «Русбитех-Астра»), РЕД ОС (разработчик: «Ред Софт»), ROSA Linux (разработчик: НТЦ ИТ РОСА), Alt Linux и дистрибутивы на его основе (разработчик: «Базальт СПО»). Для серверных конфигураций доступны серверные редакции большинства из перечисленных систем. Актуальный перечень необходимо проверять на сайте Минцифры — список может пополняться.
Что именно означает «совместимость» в контексте требования
Требование постановления № 1937 формулируется как «совместимость не менее чем с двумя доверенными операционными системами». Слово «совместимость» здесь понимается функционально — не просто факт запуска, а корректная работа заявленной функциональности продукта в среде доверенной ОС.
Что считается совместимостью
Продукт устанавливается штатным образом. Все заявленные функции работают корректно. Пользовательский интерфейс отображается правильно. Интеграции с другими системами функционируют. Данные сохраняются и считываются без ошибок. Производительность находится в разумных пределах.
Что совместимостью не считается
Продукт запускается, но часть функций не работает. Интерфейс отображается с критическими ошибками. Работа нестабильна — частые сбои и зависания. Установка требует нестандартных обходных манёвров. Продукт работает только в режиме эмуляции Windows-среды.
Специфика совместимости для разных типов продуктов
Требование совместимости с доверенными ОС применяется единообразно, но его практическое содержание существенно различается в зависимости от архитектуры и типа продукта.
| Тип продукта | Как проверяется совместимость | Типичные проблемы |
|---|---|---|
| Нативное десктопное приложение | Прямой запуск и проверка функциональности на доверенной ОС | Windows-специфичные API, WinAPI-зависимости, .NET Framework без кросс-платформенных аналогов |
| Web-приложение | Работа в доверенном браузере (Яндекс Браузер и др.) на доверенной ОС | Несовместимость с отечественными браузерами, использование устаревших web-стандартов |
| Серверное ПО | Запуск в серверной конфигурации на доверенной серверной ОС | Сервисы, привязанные к Windows Service Manager; проблемы с systemd-интеграцией |
| СУБД | Полноценная работа включая кластер, репликацию, резервное копирование | Специфика ядра Linux при работе с памятью, файловой системой; драйверы хранилищ |
| ПО с агентами на хостах | Агент и серверная часть — оба на доверенных ОС | Kernel-модули, системные вызовы, специфика Astra Linux SE с мандатным управлением доступом |
| ПО в составе ПАК | Может применяться исключение — проверка на нативной платформе | Требует документального обоснования неотделимости от аппаратной части |
Как выбрать две доверенные ОС для тестирования
Формально разработчик может выбрать любые две ОС из актуального перечня Минцифры. На практике выбор нужно делать осмысленно — с учётом нескольких факторов.
Распространённость у целевых заказчиков
Astra Linux Special Edition де-факто является стандартом в силовых ведомствах и значительной части государственных структур. РЕД ОС активно используется в гражданских государственных органах. Выбирать ОС, на которых реально работают ваши заказчики, — правильная стратегия: совместимость с ними будет иметь практическую ценность, а не только формальное значение для процедуры.
Технические особенности ОС
Astra Linux SE имеет встроенный мандатный механизм управления доступом (МАС), который отсутствует в большинстве других Linux-дистрибутивов. Для продуктов, работающих на уровне ядра или активно взаимодействующих с системными вызовами, это означает дополнительный слой сложности при адаптации. Если ваш продукт не требует тонкой системной интеграции — Astra Linux обычно не создаёт проблем.
Доступность технической поддержки
При адаптации продукта под конкретную ОС нередко возникают вопросы, требующие взаимодействия с разработчиком ОС. Наличие активной технической поддержки и документации от производителя ОС ускоряет адаптацию. Большинство ведущих отечественных ОС предоставляют программы технологического партнёрства для разработчиков.
Совместимость компонентного стека
Разные дистрибутивы используют разные версии базовых компонентов: libc, ядро Linux, systemd, графические подсистемы. Проверьте, какие версии компонентов требует ваш продукт и доступны ли они в выбранных дистрибутивах без сложных манипуляций.
Исключения из требования совместимости
Постановление № 1937 предусматривает два случая, когда требование совместимости с двумя доверенными ОС не применяется. Оба исключения требуют документального обоснования — они не работают автоматически.
Два законных исключения
Исключение 1: ПО в составе ПАК
- ПО является неотъемлемой частью программно-аппаратного комплекса
- Работа ПО технически обусловлена конкретной аппаратной платформой
- ПО не поставляется и не функционирует отдельно от аппаратной части
- Требуется детальное техническое обоснование неотделимости
Исключение 2: одна группа лиц с разработчиком ОС
- Правообладатель ПО и правообладатель ОС входят в одну группу лиц
- Аффилированность определяется по критериям 135-ФЗ (антимонопольное законодательство)
- Требуется документальное подтверждение аффилированности
- Актуально для вертикально-интегрированных IT-компаний
Как проходит проверка совместимости в центре тестирования
Понимание того, как именно работает центр тестирования при проверке совместимости, помогает правильно подготовиться. Экспертиза — не формальная галочка и не просто проверка запуска.
Развёртывание тестовой среды
Центр разворачивает выбранные доверенные ОС в конфигурации, типичной для использования данной категории ПО. Для серверного ПО — серверная конфигурация. Для десктопных приложений — рабочая станция. Важно заранее согласовать с центром, какую именно конфигурацию они будут использовать.
Установка и первичная проверка
Эксперты устанавливают продукт в тестовой среде штатным способом, описанным в документации. Нестандартные процедуры установки, требующие обходных манёвров или ручной правки конфигурации, уже на этом этапе могут вызвать замечания.
Проверка заявленной функциональности
Центр тестирует все функции, указанные в реестровой записи и документации к продукту. Каждая заявленная функция должна работать корректно. Если в описании указана, например, работа с PDF-форматом — эту функцию проверят отдельно.
Проверка интеграций
Если продукт интегрируется с другими системами — проверяется корректность этих интеграций в среде доверенной ОС. Особенно актуально для серверного ПО, СУБД и корпоративных приложений.
Оформление заключения
По результатам экспертизы центр формирует заключение: положительное (совместимость подтверждена) или с замечаниями (перечень проблем, требующих устранения). Замечания означают доработку продукта и повторную проверку — дополнительные время и расходы.
Подготовка к проверке совместимости: практические шаги
Чтобы экспертиза центра тестирования завершилась положительным заключением с первого раза, совместимость нужно проверить и подтвердить до подачи заявления. Это инвестиция времени, которая многократно окупается экономией на повторных экспертизах.
Аудит зависимостей
Полная инвентаризация всех платформо-специфичных компонентов: Windows API, COM/DCOM, .NET Framework, Windows Registry, Windows-специфичные системные службы. Каждая зависимость — потенциальная точка несовместимости.
Создание тестового стенда
Разворачиваем выбранные доверенные ОС в конфигурации, максимально близкой к той, что использует центр тестирования. Для серверного ПО — серверная конфигурация, для десктопных приложений — рабочая станция с типичными настройками.
Итеративная доработка
Устраняем выявленные несовместимости: замена Windows-специфичных библиотек на кросс-платформенные аналоги, адаптация инсталлятора, переработка проблемных компонентов. Каждый цикл завершается повторным тестированием на стенде.
Документирование результатов
Фиксируем результаты внутреннего тестирования: тестовые сценарии, конфигурации сред, результаты проверок. Это документация для центра тестирования — она ускоряет экспертизу и демонстрирует готовность продукта.
Стоимость работ по обеспечению совместимости
Стоимость работ по обеспечению совместимости с доверенными ОС — это расходы на разработку, которые несёт сама компания или её подрядчик. Они не входят в стоимость консалтингового сопровождения и не входят в стоимость экспертизы центра тестирования. Это отдельная статья бюджета, которую нужно планировать самостоятельно.
| Ситуация с продуктом | Ориентировочный объём доработки | Ориентировочный срок |
|---|---|---|
| Кросс-платформенный продукт на Java, Go, Python | Минимальный — тестирование и документация | 1–2 недели |
| Web-приложение без нативных компонентов | Адаптация под доверенные браузеры, проверка web-стандартов | 2–4 недели |
| Частичная Windows-зависимость (отдельные модули) | Замена проблемных компонентов на кросс-платформенные | 1–3 месяца |
| Глубокая Windows-интеграция (.NET, WinAPI, COM) | Серьёзная переработка архитектурных компонентов | 3–8 месяцев |
| Промышленное ПО с аппаратными зависимостями | Разработка Linux-драйверов, адаптация протоколов | 6–18 месяцев |
| Продукт уровня ядра ОС (антивирус, агент мониторинга) | Разработка kernel-модулей для каждой доверенной ОС | 3–9 месяцев |
Вопросы о совместимости с доверенными ОС
Нужно ли получать сертификат совместимости от производителя ОС?
Формально постановление № 1937 не требует сертификата совместимости от производителя ОС — достаточно положительного заключения центра тестирования. Однако наличие сертификата совместимости от «Русбитех-Астра» (Astra Linux) или «Ред Софт» (РЕД ОС) является весомым аргументом при экспертизе и существенно снижает риск замечаний. Ряд разработчиков получает такой сертификат параллельно с подготовкой к доверенному статусу.
Astra Linux SE имеет несколько уровней защиты. На каком тестировать?
Astra Linux Special Edition поставляется в нескольких редакциях с разными уровнями защищённости: «Орёл» (базовый), «Воронёж» (усиленный) и «Смоленск» (максимальный). Для большинства коммерческих приложений актуальна проверка на уровне «Орёл» или «Воронёж». Уровень «Смоленск» с полным мандатным управлением доступом используется в силовых структурах и создаёт максимальные требования к совместимости. Конкретный уровень для тестирования нужно согласовать с центром тестирования при подготовке к экспертизе.
Наш продукт работает через браузер. Какой браузер использует центр тестирования?
Для web-приложений проверяется работа в среде доверенного браузера на доверенной ОС. Перечень доверенных браузеров также ведётся Минцифры — по состоянию на начало 2026 года в него входит Яндекс Браузер. Конкретный браузер и его версию, используемые при экспертизе, стоит уточнить в центре тестирования до начала работ — и именно в этой среде провести внутреннее тестирование.
Можно ли использовать Wine или другие слои совместимости для обеспечения работы на доверенных ОС?
Использование Wine и аналогичных слоёв совместимости не является допустимым способом подтверждения совместимости с доверенными ОС для целей постановления № 1937. Требование предполагает нативную работу продукта в среде доверенной ОС — не эмуляцию Windows-окружения. Продукт, запускающийся только через Wine, фактически не совместим с доверенными ОС в смысле данного требования.
Если мы выбрали две ОС для тестирования, можем ли мы позже добавить третью без повторной полной процедуры?
Добавление совместимых ОС в реестровую запись после получения доверенного статуса — процедура актуализации сведений, которая проще и быстрее полной повторной процедуры. Стратегически разумно начинать с двух наиболее распространённых у целевых заказчиков ОС, а расширять список по мере необходимости. Это не требует повторной экспертизы при каждом добавлении ОС.
Совместимость с доверенными ОС — решаемая задача при правильной подготовке
Реестр Гарант проводит технический аудит совместимости с доверенными ОС как отдельную услугу и в рамках полного сопровождения. Главная ценность аудита — честная оценка объёма доработки до того, как компания входит в официальную процедуру. Это позволяет планировать бюджет и сроки реалистично, а не обнаруживать проблемы на экспертизе, когда времени и денег на исправление значительно меньше.
Оценить совместимость вашего продукта с доверенными ОС
Расскажите об архитектуре продукта и текущей платформе — проведём аудит и дадим конкретную оценку объёма доработок и сроков подготовки к экспертизе.
Телефон / WhatsApp / Telegram: +7 920-898-17-18
Email: reestrgarant@mail.ru
Первичная консультация бесплатная в рабочее время.
