Методическое руководство преподавателя

1. Паспорт учебного занятия и целеполагание

Вид занятия: Практическое занятие (лабораторно-практический практикум).

Длительность: 2 академических часа (основной регламент — 80 минут, сокращенный регламент — 60 минут).

Место в учебном плане: Занятие №26 логически развивает этап 1 практического занятия №9 (занятие 25). Если на этапе 1 студенты проектировали графический интерфейс формы входа и таблицы пользователей/ролей, то на этапе 2 осуществляется глубокая серверно-логическая связка клиентской формы с базой данных: обеспечение криптографической устойчивости, отражение атак перебора и разграничение полномочий.

Ключевые образовательные цели

• Обучающие: освоить архитектурный процесс интеграции формы входа с СУБД; изучить алгоритм соленого хэширования HMAC/SHA-256; реализовать логику блокировки аккаунта (атрибуты failed_attempts, locked_until); спроектировать структуру таблицы аудита безопасности Security_Audit_Log; настроить ролевое управление элементами экранного интерфейса на клиенте.
• Развивающие: развить критическое инженерное мышление при анализе векторов угроз (перебор паролей по словарю, инъекции, Race Condition при авторизации); сформировать навыки безопасной разработки (Secure by Design).
• Воспитательные: воспитать профессиональную этику разработчика ПО и ответственность за сохранение конфиденциальности в соответствии с законодательством РФ (ФЗ-152 «О персональных данных»).

2. Поминутный тайминг учебного занятия (80 и 60 минут)

Методический план предусматривает два регламента проведения с сохранением ключевых дидактических единиц:

3. Архитектура интеграции формы входа с реляционной БД

3.1. Схема сущностей безопасности (Users и Security_Audit_Log)

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

-- 1. Таблица учетных записей пользователей
CREATE TABLE app_users (
    user_id SERIAL PRIMARY KEY,
    login VARCHAR(50) NOT NULL UNIQUE,
    password_hash CHAR(64) NOT NULL,        -- SHA-256 хэш (hex-строка)
    salt CHAR(32) NOT NULL,                 -- Индивидуальная криптографическая соль (16 байт hex)
    role_id INT NOT NULL REFERENCES app_roles(role_id),
    is_active BOOLEAN NOT NULL DEFAULT TRUE,
    failed_attempts INT NOT NULL DEFAULT 0, -- Счетчик подряд идущих неудачных попыток
    locked_until TIMESTAMP NULL,             -- Время, до которого вход заблокирован
    password_expiry DATE NOT NULL,          -- Срок годности пароля
    must_change_password BOOLEAN NOT NULL DEFAULT FALSE,
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);

-- 2. Таблица журнала аудита событий безопасности
CREATE TABLE security_audit_log (
    log_id BIGSERIAL PRIMARY KEY,
    event_type VARCHAR(30) NOT NULL,        -- 'AUTH_SUCCESS', 'AUTH_FAILURE', 'ACCOUNT_LOCKED', 'PWD_CHANGE'
    user_id INT NULL REFERENCES app_users(user_id) ON DELETE SET NULL,
    attempted_login VARCHAR(50) NOT NULL,   -- Фиксируется введенный логин (даже если пользователя нет)
    ip_address VARCHAR(45) NOT NULL,        -- IPv4 или IPv6 клиента
    timestamp TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    status VARCHAR(20) NOT NULL,            -- 'SUCCESS', 'FAILED', 'BLOCKED'
    details TEXT NULL                       -- Дополнительная диагностическая информация
);
CREATE INDEX idx_security_log_lookup ON security_audit_log (attempted_login, timestamp DESC);

3.2. Алгоритм процедуры верификации пароля и защита от перебора (Brute-force)

Процедура верификации выполняет следующие обязательные шаги транзакционно:

1. Поиск пользователя: выборка по login = p_login. Если учетная запись не найдена, регистрируется событие AUTH_FAILURE с причиной «Пользователь не найден», при этом на клиенте выдается обобщенное сообщение: «Неверный логин или пароль» (предотвращение атак перечисления учетных записей — User Enumeration).
2. Проверка блокировки (locked_until): если locked_until IS NOT NULL AND locked_until > CURRENT_TIMESTAMP, вход отклоняется с фиксацией ACCOUNT_LOCKED, интерфейс сообщает время окончания блокировки.
3. Проверка активности (is_active): если is_active = FALSE, аккаунт деактивирован администратором — отказ в доступе.
4. Проверка хэша: вычисляется v_computed_hash = SHA256(p_password || salt).
5. При несовпадении хэшей:
   • Инкрементируется failed_attempts = failed_attempts + 1.
   • Если failed_attempts >= 3 (порог системы): устанавливается locked_until = CURRENT_TIMESTAMP + INTERVAL '15 minute', регистрируется событие ACCOUNT_LOCKED.
   • Иначе регистрируется AUTH_FAILURE.
6. При совпадении хэшей:
   • Сбрасывается счетчик: failed_attempts = 0, locked_until = NULL.
   • Регистрируется AUTH_SUCCESS в журнале аудита.
   • Возвращается токен/данные сессии и роль пользователя.

3.3. Динамическая настройка прав экранного интерфейса по ролевой модели (RBAC)

После возврата сервером успешного ответа и идентификатора роли клиентское приложение настраивает отображение элементов:

• Администратор (Role = 'ADMIN'): доступ ко всем управляющим модулям: справочники, редактирование записей, управление учетными записями, просмотр security_audit_log.
• Специалист / Оператор (Role = 'OPERATOR' / 'DOCTOR' / 'STOREKEEPER'): доступ к предметным рабочим формам ввода и поиска в рамках должностных обязанностей; системные кнопки администрирования скрыты (display: none или удалены из DOM).
• Пользователь / Студент (Role = 'USER' / 'STUDENT'): режим «только чтение» (Read-Only) своих данных и личный кабинет.

4. Типовые студенческие ошибки и методы их устранения

5. Педагогические приемы и критерии оценивания

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

• Метод «Адвокат дьявола» (Red Team / Blue Team): преподаватель предлагает студентам попытаться обойти собственный алгоритм проверки пароля (например, отправить 10 запросов подряд без задержки).
• Проблемная визуализация: демонстрация логов реальных атак перебора демонстрирует студентам прикладную ценность изучаемых механизмов.