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

Практическое занятие №9: проект БД и форма входа, этап 1

Комплексное руководство по проведению практического занятия по дисциплине «ОП.08 Основы проектирования баз данных» для специальности СПО 09.02.07 «Информационные системы и программирование» (СИЭУиП).

Раздел программы Тема 4. Проектирование структур баз данных (§2.2 с.7–8)
Академические часы 2 академических часа (80 / 60 мин)
Форма работы Практическое занятие с ПК
Целевой артефакт Схема таблиц безопасности + макет диалога входа

1. Детальный тайминг занятия

Организация образовательного процесса рассчитана на два сценария: основной (полный двухчасовой регламент 80 минут) и сокращенный академический регламент (60 минут при сдвоенных или ускоренных парах).

1.1. Основной регламент (80 минут)

Этап Время Деятельность преподавателя Деятельность студентов
1. Оргмомент и мотивация 5 мин
(00:00–00:05)
Приветствует учебную группу, отмечает посещаемость в электронном журнале. Ставит проблемный вопрос: почему 80% утечек данных начинаются со скомпрометированного диалога входа или некорректно спроектированной таблицы учетных записей? Готовят рабочие места к работе, запускают рабочую среду СУБД (PostgreSQL / SQLite / MySQL) и браузер с интерактивным рабочим листом zanyatie.html.
2. Актуализация и вводный инструктаж 15 мин
(00:05–00:20)
Разбирает концептуальную архитектуру подсистемы информационной безопасности: таблицы Пользователи, Роли, Журнал_аудита. Объясняет разницу между аутентификацией (проверка подлинности: кто ты?) и авторизацией (проверка полномочий: что тебе разрешено?). Демонстрирует слайды 1–7. Анализируют сущности безопасности, задают вопросы по типам данных (почему password_hash требует VARCHAR(64) или CHAR(60), почему нельзя хранить пароли в открытом виде, зачем нужна уникальная криптографическая соль salt).
3. Демонстрация сквозного эталона 12 мин
(00:20–00:32)
В режиме живого кодирования (Live-coding) демонстрирует создание таблиц подсистемы аутентификации в СУБД и проработку макета экранной формы диалога Login Dialog (состояния контролов: фокус, валидация логина, скрытие символов пароля точками, блокировка при 3 неверных попытках, запись в журнал аудита). Фиксируют последовательность DDL-скриптов, требования к внешним ключам (FOREIGN KEY (role_id) REFERENCES roles(id)), флагу активности is_active и структуре макета диалогового окна.
4. Самостоятельная практическая работа 38 мин
(00:32–01:10)
Распределяет студентов по 4 предметным вариантам (Оптовый склад, Поликлиника, Банковский терминал, Образовательный портал). Оказывает индивидуальные консультации, контролирует чистоту связей между таблицами, формат хэшей, состав полей аудита и эргономику макета формы входа. Самостоятельно выполняют практические задания своего варианта в интерактивном листе: проектируют DDL-схемы таблиц учетных записей и ролей, создают макет формы входа с учетом отраслевых требований (филиалы, 2FA, экранная клавиатура, сброс пароля), сохраняют промежуточный прогресс в localStorage.
5. Защита решений, рефлексия и итоги 10 мин
(01:10–01:20)
Организует экспресс-защиту результатов: опрашивает студентов у доски/экрана по ключевым узлам безопасности (как устроена проверка соли, что происходит при деактивации пользователя через is_active = FALSE, какие события пишутся в журнал аудита). Подводит итоги этапа 1. Демонстрируют заполненные формы рабочего листа, отвечают на контрольные вопросы, формулируют выводы по защищенности спроектированного интерфейса, сохраняют итоговый документ.

1.2. Сокращенный регламент (60 минут)

Этап Время Деятельность преподавателя Деятельность студентов
1. Оргмомент 3 мин
(00:00–00:03)
Быстрая проверка присутствующих, мобилизация группы, формулировка цели занятия: разработка таблиц безопасности и макета Login-формы. Занимают рабочие места, загружают рабочий лист занятия.
2. Экспресс-инструктаж 10 мин
(00:03–00:13)
Концентрированно освещает базовую триаду таблиц (Пользователи, Роли, Журнал_аудита) и ключевые требования к экранной форме входа (слайды 3, 5, 8, 11). Воспринимают архитектурные ограничения, готовят структуру полей под свой вариант.
3. Лаконичный эталон 7 мин
(00:13–00:20)
Демонстрирует базовый SQL DDL скрипт и схему состояний диалогового окна. Сверяют типовой шаблон со своей предметной областью.
4. Самостоятельная работа 32 мин
(00:20–00:52)
Курирует процесс проектирования, уделяя первостепенное внимание правильному типажу полей (хэш, соль, булевы флаги, внешние ключи) и компоновке элементов диалога входа. Проектируют таблицы и макет формы в интерактивном листе, заполняют проектные поля.
5. Контроль и итог 8 мин
(00:52–01:00)
Выборочно проверяет решения, акцентирует внимание на недопустимости открытого хранения паролей и важности аудита. Выставляет оценки. Защищают выполненный проект, фиксируют домашнее задание.

