Всё о получении статуса доверенного ПО: этапы, требования, сроки и наши услуги.
Материал давал техническую детализацию требования совместимости с доверенными ОС редкого для этого кластера уровня: по типам продуктов, процедуре тестирования, исключениям. Но одно утверждение о браузерах было неточным, а венчали текст вымышленная статистика и рекламный блок с ценами. Уточняем факт о браузерах, убираем недоказуемые цифры, оставляем техническую часть.
Главное: требование совместимости минимум с двумя доверенными операционными системами из перечня Минцифры: одно из пяти условий доверенного статуса по постановлению №1937. «Совместимость» понимается функционально: не факт запуска, а корректная работа всей заявленной функциональности продукта в среде доверенной ОС, что проверяет аккредитованный центр тестирования. Два исключения снимают это требование: ПО в составе программно-аппаратного комплекса с технической привязкой к аппаратной платформе и случай, когда правообладатель ПО и правообладатель ОС входят в одну группу лиц.
| Утверждение из старой версии статьи | Реальное положение дел |
|---|---|
| «Перечень доверенных браузеров ведёт Минцифры, в него входит Яндекс Браузер» — как отдельный официальный реестр | Отдельного реестра доверенных браузеров не существует; браузеры входят в общий реестр российского ПО как обычный класс продуктов, а требование о поддержке российских браузеров — часть общей логики доверенного статуса, а не отдельный сертифицированный список |
| Стоимость аудита совместимости «от 50 000 ₽», срок «5 дней», статистика «95% успешных включений с первого раза» | Такие цифры не подтверждаются официальными источниками |
Что такое доверенные операционные системы
Доверенные операционные системы — отдельная категория в реестре российского ПО, соответствующая критериям постановления №1937: включение ОС в перечень означает, что она сама прошла или проходит процедуру получения доверенного статуса по тем же правилам, что и прикладное ПО. Перечень ведёт и обновляет Минцифры как часть ФГИС «Реестр программного обеспечения» — это живой документ, и актуальную версию нужно проверять непосредственно перед началом работ по совместимости: ОС, выбранная для тестирования сегодня, должна оставаться в перечне к моменту экспертизы.
В перечень входят преимущественно отечественные дистрибутивы на базе Linux. Среди наиболее распространённых в государственном секторе — Astra Linux Special Edition («Русбитех-Астра»), РЕД ОС («Ред Софт»), ROSA Linux (НТЦ ИТ РОСА), Alt Linux и дистрибутивы на его основе («Базальт СПО»). Для серверных конфигураций доступны серверные редакции большинства из перечисленных систем.
Что именно означает «совместимость» в требовании
Слово «совместимость» здесь понимается функционально — не просто факт запуска, а корректная работа заявленной функциональности продукта в среде доверенной ОС. Совместимостью считается: штатная установка продукта, корректная работа всех заявленных функций, правильное отображение пользовательского интерфейса, работающие интеграции с другими системами, сохранение и считывание данных без ошибок, производительность в разумных пределах. Совместимостью не считается: запуск с частично неработающими функциями, критические ошибки интерфейса, нестабильная работа с частыми сбоями, установка через нестандартные обходные манёвры, работа только в режиме эмуляции Windows-среды.
Специфика совместимости для разных типов продуктов
| Тип продукта | Как проверяется совместимость | Типичные проблемы |
|---|---|---|
| Нативное десктопное приложение | Прямой запуск и проверка функциональности на доверенной ОС | Windows-специфичные API, WinAPI-зависимости, .NET Framework без кросс-платформенных аналогов |
| Веб-приложение | Работа в браузере, поддерживаемом на доверенной ОС | Несовместимость с российскими браузерами, использование устаревших веб-стандартов |
| Серверное ПО | Запуск в серверной конфигурации на доверенной серверной ОС | Сервисы, привязанные к Windows Service Manager; проблемы с systemd-интеграцией |
| СУБД | Полноценная работа, включая кластер, репликацию, резервное копирование | Специфика ядра Linux при работе с памятью и файловой системой; драйверы хранилищ |
| ПО с агентами на хостах | Агент и серверная часть проверяются оба на доверенных ОС | Kernel-модули, системные вызовы, специфика Astra Linux SE с мандатным управлением доступом |
| ПО в составе ПАК | Может применяться исключение — проверка на нативной платформе | Требует документального обоснования неотделимости от аппаратной части |
Как выбрать две доверенные ОС для тестирования
Формально разработчик может выбрать любые две ОС из актуального перечня, но на практике выбор стоит делать осмысленно. Первый фактор: распространённость у целевых заказчиков. Astra Linux Special Edition де-факто стандарт в силовых ведомствах и значительной части государственных структур, РЕД ОС активно используется в гражданских государственных органах, и совместимость с реально используемыми заказчиками системами имеет не только формальное значение для процедуры, но и практическую ценность.
Второй фактор: технические особенности конкретной ОС. Astra Linux SE поставляется в нескольких редакциях с разными уровнями защищённости: «Орёл» — базовый уровень с дискреционным управлением доступом для обычного использования, «Воронеж» — усиленный уровень с мандатным контролем целостности и замкнутой программной средой для данных ограниченного доступа, «Смоленск» — максимальный уровень с полным мандатным управлением доступом для работы со сведениями, составляющими гостайну. Для большинства коммерческих продуктов достаточно проверки на уровне «Орёл» или «Воронеж»; «Смоленск» создаёт заметно более высокие требования к совместимости и актуален прежде всего для продуктов, ориентированных на силовые структуры.
Третий и четвёртый факторы: доступность технической поддержки от разработчика ОС и совместимость компонентного стека: версии libc, ядра Linux, systemd и графических подсистем различаются между дистрибутивами, и это стоит проверить заранее, а не в ходе экспертизы.
Исключения из требования совместимости
Постановление № 1937 целиком: реквизиты, сроки и точные формулировки
Речь о постановлении Правительства Российской Федерации от 28 ноября 2025 г. № 1937 «О внесении изменений в некоторые акты Правительства Российской Федерации» — в редакции постановления Правительства РФ от 25 декабря 2025 г. № 2139. Оно вступило в силу 1 марта 2026 года и правит Правила формирования и ведения единого реестра российских программ для ЭВМ и баз данных, утверждённые постановлением Правительства РФ от 16 ноября 2015 г. № 1236. Ниже — то, что в нём стоит числом и что определяет исход заявки.
| Что установлено | Значение | Норма |
|---|---|---|
| Сколько доверенных ОС нужно | Не менее 2 операционных систем, соответствующих требованиям к доверенному программному обеспечению | Подпункт «м» пункта 5 Правил (для реестра ЕАЭС — подпункт «м» пункта 42) |
| Когда достаточно одной ОС | Два случая: правообладатель ПО и правообладатель ОС входят в одну группу лиц; ПО используется исключительно в составе программно-аппаратного комплекса | Абзацы второй и третий подпункта «м» пункта 5 |
| Срок на подтверждение ПАК после включения в реестр | Не позднее 6 месяцев с момента включения сведений о ПО заявитель обязан внести в реестр сведения о программно-аппаратном комплексе, в составе которого используется это ПО | Пункт 30(6) Правил |
| Что будет, если срок пропущен | При отсутствии в реестре сведений о ПАК либо сведений о совместимости не менее чем с 2 операционными системами разных правообладателей уполномоченный орган принимает решение об исключении ПО из реестра | Пункт 30(6) Правил, абзац второй |
| Как быстро обновляют запись о совместимости | В течение 5 рабочих дней со дня утверждения экспертным советом заключения о совместимости ПО с доверенной ОС | Правила, порядок внесения изменений в сведения по подпункту «ф» пункта 4 |
| План проверок уже включённого ПО | Минцифры России в 6-месячный срок со дня официального опубликования постановления утверждает план проверок сведений о ПО в обоих реестрах на соответствие подпунктам «м» пунктов 5 и 42 Правил | Пункт 2 постановления № 1937 |
| Порог по выручке внутри группы лиц | Не более 30 % общей выручки правообладателя от реализации ПО за истекший календарный год — только для госкорпораций, госкомпаний, публично-правовых компаний и организаций, где прямое и (или) косвенное участие Российской Федерации, субъекта РФ или муниципального образования в совокупности превышает 50 %, а также организаций из одной с ними группы лиц | Подпункт «н» пункта 5 Правил |
| Сколько хранятся электронные документы заявки | Весь период с момента включения сведений о ПО или ПАК в реестр | Пункт 15 Правил |
Три вещи из этой таблицы стоят того, чтобы их проговорить отдельно.
«Две ОС» — это две ОС разных правообладателей. Формулировка про исключение из реестра называет их прямо: «не менее чем с 2 операционными системами разных правообладателей». Совместимость с двумя дистрибутивами одного вендора требование не закрывает.
Шесть месяцев — не рекомендация, а срок до исключения. Если продукт вошёл в реестр по «одной ОС в составе ПАК», отсчёт пошёл с даты включения сведений: за полгода в реестре должна появиться запись о самом программно-аппаратном комплексе. Не появилась — уполномоченный орган исключает ПО.
Проверять будут и тех, кто уже в реестре. Пункт 2 постановления обязывает Минцифры за шесть месяцев со дня опубликования утвердить план проверок уже включённых записей на соответствие требованию о совместимости. То есть норма работает не только на новые заявки.
Сами требования к доверенному программному обеспечению установлены не этим постановлением: оно ссылается на части 37 и 39 статьи 2 Федерального закона «О внесении изменений в Федеральный закон „О безопасности критической информационной инфраструктуры Российской Федерации“». В самом реестре появились две новые графы — информация о совместимости с операционными системами (подпункт «ф» пункта 4 Правил) и информация о соответствии ПО требованиям к доверенному ПО (подпункт «ц» пункта 4).
Реквизиты и сроки приведены по состоянию на 27 августа 2026 года. Правила ведения реестра правят часто — перед подачей сверяйте редакцию на дату обращения.
Постановление предусматривает два случая, когда требование совместимости с двумя доверенными ОС не применяется, и оба требуют документального обоснования, а не работают автоматически. Первое исключение: ПО как неотъемлемая часть программно-аппаратного комплекса, где работа продукта технически обусловлена конкретной аппаратной платформой, ПО не поставляется и не функционирует отдельно от аппаратной части, требуется детальное техническое обоснование неотделимости. Второе исключение: правообладатель ПО и правообладатель операционной системы входят в одну группу лиц по критериям антимонопольного законодательства (135-ФЗ); это актуально прежде всего для вертикально интегрированных ИТ-компаний и требует документального подтверждения аффилированности.
Как проходит проверка совместимости в центре тестирования
Экспертиза — не формальная проверка факта запуска. Центр тестирования разворачивает выбранные доверенные ОС в конфигурации, типичной для использования данной категории продукта: серверная конфигурация для серверного ПО, рабочая станция для десктопных приложений. Продукт устанавливают штатным способом, описанным в документации; нестандартные процедуры установки уже на этом этапе вызывают замечания. Затем проверяют каждую заявленную в реестровой записи функцию отдельно и, если продукт интегрируется с другими системами, корректность этих интеграций в среде доверенной ОС. По результатам центр формирует заключение: положительное, если совместимость подтверждена, либо с замечаниями — перечнем проблем, которые нужно устранить, что означает доработку продукта и повторную проверку с дополнительными временем и расходами.
Разрыв между «теоретически можно запустить» и «полноценно работает на уровне, достаточном для государственного заказчика», на практике оказывается одним из главных источников задержек и отрицательных заключений. Причина в том, что большинство коммерческих продуктов изначально разрабатывались для Windows-среды без расчёта на совместимость с отечественными Linux-дистрибутивами, и обнаружить весь объём Windows-специфичных зависимостей проще заранее, через внутренний аудит на собственном тестовом стенде, а не постфактум по замечаниям центра тестирования.
Подготовка к проверке: практические шаги
Чтобы экспертиза завершилась положительным заключением с первого раза, совместимость разумно проверить и подтвердить ещё до подачи заявления. Первый шаг: полная инвентаризация платформо-специфичных компонентов: Windows API, COM/DCOM, .NET Framework, реестр Windows, Windows-специфичные системные службы, поскольку каждая такая зависимость — потенциальная точка несовместимости. Второй шаг: тестовый стенд с выбранными доверенными ОС в конфигурации, максимально близкой к той, что использует центр тестирования. Третий — итеративная доработка: замена Windows-специфичных библиотек на кросс-платформенные аналоги, адаптация инсталлятора, переработка проблемных компонентов, с повторным тестированием после каждого цикла. Четвёртый — документирование результатов внутреннего тестирования: тестовые сценарии, конфигурации сред, итоги проверок, это ускоряет экспертизу и демонстрирует готовность продукта центру тестирования.
Ориентировочный объём доработки по типу продукта
Расходы на обеспечение совместимости несёт сама компания или её подрядчик: это отдельная статья бюджета, не входящая ни в консалтинговое сопровождение, ни в стоимость экспертизы центра тестирования.
| Ситуация с продуктом | Ориентировочный объём доработки | Ориентировочный срок |
|---|---|---|
| Кросс-платформенный продукт на Java, Go, Python | Минимальный: тестирование и документация | 1–2 недели |
| Веб-приложение без нативных компонентов | Адаптация под российские браузеры, проверка веб-стандартов | 2–4 недели |
| Частичная Windows-зависимость (отдельные модули) | Замена проблемных компонентов на кросс-платформенные | 1–3 месяца |
| Глубокая Windows-интеграция (.NET, WinAPI, COM) | Серьёзная переработка архитектурных компонентов | 3–8 месяцев |
| Промышленное ПО с аппаратными зависимостями | Разработка Linux-драйверов, адаптация протоколов | 6–18 месяцев |
| Продукт уровня ядра ОС (антивирус, агент мониторинга) | Разработка kernel-модулей для каждой доверенной ОС | 3–9 месяцев |
Вопросы и ответы
Короткие ответы на вопросы, которые чаще всего возникают при подготовке документов и подаче заявки.
Нужно ли получать сертификат совместимости от производителя ОС?
Формально постановление №1937 не требует сертификата совместимости от производителя ОС — достаточно положительного заключения центра тестирования. Но наличие сертификата совместимости от «Русбитех-Астра» или «Ред Софт» служит весомым аргументом при экспертизе и снижает риск замечаний, поэтому часть разработчиков получает такой сертификат параллельно с подготовкой к доверенному статусу.
Astra Linux SE имеет несколько уровней защиты — на каком тестировать?
Для большинства коммерческих продуктов достаточна проверка на уровне «Орёл» или «Воронеж». Уровень «Смоленск» с полным мандатным управлением доступом используется в силовых структурах и создаёт максимальные требования к совместимости. Конкретный уровень для тестирования стоит согласовать с центром тестирования при подготовке к экспертизе.
Продукт работает через браузер — какой браузер используется при проверке?
Отдельного официального реестра доверенных браузеров не существует: требование заключается в поддержке российских браузеров как части общей совместимости с доверенной средой. Яндекс Браузер — самый распространённый российский браузер и типичный кандидат для тестирования, но конкретный браузер и его версию для экспертизы стоит уточнить в центре тестирования до начала работ.
Можно ли использовать Wine или другие слои совместимости для работы на доверенных ОС?
Нет. Требование предполагает нативную работу продукта в среде доверенной ОС, а не эмуляцию Windows-окружения. Продукт, запускающийся только через Wine, фактически не совместим с доверенными ОС в смысле этого требования.
Можно ли позже добавить третью совместимую ОС без повторной полной процедуры?
Да. Добавление совместимых ОС в реестровую запись после получения статуса — процедура актуализации сведений, которая проще и быстрее полной повторной процедуры и не требует новой экспертизы по каждой добавляемой ОС. Стратегически разумно начинать с двух наиболее распространённых у целевых заказчиков систем, а расширять список по мере необходимости.
Источники
- КонсультантПлюс, порядок формирования перечня доверенного ПО: требование совместимости с доверенными ОС и исключения по постановлению №1937.
- Реестр российского программного обеспечения, Минцифры России: перечень доверенных операционных систем и общий реестр ПО, включая браузеры.
