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