|
|
@@ -0,0 +1,98 @@
|
|
|
+# Сценарий интерактивной браузерной игры «Защитник доступа»
|
|
|
+## Тема: настройка механизма полномочного управления доступом на основе доклада.
|
|
|
+## Цель игры: успешно пройти все этапы настройки системы управления доступом, предотвратить утечки данных и получить статус «Эксперт по информационной безопасности».
|
|
|
+## Целевая аудитория: ИТ специалисты, администраторы, студенты профильных специальностей.
|
|
|
+## Формат: веб приложение с интерактивными элементами, имитирующими реальные инструменты администрирования.
|
|
|
+### Сцена 1. Анализ требований безопасности
|
|
|
+Элементы:
|
|
|
+• интерактивная карта сети компании с иконками ресурсов (БД клиентов, файловый сервер, корпоративное приложение, почта);
|
|
|
+• панель классификации данных с тремя уровнями: «Общедоступные», «Внутренние», «Конфиденциальные»;
|
|
|
+• список отделов: «ИТ администрация», «Отдел продаж», «Служба поддержки», «Бухгалтерия»;
|
|
|
+• всплывающие подсказки с описанием каждого ресурса и отдела.
|
|
|
+Действия:
|
|
|
+• перетаскивать иконки ресурсов на карту;
|
|
|
+• выбирать уровень конфиденциальности для каждого ресурса через выпадающий список;
|
|
|
+• указывать отделы, которым нужен доступ к ресурсу (чекбоксы);
|
|
|
+• нажимать кнопку «Проверить классификацию» для получения обратной связи.
|
|
|
+Условия перехода:
|
|
|
+• все 4 ресурса размещены на карте;
|
|
|
+• для каждого ресурса выбран уровень конфиденциальности;
|
|
|
+• минимум 2 ресурса отмечены как «Конфиденциальные»;
|
|
|
+• для каждого ресурса указаны целевые отделы (не менее 1);
|
|
|
+• система подтверждает корректность классификации (зелёная галочка).
|
|
|
+
|
|
|
+### Сцена 2. Создание модели ролей и групп пользователей
|
|
|
+Элементы:
|
|
|
+• конструктор ролей с полями: «Название роли», «Описание», «Разрешённые действия»;
|
|
|
+• дерево групп пользователей: IT_Admins, Sales, Support, Finance;
|
|
|
+• матрица доступа (таблица: ресурсы × роли) с чекбоксами для прав (чтение, запись, выполнение, полный доступ);
|
|
|
+• кнопка «Применить роли» для проверки логики.
|
|
|
+Действия:
|
|
|
+• создавать роли: «Администратор системы», «Менеджер по продажам», «Сотрудник поддержки», «Бухгалтер»;
|
|
|
+• заполнять описание и разрешённые действия для каждой роли;
|
|
|
+• добавлять пользователей в группы через drag and drop;
|
|
|
+• отмечать права в матрице доступа для каждой роли (например, «Менеджер» — чтение БД клиентов);
|
|
|
+• проверять конфликты прав (система подсвечивает избыточные привилегии красным).
|
|
|
+Условия перехода:
|
|
|
+• созданы все 4 роли с уникальными наборами прав;
|
|
|
+• каждая группа содержит не менее 2 пользователей;
|
|
|
+• в матрице доступа нет конфликтов (все роли имеют минимально необходимые права);
|
|
|
+• система выдаёт сообщение: «Модель ролей утверждена».
|
|
|
+
|
|
|
+### Сцена 3. Распределение прав доступа (Linux и Windows)
|
|
|
+Элементы:
|
|
|
+• эмулятор терминала Linux с командной строкой (подсказки по chmod, chown, setfacl);
|
|
|
+• графический интерфейс Windows: вкладка «Безопасность» свойств папки (список пользователей/групп, разрешения);
|
|
|
+• тестовые файлы и каталоги: /confidential_data, C:\Finance\Reports;
|
|
|
+• индикатор соблюдения принципа наименьших привилегий (зелёный/красный).
|
|
|
+Действия:
|
|
|
+• вводить команды терминала для настройки прав (например, chmod 750 /confidential_data);
|
|
|
+• назначать владельца и группу через chown root:sales_group /confidential_data;
|
|
|
+• настраивать разрешения в Windows: выбирать группу Sales → устанавливать «Чтение и выполнение»;
|
|
|
+• проверять доступность файлов для разных ролей (кнопка «Тест доступа»).
|
|
|
+Условия перехода:
|
|
|
+• права настроены для всех критических ресурсов в обеих ОС;
|
|
|
+• принцип наименьших привилегий соблюдён (роли не имеют лишних прав);
|
|
|
+• тест доступа пройден: нужные роли видят файлы, остальные — получают ошибку «Доступ запрещён»;
|
|
|
+• индикатор принципа наименьших привилегий — зелёный.
|
|
|
+
|
|
|
+### Сцена 4. Внедрение механизмов аутентификации и авторизации
|
|
|
+Элементы:
|
|
|
+• панель настройки PAM/LDAP (Linux): чекбоксы для модулей, поле ввода сервера LDAP;
|
|
|
+• интерфейс Active Directory (Windows): дерево доменов, список пользователей, вкладка «Политики безопасности»;
|
|
|
+• симулятор двухфакторной аутентификации: виртуальные YubiKey, SMS коды;
|
|
|
+• журнал попыток входа (пустой на старте).
|
|
|
+Действия:
|
|
|
+• активировать PAM в Linux, подключить сервер LDAP (ввести IP адрес);
|
|
|
+• настроить Active Directory: создать домен, добавить пользователей, включить групповую политику;
|
|
|
+• включить двухфакторную аутентификацию для роли «Администратор» (выбрать YubiKey);
|
|
|
+• симулировать вход пользователя: вводить логин/пароль → получать SMS код → вводить код.
|
|
|
+Условия перехода:
|
|
|
+• хотя бы один механизм аутентификации активирован для каждой ОС (PAM/LDAP для Linux, AD для Windows);
|
|
|
+• двухфакторная аутентификация включена для роли «Администратор»;
|
|
|
+• журнал попыток входа показывает успешный вход с двухфакторной проверкой;
|
|
|
+• система подтверждает: «Аутентификация настроена».
|
|
|
+
|
|
|
+### Сцена 5. Организация мониторинга и аудита
|
|
|
+Элементы:
|
|
|
+• дашборд с логами в реальном времени (события: вход, доступ к файлу, ошибка, подозрительное действие);
|
|
|
+• конструктор правил аудита: поля «Условие» (например, «3 неудачных входа подряд»), «Действие» (оповещение, блокировка);
|
|
|
+• отчёт по результатам аудита (таблица: ресурс, роль, нарушение, рекомендация);
|
|
|
+• кнопка «Запустить аудит» для симуляции проверки.
|
|
|
+Действия:
|
|
|
+• фильтровать логи по типам событий (кнопка «Показать только ошибки»);
|
|
|
+• создавать правила уведомлений: например, «При попытке доступа к /confidential_data извне — отправить email администратору»;
|
|
|
+• запускать симуляцию аудита (кнопка «Запустить аудит») → анализировать отчёт;
|
|
|
+• исправлять нарушения: перенастраивать права или правила аудита на основе рекомендаций отчёта.
|
|
|
+Условия завершения игры:
|
|
|
+• настроены правила мониторинга для критических событий (не менее 3 правил);
|
|
|
+• создано минимум 2 правила автоматических уведомлений;
|
|
|
+• отчёт аудита показывает отсутствие нарушений прав доступа;
|
|
|
+• игрок получает сертификат «Эксперт по полномочному управлению доступом» с уникальным ID;
|
|
|
+• открывается доступ к бонусному уровню «Реагирование на инцидент» (опционально).
|
|
|
+
|
|
|
+Технические примечания:
|
|
|
+• Для сцен 3 и 4 требуются стилизованные изображения интерфейсов Linux терминала и Windows проводника.
|
|
|
+• Дашборд в сцене 5 должен визуализировать логи в виде таблицы и графиков (количество событий по типам).
|
|
|
+• Все действия игрока логируются для последующего анализа (статистика правильных/неправильных решений).
|
|
|
+Если хотите, могу детализировать любую сцену, добавить игровые механики (очки, таймер) или адаптировать сценарий под конкретную платформу
|