2. Архитектура подсистемы безопасности и аутентификации

В рамках Практического занятия №9 (Этап 1) студенты закладывают фундамент безопасности корпоративной информационной системы. Ключевая концепция: полное разделение учетных данных доступа, системы ролевых полномочий (RBAC — Role-Based Access Control) и журнала событий информационной безопасности.

2.1. Реляционная схема подсистемы аутентификации

Триада таблиц безопасности:
  1. roles (Справочник ролей) — определяет функциональные категории пользователей.
  2. users (Учетные записи пользователей) — хранит идентификаторы доступа, криптографические соли, хэши паролей и статусы учетных записей.
  3. audit_logs (Журнал аудита безопасности) — фиксирует каждый факт успешного или неуспешного входа, изменения пароля, блокировки аккаунта.
-- 1. Справочник ролей пользователей (RBAC)
CREATE TABLE roles (
    id SERIAL PRIMARY KEY,
    role_name VARCHAR(50) NOT NULL UNIQUE,     -- 'admin', 'manager', 'cashier', 'doctor'
    role_description VARCHAR(255) NOT NULL,    -- Описание служебных обязанностей роли
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP NOT NULL
);

-- 2. Таблица пользователей информационной системы
CREATE TABLE users (
    id BIGSERIAL PRIMARY KEY,
    login VARCHAR(50) NOT NULL UNIQUE,          -- Уникальный логин / табельный номер / email
    salt VARCHAR(64) NOT NULL,                  -- Криптографическая соль (hex/base64, min 16-32 байт)
    password_hash VARCHAR(128) NOT NULL,        -- Хэш пароля: SHA-256 (64 hex) или bcrypt ($2b$12$... 60 char)
    role_id INTEGER NOT NULL,                   -- Ссылка на роль в системе
    is_active BOOLEAN DEFAULT TRUE NOT NULL,    -- Флаг активности (soft delete / блокировка)
    failed_attempts SMALLINT DEFAULT 0 NOT NULL,-- Счетчик подряд идущих неверных попыток
    locked_until TIMESTAMP WITH TIME ZONE,      -- Время временной блокировки после N ошибок
    created_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP NOT NULL,
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP NOT NULL,
    CONSTRAINT fk_users_role FOREIGN KEY (role_id) 
        REFERENCES roles(id) ON UPDATE CASCADE ON DELETE RESTRICT
);

-- 3. Журнал аудита событий безопасности
CREATE TABLE audit_logs (
    id BIGSERIAL PRIMARY KEY,
    user_id BIGINT,                             -- Ссылка на пользователя (NULL если пользователь не найден)
    attempted_login VARCHAR(50) NOT NULL,       -- Введенный логин (для расследования подбора)
    event_type VARCHAR(30) NOT NULL,            -- 'LOGIN_SUCCESS', 'LOGIN_FAILURE', 'PASSWORD_RESET', 'ACCOUNT_LOCKED'
    ip_address VARCHAR(45) NOT NULL,            -- IPv4 или IPv6 адрес клиента
    user_agent VARCHAR(255),                    -- Идентификатор клиентского ПО / браузера
    event_time TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP NOT NULL,
    details TEXT,                               -- Дополнительные параметры инцидента
    CONSTRAINT fk_audit_user FOREIGN KEY (user_id) 
        REFERENCES users(id) ON UPDATE CASCADE ON DELETE SET NULL
);

CREATE INDEX idx_users_login ON users(login);
CREATE INDEX idx_audit_event_time ON audit_logs(event_time);
CREATE INDEX idx_audit_user_id ON audit_logs(user_id);

2.2. Анализ атрибутов сущности «Пользователи»

