Утечки персональных данных в логах, админке и кабинете

Где данные выходят за пределы модели

Риск утечки редко связан только с самой моделью. Персональные данные почти всегда проходят через несколько слоев приложения: форму, API, очередь, логи, админку, экспорт, резервные копии. Если смотреть только на вызов LLM, легко пропустить место, где данные уже стали обычной частью продукта и начали жить своей отдельной жизнью.

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

Что попадает в кабинет, админку и логи

Проблема обычно не в абстрактных "данных пользователя", а в очень конкретных полях. В кабинетах и служебных системах остаются ФИО, телефон, email, адрес доставки или регистрации, номера заказов и договоров, текст запросов к модели, фрагменты ответов, session id, токены, комментарии операторов и полные payload при ошибках. По отдельности часть таких полей кажется безобидной. Вместе они уже дают понятный профиль человека.

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

С логами происходит то же самое. Запрос падает - сервис пишет body целиком. Модель возвращает ошибку - приложение сохраняет ответ целиком. Прокси добавляет заголовки, мониторинг складывает их в сыром виде. Если команда использует LLM-шлюз, это не убирает риск на стороне приложения. Даже при работе через RU LLM, где есть маскирование PII, AI-Law метки и аудит-трейлы, утечка может начаться раньше или позже шлюза - в middleware, журнале исключений, кабинете или экспорте.

Искать нужно не только секреты вроде токенов. Намного чаще всплывают обычные рабочие данные, которые никто не считал чувствительными. Именно они потом лежат в логах дольше всего.

Как найти точки утечки

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

Начните с простой схемы. Нарисуйте путь данных от формы или чата до последнего места хранения. Отметьте не только основную базу, но и error tracker, access log, BI-выгрузки, почтовые уведомления, архивы в объектном хранилище, чаты поддержки и тестовые стенды. Потом пройдите по всем местам, где человек может увидеть или скачать данные: карточка клиента, история запросов, поиск в админке, CSV-экспорт, дампы для разработчиков, резервные копии.

После этого выпишите поля, без которых задача все равно работает. Во многих сценариях системе нужен текст обращения и внутренний id, а ФИО, телефон, email, точный адрес и полный IP там лишние. Отдельно проверьте ошибки и поиск. В реальных инцидентах персональные данные часто всплывают не в бизнес-таблицах, а в stack trace, debug-сообщениях, индексах поиска и автодополнении, куда PII попадает без маскирования.

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

Есть и быстрый способ проверить себя. Возьмите одну тестовую запись с ПДн, проведите ее по полному сценарию, а потом попробуйте найти эти данные руками: в логах, в админке, в экспорте, в поиске, в мониторинге, в резервной копии. Такой тест быстро показывает реальное число копий. Если запись находится в пяти местах вместо двух, план работ уже понятен.

Простой сценарий из продакшена

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

Чат передает сообщение в backend, тот вызывает сервис статусов заказов, и один из внутренних запросов падает. У разработчика раньше был включен подробный режим логирования, чтобы быстрее ловить ошибки. Журнал сохраняет весь запрос целиком: телефон, номер заказа, текст сообщения, идентификатор пользователя, иногда еще и кусок ответа сервиса.

Сотрудник поддержки открывает админку и идет в журнал ошибки, потому что клиент ждет ответ. Он не ищет ПДн и не пытается собрать лишнюю информацию. Он просто хочет понять, почему сломалась проверка заказа. Но на экране уже есть данные, которые ему не нужны полностью.

Дальше начинается обычная цепочка. Саппорт копирует фрагмент лога в задачу для разработки. Разработчик выгружает похожие ошибки за день. Аналитик берет тот же файл для отчета по инцидентам. Файл остается в общей папке или почте без понятного срока удаления.

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

Проблема не в самой модели. Даже если команда держит обработку внутри РФ и аккуратно строит LLM-интеграцию, приложение может само вынести ПДн за пределы контролируемого контура. Логи, выгрузки и скриншоты из админки живут отдельно от основной базы. У них часто нет нормальной маскировки, узкого доступа и внятного срока хранения.

Через месяц сбой давно закрыт, клиент уже получил ответ, а телефон и номер заказа все еще лежат в архиве логов, в CSV для отчета и в комментарии к тикету. Никто не помнит, зачем их сохранили, кто скачал файл и когда его должны удалить. Для 152-ФЗ это плохой сценарий: данные остались там, где они больше не нужны.

Что чаще всего ломает контроль

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

Вторая частая причина - общий доступ к админке. Один логин на всю команду кажется удобным, пока не нужно понять, кто открыл карточку клиента, кто выгрузил список и кто поменял правила маскирования. Без ролей и журнала действий админка быстро превращается в место, где данные видят все, кому они не нужны.

Третья проблема совсем бытовая. Сотрудник делает скриншот из кабинета и отправляет его в рабочий чат, чтобы быстро спросить коллегу, почему не проходит заявка. На скриншоте остаются ФИО, телефон, email и иногда номер документа. Данные уже ушли в другой канал с другим кругом доступа и другим сроком хранения.

Отдельно стоит экспорт "на всякий случай". CSV выгружают перед релизом, для сверки или ручной проверки, а потом файл лежит на ноутбуке, в почте, мессенджере или общей папке. О нем вспоминают только после инцидента.

