Политика хранения данных: храните меньше данных и снижайте риски

Почему меньше данных = меньше рисков

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

Лишние данные увеличивают риск, потому что создают дополнительные места, которые нужно защищать, и больше шансов на ошибки. Это также увеличивает затраты: больше хранилища и бэкапов, больше проверок доступа, больше работы по обработке запросов на удаление и больше времени на расследование инцидентов.

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

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

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

«Навсегда» — не нейтральный выбор. Если что-то пойдёт не так, «навсегда» может означать годы экспозиции. Одна утечка может включать старые аккаунты, заброшенные фичи, устаревшие логи и забытые экспорты. Это также означает, что через годы вам придётся объяснять, зачем вы хранили данные, которые не были нужны.

Распространённый пример — отладочные логи. Быстро собранные приложения (включая прототипы, созданные ИИ) часто по ошибке логируют чувствительные детали: токены сброса пароля, полные ответы API или секреты в открытом виде. Если такие логи хранятся бесконечно, одна ошибка превращается в долгий и дорогой инцидент. Короче сроки хранения уменьшают радиус поражения.

Картируйте, что вы собираете и куда это попадает

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

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

• Данные клиентов (профили, реквизиты оплаты, тикеты поддержки)
• Данные сотрудников (зарплата, заметки о производительности, записи об устройствах)
• Данные поставщиков (контракты, счета, контакт-листы)
• Продуктовые данные (события использования, отчёты об ошибках, feature flags)
• Чувствительные элементы (пароли, документы удостоверяющие личность, медицинские или финансовые данные)

Далее запишите, откуда поступает каждый тип: формы регистрации и оплаты, письма в поддержку, серверные логи, загрузки файлов и сторонние инструменты (платежи, аналитика, email, CRM). Именно точки сбора — где обычно начинается случайный перерасход данных.

Затем отследите, где эти данные хранятся сегодня, а не там, где вы думаете. Включите очевидные системы (база приложения, хранилище данных, тикетная система) и неформальные (общие таблицы, сообщения в чате, личные почтовые ящики).

Наконец, отметьте «скрытые» хранилища, которые незаметно удлиняют сроки хранения:

• Бэкапы и снепшоты
• Экспорты аналитики или сырые дампы событий
• Инструменты логирования, сохраняющие payload запросов
• Вложения в почте, пересылаемые между командой
• Стейджинг/дев базы, скопированные из продакшена

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

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

Решите, что вам действительно нужно собирать

Хорошая политика хранения начинается раньше, чем хранение. Она начинается с момента сбора. Если вы никогда не собираете данные, вам не придётся их защищать, удалять или объяснять, почему они у вас есть.

Используйте простой тест: помогают ли эти данные предоставить услугу, выполнить юридическую обязанность или предотвратить мошенничество? Если честный ответ «может когда-то пригодится», считайте их опциональными, пока не получите доказательства обратного.

Отделяйте «обязательно» от «приятно иметь»

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

Спрашивайте о каждом поле: что сломается, если мы удалим его? Если ничего не ломается, это «приятно иметь». Если продукт не сможет работать без него (например, нельзя создать аккаунт без email), это «обязательно».

Практичный подход:

• Отмечайте каждое поле как Обязательное, Необязательное или Перестать собирать
• По умолчанию новые поля — Необязательные, повышайте статус только при реальной ценности
• Избегайте сбора высокорисковых данных «на всякий случай»
• Назначьте владельца для каждого поля (реальный человек или команда)

Связывайте каждый тип данных с одной понятной целью

Для каждого типа данных напишите назначение, понятное непрофессионалу:

• Email: «Отправлять коды входа и важные уведомления об аккаунте.»
• Адрес для выставления счета: «Рассчитать налог и выписать счёт.»
• Чаты поддержки: «Решать проблемы клиентов и улучшать справку.»

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

Решите, кому действительно нужен доступ

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

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

Будьте строги с полями, которые трудно защищать или сложно обосновать, например с номерами соцстраха. Если у вас нет юридического требования их собирать — не собирайте. Если вы всё же обязаны собирать высокорисковые данные, относитесь к ним как к особому случаю: дополнительные контролы и короткий срок хранения.

Сколько хранить? Простые правила, которые работают

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

Начните с дефолта, затем делайте исключения

