Что хранить в логах по закону и сколько времени

MAATRIX

Сразу оговорка: это обзорный материал о том, какие вопросы вообще возникают вокруг логов с правовой точки зрения, а не юридическая консультация и не инструкция «храните ровно столько-то дней». Точные требования зависят от вида деятельности, юрисдикции и типа данных — за конкретным ответом для вашего проекта нужно идти к юристу. Дальше — только чтобы вы понимали, о чём вообще спрашивать. Владелец обычного сайта или сервиса рано или поздно натыкается на логи с IP-адресами и действиями пользователей и задаётся вопросом: а можно ли их вообще хранить, и не нарушает ли это что-то. Вопрос на самом деле двойной — и в нём легко перепутать две разные темы, которые внешне похожи, а по сути противоположны.

Логи как персональные данные: что в них может подпадать под защиту

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

• IP-адрес клиента — во многих юрисдикциях (в том числе в практике применения GDPR в ЕС) рассматривается как персональные данные, поскольку при определённых условиях позволяет идентифицировать конкретного человека.
• Идентификатор пользователя, логин, email, номер телефона в логе действий — прямые персональные данные, если привязаны к конкретному аккаунту.
• User-Agent, cookie-идентификаторы, fingerprint браузера — в отдельности не всегда персональные данные, но в связке с другими полями лога (тот же IP, тот же аккаунт) могут стать частью идентифицирующего набора.
• Содержимое действий пользователя (что искал, что купил, какие страницы смотрел), если это привязано к личности, — уже не технический след, а данные о поведении, категория более чувствительная, чем просто факт визита.

Подробнее о том, что вообще считается персональными данными и как это соотносится с требованиями к месту хранения сервера, — в статье про 152-ФЗ и локализацию данных: там разобран список того, что закон относит к персональным данным, и почему даже простая форма с именем и телефоном уже подпадает под регулирование.

Если в ваших логах есть персональные данные, из этого практически следует несколько вещей, которые стоит проговорить именно с юристом применительно к вашему случаю:

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

Здесь принципиально важно не путать «мы должны это хранить какое-то время для защиты данных» с «мы обязаны хранить это конкретное количество месяцев по закону» — вторая формулировка относится уже к следующей теме.

Отдельная категория: обязательное хранение логов для определённых видов сервисов

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

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

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

Если вы не уверены, подпадает ли ваш проект под подобную категорию, — это ровно тот случай, где стоит один раз проконсультироваться с юристом и получить письменный ответ по вашей конкретной модели деятельности, а не полагаться на общие статьи в интернете (включая эту).

Практический совет для обычного владельца сайта: баланс, а не крайность

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

Для логов сервера эта цель почти всегда одна — диагностика и безопасность:

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

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

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

Дополнительно стоит разделять два уровня хранения:

• Сырые построчные логи с персональными данными (полный IP, идентификатор пользователя, детали запроса) — короткий срок, минимальный доступ, чёткая техническая цель.
• Агрегированная статистика (число запросов в минуту, количество ошибок, суммарный трафик без привязки к конкретному человеку) — можно хранить дольше, потому что она обычно уже не относится к персональным данным и не несёт того же риска.

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

Что реально стоит сделать на уровне обычного проекта

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

1. Выясните, подпадаете ли вы под специальные требования (оператор связи, информационный посредник и подобные категории) — если сомневаетесь, задайте этот вопрос юристу отдельно, конкретно и письменно.
2. Определите, какие поля в логах реально относятся к персональным данным — IP, идентификаторы пользователей, содержимое действий — и отделите их от чисто технических метрик.
3. Зафиксируйте цель хранения каждой категории логов — «для диагностики за последние N дней», «для разбора спорных ситуаций за последние M месяцев» — и держите срок хранения соразмерным этой цели.
4. Настройте техническую ротацию так, чтобы срок хранения не держался на честном слове, а обеспечивался автоматически — logrotate, journald, ретеншен в системе централизованного логирования.
5. Ограничьте доступ к логам тем, кому он реально нужен по работе, а не всей команде по умолчанию.
6. Пересматривайте политику раз в какое-то время — по мере роста проекта состав логов и целей их использования меняется, и то, что было оправдано на старте, может перестать быть таковым.

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

Частые вопросы