В сфере государственной информационной безопасности произошел тектонический сдвиг. Принятие Приказа ФСТЭК России №117 от 11.04.2025 (зарегистрирован в Минюсте РФ 16.06.2025 № 82619) и публикация нового Методического документа ФСТЭК России от 12.04.2026 «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах» кардинально меняют правила игры.
На первый взгляд — очередное изменение нормативной базы. Но на самом деле это смена парадигмы: переход от статичной, «бумажной» аттестации к непрерывному, процессно-ориентированному управлению защитой информации с жестким контролем уязвимостей, ИТ-инфраструктуры и ответственности.
В статье разбираем суть изменений, их практические последствия для операторов и подрядчиков, скрытые камни и даем пошаговый план соответствия новым требованиям.
1. Почему старый подход больше не работает?
Долгое время базовым документом для ГИС оставался знаменитый Приказ ФСТЭК №17. Он создавался в эпоху, когда ИТ-ландшафт госорганов был преимущественно изолированным и статичным. Основной упор делался на разовые мероприятия: спроектировали, внедрили СЗИ, получили аттестат соответствия на несколько лет и «забыли».
Но сегодня реальность изменилась:
Интеграция через API и СМЭВ: Современные ГИС постоянно обмениваются данными с внешними сервисами, открывая новые векторы атак.
Микросервисы и контейнеризация: Использование Docker и Kubernetes стало стандартом при разработке госсервисов, но классические средства защиты их «не видят».
Облачная инфраструктура: Госсектор активно мигрирует в коммерческие и государственные ЦОД и облака.
Ландшафт угроз: DDoS-атаки, сложные целевые атаки (APT) и утечки данных стали ежедневным вызовом.
Приказ №117 и Методический документ 2026 года — это ответ регулятора на технологический прогресс. Защита теперь должна быть не «внедренной один раз», а непрерывной.
2. Приказ №117: ключевые изменения на верхнем уровне
2.1. Круг лиц, подпадающих под требования, резко расширен
Ранее фокус внимания смещался исключительно на операторов ГИС. Новый приказ четко очерчивает круг систем: это не только ГИС, но и информационные системы государственных органов, государственных унитарных предприятий (ГУП), государственных учреждений (ГКУ, ГБУ) и муниципальных организаций.
Важный инсайд для бизнеса: Требования автоматически транслируются на подрядные организации (разработчиков, системных интеграторов, сервис-провайдеров). Если ваша компания по госконтракту разрабатывает, модернизирует или осуществляет техническую поддержку системы госоргана или ГУПа, соблюдение требований Приказа №117 и Методического документа становится для вас обязательным условием допуска к работам.
2.2. Матрица классификации защищенности
Приказ №117 устанавливает четкую зависимость класса защищенности информационной системы (К1, К2, К3) от уровня значимости информации (УЗ 1, УЗ 2, УЗ 3) и масштаба системы:
Масштаб информационной системы | Класс защищенности при УЗ 1 | Класс защищенности при УЗ 2 | Класс защищенности при УЗ 3 |
|---|---|---|---|
Федеральный | К1 | К1 | К2 |
Региональный | К1 | К2 | К3 |
Объектовый (локальный) | К1 | К2 | К3 |
Обратите внимание: Если информация имеет наивысший уровень значимости (УЗ 1), система в любом случае получает максимальный класс защищенности К1, вне зависимости от того, развернута она на уровне всей страны или в рамках одного конкретного ведомственного объекта.
2.3. Жесткие требования к контролю инфраструктуры (п. 8 Приказа)
Классы защищенности информационных систем, функционирующих на базе информационно-телекоммуникационной инфраструктуры (ЦОД, ведомственные сети, облака), не должны быть выше класса защищенности самой этой инфраструктуры.
Если вы размещаете ГИС класса К2 в коммерческом облаке, этот облачный провайдер обязан иметь аттестованную инфраструктуру класса не ниже К2. В противном случае комплаенс пройти не удастся.
3. Методический документ 2026 года: от теории к практике
Если Приказ №117 задает рамки («что должно быть сделано»), то новый Методический документ от 12 апреля 2026 года детально расписывает механики («как именно это делать»).
3.1. Структура документа
Документ уходит от абстрактных формулировок и делит весь процесс защиты на:
19 базовых мероприятий (процессов) обеспечения ИБ (управление уязвимостями, конфигурациями, обновлениями, защита контейнеров, реагирование на инциденты и т.д.).
17 групп технических мер (ИАФ, УПД, РСБ, СОВ, МСЭ и др.).
Для каждой технической меры теперь жестко прописаны базовые требования к реализации и требования к усилению, которые активируются в зависимости от присвоенного класса (К1–К3).
3.2. Пример жесткой детализации: Аутентификация (ИАФ)
Забудьте про формальные регламенты смены паролей «раз в год». Новый документ устанавливает жесткие технические параметры:
Для базового уровня: Длина пароля не менее 12 символов, использование минимум 4 групп символов (алфавит не менее 70 символов), блокировка учетной записи после 5 неудачных попыток ввода, принудительная смена пароля не реже чем раз в 90 дней.
Усиление для К2 и К1: Обязательное внедрение многофакторной аутентификации (MFA) при любом удаленном доступе. Для привилегированных пользователей (администраторов) в системах К1 требуется строгая аутентификация с использованием аппаратных средств (токенов) и сертификатов.
4. Главные подводные камни, к которым нужно готовиться
4.1. Оркестрация и контейнеризация (Меры ЗКО)
Впервые на уровне методических документов ФСТЭК так подробно выделен блок защиты сред контейнеризации (ЗКО.1 – ЗКО.8). Регулятор требует:
Контроля целостности образов контейнеров и проверки их на уязвимости до деплоя в продуктивную среду;
Изоляции контейнеров друг от друга и ограничения привилегий процессов внутри контейнера;
Логирования событий безопасности на уровне оркестратора (Kubernetes).
4.2. Безопасность API (Меры ЗПИ)
Интеграционные интерфейсы (API) признаны одной из ключевых зон риска. Введены три обязательные меры:
ЗПИ.1 (Защита данных API): Запрет на раскрытие внутренней структуры системы в ответах об ошибках.
ЗПИ.2 (Управление доступом): Обязательная аутентификация всех запросов к API и ограничение частоты запросов (Rate Limiting) для защиты от brute-force и DDoS.
ЗПИ.3 (Валидация): Проверка входящих запросов на соответствие строгой спецификации API (например, OpenAPI/Swagger).
4.3. Окно устранения уязвимостей сузилось до минимума
Процесс управления уязвимостями (КУ) и обновлениями (КО) теперь требует от ИТ- и ИБ-служб работы в режиме high-alert. На закрытие критических уязвимостей, для которых есть публичные эксплойты, могут отводиться считанные часы (вплоть до 24 часов с момента обнаружения/публикации в БДУ ФСТЭК). Если патча от вендора нет — оператор обязан незамедлительно применить компенсирующие меры (например, виртуальный патчинг на WAF или временное отключение компонента).
5. Пошаговый план перехода на новые требования
[Шаг 1: Инвентаризация и Классификация]
│
▼
[Шаг 2: GAP-анализ по Методическому документу 2026]
│
▼
[Шаг 3: Пересмотр моделей угроз и политик ИБ]
│
▼
[Шаг 4: Модернизация СЗИ (MFA, WAF, Контейнеры, SIEM)]
│
▼
[Шаг 5: Аудит и ревизия договоров с подрядчиками/ЦОД]
│
▼
[Шаг 6: Аттестация / Контроль соответствия]
Инвентаризация и классификация: Пересмотрите все информационные активы. Определите масштаб и УЗ. Составьте и утвердите новый Акт классификации системы по правилам Приказа №117.
GAP-анализ: Возьмите приложение к Методическому документу от 12.04.2026, сопоставьте ваш класс (К1–К3) с таблицей мер и выявите «разрывы» между текущим состоянием ИБ и новыми требованиями ФСТЭК.
Обновление политик и регламентов: Перепишите внутренние инструкции. Управление конфигурациями, парольная политика, удаленный доступ и реагирование на инциденты должны быть актуализированы.
Техническая модернизация: Внедрите недостающие инструменты контроля:
Системы двухфакторной аутентификации (2FA/MFA);
Защиту API и веб-приложений (WAF / API Gateway);
Средства сканирования уязвимостей и анализа защищенности контейнеров.
Работа с цепочкой поставок (Supply Chain): Проведите ревизию договоров с ИТ-подрядчиками и облачными провайдерами. Включите в SLA требования по соблюдению Приказа №117.
Что в итоге?
Приказ №117 ФСТЭК и сопутствующий методический документ 2026 года окончательно закрывают эпоху «декоративной» безопасности в госсекторе. Новые правила требуют от организаций построения реальных, работающих процессов ИБ.
Организациям, которые уже выстроили зрелые процессы (используют DevSecOps, SIEM-системы, полноценный Vulnerability Management), адаптироваться будет проще. Тем же, кто полагался исключительно на бумажные аттестаты, предстоит масштабная техническая и организационная модернизация.