Этап 1. Организационный момент и мотивация
80 мин: 5 минут (00:00–00:05) | 60 мин: 3 минуты (00:00–00:03)
Методическая цель: оперативная мобилизация учебной группы, проверка явки, погружение студентов в проблематику информационной безопасности прикладных баз данных и формулировка инженерной цели этапа 1.
Прямая речь преподавателя:
«Здравствуйте, коллеги! Прошу занять свои рабочие места и включить рабочие станции. Сегодня мы начинаем фундаментальный практический блок: Практическое занятие №9 "Проект БД и форма входа, этап 1".
Давайте сразу начнем с сурового факта из индустрии: более 80% всех катастрофических утечек корпоративных данных происходят не из-за изощренных математических атак на шифры, а из-за грубейших детских ошибок разработчиков на этапе проектирования таблиц пользователей и интерфейса авторизации.
Если разработчик сохранил пароль в открытом виде, если он забыл добавить случайную криптографическую соль, если диалоговое окно любезно подсказывает злоумышленнику: "Такой логин не существует" — система уже взломана до того, как в нее внесли первую реальную запись! Сегодня каждый из вас спроектирует архитектурно безупречную подсистему аутентификации и разработает защищенный макет формы входа под свою отраслевую предметную область. Открываем интерактивный лист zanyatie.html и приступаем к работе!»
Ожидаемые действия студентов:
Студенты приветствуют преподавателя, запускают среду СУБД, открывают браузер с локальным файлом zanyatie.html, заполняют вводные поля ФИО и группы, настраиваются на интенсивную инженерную работу.
Этап 2. Вводный инструктаж и актуализация опорных знаний
80 мин: 15 минут (00:05–00:20) | 60 мин: 10 минут (00:03–00:13)
Методическая цель: актуализировать теоретические знания по концепциям AAA (Идентификация, Аутентификация, Авторизация), криптографическому хэшированию с солью (SHA-256 + Salt, bcrypt), ролевой модели доступа (RBAC) и протоколированию аудита.
Прямая речь преподавателя:
«Внимание на проекционный экран. На слайде 3 представлена классическая триада информационной безопасности. Давайте проведем четкую границу, которую начинающие программисты часто путают.
Что такое идентификация? Это ответ на вопрос: "Кто ты?". Пользователь вводит логин или прикладывает пропуск. Система находит строку в базе данных.
Что такое аутентификация? Это ответ на вызов: "Докажи, что ты — это действительно ты!". Пользователь предъявляет секретный фактор — пароль, PIN-код или временный код из аутентификатора.
А что такое авторизация? Это проверка: "Что тебе разрешено делать в системе после успешного входа?". Например, кассир имеет право пробить чек, но не имеет права редактировать справочник цен в БД.
Вопрос к аудитории: почему категорически запрещено хранить пароли в таблице базы данных в виде открытого текста password VARCHAR(50)?»
Ответ студента (Смирнов А.):
«Если злоумышленник украдет дамп базы данных через SQL-инъекцию или получит доступ к резервной копии, он мгновенно увидит пароли всех пользователей, включая администраторов. Кроме того, сотрудники технической поддержки или сами администраторы БД не должны иметь доступ к личным паролям пользователей.»
Прямая речь преподавателя:
«Абсолютно верно! База данных никогда не должна знать исходный пароль. Мы храним только результат односторонней математической функции — хэш. Но возникает следующий вопрос: почему наивный хэш SHA256(password) тоже уязвим?»
Ответ студента (Кузнецова В.):
«Потому что функция детерминирована: одинаковый пароль всегда дает одинаковый хэш. Хакеры используют готовые гигантские базы данных — радужные таблицы (Rainbow Tables). Если у ста сотрудников пароль "Password123", хэши будут одинаковыми, и их моментально расшифруют по таблице соответствий!»
Прямая речь преподавателя:
«Блестящий ответ! Именно поэтому для каждого пользователя при регистрации генерируется персональная случайная криптографическая соль salt длиной не менее 16–32 байт. Мы хэшируем склейку: Hash(password + salt). Даже если пароли совпадут, из-за разной соли хэши в базе будут абсолютно уникальны, а радужные таблицы станут полностью бесполезными!
В промышленных системах мы используем адаптивные алгоритмы с настраиваемым фактором замедления — например, bcrypt или Argon2, которые защищают базу от подбора на мощных видеокартах GPU.
И третья обязательная таблица — audit_logs. Любая попытка входа, успешная или провальная, должна фиксироваться: дата и точное время, IP-адрес, введенный логин и тип события. Без аудита служба безопасности слепа!»
Этап 3. Демонстрация сквозного проектного эталона
80 мин: 12 минут (00:20–00:32) | 60 мин: 7 минут (00:13–00:20)
Методическая цель: продемонстрировать эталонную структуру реляционных таблиц безопасности и ключевые инженерные требования к элементам экранной формы Login Dialog.
Прямая речь преподавателя:
«Обратите внимание на структуру DDL-скрипта на экране. Показываю базовую эталонную модель:
1. Таблица roles: первичный ключ id, уникальное наименование role_name VARCHAR(50) NOT NULL UNIQUE, текстовое описание служебных полномочий role_description.
2. Таблица users: первичный ключ id BIGSERIAL, уникальный логин login VARCHAR(50) NOT NULL UNIQUE, криптографическая соль salt VARCHAR(64) NOT NULL, хэш пароля password_hash VARCHAR(128) NOT NULL, внешний ключ role_id INTEGER REFERENCES roles(id), флаг активности is_active BOOLEAN DEFAULT TRUE NOT NULL, счетчик ошибок failed_attempts SMALLINT DEFAULT 0 и дата создания created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW().
Заметьте: мы не используем каскадное удаление ON DELETE CASCADE для пользователей! Если сотрудник увольняется, мы ставим is_active = FALSE (Soft Delete). Иначе удаление пользователя разрушит всю историю заказов или финансовых документов в смежных таблицах системы!
Теперь по экранной форме входа (Login Dialog). Макет формы должен отвечать четырем обязательным критериям UX/Security:
Во-первых, поле пароля обязательно маскирует символы маркерами (type="password").
Во-вторых, кнопка входа должна переходить в состояние блокировки при клике во избежание повторной отправки.
В-третьих, при ошибке форма выдает нейтральное сообщение: "Неверный логин или пароль". Категорически запрещено писать: "Такого логина нет"! Это исключает атаку перечисления логинов (User Enumeration).
В-четвертых, форма должна учитывать специфику вашей предметной области!»
Этап 4. Практическая самостоятельная работа студентов
80 мин: 38 минут (00:32–01:10) | 60 мин: 32 минуты (00:20–00:52)
Методическая цель: выработка устойчивых профессиональных умений проектирования таблиц учетных записей, ролей и аудита в СУБД, а также проектирования интерфейсных диалогов авторизации с учетом отраслевой специфики.
Прямая речь преподавателя:
«Переходим к индивидуальному выполнению вариантов. У нас 4 предметные области:
— Вариант 1: Информационная система "Оптовый склад". Роли: Кладовщик, Менеджер, Бухгалтер, Администратор. В форме входа обязательно проектируется выпадающий список выбора филиала склада и скрытие символов пароля.
— Вариант 2: Медицинская система поликлиники. Роли: Врач, Регистратор, Главврач. Вход осуществляется по служебному табельному номеру и паролю, с последующим запросом второго фактора (2FA) для доступа к врачебной тайне.
— Вариант 3: Банковский терминал обслуживания. Роли: Оператор, Кредитный инспектор, Контролер. Форма входа оснащается виртуальной экранной цифровой клавиатурой со случайным перемешиванием кнопок для защиты от подглядывания.
— Вариант 4: Образовательный портал колледжа. Роли: Студент, Преподаватель, Куратор, Родитель. Проектируется диалог входа с защищенным сценарием восстановления забытого пароля.
В интерактивном листе заполняйте проектные блоки: DDL-спецификацию таблиц, макет формы и обоснование архитектурных решений. Не забывайте периодически нажимать кнопку "Сохранить прогресс", чтобы данные записались в локальное хранилище браузера. Я провожу индивидуальные консультации. Приступайте!»
Действия студентов:
Студенты переключаются на назначенный вариант, проектируют SQL-структуру таблиц учетных записей под специфику своей предметной области, прорабатывают макет диалогового окна формы входа, прописывают логику состояний интерфейса и формулируют обоснование защиты.
Индивидуальная консультация (фрагмент диалога с бригадой Варианта 2):
«Обратите внимание: для медицинской системы поликлиники табельный номер врача может содержать лидирующие нули (например, "00412"). Поэтому поле login должно быть строковым типом VARCHAR(20), а не целочисленным INTEGER! Для двухфакторной аутентификации в таблицу пользователей добавьте поле totp_secret VARCHAR(64) или признак is_2fa_enabled BOOLEAN. Отличная мысль, продолжайте проектирование!»
Этап 5. Защита проектных решений, подведение итогов и рефлексия
80 мин: 10 минут (01:10–01:20) | 60 мин: 8 минут (00:52–01:00)
Методическая цель: оценка уровня освоения компетенций, рефлексивный разбор типичных студенческих коллизий, выставление баллов в соответствии с критериальной рубрикой, фиксация перехода ко 2 этапу проекта.
Прямая речь преподавателя:
«Время вышло, коллеги! Давайте подведем итоги первого этапа создания проекта БД и формы входа.
По результатам экспресс-проверки подавляющее большинство успешно справилось с проектированием триады таблиц. В каждой работе присутствует криптографическая соль, поле хэша пароля достаточной размерности и справочник ролей.
Какие типичные ошибки я заметил во время обхода?
1. Некоторые студенты забыли добавить UNIQUE на поле login. Помните: если два пользователя смогут зарегистрироваться с одинаковым логином, СУБД вернет несколько записей при авторизации, и серверное приложение упадет с ошибкой множественного результата!
2. В некоторых макетах формы входа кнопки "Войти" не имели состояния Disabled. Если сервер отвечает с задержкой в 1 секунду, нетерпеливый пользователь нажмет кнопку 5 раз подряд, создав паразитные дублирующие запросы и перегрузив базу аудита.
Сегодня за занятие выставляются баллы по 4-балльной шкале:
— 2 балла за корректность схемы таблиц безопасности (users, roles, audit_logs);
— 1 балл за качество и отраслевую эргономику макета формы входа;
— 1 балл за аналитическое обоснование и блок самопроверки.
На следующем занятии (Этап 2) мы перейдем к программной реализации логики проверки паролей и навигации в зависимости от назначенной роли. Обязательно сохраните свои рабочие листы. Благодарю всех за продуктивную работу, занятие окончено!»
Ожидаемые действия студентов:
Студенты задают финальные вопросы, сверяют свои решения с эталонными требованиями, нажимают кнопку "Сохранить прогресс", фиксируют выставленные баллы и готовят рабочие места к завершению занятия.