Когда вы открываете 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 состоит из двух частей:

  1. Сервер (или кластер серверов) проксирования — пропускает, анализирует и маршрутизирует трафик в соответствии с заданными правилами.

  2. Сервер управления и конфигурации — предоставляет веб-интерфейс для администрирования, хранит логи и настройки, управляет конфигурациями.

Схема работы IVA SBC
Схема работы 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)


  1. nv13
    20.08.2025 17:48

    если в теле запроса к API случайно (или намеренно) изменить заглавную букву в названии параметра, то SBC вернет 403 Forbidden и зафиксирует это как нарушение модели. Все просто и эффективно.

    А само API не 403 вернуло бы? Не очень понятно, зачем всё таки такое нужно - что бы защититься от отсутствия корректной валидации запросов на самом сервере? Иметь более простое управление полиси и валидацией разных апи в одном месте? На серверах валидация вообще не делается? Но ведь севисы могут использовать внешние апи между собой тоже и не через sbc. В общем понятно, что элегантное достаточно решение, но цели как то неочевидны, имхо.


  1. savostin
    20.08.2025 17:48

    Как много слов… Основная задача Application Firewall - отсечь сетевые атаки. Когда идет много запросов нужно быстро и легко их обработать и отсеять. Это достигается за счет «не парсинга» тела запроса. Те вместо того, чтобы разгрузить приложения, вы продублировали логику парсинга тела запроса и вложили кучу денег в CPU.

    Я понимаю, что конкретно в вашем случае это возможно слегка сняло нагрузку с приложений, т к они еще более тяжелые. Но в общем случае такой подход не оправдан имхо.