Выберите стандартный период хранения для каждого типа данных, исходя из цели (поддержка, бухгалтерия, безопасность, закон). Стандарты не дадут «хранить вечно» стать молчаливым правилом.

Один практичный подход — задать хранение по категориям:

• Данные аккаунта (имя, email): хранить пока аккаунт активен, затем удалить или анонимизировать после льготного периода.
• Платежи и счета: хранить столько, сколько нужно для бухгалтерии и споров.
• Сообщения поддержки: хранить только пока они помогают решать проблемы и обучать команду.
• События безопасности: хранить достаточно долго для расследования, затем сводить в агрегаты.
• Продуктовая аналитика: агрегированные данные хранить дольше, чем сырые события.

Чувствительные данные обычно имеют самые короткие сроки. То же касается подробных логов. Логи часто содержат IP-адреса, токены или случайные секреты, особенно в быстро собранных продуктах. Храните подробные логи недолго (дни или недели), затем оставляйте только то, что нужно (счётчики, типы ошибок) дольше.

Разные сроки для активных и неактивных пользователей

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

Это заставляет определять, что хранится «на всякий случай». Если пользователь не пользуется продуктом, необходимость держать его подробные данные обычно быстро исчезает.

Что делать при запросе на удаление

Запрос на удаление не должен быть паническим. Определите заранее:

• Что вы удаляете (и что обязаны хранить по закону/бухгалтерии)
• Сколько времени занимает выполнение (например, в течение 30 дней)
• Как обрабатывать бэкапы (они истекают сами по себе или исключаются из восстановления)
• Какой доказательный след вы сохраняете (небольшая запись о том, что запрос обработан)

Если вы сможете изложить эти правила простым языком, их обычно можно реализовать без драмы — и без хранения данных дольше, чем нужно.

Составьте график хранения, которому можно следовать

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

Начните с простой таблицы, отвечающей на пять вопросов: какие данные, зачем они нужны, кто ответственный, как долго хранить и как удалять. Цель не в том, чтобы в первый день всё каталогизировать идеально, а в том, чтобы ничего не оставалось «на всякий случай».

«Владелец» — вот что отличает план от пожелания. Выберите реального человека или роль для каждой строки. Им не нужно удалять все вручную, но они должны замечать, когда что-то уходит в сторону (например, логи вдруг хранятся год).

Пишите правила хранения простыми словами и избегайте расплывчатых формулировок типа «по мере необходимости». Хорошие правила звучат как: «Удалить через 30 дней после закрытия аккаунта» или «Хранить 14 дней, если не открыт инцидент». Если вы не можете сказать это в одном предложении — вероятно, неясно.

Исключения будут — документируйте их заранее:

• Юридическая приостановка: приостанавливает удаление для конкретных аккаунтов или записей
• Расследование мошенничества или безопасности: хранить релевантные логи и события до закрытия дела
• Регуляторный запрос: хранить только то, что требуется, а не всё подряд

Для каждого исключения укажите, кто может его одобрить и как это фиксируется (даже простой тикет или письменная заметка). Так «временно» не превратится в «навсегда».

Пошагово: внедряем минимизацию данных и правила хранения

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

1) Обрезайте данные у источника

Начните с форм, потоков регистрации, оформления заказа, тикетов поддержки и «приятной» аналитики. Убирайте поля, которые не нужны для сервиса, предотвращения мошенничества или законной причины.

Если вы не можете назвать отчёт, фичу или юридическую причину, для которой нужно поле — перестаньте его собирать.

2) Уменьшайте копии и ужесточайте доступ

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

Если внешнему инструменту нужны данные, отправляйте минимально возможный набор (например, ID пользователя и уровень плана, а не полный профиль).

3) Автоматизируйте удаление, а не напоминания

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

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

4) Убедитесь, что удаление реально (включая бэкапы)

Удаление записи в приложении — не то же самое, что удаление везде. Уточните, как долго бэкапы, реплики и таблицы хранилища данных держат данные. Если бэкапы обязаны существовать, задайте короткое окно хранения и зафиксируйте, что значит «удалено» на практике (например: удалено из продакшена немедленно, исчезает из бэкапов в течение 30 дней).

5) Пересматривайте ежеквартально и исправляйте отклонения

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

