Многоуровневая безопасность

Многоуровневая вычислительная среда (MLS-окружение) обычно требует высоконадежной информационной системы, часто построенной на базе MLS-операционной системы, хотя это не является обязательным. Большинство функций MLS может быть реализовано даже с помощью не доверенных компьютеров, если они объединены независимыми аппаратными каналами, соответствующими требованиям безопасности. Примером аппаратной реализации MLS может служить асимметричная изоляция^[1]. В случае, когда на одном компьютере реализован режим MLS, операционная система должна быть доверенной. Поскольку вся информация в среде MLS физически доступна ОС, необходимы строгие логические механизмы управления доступом — обычно реализуемые средствами обязательный контроль доступа, например с помощью меток безопасности, как в модели Белла — ЛаПадулы.

Пользователи, внедряющие доверенные операционные системы, обычно требуют формальной оценки компьютерной безопасности продукта. При расширении диапазона уровней безопасности требования оценки повышаются: речь идёт о минимальных и максимальных уровнях классификации, которые может обрабатывать система. Trusted Computer System Evaluation Criteria (TCSEC) стали первым стандартом, позволяющим оценивать MLS-системы. Для этого стандарта существовало однозначное соответствие^[2] между требованиями безопасности и диапазоном реализуемых уровней MLS. Исторически лишь немногие реализации были сертифицированы для поддержки многоуровневой обработки (от не секретно до совершенно секретно): среди них — SCOMP компании Honeywell, SACDIN ВВС США, система Blacker Агентства национальной безопасности США и MLS LAN компании Boeing — все они базировались на TCSEC в 1980-х и архитектуре Intel 80386. В настоящее время оценка MLS-продуктов проводится по Common Criteria. В конце 2008 года первая операционная система была сертифицирована на высоком уровне уверенности в оценке: Evaluation Assurance Level (EAL) 6+ / High Robustness в рамках программы правительства США для сред с высоким уровнем угроз. Хотя этот уровень уверенности схож с классом A1 по Orange Book (например, требования к формальным методам), функциональные требования здесь направлены прежде всего на изоляцию и политики контроля потоков информации, а не на более высокоуровневые политики типа Белла — ЛаПадулы. Из-за того, что Common Criteria отделила уверенность (EAL) от функциональности (Protection Profile), потеряна ранее существовавшая чёткая связь между требованиями безопасности и поддерживаемыми уровнями безопасности, документированная в CSC-STD-004-85 (после перехода от Rainbow Series к Common Criteria).

Свободно распространяемые операционные системы с поддержкой некоторых функций MLS включают Linux с включённым Security-Enhanced Linux и FreeBSD^[3]. Ранее считалось, что для таких бесплатных реализаций MLS сертификация по безопасности затруднительна по трём причинам:

1. Реализация механизмов самозащиты ядра на должном для MLS уровне очень сложна; к тому же, подобные разработки не проектировались и не сертифицировались для MLS-профилей защиты, поэтому не гарантируют необходимый уровень самозащиты.
2. Помимо уровней EAL, в Common Criteria нет набора высоконадёжных профилей защиты, определяющих жёсткие требования к функционированию MLS-режима.
3. Даже при соблюдении первых двух пунктов процесс оценки крайне затратен и требует специального контроля изменений в программном обеспечении.

Несмотря на эти предположения, Red Hat Enterprise Linux 5 был сертифицирован по LSPP, RBACPP и CAPP на уровне EAL4+ в июне 2007 года^[4]. Для обеспечения MLS в нём применяется Security-Enhanced Linux — это первая сертификация Common Criteria, реализующая контроль свойств безопасности TOE при помощи Security-Enhanced Linux.

Стратегия вендорской сертификации может быть обманчива для неспециалистов. Часто преувеличивается значение уровня EAL, например, профиль защиты EAL 3 (например, CAPP)^[5] может быть сертифицирован на более высокий уровень EAL 4 или EAL 5, хотя сам профиль MLS не поддерживает. Также нередко внедряются функции MLS (например, профиль защиты RBAC или LSPP), но ядро не сертифицируется по MLS-профилю. Такие функции запускаются как сервисы поверх ядра и полагаются на его защищённость от сбоев и атак; если ядро не аттестовано на MLS, функциональность MLS не может считаться надёжной — вне зависимости от успешности демонстраций. Особенно важно, что CAPP явно не является MLS-профилем, поскольку исключает механизмы самозащиты, критичные для многоуровневой безопасности.

