«ГИГАНТ — Компьютерные системы»: доверенное ПО — почему реестровой записи недостаточно для миграции

Переход на доверенное ПО редко упирается в поиск российского аналога. Сложнее определить, какие требования действуют именно для конкретной системы, какие решения нужно заменить уже сейчас, а какие попадут под новые правила позже. Значимый объект КИИ, ГИС, защитный контур, виртуализация и промышленное ПО подчиняются разным основаниям и срокам. Если свести их в одну миграционную программу, компания рискует начать не с того участка, заложить в архитектуру несовместимые решения и обнаружить критичные зависимости уже после закупки.
Как разделить регуляторные контуры, проверить не только статус продукта, но и его место в целевой архитектуре, выстроить очередность миграции и не превратить формальное соответствие требованиям в дорогую перестройку инфраструктуры, рассказывает Дмитрий Битченков, директор департамента сопровождения конкурентных процедур компании «ГИГАНТ — Компьютерные системы», преподаватель дисциплины «Документирование в сфере закупок» РТУ МИРЭА.
Реестровая запись больше не гарантирует закупочный приоритет
При закупках по Законам № 44-ФЗ и № 223-ФЗ российское ПО без отметки о соответствии требованиям доверенного ПО в предусмотренных случаях приравнивается к иностранному для целей национального режима, если в процедуре участвует доверенное решение. Поэтому проверять нужно не только наличие продукта в реестре, но и конкретную версию, актуальность реестровой записи и отметки о соответствии требованиям доверенного ПО, и сведения о совместимости и состав фактически используемой конфигурации.
Следующий риск связан с совместимостью. Для регулируемых классов ПО потребуется подтвердить работу как минимум с двумя доверенными операционными системами. С 1 сентября 2026 года требование применяется к офисному ПО. С 1 января 2027 года требование затронет виртуализацию, облачные и распределенные вычисления, хранение данных, серверное ПО, СУБД, мониторинг и контейнеризацию, с 1 июня — прикладные и отраслевые системы, средства информационной безопасности и обработки данных, с 1 января 2028 года — промышленное ПО и системы управления процессами.
Поэтому проверять нужно не отдельный продукт, а всю технологическую связку. Если СУБД, платформа виртуализации, средства резервного копирования и прикладные системы рассчитаны на разные наборы ОС, соответствие одного компонента не решает задачу. К моменту вступления требований в силу замены или доработки может потребовать уже вся платформа.
КИИ, ГИС, средства защиты и облака нельзя объединять в один контур
Единого календаря миграции, одинакового для любой государственной или корпоративной информационной системы, нет. Обязательность применения конкретных решений зависит от вида системы, статуса организации, наличия значимых объектов КИИ, категории значимости, отрасли и состава обрабатываемой информации.
Указ Президента № 166 запрещает с 1 января 2025 года органам государственной власти и подпадающим под него заказчикам использовать иностранное ПО на принадлежащих им значимых объектах КИИ. Ограничение касается именно установленного указом круга организаций и значимых объектов. Его нельзя автоматически распространять на любую систему субъекта КИИ, как нельзя считать любую корпоративную информационную систему значимым объектом только из-за того, что ее остановка создаст сложности для бизнеса.
Для государственных информационных систем действуют требования национального режима, защиты информации, аттестации, сертификации и отраслевого регулирования. Но сам статус ГИС не означает, что каждый установленный в ней программный компонент автоматически обязан иметь доверенную отметку. Сначала необходимо определить требования, применимые к конкретной системе и конкретному классу ПО, и только затем формировать перечень допустимых решений.
Отдельно необходимо рассматривать средства защиты информации. Указ Президента № 250 с 1 января 2025 года запрещает указанным в нём органам и организациям использовать средства защиты информации, странами происхождения которых являются недружественные иностранные государства, а также средства защиты, производимые организациями, находящимися под контролем таких государств. Применимость запрета к конкретной организации следует определять по её статусу и основаниям, предусмотренным Указом № 250. Это самостоятельное требование, которое нельзя откладывать до будущих этапов перехода на доверенное прикладное или инфраструктурное ПО.
На практике под проверку могут попасть антивирусы, межсетевые экраны, DLP-, EDR- и SIEM-системы, средства контроля доступа и другие защитные решения. Однако принимать решение только по маркетинговому классу продукта нельзя. Для каждого решения нужно отдельно оценивать его функциональное назначение, страну происхождения, структуру контроля производителя, применимость требований к сертификации и фактическую роль в системе защиты.
Также важно разделять два облачных трека. Требование совместимости средств виртуализации и программного обеспечения для облачных вычислений с доверенными операционными системами регулирует свойства продукта и его реестровый статус. Само по себе оно не запрещает компании пользоваться иностранным облачным сервисом. Возможные ограничения использования зарубежных корпоративных облаков относятся к самостоятельному и пока развивающемуся регуляторному направлению; они не являются частью требований о совместимости ПО с доверенными ОС. Смешение этих вопросов приводит либо к лишним затратам, либо к ошибочному выводу, что текущая архитектура уже соответствует требованиям.
Инициатива об ограничении использования иностранных корпоративных облаков крупным бизнесом, в том числе для хранения и обработки персональных данных, должна рассматриваться как самостоятельный проектный трек. Она не является частью требований о совместимости с доверенными ОС и не должна подменять анализ действующих обязанностей организации.
Отдельного штрафа за «не успели перейти» может не быть, но риск остается
Компаниям опасно искать в КоАП одну статью с названием «нарушение срока перехода на доверенное ПО». Ответственность обычно наступает за конкретное нарушение: использование иностранного продукта там, где оно уже запрещено, несоблюдение требований безопасности значимого объекта КИИ, применение несертифицированного средства при обязательной сертификации, нарушение правил эксплуатации или доступа к объекту, а также ошибки при проведении регулируемой закупки.
В 2025 году были увеличены штрафы по статье 13.12 КоАП за отдельные нарушения правил защиты информации. В зависимости от состава максимальный штраф для юридических лиц может достигать 100 тыс. рублей.
С 20 апреля 2026 года действует статья 13.12.2 КоАП РФ. Она предусматривает ответственность за нарушение правил эксплуатации средств хранения, обработки или передачи охраняемой компьютерной информации, содержащейся в КИИ, а также правил доступа к такой информации и соответствующим системам, сетям и средствам связи. Для должностных лиц предусмотрен штраф от 10 тыс. до 50 тыс. рублей, для юридических лиц — от 100 тыс. до 500 тыс. рублей.
Уголовная ответственность по статье 274.1 УК РФ не возникает только из-за задержки миграции. Для нее необходимы самостоятельные признаки преступления и предусмотренные законом последствия. Но это не означает, что откладывание проекта безопасно. Чем дольше в критичном контуре сохраняется неподдерживаемое или запрещенное решение, тем сложнее отделить проблему миграции от нарушения требований к эксплуатации и защите системы.
Особенно рискованно опираться на упоминаемые в проектах нормативных актов, отраслевых планах или публичных обсуждениях сроки 2028-2036 годов как на универсальную отсрочку. Любая более поздняя дата должна относиться к конкретной организации, категории объекта и нормативному основанию. Такие сроки могут быть связаны, в частности, с особо значимыми проектами, индивидуально обоснованными решениями или специальными условиями перехода, а не с общим правом субъекта КИИ отложить миграцию. Она не отменяет уже действующие ограничения Указов № 166 и № 250 и не дает права сохранить иностранное решение только потому, что его замена технически сложна.
Миграция начинается с правового периметра, а не с выбора аналога
Первый результат проекта — не список российских продуктов, а карта регулируемых систем. В нее должны входить информационные системы, программно-аппаратные комплексы, лицензии, облачные сервисы, средства защиты, операционные системы, платформы виртуализации, СУБД, резервное копирование, мониторинг и прикладные решения. Для каждого объекта необходимо определить владельца, назначение, взаимосвязи, статус КИИ, категорию значимости, применимость Указов № 166 и № 250, требования к защите и основание для использования конкретного класса ПО.
Без такой квалификации организация почти неизбежно смешивает разные миграционные очереди. Средства защиты информации с уже наступившим сроком запрета оказываются в одной дорожной карте с промышленной системой, замена которой требует нескольких технологических остановов. Офисное ПО рассматривается одновременно с виртуализацией, хотя у них разные зависимости, риски и календарь требований. В результате команда начинает с наиболее заметного продукта, а не с наиболее критичного нарушения.
После определения периметра нужен единый владелец программы перехода и рабочая группа, куда входят ИТ, информационная безопасность, юристы, закупки, эксплуатация и владельцы бизнес-процессов. Это не формальность. Решение о замене СУБД может изменить прикладной слой, резервное копирование и требования к оборудованию. Переход на другую платформу виртуализации затрагивает мониторинг, автоматизацию, лицензирование и модель аварийного восстановления. Такие решения нельзя принимать внутри одного подразделения.
Для каждого кандидата следует формировать технический и юридический паспорт. В нем фиксируются точное наименование и версия продукта, класс ПО, номер реестровой записи, наличие доверенной отметки и актуальность сведений о её соответствии требованиям, совместимые операционные системы, лицензионная модель, сертификаты, условия поддержки, порядок выпуска обновлений и ограничения по используемым компонентам. Проверка только названия продукта недостаточна: разные версии одной системы могут иметь разный статус, набор совместимых платформ и состав сертифицированной конфигурации.
Следующий этап — анализ разрывов и пилотирование. Здесь проверяется не демонстрационный сценарий поставщика, а фактическая работа будущей системы: интеграции, миграция данных, производительность под бизнес-нагрузкой, отказоустойчивость, обновление, мониторинг, резервное копирование и восстановление. Отдельно нужно тестировать действия персонала при отказе и взаимодействие с технической поддержкой. Система, которая успешно прошла установку, но не была восстановлена из резервной копии, еще не готова к промышленной эксплуатации.
Критерии пилота должны быть измеримыми. Вместо формулировки «обеспечить высокую производительность» необходимо указать допустимое время ответа, количество транзакций, объем обрабатываемых данных и поведение при пиковой нагрузке. Вместо общего требования отказоустойчивости — определить RTO, RPO, допустимый простой, сценарий переключения и порядок возврата к основной площадке. Вместо обещания совместимости — провести тест на фактических версиях операционной системы, СУБД, драйверов, средств защиты и прикладных компонентов.
По итогам пилота формируется целевая архитектура и дорожная карта. В ней фиксируются миграционные очереди, технологические зависимости, бюджеты, ответственные, окна переключения, период параллельной эксплуатации, критерии приемки и план отката. До начала работ необходимо иметь актуальную резервную копию, доказанное восстановление из нее и понятный сценарий возврата. Наличие файла резервной копии без проведенного теста восстановления не снижает риск миграции.
Закупочная документация должна описывать функциональные, архитектурные и измеримые требования к результату, а не воспроизводить интерфейс и техническую структуру конкретного иностранного продукта. Иначе компания либо искусственно сужает конкуренцию, либо приобретает российскую систему, которую вынуждена использовать в чужой для нее архитектуре. Реестровый и доверенный статус нужно проверять при рассмотрении заявки, заключении договора и приемке, а не только при подготовке технического задания.
После запуска контроль не заканчивается. Необходимо отслеживать изменения реестровой записи, актуальность сведений о соответствии требованиям доверенного ПО, сертификатов, появление уязвимостей, выпуск обновлений, качество поддержки и соответствие фактической конфигурации принятой архитектуре. Если после внедрения система была обновлена, дополнена сторонним модулем или переведена на другую операционную систему, формальное соответствие первоначальной закупке уже ничего не говорит о текущем состоянии контура.
Где проекты чаще всего ломаются
Первая группа ошибок возникает при юридической квалификации. Компания считает доверенной любую программу из реестра российского ПО, переносит требования значимого объекта КИИ на все корпоративные системы или, наоборот, не включает в периметр систему, которая фактически используется на значимом объекте. К этому же относится попытка объединить офисное ПО, виртуализацию, СУБД, промышленный контур и средства защиты в одну миграционную очередь без учета разных оснований и сроков.
Вторая группа связана с неверным прочтением отдельных требований. Совместимость облачного ПО с доверенными операционными системами принимают за запрет иностранных облаков. Переход на доверенное прикладное ПО считают достаточным выполнением требований, хотя в критичном контуре продолжают использоваться иностранные СЗИ, подпадающие под Указ № 250. Дальние сроки из проектов документов воспринимают как автоматическую отсрочку, не проверяя, относятся ли они к конкретному объекту и организации.
Третья группа ошибок проявляется уже в архитектуре. Компания проверяет реестровый статус, но не тестирует производительность, интеграции, обновления, отказоустойчивость и работу поддержки. Миграция начинается без проверенного восстановления и плана отката. Пилот проводится на упрощенном стенде, где нет реальных объемов данных, действующих политик безопасности и смежных систем. После формально успешного испытания проблемы обнаруживаются в промышленном контуре.
Наконец, многие проекты изначально ограничивают сами себя техническим заданием, написанным как описание иностранного продукта. В него переносят названия функций, внутреннюю структуру и привычные интерфейсы вместо того, чтобы определить, какой результат должна обеспечивать новая система. В итоге организация либо не находит полного аналога, либо получает российское решение, которое формально соответствует документам, но не соответствует архитектуре и процессам эксплуатации.
Доверенность нельзя рассматривать как свойство отдельной коробки с программным обеспечением. Она должна подтверждаться по всей цепочке: правовой статус продукта, совместимость платформ, конфигурация, интеграции, безопасность, обновления, восстановление и поддержка. Реестровая отметка открывает продукту дорогу в проект, но не отвечает на главный вопрос — сможет ли компания безопасно заменить им действующую систему и затем годами эксплуатировать ее под реальной нагрузкой.
Источник: https://globalcio.ru/discussion/61935/?sphrase_id=51398