Базу заявок охраняют всерьез. Пароль, права доступа, отдельная учетная запись, журнал входов. А рядом с базой живут файлы и скрипты, которые читают ее целиком, и у них нет ни владельца, ни срока жизни, ни строки в реестре систем.
21 августа 2026 года мы посчитали такие места в собственном контуре. Ниже цифры этого замера и то, что мы по ним поменяли.
Периметр отвечает на вопрос «кто войдет», а нужен ответ «что где лежит»
Наберите в поиске «утечка персональных данных компании». На 21 августа 2026 года по региону Москва десять результатов из десяти разбирают одно и то же: инсайдер выносит базу, сотрудник щелкает по фишинговой ссылке, менеджер отправляет список не тому адресату. Виноват человек, вывод понятен, делать после прочтения нечего.
Проблема в том, что человек выносит данные оттуда, где они лежат. А лежат они шире, чем принято думать. Основная база это одно место из нескольких, и остальные места заводятся по ходу работы: под разовую задачу, под проверку доставки, под выгрузку для отчета. Каждое такое место создается за пять минут и потом живет годами.
Инвентарь мест отличается от периметра тем, что его можно проверить командой и получить число. Периметр подтверждается словами «у нас настроен доступ». Число спорить не дает.
Место в инвентаре это любая точка, где контакт человека читается глазами: строка в базе, поле в письме, файл на диске, вывод скрипта в консоль. Критерий грубый и потому рабочий. Он обходится без классификации систем и уровней защищенности, а требует одного: пройти по каталогам и посчитать.
Сколько стоит инцидент, мы здесь не считаем, для этого есть разбор штрафов за утечку персональных данных в 2026 году. Дальше речь про инвентарь: какие места находятся в рабочем контуре, если посчитать их честно.
Наш замер: 16 скриптов с доступом к заявкам, 1 из них в git
Мы взяли рабочий каталог инструментов, где лежат скрипты для развертывания и разовых операций. Искали вхождения имен полей заявки: идентификатор записи, телефон, почта. Затем сверили найденное со списком файлов под контролем версий. Обе команды отрабатывают за секунду, повторить их у себя можно прямо сейчас.
| Показатель каталога инструментов | Значение на 21.08.2026 |
|---|---|
| Скриптов, обращающихся к полям персональных данных | 16 |
| Из них под контролем версий | 1 |
| Вне контроля версий | 15 |
| Всего файлов в каталоге за 31 день | 78 |
| Из них в git | 8 |
78 файлов появились за месяц, с 20 июля по 20 августа 2026 года. В историю репозитория попали восемь. Остальные семьдесят живут только на диске: их никто не ревьюил, про них не спросят на приемке, и после ухода автора о них не узнает никто.
Пятнадцать скриптов из шестнадцати умеют читать контакты людей и при этом невидимы для любой проверки. Причина простая: они писались как временные. Временный статус означает, что правила на них не распространили, а удалить забыли.
Разовый скрипт, который выгружает все заявки целиком
Разберем один файл из этих пятнадцати. 28 строк, комментарий в первой строке: «выгрузка всех лидов в JSON, READ-ONLY». Написан под конкретную задачу с номером, отработал один раз, в репозиторий не попал.
Что он делает. Снимает лимит выборки, берет записи любого статуса, складывает идентификатор, дату, статус, заголовок, содержимое и все мета-поля целиком и печатает результат в стандартный вывод.
Пометка READ-ONLY здесь про базу, а не про данные. База после запуска остается нетронутой, все верно. Но прочитать все и напечатать в консоль это и есть механизм выноса: дальше вывод уходит в файл, в буфер обмена, в переписку с коллегой, в чат с нейросетью. Ни один из этих переходов нигде не фиксируется.
Слово «разовый» в названии задачи работает как разрешение обойти правила. Скрипт не проходит ревью, потому что временный. Не попадает в реестр, потому что временный. Не удаляется, потому что про него забыли на следующий день.
Владельца у файла тоже нет. Автор помнит о нем неделю, дальше скрипт растворяется в каталоге, и следующий разработчик находит там готовый инструмент выгрузки, которым удобно воспользоваться еще раз.
Одна команда добавления, и 45 контактов уезжают в историю репозитория
Вывод такого скрипта где-то оседает. У нас он осел в рабочей копии: файл выгрузки от 19 августа 2026 года, 51 349 байт. Внутри 45 заявок за период с 15 июля по 19 августа, поля с именем, почтой и контактом для связи.
Дальше мы проверили, закрыт ли файл от репозитория. Проверка 21 августа 2026 года: команда, которая показывает правило исключения, для этого пути ничего не вернула. В списке исключений правила под каталог с выгрузками нет. Короткий статус репозитория показывает каталог как неотслеживаемый.
Перевод на человеческий: одна привычная команда добавления всех изменений отправила бы 45 записей с контактами в историю репозитория навсегда. Дальше репозиторий уезжает к подрядчику, на сервер сборки, в зеркало у второго разработчика.
Обидная деталь: код в такой ситуации написан правильно. Скрипт читает и печатает, база под доступом, пароли на месте. Утечку создает файл, который забыли убрать, и отсутствие одной строки в списке исключений.
Течь оказалась в почте, а не в базе
В августе 2026 года мы разобрали три канала, куда попадают данные человека, оставившего заявку на сайте. Полная методика и результаты опубликованы в материале про персональные данные в ИИ-канале и проект приказа ФСТЭК.
| Канал | Что там лежало | Итог проверки |
|---|---|---|
| Письмо менеджеру | Имя, телефон, почта, компания и текст задачи в открытом виде | Течь была здесь |
| База сайта | 36 заявок на тот момент, хранение без заданного срока | Хранилище под доступом |
| Журналы ошибок | Идентификатор заявки и адрес получателя | Чисто |
Подозрение обычно падает на журналы. Журналы оказались чистыми. Открытые контакты жили в почтовом канале, куда никто не смотрел, потому что почта воспринимается как рабочий инструмент, а не как хранилище персональных данных.
Вторая цифра из этой таблицы важнее первой. На момент того разбора в базе было 36 заявок, на 19 августа 2026 года уже 45. Объем растет сам по себе, а срок хранения так и не задан. Каждая неделя добавляет записи, которые никто не собирался хранить и никто не собирается удалять.
Что делать: инвентарь мест, срок хранения, короткоживущие креды
Сначала список мест. По нашему замеру персональные данные лежат минимум в пяти точках помимо основной базы: разовые скрипты в каталоге инструментов, файлы выгрузок в рабочих копиях, письма-уведомления в ящиках сотрудников, сохраненные на диск письма от проверок доставки, копии репозитория у подрядчиков. Одно такое письмо мы нашли у себя: файл сохранили руками при проверке доставки, и он остался лежать среди скриптов.
-
Составьте инвентарь мест, а не список систем
Пройдите поиском по каталогам разработки и деплоя на имена полей: почта, телефон, идентификатор заявки. Сверьте найденное со списком файлов под контролем версий. Разница между двумя числами и есть ваша слепая зона.
-
Закройте рабочие копии от репозитория
Каталог с выгрузками добавляется в список исключений до того, как в нем появляется первый файл. Проверяется командой, которая показывает правило для конкретного пути: если она молчит, файл поедет в историю при первом же добавлении всех изменений.
-
Задайте срок хранения и точку удаления
У заявки в базе, у письма в ящике и у файла выгрузки срок разный, и его надо записать. Наш открытый пункт именно здесь: 45 записей лежат без заданного срока, и мы об этом пишем вслух.
-
Сделайте доступы короткоживущими
Пароль приложения под разовую загрузку файлов мы создали и удалили сразу после работы. Проверка 21 августа 2026 года показала: активных паролей приложений у пользователя нет. Ключ, выданный на один раз, живет один раз.
Порядок шагов важен. Инвентарь идет первым, потому что без него срок хранения задается для базы и не задается для четырех остальных мест. Дальше пригодится чек-лист аудита персональных данных: он про документы и проверку, а инвентарь дает ему фактуру. Если после инвентаря выяснится, что часть полей вообще не нужна в выгрузках, посмотрите методы обезличивания по 152-ФЗ: дешевле выгружать метку вместо контакта.
Теперь про границы этого текста. Мы не мерили механику мошенников: как собирают профиль по номеру телефона, что дает открытая разведка, как устроен пробив. Замеров нет, поэтому в статье этого нет. Мы не приводим долю утечек по причинам и проценты инцидентов по рынку: чужие цифры без первоисточника мы не публикуем. Все числа выше сняты с одного контура за один день и описывают его, а не отрасль.
Сколько стоит разобрать свой контур
Замер, который дал таблицу выше, занимает часы, а не недели. Поиск по каталогам и сверка с контролем версий делаются за один заход. Дольше идет разбор находок: по каждому файлу надо решить, нужен он, кому принадлежит и когда удаляется.
Находки после разбора обычно ложатся в три стопки: файлы под удаление сразу, скрипты под перенос в репозиторий с ревью и места, которым нужно правило хранения. Первая стопка закрывается в тот же день и сокращает число точек с контактами быстрее всего.
Мы работаем по ставке 2 500 ₽/ч, оплата по факту сделанного, без аванса. Инвентарь мест и правила для рабочих копий закрываются аудитом процессов и данных. Если после разбора нужны руки, чтобы держать правила живыми, это поддержка проекта: срок хранения, ротация ключей и чистка выгрузок работают только в режиме регулярной проверки.
Часы не пропадут в любом случае. Инвентарь мест нужен и для разговора с проверяющим, и для договора с подрядчиком, и для собственного спокойствия в день, когда кто-то наберет команду добавления всех изменений в каталоге с выгрузкой.
Посчитаем, сколько мест с персональными данными в вашем контуре
Поиск по каталогам разработки, сверка с контролем версий, список файлов и скриптов с доступом к контактам. На выходе таблица с числами и решение по каждой находке. Ставка 2 500 ₽/ч, оплата по факту, без аванса.
Пришлем свой чек-лист замера
Оставьте контакт: отправим команды, которыми мы считали скрипты и выгрузки у себя, и разберем ваши находки на созвоне. Дальше по ставке 2 500 ₽/ч, оплата по факту.
Где еще лежат персональные данные, кроме основной базы?
По нашему замеру от 21 августа 2026 года мест минимум пять: разовые скрипты в каталоге инструментов, файлы выгрузок в рабочих копиях, письма-уведомления в ящиках сотрудников, сохраненные на диск письма от проверок доставки и копии репозитория у подрядчиков. У нас в каталоге инструментов нашлось 16 скриптов с доступом к полям заявки, под контролем версий из них один.
Чем опасен скрипт, помеченный как READ-ONLY?
Пометка про базу, а не про данные. Скрипт из нашего примера снимает лимит выборки, берет записи любого статуса и печатает все поля в стандартный вывод. База после запуска цела, но содержимое уже вышло за ее пределы: дальше вывод уходит в файл, в переписку, в чат с нейросетью. Ни один из этих переходов не журналируется.
Как проверить, что выгрузка не уедет в репозиторий?
Спросите у git правило исключения для конкретного пути. Молчание в ответ означает, что файл не закрыт и попадет в историю при первом добавлении всех изменений. Мы так проверили каталог с выгрузкой 45 заявок: правила под него не было. Каталог для выгрузок закрывается в списке исключений до того, как в нем появится первый файл.
Какой срок хранения заявок задать?
Числа мы здесь не назовем, потому что у самих срок пока не задан: 45 записей лежат в базе бессрочно, и это наш открытый пункт. Правило, которое работает независимо от цифры: срок записан, точка удаления назначена, удаление проверяется. Бессрочное хранение растет само по себе, за месяц с небольшим у нас прибавилось девять заявок к прежним 36.
Почему течь оказалась в почте, а не в базе?
Базу охраняют осознанно: доступ, пароль, права. Почта воспринимается как рабочий инструмент, поэтому письмо с именем, телефоном, почтой и текстом задачи в открытом виде расходится по ящикам без всякого контроля. Журналы ошибок при той же проверке оказались чистыми, хотя подозрение падает обычно на них.
