База лежала в открытом доступе по ошибке SEO-специалиста и GPT

Собственник спросил осторожно: "У нас же не могли слить базу?" Повод был - месяцем раньше на одном из его сайтов мы уже находили открытый архив. Я проверил все сайты, до которых у него есть отношение. Результат: на соседнем сайте лежали две полные копии базы данных, доступные любому человеку в интернете, - самой старой было пять месяцев.

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

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

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

Именно так выглядели три находки на этом аудите.

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

Архив сайта на 876 мегабайт на копии другого сайта - со всеми файлами и базой внутри. Такой архив разворачивается в один клик где угодно: у того, кто его скачал, появляется полная рабочая копия чужого бизнеса.

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

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

Главная методическая ошибка в таких проверках - искать файлы на сервере и по факту находки объявлять утечку. Файл может лежать на диске и не отдаваться наружу, а может лежать в неожиданном месте и прекрасно скачиваться.

Поэтому порядок такой: сначала смотрю, что лежит на диске - архивы, копии базы, файлы с расширениями bak, old, save, остатки установщиков. Потом каждую находку пробую скачать из интернета, как это сделал бы посторонний: скачалось - значит утечка, не скачалось - значит просто мусор на сервере. И отдельно запрашиваю снаружи ходовые адреса вслепую, даже если на диске чисто: доступа к диску может не быть вовсе, а файл при этом отдаётся.

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

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

Это важный практический вывод, а не формальность. Если в базе есть персональные данные клиентов, невозможность доказать отсутствие утечки означает, что исходить придётся из худшего: считать данные скомпрометированными, менять ключи и пароли, оценивать обязанности по 152-ФЗ. Разница между "у нас была дыра" и "у нас была утечка" стоит дорого, и определяется она наличием логов, которых обычно нет.

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

Причина простая. На сайте работает не только тот, кто заказал аудит: есть SEO-подрядчик, прежние разработчики, иногда сам собственник. Той самой панелью управления базой, судя по датам, кто-то регулярно пользовался. Молча снести её - значит сломать чужой рабочий процесс, а объясняться будет заказчик.

Логика такая: находки, потом отчёт, потом решение владельца, и только потом правки - с бэкапом до изменения. Файлы, к слову, были открыты уже пять месяцев; час до ответа собственника ничего не менял.

Два документа. Технический разбор - что где лежит, каким запросом это проверяется, что предлагается сделать. И отчёт собственнику человеческим языком: что нашли, чем это грозит, как давно открыто, что делать в порядке важности и сколько это займёт (получилось около трёх часов работы).

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

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