Компания General Dynamics предлагает PitBull — доверенную операционную систему с поддержкой MLS. Современная версия распространяется как модификация Red Hat Enterprise Linux, тогда как ранние варианты были реализованы для Solaris, IBM AIX и SVR4 Unix. PitBull реализует механизм безопасности по модели Белла — ЛаПадулы (конфиденциальность), механизмы целостности по модели Биба, замену привилегий для суперпользователя, а также множество других функций. PitBull является основой среды General Dynamics Trusted Network Environment (TNE) с 2009 года. TNE обеспечивает многоуровневый обмен и доступ для пользователей Министерства обороны и разведывательного сообщества США на различных уровнях классификации. Она также служит фундаментом для среды многоуровневого взаимодействия союзников, системы Battlefield Information Collection and Exploitation Systems Extended^[6] (BICES-X).

Sun Microsystems (ныне Oracle Corporation) предлагает интегрированную в коммерческие операционные системы Solaris и OpenSolaris функцию Solaris Trusted Extensions. В дополнение к профилям CAPP и RBAC, Trusted Extensions были сертифицированы на уровне EAL4 соответственно LSPP^[7]. Данный сертификат охватывает как настольные, так и сетевые функции. LSPP запрещает пользователям выходить за пределы политик маркировки, реализованных ядром и сервером X Window System (X11). Оценка сертификации не включает анализ скрытых каналов. Так как сертификация опирается на CAPP, она не даёт оснований считать продукт надёжным для MLS-сред.

BAE Systems выпускает систему XTS-400, заявленную производителем как поддерживающую MLS с «высокой степенью надёжности». Предшественники XTS-400 (например, XTS-300) сертифицировались по TCSEC на уровне B3, что подразумевает поддержку MLS. XTS-400 прошла оценку Common Criteria по EAL5+ относительно CAPP и LSPP. Оба последних — это EAL3-профили, не обладающие собственной поддержкой MLS, однако security target^[8] расширяет набор функций безопасности и реализует возможности MLS.

Очистка данных представляет серьёзную проблему для MLS-систем. Реализации MLS-контроля (например, по модели Белла — ЛаПадулы) позволяют обмен только там, где нарушение политики безопасности невозможно. Пользователи с низким уровнем допуска могут легко делиться данными с более высокими уровнями, но обратная связь невозможна. Нет надёжного способа для пользователя с уровнем «совершенно секретно» отредактировать файл, очистить его от засекреченной информации и передать коллегам с более низким доступом. На практике эту проблему часто обходят с помощью специальных привилегированных функций, позволяющих доверенным лицам изменить гриф файла, но данный механизм не гарантирует безопасности.

Другой проблемой являются скрытые каналы. Чтобы исключить утечку, MLS-система должна гарантированно предотвращать любые способы передачи сигналов от процесса «совершенно секретно» к «секретно» или ниже, в том числе через косвенные признаки — свободную память, пространство на диске, время отклика и др. Использование таких признаков для передачи информации и есть эксплуатация скрытого канала. Исключить все скрытые каналы в реально функционирующей системе практически невозможно; само их выявление представляет собой сложную задачу. Большинство коммерческих MLS-систем не пытается закрыть скрытые каналы, что делает невозможным их применение в наиболее критичных средах.

Проблема обхода (bypass) особенно значима при попытке обрабатывать секретные объекты как MLS-доверенные. Например, попытка экспортировать данные из секретного объекта в открытое хранилище на основании формата как признака их не секретности. Подобные обходы легко превращаются в неконтролируемые каналы утечки. Обходы чаще возникают при попытке доработать систему без учёта MLS в архитектуре; в подобных случаях придумываются псевдозащищённые схемы, например разбор содержимого в обходимых данных, однако без доверия к источнику невозможно гарантировать отсутствие секретной информации — уверенный "защищённый обход" невозможен, как и мифический High Assurance Guard. Такие риски известны давно, а существующие решения по сути процедурные, а не технические. До сих пор невозможно надёжно оценить объём утекшей информации через обходы.

