Новые угрозы — новые правила: эволюция российского законодательства в сфере ИТ и ИБ

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

Эта статья — третья часть цикла. В первой мы разбирали, как менялись цели и методы атак, во второй — как это проявилось в статистике реальных инцидентов. Теперь посмотрим на ответ государства: как регулирование прошло путь от защиты отдельных систем к технологической независимости, постоянному мониторингу и требованию быть готовым к инциденту не «на бумаге», а в реальной эксплуатации.

До 2022 года: фундамент был, но под другую модель риска

2022 год не создал российское регулирование ИБ с нуля. К этому моменту уже существовала достаточно развитая нормативная база: требования к защите государственных информационных систем, информационных систем персональных данных и АСУ ТП, отдельный контур регулирования КИИ и ГосСОПКА, процедуры категорирования и аттестации, требования к организационным и техническим мерам защиты. Параллельно уже несколько лет развивалась политика импортозамещения — действовал реестр российского ПО, а для государственных заказчиков были установлены ограничения на закупку иностранных программных продуктов. Поэтому правильнее будет сказать иначе: после 2022 года изменилась не исходная конструкция, а режим, в котором ей пришлось работать.

Еще Доктрина информационной безопасности РФ, утвержденная Указом Президента РФ от 05.12.2016 № 646, относила устойчивое функционирование информационной инфраструктуры к национальным интересам и прямо указывала на рост сложности и координированности компьютерных атак. В том же документе была обозначена зависимость отечественной промышленности от зарубежного ПО, вычислительной техники, электронной компонентной базы и средств связи. То есть будущая проблема была видна задолго до того, как стала операционной.

Практический каркас появился с Федеральным законом от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». Закон определил субъекты и объекты КИИ, ввел категорирование по последствиям возможного инцидента, закрепил обязанности по защите значимых объектов и связал их с ГосСОПКА. Постановление Правительства РФ от 08.02.2018 № 127 перевело эту логику в процедуру: объект нужно выявить, оценить последствия нарушения его работы, присвоить категорию и направить сведения регулятору.

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

По сути, это была объектно-ориентированная модель. В центре внимания находилась конкретная информационная система, сеть или АСУ: насколько она критична и какие меры ей положены. Для своего времени подход был логичным и достаточно подробным.

Причем говорить, что требования были только формальными, было бы неверно. Приказ ФСТЭК России от 25.12.2017 № 239 уже требовал идентификацию и аутентификацию, управление доступом, аудит безопасности, предотвращение вторжений, управление конфигурациями и обновлениями, реагирование на инциденты и действия в нештатных ситуациях. Большая часть того, что сегодня называют базовой инженерной гигиеной ИБ, в нормативной базе уже была.

Проблема была не в отсутствии требований: требования были. Ограничение было в модели риска, под которую они создавались.

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

Это хорошо видно по ранней политике импортозамещения. Постановление Правительства РФ от 16.11.2015 № 1236 сформировало реестр российского ПО и ограничения на закупку иностранного программного обеспечения для государственных и муниципальных нужд. Вопрос тогда звучал преимущественно так: есть ли российский аналог и можно ли закупать иностранное решение.

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

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

Эта позиция закреплена в Указе Президента РФ от 12.04.2021 № 213 и Указе Президента РФ от 02.07.2021 № 400. К концу 2021 года основные риски уже были названы: атаки на КИИ, межгосударственное информационное противоборство, зависимость от иностранных технологий. Государство понимало проблему, но сама эксплуатационная модель инфраструктуры пока менялась гораздо медленнее.

Эту дистанцию и сократил 2022 год. Резкий рост числа атак совпал с ограничением доступа к ряду иностранных технологий, и прежние представления об устойчивости пришлось пересматривать. Возник вполне практический вопрос: насколько надежен критический процесс, если его работа зависит от поставщика, который может прекратить поддержку, выпуск обновлений или действие лицензий? Так в повестке ИБ появился еще один обязательный вопрос. Уже недостаточно было понимать, что именно защищать и какие средства для этого применять. Пришлось смотреть глубже: на каких технологиях работает система, от кого она зависит и кто в действительности контролирует ее жизненный цикл.

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

