Самая дорогая ошибка при подготовке к аттестации по приказу ФСТЭК № 117 - начинать с закупки межсетевого экрана, антивируса, сканера уязвимостей и пачки сертификатов. Проверка начинается раньше. Сначала нужно определить границы информационной системы, понять, подпадает ли система под приказ, правильно установить класс защищенности и связать требования ФСТЭК с реальными процессами внутри организации. Только после такой работы становится понятно, каких документов, настроек и средств защиты действительно не хватает.
Я бы считал систему готовой не тогда, когда у компании собрана толстая папка регламентов, а когда для каждого требования можно показать работающий механизм и доказательства его работы. Учетные записи действительно блокируются, уязвимости устраняются в заданные сроки, резервные копии восстанавливаются, журналы анализируются, права администраторов контролируются, а схема системы совпадает с реальной инфраструктурой. Именно такой подход позволяет провести предварительный аудит до прихода аттестационной комиссии.
Материал предназначен для законной подготовки информационных систем к выполнению требований регуляторов. При проведении аудита, тестирования защищенности и проверки доступа нужно соблюдать законодательство России, условия договоров и правила владельца системы. Проверки нельзя проводить без соответствующих полномочий.
Сначала проверьте, нужна ли системе аттестация и какой у нее класс
Приказ ФСТЭК № 117 действует с 1 марта 2026 года и заменил приказ № 17. Требования распространяются на государственные информационные системы, другие информационные системы государственных органов, государственных унитарных предприятий и государственных учреждений. Для муниципальных информационных систем требования также применяются, если законодательство не устанавливает иное.
С коммерческими организациями ситуация сложнее, чем иногда следует из рекламы услуг по аттестации. Сам государственный контракт еще не превращает всю инфраструктуру подрядчика в объект обязательной аттестации. Если из ГИС передается информация ограниченного доступа, принимающая система должна соответствовать установленным требованиям защиты. Конкретный объем обязанностей зависит от роли организации, состава данных, договора и архитектуры информационного взаимодействия.
Для ГИС аттестацию проводят до начала обработки или хранения информации. Для иных информационных систем государственных органов, ГУПов и государственных учреждений решение о необходимости аттестации принимает руководитель оператора или ответственное лицо. Аттестаты, выданные до вступления приказа № 117 в силу, автоматически не аннулировались.
Следующая частая ошибка - выбрать К3 просто потому, что система небольшая. В приказе осталось три класса, от К3 до К1, но класс рассчитывают по уровню значимости информации и масштабу системы.
| Уровень значимости | Федеральный масштаб | Региональный масштаб | Объектовый масштаб |
|---|---|---|---|
| УЗ 1 | К1 | К1 | К1 |
| УЗ 2 | К1 | К2 | К2 |
| УЗ 3 | К2 | К3 | К3 |
Таким образом, типовая система К3 предполагает низкий уровень значимости информации и региональный либо объектовый масштаб. Федеральная система даже при УЗ 3 получает К2. Для информации с пометкой «для служебного пользования» устанавливается УЗ 1, поэтому К3 для такого случая уже не получится.
Результаты классификации оформляют актом. Если внутри крупной системы есть сегменты с разными условиями работы, приказ допускает присвоить сегментам разные классы. Такой подход иногда позволяет не распространять максимальные требования на всю инфраструктуру, но границы сегментов и информационные потоки придется обосновать.
Документы нужны не для папки, а для работающих процессов
После классификации я бы проверял организационную часть. Приказ № 117 заметно сильнее прежнего подхода привязывает защиту к постоянным процессам. Политика безопасности должна описывать защищаемые системы, объекты, сети, цели защиты, роли сотрудников, полномочия и ответственность. Руководитель назначает ответственное лицо, а функции ИБ закрепляются за подразделением или отдельными специалистами.
Есть неочевидное кадровое требование. Если создано подразделение по защите информации, не менее 30 процентов его работников должны иметь профильное профессиональное образование либо пройти профессиональную переподготовку в области информационной безопасности.
Для предварительной проверки я использую примерно такой набор.
| Что проверить | Что должно подтверждать работу процесса |
|---|---|
| Учетные записи | Правила создания, изменения, блокирования и удаления учетных записей, включая привилегированные |
| Права доступа | Матрица доступа, назначенные роли, подтверждение принципа минимальных привилегий |
| Уязвимости | Регламент, результаты сканирования, классификация уязвимостей, заявки и отчеты об устранении |
| Обновления | Проверка подлинности, тестовый контур, согласование установки и история обновлений |
| Конфигурации | Инвентаризация ИТ-активов, эталонные конфигурации и контроль изменений |
| Удаленный доступ | Разрешенные устройства, защищенные каналы, аутентификация, журналирование и контроль сессий |
| Мониторинг | Источники событий, правила анализа, зарегистрированные инциденты и отчеты руководству |
| Резервное копирование | Политика копирования, разные носители и места хранения, результаты тестового восстановления |
| Подрядчики | Условия доступа, договорные требования ИБ, контроль действий и изолированные стенды разработки |
| Обучение | Материалы обучения, результаты проверки знаний, тренировок и имитационных фишинговых рассылок |
Регламент управления уязвимостями заслуживает отдельной проверки. Критические уязвимости, которые может использовать нарушитель, приказ требует устранить либо закрыть компенсирующими мерами не позднее чем за 24 часа. Для высокого уровня опасности срок составляет не более семи календарных дней. Сроки для среднего и низкого уровней организация устанавливает сама. Если обнаружена уязвимость, которой нет в банке данных угроз ФСТЭК, сведения о ней нужно передать регулятору не позднее пяти рабочих дней.
С обновлениями тоже нельзя ограничиться фразой «устанавливаем автоматически». Приказ требует проверять подлинность и целостность обновлений, тестировать их до промышленной установки и выдавать разрешение на применение. Неконтролируемая установка обновлений прямо не допускается.
Еще один хороший тест на реальность документов связан с резервными копиями. Для значимых функций оператор устанавливает время восстановления. Максимальный интервал для К3 составляет четыре недели, для К2 семь календарных дней, для К1 24 часа. Четыре недели не являются рекомендацией держать систему выключенной почти месяц. Организация вправе установить значительно более жесткий показатель. Восстановление из резервных копий нужно периодически проверять, в том числе в форме тренировок, не реже одного раза в два года.
Какие технические средства действительно нужны
В коммерческих чек-листах приказ № 117 иногда выглядит как каталог продуктов. Сертифицированная операционная система, NGFW, WAF, PAM, сканер уязвимостей, антивирус, защищенная СУБД и резервное копирование. Такой набор может оказаться разумной архитектурой, но сам приказ не требует покупать конкретные бренды и не устанавливает универсальный комплект коробочных продуктов.
ФСТЭК задает базовые направления защиты, а утвержденный методический документ «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах» детализирует конкретные меры для К1, К2 и К3. Затем базовый набор адаптируют под архитектуру, технологии, актуальные угрозы и возможности нарушителя.
В перечень входят идентификация и аутентификация, управление доступом, регистрация событий, защита виртуализации и облаков, контейнеров и систем оркестрации, электронной почты, веб-технологий, программных интерфейсов, конечных и мобильных устройств, интернета вещей, беспроводных сетей, антивирусная защита, сетевое обнаружение и предотвращение вторжений, сегментация, межсетевое экранирование, защита от отказа в обслуживании и защита сетевого взаимодействия.
Поэтому тезис «для приказа № 117 обязательно нужен NGFW» слишком грубый. Требования к межсетевому экранированию, сегментации, обнаружению вторжений и другим функциям действительно существуют. Реализовать их можно одной многофункциональной платформой или несколькими средствами, если выбранная схема выполняет необходимые меры и отвечает требованиям к сертификации.
То же относится к WAF. Для системы с веб-интерфейсом меры защиты веб-технологий потребуются, но из текста приказа не следует универсальное правило «каждой системе купить отдельный WAF». Решение принимают после выбора базовых мер, их адаптации и анализа угроз.
Сертифицированная операционная система часто упрощает проект, но утверждение «по приказу № 117 любая ОС обязательно должна быть сертифицированной» тоже неточно. Приказ требует применять сертифицированные средства защиты информации и допускает встроенные средства защиты на аппаратном и системном уровнях. Инженер должен определить, какие функции безопасности реализует сама ОС, какие накладываются отдельным СЗИ и каким сертификатом подтверждается необходимый класс.
Для К3 применяемые сертифицированные СЗИ должны соответствовать 6 классу защиты и уровню доверия. Для К2 требуется не ниже 5 класса, для К1 не ниже 4 класса. Проверять нужно не только наличие знакомого названия в реестре, но и конкретную версию продукта, срок и область действия сертификата, разрешенную конфигурацию и требования эксплуатационной документации.
Особенно внимательно я бы проверил аутентификацию. Для привилегированного доступа приказ требует строгую аутентификацию, а при технической невозможности допускает усиленную многофакторную. Поэтому привычная формула «администраторам достаточно любой двухфакторной аутентификации» неточна. Нужно проверить, соответствует ли механизм терминологии и требованиям ФСТЭК.
Удаленный доступ требует защищать канал и устройство пользователя. Для служебного удаленного доступа базовая редакция требует строгую аутентификацию и использование сетей связи, расположенных на территории России. С 1 сентября вступают в силу изменения по приказу № 137, которые в ряде положений добавляют возможность усиленной многофакторной аутентификации.
Криптографию нужно рассматривать отдельно. Приказ ФСТЭК № 117 регулирует некриптографическую защиту. Если используются шифровальные средства, дополнительно применяются требования ФСБ. Существует еще приказ ФСБ № 117 от 18 марта 2025 года. Совпадение номеров легко вводит в заблуждение, хотя документы выпустили разные регуляторы и регулируют разные части защиты.
Для публичных сервисов потребуется защита от атак на отказ в обслуживании. Приказ предусматривает привлечение хостинг-провайдеров, операторов связи или организаций, фильтрующих вредоносный трафик. Средства такой фильтрации должны находиться на территории России.
Если организация сама разрабатывает программное обеспечение, появляется отдельный процесс безопасной разработки по ГОСТ Р 56939-2024. Подрядчику нельзя разрабатывать и тестировать ПО непосредственно в промышленной системе. Для разработки и тестирования должны использоваться выделенные стенды, изолированные от рабочего контура.
Не стоит забывать и про искусственный интеллект. Приказ отдельно регулирует применение ИИ внутри защищаемых систем. Оператор должен контролировать запросы и ответы, учитывать риск недостоверных результатов и не передавать разработчику модели информацию ограниченного доступа для улучшения модели. Для организации, которая подключила внешнего ИИ-помощника к внутренним данным «просто через API», такой пункт может внезапно стать одним из самых сложных.
Мой чек-лист перед вызовом аттестационной комиссии
За несколько недель до аттестации я бы не перечитывал регламенты по очереди, а провел внутреннюю репетицию проверки. Берем случайного сотрудника, администратора, сервер, рабочую станцию, уязвимость, резервную копию и событие безопасности, после чего прослеживаем полный путь каждого объекта.
- Границы системы определены. Есть актуальная схема, перечень серверов, рабочих мест, виртуальных машин, контейнеров, сетей, внешних сервисов и каналов взаимодействия.
- Класс обоснован. Есть расчет уровня значимости, определен масштаб и утвержден акт классификации.
- Меры выбраны правильно. Базовый набор для класса адаптирован под архитектуру и проверен относительно актуальных угроз.
- СЗИ соответствуют проекту. Проверены сертификаты, версии, конфигурации и техническая поддержка.
- Доступ контролируется. Нет общих административных учетных записей, лишних привилегий и забытых пользователей.
- Уязвимости устраняются в срок. Можно показать не только отчет сканера, но и историю исправлений или компенсирующих мер.
- Мониторинг действительно работает. Журналы поступают, события анализируются, инциденты регистрируются, отчеты формируются.
- Резервные копии восстанавливаются. Последняя проверка восстановления завершилась успешно и зафиксирована документально.
- Подрядчики находятся внутри модели защиты. Их доступ формализован, ограничен и контролируется.
- Документы совпадают с инфраструктурой. В регламенте нет старого VPN, давно удаленного антивируса или сервера, которого уже год нет в сети.
Последний пункт чаще всего показывает реальную степень готовности. Аттестация плохо сочетается с инфраструктурой, которая меняется быстрее документов.
Нужно учитывать и ближайшие изменения правил. С 1 сентября меняется не только приказ № 117. Вступает в силу новая редакция порядка аттестации по приказу ФСТЭК № 77. Правила подробнее описывают анализ уязвимостей, тестирование на проникновение, периодический контроль и действия после модернизации аттестованной системы. ФСТЭК также уже утвердила методику оценки уровня зрелости деятельности в области технической защиты информации.
Поэтому готовиться только по старому чек-листу средств защиты я бы не стал. Приказ № 117 фактически проверяет три слоя одновременно. Организация должна правильно определить требования, построить техническую защиту и доказать, что процессы работают постоянно. Если хотя бы один слой существует только на бумаге, проблемы обычно появляются еще до собственно аттестационных испытаний.
Для общего понимания изменений полезно отдельно посмотреть разбор приказа № 117 на SecurityLab. А при проектировании конкретной системы рабочими источниками должны оставаться актуальная редакция приказа, методические документы ФСТЭК, порядок аттестации по приказу № 77 и эксплуатационная документация выбранных средств защиты.
В сухом остатке я бы начинал подготовку не с вопроса «что купить», а с четырех проверок. Какие данные обрабатывает система, какой у нее класс, какие угрозы актуальны и чем подтверждается выполнение каждой выбранной меры. После такого аудита список закупок обычно становится короче, а вероятность неприятных сюрпризов во время аттестации заметно снижается.
Частые вопросы об аттестации по приказу ФСТЭК № 117
Кому нужна аттестация по приказу ФСТЭК № 117?
Для государственных информационных систем аттестация обязательна до начала обработки или хранения информации. Для иных информационных систем государственных органов, ГУПов и государственных учреждений решение принимает руководитель оператора или ответственное лицо. У частных компаний обязанности зависят от роли в конкретной системе, обрабатываемой информации и условий взаимодействия с государственным заказчиком.
Нужно ли переаттестовывать систему из-за вступления приказа № 117?
Нет. Приказ прямо сохраняет действительность аттестатов, выданных до вступления новых требований в силу. Однако модернизация системы, изменение класса или существенные изменения системы защиты могут потребовать дополнительных испытаний либо повторной аттестации.
Что означает класс защищенности К3?
К3 является минимальным из трех классов приказа № 117. Такой класс получается для системы регионального или объектового масштаба с уровнем значимости УЗ 3. К3 должен обеспечивать защиту от нарушителей с базовым уровнем возможностей.
Обязателен ли NGFW для приказа ФСТЭК № 117?
Приказ не требует продукт определенного класса с названием NGFW. Требуются конкретные функции защиты, включая сегментацию, межсетевое экранирование, сетевое обнаружение и предотвращение вторжений и другие меры. Организация может реализовать функции одной платформой или несколькими средствами защиты.
Нужна ли сертифицированная операционная система?
Сертифицированная ОС часто упрощает выполнение требований, но универсального требования использовать только сертифицированные операционные системы приказ не формулирует. Нужно определить, какие функции защиты реализуются средствами ОС, какие отдельными СЗИ и каким образом подтверждается соответствие выбранных средств требованиям ФСТЭК.
Как быстро нужно устранять критические уязвимости?
Уязвимости критического уровня, которые может использовать нарушитель, должны быть устранены либо нейтрализованы компенсирующими мерами не позднее 24 часов. Для уязвимостей высокого уровня установлен срок не более семи календарных дней.
Достаточно ли двухфакторной аутентификации для администратора?
Не любую двухфакторную схему можно автоматически считать соответствующей требованиям. Для привилегированного доступа приказ устанавливает строгую аутентификацию, а при технической невозможности ее применения допускает усиленную многофакторную аутентификацию. Конкретный механизм нужно сопоставлять с требованиями ФСТЭК и применяемых стандартов.
