Интерактивный рабочий лист: Проект БД и форма входа, этап 2

ОП.08 Основы проектирования баз данных • Тема 4 (§2.2 с.7–8) • Практическое занятие №9 (Занятие 26)

ФИО обучающегося:

Учебная группа:

Выберите назначенный вариант практического кейса:

Вариант 1. Складской учет: защита формы входа кладовщика и учет ошибок

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

1.1. SQL DDL структуры таблиц пользователей склада и журнала Security_Log:

Опишите таблицы с полями failed_attempts, locked_until, salt, password_hash, а также структуру журнала аудита.

1.2. Процедура верификации с алгоритмом блокировки (3 ошибки → 15 минут):

Составьте тело процедуры/функции: проверка блокировки по времени, расчет хэша, инкремент счетчика при ошибке, блокировка на 15 мин и сброс счетчика при успехе.

1.3. Протокол аудита безопасности (формирование записи в Security_Log):

Приведите пример SQL-команд регистрации события неудачной попытки ввода (AUTH_FAILURE) и события блокировки учетной записи (ACCOUNT_LOCKED).

1.4. Контрольные вопросы по Варианту 1:

1) Почему при неверном пароле нельзя выводить оставшееся количество попыток непосредственно на экран входа?
2) Каким запросом администратор склада может досрочно разблокировать аккаунт кладовщика?

Вариант 2. Медицинская карта: строгий аудит доступа к ПДн и деактивация

Предметный сценарий: В медицинской информационной системе (МИС) врачи получают доступ к защищенным персональным данным пациентов (диагнозы, анализы). Требуется обеспечить точный аудит каждой сессии (timestamp с миллисекундами, IP рабочей станции кабинета, идентификатор врача) и немедленный запрет входа при увольнении или временном отстранении (is_active = FALSE).

2.1. Реляционная схема учетных записей медицинского персонала и журнала доступа:

Спроектируйте поля таблицы врачей (включая признак is_active, сертификат/хэш, специальность) и структуру журнала доступа к персональным данным.

2.2. Алгоритм проверки активности врача и авторизации сессии:

Опишите логику SQL-процедуры: отказ в аутентификации при is_active = FALSE со статусом ACCOUNT_DEACTIVATED, фиксация IP-адреса рабочего терминала и точного времени начала сессии.

2.3. Запрос выявления аномальной активности в нерабочее время:

Составьте SQL-запрос к журналу аудита, находящий все успешные и неуспешные попытки входа под учетными записями врачей в период с 22:00 до 06:00.

2.4. Контрольные вопросы по Варианту 2:

1) Каковы требования ФЗ-152 к логированию доступа к персональным данным врачебной тайны?
2) В чем опасность физического удаления учетной записи врача вместо мягкой деактивации (is_active = FALSE)?

Вариант 3. Банковский терминал: валидация оператора и срок годности пароля

Предметный сценарий: В банковском терминале самообслуживания и расчетно-кассовом модуле операторы имеют доступ к финансовым транзакциям. Стандарты финансовой безопасности требуют: 1) проверку срока действия пароля (password_expiry, не более 90 дней); 2) флаг принудительной смены пароля при первом входе (must_change_password); 3) терминальный журнал аудита.

3.1. Спецификация таблицы банковских операторов с политиками паролей:

Спроектируйте схему: operator_id, terminal_id, password_hash, salt, password_expiry, must_change_password, failed_attempts.

3.2. Логика проверки срока действия пароля и первого входа:

Составьте SQL-процедуру валидации: если пароль верен, но password_expiry < CURRENT_DATE или must_change_password = TRUE, возвращается статус PASSWORD_EXPIRED с перенаправлением на экран смены пароля без выдачи рабочего токена.

3.3. Процедура защищенной смены пароля в СУБД:

Опишите процедуру смены пароля: генерация новой соли, вычисление нового хэша, установка password_expiry = CURRENT_DATE + INTERVAL '90 day', must_change_password = FALSE и запись в аудит.

3.4. Контрольные вопросы по Варианту 3:

1) Почему при смене пароля необходимо генерировать новую соль, а не использовать старую?
2) Какие ограничения на сложность пароля должны проверяться перед записью нового хэша в базу данных?

Вариант 4. Образовательная платформа: ролевая маршрутизация и сессии

Предметный сценарий: В единой образовательной платформе института через единую форму входа авторизуются студенты, преподаватели и администраторы деканата. В зависимости от возвращенной роли (role_name) клиентское приложение выполняет динамическое переключение интерфейса: студента — в личный кабинет с оценками, администратора — в панель управления структурой института с фиксацией входа в журнале сессий.

4.1. Схема связей пользователей, ролей и журнала сессий платформы:

Спроектируйте таблицы platform_users, roles, user_sessions и security_audit_log со всеми внешними ключами и ограничениями.

4.2. SQL-процедура аутентификации с возвратом профиля и роли:

Разработайте процедуру, выполняющую проверку учетных данных и возвращающую user_id, role_name, full_name и статус блокировки.

4.3. Алгоритм клиентской динамической настройки интерфейса:

Опишите логику JavaScript/псевдокод: получение роли, сокрытие административных кнопок для студентов (скрытие меню деканата) и маршрутизация на соответствующий экран.

4.4. Контрольные вопросы по Варианту 4:

1) Почему одного только скрытия кнопок в клиентском интерфейсе недостаточно для обеспечения безопасности авторизации?
2) Как база данных должна повторно проверять права пользователя при выполнении любого запроса к данным?

Все данные сохранены в localStorage!