API-интеграции между маркетинговыми сервисами часто ломаются не по коду, а по доступам

API-интеграции между маркетинговыми сервисами часто ломаются не по коду, а по доступам

Интеграции CRM, трекеров, DSP, email-платформ и BI-систем обычно строятся на постоянных токенах и широких правах. Риск появляется там, где один ключ умеет читать лиды, менять кампании и выгружать отчеты. При компрометации такого контура атакующий получает не один сервис, а связку процессов и данные сквозного трекинга.

Базовая защита начинается с сегментации прав:
— отдельный токен на каждую интеграцию;
— минимальный scope без write-доступа там, где достаточно read;
— ротация секретов через хранилище, а не вручную;
— жесткая привязка webhook-ов к allowlist IP и подписи запросов;
— запрет на использование личных API-ключей в production.

Вторая зона риска — утечки через логи и webhook-пайплайны. В логи не должны попадать Authorization headers, refresh token, PII и payload целиком. Для входящих событий нужен контроль целостности: HMAC-подпись, timestamp, защита от replay и отдельная очередь на валидацию. Если интеграция принимает данные из внешней рекламной сети, считайте ее недоверенной по умолчанию.

Проверяйте, кто может создавать новые интеграции, менять callback URL и отключать алерты. Эти операции должны уходить в audit trail с уведомлением в SecOps или DevOps. Проверяйте логи, истина всегда скрыта в них. Если в архитектуре есть один универсальный ключ, у вас не интеграция, а единая точка отказа.