Утечки данных через API: аналитика инцидентов и реальные цифры уязвимостей

Другой источник, опрос Salt Security за 2024 год, измеряет опыт команд: 37% респондентов сообщили хотя бы об одном инциденте безопасности API за предыдущие двенадцать месяцев. Годом ранее таких ответов было 17%.

Эти показатели не складываются в единую картину ущерба. У Akamai единица измерения — вредоносное обращение в наблюдаемом трафике; у Salt Security — ответ участника опроса об инциденте в его организации. Различаются и методики, и охват. Если держать это различие в уме, цифры помогают оценить масштаб проблемы, не превращая попытки атак в число состоявшихся утечек.

Масштаб киберугроз: статистика атак на программные интерфейсы от Akamai и Salt Security

Akamai анализирует трафик своей глобальной сети доставки контента. В её отчёте за рассматриваемый период указаны 108 миллиардов атак на API. Там же говорится, что число атак на веб-приложения и API вместе выросло на 49% между первым кварталом 2023-го и первым кварталом 2024-го. Это данные о наблюдаемом вредоносном трафике. Они не показывают, сколько обращений привели к компрометации данных, и сами по себе не позволяют посчитать число уникальных атакующих или пострадавших организаций.

Salt Security использует другой подход. В State of API Security Report 2024 компания сообщает результаты опроса специалистов по безопасности и разработке. За предыдущие двенадцать месяцев об инциденте безопасности API сообщили 37% респондентов; об инциденте, связанном с раскрытием чувствительных данных или нарушением приватности, сообщили 38%. Ещё 37% указали, что обнаруживали уязвимости в работающих API. Это доли участников исследования, а не всех компаний и не подтверждённые записи из единого реестра инцидентов.

В исследованиях безопасности легко потерять разницу между событием, попыткой и оценкой респондента. Например, большое число запросов может отражать интенсивное сканирование, но не доказывает, что атакующему удалось пройти авторизацию. А ответ об инциденте не всегда означает, что организация раскрыла публичные подробности или зафиксировала ущерб в финансовой отчётности.

Поэтому статистика утечек данных через API и статистика атак на интерфейсы отвечают на разные вопросы. Первая должна описывать состоявшееся раскрытие информации или потерю контроля над ней. Вторая показывает активность, которую системы наблюдения классифицировали как вредоносную. Эти показатели полезны вместе, но только если не выдавать один за другой.

Большой объём вредоносного трафика говорит о давлении на API. Сам по себе он ещё не сообщает, сколько данных покинуло систему.

Анатомия уязвимостей интерфейсов: как ошибка авторизации BOLA приводит к раскрытию данных

Broken Object Level Authorization, или BOLA, занимает первое место в OWASP API Security Top 10 2023 года. Это ошибка авторизации на уровне объекта: API получает идентификатор записи, но не проверяет, вправе ли текущий пользователь эту запись просматривать или изменять.

Аутентификация отвечает на вопрос, кто обращается к системе. Авторизация определяет, что именно этому пользователю разрешено. Если сервер проверил личность пользователя, но не проверил его права на конкретный заказ, документ или профиль, одного успешного входа недостаточно для защиты данных.

Типичный сценарий выглядит просто. Пользователь запрашивает собственный заказ, а в URL или теле запроса передаётся его идентификатор. Если заменить его на другой, а сервер не проверит принадлежность записи, API может вернуть чужие данные. Сходным образом устроена и возможность менять объект, если проверка прав ограничивается самим фактом наличия действующей сессии.

Функциональные тесты часто подтверждают ожидаемый маршрут: пользователь входит в систему, открывает свою запись, получает корректный ответ. Проверка авторизации требует другого сценария: тот же запрос выполняется от имени пользователя, которому объект не принадлежит. Именно на границе между этими двумя проверками и проявляется BOLA. Это не доказывает, что такая ошибка встречается в большинстве API; это объясняет, почему она требует отдельного внимания при тестировании доступа.

Проверка тоже может быть сложнее, чем сравнение одного поля. Объект может принадлежать организации, проекту или рабочей области, а пользователь получает доступ через роль, группу или делегированные полномочия. Условие вроде «идентификатор владельца записи совпадает с идентификатором текущего пользователя» не покрывает такие модели, если в системе есть другие законные связи доступа. Проверка должна учитывать реальную модель прав, а не удобный для теста частный случай.

