Политика уничтожения данных

Документ: data_destruction_policy.md
Версия: 1.0
Оператор: ИП Кудрявцев Степан Александрович
ОГРН: 324784700000012 | ИНН: 780252833730
Юридический адрес: Россия, Санкт-Петербург
Контакт по вопросам защиты данных: [DATA_PROTECTION_EMAIL]

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

---

1. Назначение и область применения

1.1. Назначение документа

Настоящая Политика уничтожения данных и очистки сессий (далее — «Политика») определяет порядок, сроки, методы и верификацию уничтожения данных, обрабатываемых Платформой Anon (далее — «Платформа»), а также механизмы криптографического уничтожения (crypto erasure), применяемые для обеспечения невозможности восстановления уничтоженных данных.

1.2. Правовое основание

Политика разработана в соответствии с требованиями:

• Федерального закона от 27.07.2006 № 152-ФЗ «О персональных данных», ст. 21 (обязанность оператора по уничтожению ПДн);
• Постановления Правительства РФ от 01.11.2012 № 1119;
• Приказа ФСТЭК России от 18.02.2013 № 21;
• ГОСТ Р ИСО/МЭК 27001-2021.

1.3. Область применения

Политика распространяется на все категории данных, обрабатываемых Платформой:

• Исходные документы, загруженные пользователями;
• Анонимизированные документы (результаты обработки);
• Токен-маппинги (соответствия исходных данных и токенов);
• Временные файлы OCR-обработки;
• Данные кэша (Redis);
• Метаданные сессий.

---

2. Модель хранения: сессионная архитектура

2.1. Принцип «данные по дизайну не хранятся»

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

2.2. Тарифы хранения сессий

2.3. Отсчёт срока хранения

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

---

3. Криптографическое уничтожение (Crypto Erasure)

3.1. Принцип

Токен-маппинги шифруются алгоритмом AES-256-GCM с уникальным ключом шифрования (Data Encryption Key, DEK) для каждой сессии. Уничтожение ключа шифрования делает зашифрованные данные нечитаемыми без необходимости физического удаления шифртекста.

3.2. Механизм

[Создание сессии]
        |
        | Генерация DEK (AES-256, 256 бит, CSPRNG)
        | Генерация уникального nonce (96 бит)
        v
[Обработка документа]
        |
        | Токен-маппинг шифруется: AES-256-GCM(DEK, nonce, plaintext)
        | Шифртекст + тег аутентификации сохраняются в БД
        | DEK хранится в Redis с TTL = срок сессии
        v
[Истечение сессии / запрос на уничтожение]
        |
        | 1. DEK удаляется из Redis (UNLINK, затем перезапись нулями)
        | 2. Шифртекст остаётся в БД временно (до очистки Celery-задачей)
        | 3. Шифртекст удаляется из БД в рамках плановой очистки
        v
[Данные уничтожены]

3.3. Верификация уничтожения

Платформа может подтвердить факт уничтожения данных сессии:

3.3.1. Запрос на верификацию направляется пользователем через API (GET /api/v1/sessions/{session_id}/destruction-status) или через веб-интерфейс (раздел «Мои сессии»).

3.3.2. Ответ системы содержит:

{
  "session_id": "...",
  "status": "destroyed",
  "dek_destroyed_at": "2026-03-19T18:23:07.841Z",
  "ciphertext_purged_at": "2026-03-19T20:00:00.000Z",
  "temp_files_purged_at": "2026-03-19T18:23:07.900Z",
  "verification": "Ключ шифрования уничтожен. Восстановление данных невозможно."
}

3.3.3. Факт уничтожения подтверждается отсутствием ключа DEK: попытка доступа к данным сессии после уничтожения возвращает ошибку 410 Gone с указанием времени уничтожения.

---

4. Очистка компонентов инфраструктуры

4.1. База данных (PostgreSQL)

4.1.1. Плановая очистка

Celery Beat задача SessionCleanupTask выполняется каждые 15 минут (интервал настраивается Оператором) и:

1. Выбирает сессии с истёкшим сроком хранения (expires_at < NOW());
2. Удаляет записи из таблиц: anon_jobs, file_items, token_mappings (каскадно);
3. Фиксирует факт удаления в журнале уничтожения данных (data_destruction_log).

4.1.2. Журнал уничтожения

