Войти
Многоуровневая система безопасность или несколько уровней безопасности ( MLS) является применением компьютерной системы обработки информации с несовместимыми классификациями (т.е. на разных уровнях безопасности), доступ разрешения пользователей с различными зазорами безопасности и потребностями к ноу, и запретить пользователь от получения доступа к информации, на которую у них нет разрешения. Есть два контекста использования многоуровневой безопасности. Один из них - это система, которая адекватна для защиты от подрывной деятельности и имеет надежные механизмы для разделения информационных доменов, то есть заслуживающая доверия. Другой контекст - это приложение компьютера, которое требует, чтобы компьютер был достаточно сильным, чтобы защитить себя от подрывной деятельности, и обладать адекватными механизмами для разделения информационных доменов, то есть системой, которой мы должны доверять. Это различие важно, поскольку системы, которым нужно доверять, не обязательно заслуживают доверия.
Операционная среда MLS часто требует надежной системы обработки информации, часто построенной на операционной системе (ОС) MLS, но не обязательно. Большинство функций MLS может поддерживаться системой, полностью состоящей из ненадежных компьютеров, хотя для этого требуется несколько независимых компьютеров, связанных аппаратными каналами, совместимыми с безопасностью (см. Раздел B.6.2 Интерпретации доверенной сети, NCSC-TG-005 ). Примером MLS с аппаратным обеспечением является асимметричная изоляция. Если один компьютер используется в режиме MLS, то этот компьютер должен использовать доверенную операционную систему (ОС). Поскольку вся информация в среде MLS физически доступна ОС, должны существовать строгие логические элементы управления, чтобы гарантировать, что доступ к информации строго контролируется. Обычно это включает принудительный контроль доступа с использованием меток безопасности, как в модели Белла – ЛаПадулы.
Заказчики, которые развертывают доверенные операционные системы, обычно требуют, чтобы продукт прошел формальную оценку компьютерной безопасности. Оценка более строгая для более широкого диапазона безопасности, который является самым низким и самым высоким уровнями классификации, которые может обработать система. В критерии определения безопасности компьютерных систем (TCSEC) была первым критерием оценки, разработанный для оценки MLS в компьютерных системах. В соответствии с этими критериями существует четкое единообразное соответствие между требованиями безопасности и широтой диапазона безопасности MLS. Исторически немногие реализации были сертифицированы для обработки MLS с диапазоном безопасности от Несекретного до Совершенно секретно. Среди них были Honeywell 's SCOMP, USAF SACDIN, NSA ' s чернее и Boeing МЛ LAN «s, все под TCSEC, 1980s марочные и Intel 80386 -На. В настоящее время продукция MLS проходит оценку по Общим критериям. В конце 2008 года первая операционная система (подробнее ниже) была сертифицирована на высокий оцененный уровень гарантии: Evaluation Assurance Level (EAL) - EAL 6+ / High Robustness, под эгидой правительственной программы США, требующей многоуровневой безопасности при высокой угрозе. Окружающая среда. Хотя этот уровень доверия имеет много общего с уровнем гарантии старой Orange Book A1 (например, формальные методы), функциональные требования сосредоточены на фундаментальных политиках изоляции и информационных потоков, а не на политиках более высокого уровня, таких как Bell-La Padula. Поскольку Common Criteria развязал сочетание гарантии (EAL) и функциональности (Protection Profile) TCSEC, четкое единообразное соответствие между требованиями безопасности и возможностями диапазона безопасности MLS, задокументированное в CSC-STD-004-85, было в значительной степени утрачено, когда Common Criteria заменил собой Серия радуги.
Свободно доступные операционные системы с некоторыми функциями, поддерживающими MLS, включают Linux с включенной функцией Security-Enhanced Linux и FreeBSD. Когда-то считалось, что оценка безопасности является проблемой для этих бесплатных реализаций MLS по трем причинам:
Несмотря на такие предположения, Red Hat Enterprise Linux 5 был сертифицирован по LSPP, RBACPP и CAPP на EAL4 + в июне 2007 года. Он использует Linux с улучшенной безопасностью для реализации MLS и был первым сертификатом Common Criteria для обеспечения соблюдения свойств безопасности TOE с Linux с расширенной безопасностью..
Стратегии сертификации поставщиков могут ввести в заблуждение неспециалистов. Обычная стратегия использует чрезмерное внимание непрофессионала к уровню EAL с чрезмерной сертификацией, например, сертификация профиля защиты EAL 3 (например, CAPP) на повышенные уровни, такие как EAL 4 или EAL 5. Другая - добавление и сертификация функций поддержки MLS (таких как роль профиль защиты управления доступом (RBACPP) и помеченный профиль защиты безопасности (LSPP)) к ядру, которое не оценивается для профиля защиты с поддержкой MLS. Эти типы функций представляют собой службы, запускаемые в ядре и зависящие от ядра для защиты их от повреждения и подрывной деятельности. Если ядро не оценивается по профилю защиты с поддержкой MLS, функциям MLS нельзя доверять, независимо от того, насколько впечатляюще выглядит демонстрация. Особо следует отметить, что CAPP не является профилем с поддержкой MLS, поскольку он специально исключает возможности самозащиты, критичные для MLS.
General Dynamics предлагает PitBull, надежную операционную систему MLS. PitBull в настоящее время предлагается только как расширенная версия Red Hat Enterprise Linux, но более ранние версии существовали для Sun Microsystems Solaris, IBM AIX и SVR4 Unix. PitBull предоставляет механизм безопасности Bell LaPadula, механизм целостности Biba, замену привилегий для суперпользователя и многие другие функции. PitBull имеет базу безопасности для продукта Trusted Network Environment (TNE) General Dynamics с 2009 года. TNE обеспечивает многоуровневый обмен информацией и доступ для пользователей в сообществах Министерства обороны и разведки, использующих различные уровни классификации. Это также основа для многоуровневой среды совместного использования коалиций, расширенной системы сбора и эксплуатации информации поля боя (BICES-X).
Sun Microsystems, теперь Oracle Corporation, предлагает Solaris Trusted Extensions в качестве интегрированной функции коммерческих ОС Solaris и OpenSolaris. В дополнение к профилям защиты управляемого доступа (CAPP) и управления доступом на основе ролей (RBAC), доверенные расширения также были сертифицированы по EAL4 для маркированного профиля защиты безопасности (LSPP). Цель безопасности включает как настольные, так и сетевые функции. LSPP требует, чтобы пользователи не имели права переопределять политики маркировки, применяемые ядром и системой X Window (сервер X11). Оценка не включает анализ скрытых каналов. Поскольку эти сертификаты зависят от CAPP, сертификаты Common Criteria не предполагают, что этот продукт заслуживает доверия для MLS.
BAE Systems предлагает XTS-400, коммерческую систему, которая поддерживает MLS с «высокой степенью надежности», как утверждает производитель. Продукты-предшественники (включая XTS-300) оценивались на уровне TCSEC B3, который поддерживает MLS. XTS-400 был оценен по общим критериям на уровне EAL5 + по профилям защиты CAPP и LSPP. CAPP и LSPP являются профилями защиты EAL3, которые изначально не поддерживают MLS, но цель безопасности для оценки Common Criteria этого продукта содержит расширенный набор функций безопасности, которые обеспечивают возможность MLS.
Санитарная обработка - это проблемная область для систем MLS. Системы, которые реализуют ограничения MLS, подобные тем, которые определены в модели Белла – ЛаПадулы, разрешают совместное использование только в том случае, если оно явно не нарушает ограничения безопасности. Пользователи с более низким уровнем допуска могут легко делиться своей работой с пользователями с более высоким уровнем допуска, но не наоборот. Не существует эффективного и надежного механизма, с помощью которого пользователь совершенно секретно может редактировать совершенно секретный файл, удалять всю совершенно секретную информацию и затем доставлять ее пользователям с секретным или более низким уровнем допуска. На практике системы MLS обходят эту проблему с помощью привилегированных функций, которые позволяют надежному пользователю обойти механизм MLS и изменить классификацию безопасности файла. Однако методика ненадежна.
Скрытые каналы представляют собой еще одну проблему для систем MLS. Чтобы система MLS могла идеально хранить секреты, не должно быть возможности для процесса Совершенно секретно передавать сигналы любого вида секретному или более низкому процессу. Сюда входят побочные эффекты, такие как изменения доступной памяти или дискового пространства или изменения времени процесса. Когда процесс использует такой побочный эффект для передачи данных, он использует скрытый канал. В практической вычислительной системе чрезвычайно сложно закрыть все скрытые каналы, а на практике это может оказаться невозможным. Процесс выявления всех скрытых каналов сам по себе является сложной задачей. Большинство коммерчески доступных систем MLS не пытаются закрыть все скрытые каналы, хотя это делает непрактичным их использование в приложениях с высоким уровнем безопасности.
Обход проблематичен, когда он вводится как средство обработки объекта высокого уровня системы, как если бы он был доверенным MLS. Типичным примером является извлечение данных из секретного системного объекта высокого уровня для отправки в неклассифицированное место назначения, указав какое-либо свойство данных в качестве надежного доказательства того, что они «действительно» неклассифицированы (например, «строгий» формат). Системе высокого уровня нельзя доверять, чтобы сохранить какие-либо доверенные свидетельства, и в результате открывается открытый путь к данным без логического способа безопасного посредничества. Обход может быть рискованным, потому что, в отличие от скрытых каналов с узкой полосой пропускания, которые трудно использовать, обход может привести к большой, легко используемой открытой утечке в системе. Обход часто возникает из-за невозможности использовать доверенные операционные среды для поддержания непрерывного разделения доменов безопасности на всем пути до их происхождения. Когда этот источник находится за пределами границы системы, может оказаться невозможным подтвердить доверенное разделение на источник. В этом случае риск обхода может быть неизбежен, если поток действительно необходим.
Типичным примером неизбежного обхода является субъектная система, которая должна принимать секретные IP-пакеты от ненадежного источника, шифровать секретные данные пользователя, а не заголовок, и передавать результат в ненадежную сеть. Источник находится вне сферы влияния субъектной системы. Хотя источник не является доверенным (например, высокий уровень системы), ему доверяют, как если бы он был MLS, поскольку он предоставляет пакеты с неклассифицированными заголовками и секретными пользовательскими данными в виде открытого текста, конструкцией данных MLS. Поскольку источник не является надежным, он может быть поврежден и хранить секреты в неклассифицированном заголовке пакета. Поврежденные заголовки пакетов могут быть бессмысленными, но субъектная система не может определить это с какой-либо разумной надежностью. Данные пользователя пакета криптографически хорошо защищены, но заголовок пакета может содержать читаемые секреты. Если поврежденные пакеты передаются в ненадежную сеть субъектной системой, они могут быть не маршрутизируемыми, но какой-то взаимодействующий поврежденный процесс в сети может захватить пакеты и подтвердить их, а субъектная система может не обнаружить утечку. Это может быть большая явная утечка, которую трудно обнаружить. Просмотр классифицированных пакетов с неклассифицированными заголовками как системных структур вместо структур MLS, которыми они на самом деле являются, представляет собой очень распространенную, но серьезную угрозу.
В большинстве случаев обхода можно избежать. Избегаемый обход часто возникает, когда системные архитекторы проектируют систему до того, как правильно учли безопасность, а затем пытаются применить безопасность постфактум в качестве дополнительных функций. В этой ситуации обход оказывается единственным (простым) способом заставить систему работать. Предлагаются (и одобряются!) Некоторые псевдобезопасные схемы, которые проверяют содержимое обойденных данных в тщетной попытке установить, что обойденные данные не содержат секретов. Это невозможно без доверия к данным, например к их формату, что противоречит предположению о том, что источнику не доверяют сохранение каких-либо характеристик исходных данных. Гарантированный «безопасный обход» - это миф, как и так называемая High Assurance Guard (HAG), которая прозрачно реализует обход. Риск, который они представляют, давно признан; существующие решения в конечном итоге носят процедурный, а не технический характер. Невозможно с уверенностью узнать, какой объем секретной информации извлекается из наших систем с помощью обхода.
Существует снижение CompuSec экспертов и термин MLS был перегружен. Непрофессионалы проектируют безопасные вычислительные системы и приходят к выводу, что MLS не существует. Эти два использования: MLS как среда обработки против MLS как возможность. Убеждение, что MLS не существует, основано на убеждении, что не существует продуктов, сертифицированных для работы в среде или режиме MLS, и, следовательно, MLS как возможность не существует. Одно не подразумевает другого. Многие системы работают в среде, содержащей данные с неодинаковыми уровнями безопасности и, следовательно, являются MLS в соответствии с теоремой о промежуточном значении компьютерной безопасности (CS-IVT). Последствия этой путаницы еще глубже. Сертифицированные NSA операционные системы, базы данных и сети MLS существуют в рабочем режиме с 1970-х годов, и продукты MLS продолжают создаваться, продаваться и развертываться.
Непрофессионалы часто приходят к выводу, что признание того, что система работает в среде MLS (ориентированное на окружающую среду значение MLS), должно быть поддержано в предполагаемом углу наличия проблемы без решения MLS (ориентированное на возможности значение MLS). MLS обманчиво сложен, и то, что простые решения не очевидны, не оправдывает вывод о том, что их не существует. Это может привести к ужасающему невежеству в отношении COMPUSEC, которое проявляется как шепот, что «нельзя говорить о MLS» и «Нет такой вещи, как MLS». Эти схемы отказа MLS меняются так быстро, что их невозможно устранить. Вместо этого важно прояснить различие между MLS-средой и MLS-совместимой.
Первоначальное использование термина MLS относилось к среде безопасности или режиму. Одним из решений этой путаницы является сохранение исходного определения MLS и конкретизация возможности MLS при использовании этого контекста.
Несколько независимых уровней безопасности (MILS) - это архитектура, которая обращается к компоненту разделения доменов MLS. Обратите внимание, что UCDMO (правительство США, возглавляющее междоменные и многоуровневые системы) ввело термин « междоменный доступ» в качестве категории в своей базовой линиисистем, аккредитованных Министерством обороны и разведывательным сообществом, и эту категорию можно рассматривать как по существу аналог MILS.
Модели безопасности, такие как модель Биба (для целостности) и модель Белла – ЛаПадула (для конфиденциальности), допускают односторонний поток между определенными доменами безопасности, которые в противном случае считаются изолированными. MILS направлен на изоляцию, лежащую в основе MLS, без обращения к управляемому взаимодействию между доменами, на которые обращаются вышеуказанные модели. Упомянутые выше доверенные каналы, отвечающие требованиям безопасности, могут связывать домены MILS для поддержки дополнительных функций MLS.
Подход MILS реализует стратегию, характеризуемую более старым термином MSL ( несколько одноуровневых), который изолирует каждый уровень информации в своей собственной одноуровневой среде ( System High ).
Жесткая коммуникация и изоляция процессов, предлагаемые MILS, могут быть более полезны для программных приложений сверхвысокой надежности, чем MLS. В частности, MILS не обращается к иерархической структуре, воплощенной в понятии уровней безопасности. Это требует добавления определенных приложений импорта / экспорта между доменами, каждый из которых требует соответствующей аккредитации. Таким образом, MILS можно было бы лучше назвать несколькими независимыми доменами безопасности (для эмуляции MLS на MILS потребуется аналогичный набор аккредитованных приложений для приложений MLS). Отказавшись от решения нестандартного взаимодействия между уровнями, согласующегося с иерархическими отношениями Bell-La Padula, MILS (почти обманчиво) прост в реализации на начальном этапе, но требует нетривиальных дополнительных приложений импорта / экспорта для достижения богатства и гибкости, ожидаемых практическое применение MLS.
При любом сравнении MILS / MLS следует учитывать, является ли аккредитация набора более простых экспортных приложений более достижимой, чем аккредитация одного, более сложного ядра MLS. Этот вопрос частично зависит от степени взаимодействия импорта / экспорта, которое требуется заинтересованным сторонам. В пользу MILS - возможность того, что не для всех экспортных приложений потребуется максимальная гарантия.
Есть еще один способ решения таких задач - многоуровневый. Каждый уровень безопасности изолирован в отдельном ненадежном домене. Отсутствие средства связи между доменами гарантирует невозможность взаимодействия. Механизм этой изоляции обычно заключается в физическом разделении на отдельные компьютеры. Это часто используется для поддержки приложений или операционных систем, которые не могут поддерживать MLS, например Microsoft Windows.
Инфраструктура, такая как доверенные операционные системы, является важным компонентом систем MLS, но для того, чтобы соответствовать критериям, требуемым в соответствии с определением MLS в CNSSI 4009 (перефразировано в начале этой статьи), система должна предоставлять пользовательский интерфейс, способный позволяя пользователю получать доступ и обрабатывать контент на нескольких уровнях классификации из одной системы. UCDMO запустил трек, специально посвященный MLS на Симпозиуме NSA по обеспечению информации в 2009 году, в котором он выделил несколько аккредитованных (в производстве) и новых систем MLS. Обратите внимание на использование MLS в SELinux.
Есть несколько баз данных, классифицируемых как системы MLS. У Oracle есть продукт под названием Oracle Label Security (OLS), который реализует обязательный контроль доступа - обычно путем добавления столбца «метка» в каждую таблицу в базе данных Oracle. OLS развертывается в INSCOM армии США в качестве основы для разведывательной базы данных из всех источников, охватывающей сети JWICS и SIPRNet. Существует проект по созданию помеченной версии PostgreSQL, а также есть более старые реализации помеченных баз данных, такие как Trusted Rubix. Эти системы баз данных MLS обеспечивают единую внутреннюю систему для контента, охватывающего несколько ярлыков, но они не решают проблему, связанную с тем, что пользователи обрабатывают контент на нескольких уровнях безопасности в одной системе, обеспечивая при этом обязательный контроль доступа.
Есть также несколько приложений для конечных пользователей MLS. Другая возможность MLS, которая в настоящее время находится в базовой версии UCDMO, называется MLChat, и это чат-сервер, работающий в операционной системе XTS-400 - он был создан Лабораторией военно-морских исследований США. Учитывая, что контент от пользователей из разных доменов проходит через сервер MLChat, для защиты секретного контента используется сканирование грязных слов, и были некоторые споры о том, действительно ли это система MLS или, скорее, форма защиты данных при передаче между доменами.. Обязательный контроль доступа поддерживается комбинацией XTS-400 и механизмов, специфичных для приложений.
Объединенный междоменный обмен (JCDX) - еще один пример возможности MLS, которая в настоящее время находится на базовом уровне UCDMO. JCDX - единственная аккредитованная Министерством обороны (DoD), Управлением военной разведки (DIA) многоуровневая система безопасности (MLS) для командования, управления, связи, компьютеров и разведки (C4I), которая обеспечивает поддержку разведки и предупреждения в режиме реального времени на театре военных действий и в будущем. развернуты тактические командиры. Архитектура JCDX полностью интегрирована с защищенной операционной системой с высоким уровнем защиты 4 (PL4), использующей маркировку данных для распространения информации о силовых действиях и потенциальных террористических угрозах в Мировом океане и вокруг них в режиме, близком к реальному времени. Он установлен в местах в США и странах-партнерах, где он может предоставлять данные от Top Secret / SCI до уровней Secret-Releasable, и все это на единой платформе.
Приложения MLS, которые в настоящее время не входят в базовый план UCDMO, включают несколько приложений от BlueSpace. BlueSpace имеет несколько приложений MLS, включая почтовый клиент MLS, поисковое приложение MLS и систему MLS C2. BlueSpace использует стратегию промежуточного программного обеспечения, позволяющую своим приложениям быть платформенно-независимыми, организуя один пользовательский интерфейс для нескольких экземпляров ОС Windows ( виртуализированные или удаленные сеансы терминала ). США научно - исследовательской лаборатории ВМС также реализует многоуровневую структуру веб - приложений под названием MLWeb который интегрирует Ruby On Rails рамки с базой данных на основе многоуровневой SQLite3.
Возможно, самым большим изменением, происходящим сегодня на арене многоуровневой безопасности, является конвергенция MLS с виртуализацией. Все большее число доверенных операционных систем отказываются от маркировки файлов и процессов и вместо этого переходят на контейнеры UNIX или виртуальные машины. Примеры включают зоны в Solaris 10 TX и гипервизор с заполненными ячейками в таких системах, как платформа Integrity от Green Hill и XenClient XT от Citrix. High Assurance Platform от АНБ, как реализуется в General Dynamics " Доверенные виртуализации среды (TVE) является еще одним примером - он использует SELinux по своей сути, и может поддерживать приложения MLS, которые охватывают несколько доменов.
|journal=( помощь )|journal=( помощь )|journal=( помощь )Справочная политика SELinux [...] Многоуровневая безопасность (MLS) добавляет более совершенный метод безопасного доступа. MLS добавляет к ресурсам значение уровня безопасности.
|journal=( помощь )(также известный как TCSEC или «Оранжевая книга»).|journal=( помощь )(также известный как TNI или «Красная книга»). [1] |journal=( помощь )CS1 maint: несколько имен: список авторов ( ссылка )