Для анализа утечки через программный интерфейс важно смотреть не только на сам идентификатор, но и на то, как сервер принимает решение о доступе:

• Есть ли проверка прав на каждый объект при чтении, изменении и удалении.
• Учитываются ли организация, роль и контекст, если доступ предоставляется не одному владельцу.
• Одинаково ли защищены новые и старые версии API.
• Можно ли по ответам сервера понять, существует ли чужой объект или как устроена система идентификаторов.
• Попадают ли неуспешные попытки доступа в журнал так, чтобы их можно было связать с пользователем или сервисом.

BOLA не сводится к перебору последовательных номеров. Идентификаторы могут выглядеть случайными, но непредсказуемый идентификатор не заменяет проверку полномочий. Если сервер выдаёт данные объекта любому, кто знает его идентификатор, секретность этого значения становится единственным барьером. Для контроля доступа этого недостаточно.

Проблемы видимости и контроля: управление сотнями API в корпоративных системах

По данным Salt Security за 2024 год, 66% опрошенных организаций управляют более чем сотней API. Когда интерфейсов становится так много, ручной список быстро теряет актуальность: команды выпускают новые версии, добавляют партнёрские интеграции, запускают внутренние сервисы и меняют маршруты между компонентами.

Salt Security сообщает также, что у 58% участников есть процесс обнаружения API. Остальные участники не сообщили о наличии такого процесса. Из этой доли нельзя заключить, что организации совсем не знают о своих интерфейсах: исследование говорит именно об ответах респондентов, а не о независимом аудите каждой инфраструктуры. Но отсутствие формальной процедуры усложняет базовую задачу: установить, какие API существуют, кто за них отвечает и какие из них больше не должны принимать запросы.

В большой системе проблема видимости принимает несколько форм. Shadow API появляются вне стандартного процесса разработки и проверки: например, как вспомогательные маршруты для интеграции или тестирования. Устаревшие интерфейсы продолжают работать, потому что у них есть пользователи или никто не уверен, что их безопасно отключить. Внутренний API может неожиданно оказаться доступным через неверную конфигурацию сети или шлюза.

Каждый такой случай требует своего решения. Для нового интерфейса нужно установить владельца и включить его в реестр. Для старого нужно определить, есть ли потребители и как вывести его из эксплуатации без поломки зависимых систем. Для внутреннего требуется проверить фактический маршрут доступа, а не полагаться на название или предполагаемое расположение в сети.

Рабочий учёт API обычно связывает несколько сведений: владельца сервиса, назначение интерфейса, версию, среду, способ аутентификации, разрешённые роли и состояние жизненного цикла. Тогда команда может отличить действующий публичный endpoint от внутреннего интерфейса, который пора отключить, и быстрее установить, кому поручить исправление.

Ключевой вопрос здесь не в том, достигла ли организация условного порога в сто интерфейсов. Важно, есть ли процесс, который обнаруживает изменения и доводит их до реестра. Если инвентаризация обновляется только вручную, она начинает отставать именно тогда, когда API меняются чаще всего.

Неаутентифицированный трафик и внутренние векторы атак в клиентской аналитике Salt Labs

В клиентской аналитике Salt Labs за 2024 год 61% атак на API были классифицированы как неаутентифицированные. Это доля атак в рамках исследования. Её не следует пересказывать как долю всех запросов к API или как долю интерфейсов, оставленных открытыми. Показатель всё же обращает внимание на важный класс рисков: вредоносное взаимодействие может происходить до входа в учётную запись или без использования похищенного токена.

Причина не всегда в том, что endpoint вообще не предусматривает авторизацию. Анонимный доступ может быть намеренным, например для получения публичных данных. Проблема возникает, когда вместе с доступом забывают ограничить объём и характер выдаваемой информации, либо когда проверка прав не соответствует чувствительности операции. Отдельный риск связан с временными и тестовыми маршрутами, если их правила случайно переносятся в рабочую среду.

