Переход на доверенное ПО редко упирается в поиск российского аналога. Сложнее определить, какие требования действуют именно для конкретной системы, какие решения нужно заменить уже сейчас, а какие попадут под новые правила позже. Значимый объект КИИ, ГИС, защитный контур, виртуализация и промышленное ПО подчиняются разным основаниям и срокам. Если свести их в одну миграционную программу, компания рискует начать не с того участка, заложить в архитектуру несовместимые решения и обнаружить критичные зависимости уже после закупки.Как разделить регуляторные контуры, проверить не только статус продукта, но и его место в целевой архитектуре, выстроить очередность миграции и не превратить формальное соответствие требованиям в дорогую перестройку инфраструктуры, рассказывает Дмитрий Битченков, директор департамента сопровождения конкурентных процедур компании «ГИГАНТ — Компьютерные системы», преподаватель дисциплины «Документирование в сфере закупок» РТУ МИРЭА.Реестровая запись больше не гарантирует закупочный приоритет

При закупках по Законам № 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. Дальние сроки из проектов документов воспринимают как автоматическую отсрочку, не проверяя, относятся ли они к конкретному объекту и организации.

Третья группа ошибок проявляется уже в архитектуре. Компания проверяет реестровый статус, но не тестирует производительность, интеграции, обновления, отказоустойчивость и работу поддержки. Миграция начинается без проверенного восстановления и плана отката. Пилот проводится на упрощенном стенде, где нет реальных объемов данных, действующих политик безопасности и смежных систем. После формально успешного испытания проблемы обнаруживаются в промышленном контуре.

Наконец, многие проекты изначально ограничивают сами себя техническим заданием, написанным как описание иностранного продукта. В него переносят названия функций, внутреннюю структуру и привычные интерфейсы вместо того, чтобы определить, какой результат должна обеспечивать новая система. В итоге организация либо не находит полного аналога, либо получает российское решение, которое формально соответствует документам, но не соответствует архитектуре и процессам эксплуатации.

Доверенность нельзя рассматривать как свойство отдельной коробки с программным обеспечением. Она должна подтверждаться по всей цепочке: правовой статус продукта, совместимость платформ, конфигурация, интеграции, безопасность, обновления, восстановление и поддержка. Реестровая отметка открывает продукту дорогу в проект, но не отвечает на главный вопрос - сможет ли компания безопасно заменить им действующую систему и затем годами эксплуатировать ее под реальной нагрузкой.

Глеб Ковалев, руководитель ИТ-отдела, «ГИГАНТ — Компьютерные системы» рассказал о том, для каких организаций действительно оправдано внедрение систем выявления инсайдерских угроз, а также о том, с чего стоит начинать построение такой защиты. Он объяснил, какие технические и организационные требования нужно выполнить до внедрения DLP и UEBA, по каким критериям выбирать решение, если сравниваешь несколько продуктов, и какие показатели после запуска реально говорят о том, что система работает, а не просто сыпет уведомлениями. 

— Для каких организаций и сценариев внедрение систем выявления инсайдерских угроз сегодня действительно оправдано, а в каких случаях их использование будет избыточным?

Системы выявления инсайдерских угроз жизненно необходимы в случаях, когда компания работает с критически важной, коммерчески чувствительной или персональной информацией, где потенциальный ущерб от утечки существенно превышает стоимость внедрения и эксплуатации системы. Это могут быть банки, промпредприятия, телеком-операторы, ИТ-компании, объекты КИИ, государственные ведомства и организации, а также компании, которые разрабатывают собственные технологии, программное обеспечение и конструкторскую документацию.

Чем крупнее компания, тем больше сотрудников, удаленных пользователей, подрядчиков и тем чаще используются облачные сервисы и сложные системы доступа к данным. Это повышает риски утечек. Например, сотрудник отправляет документы в личный аккаунт в мессенджере или на личную почту, сохраняет в стороннее облако, перекидывает на флешку, в том числе клиентские базы. Иногда без всякого злого умысла, а потому что хочет поработать в командировке или в отпуске, но бывает и так, что критически важную информацию собирают увольняющиеся сотрудники. 

Организациям с небольшим объемом чувствительных данных и простой инфраструктурой на первом этапе может быть достаточно базовых мер: разграничить доступ, использовать многофакторную аутентификацию и журналирование, контролировать подключаемые устройства и своевременно отзывать права при увольнении. В крупных и распределенных средах базовых мер часто оказывается недостаточно, уже не обойтись без полноценного комплекса DLP, UEBA и других специализированных средств.

Также на выбор влияет стоимость потенциального инцидента и способность обеспечить полноценное управление системой мониторинга. Пока не будут определены защищаемые данные, ответственные сотрудники и порядок реагирования, даже дорогое решение не поможет реально повысить уровень безопасности.

— С чего стоит начинать построение системы защиты от инсайдерских угроз, чтобы избежать типичных ошибок на этапе внедрения?