Поле Тип данных Ограничения Назначение и инженерный смысл
id BIGSERIAL / INTEGER PRIMARY KEY Суррогатный первичный ключ. Исключает зависимость внутренних связей от изменений логина или паспортных данных.
login VARCHAR(50) NOT NULL, UNIQUE Уникальный публичный идентификатор субъекта. Индексируется B-Tree деревом для мгновенного поиска за $O(\log N)$.
salt VARCHAR(64) NOT NULL Индивидуальная псевдослучайная криптографическая соль (CSPRN-генератор). Защищает от атак по радужным таблицам (Rainbow tables) и коллизий одинаковых паролей у разных пользователей.
password_hash VARCHAR(128) NOT NULL Результат работы односторонней хэш-функции от склейки password + salt. В чистом виде пароль НИКОГДА не попадает на диск и в память БД!
role_id INTEGER NOT NULL, FK Связь с таблицей ролей. Реализует принцип наименьших привилегий (Principle of Least Privilege). Категорически запрещено жестко кодировать права строками внутри таблицы пользователя.
is_active BOOLEAN NOT NULL, DEFAULT TRUE Механизм мягкой блокировки (Soft Disable). При увольнении сотрудника запись не удаляется (чтобы не нарушать целостность аудита и финансовых документов), а переводится в FALSE.
created_at TIMESTAMP WITH TIME ZONE NOT NULL, DEFAULT NOW() Временная метка создания учетной записи для аудита жизненного цикла учетных данных.

3. Проектирование диалогового окна формы входа (Login Dialog)

Форма аутентификации — критический интерфейсный узел. Ее проектирование требует гармоничного сочетания защищенности (Security) и удобства пользователя (User Experience — UX).

3.1. Архитектурная анатомия диалога входа

Обязательные элементы интерфейса:
  • Поле ввода логина с автофокусом и понятным плейсхолдером (без вымышленных данных).
  • Поле ввода пароля с маскированием символов (type="password") и переключателем видимости («глазок»).
  • Кнопка отправки формы «Войти» (Submit action, срабатывание по клавише Enter).
  • Индикатор процесса выполнения запроса (Spinner / Disabled состояние кнопки во время отправки).
  • Контейнер вывода системных сообщений об ошибках нейтрального характера.
Требования безопасности на клиенте:
  • Отключение автозаполнения для чувствительных режимов (autocomplete="off" или autocomplete="current-password").
  • Защита от перебора: ограничение частоты кликов (Debounce / Throttling) на кнопке входа.
  • Нейтральные формулировки ошибок: вывод сообщения «Неверный логин или пароль» вместо «Пользователь не найден». Раскрытие наличия логина облегчает злоумышленнику атаку перечисления (User Enumeration).
  • Сброс поля ввода пароля после каждой неудачной попытки входа.

3.2. Состояния диалогового окна (State Machine)

Форма входа описывается конечным автоматом со следующими состояниями:

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

Типовая ошибка студента В чем заключается угроза / дефект Педагогический прием и контрмера
Хранение паролей в открытом виде (Plaintext) Поле password VARCHAR(50) хранит прямой текст. Любой разработчик, дамп базы, резервная копия или SQL-инъекция мгновенно компрометируют всех пользователей. Прием «Аудит утечки»: преподаватель демонстрирует команду SELECT * FROM users; и спрашивает студента: «Вы доверите этой системе свой личный банковский пароль?». Вводится строгое требование: только salt + password_hash.
Использование хэша без соли (MD5 / SHA-256 без salt) Одинаковые пароли («123456», «qwerty») дают одинаковый хэш. База моментально вскрывается по предварительно скомпилированным радужным таблицам (Rainbow tables). Прием «Эксперимент с близнецами»: преподаватель просит зарегистрировать двух пользователей с паролем «Password123». Если хэши в таблице идентичны — работа не принимается, пока в формулу не будет добавлена случайная соль.
Детализированные подсказки злоумышленнику Интерфейс сообщает: «Такой логин не зарегистрирован» либо «Пароль для пользователя ivan не верен». Разбор вектора атаки: объяснение концепции User Enumeration. Интерфейс должен выдавать единую нейтральную ошибку: «Неверный логин или пароль».
Каскадное удаление пользователей ON DELETE CASCADE При удалении роли удаляются все сотрудники, либо при увольнении сотрудника удаляется запись из базы, разрушая историю заказов, рецептов или финансовых проводок. Введение Soft Delete: объяснение роли атрибута is_active BOOLEAN. Учетные записи сотрудников никогда не удаляются физически — только деактивируются!
Отсутствие аудита попыток входа БД содержит только текущее состояние. Невозможно расследовать инцидент перебора паролей (Brute-force) или несанкционированный ночной доступ. Проектирование таблицы audit_logs: обязательное включение фиксации времени, IP-адреса и типа события (успех/неудача).