С 1 марта 2026 года требования к защите информации в государственных информационных системах существенно изменились. На смену хорошо знакомому специалистам по ИБ приказу ФСТЭК России № 17 пришёл приказ ФСТЭК России от 11.04.2025 № 117.
Новый приказ распространяется не только на государственные информационные системы (ГИС), но и на иные информационные системы государственных органов, государственных унитарных предприятий и государственных учреждений.
При этом воспринимать № 117 просто как «обновлённый 17-й приказ» не совсем правильно. Подход к защите информации стал заметно ближе к реальной эксплуатации современных ИТ-систем.
Что изменилось
Одно из важных изменений — больший акцент на управление рисками и актуальными угрозами, а не только на формальное выполнение заранее определённого набора мер защиты.
На практике это означает, что недостаточно установить межсетевой экран, антивирус, СЗИ от НСД и подготовить комплект документов. Необходимо понимать, от каких именно угроз защищается система и насколько применяемые меры действительно работают.
Больше внимания уделяется процессам, которые должны выполняться постоянно:
- управлению уязвимостями;
- контролю конфигураций;
- регистрации и анализу событий безопасности;
- реагированию на компьютерные инциденты;
- контролю изменений информационной системы;
- периодической оценке эффективности реализованных мер защиты.
То есть информационная безопасность всё меньше выглядит как проект «провели аттестацию и забыли на несколько лет» и всё больше становится постоянным процессом.
Пример: нашли критическую уязвимость
Допустим, в используемом организацией ПО обнаружена критическая уязвимость, для которой уже существует публичный эксплойт.
Формального наличия сканера уязвимостей здесь недостаточно.
Рабочий процесс должен выглядеть примерно так:
обнаружили уязвимость → оценили её применимость к конкретной системе → определили критичность → назначили ответственного → установили обновление или применили компенсирующие меры → проверили устранение.
Если обновить систему нельзя, например из-за несовместимости с прикладным ПО, риск не должен просто оставаться в отчёте сканера. Можно ограничить сетевой доступ к сервису, изменить правила межсетевого экрана, усилить мониторинг или применить другие компенсирующие меры.
Пример: администратор изменил настройки сервера
Ещё одна типовая ситуация — изменение конфигурации.
Администратор временно открыл сетевой порт для диагностики проблемы и после завершения работ забыл его закрыть.
В зрелом процессе защиты такие изменения должны выявляться средствами контроля конфигураций или мониторинга.
Поэтому полезный практический use case выглядит следующим образом:
эталонная конфигурация → изменение → обнаружение отклонения → проверка изменения → возврат к безопасной конфигурации.
Особенно это актуально для серверов, средств виртуализации, сетевого оборудования и средств защиты информации.
Пример: SIEM есть, но события никто не анализирует
Распространённая ситуация: организация внедрила SIEM, события туда поступают, формально требование по регистрации событий выполнено.
Но если ночью с учётной записью администратора происходит несколько десятков неудачных попыток входа, затем успешная авторизация и запуск PowerShell — кто и когда это увидит?
Само наличие SIEM проблему не решает.
Необходимо определить, какие события контролируются, какие сценарии считаются подозрительными, кто получает уведомления и что должен сделать сотрудник при срабатывании правила корреляции.
Именно связка «техническое средство + процесс реагирования» даёт реальный результат.
Что стоит сделать организациям уже сейчас
Если информационная система ранее создавалась и аттестовывалась по требованиям приказа № 17, начинать всё с нуля обычно не требуется.
Рациональнее провести gap-анализ:
текущая система защиты → требования № 117 → выявленные несоответствия → план мероприятий.
На практике мы рекомендуем начать с инвентаризации информационных систем и средств защиты, пересмотреть модель угроз, проверить процессы управления уязвимостями и изменениями, организацию мониторинга событий ИБ и реагирования на инциденты.
Отдельно стоит проверить документацию. За несколько лет эксплуатации реальная архитектура системы часто заметно расходится с той, которая была зафиксирована при первоначальной аттестации.
Чем мы можем помочь
ProfIT Security проводит обследование информационных систем и помогает привести систему защиты в соответствие требованиям приказа ФСТЭК России № 117.
Работу можно начать с небольшого gap-аудита: определить, какие требования уже выполняются, где есть несоответствия и какие мероприятия действительно необходимо выполнить.
Результатом становится не очередной многостраничный отчёт «для галочки», а понятный план: что необходимо изменить, насколько это критично, какие технические и организационные меры нужны и в какой последовательности их разумно внедрять.