Каждый факт уничтожения данных фиксируется в таблице data_destruction_log:

Важно: Журнал уничтожения содержит только метаданные об операции, но не содержит уничтоженного содержимого.

4.2. Кэш Redis

4.2.1. Ключи шифрования сессий (DEK) хранятся в Redis db 2 с установленным TTL, равным сроку хранения сессии.

4.2.2. По истечении TTL Redis автоматически удаляет ключ (eviction policy: volatile-ttl).

4.2.3. Дополнительная Celery-задача RedisKeyCleanupTask выполняется каждые 60 минут (интервал настраивается Оператором) и проверяет наличие ключей, соответствующих истёкшим сессиям, удаляя их принудительно (защита от сбоев TTL).

4.2.4. Redis настроен с maxmemory-policy = allkeys-lru как дополнительная страховка: при исчерпании памяти наименее востребованные ключи удаляются автоматически.

4.3. Временные файлы

4.3.1. При загрузке документов создаются временные файлы:

4.3.2. Celery-задача TempFileCleanupTask выполняется каждые 10 минут (интервал настраивается Оператором) и удаляет все файлы старше установленного лимита.

4.3.3. Временные файлы создаются с правами 0600 (чтение/запись только владельцу процесса) и размещаются в директории с правами 0700.

4.3.4. При завершении обработки каждого документа (как успешном, так и по ошибке) выполняется немедленная очистка связанных временных файлов в блоке finally.

4.4. Файлы результатов

Анонимизированные документы (результаты обработки) хранятся:

• В объектном хранилище или на файловой системе сервера;
• Привязаны к сессии;
• Удаляются при очистке сессии (задача SessionCleanupTask);
• Не включаются в резервные копии.

---

5. Инициированное пользователем уничтожение

5.1. Немедленное уничтожение через веб-интерфейс

Пользователь может в любое время инициировать немедленное уничтожение данных текущей сессии:

• В веб-интерфейсе: кнопка «Уничтожить данные сессии» (с подтверждением);
• Через API: DELETE /api/v1/sessions/{session_id};
• В Telegram-боте: команда /destroy.

5.2. Необратимость

Уничтожение данных является необратимым. Пользователь предупреждается об этом перед подтверждением. После уничтожения:

• Восстановление данных невозможно;
• Деанонимизация невозможна (ключ DEK уничтожен);
• Повторное скачивание результатов невозможно.

5.3. Уничтожение учётной записи

При запросе пользователя на удаление учётной записи:

1. Все активные сессии немедленно уничтожаются (включая DEK);
2. Учётные данные (email, хэш пароля, профиль) удаляются из основной БД;
3. Записи в журнале уничтожения и журнале согласий сохраняются (псевдонимизируются) в соответствии с требованиями законодательства;
4. Подтверждение удаления направляется на email пользователя.

---

6. Отсутствие резервного копирования сессионных данных

6.1. Принцип

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

• Невозможность восстановления данных после уничтожения;
• Соответствие заявленным срокам хранения;
• Отсутствие «теневых копий» уничтоженных данных.

6.2. Что резервируется

Резервному копированию подлежат:

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

---

7. Аудит и контроль

7.1. Мониторинг очистки

Платформа осуществляет непрерывный мониторинг процессов очистки:

• Prometheus-метрики: anon_sessions_expired_total, anon_sessions_cleaned_total, anon_temp_files_cleaned_total;
• Алерт: срабатывает при обнаружении сессий, существующих более 2x установленного срока хранения (аномалия);
• Алерт: срабатывает при объёме временных файлов более 1 ГБ.

7.2. Ежемесячный аудит

Не реже одного раза в месяц проводится проверка:

• Количество сессий с истёкшим сроком хранения (должно быть 0);
• Количество DEK в Redis для истёкших сессий (должно быть 0);
• Объём временных файлов старше 1 часа (должен быть 0);
• Соответствие записей в data_destruction_log фактическому удалению.

---

8. Изменение Политики

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

---

Настраиваемые параметры

Следующие параметры настраиваются Оператором в Панели управления Платформы. Указанные ниже значения являются значениями по умолчанию.

Все параметры настраиваются в: Панель управления → Настройки → Сроки хранения

---

ИП Кудрявцев Степан Александрович | lexaris.ru | [DATA_PROTECTION_EMAIL]
Версия 1.0 | 2026-03-19