2022–2023 годы: безопасность выходит из режима обычного комплаенса

В 2022 году подход государства к ИБ заметно меняется. В центре внимания оказываются три вещи: зависимость от иностранных технологий, личная ответственность руководителей и порядок действий при киберинцидентах. Причем изменения идут почти одновременно и довольно быстро доходят до уровня конкретных требований к организациям.

Технологическая зависимость становится риском безопасности

Серьезный поворот закрепил Указ Президента РФ от 30.03.2022 № 166. Для значимых объектов КИИ он ограничил закупку иностранного ПО без согласования и задал курс на переход к отечественному программному обеспечению, радиоэлектронной продукции и телекоммуникационному оборудованию. С этого момента импортозамещение уже трудно рассматривать как обычный вопрос закупок: от происхождения технологий напрямую начинает зависеть устойчивость критической инфраструктуры.

Через несколько месяцев Постановление Правительства РФ от 22.08.2022 № 1478 задает практические правила: требования к ПО на значимых объектах, порядок согласования иностранного ПО и переход на российские решения. Технологический стек регулируемой организации фактически становится самостоятельным объектом контроля.

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

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

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

ИБ становится ответственностью руководства

Вторая линия — управление. Указ Президента РФ от 01.05.2022 № 250 закрепляет полномочия в области ИБ за заместителем руководителя, требует создать или определить профильное подразделение и вводит персональную ответственность руководителей соответствующих органов и организаций за обеспечение информационной безопасности.

Детали закрепляет Постановление Правительства РФ от 15.07.2022 № 1272: ответственное лицо получает прямое подчинение руководителю, а подразделение ИБ — задачи по защите ресурсов, обнаружению атак, реагированию и снижению последствий нарушения работы систем.

Это не косметическая перестановка должностей. ИБ поднимается с уровня «технической функции» на уровень управленческой ответственности. Появляется тот, кто должен не только согласовать документ, но и отвечать за способность организации выдержать реальный инцидент.

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

Инцидент требует заранее подготовленного сценария

Еще одно заметное изменение касается работы с инцидентами. Федеральный закон от 14.07.2022 № 266-ФЗ обязал операторов персональных данных сообщать о нарушениях безопасности: первичное уведомление направляется в течение 24 часов, результаты внутреннего расследования — в течение 72 часов. Для компьютерных инцидентов, связанных с неправомерной передачей персональных данных, также закрепляется взаимодействие с ГосСОПКА.

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

В 2023 году Приказ ФСБ России от 13.02.2023 № 77 конкретизирует взаимодействие операторов с ГосСОПКА через НКЦКИ. Инцидент все меньше остается внутренней проблемой компании: он становится источником информации для общего механизма обнаружения и анализа атак.

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

От замены продукта к управляемой технологической базе

В 2023 году экстренные решения начинают превращаться в долгосрочную политику. Концепция технологического развития до 2030 года, утвержденная распоряжением Правительства РФ от 20.05.2023 № 1315-р, закрепляет технологический суверенитет как цель и связывает его с наличием критических технологий и производственных возможностей под национальным контролем.

Для КИИ этот подход развивается в Постановлении Правительства РФ от 14.11.2023 № 1912, которое устанавливает плановый переход субъектов КИИ на преимущественное применение доверенных программно-аппаратных комплексов. Появляются критерии доверенности, планы, целевые показатели и контроль исполнения.

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

К концу 2023 года вопрос уже звучит шире, чем «чем заменить иностранный продукт». Важно, кто контролирует разработку критической технологии, кто выпускает обновления, обеспечивает поддержку и определяет ее дальнейшее развитие.

К этому моменту складывается новая модель. Технологическая основа инфраструктуры становится частью ИБ, ответственность за ее устойчивость поднимается до уровня руководства, а работа с инцидентами требует заранее подготовленного процесса. В 2024–2025 годах многие решения, принятые как ответ на кризис, постепенно закрепляются в повседневной практике.

