
Когда вы открываете REST API своего сервиса во внешний мир, вы приглашаете не только легитимных клиентов, но и потенциальных злоумышленников. API по сути становится линией боевого соприкосновения. Сегодня уже недостаточно просто проверять права доступа или надеяться, что фронтенд не отправит «плохой» запрос, да и WAF перестает быть панацеей.
Для защиты от потенциальных злоумышленников мы в IVA Technologies реализовали механизм строгой валидации API прямо на уровне сетевого периметра — в нашем продукте IVA SBC (Session Border Controller). Механизм позволяет не только фильтровать трафик, но и полноценно проверять каждый запрос на соответствие актуальной модели API, автоматически синхронизируемой с основным приложением.
Рассказываем, как устроена эта функция, какие задачи решает — и почему на рынке почти нет аналогов.
Что такое SBC?
SBC (Session Border Controller, пограничный контроллер сессий) — это программное решение, устанавливаемое на периметре сети для контроля, маршрутизации и защиты трафика. Изначально SBC создавались для безопасного обмена голосовым и видео-трафиком между провайдерами, но в корпоративных системах они эволюционировали в универсальные шлюзы безопасности для множества протоколов и сценариев применения.
В IVA Technologies SBC это модульная платформа, выполняющая несколько ключевых задач:
Маршрутизация трафика: HTTP, SIP, H.323, TURN и их комбинаций.
Фильтрация и защита: блокировка DoS-атак на уровне сигнализации (SIP/H.323), отбрасывание некорректных пакетов, фильтрация RTP-потоков.
Сокрытие внутренней архитектуры сети: реализация NAT traversal, чтобы внешние клиенты могли подключаться без раскрытия внутренних IP.
Проксирование WebRTC: безопасная передача данных и медиа-потоков через доверенные каналы.
Сбор и анализ статистики: интеграция с системами мониторинга (например, Victoria Metrics), аудит событий, логирование всех запросов и вызовов.
Архитектурно IVA SBC состоит из двух частей:
Сервер (или кластер серверов) проксирования — пропускает, анализирует и маршрутизирует трафик в соответствии с заданными правилами.
Сервер управления и конфигурации — предоставляет веб-интерфейс для администрирования, хранит логи и настройки, управляет конфигурациями.

Главное отличие IVA SBC от универсальных решений в том, что он глубоко интегрирован в экосистему IVA Technologies и «понимает» внутреннюю логику наших продуктов. Это позволяет, например, автоматически синхронизировать модель API с установленной версией MCU и применять строгую валидацию запросов прямо на сетевом периметре — чего сложно добиться на сторонних SBC.
Что обеспечивает строгая валидация?
Если упрощенно: мы проверяем каждый входящий HTTP-запрос к нашей платформе на соответствие строгой модели API, хранимой на стороне бэкенда. Если запрос не соответствует установленным параметрам, то он не просто отклоняется, а фиксируется в логах, SIEM, с указанием, что именно нарушено.
Архитектура механизма работает так:
Клиент отправляет HTTP-запрос в сторону платформы IVA MCU.
Запрос проходит через пограничный контроллер сессий IVA SBC (Session Border Controller), который выступает в роли HTTP reverse proxy.
SBC точно «знает», как выглядит правильная модель взаимодействия с API. Причем эта модель автоматически извлекается из установленной версии продукта.
Если параметры запроса не соответствуют описанию, то запрос отбрасывается и логируется с подробностями нарушения.
Наглядный пример: если в теле запроса к API случайно (или намеренно) изменить заглавную букву в названии параметра, то SBC вернет 403 Forbidden и зафиксирует это как нарушение модели. Все просто и эффективно.
Откуда берется нужная модель API?
Это одна из наших ключевых фич: IVA SBC не использует внешнюю или отдельную модель API. Он извлекает ее напрямую из установленной версии IVA MCU.
То есть:
SBC автоматически синхронизирует версионность. Если у клиента установлена версия MCU 1.2 — SBC извлечет именно модель 1.2. Обновили MCU — SBC подтянул новую модель. Никаких ручных настроек или конфигураций.
Это упрощает поддержку ИТ-систем, убирает человеческий фактор и позволяет обеспечить корректную проверку именно для той версии API, которая реально используется на сервере. Однако при желании нужную версию можно извлечь и вручную.
Безопасность без компромиссов
Строгая валидация API работает как «брандмауэр по смыслу»: она фильтрует именно по логике взаимодействия с API. Это позволяет:
Отсечь попытки обхода или взлома через некорректные запросы.
Защититься от ряда атак уровня приложения.
Получать точные логи и инциденты в SIEM-систему о каждом нарушении.
Мы оцениваем, что текущая реализация перекрывает до 80% функциональности типичных Web Application Firewall (WAF), но при этом встроена напрямую в наш стек и не требует внешней интеграции. Это не просто удобная фича, а ощутимый вклад в безопасность всей системы корпоративных коммуникаций.
Только для своих
Наш SBC не проектировался как решение для внешних сервисов. Строгая валидация — это фича, заточенная под продукты IVA Technologies, в первую очередь под MCU. Благодаря тесной интеграции SBC может работать с точной моделью API, чего невозможно добиться в универсальных решениях.
Почему это важно?
Мы видим API одновременно и как способ интеграции, и как потенциальный вектор атаки. Именно поэтому защита начинается не на периметре, а на уровне логики взаимодействия. Строгая валидация это наш способ поставить барьер там, где многие просто надеются на «корректный клиент».
В отличие от большинства разработчиков web приложений, которые сбрасывают все вопросы безопасности на внешний WAF, мы занимаемся безопасностью на уровне архитектуры и функций непосредственно в составе наших продуктов, и делаем это хорошо.
Нам важно, чтобы коммуникационные продукты IVA Technologies не только работали, но и оставались надежно защищенными. А значит — все ваши данные, процессы и пользователи будут в безопасности.
Комментарии (2)
savostin
20.08.2025 17:48Как много слов… Основная задача Application Firewall - отсечь сетевые атаки. Когда идет много запросов нужно быстро и легко их обработать и отсеять. Это достигается за счет «не парсинга» тела запроса. Те вместо того, чтобы разгрузить приложения, вы продублировали логику парсинга тела запроса и вложили кучу денег в CPU.
Я понимаю, что конкретно в вашем случае это возможно слегка сняло нагрузку с приложений, т к они еще более тяжелые. Но в общем случае такой подход не оправдан имхо.
nv13
А само API не 403 вернуло бы? Не очень понятно, зачем всё таки такое нужно - что бы защититься от отсутствия корректной валидации запросов на самом сервере? Иметь более простое управление полиси и валидацией разных апи в одном месте? На серверах валидация вообще не делается? Но ведь севисы могут использовать внешние апи между собой тоже и не через sbc. В общем понятно, что элегантное достаточно решение, но цели как то неочевидны, имхо.