Безопасность API в SaaS: чеклист проверки интеграций

В классификации OWASP API Security Top 10 за 2023 год эта проблема называется Broken Object Level Authorization, или BOLA.

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

Уязвимости архитектуры: BOLA, SSRF и бизнес-потоки

BOLA возникает, когда сервер проверяет, что пользователь прошёл аутентификацию, но не сверяет его права с конкретным объектом. Например, клиент отправляет запрос к записи с идентификатором 7421, а API возвращает данные без проверки, принадлежит ли эта запись его организации. Подмена ID в запросе тогда становится способом доступа к чужой информации.

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

При аудите полезно пройти по ресурсам API и задать для каждого один и тот же набор вопросов:

1. Кто может выполнить запрос: пользователь, сервисная учётная запись или любой обладатель токена?

2. Проверяет ли сервер принадлежность объекта нужному пользователю, команде или организации?

3. Совпадают ли права для чтения, изменения и удаления, или для каждой операции задана отдельная политика?

4. Что вернёт API при подмене идентификатора: отказ, пустой ответ или данные чужого объекта?

5. Не раскрывают ли ошибки, журналы и ответы API внутренние идентификаторы и сведения о чужих записях?

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

В OWASP API Security Top 10 2023 года отдельно выделена угроза SSRF, или Server Side Request Forgery. Она возникает, когда API принимает от клиента адрес или URL, а затем сам обращается по нему. Если адрес контролируется недостаточно строго, сервер могут заставить запрашивать ресурсы, которые извне недоступны. Риск появляется в функциях импорта по URL, загрузки изображений, вебхуках и обработке документов.

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

Ещё один отдельный класс риска — неограниченный доступ к чувствительным бизнес-потокам, обозначенный в классификации OWASP как API6:2023. Запрос может быть корректным по формату и авторизации, но автоматизация сценария создаёт ущерб: массовое бронирование, перебор промокодов, создание большого числа заявок. Здесь нужны ограничения на уровне бизнес-операции, а не только на уровне сетевого соединения.

Проверка токена отвечает на вопрос, кто пришёл. BOLA-аудит отвечает на вопрос, какую именно запись этому субъекту разрешено затронуть.

Аутентификация и права: OAuth 2.0, OIDC и жизненный цикл токена

Для SaaS-интеграций обычно применяют OAuth 2.0 и OpenID Connect. OAuth 2.0 задаёт механизм делегирования доступа, а OIDC добавляет слой идентификации. Выбор конкретного потока зависит от типа клиента и сценария интеграции. Архитектурная задача при этом остаётся прежней: выдать минимально необходимые права и ограничить последствия утечки учётных данных.

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

Access-токены для SaaS-интеграций обычно настраивают с коротким сроком действия, ориентиром служит диапазон 15–60 минут. Долгоживущий токен увеличивает окно, в котором украденный секрет остаётся пригодным. Короткий срок сам по себе не предотвращает компрометацию, поэтому нужно продумать безопасное обновление токенов и отзыв доступа при инциденте.

Проверка конфигурации включает несколько уровней:

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

JWT — формат токена, а не готовая политика безопасности. Наличие подписанного JWT не доказывает, что приложение проверяет нужные права, срок действия и ожидаемого получателя. Следует проверить, какие поля токена валидирует API, как обрабатывает истёкшие или некорректные токены и не принимает ли один сервис токен, выпущенный для другого контекста.

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

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

Шифрование данных при передаче и хранении

Для защиты API-трафика применяют HTTPS с TLS 1.2 или TLS 1.3. Это защищает данные при передаче по сети, но не исправляет ошибки авторизации и не защищает уже сохранённые данные от неправильной настройки доступа. Шифрование канала, контроль прав и защита хранилища решают разные задачи.

Для чувствительных данных в хранении используют AES-256. Само упоминание алгоритма в документации сервиса ещё не отвечает на вопросы управления ключами. Нужно выяснить, кто управляет ключами, как ограничен доступ к ним и что происходит при их ротации. При оценке SaaS отдельно учитывают данные в резервных копиях, экспортах и логах: если чувствительные поля копируются в незащищённую систему мониторинга, шифрование основного хранилища не закрывает риск.

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

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

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

API-шлюз, rate limiting и защита от исчерпания ресурсов

API-шлюз помогает централизовать маршрутизацию, аутентификацию, ограничения запросов и сбор телеметрии. Он не заменяет проверки авторизации внутри сервиса. Если шлюз пропускает запрос с корректным токеном, приложение всё равно должно определить, имеет ли субъект право на конкретную запись.

Rate limiting ограничивает частоту запросов и помогает сдерживать перебор, злоупотребление ресурсами и часть DoS-сценариев. Лимиты нужно связывать с контекстом: адресом клиента, учётной записью, токеном или конкретной операцией. Один общий предел на весь API может одновременно пропустить атаку на чувствительный эндпоинт и заблокировать нормальную работу других клиентов.

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

При настройке шлюза проверьте:

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

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

Мониторинг подозрительной активности и аудит интеграции

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

Мониторинг должен выявлять отклонения от поведения интеграции: резкий рост ошибок авторизации, массовое чтение объектов, необычную частоту запросов, повторяющиеся обращения к последовательным ID и всплеск операций экспорта. Отдельно анализируют вызовы, где один субъект последовательно обращается к объектам, принадлежащим разным организациям. Такой паттерн может указывать на BOLA или на ошибку в серверной логике.

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

Проверку безопасности API в SaaS интеграциях удобно завершать коротким циклом ревизии:

1. Составить список интеграций, их владельцев, токенов и доступных ресурсов.

2. Сверить разрешения с фактическими функциями и удалить избыточные права.

3. Проверить объектную авторизацию на чтение, изменение и удаление, включая вложенные и пакетные запросы.

4. Проверить обработку URL и перенаправлений в функциях импорта, вебхуков и загрузки данных.

5. Подтвердить использование TLS, правила хранения чувствительных данных и управление ключами шифрования.

6. Проверить лимиты запросов, размеры пакетов и поведение при отказе внешнего сервиса.

7. Убедиться, что журналы поддерживают расследование, но не содержат токены и лишние данные.

8. Отработать отзыв учётных данных и отключение интеграции на тестовом сценарии.

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

Безопасность интеграции определяется тем, как система проверяет каждый запрос и ограничивает его последствия. OAuth и короткий срок действия токена уменьшают риск компрометации учётных данных. TLS защищает канал. AES-256 относится к защите данных в хранении. Rate limiting сдерживает злоупотребление нагрузкой. Ни одна из этих мер отдельно не закрывает BOLA, SSRF и ошибки бизнес-логики. Приёмка интеграции должна опираться на проверяемые права, реальные сценарии запросов и заранее отработанный отзыв доступа.