2024–2025 годы: от экстренных мер к постоянной готовности

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

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

КИИ: от категорирования к постоянной работе

В 2024 году Указ Президента РФ от 13.06.2024 № 500 развивает инфраструктуру ГосСОПКА. Для ее центров вводятся требования, аккредитация и контроль со стороны ФСБ России. Таким образом, внимание регулятора распространяется и на сами структуры, через которые проходит обнаружение и отработка компьютерных атак.

В 2025 году этот подход получает дальнейшее развитие. Федеральный закон от 07.04.2025 № 58-ФЗ усиливает отраслевую модель регулирования КИИ. Правительство получает полномочия определять перечни типовых объектов по отраслям и особенности их категорирования. Для значимых объектов закрепляется непрерывное взаимодействие с ГосСОПКА.

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

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

К концу 2025 года появляются процедуры, которые делают этот подход гораздо более предметным. Приказы ФСБ № 539, 546, 547 и 548 регулируют получение сведений о средствах и способах атак, обмен информацией об атаках и инцидентах, порядок информирования ФСБ, реагирование и непрерывное взаимодействие с ГосСОПКА.

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

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

Постепенно меняется и роль ГосСОПКА. Это уже не просто адрес, куда организация передает сведения после произошедшего инцидента.

Российское ПО: следующий этап — доверенность и жизненный цикл

После 2022 года быстро стало понятно, что одной метки «российское» недостаточно. Для критической инфраструктуры важны разработчик, поддержка, обновления, совместимость, состав продукта и возможность его модернизации.

Эту логику хорошо показывают Постановление Правительства РФ от 26.11.2025 № 1888 и Постановление Правительства РФ от 28.11.2025 № 1931. Первое вводит механизм соглашений о разработке и модернизации ПО для особо значимых проектов импортозамещения, второе — правила формирования перечня доверенных российских программ и баз данных.

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

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

Защита становится процессом, а не набором СЗИ

Тот же сдвиг виден в Приказе ФСТЭК России от 11.04.2025 № 117. Благодаря этому документу особенно заметен управленческий и эксплуатационный контур: политика защиты, распределение ответственности, управление уязвимостями и обновлениями, мониторинг, работа с подрядчиками, аттестация и контроль эффективности мер.

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

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

Современная модель регулирования все меньше спрашивает: «Есть ли у вас защита?» И все чаще — «Работает ли она сейчас и можете ли вы это доказать?»

Если собрать изменения 2024–2025 годов вместе, получается достаточно цельная конструкция. КИИ получает более четкий отраслевой периметр, ГосСОПКА — непрерывный режим взаимодействия, российская технологическая база — критерии доверенности и развития, а требования к защите — жизненный цикл от проектирования до эксплуатации и контроля.

Что это меняет для организации

Для бизнеса главный сдвиг состоит в том, что нормативное требование все чаще заканчивается не в юридическом заключении, а в конкретной системе, договоре или процессе. КИИ затрагивает эксплуатацию и реагирование, российское ПО — архитектуру и закупки, требования ФСТЭК — управление уязвимостями, обновлениями и подрядчиками. Поэтому мониторинга новых актов самого по себе уже недостаточно.

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

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

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

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

Что эта модель не решает автоматически

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

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

Заключение

За 2020–2025 годы российское регулирование ИТ и ИБ не поменяло курс радикально, но стало гораздо жестче связывать отдельные требования между собой. К 2022 году уже существовала базовая конструкция: КИИ, категорирование, технические меры защиты, ГосСОПКА, курс на импортозамещение. Затем акцент сместился на технологическую независимость, ответственность руководителей и обязательную работу с инцидентами. К 2024–2025 годам эти требования уже воспринимаются не как отдельные меры, а как постоянная часть эксплуатации инфраструктуры.

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

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

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

Полина Егорова

инженер лаборатории исследований кибербезопасности компании «Газинформсервис»