Наиболее наглядный пример неминуемого обхода — ситуация, когда система обязана принимать секретные IP-пакеты от недоверенного источника, шифровать только полезную нагрузку, а не заголовок, и передавать их в недоверенную сеть. Поскольку источник формально недоверен, он может произвольно вставлять секретные данные в незашифрованную часть. Если такой трафик дальше попадёт в открытую сеть, злоумышленник может получить инсайдерскую информацию, а выявить такой канал будет очень сложно. Признание подобной структуры system high (вместо MLS) приводит к широко распространённой, но серьёзной угрозе.

В большинстве случаев обход можно избежать — если изначально проектировать архитектуру с учётом безопасности, а не накладывать защиту позднее в виде надстроек. Иногда одобряются (или утверждаются) схемы, пытающиеся анализировать содержимое обходимых данных для защиты, что невозможно без доверия к формату исходных данных, а значит не решает проблему. "Безопасный обход" по сути невозможен, так же как и полностью прозрачный High Assurance Guard. Проблема известна давно; все существующие решения носят процедурный, а не технический характер.

В последнее время ряд неспециалистов в области IT приходит к выводу о якобы не существовании MLS. Причиной может служить падение числа экспертов по информационной безопасности^[9] и смешение двух смыслов термина: MLS как характеристики среды и MLS как способности (capability). Многие считают, что MLS не существует, поскольку не существует сертифицированных продуктов для работы в режиме MLS, однако это не одно и то же. Системы, работающие со смешанными уровнями секретности, формально удовлетворяют определению MLS по Computer Security Intermediate Value Theorem (CS-IVT)^[10]. При этом существуют сертифицированные Агентством национальной безопасности США MLS-системы с 1970-х годов, причём MLS-продукты продолжают разрабатываться и внедряться.

Часто ошибочно считают, что признание системы MLS-средой ведёт к признанию нерешаемости проблем MLS на уровне функций. Однако MLS гораздо сложнее, чем может показаться на первый взгляд, и отсутствие простых решений не доказывает их не существование. Такая точка зрения ведёт к негативным последствиям для компьютерной безопасности, в том числе к «запретной теме» MLS. Проблема решается чётким разделением смысла MLS-среды и MLS-способности.

• MLS как среда или режим безопасности: в среде, где пользователи имеют разные допуски, MLS может восприниматься как механизм коллективного доступа, позволяющий обмен информацией только между теми, кто допущен к нужному уровню. Система работает в режиме MLS, если у неё есть связь с теми, чей допуск ниже максимального уровня обрабатываемых ею данных (по CS-IVT). Классификация режима зависит только от реальной среды — состава данных, допусков пользователей и каналов связи. Режим работы независим от возможностей системы, хотя система не должна эксплуатироваться в режиме, не соответствующем её уровню доверия.
• MLS как функция: разработчики систем склонны воспринимать MLS как техническую способность к обеспечению изоляции или политик безопасности (например, по модели Белла — ЛаПадулы). Система считается MLS-способной, если она гарантированно реализует изоляционные политики.

Первоначальное определение MLS относилось к характеристике среды. Решение проблемы — придерживаться исторического значения (как среды), а в случае необходимости специально оговаривать MLS-функциональность.

Multiple Independent Levels of Security (MILS, Множественные независимые уровни защищённости) — это архитектура, решающая задачу разделения доменов в рамках MLS. При этом создан термин Cross Domain Access как категория Минобороны и разведывательного сообщества США, часто отождествляемая с архитектурой MILS.

Модели безопасности, такие как модель Биба (целостность) и модель Белла — ЛаПадулы (конфиденциальность), допускают односторонние потоки между обычно изолированными доменами безопасности. MILS решает именно задачу изоляции, не затрагивая управляемое взаимодействие между доменами, реализуемое перечисленными моделями. Безопасные каналы, упомянутые выше, могут объединять домены MILS для расширения возможностей MLS.

Архитектура MILS следует более старой концепции MSL (multiple single level — множественные однородные уровни), в которой каждый уровень информации изолирован в своём одномерном окружении (System High).

