Этап 1. Организационный момент и мотивационный инцидент
80 мин: 5 минут / 60 мин: 3 минуты
Прямая речь преподавателя:
«Здравствуйте, коллеги! Прошу занять свои рабочие места и включить компьютеры. На прошлом занятии мы завершили этап 1: спроектировали экранную форму аутентификации и базовую структуру таблицы пользователей. Но ответьте честно: что произойдет, если злоумышленник запустит простейший Python-скрипт, отправляющий 500 запросов в секунду с перебором паролей из словаря "rockyou.txt"? Если у нас нет серверного лимита попыток, такой сервис "ляжет" или аккаунт администратора будет скомпрометирован за 10 минут. Сегодня на этапе 2 мы реализуем надежный эшелонированный протокол безопасности: криптографическую проверку хэша с солью, автоматическую блокировку аккаунта на 15 минут при трех неверных вводах (Brute-force protection) и ведение неизменяемого журнала безопасности Security Audit Log. Открываем рабочие материалы!»
Действия и реплики обучающихся:
Приветствуют преподавателя, проверяют запуск рабочих инструментов, готовят локальный комплект материалов по занятию 26. Включаются в осмысление инцидента безопасности: осознают, что проверка на клиенте легко обходится прямыми HTTP-запросами через Postman или curl.
Основной регламент (80 минут): 5 мин
Преподаватель успевает разобрать на слайде 2 статистику реальных взломов баз данных из отчета OWASP Top-10 (Identification and Authentication Failures).
Сокращенный регламент (60 минут): 3 мин
Лаконичная постановка цели без расширенной статистики, акцент на связывании формы и СУБД.
Этап 2. Актуализация опорных знаний и теоретический разбор алгоритма
80 мин: 15 минут / 60 мин: 12 минут
Прямая речь преподавателя:
«Вспомним базовое правило информационной безопасности: пароли никогда не хранятся в открытом виде. Почему? При любой утечке дампа базы данных злоумышленники мгновенно получат учетные данные всех клиентов. Но почему недостаточно просто захэшировать пароль через SHA-256? Кто ответит?»
Ответ студента (Иванов):
«Потому что одинаковые пароли дадут одинаковый хэш. Злоумышленники заранее сгенерировали радужные таблицы (Rainbow Tables) под все популярные пароли и смогут мгновенно найти соответствие!»
Прямая речь преподавателя:
«Абсолютно верно, Иванов! Именно поэтому мы добавляем к паролю индивидуальную криптографическую соль (Salt). Взгляните на экран (слайд 6–7). Алгоритм верификации пароля в процедуре СУБД состоит строго из пяти шагов:
1. Поиск учетной записи по логину: если пользователь не найден, мы обязаны вернуть нейтральное сообщение "Неверный логин или пароль", чтобы злоумышленник не понял, существует ли такой пользователь в системе (защита от User Enumeration).
2. Проверка тайм-аута блокировки: если поле locked_until > CURRENT_TIMESTAMP, мы не тратим ресурсы на проверку пароля, а сразу отклоняем запрос.
3. Проверка активности: если is_active = FALSE — аккаунт отключен.
4. Вычисление и сравнение соленого хэша: SHA256(введенный_пароль || salt).
5. Аудит и обработка: при успехе сбрасываем failed_attempts = 0 и locked_until = NULL. При ошибке инкрементируем failed_attempts + 1. Если достигнут порог 3 ошибки — ставим блокировку на 15 минут и пишем в журнал ACCOUNT_LOCKED.»
Этап 3. Демонстрация сквозного инженерного эталона на проекторе
80 мин: 10 минут / 60 мин: 8 минут
Прямая речь преподавателя:
«Внимание на проектор. Сейчас я на живом примере продемонстрирую реакцию базы данных. У нас создана таблица пользователей и таблица security_audit_log. Я ввожу верный логин operator_1, но трижды ошибаюсь в пароле.
Попытка 1: в логе появляется AUTH_FAILURE, счетчик failed_attempts равен 1.
Попытка 2: в логе второй AUTH_FAILURE, счетчик равен 2.
Попытка 3: срабатывает триггер безопасности! В таблице пользователей поле locked_until получает значение текущего времени плюс 15 минут, а в журнал безопасности записывается статус ACCOUNT_LOCKED.
Теперь, даже если на 4-й раз я введу абсолютно правильный пароль, СУБД отклонит вход, потому что учетная запись заблокирована! Обратите внимание: в журнал аудита мы фиксируем IP-адрес клиента и точное серверное время, но ни при каких обстоятельствах не записываем введенный пользователем сырой пароль!»
Вопрос студента (Петрова):
«А если через 15 минут пользователь вспомнит верный пароль и зайдет, блокировка снимется автоматически или нужен администратор?»
Прямая речь преподавателя:
«Отличный вопрос! Поскольку условие блокировки проверяет locked_until > CURRENT_TIMESTAMP, по истечении 15 минут текущее время станет больше сохраненной метки. Условие блокировки перестанет выполняться автоматически, и при вводе правильного пароля вход успешно произойдет, а счетчик неудач сбросится в ноль.»
Этап 4. Практический практикум студентов в zanyatie.html
80 мин: 40 минут / 60 мин: 30 минут
Прямая речь преподавателя:
«Приступаем к индивидуальной практической работе. Открываем файл zanyatie.html. Обязательно введите свои реальные ФИО и учебную группу в верхней панели. Распределение по 4 вариантам:
• 1-й ряд выполняет Вариант 1 (Складской учет): протокол проверки кладовщика, блокировка при 3 ошибках на 15 минут, запись в Security_Log.
• 2-й ряд выполняет Вариант 2 (Медицинская карта): аудит доступа к персональным данным, фиксация IP рабочей станции, запрет входа при is_active = FALSE.
• 3-й ряд выполняет Вариант 3 (Банковский терминал): проверка срока действия пароля password_expiry, требование обязательной смены пароля при первом входе.
• 4-й ряд выполняет Вариант 4 (Образовательная платформа): ролевое перенаправление: студент в ЛК, администратор в консоль управления, протоколирование сессий.
Все данные автоматически сохраняются в вашем браузере. Приступайте, я буду подходить для консультаций.»
Деятельность обучающихся:
Обучающиеся работают в интерактивном листе. Проектируют SQL-процедуру верификации, составляют структуру журнала аудита, описывают логику динамического изменения экранного интерфейса в зависимости от роли (скрытие админ-панели для непривилегированных пользователей).
Этап 5. Экспертный разбор типичных студенческих ошибок
80 мин: 5 минут / 60 мин: 4 минуты
Прямая речь преподавателя:
«Коллеги, остановитесь на минуту, разберем три критические ошибки, которые я уже заметил в решениях:
Ошибка 1: Сброс счетчика неудач до проверки пароля. Некоторые из вас написали UPDATE users SET failed_attempts = 0 прямо в начале процедуры входа! В этом случае счетчик никогда не превысит 1, и защита от перебора просто уничтожена.
Ошибка 2: Вывод на экран сообщения "Пользователь с таким логином не существует". Запомните: интерфейс должен отвечать "Неверный логин или пароль", чтобы злоумышленник не мог составить базу существующих логинов компании.
Ошибка 3: Запись в лог аудита введенного пароля. Если в журнал аудита попадает пароль, этот лог сам становится огромной уязвимостью. Логируем только логин, IP, статус и тип события!»
Этап 6. Итог занятия, рефлексия, оценивание и домашнее задание
80 мин: 5 минут / 60 мин: 3 минуты
Прямая речь преподавателя:
«Посмотрим на слайд 15 нашей презентации. Знаменитый комикс Randall Munroe о "Little Bobby Tables" напоминает: безопасность базы данных и ее интерфейсов — это вопрос профессионализма разработчика. Если вы халатно отнесетесь к входным данным, цена ошибки — уничтожение или компрометация всей корпоративной базы.
Сегодня все отлично поработали. Нажмите кнопку "Экспорт в PDF" в рабочем листе для фиксации ваших решений. Оценки выставляются в соответствии с 4-балльной рубрикой. Обратите внимание: файл domashnee_zadanie.html является резервным дистанционным заданием — выполняйте его только в случае пропуска пары по уважительной причине или по индивидуальному назначению преподавателя. Спасибо за работу, занятие окончено!»