Такие случаи нельзя обнаружить одним только контролем украденных учётных данных. Нужны проверки доступных без входа маршрутов, сопоставление ответа с назначением endpoint и мониторинг запросов, которые отклоняются или ведут себя нетипично. Если анонимный маршрут необходим, его права и возвращаемые поля должны быть ограничены именно тем, что нужно для публичного сценария.

Salt Labs также сообщает, что 13% попыток атак были направлены на внутренние API. Это не означает, что все такие интерфейсы были доступны напрямую из интернета. Внутренние сервисы могут становиться частью пути атаки из-за ошибок сегментации, настроек шлюза или уже скомпрометированного компонента. Само слово «внутренний» описывает предполагаемое расположение интерфейса, но не доказывает, что запрос к нему всегда исходит из доверенного источника.

Если внутренний API достижим из недоверенной зоны, его защищённость должна определяться реальными проверками доступа, а не названием.

Для сервис-сервисных вызовов важны отдельные удостоверения и ограниченные права. Если один компонент может обращаться ко всем интерфейсам без проверки полномочий, компрометация этого компонента создаёт более широкий риск. Сегментация, аутентификация между сервисами и журналы доступа помогают ограничить такой сценарий и восстановить ход событий после инцидента.

Финансовое измерение ущерба: во сколько бизнесу обходятся инциденты безопасности API

В исследовании Akamai за 2024 год участвовали 1 207 руководителей и специалистов из США, Великобритании и Германии. Среди опрошенных руководителей высшего звена в США среднее финансовое воздействие одного API-инцидента оценивалось в 943 162 доллара. Это самооценка респондентов в конкретной выборке, а не универсальная стоимость инцидента для любой компании.

Эту сумму не стоит раскладывать на конкретные статьи расходов без подтверждения методики исследования. В доступном показателе важны прежде всего его границы: речь идёт об оценке участников опроса, а не о среднем убытке, рассчитанном по финансовой отчётности всех пострадавших организаций. У компании с большим объёмом чувствительных данных и сложной инфраструктурой последствия могут отличаться от последствий для небольшого сервиса.

При разборе собственного инцидента организации обычно приходится отдельно оценивать несколько типов последствий: расследование и восстановление систем, простой затронутых сервисов, обязательства перед пользователями и регуляторами, замену скомпрометированных ключей и учётных данных. Конкретный состав затрат зависит от того, какие данные затронуты, как долго продолжался доступ и какие обязанности возникают в соответствующей юрисдикции. Нельзя автоматически включать штрафы, потерю выручки или отток клиентов в каждую опубликованную оценку Akamai: без подтверждения методики такое разложение создаёт ложную точность.

Финансовый показатель полезнее не как готовый аргумент за покупку конкретного продукта, а как повод задать практические вопросы. Какие API работают с чувствительными данными? Кто первым узнает о необычных обращениях? Можно ли быстро отозвать ключ или ограничить доступ сервиса? Есть ли журналы, по которым команда сможет определить масштаб проблемы? Ответы показывают, где организация уязвима и какие меры стоит поставить в очередь раньше.

Для защиты корпоративных API недостаточно установить шлюз и считать работу законченной. Шлюз может помочь управлять трафиком, но не заменяет проверку прав на объекты, инвентаризацию интерфейсов и расследование событий. Система мониторинга полезна, если команда понимает, какие отклонения требуют реакции, а владелец API может исправить найденную проблему.

Практичный порядок начинается с видимости. Сначала команда собирает реестр публичных и внутренних интерфейсов, назначает владельцев и отмечает устаревшие версии. Затем проверяет авторизацию на уровне объектов в сценариях с разными ролями и контекстами доступа. После этого настраивает журналирование так, чтобы запросы можно было связать с пользователем или сервисным аккаунтом, а при аномалии быстро ограничить доступ.

У API нет единственной уязвимости, которая объясняет все инциденты. Но у повторяющейся проблемы есть узнаваемая основа: система знает, кто обращается, однако теряет контроль над тем, к каким данным и действиям этого пользователя следует допустить. Статистика помогает заметить масштаб давления и услышать сигналы команд. Реальная защита начинается с проверки каждого маршрута, каждого объекта и каждого права доступа.