Жизненный цикл данных

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

Результат урока — карта хранения security-lab и правила сохранения, восстановления и удаления. Это техническая модель учебного приложения; она не является заключением о выполнении правовых требований реального проекта.

Какие сведения нужны

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

Загруженное изображение имеет серверный ID, владельца и имя хранилища. Исходное filename мы не сохраняем. Даже небольшое сокращение ненужного состава упрощает защиту, журналирование и будущий перенос данных.

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

Карта хранения

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

Сведения	Основное место	Дополнительная копия
Заметки и пользователи	instance/data.sqlite3	Проверяемая копия базы
Изображения	instance/private_media	Копия файлов
Сессия	Подписанная cookie клиента	Возможная ранее скопированная строка
Наблюдение запроса	Выбранный журнал	Система хранения журналов

Таблица помогает увидеть ошибку: удаление строки uploads не обязательно удаляет файл. Аналогично очистка рабочего журнала не меняет уже сохранённый архив. Политика должна охватывать эти связи.

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

Согласованная копия

Файл SQLite может изменяться во время работы. Простое копирование одного файла в случайный момент не описывает согласованное состояние базы. Для этого SQLite предоставляет backup API.

import sqlite3

source = sqlite3.connect("file:instance/data.sqlite3?mode=ro", uri=True)
target = sqlite3.connect("backup-data.sqlite3")
try:
    source.backup(target)
finally:
    target.close()
    source.close()

Это самостоятельный фрагмент для будущего локального выполнения. Он копирует базу и не включает изображения или настройки. Поведение метода описано в документации sqlite3 backup.

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

Восстановление и права

Копия имеет значение, если её можно восстановить в отдельное место и проверить. Восстановление не должно сразу заменять действующую базу ради проверки «открывается ли файл». Сначала создаётся изолированное окружение.

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

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

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

Удаление и связанные объекты

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

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

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

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

Сроки и минимизация

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

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

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

Снимок и актуальное решение

После восстановления сравните не только число заметок, но и статус пользователей. Старый снимок может содержать active=1 для уже отключённого владельца. Это пример, когда данные прочитались технически правильно, а актуальное полномочие вернулось неправильно.

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

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

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