В 2026 году требования ФСТЭК к защите информации окончательно смещаются от формального выполнения перечней мер к риск-ориентированному подходу. Вместо фиксированных таблиц безопасности организации должны обосновывать архитектуру защиты на основе модели угроз и анализа рисков. Кибер Медиа разбирает, какие документы формируют действующие требования ФСТЭК к средствам защиты информации, как работает система сертификации СЗИ и что именно проверяет регулятор при аттестации информационных систем.
Содержание
Регулирование средств защиты информации в России строится как многоуровневая система документов ФСТЭК. Одни из них определяют базовые требования к защите информации, другие задают методику анализа угроз, третьи регулируют процедуры аттестации и правила сертификации самих средств защиты. В совокупности они формируют нормативную рамку, в которой проектируется и проверяется система информационной безопасности.
Для удобства эту систему можно условно разделить на несколько ключевых блоков.
|
Группа документов |
Что регулирует |
Практическая роль для ИБ-специалистов |
|
Базовые приказы ФСТЭК |
Общие требования к защите информации в информационных системах |
Определяют архитектуру системы защиты, перечень мер безопасности и требования к их реализации |
|
Методики определения угроз безопасности информации |
Процедуру выявления и анализа угроз безопасности информации при построении модели угроз |
Используются при построении модели угроз — основного документа для обоснования мер защиты |
|
Документы по аттестации информационных систем |
Порядок проведения проверок и испытаний |
Определяют процедуру подтверждения соответствия системы требованиям безопасности |
|
Требования к средствам защиты и их сертификации |
Правила разработки, испытаний и оценки СЗИ |
Позволяют определить, какие продукты можно применять в регулируемых информационных системах |
|
Реестры сертифицированных СЗИ |
Перечень средств защиты с действующими сертификатами |
Используются для проверки легитимности и выбора решений при проектировании защиты |
Такая структура отражает логику построения системы защиты информации. Сначала формируется модель угроз и определяется набор необходимых мер безопасности, затем подбираются сертифицированные средства защиты, а после внедрения система проходит процедуру аттестации.
Таким образом, соответствие требованиям ФСТЭК проверяется не только по формальному наличию средств защиты. Регулятор оценивает, насколько выбранные решения обоснованы с точки зрения актуальных угроз, корректно ли они интегрированы в архитектуру системы и способны ли реально обеспечивать требуемый уровень безопасности.
В 2026 году одним из наиболее заметных изменений в регулировании защиты информации стало вступление в силу приказа ФСТЭК №117, который заменил ранее действовавший приказ №17. Формально документ продолжает регулировать требования к защите информации в государственных информационных системах, однако подход к формированию мер безопасности в нем существенно пересмотрен.
Главное отличие нового приказа — отказ от фиксированных таблиц мер защиты для классов К1, К2 и К3. В прежней версии регулирования специалистам по ИБ было проще ориентироваться: для каждого класса системы существовал заранее определенный перечень организационных и технических мер, который необходимо было реализовать. Такой подход обеспечивал понятность требований, но плохо учитывал особенности конкретной инфраструктуры. С развитием виртуализации, облачных сервисов и контейнерных платформ универсальные таблицы стали все хуже отражать реальные архитектуры информационных систем.
Приказ №117 фактически переводит регулирование на более гибкую модель. Вместо формального соответствия готовым наборам мер организация должна самостоятельно обосновать, какие механизмы защиты необходимы для конкретной системы и почему именно они обеспечивают требуемый уровень безопасности. Это означает, что ключевую роль начинают играть аналитические документы — прежде всего модель угроз и результаты анализа рисков.
Александр Буравцов
Директор по информационной безопасности компании CommuniGate Pro
Со вступлением в силу Приказ ФСТЭК России №117, который заменил Приказ ФСТЭК России №17, регулятор отказался от фиксированных таблиц мер и перешел к риск-ориентированному подходу. При этом необходимый набор мер отражен в проекте методического документа, опубликованном на сайте ФСТЭК России и находящемся на этапе утверждения.
Теперь недостаточно формально ссылаться на перечень мер. Компании должны обосновать их применимость с учетом архитектуры системы и актуальных угроз. Одной модели угроз недостаточно. Требуется формализованная оценка рисков, собственная методика их анализа и документальное подтверждение связи между угрозами, рисками и выбранными средствами защиты. Регулятор фактически оценивает не перечень СЗИ, а логику управленческого решения и достаточность принятых мер.
Таким образом, приказ №117 не столько сокращает требования к защите, сколько меняет саму логику их применения. Если раньше основным доказательством соответствия было выполнение предписанных мер из таблицы, то теперь регулятор ожидает увидеть обоснованную архитектуру безопасности, в которой выбранные средства защиты напрямую связаны с выявленными угрозами и особенностями инфраструктуры.
Даже при корректно построенной архитектуре защиты и детально проработанной модели угроз система не сможет пройти аттестацию, если в ней используются неподходящие средства защиты информации. В регулируемых информационных системах ключевое значение имеет не только функциональность продукта, но и его сертификация ФСТЭК.
В государственных информационных системах и других инфраструктурах, где требуется соответствие требованиям регулятора, применяются сертифицированные средства защиты информации. Это решения, которые прошли испытания в аккредитованных лабораториях и получили сертификат соответствия ФСТЭК.
К таким средствам могут относиться:
Сертификат подтверждает, что продукт реализует заявленные функции защиты и может применяться в информационных системах определенного типа.
Сертификация — это процедура независимых испытаний, в ходе которой проверяются механизмы безопасности продукта и корректность их реализации.
По итогам испытаний выдается сертификат, в котором указываются:
|
Параметр |
Что означает |
|
Тип средства защиты |
Категория продукта, например, межсетевой экран или система обнаружения вторжений |
|
Класс или уровень доверия |
Уровень требований безопасности, которому соответствует продукт |
|
Область применения |
В каких типах информационных систем допускается использование |
|
Срок действия сертификата |
Период, в течение которого сертификат считается действительным |
Именно эти параметры определяют, можно ли использовать конкретный продукт в проектируемой системе защиты.
ФСТЭК ведет официальный реестр сертифицированных средств защиты информации. Это основной источник информации о действующих сертификатах.
ИБ-специалисты используют его для нескольких задач:
Особенно важно обращать внимание не только на наличие сертификата, но и на область его применения — она может ограничивать использование продукта определенными типами систем.
Даже при наличии сертифицированных продуктов компании часто допускают ошибки, которые выявляются уже на этапе аттестации или проверки регулятора.
Наиболее распространенные из них:
Поэтому при проектировании системы защиты важно учитывать не только технические характеристики решений, но и их регуляторный статус. В инфраструктурах, подпадающих под требования ФСТЭК, именно сочетание функциональности продукта и корректного сертификата определяет возможность его использования.
По мере развития ИТ-архитектур регулятору пришлось адаптировать требования безопасности к новым технологическим моделям. Если раньше нормативные документы в основном ориентировались на классические серверные инфраструктуры, то сегодня значительная часть сервисов разворачивается в виртуализированных и контейнерных средах. В результате в требованиях ФСТЭК появились положения, прямо затрагивающие защиту контейнерных платформ, таких как Docker и Kubernetes.
Интерес регулятора к этим технологиям вполне закономерен. Контейнеризация активно используется при построении микросервисных архитектур, в DevOps-процессах и при эксплуатации облачных платформ. При этом контейнерные среды создают новые классы рисков: уязвимости в образах, ошибки в конфигурации оркестраторов, неконтролируемый доступ к секретам и возможность выхода из контейнера в хостовую систему. Без дополнительных мер защиты такие платформы могут стать точкой компрометации всей инфраструктуры.
Максим Кузнецов
Руководитель отдела защиты информации ГИС Бастион
Для успешной аттестации информационных систем, в которых используются технологии контейнеризации, необходим всесторонний подход к защите изолированных платформ. Он обязательно должен включать не только авторизацию при доступе к ним и четкое разграничение прав доступа, но и реализацию целостности средств контейнеризации, контейнеров и их образов.
Важным элементом для обеспечения их безопасности должно стать предотвращение несанкционированного доступа изолированной среды к ресурсам других таких же сред, регистрация событий безопасности, связанных с ними, а также регулярное резервное копирование с дальнейшей возможностью их восстановления. Кроме того, необходимо на постоянной основе осуществлять проверку образов контейнеров на известные уязвимости, что позволит своевременно обнаруживать и устранять слабые места до того, как ими воспользуются злоумышленники.
Стоит отметить, что ФСТЭК выпустил проект методического документа «Мероприятия и меры по защите информации, содержащейся в информационных системах» от 5 февраля 2026 г. №240/22/611, который содержит в себе группу мер, направленных на защиту технологий контейнерных сред и их оркестрации.
На практике это означает, что контейнерная платформа должна рассматриваться как полноценный элемент защищаемой инфраструктуры. Ее конфигурация, механизмы разграничения доступа и средства мониторинга должны быть описаны в архитектуре системы защиты и подтверждать выполнение соответствующих мер безопасности.
Для специалистов по ИБ это меняет сам подход к проектированию защиты: помимо традиционных сетевых и хостовых механизмов необходимо учитывать особенности контейнерных платформ и закладывать контроль безопасности на уровне всей среды оркестрации.
Требования к обнаружению и реагированию на ИБ-инциденты в последние годы заметно усилились. Если раньше основной акцент делался на предотвращении атак и контроле доступа, то сегодня регулятор уделяет все больше внимания способности организации своевременно выявлять подозрительную активность и корректно реагировать на инциденты.
Это связано с тем, что даже хорошо защищенная инфраструктура не может полностью исключить вероятность компрометации. Поэтому важным элементом системы защиты становится постоянный мониторинг событий безопасности и отлаженные процессы реагирования.
На практике проверка этих требований выходит далеко за рамки формального наличия средств мониторинга. Аудиторы оценивают, насколько система обнаружения инцидентов действительно интегрирована в инфраструктуру и поддерживается рабочими процессами.
В современных архитектурах мониторинг безопасности обычно строится вокруг нескольких классов решений.
|
Тип системы |
Роль в инфраструктуре безопасности |
|
SIEM |
Централизованный сбор и корреляция событий безопасности из различных источников |
|
EDR |
Обнаружение подозрительной активности на конечных узлах и реагирование на атаки |
|
XDR |
Объединение данных из различных источников (endpoint, сеть, облако) для комплексного анализа атак |
При этом наличие таких систем само по себе не гарантирует соответствие требованиям. Проверяющие обращают внимание на более широкий набор факторов.
Юлия Смолина
Руководитель центра компетенций по консалтингу ИБ «Софтлайн Решения» (ГК Softline)
Требования регуляторов сместились в сторону контроля результативности процессов. При проверках акцент будет делаться не просто на наличие лицензий на средства защиты информации и регламентов, но и на то, как система работает на деле. В частности, будут запрашивать доказательства настройки EDR/XDR, наличие централизованного мониторинга событий со всех узлов, а также четкие процедуры реагирования на разные типы инцидентов (плейбуков). И, конечно, проверят, знают ли сотрудники, как действовать в случае атаки, и есть ли отчеты о реагировании на прошлые инциденты.
При внедрении EDR/XDR лучше не торопиться и делать это поэтапно, чтобы не нарушить бизнес-процессы. Стоит начать с режима мониторинга (только сбор и анализ). На основе собранной информации необходимо проанализировать поведенческие паттерны, характерные для конкретной инфраструктуры, и настроить правила так, чтобы исключить заведомо ложные срабатывания. Главное — использовать решения, которые легко подстроить под задачи и специфику организации.
Таким образом, для соответствия требованиям ФСТЭК недостаточно просто внедрить SIEM или EDR. Регулятор ожидает увидеть полноценную систему управления инцидентами, где технические средства мониторинга дополняются понятными процессами реагирования, ответственными ролями и документированной практикой обработки событий безопасности.
Современный подход регуляторов к проверкам окончательно сместился от формального комплаенса к оценке реальной устойчивости. Если раньше достаточно было показать купленную лицензию и утвержденный регламент, то сегодня инспекторов интересует «прожиточный минимум» зрелости: как быстро процессы адаптируются к новым угрозам вроде XZ Utils или атакам на цепочки поставок.
В центре внимания оказываются 4 критических узла: управление уязвимостями, установка обновлений, контроль конфигураций и сценарии реагирования на инциденты. Регулятор оценивает не факт наличия инструментов, а их интеграцию в ИТ-ландшафт и предсказуемость результата.
|
Процесс ИБ |
Что проверяет регулятор |
Ключевые метрики эффективности (KPI) |
|
Управление уязвимостями |
Регламент сканирования, отчеты о пентестах, реестр исключений. |
MTTD, % охвата инфраструктуры сканированием. |
|
Patch Management |
Матрица ответственности (RACI), отчеты об установке патчей в тестовой среде. |
Time-to-Patch, кол-во критических «просрочек». |
|
Контроль конфигураций |
Эталонные образы, чек-листы харденинга систем. |
Configuration Drift |
|
Реагирование |
Планы IRP, протоколы киберучений. |
MTTR |
Важно понимать, что высокий уровень зрелости подтверждается не словами, а выгрузками из систем (SIEM, VM, CMDB). Аудиторы ищут доказательства того, что ИБ-служба контролирует динамику изменений, а не просто «тушит пожары».
Юлия Смолина
Руководитель центра компетенций по консалтингу ИБ «Софтлайн Решения» (ГК Softline)
Регуляторы при проведении проверок будут оценивать не наличие утвержденных регламентов, а реальные результаты работы. Этот подход подробно описан в проекте нового методического документа ФСТЭК России и обсуждался на форуме «Технология и безопасность», который прошел на прошлой неделе.
Имитировать выполнение требований не получится — это выяснится при первой же отправке отчета по оценке КЗИ. Например, если для подтверждения отсутствия критичных уязвимостей в отчете нет данных напрямую из сканера, специалисты ФСТЭК обязательно запросят дополнительные материалы и в итоге найдут нарушения.
Особое внимание уделяется корреляции данных. Если в отчете сканера уязвимость закрыта, а в системе управления патчами установка не зафиксирована, это становится «красным флагом». Такая рассинхронизация наглядно демонстрирует низкую зрелость и разрыв в коммуникациях между подразделениями.
Вопрос кадрового обеспечения в ИБ сегодня рассматривается регуляторами через призму операционной устойчивости. Основной фокус направлен на то, чтобы ответственные за безопасность обладали не только формальным статусом, но и актуальным набором компетенций для противодействия современным угрозам.
Базовым требованием остается наличие профильного высшего образования или диплома о профессиональной переподготовке объемом не менее 512 часов. Однако, учитывая скорость изменений в отрасли, регулятор ожидает от специалистов регулярного повышения квалификации — как правило, не реже одного раза в три года. В дополнение к этому крайне приветствуется наличие вендорских сертификатов, подтверждающих умение работать с конкретными СЗИ, внедренными в инфраструктуру компании.
Модель распределения компетенций и ответственности:
Стоит подчеркнуть, что использование аутсорсинга не означает передачу ответственности за риски. Согласно позиции регуляторов, на стороне заказчика всегда должен оставаться «контролирующий центр» — квалифицированные специалисты, способные ставить задачи подрядчикам и адекватно оценивать качество их работы.
Сергей Коловангин
Начальник отдела ИТ компании «Газинформсервис»
Требования к персоналу также формализованы в нормативных документах ФСТЭК России. Разумеется, увольнение сертифицированного специалиста может привести к нарушению условий действия аттестата соответствия, но это зона ответственности руководства и кадрового подразделения организации. Фиктивное наличие специалиста по безопасности приравнивается к отсутствию такого специалиста в штате, попытка в этом вопросе ввести в заблуждение представителя регулятора при проверках также чревата серьезными последствиями, поэтому прием на работу студента с профилем по ИБ хотя бы на полставки или вчерашнего выпускника без опыта в любом случае будет более разумным вариантом, чем оставаться вовсе без специалиста по ИБ.
Таким образом, требования к кадрам строятся на принципе разумного баланса: внутри компании удерживается экспертиза по управлению рисками и архитектуре, в то время как специфические и ресурсоемкие задачи могут быть делегированы внешним экспертам. Это позволяет поддерживать высокий уровень защиты без необходимости раздувать штат до избыточных размеров.
Выход на аттестацию для многих превращается в «театр безопасности», где регулятор играет роль опытного критика, который видит фальшь с первой минуты. Главный инсайт последних проверок: ФСТЭК больше не смотрит на наличие наклеек на серверах. Инспекторы ищут логические разрывы, и самый болезненный из них — несоответствие выбранных СЗИ актуальной модели угроз. Это классика: компания покупает дорогостоящие периметральные решения, но в модели угроз черным по белому написано про инсайдеров и флешки, против которых этот комбайн бессилен. Система защиты в таком случае — это дорогой забор в чистом поле, который просто обходят стороной.
Другая ловушка — дефицит вещественных доказательств. В ИБ не работает принцип «верьте на слово». Если ваш регламент велит проверять логи каждое утро, инспектор попросит показать не подпись в журнале, а выгрузку из SIEM или Elasticsearch за случайный вторник 3 месяца назад. Нет логов — нет процесса.
Типовые несоответствия, выявляемые в ходе аттестационных испытаний:
Проблема в том, что «бумажная» безопасность всегда статична, а реальная ИТ-инфраструктура — это живой организм. Когда ФСТЭК находит несоответствие, это не просто формальное замечание, а индикатор того, что ваша защита живет в параллельной вселенной, отдельно от реальных серверов и людей.
Чтобы проверка не превратилась в фиаско, стоит практиковать «самострелы»: внутренние аудиты, где ИБ-команда пытается доказать выполнение каждой меры не словами, а конкретным цифровым следом. Если вы не можете найти лог или отчет для себя, инспектор не найдет его и подавно.
В 2026 году подготовка к аттестации ФСТЭК перестала быть формальным сбором подписей. В условиях эксплуатации гетерогенных сред — от параллельного импорта до решений новых вендоров — регулятор оценивает прежде всего реальную управляемость инфраструктуры. Основной риск сегодня — наличие уязвимых узлов, которые невозможно оперативно обновить.
Михаил Савельев
Директор департамента методологии информационной безопасности «Ростелекома»
Регулятор допускает применение так называемых компенсирующих мер, которые позволяют нивелировать наличие в информационных системах уязвимостей. Если мера позволяет не допустить возможность эксплуатации уязвимости, то компания может продолжить использование софта или оборудования.
План подготовки должен базироваться на глубокой инвентаризации и приоритизации активов. Если в парке оборудования есть критические «дыры», на которые нет патчей, стратегия перестраивается на эшелонированную защиту. Регулятор примет систему, если увидит, что потенциально опасный узел не просто «висит» в сети, а изолирован барьерами, нивелирующими риск эксплуатации уязвимости.
Второй обязательный этап — верификация «цифрового следа». Регламенты должны подтверждаться выгрузками из SIEM или журналов аудита. Любая мера защиты, задекларированная в документах, обязана иметь фактическое подтверждение в виде логов за последние несколько месяцев.
Михаил Марченко
Руководитель направления информационной безопасности инфраструктуры Т1 Облако
Наилучшим вариантом будет заранее построить или модернизировать архитектуру системы так, чтобы все ее компоненты были максимально изолированы друг от друга и внешних сетей. Таким образом, даже если в используемом ПО будет обнаружена уязвимость, то ее эксплуатация будет или вовсе невозможна, или затруднительна, и у владельца будет достаточно времени, чтобы дождаться патча безопасности без негативного влияния на работу системы.
Завершает подготовку внутренний аудит на соответствие проектным решениям. Часто конфигурации СЗИ меняются администраторами «для удобства», что де-факто аннулирует аттестат. Своевременное выявление таких отклонений и их отражение в документации — залог успешного прохождения официальной проверки.
Подводя итог, в 2026 году регулятор окончательно перешел от проверки «наличия коробок» к оценке реальной устойчивости. Успех аттестации теперь зависит не от стопки регламентов, а от логической связки между актуальной моделью угроз и доказанным цифровым следом в системах мониторинга.
Сегодня информационная безопасность — это непрерывный процесс, а не разовый проект. Выигрывают компании, которые делают ставку на прозрачность архитектуры и регулярный самоаудит, превращая комплаенс из бюрократического барьера в работающий инструмент защиты бизнеса.
Атаки на системы искусственного интеллекта смещаются с уровня кода на уровень данных.
Бурное внедрение нейросетей в бизнес-процессы породило не только новые возможности, но и специфические угрозы: от галлюцинаций и утечек обучающих выборок до жестких требований EU AI Act.
47% экспертов, представляющих руководство средних и крупных компаний, считают атаки с целью вымогательства главным риском своей информационной безопасности в 2025 году.
Корпоративные VPN перестают быть технической «данностью» и переходят в категорию регулируемых сетевых сервисов.
Вельц Сергей Владимирович - технический директор, соучредитель ООО "КБ ТехноСкор" специально для читателей Кибер Медиа рассказывает, как банку автоматизировать комплаенс-контроль, отказаться от рутины и превратить управление рисками из угадывания в точный расчет с помощью AI-агентов.
В 2026 году ландшафт цифровых коммуникаций претерпевает серьезные изменения: на фоне локальных сбоев связи, инфраструктурных ограничений и растущей потребности в автономности пользователи массово переходят на альтернативные способы общения.
Количество кибератак растет, а вместе с ними — и бюджеты на информационную безопасность.
Принцип security by obscurity знаком каждому, кто хоть немного погружен в кибербезопасность.
Категорирование объектов критической информационной инфраструктуры в 2026 году обрело новые контуры.
Современная атака может не оставить ни одного файла на диске — и при этом полностью скомпрометировать инфраструктуру.
