1 марта 2026 года вступил в силу Приказ ФСТЭК 117. Отрасль получила новые требования к защите информации в государственных информационных системах, но осталась без инструкций по их выполнению. Базовый набор мер из предыдущего Приказа 17 ушел в прошлое, а взамен регулятор дал только общие заголовки. Месяц неопределенности закончился 12 апреля публикацией методических рекомендаций. За это время инженеры и аудиторы пытались понять, как именно строить защиту без детализации. Теперь картина прояснилась, и подход к аттестации придется менять. https://seberd.ru/25530/
Приказ ФСТЭК 117 утвердили 11 апреля 2025 года. В силу документ вступил 1 марта 2026-го — почти через год после публикации. У инфраструктурных команд и безопасников было одиннадцать месяцев на чтение текста, оценку бюджета и запуск закупок. Методический документ с детализацией мер вышел 12 апреля, уже после вступления приказа в силу, и задержка методички действительно добавила нервозности. Крупные интеграторы и вендоры начали адаптировать продукты под черновики задолго до весны, поэтому разговоры о месячном параличе отрасли остаются преувеличением.
Старый 17-й приказ с его знаменитым Приложением 2 давно превратился в инструмент для формального закрытия задач. Инженеры годами покупали средства защиты, чтобы поставить галочки в таблицах, а аудиторы проверяли наличие лицензий, а не зрелость процессов. Новый подход смещает фокус. Аудитор смотрит на то, как организация реагирует на инцидент, управляет конфигурациями и обновляет парк машин. Лицензия на сканер уязвимостей не спасает, если к нему не написан регламент приоритизации и не назначен ответственный за верификацию ложных срабатываний.
Зона покрытия расширилась, но не настолько драматично, как писали в телеграм-каналах весной. Под 117-й приказ попали не только классические государственные информационные системы, но и иные системы госорганов, унитарных предприятий и учреждений. Отдельно прописаны центры обработки данных, где размещается инфраструктура. Коммерческим площадкам, обслуживающим госсектор, не требуется проходить полную аттестацию как оператор — достаточно привести в соответствие процессы обработки и разграничения доступа, обновить соглашения об уровне сервиса и обеспечить изоляцию контуров. Стоимость услуг корректируется скорее из-за возросших трудозатрат на поддержку изолированных сегментов, а не из-за тотальной перестройки бизнеса провайдеров.
Как теперь считать класс защищённости
Классов по-прежнему три. Первый — самый высокий, третий — самый низкий. Матрица определения связывает уровень значимости информации и масштаб системы. Уровень значимости выводится из максимальной степени ущерба по трём свойствам: конфиденциальность, целостность, доступность.
Для документов с пометкой «для служебного пользования» автоматически ставится высокий уровень значимости. Об этом часто забывают при первичной классификации, а аудиторы на проверках целенаправленно ищут такие документы в системе и поднимают класс, если оператор занизил значимость.
Масштаб определяется географией: федеральный, региональный, объектовый. Итоговый класс берётся из таблицы приложения. Делить систему на сегменты с разными классами стоит сознательно. Тянуть всю инфраструктуру под максимальный класс дорого и избыточно, а выделение критичного сегмента с усиленной защитой экономит бюджет и упрощает обоснование мер.
Акт классификации пересматривается при любом изменении масштаба или значимости. Добавление нового сервиса, расширение географии пользователей, подключение внешних источников данных — всё это поводы открыть акт заново. Операторы, которые классифицировали систему один раз при вводе в эксплуатацию и забыли, на аттестации получают замечания.
Показатели Кзи и Пзи: не катастрофа, но дисциплина
Приказ вводит показатель защищённости Кзи и показатель уровня зрелости Пзи. Первый отражает состояние защиты от базового уровня угроз, рассчитывается раз в полгода. Второй оценивает зрелость процессов, периодичность — раз в два года. Полные детальные методики расчёта запаздывают, но регулятор уже дал разъяснения и переходные подходы.
Жёсткие сроки отчётности — три дня на доклад руководителю при несоответствии нормативам и пять рабочих дней на отправку отчёта в ФСТЭК — казались нереальными для бюрократической машины крупных предприятий. Регулятор понимает инерционность корпоративных процессов и на текущем этапе использует эти сроки как инструмент мониторинга, а не как повод для массовых штрафов. Отделы информационной безопасности вынуждены поддерживать актуальную картину угроз постоянно, а не рисовать отчёты задним числом раз в год.
Базовые меры и реальные пробелы
Пункт 63 приказа перечисляет восемнадцать базовых мер, и набор сильно отличается от старого приложения 2. Контейнерные среды и их оркестрация. Виртуализация и облачные вычисления. Веб-технологии. Программные интерфейсы. Интернет вещей. Искусственный интеллект.
Для каждой меры методичка описывает цель, требования к реализации, правила документирования и усиления. В разделе мероприятий усиления работают как точки роста и не привязаны к классу. В разделе мер защиты усиления становятся обязательными в зависимости от класса системы.
Таблица маппинга показывает, где на практике возникают пробелы. Правая колонка — то, на чём срезаются при аттестации, причём многие из этих проблем существовали и при 17-м приказе. Новизна 117-го не в появлении новых классов средств защиты, а в том, что на процессы теперь смотрят серьёзнее.
| Требование | Что защищаем | Типовые средства | Где обычно пробел |
|---|---|---|---|
| Идентификация и аутентификация | Учётные записи | Мультифактор, IDM, PAM | Разделение ролей требует организационной работы |
| Управление доступом | Матрицы прав | PAM, Active Directory | Привилегированные сессии без записи |
| Регистрация событий безопасности | Логи | MaxPatrol SIEM, PT SIEM, KUMA | Без SIEM аттестацию не пройти |
| Антивирусная защита | Хосты, почта, трафик | Kaspersky, шлюзовые решения | Проверка почты часто не покрыта |
| Сегментация и экранирование | Сетевой периметр | UserGate, SolidWall | Контроль прикладного уровня не настроен |
| Обнаружение вторжений | Сетевые атаки | СОВ в NGFW, PT NAD | Сигнатуры не обновляются |
| Защита от DDoS | Доступность | Делегирование провайдеру | В соглашении нет ответственности провайдера |
| Защита каналов передачи | Трафик | ГОСТ-VPN, криптошлюзы | Ключи не меняются по регламенту |
| Защита конечных устройств | АРМ с интернетом | Secret Net Studio, Dallas Lock | USB-порты не блокируются |
| Защита мобильных устройств | Планшеты, ноутбуки | MDM-системы | Сертифицированных вендоров мало |
| Защита виртуализации | Гипервизор, ВМ | vGate, Dallas Lock | Строка в планах часто пустая |
| Защита контейнеров | Образы, оркестратор | K8s-решения, аналоги | Сертифицированных средств становится больше, но выбор ограничен |
| Защита веб-технологий | Веб-приложения | PT AF, SolidWall WAF | Межсетевой экран уровня приложений без настройки правил |
| Защита API | Интерфейсы | API Gateway плюс WAF | Отдельного класса средств нет |
| Защита почты | Почтовые сервисы | Шлюзы, DLP | Канал не всегда контролируется |
| Защита IoT | Датчики, контроллеры | Сегментация | Специализированных средств мало |
| Выявление уязвимостей | Инфраструктура | MaxPatrol VM, RedCheck, Сканер-ВС | Анализ требует ручной экспертизы |
| Резервное копирование | Данные, конфигурации | Кибер Бэкап, Acronis | Тестовые восстановления не проводятся |
| Защита СУБД | Базы данных | Postgres Pro, Dallas Lock для СУБД | Журналы не пишутся |
| Безопасная разработка | Собственное ПО | Solar appScreener, PT AI | Статический и динамический анализ внедрены формально |
| Мониторинг ИБ | События | SIEM плюс SOC | Регламент без инфраструктуры |
| Защита ИИ | Модели, данные | Фильтрация промптов | Рынок средств не сформирован |
Средства куплены, лицензии действуют, а процессы вокруг них не выстроены. Аудитор смотрит на замкнутость цикла: выявление, реагирование, документирование, улучшение.
Контейнеры: ситуация уже не безвыходная
Утверждения об отсутствии сертифицированных средств для контроля Kubernetes устарели ещё до вступления приказа в силу. К маю 2026 года вендоры выпустили первые решения для защиты контейнерных сред и оркестраторов, процессы сертификации идут полным ходом. Выбор меньше, чем для классических межсетевых экранов, но говорить о безвыходности уже нельзя.
Защита гипервизора и контейнерной платформы раньше рассматривалась как опциональная надстройка. Теперь входит в базовый набор мер. Для виртуальных машин требуется защита гипервизора, контроль виртуальных сетей, изоляция гостевых систем, мониторинг на уровне хоста. Типовой vSphere или Proxmox без специализированных средств аттестацию не пройдут.
Контейнерный стек остаётся отдельной головной болью. Образы, реестры, оркестратор, сетевые политики между подами. Разработчикам придётся встраивать сканирование образов в конвейер поставки, администраторам — описывать сетевые политики явно, а не полагаться на настройки по умолчанию. При аттестации неизбежно придётся оформлять компенсирующие меры по пункту 69 приказа с детальным обоснованием. Интеграторы успешно закрывают этот блок, комбинируя специализированные продукты с жёсткими сетевыми политиками и компенсационными мерами на уровне гипервизора.
Уязвимости за 24 часа: как это работает на самом деле
Критические уязвимости закрываются за двадцать четыре часа. Высокого уровня опасности — за семь календарных дней. Средние и низкие идут по внутреннему регламенту, но сроки должны быть зафиксированы документально.
Требование звучит как издевательство над здравым смыслом для любой распределённой системы. Обновление ядра или патч для системы управления базами данных в промышленном контуре требует тестирования, окна на обслуживание и согласования с бизнесом. Уложиться в сутки физически невозможно без риска обрушить сервис.
Приказ оставляет легальный путь обхода через компенсирующие меры. Оператор фиксирует уязвимость, оценивает риски и применяет временные ограничения, оформляя внутренним актом. Массовое закрытие критических уязвимостей за сутки происходит только на бумаге, в реальности отрасль живёт через систему компенсаций и плановых окон обновлений. Регулятор это понимает, но в тексте приказа формулировки жёсткие.
Обнаружение уязвимости, отсутствующей в банке данных угроз ФСТЭК, запускает отдельную процедуру: пять рабочих дней на уведомление регулятора. Бюрократическая нагрузка растёт, но отрасль получает канал обратной связи с ведомством.
Сканер уязвимостей закрывает только часть задачи. Выявляет известные проблемы и формирует отчёт. Глубокий анализ, верификация ложных срабатываний, приоритизация — работа инженера. ФСТЭК выпускал отдельную методику по анализу уязвимостей, и на неё придётся опираться при выстраивании процесса.
Искусственный интеллект: территория, где отрасль впереди регулятора
Приказ впервые в российской нормативной базе детализирует требования к системам с искусственным интеллектом. Оператор обязан исключить несанкционированный доступ через воздействие на наборы данных, модели, параметры, процессы обработки. Передача информации ограниченного доступа разработчику модели для дообучения запрещена напрямую — закрыта распространённая практика утечек через внешние программные интерфейсы.
Для пользовательских запросов вводятся два режима контроля. Строго заданные шаблоны — определяются допустимые форматы запросов и ответов. Свободная текстовая форма — определяются допустимые тематики. Разрабатываются статистические критерии недостоверных ответов, ограничивается область решений на их основе.
В состав систем включаются только доверенные технологии искусственного интеллекта. Что именно считать доверенными, определяют отдельные документы в рамках Национальной стратегии развития.
Контроль свободной формы вызывает больше всего вопросов. Модели регулярно обновляются, их поведение не всегда предсказуемо, формализовать допустимые тематики для широкого круга задач затруднительно. Требования к статистическим критериям выявления недостоверных ответов выглядят скорее как пожелания, чем как чёткие нормы. Официальных разъяснений по узким кейсам пока нет. Операторам, у которых большие языковые модели уже в продакшене, придётся идти в первых рядах и формировать практику вместе с регулятором. Ожидается, что ФСТЭК будет закрывать глаза на строгое соблюдение метрик достоверности, если оператор внедрит базовые фильтры промптов и ограничит область принятия решений на основе ответов модели.
Можно ли вообще формализовать допустимые тематики для генеративной модели, которая по определению выдаёт вероятностный результат?
Удалённый доступ: личные устройства скорее запрещены, чем допущены
Удалёнка оформляется жёстко. Сети связи на территории России, защита каналов, строгая аутентификация. Личные устройства допускаются по согласованию с подразделением информационной безопасности при применении сертифицированных средств безопасной дистанционной работы, антивируса и других средств защиты.
В корпоративных реалиях эта формулировка трансформируется в прямой запрет. Развернуть полноценную инфраструктуру управления мобильными устройствами, обеспечить сертифицированную криптозащиту на чужом смартфоне и гарантировать отсутствие вредоносного программного обеспечения на личном ноутбуке требует непропорционально высоких затрат. Бизнес выбирает путь наименьшего сопротивления: доступ к корпоративным ресурсам с неучтенных устройств блокируется на уровне шлюзов.
Привилегированный доступ требует строгой аутентификации. При технической невозможности — усиленной многофакторной. Объединение ролей системного администрирования, разработки, администрирования безопасности в одной учётной записи запрещено прямо. Разделение ролей из рекомендации превратилось в требование.
Встроенные привилегированные учётные записи отключаются после настройки. Если отключение невозможно — переименовываются, аутентификационная информация меняется. Все действия с привилегированными учётными записями регистрируются.
Разработка и подрядчики: править код на проде больше нельзя
Взаимодействие с подрядными организациями оформляется отдельным блоком. Подрядчик знакомится с политикой информационной безопасности в касающейся его части, обязанность выполнения фиксируется в договоре. Копирование информации запрещено, если прямо не предусмотрено документами.
Разработка и тестирование программного обеспечения подрядчиками в эксплуатируемых системах запрещены. Для таких работ выделяются изолированные стенды. В госсекторе разработчики по привычке правят код прямо на продуктивной среде, и теперь такая практика прямо противоречит приказу.
Безопасная разработка опирается на национальный стандарт ГОСТ Р 56939-2024. При самостоятельной разработке оператор реализует меры из разделов 4 и 5 стандарта. При привлечении подрядчика требования включаются в техническое задание. Статический и динамический анализ кода, проверка зависимостей — всё это теперь не инициатива команды разработки, а нормативное требование.
Непрерывность и восстановление: бумажные процедуры как резерв
Интервалы восстановления привязаны к классам. Для систем первого класса — не более 24 часов с момента обнаружения нарушения. Для второго — не более 7 календарных дней. Для третьего — не более 4 недель.
Значимые функции обеспечиваются отказоустойчивой конфигурацией. Резервные копии тестируются на работоспособность. Раз в два года проводятся тренировки по восстановлению с привлечением сотрудников.
При превышении интервалов обеспечивается выполнение функций в неавтоматизированном режиме. Бумажные процедуры как резерв — не архаика, а осознанное требование регулятора, признающего, что полная автоматизация не всегда достижима.
Подразделение ИБ и компетенции
Руководитель создаёт структурное подразделение или назначает специалистов по защите. Не менее тридцати процентов работников подразделения должны иметь профильное образование или переподготовку. Для небольших организаций это означает, что из трёх безопасников как минимум один должен иметь диплом или сертификат о переподготовке.
Подразделение работает во взаимодействии с ИТ и бизнес-подразделениями. Для выполнения функций применяются средства выявления угроз, обнаружения вторжений, контроля защищённости, мониторинга, анализа уязвимостей. Привлечение лицензированных организаций допускается, но работники подразделения оператора обязательно участвуют в приёмке работ.
Средства защиты: сертификация и уровни доверия
Применяются только сертифицированные средства с поддержкой безопасности на территории России, включая выпуск обновлений. Запреты указа Президента 250 от 1 мая 2022 года соблюдаются в полном объёме — средства из недружественных юрисдикций исключены даже при действующих сертификатах.
Классы защиты и уровни доверия привязаны к классу системы. Для К1 требуются средства не ниже 4 класса и уровня доверия. Для К2 — не ниже 5 класса. Для К3 — 6 класс.
Стандартные операционные системы с наложенными средствами защиты от несанкционированного доступа формально допускаются. На практике сертифицированные дистрибутивы снимают большинство вопросов аудиторов и экономят время на обоснованиях.
Мониторинг и контроль защищённости
Мониторинг проводится по национальному стандарту в отношении всех систем, кроме локальных и изолированных. Для анализа событий допускается применение доверенных технологий искусственного интеллекта — регулятор признаёт, что объёмы логов не обрабатываются вручную.
Отчёт о результатах мониторинга готовится с периодичностью, установленной внутренним регламентом. Последний отчёт за год направляется в ФСТЭК.
Контроль уровня защищённости проводится не реже раза в три года или после инцидента. Методы включают выявление уязвимостей с экспертной оценкой, поиск несанкционированных подключений, тестирование моделированием угроз, тренировки. Отчёт представляется руководителю в течение трёх рабочих дней, в ФСТЭК — пяти рабочих дней.
Переходный период: окно закрывается
Ранее выданные аттестаты по 17 приказу действуют до окончания срока. Экстренно переаттестовывать работающие системы не нужно. Новая инфраструктура проверяется строго по 117 приказу. Жёстких сроков перехода на новые стандарты регулятор не установил, но необходимость планирования подчеркнул.
Окно возможностей для спокойной подготовки без авралов постепенно закрывается. Давление со стороны внутренних аудиторов и профильных министерств растёт, большинство ведомств ставит цель привести свои системы в соответствие новым требованиям до конца 2026 — начала 2027 года. Инфраструктурным командам стоит сместить фокус с экстренной закупки оборудования на проработку бумажной архитектуры и процессов. Написание регламентов управления уязвимостями, инцидентами и конфигурациями занимает месяцы.
Где неопределённость максимальная
Главные риски текущей кампании по аттестации лежат не в технической части, а в недостатке разъяснений по новым направлениям. Искусственный интеллект, контейнеры, точные формулы расчёта показателей защищённости и зрелости — именно здесь первые аттестации покажут, насколько регулятор готов быть гибким.
Разные лицензиаты и проверяющие органы по-разному интерпретируют расплывчатые формулировки методических рекомендаций. То, что один аудитор примет как адекватную компенсирующую меру, другой завернёт и потребует закупки нового оборудования. Организациям приходится тратить больше времени на предварительные показы и неформальные согласования с конкретными проверяющими, чем на техническую настройку средств защиты.
Единая правоприменительная практика только формируется. Первые полгода-год пройдут под знаком притирки между бизнесом и лицензиатами. Тем, у кого архитектура попадает в серую зону, стоит идти на проверку раньше и формировать практику вместе с ведомством, а не ждать, пока кто-то другой проложит дорогу. Зрелость процессов, подкреплённая работающими процедурами, станет главным критерием успешной аттестации — и это, пожалуй, самое честное изменение по сравнению с эпохой 17-го приказа.
Не бегите сразу закупать железо. Сначала проведите честный аудит именно по правой колонке таблицы, где процессы хромают. SIEM, защита виртуализации, сканеры это проекты длинные, начинайте их уже сейчас, иначе к аттестации не успеете.
Перепишите регламенты: управление уязвимостями с реальными сроками и компенсирующими мерами, мониторинг, удалённый доступ, работу с подрядчиками.
Приказ 117 не идеальный, однако он заметно лучше предыдущего. В нём меньше догмы и больше внимания к реальным угрозам. Там, где пока нет сертифицированного средства, оператор может обосновать компенсирующие меры. Главное не ждать, пока все вокруг пройдут аттестацию и наработают практику. Те организации, которые выйдут первыми, особенно по темам искусственного интеллекта и контейнеров, во многом сами будут формировать, как этот приказ будут применять на местах.