Жёсткое разделение процессов и их изоляция, реализуемые MILS, могут оказаться более полезными для крайне ответственных приложений, чем классический MLS. MILS не поддерживает иерархическую структуру «уровней безопасности» — для обмена между уровнями требуются отдельные дополнительные приложения импорта/экспорта, каждое из которых должно проходить индивидуальную сертификацию. В этом смысле MILS можно называть «множественные независимые домены безопасности», а для эмуляции MLS на базе MILS также потребуется разработка и сертификация соответствующих приложений. Отказ архитетуры MILS от изначальной поддержки взаимодействия между уровнями безопасности делает её начально просто реализуемой, но для полноценного MLS-функционала требуется не тривиальная надстройка из сервисов импорта/экспорта.

Сравнивая MLS/MLS, стоит учитывать, не проще ли сертифицировать набор небольших специализированных экспортных приложений, чем централизованное MLS-ядро. Это во многом зависит от ожидаемого объёма взаимодействий. В пользу MILS говорит то, что не все экспортные приложения требуют максимальной уверенности.

Существует и иной способ решения задачи — архитектура множественных однородных уровней. Здесь каждый уровень изолирован в своём собственном недоверенном домене, а отсутствие средств передачи данных гарантирует полное отсутствие взаимодействия. Обычно используется физическое разделение (на разных компьютерах). Такой подход применяется для приложений и операционных систем, не поддерживающих MLS (например, Microsoft Windows).

Инфраструктура, такая как доверенные операционные системы, важна для MLS-систем, однако для полного соответствия определению MLS по CNSSI 4009 требуется, чтобы пользовательский интерфейс позволял работать с контентом на разных уровнях секретности с одного устройства. Подразделение UCDMO США проводило отдельную сессию по MLS на симпозиуме NSA по информационной безопасности в 2009 году, где были представлены аккредитованные и экспериментальные реализованные системы MLS. Одним из примеров MLS в пользовательском пространстве является SELinux^[11].

Существуют базы данных, классифицируемые как MLS-системы. Компания Oracle выпускает Oracle Label Security (OLS), реализующую обязательный контроль доступа — как правило, добавляя в каждую таблицу базы данных Oracle особый столбец с меткой. OLS внедряется, к примеру, в INSCOM Армии США как основа разведывательной базы, охватывающей сети JWICS и SIPRNet. Разрабатывается версия PostgreSQL с поддержкой меток, а также существуют устаревшие реализации, как Trusted Rubix. Эти системы предоставляют унифицированную инфраструктуру для хранения данных с различным уровнем секретности, но не решают проблему работы пользователя с многоуровневым контентом при одновременном соблюдении обязательного контроля доступа.

Есть и ряд MLS-приложений для конечных пользователей. Например, сервер чата MLChat, работающий на базе XTS-400 и созданный Исследовательской лабораторией ВМС США. Поскольку в MLChat пересекаются потоки пользователей разных доменов, реализована фильтрация по ключевым словам для защиты класифицированных данных, однако ведутся споры, относится ли система к полноценным MLS или скорее к типу междоменных решений. Обязательный контроль доступа реализуется комбинированно — средствами XTS-400 и прикладного уровня^[12].

Среди продуктов, не входящих в текущий перечень UCDMO, можно выделить пакет MLS-приложений компании BlueSpace, включающий MLS-клиент электронной почты, систему поиска, систему управления, и др. BlueSpace использует middleware для обеспечения многоплатформенной поддержки, обеспечивая единый интерфейс между несколькими экземплярами Windows (виртуализированными или в виде удалённых сессий). Исследовательская лаборатория ВМС США также создала фреймворк MLWeb на базе Ruby on Rails и многозначной СУБД на SQLite3.

Важнейшая современная тенденция в области MLS — сближение с технологиями виртуализации. Всё больше доверенных операционных систем переходят от маркировки файлов и процессов к контейнерам (например, зоны в Solaris 10 TX) либо виртуальным машинам (hypervisor, как у Green Hills Integrity или XenClient XT от Citrix). Программа High Assurance Platform Агентства национальной безопасности, реализованная на платформе Trusted Virtualization Environment (TVE) General Dynamics, использует в основе SE Linux, поддерживает MLS-приложения, охватывающие несколько доменов.