Действия при утечке и инциденте

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

Результат урока — план инцидента для security-lab и механизмы отзыва доступа. Все сценарии условные: курс не сообщает о произошедшей утечке ProfessorWeb и не выполняет изменения его аккаунтов.

Сначала определить объект

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

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

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

Отзыв сессий владельца

В нашей модели версия хранится в базе и сравнивается при каждом запросе. Повышение auth_version делает старый снимок cookie неподходящим.

cursor = db.execute(
    "UPDATE users SET auth_version = auth_version + 1 WHERE name = ?",
    (name,),
)
if cursor.rowcount != 1:
    raise ValueError("Неизвестный пользователь")
db.commit()

Это фрагмент локального административного действия, а не свободный HTTP-маршрут. Name передаётся параметром SQL. Сам факт знания имени не даёт браузеру право выполнить такую операцию.

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

.venv/bin/python -m flask --app app revoke alice

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

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

Смена пароля

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

db.execute(
    "UPDATE users SET password_hash = ?, auth_version = auth_version + 1 "
    "WHERE name = ?",
    (generate_password_hash(new_password, method="scrypt"), name),
)
db.commit()

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

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

Смена общего ключа

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

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

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

Принципы управления сроками и отзывом сессий описаны в OWASP Session Management. Наш auth_version является конкретным учебным механизмом для отзыва всех сессий одного пользователя.

Сохранить сведения для разбора

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

Журнал курса содержит route, status, requestId и длительность. Он может помочь связать наблюдение, но не восстановит каждое содержимое изменения. Не нужно утверждать, что отсутствие подробной строки означает отсутствие нежелательного действия.

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

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

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

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

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

Завершение и наблюдение

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

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

Что означает завершение

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

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

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

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