Новые угрозы - новые правила: как менялось российское законодательство в сфере ИТ и информационной безопасности
За последние пять лет изменилась не только структура киберугроз, но и сам подход к защите цифровой инфраструктуры. Массовые вредоносные кампании, DDoS-атаки и попытки шифрования данных по-прежнему актуальны. Однако все чаще организации сталкиваются с менее заметными сценариями: длительным присутствием злоумышленников в сети, компрометацией подрядчиков, использованием штатных инструментов администрирования и атаками на критически важные отрасли.
Одновременно выросло значение технологической зависимости. Использование программных продуктов, оборудования и сервисов, жизненный цикл которых контролируется за пределами страны, стало рассматриваться не только как экономический или операционный риск, но и как фактор национальной безопасности.
Российское регулирование информационной безопасности прошло путь от защиты отдельных систем к комплексной модели, включающей технологическую независимость, постоянный контроль, управление цепочками поставок и готовность к реальному реагированию на инциденты.
До 2022 года: нормативная база уже существовала
События 2022 года не сформировали российское законодательство в сфере ИБ с нуля. К тому моменту действовал развернутый набор требований для государственных информационных систем, информационных систем персональных данных, автоматизированных систем управления технологическими процессами и объектов критической информационной инфраструктуры.
Существовали отдельные процедуры категорирования, аттестации, контроля соответствия и взаимодействия с государственной системой обнаружения, предупреждения и ликвидации последствий компьютерных атак. Параллельно развивалась политика импортозамещения: был создан реестр российского программного обеспечения, а для государственных заказчиков установлены ограничения на закупку отдельных иностранных решений.
Поэтому после 2022 года изменилась не сама конструкция регулирования, а условия, в которых организации должны были ее выполнять. Требования, ранее воспринимавшиеся как элемент комплаенса, превратились в условие устойчивой работы бизнеса и государственных систем.
Еще в Доктрине информационной безопасности Российской Федерации, утвержденной указом Президента РФ от 5 декабря 2016 года № 646, устойчивое функционирование информационной инфраструктуры было отнесено к национальным интересам. Документ также фиксировал рост сложности и скоординированности компьютерных атак и указывал на зависимость отечественной промышленности от зарубежного программного обеспечения, вычислительной техники, электронной компонентной базы и средств связи.
Иными словами, ключевые риски были обозначены заранее. Однако до резкого изменения внешней среды они зачастую воспринимались как стратегические, а не как ежедневные операционные угрозы.
КИИ: переход от общих принципов к формализованной ответственности
Важной основой современной модели стал Федеральный закон от 26 июля 2017 года № 187-ФЗ "О безопасности критической информационной инфраструктуры Российской Федерации". Он определил состав субъектов и объектов КИИ, закрепил процедуру категорирования и установил обязанности владельцев значимых объектов.
Постановление Правительства РФ от 8 февраля 2018 года № 127 перевело эти положения в практический алгоритм. Организация должна выявить потенциальные объекты КИИ, оценить последствия нарушения их работы, определить категорию значимости и передать необходимые сведения регулятору.
Главное преимущество такого подхода заключается в привязке требований к последствиям инцидента. Система признается важной не потому, что так считает ее владелец, а потому, что ее отказ способен повлиять на энергетику, транспорт, связь, финансовые операции, промышленное производство или иные значимые процессы.
До 2022 года в центре внимания находился конкретный объект: информационная система, сеть или автоматизированная система управления. Для нее определялись уровень критичности и необходимый набор мер защиты. Такой объектный подход был логичным и достаточно детально проработанным.
Требования также не ограничивались формальными документами. Приказ ФСТЭК России от 25 декабря 2017 года № 239 предусматривал идентификацию и аутентификацию пользователей, разграничение доступа, регистрацию событий безопасности, защиту от вторжений, управление конфигурациями и обновлениями, реагирование на инциденты и действия в нештатных ситуациях.
Следовательно, базовые элементы инженерной кибербезопасности уже были закреплены нормативно. Проблема заключалась не в полном отсутствии правил, а в разрыве между формальным выполнением требований и реальной готовностью организации противостоять сложной атаке.
2022-2023 годы: информационная безопасность становится задачей руководства
После 2022 года безопасность перестала быть исключительно зоной ответственности ИТ- и ИБ-подразделений. Риски начали напрямую влиять на непрерывность бизнеса, доступность производственных процессов, выполнение контрактов и возможность использовать критически важные цифровые сервисы.
Руководству пришлось отвечать уже не только на вопрос о наличии необходимых средств защиты, но и на более практичные вопросы:
- может ли организация продолжить работу после компрометации ключевой системы;
- кто принимает решения во время атаки;
- насколько быстро восстанавливаются резервные копии;
- какие подрядчики имеют доступ к инфраструктуре;
- способен ли персонал действовать без внешней технической поддержки;
- какие функции зависят от импортного программного обеспечения или оборудования.
Так изменилось само понимание соответствия требованиям. Наличие политики, регламента или договора с оператором мониторинга больше не гарантирует безопасности. Важным показателем становится способность выполнить предусмотренные процедуры в условиях дефицита времени и неполной информации.
Технологическая зависимость превращается в угрозу
Одним из главных последствий внешних ограничений стала переоценка зависимости от иностранных технологий. Ранее зарубежный продукт мог считаться обычным элементом ИТ-ландшафта. Теперь его происхождение, модель обновления, наличие удаленных сервисов и возможность поддержки стали предметом отдельного анализа.
При этом простая замена иностранного решения российским не всегда устраняет риск. Необходимо учитывать архитектуру продукта, качество обновлений, защищенность процесса разработки, совместимость с существующими системами и возможность долгосрочной эксплуатации.
Важным становится понятие управляемой технологической базы. Организация должна понимать, какие компоненты используются в ее инфраструктуре, кто отвечает за их сопровождение, откуда поступают обновления и насколько быстро можно перейти на резервную платформу.
Инцидент требует заранее подготовленного сценария
Серьезная атака может развиваться быстрее, чем согласуются внутренние решения. Поэтому в организациях усилилось внимание к планам реагирования, резервному копированию, сегментации сети и тренировкам персонала.
Эффективный план реагирования должен описывать не только технические действия. В нем необходимо определить порядок эскалации, роли руководителей, правила взаимодействия с регуляторами, процедуру фиксации доказательств, работу с клиентами и подрядчиками, а также условия перехода на резервные процессы.
Отдельное значение имеет проверка восстановления. Резервная копия сама по себе не является гарантией защиты: важно знать, можно ли ее развернуть, не повреждена ли она, достаточно ли ресурсов для восстановления и сколько времени займет возврат критических функций.
2024-2025 годы: от экстренных мер к постоянной готовности
На следующем этапе регулирование стало смещаться от разовых антикризисных действий к постоянной устойчивости. Организациям необходимо не просто выполнить комплекс требований, а поддерживать его в актуальном состоянии при изменении архитектуры, состава сотрудников, программного обеспечения и внешних угроз.
Это означает регулярный пересмотр моделей угроз, контроль изменений, инвентаризацию активов, проверку учетных записей, оценку уязвимостей и анализ событий безопасности. Защита должна быть встроена в жизненный цикл информационной системы - от проектирования до вывода из эксплуатации.
Для объектов КИИ категорирование больше не может восприниматься как финальная процедура. После определения категории начинается длительная работа: поддержание мер защиты, контроль подрядчиков, расследование инцидентов, взаимодействие с регуляторами и документирование изменений.
Российское ПО: важен не только статус в реестре
Следующий этап импортозамещения связан с переходом от формального выбора российского продукта к оценке его надежности и управляемости. Сам факт включения программного обеспечения в соответствующий перечень не отвечает на все вопросы безопасности.
Организациям важно оценивать, как разработчик выпускает обновления, устраняет уязвимости, обеспечивает совместимость версий и реагирует на сообщения об инцидентах. Не менее важны прозрачность жизненного цикла, наличие технической поддержки и возможность безопасного сопровождения продукта в течение нескольких лет.
Появляется и дополнительная задача - проверка программных компонентов, библиотек и зависимостей. Даже отечественное приложение может использовать сторонние модули, которые создают отдельные риски для безопасности и устойчивости.
Защита становится процессом, а не комплектом средств
Современная модель ИБ не сводится к закупке межсетевого экрана, антивируса или системы мониторинга. Технические средства эффективны только тогда, когда встроены в управляемый процесс.
В этот процесс входят инвентаризация активов, классификация данных, управление доступом, контроль привилегированных учетных записей, сегментация сети, регулярное обновление систем, обучение сотрудников и анализ инцидентов. Не менее важны метрики: время обнаружения, скорость локализации, продолжительность восстановления и доля успешно проверенных резервных копий.
Особую роль играет управление цепочками поставок. Подрядчики, интеграторы, облачные операторы и поставщики оборудования могут иметь доступ к критическим системам. Поэтому проверка контрагентов и ограничение их полномочий становятся частью общей модели защиты.
Что меняется для организации
Организации приходится переходить от периодической подготовки отчетности к непрерывному управлению рисками. ИБ должна быть связана с бизнес-планированием, бюджетированием, закупками и проектированием новых сервисов.
Перед внедрением системы необходимо определить, какие процессы являются критичными, какие последствия вызовет их остановка и какие зависимости могут затруднить восстановление. Такой анализ позволяет расставить приоритеты и направлять ресурсы не на формальное закрытие всех возможных направлений, а на защиту действительно значимых функций.
Также возрастает роль руководителей подразделений. Информационная безопасность становится общей зоной ответственности: ИТ обеспечивает устойчивость инфраструктуры, ИБ контролирует риски и реагирование, бизнес определяет приоритеты, а руководство принимает решения о приемлемом уровне риска.
Что регулирование не решает автоматически
Даже самая подробная нормативная база не может гарантировать отсутствие инцидентов. Правила не заменяют качественную архитектуру, подготовленный персонал и регулярные практические проверки.
Сохраняются риски, связанные с человеческими ошибками, устаревшими системами, недостатком специалистов, сложностью наследуемой инфраструктуры и неконтролируемыми зависимостями от подрядчиков. Дополнительную проблему создает разрыв между требованиями к документам и фактическим состоянием систем.
Поэтому организациям важно воспринимать нормативные требования как минимальную рамку, а не как готовую стратегию защиты. Реальная устойчивость формируется через постоянное тестирование, анализ инцидентов, обновление процессов и способность быстро менять технологические решения.
Итог
Российское регулирование в сфере ИТ и информационной безопасности прошло несколько этапов. Сначала основной акцент делался на защите конкретных систем и выполнении установленных организационных и технических мер. Затем в центр внимания вышли технологическая независимость, безопасность цепочек поставок и ответственность руководства. На современном этапе ключевой становится постоянная готовность к инцидентам и способность сохранять работоспособность в условиях компрометации отдельных компонентов.
Главный результат этих изменений - переход от формального соответствия к управляемой устойчивости. Безопасность рассматривается не как разовая проверка и не как набор закупленных средств защиты, а как непрерывный процесс, охватывающий технологии, людей, поставщиков и управленческие решения.