Первые подозрения: внутренний враг
Когда поступили первые жалобы, мы действовали по стандартному протоколу: проверили права доступа, подняли логи операций с базой данных. Все запросы к таблице с номерами телефонов были учтены — никто не выгружал её целиком. Мы настроили SIEM-систему на подозрительные паттерны: массовые выборки, необычное время суток. Ничего. Тогда я решил посмотреть сетевой трафик от серверов приложений к внешним ресурсам. И тут началось самое интересное.
Неожиданный след: внешние API
Оказалось, что при каждом звонке или SMS-верификации наши серверы отправляли запрос к API стороннего сервиса проверки номера — того самого, который используют операторы для валидации Caller ID. В документации было написано, что сервис проверяет только формат и доступность номера, но на деле он передавал данные обратно оператору, который затем «обогащал» их и продавал маркетинговым платформам. Мы не заметили этого раньше, потому что трафик был зашифрован, а в логах приложения он выглядел как обычный вызов функции проверки номера.
Важный момент: мы доверяли API, который не подписывал NDA и не гарантировал конфиденциальность. Никто не читал мелкий шрифт в лицензионном соглашении.
Техническая реконструкция
Мы написали скрипт на Python, который эмулировал регистрацию нового пользователя и перехватывал трафик через tcpdump. Выяснилось, что запрос к API содержал не только номер, но и дополнительные метаданные: IP адрес, User-Agent, даже hash пароля (к счастью, с солью). Эти данные уходили напрямую оператору, минуя наше согласие. Мы сравнили паттерны звонков: спам-звонки начинались ровно через 30–60 секунд после отправки запроса к API.
Сравнение методов утечки
| Метод | Источник утечки | Обнаружение | Сложность предотвращения |
|---|---|---|---|
| Внутренний сотрудник | База данных | Логи доступа, DLP | Средняя |
| Взлом веб-приложения | API эндпоинты | WAF, пентесты | Высокая |
| Утечка через оператора | Внешний API | Анализ трафика, аудит данных | Низкая (требует аудита партнёров) |
Практические советы: как не попасться
- Аудите все внешние интеграции — проверяйте, какие данные передаются на сторону, даже если это «безопасный» API.
- Мониторьте сетевой трафик — используйте tcpdump или Zeek для обнаружения подозрительных соединений.
- Тестируйте поведение сервисов — отправляйте тестовые данные и смотрите, всплывают ли они в спам-базах.
- Требуйте NDA и подписывайте Data Processing Agreement — юридически обяжите партнёра не использовать данные не по назначению.
Личное наблюдение автора: часто проблемы безопасности лежат на стыке технологий и бизнеса. Операторы продают данные легально, прикрываясь «необходимостью проверки». Наша ошибка в том, что мы не задали вопрос: «А что происходит с данными после проверки?»
Резюме
Мы не нашли крота в компании. Вместо этого обнаружили, что утечка происходит через доверенный, но юридически не защищённый канал API. После замены провайдера и внедрения собственной проверки номеров через open-source библиотеки спам прекратился. История научила нас одному: доверяй, но проверяй — особенно когда речь идёт о данных клиентов.
