“Существующие модели безопасности, такие как Bell–LaPadula или Biba, описывают отдельные аспекты — конфиденциальность или целостность. Их можно совмещать, но это сложный ручной процесс, похожий на сборку гибридного двигателя из деталей разных машин. Нужна единая вычислительная модель, которая позволяет задавать любые политики безопасности — от банковских до военных — одним формальным языком и автоматически проверять их на противоречия. Это не просто математическая абстракция, а основа для реальных систем аттестации.”
Почему отдельных моделей уже недостаточно
Современные информационные системы редко защищают что-то одно. Государственная база данных должна одновременно предотвращать утечку секретных сведений и гарантировать, что учётные записи чиновников не будут скомпрометированы для внесения изменений. Финансовая платформа обязана обеспечивать и конфиденциальность транзакций, и их неизменность, и доступность для аудита.
Классические модели безопасности были созданы для решения отдельных задач. Модель Белла-ЛаПадулы — эталон контроля доступа для защиты государственных секретов — жёстко разделяет информацию по уровням секретности, но абсолютно не заботится о её целостности. Обратная ей модель Биба создана для защиты от несанкционированных изменений, но игнорирует конфиденциальность. Попытка применить их вместе к одной системе приводит к конфликту правил. Одна модель разрешает запись «сверху вниз», другая — «снизу вверх». Без общего формализма администратор вынужден вручную искать компромисс, что не только трудоёмко, но и чревато ошибками, которые могут привести к уязвимостям.
От математической теории к практическому инструменту
Унифицированная вычислительная модель, это не просто «объединение» старых подходов. Это создание нового формального языка, на котором можно описать любые требования безопасности как набор правил, условий и состояний системы. Такой язык должен быть достаточно выразительным, чтобы охватить известные политики, и достаточно строгим, чтобы допускать автоматический анализ.
На практике это означает переход от текстовых политик в регламентах (например, «сотрудник отдела кадров имеет доступ к персональным данным, но не может их экспортировать») к их машинному представлению. Последнее позволяет не только автоматически настраивать систему контроля доступа, но и проверять всю политику целиком на внутреннюю противоречивость, избыточность или невыполнимость некоторых правил.
Компоненты единой модели
Любая такая модель строится на нескольких ключевых абстракциях.
Субъекты, объекты и операции
Субъект, это активный элемент (пользователь, процесс, сервис), который инициирует действие. Объект — пассивный элемент (файл, запись в базе данных, сетевое соединение), над которым производится действие. Операция, это собственно действие: чтение, запись, выполнение, создание, удаление. В единой модели этот базовый набор расширяется. Например, операцией может быть «делегирование права» или «изменение атрибута безопасности».
Состояние системы и правила перехода
Модель описывает систему в каждый момент времени как состояние — снимок всех разрешений, атрибутов и текущих действий. Правила перехода определяют, при каких условиях система может перейти из одного состояния в другое. Именно здесь кодируется политика безопасности: правило может разрешить субъекту прочитать объект только если его уровень допуска не ниже уровня секретности объекта. Другое правило может запретить процессу с низким уровнем целостности записывать данные в файл с высоким уровнем.
Атрибуты безопасности
Это метки, приписанные субъектам и объектам. В классических моделях это были просто уровни (конфиденциальности или целостности). В унифицированной модели атрибуты становятся многомерными и могут включать в себя роли, членство в группах, временные ограничения, географическое местоположение источника запроса и даже результаты предыдущих проверок. Например, атрибут может быть таким: {role: 'auditor', clearance: 'L3', session_start: '10:00', allowed_ops: ['read', 'log']}.
Как работает автоматизированная верификация политик
Когда политика описана на формальном языке модели, её можно «прокрутить» через анализатор. Задача анализатора — доказать, что из начального безопасного состояния система не может перейти в небезопасное, нарушив хотя бы одно из заданных свойств. Эти свойства формулируются на том же языке. Например:
- Свойство конфиденциальности: «Информация с меткой ‘Секретно’ никогда не может быть прочитана субъектом без соответствующего уровня допуска».
- Свойство целостности: «Данные в финансовом журнале не могут быть изменены процессом, запущенным из неподписанного модуля».
- Свойство доступности: «Сервис аутентификации должен отвечать на запросы роли ‘эксперт’ не позднее 100 мс при любом допустимом состоянии системы».
Анализатор, используя методы model checking или теорем доказывания, проверяет выполнимость этих свойств для всех возможных последовательностей действий. Если обнаруживается контрпример — последовательность шагов, ведущая к нарушению, — значит, политика содержит уязвимость или противоречие. Это позволяет выявить проблемы на этапе проектирования, до развёртывания системы.
Практическое применение в контексте 152-ФЗ и ФСТЭК
Для регуляторных требований, таких как приказы ФСТЭК, унифицированная модель становится мостом между текстом стандарта и его технической реализацией. Многие требования из руководящих документов могут быть переведены в формальные правила.
Например, требование о разделении обязанностей (SoD) можно описать как правило: «Не существует такого субъекта, который в рамках одной сессии может выполнить операцию O1 (инициирование платежа) и операцию O2 (его утверждение)». Анализатор проверит, что в системе, сконфигурированной по заданной политике доступа, такая ситуация действительно невозможна. Это гораздо надёжнее периодических ручных проверок матриц доступа.
Разработка такой модели для конкретной организации или класса систем позволяет создать эталонную, верифицированную конфигурацию безопасности. Её можно использовать как основу для аттестации, доказывая регулятору, что система не просто настроена по checklist, а её безопасность математически обоснована.
Трудности и ограничения
Главная проблема — сложность. Чем больше и разнообразнее политика, тем больше возможных состояний системы, что приводит к «взрыву состояний» — exponential state explosion. Проверка становится вычислительно невыполнимой для очень сложных систем. Решение — использование абстракций, упрощающих модель без потери важных свойств безопасности, и модульный подход, когда система проверяется по частям.
Вторая проблема — необходимость экспертов, способных формализовать требования регуляторики на строгом математическом языке. Это новая специальность на стыке информационной безопасности, software engineering и формальных методов.
Несмотря на сложность, движение в сторону единых формальных моделей, это эволюционный путь. Без них обеспечение безопасности в комплексных цифровых средах будет всё больше напоминать попытку управлять современным истребителем с помощью рычагов и шкивов от биплана. Формальная модель не гарантирует отсутствия уязвимостей в реализации, но она даёт уверенность в правильности самого плана защиты, что уже является критическим шагом вперёд.