Многоуровневая безопасность или множественные уровни безопасности ( MLS ) — это применение компьютерной системы для обработки информации с несовместимыми классификациями (т. е. на разных уровнях безопасности), разрешения доступа пользователям с разными допусками и потребностями в информации , а также предотвращения доступа пользователей к информации, на которую у них нет разрешения. Существует два контекста использования многоуровневой безопасности.
Это различие важно, поскольку системы, которым нужно доверять, не обязательно заслуживают доверия.
Операционная среда MLS часто требует высоконадежной системы обработки информации, часто построенной на операционной системе (ОС) MLS, но не обязательно. Большинство функций MLS может поддерживаться системой, полностью состоящей из ненадежных компьютеров, хотя для этого требуется несколько независимых компьютеров, связанных аппаратными каналами безопасности (см. раздел B.6.2 Интерпретации доверенных сетей, NCSC-TG-005). Примером аппаратно-усиленной MLS является асимметричная изоляция . [1] Если один компьютер используется в режиме MLS, то этот компьютер должен использовать доверенную операционную систему (ОС). Поскольку вся информация в среде MLS физически доступна ОС, должны существовать строгие логические элементы управления, чтобы гарантировать, что доступ к информации строго контролируется. Обычно это включает в себя обязательный контроль доступа , который использует метки безопасности, такие как модель Белла–ЛаПадулы .
Клиенты, которые развертывают доверенные операционные системы, обычно требуют, чтобы продукт прошел формальную оценку компьютерной безопасности. Оценка более строгая для более широкого диапазона безопасности, которые являются низшими и высшими уровнями классификации, которые может обрабатывать система. Критерии оценки доверенных компьютерных систем (TCSEC) были первыми критериями оценки, разработанными для оценки MLS в компьютерных системах. В рамках этих критериев существовало четкое единообразное сопоставление [2] между требованиями безопасности и широтой диапазона безопасности MLS. Исторически немногие реализации были сертифицированы как способные обрабатывать MLS с диапазоном безопасности от «Неклассифицировано» до «Совершенно секретно». Среди них были Honeywell SCOMP, USAF SACDIN, NSA Blacker и Boeing MLS LAN, все в соответствии с TCSEC, 1980-х годов и на базе Intel 80386. В настоящее время продукты MLS оцениваются в соответствии с Общими критериями . В конце 2008 года первая операционная система (подробнее ниже) была сертифицирована по высокому уровню оценки гарантий: Evaluation Assurance Level (EAL) - EAL 6+ / High Robustness, под эгидой правительственной программы США, требующей многоуровневой безопасности в среде с высокой угрозой. Хотя этот уровень гарантий имеет много общего с уровнем старой Orange Book A1 (например, формальные методы), функциональные требования сосредоточены на фундаментальной изоляции и политиках потока информации, а не на политиках более высокого уровня, таких как Bell-La Padula. Поскольку Common Criteria разделила сопряжение TCSEC гарантии (EAL) и функциональности (профиль защиты), четкое единообразное сопоставление между требованиями безопасности и возможностями диапазона безопасности MLS, задокументированное в CSC-STD-004-85, в значительной степени было утрачено, когда Common Criteria заменила Rainbow Series .
Свободно доступные операционные системы с некоторыми функциями, поддерживающими MLS, включают Linux с включенной функцией Security-Enhanced Linux и FreeBSD . [3] Оценка безопасности когда-то считалась проблемой для этих бесплатных реализаций MLS по трем причинам:
Несмотря на подобные предположения, Red Hat Enterprise Linux 5 был сертифицирован по LSPP, RBACPP и CAPP на уровне EAL4+ в июне 2007 года. [4] Он использует Security-Enhanced Linux для реализации MLS и стал первой сертификацией Common Criteria для обеспечения свойств безопасности TOE с Security-Enhanced Linux.
Стратегии сертификации поставщиков могут вводить в заблуждение неспециалистов. Распространенная стратегия использует чрезмерное внимание неспециалистов к уровню EAL с помощью чрезмерной сертификации, например, сертификации профиля защиты EAL 3 (например, CAPP) [5] до повышенных уровней, таких как 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 является основой безопасности для продукта General Dynamics Trusted Network Environment (TNE) с 2009 года. TNE обеспечивает многоуровневый обмен информацией и доступ для пользователей в сообществах Министерства обороны и разведки, работающих с различными уровнями классификации. Это также основа для многоуровневой коалиционной среды обмена, Battlefield Information Collection and Exploitation Systems Extended [6] (BICES-X).
Sun Microsystems , теперь Oracle Corporation , предлагает Solaris Trusted Extensions как интегрированную функцию коммерческих ОС Solaris и OpenSolaris . В дополнение к профилю защиты контролируемого доступа (CAPP) и профилям защиты управления доступом на основе ролей (RBAC), Trusted Extensions также были сертифицированы на уровне EAL4 для маркированного профиля защиты безопасности (LSPP). [7] Цель безопасности включает как настольную, так и сетевую функциональность. LSPP требует, чтобы пользователи не имели полномочий переопределять политики маркировки, применяемые ядром и X Window System (сервер X11). Оценка не включает анализ скрытых каналов . Поскольку эти сертификации зависят от CAPP, никакие сертификаты Common Criteria не предполагают, что этот продукт заслуживает доверия для MLS.
BAE Systems предлагает XTS-400 , коммерческую систему, которая поддерживает MLS на уровне, который поставщик называет «высокой гарантией». Предшествующие продукты (включая XTS-300) были оценены на уровне TCSEC B3, что является MLS-совместимым. XTS-400 был оценен в соответствии с Common Criteria на уровне EAL5+ по профилям защиты CAPP и LSPP. CAPP и LSPP являются профилями защиты EAL3, которые по своей сути не являются MLS-совместимыми, но цель безопасности [8] для оценки Common Criteria этого продукта содержит обогащенный набор функций безопасности, которые обеспечивают возможность MLS.
Санация является проблемной областью для систем MLS. Системы, реализующие ограничения MLS, такие как определенные моделью Белла–ЛаПадулы , разрешают совместное использование только в том случае, если это явно не нарушает ограничений безопасности. Пользователи с более низким уровнем допуска могут легко делиться своей работой с пользователями с более высоким уровнем допуска, но не наоборот. Не существует эффективного и надежного механизма, с помощью которого пользователь с уровнем допуска «Совершенно секретно» может редактировать файл «Совершенно секретно», удалять всю информацию «Совершенно секретно», а затем передавать ее пользователям с уровнем допуска «Секретно» или более низким. На практике системы MLS обходят эту проблему с помощью привилегированных функций, которые позволяют надежному пользователю обходить механизм MLS и изменять классификацию безопасности файла. Однако этот метод ненадежен .
Скрытые каналы представляют собой еще одну проблему для систем MLS. Для того чтобы система MLS идеально хранила секреты, не должно быть возможности для процесса «Совершенно секретно» передавать сигналы любого рода процессу «Секретно» или процессу более низкого уровня. Это включает в себя побочные эффекты, такие как изменения в доступной памяти или дисковом пространстве, или изменения во времени процесса. Когда процесс использует такой побочный эффект для передачи данных, он использует скрытый канал. Крайне сложно закрыть все скрытые каналы в практической вычислительной системе, и это может быть невозможно на практике. Процесс идентификации всех скрытых каналов сам по себе является сложным. Большинство коммерчески доступных систем MLS не пытаются закрыть все скрытые каналы, хотя это делает непрактичным их использование в приложениях с высокой степенью безопасности.
Обход проблематичен, когда вводится как средство для обработки системного объекта высокого уровня, как если бы он был доверенным MLS. Типичным примером является извлечение данных из секретного системного объекта высокого уровня для отправки в неклассифицированное место назначения, ссылаясь на некоторое свойство данных как на доверенное доказательство того, что он «действительно» неклассифицирован (например, «строгий» формат). Системе высокого уровня нельзя доверять сохранение каких-либо доверенных доказательств, и в результате открывается открытый путь данных без логического способа его безопасного посредничества. Обход может быть рискованным, поскольку, в отличие от скрытых каналов с узкой полосой пропускания, которые трудно эксплуатировать, обход может представлять собой большую, легко эксплуатируемую открытую утечку в системе. Обход часто возникает из-за неиспользования доверенных операционных сред для поддержания непрерывного разделения доменов безопасности на всем пути обратно к их источнику. Когда этот источник находится за пределами границ системы, может быть невозможно проверить доверенное разделение до источника. В этом случае риск обхода может быть неизбежным, если поток действительно необходим.
Типичным примером неизбежного обхода является система субъекта, которая должна принимать секретные IP-пакеты из ненадежного источника, шифровать секретные пользовательские данные, а не заголовок, и помещать результат в ненадежную сеть. Источник находится вне сферы влияния системы субъекта. Хотя источник ненадежный (например, системный высокий уровень), ему доверяют, как если бы он был MLS, потому что он предоставляет пакеты с неклассифицированными заголовками и секретными пользовательскими данными в виде открытого текста, конструкцию данных MLS. Поскольку источник ненадежный, он может быть поврежден и помещать секреты в неклассифицированный заголовок пакета. Поврежденные заголовки пакетов могут быть бессмысленными, но система субъекта не может определить это с какой-либо разумной надежностью. Пользовательские данные пакета криптографически хорошо защищены, но заголовок пакета может содержать читаемые секреты. Если поврежденные пакеты передаются в ненадежную сеть системой субъекта, они могут быть немаршрутизируемыми, но какой-то сотрудничающий поврежденный процесс в сети может перехватить пакеты и подтвердить их, и система субъекта может не обнаружить утечку. Это может быть крупная явная утечка, которую трудно обнаружить. Просмотр классифицированных пакетов с неклассифицированными заголовками как системных структур вместо структур MLS, которыми они на самом деле являются, представляет собой очень распространенную, но серьезную угрозу.
Большинство обходов можно избежать. Обход, которого можно избежать, часто возникает, когда системные архитекторы проектируют систему до того, как правильно продумать безопасность, а затем пытаются применить безопасность постфактум в качестве дополнительных функций. В этой ситуации обход, по-видимому, является единственным (легким) способом заставить систему работать. Предлагаются (и одобряются!) некоторые псевдобезопасные схемы, которые проверяют содержимое обходных данных в тщетной попытке установить, что обходные данные не содержат секретов. Это невозможно без доверия к чему-то в данных, например, к их формату, что противоречит предположению, что источник не доверяет сохранению каких-либо характеристик исходных данных. Гарантированный «безопасный обход» — это миф, как и так называемый High Assurance Guard (HAG), который прозрачно реализует обход. Риск, который они вносят, давно признан; существующие решения в конечном итоге являются процедурными, а не техническими. Нет способа узнать наверняка, сколько секретной информации изымается из наших систем путем эксплуатации обхода.
Некоторые неспециалисты проектируют безопасные вычислительные системы и приходят к выводу, что MLS не существует. Объяснением может быть то, что наблюдается снижение числа экспертов COMPUSEC [9] и термин MLS был перегружен двумя различными значениями / использованиями. Этими двумя использованиями являются: MLS как среда обработки против MLS как возможности. Убеждение, что MLS не существует, основано на убеждении, что нет продуктов, сертифицированных для работы в среде или режиме MLS, и что, следовательно, MLS как возможности не существует. Одно не подразумевает другое. Многие системы работают в среде, содержащей данные, которые имеют неравные уровни безопасности и, следовательно, являются MLS согласно теореме о промежуточном значении компьютерной безопасности (CS-IVT). [10] Последствия этой путаницы глубже. Сертифицированные NSA операционные системы, базы данных и сети MLS существуют в рабочем режиме с 1970-х годов, и продукты MLS продолжают создаваться, продаваться и развертываться.
Неспециалисты часто приходят к выводу, что признать, что система работает в среде MLS (средоцентрическое значение MLS) означает оказаться загнанным в угол, осознавая наличие проблемы без решения MLS (возможностно-центрическое значение MLS). MLS обманчиво сложен, и то, что простые решения не очевидны, не оправдывает вывода об их отсутствии. Это может привести к парализующему невежеству в отношении COMPUSEC, которое проявляется в виде шепота о том, что «нельзя говорить о MLS» и «MLS не существует». Эти схемы отрицания MLS меняются так быстро, что их невозможно решить. Вместо этого важно прояснить различие между средой MLS и возможностями MLS.
Первоначальное использование термина MLS применялось к среде безопасности или режиму. Одним из решений этой путаницы является сохранение первоначального определения MLS и указание специфичности MLS-capable при использовании этого контекста.
Несколько независимых уровней безопасности (MILS) — это архитектура, которая решает компонент разделения доменов MLS. Обратите внимание, что UCDMO (руководитель правительства США по кросс-доменным и многоуровневым системам) создал термин « кросс-доменный доступ» как категорию в своей базовой линии аккредитованных систем DoD и разведывательного сообщества , и эту категорию можно рассматривать как по сути аналог MILS.
Модели безопасности, такие как модель Biba (для целостности) и модель Bell–LaPadula (для конфиденциальности), допускают односторонний поток между определенными доменами безопасности, которые в противном случае предполагаются изолированными. MILS решает проблему изоляции, лежащую в основе MLS, не решая контролируемое взаимодействие между доменами, рассматриваемыми в вышеупомянутых моделях. Доверенные каналы безопасности, упомянутые выше, могут связывать домены MILS для поддержки большей функциональности MLS.
Подход MILS следует стратегии, характеризуемой более старым термином MSL ( multiple single level ), которая изолирует каждый уровень информации в его собственной одноуровневой среде ( System High ).
Жесткая коммуникация процессов и изоляция, предлагаемые MILS, могут быть более полезны для сверхнадежных программных приложений, чем MLS. MILS, в частности, не рассматривает иерархическую структуру, воплощенную в понятии уровней безопасности. Это требует добавления определенных приложений импорта/экспорта между доменами, каждый из которых должен быть аккредитован соответствующим образом. Таким образом, MILS можно было бы лучше назвать множественными независимыми доменами безопасности (эмуляция MLS на MILS потребовала бы аналогичного набора аккредитованных приложений для приложений MLS). Отказываясь от рассмотрения готового взаимодействия между уровнями, соответствующего иерархическим отношениям Белла-Ла Падулы, MILS (почти обманчиво) прост в реализации изначально, но требует нетривиальных дополнительных приложений импорта/экспорта для достижения богатства и гибкости, ожидаемых от практических приложений MLS.
Любое сравнение MILS/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 предоставляют единую внутреннюю систему для контента, охватывающего несколько меток, но они не решают проблему обработки пользователями контента на нескольких уровнях безопасности в одной системе при обеспечении обязательного контроля доступа.
Также есть несколько приложений MLS для конечных пользователей. Другая возможность MLS, которая в настоящее время находится на базовой линии UCDMO, называется MLChat Архивировано 17.03.2013 на Wayback Machine , и это сервер чата, работающий на операционной системе XTS-400 — он был создан Военно-морской исследовательской лабораторией США . Учитывая, что контент от пользователей из разных доменов проходит через сервер MLChat, для защиты секретного контента используется сканирование грязных слов, и были некоторые споры о том, является ли это действительно системой MLS или скорее формой защиты данных при междоменной передаче . Обязательные элементы управления доступом поддерживаются комбинацией XTS-400 и механизмов, специфичных для приложений. [12]
Joint Cross Domain eXchange (JCDX) — еще один пример возможностей MLS, которые в настоящее время находятся на базовом уровне UCDMO [ permanent dead link ] . JCDX — единственная аккредитованная Министерством обороны (DoD), Агентством военной разведки (DIA) система многоуровневой безопасности (MLS) Command, Control, Communication, Computers and Intelligence (C4I), которая обеспечивает поддержку разведки и оповещения в режиме, близком к реальному времени для тактических командиров театра военных действий и передовых баз. Архитектура JCDX полностью интегрирована с защищенной операционной системой с высоким уровнем защиты 4 (PL4), использующей маркировку данных для распространения информации о силовых действиях и потенциальных террористических угрозах на мировых океанах и вокруг них в режиме, близком к реальному времени. Она установлена в местах в Соединенных Штатах и странах-партнерах союзников, где она способна предоставлять данные от уровня «совершенно секретно/SCI» до уровня «секретно-распространяемый», все на одной платформе.
Приложения MLS, которые в настоящее время не являются частью базовой линии UCDMO, включают несколько приложений от BlueSpace . BlueSpace имеет несколько приложений MLS, включая почтовый клиент MLS, поисковое приложение MLS и систему MLS C2. BlueSpace использует стратегию промежуточного программного обеспечения, чтобы сделать свои приложения нейтральными к платформе, организуя один пользовательский интерфейс для нескольких экземпляров ОС Windows ( виртуализированные или удаленные терминальные сеансы ). Исследовательская лаборатория ВМС США также внедрила многоуровневую структуру веб-приложений под названием MLWeb, которая интегрирует структуру Ruby on Rails с многоуровневой базой данных на основе SQLite3 .
Возможно, самым большим изменением, происходящим сегодня в сфере многоуровневой безопасности, является конвергенция MLS с виртуализацией. Все большее число доверенных операционных систем отходит от маркировки файлов и процессов и вместо этого переходит к контейнерам UNIX или виртуальным машинам . Примерами служат зоны в Solaris 10 TX и гипервизор padded cell в таких системах, как платформа Integrity компании Green Hill и XenClient XT от Citrix. Еще одним примером является High Assurance Platform от NSA , реализованная в среде Trusted Virtualization Environment (TVE) компании General Dynamics — она использует SELinux в своей основе и может поддерживать приложения MLS, охватывающие несколько доменов.
{{cite journal}}: Цитировать журнал требует |journal=( помощь ){{cite journal}}: Цитировать журнал требует |journal=( помощь ){{cite journal}}: Цитировать журнал требует |journal=( помощь )Справочная политика SELinux [...] Многоуровневая безопасность (MLS) добавляет более совершенный метод безопасного доступа. MLS добавляет значение уровня безопасности к ресурсам.
{{cite journal}}: Cite journal required |journal=( помощь ) (также известный как TCSEC или «Оранжевая книга»).{{cite journal}}: Cite journal required |journal=( помощь ) (также известная как TNI или «Красная книга»). [1]{{cite journal}}: Цитировать журнал требует |journal=( помощь )CS1 maint: multiple names: authors list (link)