Запрос «курсовая по информационной безопасности в Бауманке» охватывает несколько реальных образовательных контекстов. В официальном каталоге МГТУ есть специалитет 10.05.01 «Компьютерная безопасность», 10.05.03 «Информационная безопасность автоматизированных систем», а также магистерское направление 10.04.01 «Информационная безопасность».
Поэтому в самой работе нужно использовать точное название своей программы и дисциплины, а не подменять его общей поисковой формулировкой.
Официальный каталог:
https://open.bmstu.ru/courses/
Начните с актива
Что защищаем?
Например:
- персональные данные;
- учётные записи;
- технологическую сеть;
- исходный код;
- ключи;
- сервер;
- модель;
- документ.
Без актива модель угроз превращается в список всего опасного в интернете.
Свойства безопасности
Определите:
- confidentiality;
- integrity;
- availability.
Для конкретного актива приоритеты различаются.
Например, для медицинской записи важна конфиденциальность, а для системы управления критична ещё и доступность.
Граница системы
Покажите:
- пользователь;
- клиент;
- сервер;
- БД;
- сеть;
- внешний сервис.
Граница доверия помогает понять, где нужна защита.
Data flow diagram
Для threat modeling удобно показывать потоки.
Отметьте:
- откуда данные приходят;
- где хранятся;
- где меняется доверенная зона.
Не начинайте со списка CVE.
Угроза и уязвимость
Угроза:
«злоумышленник получает доступ».
Уязвимость:
«endpoint не проверяет право пользователя».
Не используйте эти понятия как синонимы.
Модель нарушителя
Определите:
- внешний или внутренний;
- уровень доступа;
- знания;
- ресурсы;
- цель.
Не создавайте «всемогущего хакера», против которого невозможно проектировать меры.
STRIDE
Для программной системы можно использовать категории:
- spoofing;
- tampering;
- repudiation;
- information disclosure;
- denial of service;
- elevation of privilege.
Но STRIDE является инструментом, а не готовой моделью.
Применяйте к конкретным потокам.
Risk
Риск можно представить как сочетание вероятности и ущерба.
Если используете балльную шкалу, объясните:
- уровни;
- критерии;
- итоговый приоритет.
Не подгоняйте риск под желаемую меру.
Не смешивайте compliance и безопасность
Соответствие требованию не гарантирует отсутствие уязвимостей.
И наоборот, техническая мера может быть сильной, но не закрывать формальное обязательство.
Разделяйте задачи.
Аутентификация
Покажите:
- пароль;
- MFA, если нужен;
- сессию;
- восстановление.
Не храните пароль в открытом виде.
Хеширование пароля
Используйте специализированный password hashing с солью.
Не применяйте обычный быстрый SHA-256 как полный механизм хранения пароля.
Объясните почему.
Авторизация
Проверяйте право на каждый защищённый объект.
Классическая ошибка:
пользователь меняет ID в URL и получает чужую запись.
Создайте тест на этот сценарий.
RBAC
Для ролевой модели сделайте матрицу:
- действие;
- объект;
- роль.
Не ограничивайтесь тремя if в контроллере без схемы прав.
Principle of least privilege
Сервис должен иметь только необходимые права.
Если приложение только читает таблицу, ему не нужен DROP DATABASE.
Покажите это в конфигурации.
Secret management
Не храните:
- пароль;
- API key;
- private key
в репозитории.
Используйте переменные окружения, vault или другой механизм по масштабу проекта.
TLS
Шифрование канала защищает данные при передаче.
Но оно не заменяет проверку прав на сервере.
Не пишите «HTTPS решает безопасность».
Encryption at rest
Если данные чувствительные, можно рассмотреть шифрование хранения.
Но нужно решить:
- где ключ;
- кто имеет доступ;
- как восстанавливать.
Шифрование без управления ключом мало полезно.
