Компания «Вебмониторэкс» уже несколько лет развивает средства защиты API в составе единой платформы на базе WAF. Ее назначение – отражение веб-угроз, нарастающих на фоне внедрения генеративного искусственного интеллекта и больших языковых моделей. Насколько серьёзна ситуация и что необходимо для отражения атак?
- Введение
- Проблемы защиты от кибератак через API
- Основные виды атак через API
- Как бороться против атак через API?
- Атаки нового типа через API с использованием ИИ
- Российское решение для защиты API («Вебмониторэкс»)
- Выводы
Введение
Значительная часть современных технологий безопасности построена на анализе данных, которые передаются по контролируемым каналам связи. ИТ- и ИБ-специалисты могут получить много информации об особенностях трафика: протокол и порт, результаты совпадения с сигнатурами атак. В случае выявления аномалий допустимо уверенно сказать, что есть признаки вредоносной активности, и использовать собранные данные как точку отсчёта для более детальной проверки.
Анализ трафика, передаваемого через API, не так очевиден. Во-первых, API и их спецификации чаще всего публичные, поэтому возникновение нового источника данных ещё не считается аномалией. Во-вторых, список допустимых к применению команд задаётся вендором, разработавшим API. В зависимости от своих задач он может периодически менять возможности и команды API, но они всегда будут легитимны.
Разработчику неизвестны степень зрелости и особенности контроля безопасности API у компаний-контрагентов. В контексте информационной безопасности всё это создаёт нежелательные предпосылки, которыми могут воспользоваться злоумышленники. Соответственно, мы всё чаще слышим о векторе защиты API Security.
Главным центром, который устанавливает правила учёта и классификации угроз, связанных с работой API, считается проект OWASP (The Open Worldwide Application Security Project). Благодаря ему специалисты со всего всего мира образовали своего рода сообщество. Они подсказывают, как безопасно провести разработку и наладить поддержку API. Один раз в четыре года OWASP выпускает список наиболее существенных рисков, связанных с API Security. Последняя версия выпущена в 2023 году (предыдущая — в 2019 году). Следующая появится только в 2027 году.
Рисунок 1. Количество API в ИТ-инфраструктуре компаний (Traceable, 2025)
Проблемы защиты от кибератак через API
На первый взгляд, возможности кибератак путём злонамеренного использования API не выходят за рамки обычных угроз ИБ. Однако реальная ситуация оказывается значительно более тревожной, чем может показаться.
Мы ознакомились с новым отчётом компании Traceable о трендах на рынке API Security — 2025 Global State of API Security. Согласно исследованию, в мире ситуация с безопасностью API достаточно напряжённая, особенно в таких отраслях, как Интернет-технологии, финансовые услуги, здравоохранение и розничная торговля.
При подготовке отчёта 2025 Global State of API Security авторы опросили 1548 экспертов по ИТ и ИБ более чем из 100 компаний по всему миру. Выяснилось, что за последние два года 57 % организаций по крайней мере один раз выявляли у себя утечку данных, вызванной злонамеренными или мошенническими действиями с применением API.
Рисунок 2. Обоснование необходимости защищать API
Несмотря на высокий уровень риска, проверку на уязвимости в среднем проходят только 38 % используемых API. Как отметили многие опрошенные эксперты, управляемость API в организациях во многом ограничена. Даже если атака на API будет обнаружена, только 24 % респондентов уверены, что её остановят / предотвратят. В ближайшем будущем (1–2 года) риск результативных атак через API увеличится, так считают более половины отвечавших (61 %).
Рисунок 3. Доля успешно отражаемых атак на API
Основная проблема, с которой сталкиваются ИБ-специалисты при работе с API, заключается в том, что на управление и контроль API наложены ограничения. Этого мнения придерживается более половины опрошенных (54 %). Распространение API и взаимодействие различных крупных внешних систем с их помощью только повышают риски.
У многих разработчиков не выстроен процесс документирования возможностей и вносимых изменений. В результате контрагентам становится сложнее работать с API и даже вести простой мониторинг их трафика. Отсутствие актуальных спецификаций заставляет компании самостоятельно выявлять внесённые изменения.
Основные виды атак через API
Трудности защиты передаваемых данных связаны не только с большим разнообразием интерфейсов API и отсутствием жёсткой стандартизации. Анализ безопасности API серьёзно затрудняют расширение периметра атак и использование разнообразных техник.
Лидерами кибератак на API считаются DDoS; это выделили 38 % респондентов. Подобные атаки забивают API паразитным трафиком, вызывают перебои в его обслуживании, заставляют компании выстраивать защиту от угроз неопределённого масштаба, что ведёт к повышенным затратам и организационным проблемам.
Рисунок 4. Типы атак на API, вызвавших утечку данных
Высоки также доли фрода и ошибочного использования данных. Это не всегда связано с мошенничеством и вредоносной активностью. И то и другое вероятно, если у компаний нет актуальных сведений о вносимых в API изменениях. Когда не хватает согласованности, начинают подозревать реальных пользователей. Этим активно пользуются злоумышленники, маскируя свои атаки.
Не менее тревожным признаком является высокий процент «хорошо известных атак» (known attacks). Для них уже имеются сигнатуры. Список применяемых в инфраструктуре API слишком велик, так считают злоумышленники, и не без оснований. Они делают ставку на то, что администраторы ИБ не предусмотрели проверку части API.
Это создает двойную проблему: с одной стороны, средства противодействия определённым атакам уже установлены в компании, с другой — часть API ещё не защищена надлежащим образом. В результате возникают слепые зоны для служб безопасности.
Как бороться против атак через API?
Для того чтобы предотвратить несанкционированное воздействие на API, чаще всего используют межсетевые экраны уровня веб-приложений (WAF) либо специализированные программные решения для защиты веб-приложений и API (WAAP). Как утверждают респонденты, имеющиеся средства защиты часто малоэффективны. Это заставляет компании пересматривать свои стратегии защиты и искать более мощные инструменты.
Эксперты выделяют техники, которые можно применять для защиты API.
Рисунок 5. Меры повышения защищённости API
Популярность API как объекта атак сложилась не так давно. Накопленных знаний и компетентных специалистов пока немного. Для ИБ-служб приоритетом оказывается не выбор эффективных средств реагирования, а решение организационных вопросов, позволяющих приступить к выстраиванию защиты API.
Компании не всегда способны вовремя обнаружить в череде событий характерные черты атаки на API и выделить признаки преступных действий. И то и другое оказывается более актуальной проблемой, чем предотвращение развития атаки.
Рисунок 6. Угрозы нарушения безопасности API
Исследователи назвали также инструменты для защиты API.
Рисунок 7. Инструменты для защиты API от кибератак
Атаки нового типа через API с использованием ИИ
С учётом изложенного выше возникают вопросы. Почему так мало вендоров, создающих инструменты безопасности API? Каковы причины того, что этим угрозам не уделяется такое же пристальное внимание, как, например, защите от DDoS или борьбе с уязвимостями Zero Day? По значимости атаки на API легко сравнить с проникновением в периметр компании.
Ответ достаточно прост: существующие ИТ-системы используют API, которые более-менее статичны по своей организации, и для них достаточно встроенных проверок. Контроль над использованием API не сложнее типовых задач ИБ.
В последнее время многое изменилось. Угроза нарастает за счёт того, что становятся доступны интерактивные инструменты, связанные с применением генеративного ИИ (GenAI) и больших языковых моделей (LLM). Согласно прогнозу Gartner, к 2026 году внедрение API увеличится именно благодаря системам ИИ и инструментам, использующим LLM (и то и другое обусловит рост показателя более чем в 30 % случаев).
Причина большего внимания к защите API заключается в том, что это основной механизм для передачи данных для ИИ-продуктов. Благодаря ему системы могут общаться между собой и обеспечивать простое онлайн-взаимодействие пользователей. Всё более активное распространение агентов и приложений на базе ИИ приводит к изменениям в ИТ-инфраструктурах. В будущем пользователями API станут не столько люди, сколько другие ИИ-системы, которые будут работать на пользователей.
Насколько серьёзно может измениться ситуация? Согласно оценкам, недалёк тот день, когда на каждого пользователя будет приходиться около 100 индивидуально настроенных API к ИИ-инструментам. Можно вспомнить оценку Statista: уже сегодня в мире насчитывается около 5,56 млрд пользователей интернета. Предполагается, что появится примерно 556 млрд индивидуально настроенных API для ИИ-систем. Оценка выглядит сильно завышенной, но она указывает на порядок количества профилей API. Вряд ли могут быть сомнения, что ситуацией воспользуются злоумышленники.
Рисунок 8. Изменение модели угроз для защищённости API с появлением ИИ
Интеграция ИИ с существующими экосистемами API породит множество новых рисков. Прежде всего, увеличится поверхность кибератак. Инструменты GenAI получат доступ к API, создавая новые эндпойнты для злоумышленников.
Кроме того, специфика работы AI-систем связана с переносом огромных массивов данных. Возникает риск, что в их число попадёт чувствительная для компании информация. Следует также учитывать, что API-интерфейсы ИИ-систем вынесены за пределы периметра защиты. Поэтому доступ к ним могут получить злоумышленники, использующие открытые порты ИИ-систем.
При интеграции ИИ у компаний могут возникнуть следующие проблемы:
- контроль конфиденциальных данных (60 %);
- управление безопасностью (55 %);
- отсутствие централизованного инструмента управления (36 %);
- дефицит стандартизации для API, используемых для доступа к ИИ или LLM (29 %).
Для контроля за работой API для ИИ-систем (GenAI) предлагают использовать DLP системы и ИИ-шлюзы (AI Gateway). Но эти решения, согласно исследованию, пока малоэффективны. Как показали опросы экспертов, большинство пользователей (60 %) легко находят способы обойти ограничения, предусмотренные на рабочем месте.
Рисунок 9. Типовая схема ИИ-шлюза для защиты API (Kong Inc.)
Российское решение для защиты API («Вебмониторэкс»)
Защитить API призваны продукты компании «Вебмониторэкс». В её портфеле есть собственный WAF (Web Application Firewall) и три решения линейки API Security: «ПроAPI Структура», «ПроAPI Защита» и «ПроAPI Тестирование». Все они действуют в русле подхода API-First.
Концепция API-First указывает на то, что главным в любой разработке является API. Суть относительно проста: поставить применение и безопасность API и модели его использования как более приоритетные по сравнению с решением других задач и выполнением процессов при разработке программных систем.
Очевиден отказ от подхода, когда процессы разработки начинают с постановки бизнес-приоритетов или выбора путей взаимодействия с базовой платформой. В этом случае выстраивание API осуществляется позднее и происходит в зависимости от имеющихся ограничений.
Предлагаемая модель защиты API предусматривает следующие основные задачи:
- собрать полную информацию обо всех API в инфраструктуре и об их изменениях (функции продукта «ПроAPI Структура»);
- на основе актуальной спецификации валидировать запросы к API в рамках позитивной модели (функции продукта «ПроAPI Защита»);
- выявлять недекларированные возможности, аномалии и угрозы в API до того, как ими начнут пользоваться злоумышленники (функции продукта «ПроAPI Тестирование»).
Рисунок 10. Модель защиты API, используемая компанией «Вебмониторэкс»
Наблюдаемость всех API в инфраструктуре обеспечивает продукт «ПроAPI Структура». Он использует спецификацию OpenAPI, что позволяет отображать данные, полученные путём анализа трафика на эндпойнты. Собранная информация позволяет:
- разделить API на публичные и внутренние;
- выявлять проблемные API (теневые/shadow, неиспользуемые/orphan, «призрачные»/zombie);
- отслеживать изменения в структуре API;
- контролировать передачу чувствительных данных (например, персональных) через API;
- выделять эндпойнты, подвергающиеся атаке, и собирать список отправляемых им вредоносных запросов;
- настраивать правила для продукта «ПроAPI Защита».
В 2024 году появилось дополнение к «ПроAPI Структура» — новый компонент «Обнаружение утечек API». Он позволяет автоматически находить и блокировать запросы с использованием утекших токенов / секретов.
Используя этот компонент, можно наладить отзыв ключей после их компрометации. Это позволяет выявлять попытки их эксплуатации через запросы, содержащие утерянные токены. IP-адрес, с которого поступил скомпрометированный токен, можно потом передать в SIEM для блокировки другой активности того же источника.
Продукт «ПроAPI Тестирование» выявляет различные ошибки и уязвимости, связанные с работой API. Для проверки используется спецификация OpenAPI 3.0, что позволяет автоматически подготовить тесты для оценки защищённости роутов от различных кибератак, начиная от SQL-инъекций и заканчивая SSRF.
Специалисты «Вебмониторэкса» регулярно обновляют свои продукты. Собственная команда анализа угроз помогает справляться как с новыми уязвимостями, так и с рисками, перечисленными в последнем отчёте OWASP.
Рисунок 11. Главные риски API (OWASP), для работы с которыми предназначены продукты компании «Вебмониторэкс»
Выводы
Быстрое распространение приложений, использующих GenAI и LLM, существенно повышает требования к защищённости как уже существующих API, так и вводимых для новых инструментов ИИ. Если есть намерение развивать средства контроля API и отражения кибератак на них, организациям нужно проявлять больше внимания к проблеме. Среди доступных отечественных решений можно назвать продукты компании «Вебмониторэкс», которые постоянно совершенствуются. Их внедрение позволит усилить защиту API, установленных в инфраструктуре, и подготовиться к безопасному использованию ИИ в работе.
