“Российскому специалисту по ИБ часто приходится слышать про конфиденциальность целостность доступность, но гораздо реже — про то, как на уровне формальной математики можно доказать, что секретные данные действительно никогда не попадут на публичный выход. Noninterference, это не просто «запретить», а гарантия того, что высокий уровень не влияет на низкий. А declassification, это единственный законный способ нарушить эту гарантию, и с ним больше проблем, чем кажется. Практика российских ЦОД и ФСТЭК почти никогда не говорит об этом прямо, но за требованиями скрытых каналов и изолированных сетей лежит именно эта концепция.”
Что такое управление потоками информации
Управление потоками информации, это не политика разграничения доступа, хотя и строится поверх неё. Это принципиально другая задача. В классической модели DAC или мандатного контроля (МК) вопрос стоит так: «Имеет ли субъект право прочитать объект?». Управление потоками отвечает на другой вопрос: «Куда может попасть информация после того, как её прочитали?».
Разница фундаментальна. Сотрудник с высоким уровнем допуска может законно прочитать секретный документ. Но если программа после обработки этого документа выводит результат на общедоступный принтер — произошла утечка. Мандатный контроль этого не предотвратит, ведь чтение было разрешено. Именно здесь вступают в силу механизмы контроля за потоками информации, отслеживающие маршрут данных через всю систему.
Noninterference: гарантия изоляции
Краеугольный камень всей теории — принцип невмешательства (noninterference). Формально он звучит так: действия пользователей с высоким уровнем конфиденциальности не должны оказывать никакого наблюдаемого влияния на выводы, доступные пользователям с низким уровнем. Если проще — наблюдатель с «низким» уровнем, глядя на систему (её выводы, логи, состояние сетей), никак не сможет определить, работал ли в ней кто-то «сверху» или нет.
Представьте изолированный сегмент сети для обработки персональных данных. Noninterference требует, чтобы трафик и состояние этого сегмента никак не отражались на работе публичного веб-сервера, даже в виде косвенных признаков вроде задержек или нагрузки. Речь идёт не просто о запрете сетевых соединений, а о полном отсутствии информационного влияния.
Именно эта идея стоит за многими требованиями регуляторов. Когда ФСТЭК требует защиты от скрытых каналов, он, по сути, требует обеспечения noninterference на физическом и техническом уровнях, потому что теоретически информация может «перетечь» через канал побочного действия — загрузку процессора, использование общей памяти, даже через звук системы охлаждения.
От теории к практическим механизмам
Как технически добиться такой изоляции? На разных уровнях абстракции используются разные подходы.
На уровне операционной системы и виртуализации
Здесь основная работа ведётся с метками. Каждому процессу, файлу, сетевому сокету присваивается метка конфиденциальности. Ядро или гипервизор отслеживает все операции и блокирует те, что могут привести к незаконному потоку «сверху вниз». Например, запрещается запись данных с высоким уровнем в файл с низкой меткой или отправка таких данных в сетевой интерфейс, предназначенный для публичной зоны.
На уровне языка программирования
Для критичного кода, например, в СУБД или сервисах аутентификации, используют языки со встроенной проверкой потоков. Компилятор или специальный статический анализатор проверяет, что переменная с секретом никогда не используется в условии, влияющем на публичный вывод, или не присваивается переменной с публичной меткой.
// Примерная идея: переменная с аннотацией метки
@High int secretKey = getKey();
@Low int publicCounter = 0;
// Статический анализатор отклонит эту строку:
publicCounter = secretKey; // ОШИБКА: незаконный поток из High в Low
Этот подход переносит гарантии с уровня системы на уровень приложения, позволяя отлавливать уязвимости на этапе разработки.
Declassification: когда нарушать правила необходимо
Абсолютная изоляция невозможна в реальных системах. Информация должна иногда переходить с высокого уровня на низкий — иначе зачем её собирать? Процесс контролируемого и безопасного понижения уровня конфиденциальности называется declassification (рассекречивание).
Это самая сложная и опасная часть. Неправильно настроенное рассекречивание сводит на нет все предыдущие гарантии. Классический пример — система, проверяющая пароль. Секретный эталонный хеш (высокий уровень) сравнивается с введённым пользователем значением (изначально низкий уровень). Результат сравнения («верно/неверно») должен стать публичным. Это и есть точка рассекречивания.
Проблема в том, что через эту узкую щель можно вытянуть гораздо больше, чем задумано. Атака по времени: если сравнение строк происходит побайтово и останавливается на первой несовпадающей букве, то, замеряя время ответа, атакующий может узнать длину и даже содержание секретного хеша. Система формально соблюдает noninterference, но канал побочного действия нарушает его дух.
Принципы безопасного declassification
Чтобы минимизировать риски, в теории определены строгие правила для точек рассекречивания:
- Явность: в коде должна быть чётко обозначена инструкция, которая понижает уровень. Это не должно происходить «само собой».
- Минимизация: выводится не сырая секретная информация, а лишь необходимый минимум — агрегированный результат, бит решения, факт из определённого множества.
- Цело