ФСТЭК России меняет подход к защите информационных систем: API становятся самостоятельным объектом защиты, а WAF — одним из ключевых элементов безопасности веб-периметра. Почему эти изменения важны для бизнеса и как они меняют требования к защите цифровых сервисов?
- 1. Введение
- 2. От защиты системы — к защите веб-периметра
- 3. API — новый отдельный объект защиты
- 4. WAF — must-have зрелой инфраструктуры
- 5. Боты теперь в фокусе внимания регулятора
- 6. Выводы
Введение
За последние несколько лет корпоративный веб-периметр радикально изменился. Он уже не ограничивается сайтами-визитками и несколькими веб-порталами, а включает десятки API, онлайн-сервисов, партнёрских интеграций, личных кабинетов, ИИ-интерфейсов. Меняются и подходы атакующих: они больше не «взламывают систему», а используют весь цифровой контур бизнеса как поле для атаки.
Учитывая эти изменения, ФСТЭК России решил отразить этот сдвиг и на нормативном уровне. Если раньше требования регулятора в основном концентрировались вокруг классических мер защиты (разграничение доступа, криптошлюзы, антивирусная защита, регистрация событий), то новая нормативная база — это переход к модели управления внешней цифровой экспозицией. Здесь ключевыми становятся инвентаризация, контроль изменений, защита API и устойчивость клиентских сервисов.
Этот переход отчётливо виден в трёх важных документах, выпущенных ФСТЭК России:
- «Требования о защите информации, содержащейся в государственных информационных системах, иных информационных системах государственных органов, государственных унитарных предприятий, государственных учреждений», утверждённые приказом ФСТЭК России от 11.04.2025 № 117 (вступил в силу в марте 2026 года).
- Методический документ «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах» (опубликован 12 апреля 2026 года).
- Рекомендации по повышению защищённости информационной инфраструктуры от угроз безопасности информации, связанных с атаками типа «отказ в обслуживании» (опубликованы 22 мая 2026 года).
Давайте детально разберёмся в новых требованиях к защите веб-периметра.
От защиты системы — к защите веб-периметра
В обновлённой регуляторике появляется понятие «поверхность компьютерной атаки» как совокупность компонентов информационной системы, которыми может воспользоваться злоумышленник. ФСТЭК России напрямую говорит: чем больше публичных сервисов на периметре, тем больше возможностей для реализации атаки. А уменьшение поверхности атаки — одна из «важнейших задач по защите информационных систем». То есть если раньше регулятор спрашивал: «Какие СЗИ стоят на периметре?», то теперь основной акцент сделан на том, какие веб-интерфейсы вообще существуют, зачем они нужны и насколько контролируются.
В рекомендациях ФСТЭК России указывается необходимость контроля опубликованных интерфейсов, выявления несанкционированных сервисов и ограничения неиспользуемых точек входа. По сути, регулятор впервые формализует необходимость постоянной инвентаризации веб-периметра: владелец инфраструктуры должен понимать, какие приложения, API, административные интерфейсы и интеграционные сервисы доступны извне, в каком состоянии они находятся и какие угрозы с ними связаны.
API — новый отдельный объект защиты
До недавнего времени API (программные интерфейсы взаимодействия приложений) почти не рассматривались как самостоятельный объект защиты, а воспринимались как часть веб-приложения или дополнительный веб-сервис. Но за последние годы API превратились в ключевой механизм взаимодействия цифровых сервисов. Вместе с удобством эксплуатации это создало новую проблему. Если раньше компрометация веба часто ограничивалась фронтендом, то сегодня компрометация API означает прямой доступ к операциям, данным клиентов, транзакциям и партнёрским интеграциям.
На этом фоне ФСТЭК России выводит безопасность API в отдельное направление. В методическом документе «Состав и содержание мероприятий и мер по защите информации, содержащейся в информационных системах» есть отдельный раздел 4.8 «Защита программных интерфейсов взаимодействия приложений (API) (ЗПИ)». Именно он детализирует требования к защите API.
Чтобы соответствовать рекомендациям, владелец инфраструктуры должен:
- гарантировать защиту данных, передаваемых через API. Фактически API не должны выдавать избыточные данные о внутренней архитектуре, конфигурации, ошибках обработки и механизмах аутентификации. Для этого требуется определить и задокументировать перечень API, использовать шифрование каналов, осуществлять регулярный пересмотр режимов и перенастройку ПО, реализующего API, чтобы исключить уязвимости конфигурации.
- обеспечивать полноценную проверку каждого API-запроса. ФСТЭК России требует определить перечень API, для которых необходим контроль доступа пользователей и приложений. Речь идёт не только о контроле входа в API, но и о проверке прав при каждом обращении (идентификация и аутентификация), ограничении параллельных сессий и частоты запросов (rate limiting), контроле неактивных сессий.
- проверять API на соответствие спецификации (структуре и типам данных). Требуется внедрить проверку входящих API-вызовов по позитивной модели безопасности. То есть допустимы только те запросы, которые полностью соответствуют утверждённой спецификации, а остальные отклоняются. Дополнительно требуется регулярный пересмотр API и выявление недокументированных, устаревших и неиспользуемых интерфейсов.
Таким образом, ФСТЭК России требует от компаний инвентаризировать API и вести контроль изменений, управлять API-уязвимостями, мониторить API-события. Для бизнеса это означает пересмотр архитектуры безопасности: на первый план выходят решения, способные анализировать не только синтаксис HTTP-запросов, но и бизнес-логику и структуру данных на уровне API.
Возникает вопрос: какие СЗИ могут решить такую задачу? Теоретически это можно реализовать с помощью межсетевого экрана уровня приложений (WAF), который использует дополнительные механизмы, такие как rate limiting.
Однако WAF не может в полной мере реализовать требования в части аудита и инвентаризации. Для этих задач используются решения класса API Security, которые позволяют получить полную картину текущей API-инфраструктуры и контролировать её целостность: отслеживать появление несанкционированных и теневых эндпоинтов, а также данные, которые передаются через API. Дополнительно применяются решения класса API Firewall, которые проверяют все запросы на соответствие ранее загруженной спецификации.
WAF — must-have зрелой инфраструктуры
Хотя ФСТЭК России напрямую не выделяет WAF как обязательное средство защиты, сама логика требований и методологии службы фактически делает межсетевой экран уровня приложений центральным элементом защиты веб-периметра. Если в традиционной архитектуре WAF рассматривался как дополнительный уровень защиты от известных веб-атак, то в современной регуляторной логике его значение существенно расширяется.
Методические рекомендации к приказу № 117 содержат отдельный раздел «Защита веб-технологий (ЗВТ)». В нём описаны четыре ключевые меры, в реализации которых помогает WAF.
Защита пользовательских данных. Документ рекомендует использовать HTTPS/TLS, отказаться от кэширования чувствительных данных в браузере и автозаполнения конфиденциальных форм. Напрямую указана недопустимость таких инцидентов, как межсайтовый скриптинг (XSS) и кликджекинг. WAF можно настроить на принудительное использование HTTPS (блокировать нешифрованный HTTP-трафик), а также на добавление необходимых HTTP-заголовков безопасности к ответам защищаемого веб-приложения. Кроме того, WAF способен фильтровать подозрительный контент в запросах, защищая данные от компрометации.
Управление доступом пользователей. Ключевой смысл здесь — Zero Trust для веб-приложений. Доступ к ресурсам должен регулироваться политиками безопасности: ограничением прав, своевременным отключением уволившихся сотрудников, применением многофакторной аутентификации (для привилегированных пользователей). И хотя такая защита обычно реализуется в рамках самого приложения или IAM-систем, WAF может дополнить эти меры, помогая контролировать соблюдение политик. Например, блокировать запросы к отдельным разделам ресурса при отсутствии аутентификационных данных.
Контроль и фильтрация трафика веб-приложений. Это фильтрация HTTP-запросов на предмет базовых атак (SQL-инъекций, внедрения кода и т. п.), контроль раскрытия чувствительных данных и выявление аномалий трафика. Документ фактически требует наличия инструмента, который анализирует трафик веб-приложения в режиме реального времени и предотвращает распространённые веб-атаки. Эти функции реализуются именно WAF, который обеспечивает проактивную защиту от взломов и эксплойтов.
Регистрация событий по безопасности. Необходимо фиксировать все попытки доступа, аутентификации, изменения учётных записей и параметров и передавать их в SIEM. WAF и здесь играет значительную роль: ведёт журналы всех запросов и действий, включая детали заблокированных атак, и может интегрироваться с системами мониторинга событий ИБ.
Рекомендации по противодействию атакам типа «отказ в обслуживании» прямо указывают на необходимость применения межсетевых экранов уровня приложений (WAF) для доступных из сети веб-сервисов. Это касается как операторов ГИС, так и владельцев критической информационной инфраструктуры.
В частности, рекомендуется:
- на имеющихся средствах межсетевого экранирования включить сигнатурные правила для обнаружения SQL-инъекций, XSS-атак, аномальных заголовков, а также правила проверки структуры HTTP-запросов — длины URL, заголовков и методов;
- на веб-серверах и балансировщиках нагрузки реализовать блокировку слишком больших заголовков и некорректных запросов;
- блокировать на пограничных маршрутизаторах (или специализированных СЗИ) трафик по геопризнаку (GeoIP);
- для защиты от атак типа Slowloris (DDoS на уровне L7) реализовать закрытие медленных TCP-соединений и ограничить длительное удержание соединений.
Кроме того, на уровне L7 рекомендуется предусмотреть защиту от бот-атак. Разберём этот пласт защиты отдельно.
Боты теперь в фокусе внимания регулятора
Примечательно, что рекомендации по противодействию атакам типа «отказ в обслуживании» акцентируют внимание на бот-атаках. ФСТЭК России рекомендует обеспечить внедрение антибот-защиты с использованием обратного прокси (reverse proxy) или балансировщиков нагрузки. Кроме того, на уровне L7 следует предусмотреть блокировку пустых User-Agent и User-Agent ботов, а также внедрение инструмента CAPTCHA.
По сути, это базовая архитектура WAF: он работает как reverse proxy, терминирует клиентские соединения и анализирует запрос до того, как он попадёт в приложение. Это позволяет реализовать проверку IP-адресов, анализ частоты запросов, fingerprinting клиента, анализ выполнения JavaScript.
Такие рекомендации могут быть эффективны как инструмент защиты от базовых скриптов. Однако для отражения атак продвинутых ботов, которые маскируются под реальных пользователей, этого недостаточно. Для их детектирования требуется поведенческий анализ, который реализуется в современных антибот-решениях.
Выводы
Главный сдвиг, который сейчас закрепляет ФСТЭК России, заключается не в появлении новых средств защиты, а в изменении самой логики безопасности. Периметр определяется уже не просто списком хостов, но и всеми опубликованными сервисами и приложениями с учётом их бизнес-логики.
Для бизнеса и ИБ-служб это означает новую управленческую реальность: вопрос уже не в том, «защищена ли система», а в том, насколько контролируется поверхность атаки. Любая ошибка в веб-приложении или API — это не просто техническая уязвимость, а потенциальный бизнес-ущерб: остановка сервиса, утечка данных, потеря доверия, регуляторные последствия.
И здесь WAF и API Security становятся не просто элементами ИБ-архитектуры, а инструментами управления бизнес-риском, устойчивостью цифровых сервисов и, в конечном счёте, непрерывностью бизнеса. Потому что в современной цифровой модели атакуют уже не инфраструктуру — атакуют сам бизнес.
