Утечки ПДн Q1 2023: паттерны атак и чеклист быстрых мер

Первый квартал 2023 года по числу утечек персональных данных бьёт прошлогодние показатели. Роскомнадзор публично говорит о рекордных объёмах - сотни миллионов строк, десятки компаний. В публичном пространстве появляются базы из e-commerce, медицины, HR-платформ, логистики. Мы прошлись по тому, что стало публично известно за квартал, посмотрели на паттерны - и убедились, что картина удручающая, но предсказуемая.

Что сливают и откуда

Большая часть публичных утечек Q1 2023 - это не взломы через какую-то экзотическую цепочку атак. Это два-три хорошо знакомых вектора, которые используются снова и снова.

Незащищённые S3-бакеты и object storage. Паттерн старый как мир: облачное хранилище поднимается под проект, в настройках ACL выставляется публичный доступ «временно», потом про это забывают. Или bucket policy наследуется от предыдущего окружения с широкими правами. Индексаторы типа GrayhatWarfare и похожих сервисов обходят публичное адресное пространство непрерывно - и находят то, что плохо лежит. Среди публичных инцидентов Q1 несколько явно выглядят именно как случайно открытое хранилище, а не активная атака. Утечка произошла не потому что кто-то взломал - просто никто не проверял настройки с момента создания.

Слабая или отсутствующая аутентификация на API. Второй паттерн, который мы видим в публичных разборах: API-эндпоинты без нормальной авторизации. Не уязвимость в смысле CVE, а просто отсутствие проверки прав доступа. Типичная картина: мобильное приложение или партнёрская интеграция работает через API, в какой-то момент один из эндпоинтов оказывается без проверки токена - либо изначально так написали, либо при рефакторинге потеряли middleware. Поисковики по API (Shodan, FOFA и им подобные) такое находят, и дальше вопрос только в том, кто первый обнаружит.

Компрометация через подрядчика. Третий вектор, который чуть менее очевидный, но всё более распространённый: данные утекают не из основной системы, а из инфраструктуры подрядчика. Интегратор, маркетинговое агентство, служба поддержки на аутсорсе - у всех есть доступ к каким-то данным, и у всех своя, независимая инфраструктура. Контролировать её так же внимательно, как собственную - сложно. Но ответственность по 152-ФЗ с оператора ПДн это не снимает.

Что это означает для нас как команды

Мы разбираем публичные утечки не ради интереса к чужим бедам. Это рабочий материал - из него понятно, что именно проверять у клиентов. После GoAnywhere в январе и ESXiArgs в феврале сезон открытий продолжается. На фоне вступивших в силу в феврале оборотных штрафов по 152-ФЗ вопрос «у нас точно нет открытого бакета?» стал менее риторическим.

Мы прогнали по нескольким клиентским инфраструктурам быстрый чеклист - именно по тем векторам, которые реально эксплуатировались в Q1. Результаты неравномерные. Там где была последняя аудиторская проверка меньше полугода назад - в основном порядок. Там где дольше - находки есть почти в каждом случае.

Чеклист быстрых мер

Это не исчерпывающий аудит - это то, что можно проверить за день-два и закрыть за неделю, если нашли.

S3 и object storage:

• проверить bucket policy и ACL на всех бакетах - публичного доступа быть не должно нигде, кроме случаев, когда это явно задумано для CDN со статикой
• включить S3 server access logging или CloudTrail (если AWS) / аудит-логи для Selectel и Yandex Cloud - минимум на бакеты с ПДн
• проверить кто из IAM-пользователей и ролей имеет s3:GetObject на продакшн-бакеты - список часто оказывается шире чем нужно
• убедиться что dev-окружения не используют продакшн-бакеты или их копии без ограничений

API:

• пробежать по публичным API-эндпоинтам - есть ли аутентификация везде, не только на очевидных маршрутах
• проверить документацию и реальное поведение на расхождение: задокументированные эндпоинты иногда не то же самое что реально работающие
• убедиться что rate limiting стоит - без него перебор данных через легитимный API становится тривиальным
• логирование запросов к API с ПДн: нужно иметь возможность ответить на вопрос «кто и когда запрашивал данные пользователя X»

Подрядчики и интеграции:

• составить список подрядчиков с доступом к ПДн - иногда этот список удивляет заказчика
• проверить что у каждого есть подписанное DPA (соглашение об обработке данных) - без него это уже нарушение 152-ФЗ
• убедиться что доступ у подрядчика минимально необходимый: не к целой таблице, а к нужным полям; не ко всей среде, а к конкретному сервису

Общее:

• проверить уведомление в РКН о факте обработки ПДн - если компания добавила новые категории или новые системы после последнего уведомления, это надо актуализировать
• убедиться что есть хоть какой-то план действий при инциденте: кто звонит кому, в какой срок уведомляем РКН (72 часа по новым требованиям), кто готовит описание инцидента

Что мы видим в итоге

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

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

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