Распространённые ошибки, которые держат риск высоким

Большинство проблем с данными не связаны с одним большим решением. Они возникают из мелких привычек, которые накапливаются, пока вы не сможете объяснить, что храните и зачем.

Одна ловушка — хранить логи навсегда «на потом». Логи помогают в отладке, но часто содержат email, IP, токены сброса и другие чувствительные фрагменты. Без срока хранения вчерашняя отладка превращается в утечку в следующем году.

Другой частый промах — «удалять» данные в приложении, в то время как копии живут в других местах. Люди удаляют запись из базы, но забывают про CSV на общем диске, вложение в почте или снепшот в бэкапе. Когда клиент просит удалить данные, частичное удаление недостаточно и подрывает доверие.

Сигналы, которые тихо повышают экспозицию

Следите за такими паттернами:

• Хранение «на всякий случай» без даты истечения или проверки
• Удаления происходят в одном месте, но не в экспортах, тикетах и бэкапах
• Секреты хранятся в открытом виде или в клиентском коде
• Инструменты по умолчанию копируют данные клиентов без ясной необходимости
• Нет явного владельца, поэтому никто не следит за исключениями

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

Быстрые проверки, которые можно сделать на этой неделе

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

Начните с того, что вы собираете. Выберите один ключевой поток (регистрация, оформление заказа, контактная форма) и проверьте каждое поле. Если вы не можете объяснить, зачем поле нужно в одном предложении — удалите его или сделайте необязательным.

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

Пять проверок, которые можно завершить за неделю:

• Для каждого поля напишите одно предложение с причиной и минимальным форматом (пример: год рождения, а не полная дата).
• Запишите сроки хранения для логов, загрузок и тикетов поддержки, даже грубо (пример: 30, 90, 365 дней).
• Проведите тест полного удаления для одного пользователя: база приложения, экспорты аналитики, файлы и переписки поддержки.
• Перечислите, где хранятся бэкапы и как долго они живут, включая старые снепшоты и машины разработчиков.
• Подтвердите, что чувствительные данные зашифрованы и доступ к ним ограничен небольшой группой.

Тест, который часто удивляет команды: попросите кого-то найти и удалить пользователя, который писал в поддержку год назад. Если ответ: «мы можем удалить в приложении, но не в тикетной системе или бэкапах», — у вас есть явная пробел для исправления.

Пример: сокращение сбора данных в небольшом продукте

Небольшой SaaS продавал простую подписку. При регистрации просили номер телефона, домашний адрес и дату рождения. Ничего из этого не было нужно для доставки продукта. Это появилось потому, что первая версия скопировала шаблон «полного профиля».

Через несколько месяцев поддержка просила скриншоты, когда что-то ломалось. Скриншоты часто включали имена, email и иногда платёжные данные. Команда экспортировала аналитику в таблицы «на потом» и хранила их годами с email в открытом виде.

Они решили, что это проблема риска, а не просто бумажной работы, и сделали три изменения:

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

Они также сократили хранение технических логов: логи приложения с «хранить навсегда» стали храниться 14 дней, а трассы ошибок с идентификаторами пользователей маскировали. Бэкапы тоже настроили: ежедневные бэкапы — 14 дней, ежемесячные — 3 месяца, более старые копии безопасно удалялись.

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

Следующие шаги: сокращайте хранение данных и закрепляйте это

Хорошая политика хранения — это не большой документ. Это несколько чётких решений, которым команда следует каждую неделю.

Начните с записи 10 самых важных типов данных, с которыми работает продукт (не всё, просто главное). Рядом с каждым поставьте срок хранения, который вы сможете обосновать. Затем выберите одну зону высокого риска для первоочередного исправления: логи аутентификации, загрузки файлов или общий почтовый ящик поддержки — частые виновники.

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

Если вы унаследовали кодовую базу, сгенерированную ИИ, и не уверены, что логируется или хранится, сфокусированный обзор кода и конфигураций быстро выявит основные риски (слишком подробные логи, открытые секреты и данные, скопированные не в те инструменты). Команды вроде FixMyMess (fixmymess.ai) делают такую диагностику и починку, когда прототип, созданный ИИ, нужно превратить в готовый к продакшен продукт: безопасное логирование, усиление безопасности и задачи удаления, которые действительно выполняются.