Прежде чем выбирать подходящее решение, нужно оценить риски и стоимость инцидента. Для этого необходимо определить, какие данные и бизнес-процессы имеют критическое значение, у кого есть к ним доступ, как они передаются и к каким последствиям приведет их утечка. Затем проверить действующую модель доступа: избыточные права, лишние учетные записи, неактуальные разрешения и так далее.

Следующий шаг — описать сценарии обнаружения и способы реагирования. Например, резкое увеличение объема выгружаемых данных, доступ к чувствительной информации в нетипичное для пользователя время, обращение к несвойственным пользователю ресурсам или попытка передать документы за пределы корпоративного контура. До запуска системы необходимо определить, кто получает уведомление, кто подтверждает инцидент, кто принимает решение о блокировке операции и в каких случаях к расследованию подключаются ИТ, информационная безопасность, HR, юридический департамент и руководитель подразделения.

На первом этапе решение можно протестировать в ограниченном контуре на одном-двух сценариях, чтобы оценить нагрузку на инфраструктуру и способность команды работать с инцидентами. А затем постепенно подключать и отлаживать другие сценарии. В вопросах защиты от инсайдерских угроз надежда на то, что утечки не произойдёт, - плохая стратегия: процессы обнаружения и реагирования должны быть выстроены заранее.

— Какие технические и организационные требования необходимо выполнить до внедрения DLP, UEBA или других средств выявления инсайдерской активности?

В первую очередь нужно привести в порядок базовую инфраструктуру — актуализировать сведения о пользователях, подразделениях, должностях и ролях, внедрить централизованное управление учетными записями, уникальные логины и многофакторную аутентификацию для критичных систем и удаленного доступа. Определить, где находятся чувствительные данные, кто является их владельцем, как они классифицируются и какие операции с ними допустимы.

Для поведенческой аналитики особенно важно качество исходной телеметрии. Требуется обеспечить синхронизацию времени, централизованный и защищенный сбор журналов с рабочих мест, серверов, почтовых систем, прокси, VPN, систем управления доступом, файловых хранилищ и бизнес-приложений, иначе аналитика будет давать неточные результаты. События должны однозначно связываться с конкретным пользователем или сервисной учетной записью, нормализоваться и храниться достаточно долго для построения базового профиля и расследования.

— По каким критериям следует выбирать решение для выявления инсайдерских угроз, если компания сравнивает несколько продуктов?

Выбирать решение необходимо исходя из конкретных рисков и инфраструктуры компании. Сначала необходимо определить контролируемые среды и каналы: рабочие станции, электронную почту, веб-трафик, мессенджеры, USB-устройства, облачные хранилища, виртуальные рабочие места. Затем оцениваем качество контентного анализа, распознавания русскоязычных данных, работы со словарями, применения OCR, анализа контекста и поведенческих аномалий. Отдельно проверяем уровень ложных срабатываний. Большое количество событий не показатель эффективности, наоборот специалисты могут оказаться перегруженными и пропустить действительно опасные события.

Решение должно иметь функции расследования (единая временная шкала действий пользователя, быстрый поиск по событиям, визуализация цепочки операций) и поддерживать различные варианты реагирования - от уведомления ответственного сотрудника до блокировки передачи данных.

Также важно обращать внимание на масштабируемость, производительность, возможность работы в распределенной инфраструктуре, надежность, резервирование, защищенность самой системы и разграничение доступа администраторов. Особое значение имеют уровень локализации, наличие техподдержки, прозрачный жизненный цикл продукта и независимость от поставок зарубежных компонентов. Отдельно стоит оценить совокупную стоимость владения, в которую, кроме лицензий, стоит включить серверные ресурсы, внедрение, интеграции, обучение персонала, сопровождение и работу аналитиков. 

— Какие показатели наиболее объективно отражают эффективность системы выявления инсайдерских угроз после ее внедрения?

Иногда число срабатываний возрастает из-за некорректной настройки правил, а не потому, что улучшился контроль. Чтобы корректно оценить результат, нужна совокупность технических, операционных и бизнес-метрик.

Сюда мы относим долю подтвержденных инцидентов среди всех срабатываний, уровень ложных тревог, полноту обнаружения по заранее определенным контрольным сценариям и количество инцидентов, выявленных до фактической утечки данных. Идеально, если система позволяет максимально полно восстановить картину события: определить пользователя, данные, канал передачи и последовательность действий.

Еще важно оценить скорость реагирования: время от совершения подозрительного действия до срабатывания, среднее время подтверждения, локализации и закрытия инцидента, а также доля обращений, обработанных в рамках установленного SLA.

В операционном плане полезно отслеживать нагрузку на специалистов, долю автоматизированных реакций и доступность системы. А для руководства наиболее значимы бизнес-показатели: предотвращенные финансовые потери, снижение вероятности штрафов, сокращение ущерба от утечек. Эффективность системы определяется не числом уведомлений, а тем, насколько она помогает снижать риски, реагировать на угрозы и защищать важные для бизнеса данные.