Основные подходы к защите информации
8-9 классы • Подготовка к олимпиаде по кибербезопасности
Контроль доступа — правила и механизмы, определяющие кто, к чему и как может получить доступ
❓ Вопрос: Почему недостаточно просто иметь логин и пароль для доступа к системе?
✅ Ответ: Логин и пароль только идентифицируют пользователя, но не определяют, к каким именно ресурсам он может получить доступ и какие операции может выполнять. Контроль доступа отвечает на вопрос “Что разрешено делать этому пользователю?” после того как он успешно вошел в систему. 🚀
📋 Последовательность процесса доступа:
🏷️ Идентификация (Identification)
🎯 Цель: Система понимает, с кем она имеет дело, но еще не доверяет этому заявлению.
💡 Примеры из жизни:
"Я — Иванов Алексей" (представление)
Номер паспорта (идентификатор)
Логин/username (электронный идентификатор)
🔐 Аутентификация (Authentication)
Подтверждение личности — пользователь доказывает, что он действительно тот, за кого себя выдает
💡 Примеры из жизни:
Предъявление паспорта (документ, удостоверяющий личность)
Подпись на документе (уникальная характеристика)
Отпечаток пальца (биометрика)
🚦 Авторизация (Authorization)
Определение прав доступа — система решает, что разрешено делать подтвержденному пользователю
💡 Примеры из жизни:
Пропуск в учительскую (учителям можно, ученикам — нет)
Доступ к журналу оценок (учитель может ставить оценки, ученик — только смотреть свои)
Права администратора в компьютерном классе
Угрозы на каждом этапе:
🏷️ Идентификация
Угрозы: подмена/кража идентификатора
Социальная инженерия ("Я из техподдержки, назовите ваш логин")
Кража базы логинов (утечка пользовательской базы)
Подбор логинов (admin, root, user123)
Спуфинг идентичности (подделка email, номера телефона)
Почему: Атака направлена на получение/подделку идентификатора, а не на преодоление проверки подлинности.
🔐 Аутентификация
Угрозы: обход проверки подлинности
Брутфорс/словарные атаки на пароли
Фишинг (кража учетных данных)
Кейлоггеры (перехват ввода)
Подделка биометрии (фото отпечатков, масок лица)
Перехват токенов/SMS (SIM-своппинг)
Уязвимости в алгоритмах хеширования
Почему: Цель - доказать систему, что атакующий - это легитимный пользователь.
🚦 Авторизация
Угрозы: получение прав сверх положенных
Повышение привилегий (privilege escalation)
Обход контроля доступа (access control bypass)
Уязвимости в RBAC/ABAC политиках
Недостатки в реализации моделей доступа
Использование избыточных прав
Почему: Атака происходит ПОСЛЕ успешной аутентификации, направлена на расширение прав.
Владелец ресурса сам решает, кому дать доступ
❓ Вопрос: Какая главная уязвимость DAC позволяет троянским программам наносить ущерб?
Ответ: Троянская программа выполняется с правами пользователя, который ее запустил. Если пользователь имеет широкие права доступа, троянец может получить доступ ко всем ресурсам, доступным этому пользователю, включая возможность изменения прав доступа к файлам.
❓ Задача: В Linux файл имеет права rw-r--r--. Может ли пользователь, не являющийся владельцем, изменить содержимое этого файла?
Ответ: Нет. Права rw-r--r-- означают:
Ответ: В военных системах требуется строгий централизованный контроль. DAC позволяет владельцам ресурсов самостоятельно принимать решения о доступе, что может привести к утечке секретной информации если владелец ошибется или будет скомпрометирован.
Система решает по строгим правилам, пользователи не влияют
Ответ: В DAC владелец ресурса самостоятельно решает, кому предоставить доступ. В MAC правила доступа устанавливаются централизованно системой безопасности, и даже владелец ресурса не может их изменить
❓ Задача: Сотрудник с уровнем доступа “Секретно” пытается прочитать документ с грифом “Совершенно секретно”. Разрешит ли это модель Белла-ЛаПадула?
Ответ: Нет. Принцип “no read up” запрещает субъекту читать объекты с более высоким уровнем секретности. Сотрудник с уровнем “Секретно” не может читать документы “Совершенно секретно”.
Ответ: Модель Белла-ЛаПадула запретит эту операцию по принципу “no write down”. Запись в объекты с более низким уровнем секретности запрещена для предотвращения утечки информации.
Ответ: SELinux использует метки безопасности (типы) для субъектов и объектов, а AppArmor использует пути к файлам. SELinux более строгий и сложный, AppArmor — проще в настройке но менее гибкий.
Ответ: SELinux обеспечивает более тонкий и строгий контроль, что критично для военных и государственных систем. AppArmor проще настраивать для конкретных приложений типа веб-серверов, где важнее удобство чем абсолютная безопасность.
Доступ определяется ролью, а не конкретным пользователем
Ответ: Проблема масштабируемости. В DAC при 1000 пользователей и 1000 ресурсов нужно управлять 1,000,000 разрешений. В RBAC определяются роли (10-50), и пользователям назначаются роли, что значительно сокращает администрирование.
ПОЛЬЗОВАТЕЛИ → РОЛИ → ПРАВА
U = {u₁, u₂, …, uₙ}
R = {r₁, r₂, …, rₘ}
P = {p₁, p₂, …, pₖ}
Пользователи: Иванов, Петров, Сидорова.
Роли: Учитель, Ученик, Администратор.
Права: Чтение_журнала, Запись_оценок, Управление_пользователями.
Постройте матрицу назначений
Ответ:
UA (User-Role):
Иванов → Учитель
Петров → Ученик
Сидорова → Администратор
PA (Permission-Role):
Учитель: Чтение_журнала, Запись_оценок
Ученик: Чтение_журнала
Администратор: Управление_пользователями
Ответ: “Взрыв ролей” — ситуация когда для учета всех исключений и особых случаев создается слишком много специализированных ролей. Например, вместо роли “Учитель” создаются роли “Учитель_математики”, “Учитель_физики_старшие_классы”, “Учитель_завуч” и т.д.
❓ Задача: В компании 100 сотрудников нужно разбить на роли. Каждый сотрудник имеет в среднем 5 уникальных комбинаций прав. Сколько ролей может потребоваться в худшем случае?
Ответ: В худшем случае — 500 ролей (каждому сотруднику своя роль), что полностью нивелирует преимущества RBAC. На практике стремятся к 5-15 ролям.
Доступ определяется динамически по атрибутам и контексту
Ответ: RBAC использует статические роли, а ABAC оценивает динамические атрибуты в момент запроса. ABAC учитывает контекст (время, местоположение, устройство), что позволяет принимать более гибкие решения.
Ответ:
# Пример политики ABAC
def authorize_access(user, resource, action, environment):
if (user.department == resource.department and
user.security_level >= resource.classification and
environment.time in ["09:00-18:00"] and
environment.location == "office" and
action == "read"):
return "PERMIT"
Ответ: Высокая вычислительная сложность оценки политик в реальном времени, особенно при большом количестве атрибутов и сложных логических условиях.
👤 PEP → 🧠 PDP → 📊 PIP → 📋 PAP │ │ │ │ Запрос → Решение → Атрибуты → Политики
Ответ: PDP не сможет получить актуальные значения атрибутов для принятия решения. В качественных реализациях предусматриваются механизмы fallback: кэширование, значения по умолчанию, или политика “запретить по умолчанию”
📊 Сравнительная таблица моделей
❓ Задача: Для каждого сценария выберите оптимальную модель доступа:
Персональный компьютер дома → DAC
Военная база данных → MAC
Корпоративная сеть банка → RBAC
Облачный сервис с сложными политиками → ABAC
Школьный компьютерный класс → RBAC/DAC
❓ Вопрос: Почему современные системы часто используют гибридные подходы?
Ответ: Потому что каждая модель имеет свои сильные стороны. Например: RBAC для базовой структуры прав, ABAC для сложных контекстных политик, MAC для критически важных компонентов
🧠 Олимпиадные задачи повышенной сложности
❓ Задача: Докажите что RBAC можно выразить через ABAC
Ответ: RBAC является частным случаем ABAC, где используются только два атрибута: роль пользователя и разрешения роли.
Политика ABAC будет выглядеть как: user.role ∈ resource.allowed_roles
❓ Задача: Предложите модель доступа для системы умного дома где доступ к устройствам зависит от времени суцок, присутствия людей и их возраста
Ответ: ABAC с атрибутами: user.age, user.family_role, environment.time_of_day, environment.presence_of_children, device.danger_level.
Например: доступ к плите разрешен только взрослым, когда дети дома
❓ Задача: Объясните как модель Белла-ЛаПадула предотвращает утечку информации через “троянского коня”
Ответ: Модель Белла-ЛаПадула обеспечивает ограниченную защиту через принцип “no write down”, но имеет критическую уязвимость через разрешенный “write up”.
Защита: Троян не может напрямую записать данные в объекты с низким уровнем секретности (“no write down”).
Уязвимость: Троян может записывать данные в объекты с более высоким уровнем секретности (“write up” разрешен), откуда они могут быть извлечены другим трояном или через косвенные каналы.
Полная защита требует дополнительных мер: аудит операций “write up”, мониторинг аномальной активности, комбинация с моделями целостности (Биба).
🎯 Ключевые выводы для олимпиады Что нужно уметь:
Различать модели по принципам работы и управления
Применять модели к конкретным сценариям
Анализировать компромиссы между безопасностью и удобством
Предсказывать проблемы каждой модели в различных условиях
Ответ: ABAC и гибридные модели, так как рост IoT, облачных технологий и удаленной работы требует учета контекста, который статические модели не могут обеспечить. Однако RBAC останется для базовой структуры прав в организациях
🏆 Теперь вы точно готовы к олимпиаде!