Хуже всего работают дубли. Один и тот же запрос попадает в журнал приложения, систему мониторинга, SIEM, тикеты поддержки и резервные копии. Если в одном месте данные скрыты, это не значит, что их скрыли везде. Для 152-ФЗ важен весь путь данных, а не только основная база.

Как сократить данные без потери работы

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

Если оператору нужно понять, чей это заказ, ему редко нужен полный номер телефона или вся почта. Обычно хватает маски вроде "+7 999 12-34" и "ivanov@...". Полное значение можно держать отдельно, под более узким доступом. То же самое касается текстов обращений. Во многих случаях вместо полного текста в логе достаточно ticket_id, user_id, request_id и короткой причины ошибки.

Разделение журналов тоже сильно снижает риск. В error log команде нужны стек, код ответа, request_id и время. В audit log нужен факт действия: кто вошел, что изменил, откуда пришел запрос, кто выгрузил данные. Когда все смешано в одном потоке, персональные данные быстро расползаются по алертам, дашбордам и чатам дежурных.

Неплохо работает и такой минимум:

• в интерфейсах показывать только маскированные контакты;
• в логах хранить идентификаторы и технический контекст вместо полного текста;
• перед отправкой событий в аналитику вырезать PII или заменять ее масками и хешами;
• держать полные данные только там, где без них действительно нельзя выполнить задачу.

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

Кто видит данные по пути

Персональные данные редко утекают только через модель. Чаще их читают люди и сервисы вокруг нее: поддержка, разработка, аналитика, подрядчики, мониторинг, резервные копии. Именно здесь контроль чаще всего и ломается.

Сотруднику поддержки обычно нужны номер заказа, время запроса, статус ответа и маскированные контакты. Полный текст переписки, паспортные данные или телефон целиком ему почти никогда не нужны. Если кабинет показывает все сразу, сотрудник получает доступ к тому, без чего спокойно обошелся бы.

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

Аналитику обычно нужны суммы, доли, частота ошибок, сегменты клиентов. На практике он нередко получает CSV из кабинета вместе с ФИО, телефонами и комментариями операторов. Так данные покидают прод и начинают жить на ноутбуках, в почте и общих папках.

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

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

Если вы используете LLM-шлюз, такой контроль лучше ставить до логов и админки, а не после инцидента. Например, в RU LLM встроены маскирование PII и аудит-трейлы, а логи и бэкапы хранятся в РФ. Но даже в такой схеме команде важно проверить, какие поля она сама отправляет в запрос, кто видит сырые данные в приложении и сколько эти данные живут в служебных системах.

Быстрая проверка перед релизом

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

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

Потом сделайте несколько простых проверок:

• откройте типовые экраны и сравните, какие поля видят обе роли;
• введите email и телефон в поиск и проверьте, кто вообще может искать по этим данным;
• спровоцируйте понятную ошибку и прочитайте запись в журнале целиком;
• скачайте экспорт, тестовый backup и дамп базы, если они доступны в контуре релиза;
• спросите у команды, кто отвечает за удаление старых журналов и как это проверяют.

На ошибках обычно всплывает самое неприятное. Разработчик видит stack trace и считает это технической деталью, но рядом могут лежать тело запроса, токен, номер телефона, адрес и фрагмент переписки. Если продукт использует LLM через шлюз, проверьте не только приложение, но и все вокруг вызова: API gateway, фоновые воркеры, очереди и обработчики ретраев.

Отдельно посмотрите на выгрузки. CSV для поддержки, ночной backup и дамп для отладки часто живут дольше самой записи в рабочей базе. Если в системе действует удаление ПДн через 30 дней, а резервные копии лежат полгода без маскирования, правило почти ничего не меняет.

Хороший финальный вопрос звучит очень просто: кто именно удаляет старые журналы и как команда это подтверждает. Ответ "кажется, retention настроен" здесь не подходит. Нужны срок хранения, место хранения, ответственный и способ выборочно проверить удаление на тестовых данных.

Что сделать в ближайшие две недели

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

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

Дальше уберите полные запросы и ответы из журналов по умолчанию. Для отладки обычно хватает ID запроса, времени, имени сервиса, кода ответа и короткой причины ошибки. Полный текст стоит включать только временно, по отдельной заявке и на короткий срок. Это простое изменение часто снимает большую часть риска уже в первый день.

Следующий шаг - маскирование PII и сроки жизни данных. Почта, телефон, ФИО, номер договора, адрес и свободный текст из форм не должны храниться в сыром виде там, где это не нужно. Для журналов нужен отдельный срок хранения, а не тот же, что и для бизнес-данных. В теме 152-ФЗ журналы и основную обработку лучше разбирать вместе, иначе дыры останутся именно в служебных системах.

На второй неделе проверьте доступ:

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

Если вы ведете LLM-трафик через RU LLM, имеет смысл отдельно проверить встроенные аудит-трейлы, AI-Law метки и маскирование PII, а потом сравнить это с тем, что происходит в ваших логах, очередях и админке. Переход через единый OpenAI-совместимый эндпоинт и хранение данных внутри РФ не отменяют базовую дисциплину на стороне приложения.

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