Модели безопасности: Разделение уровней доступа на основе аппаратного обеспечения.

Введение

Модель компьютерной безопасности

Многоуровневая или многоуровневая система (MSL) – это способ разделения различных уровней данных посредством использования отдельных компьютеров или виртуальных машин для каждого уровня. Она призвана обеспечить некоторые преимущества многоуровневой безопасности без необходимости внесения специальных изменений в операционную систему или приложения, но с затратами на дополнительное оборудование. Стремление к разработке операционных систем MLS было серьезно заторможено резким снижением стоимости обработки данных в начале 1990-х годов. До появления персональных компьютеров пользователи, которым требовалась обработка конфиденциальной информации, должны были либо тратить значительные средства на выделенный компьютер, либо использовать компьютер с установленной операционной системой MLS. Однако в течение 1990-х годов многие организации в оборонной и разведывательной сферах воспользовались снижением стоимости вычислительной техники для развертывания персональных систем, классифицированных для работы только на самом высоком уровне секретности, используемом в их организации. Эти персональные компьютеры работали в режиме "system high" и были подключены к локальным сетям, передающим трафик на том же уровне секретности, что и сами компьютеры. Такие реализации MSL изящно избегали сложностей MLS, но обменивали техническую простоту на неэффективное использование ресурсов. Поскольку большинству пользователей в классифицированных средах также требовались неклассифицированные системы, пользователи часто имели как минимум два компьютера, а иногда и больше (один для неклассифицированной обработки и один для каждого уровня секретности). Кроме того, каждый компьютер был подключен к своей собственной локальной сети соответствующего уровня секретности, что подразумевало использование нескольких отдельных кабельных систем (с существенными затратами на установку и обслуживание).

Пределы MSL по сравнению с MLS

Очевидный недостаток MSL (по сравнению с MLS) заключается в том, что он не поддерживает смешивание различных уровней классификации каким-либо образом. Например, возможность объединения потока данных с уровнем SECRET (полученного из файла SECRET) с потоком данных с уровнем TOP SECRET (прочитанного из файла TOP SECRET) и направления результирующего потока данных TOP SECRET в файл TOP SECRET не поддерживается. По сути, систему MSL можно рассматривать как набор параллельных (и совместно расположенных) компьютерных систем, каждая из которых ограничена работой только на одном уровне безопасности. Фактически, отдельные операционные системы MSL могут даже не понимать концепцию уровней безопасности, поскольку они функционируют как системы единого уровня. Например, хотя одна из совместно расположенных ОС MSL может быть настроена на добавление строковой метки "SECRET" ко всем выходным данным, эта ОС не имеет представления о том, как чувствительность и критичность этих данных соотносятся с данными, обрабатываемыми ее аналогом, который добавляет метку "UNCLASSIFIED" ко всем своим выходным данным. Работа с двумя или более уровнями безопасности, следовательно, требует использования методов, выходящих за рамки возможностей самих "операционных систем" MSL и нуждающихся в участии человека, называемом "ручной проверкой". Например, может быть предоставлен независимый монитор (не в понимании Бринча Хансена) для поддержки переноса данных между несколькими MSL-узлами (например, копирования файла данных из узла UNCLASSIFIED в узел SECRET). Хотя каких-либо строгих требований, установленных федеральным законодательством, касательно этой проблемы не существует, было бы целесообразно, чтобы такой монитор был небольшим, специализированным и поддерживал лишь ограниченное количество строго определенных операций, таких как импорт и экспорт файлов, настройка выходных меток и другие задачи обслуживания/администрирования, требующие обработки всех совместно расположенных MSL-узлов как единого целого, а не как отдельных систем единого уровня. Также может быть целесообразно использовать архитектуру гипервизора, например VMware, для предоставления набора MSL "ОС" в виде отдельных виртуализированных сред, поддерживаемых базовой ОС, доступ к которой разрешен только администраторам, имеющим допуск ко всем данным, управляемым любым из узлов. С точки зрения пользователей, каждый узел должен представлять сеанс входа в систему или X-дисплей-менеджера, логически неотличимый от пользовательской среды базовой "системы обслуживания".

The obvious shortcoming of MSL (as compared to MLS) is that it does not support immixture of various classification levels in any manner. For example, the notion of concatenating a SECRET data stream (taken from a SECRET file) with a TOP SECRET data stream (read from a TOP SECRET file) and directing the resultant TOP SECRET data stream into a TOP SECRET file is unsupported. In essence, an MSL system can be thought of as a set of parallel (and collocated) computer systems, each restricted to operation at one, and only one, security level. Indeed, the individual MSL operating systems may not even understand the concept of security levels, since they operate as single level systems. For example, while one of a set of collocated MSL OS may be configured to affix the character string "SECRET" to all output, that OS has no understanding of how the data compares in sensitivity and criticality to the data processed by its peer OS that affixes the string "UNCLASSIFIED" to all of its output. Operating across two or more security levels then, must use methods extraneous to the purview of the MSL "operating systems" per se, and needing human intervention, termed "manual review". For example, an independent monitor (not in Brinch Hansen's sense of the term) may be provided to support migration of data among multiple MSL peers (e. g., copying a data file from the UNCLASSIFIED peer to the SECRET peer). Although no strict requirements by way of federal legislation specifically address the concern, it would be appropriate for such a monitor to be quite small, purpose built, and supportive of only a small number of very rigidly defined operations, such as importing and exporting files, configuring output labels, and other maintenance/administration tasks that require handling all the collocated MSL peers as a unit rather than as individual, single level systems. It may also be appropriate to utilize a hypervisor software architecture, such as VMware, to provide a set of peer MSL "OS" in the form of distinct, virtualized environments supported by an underlying OS that is only accessible to administrators cleared for all of the data managed by any of the peers. From the users' perspectives, each peer would present a login or X display manager session logically indistinguishable from the underlying "maintenance OS" user environment.

Прогресс в области МСЛ

Затраты и сложность, связанные с поддержанием отдельных сетей для каждого уровня классификации, побудили Агентство национальной безопасности (АНБ) начать исследования в области сохранения концепции MSL – выделенных систем высокого уровня – при одновременном сокращении физических затрат, необходимых для нескольких сетей и компьютеров. Обработка по периодам стала первым шагом в этом направлении, установив протоколы, позволяющие организациям подключать компьютер к сети с определенным уровнем доступа, обрабатывать информацию, очищать систему и подключать ее к другой сети с другим уровнем доступа. Модель обработки по периодам обещала использование одного компьютера, но не решала проблему множества кабельных сетей и оказалась крайне неудобной для пользователей, что ограничило ее распространение. В 1990-х годах развитие технологий виртуализации изменило ситуацию для систем MSL. Внезапно появилась возможность создавать виртуальные машины (ВМ), которые функционировали как независимые компьютеры, но работали на общей аппаратной платформе. Благодаря виртуализации АНБ увидело возможность реализовать обработку по периодам на виртуальном уровне, устранив необходимость физической очистки системы путем выполнения всей обработки в выделенных ВМ высокого уровня. Однако для реализации MSL в виртуальной среде необходимо было найти способ безопасного управления виртуальным менеджером сеансов и обеспечить, чтобы любые компрометирующие действия, направленные на одну ВМ, не могли скомпрометировать другую.

Философские аспекты, простота использования, гибкость

Интересно рассмотреть философские последствия "пути решения" MSL. Вместо предоставления возможностей MLS в классической ОС, выбранное направление заключается в создании набора "виртуальных ОС" компонентов, которые могут управляться, как по отдельности, так и коллективно, базовой реальной ОС. Если основная ОС (введем термин – операционная система обслуживания, или MOS) должна обладать достаточным пониманием семантики MLS для предотвращения серьезных ошибок, таких как копирование данных из MSL-компонента с уровнем TOP SECRET в MSL-компонент с уровнем UNCLASSIFIED, то MOS должна иметь возможность: представлять метки; связывать метки с сущностями (здесь мы строго избегаем терминов "субъект" и "объект"); сравнивать метки (строго избегая термина "референсный монитор"); различать контексты, в которых метки имеют смысл, и те, в которых они не имеют смысла (строго избегая термина "доверенная вычислительная база" [TCB]); список можно продолжать. Легко заметить, что проблемы архитектуры и проектирования MLS не были устранены, а лишь перенесены на отдельный уровень программного обеспечения, которое невидимо управляет принудительным контролем доступа, освобождая верхние уровни от этой задачи. Эта концепция – не что иное, как архитектурная концепция двойственности (взятая из отчета Андерсона), лежащая в основе доверенных систем в стиле Министерства обороны. Положительным достижением набора абстракций MSL-компонентов стало радикальное ограничение области применения программных механизмов, осведомленных о MAC, до небольшого, лежащего в основе MOS. Однако это было достигнуто ценой утраты любых практических возможностей MLS, даже самых элементарных, например, когда пользователь с допуском SECRET добавляет неклассифицированный абзац, взятый из неклассифицированного файла, в свой отчет SECRET. Реализация MSL, очевидно, потребует репликации каждого "многократно используемого" ресурса (в данном примере, файла UNCLASSIFIED) во всех MSL-компонентах, которым он может быть полезен, что приведет либо к избыточному расходу памяти, либо к непосильной нагрузке на администратора, способного выполнять такую репликацию по запросу пользователей. (Разумеется, поскольку пользователь с допуском SECRET не может "просматривать" неклассифицированные ресурсы системы, кроме как путем выхода из системы и повторного входа в систему с уровнем UNCLASSIFIED, это свидетельствует о еще одном серьезном ограничении функциональности и гибкости.) В качестве альтернативы, менее конфиденциальные файловые системы можно смонтировать через NFS в режиме "только для чтения", чтобы более надежные пользователи могли просматривать их содержимое, но не изменять его. Однако MSL-компонент ОС не будет иметь фактических средств для определения (например, с помощью команды просмотра каталога), что ресурсы NFS находятся на другом уровне конфиденциальности, чем локальные ресурсы, и не будет надежных средств для предотвращения несанкционированного потока конфиденциальной информации, кроме примитивного механизма "все или ничего" – монтирования NFS в режиме "только для чтения". Чтобы продемонстрировать, насколько серьезным препятствием является такое радикальное применение "совместного использования файлов между уровнями", рассмотрим систему MLS, поддерживающую данные UNCLASSIFIED, SECRET и TOP SECRET, и пользователя с допуском TOP SECRET, вошедшего в систему на этом уровне. Структуры каталогов MLS построены на принципе сдерживания, который, в общих чертах, предписывает, что более высокие уровни конфиденциальности находятся глубже в дереве: обычно уровень каталога должен соответствовать или доминировать над уровнем его родительского каталога, а уровень файла (точнее, любой ссылки на него) должен соответствовать уровню каталога, в котором он каталогизирован. (Это строго верно для MLS UNIX: альтернативы, поддерживающие различные концепции каталогов, записей каталогов, i-узлов и т. д. – такие как Multics, добавляющая абстракцию "ветви" к парадигме каталогов – допускают более широкий набор альтернативных реализаций.) Ортогональные механизмы предусмотрены для общедоступных и временных каталогов, таких как /tmp или C:\TEMP, которые автоматически и невидимо разделяются ОС, а запросы пользователей на доступ к файлам автоматически "перенаправляются" в соответствующий раздел каталога с соответствующей меткой. Пользователь TOP SECRET может свободно просматривать всю систему, его единственное ограничение заключается в том, что во время входа в систему на этом уровне ему разрешено создавать новые файлы TOP SECRET только в определенных каталогах или их подкаталогах. В альтернативе MSL, где любое просматриваемое содержимое должно быть конкретно и кропотливо реплицировано во все применимые уровни полностью проверенным администратором – то есть, в данном случае, все данные SECRET должны быть реплицированы в MSL-компонент ОС TOP SECRET, а все данные UNCLASSIFIED – в компоненты SECRET и TOP SECRET – легко понять, что чем выше допуск пользователя, тем более разочаровывающим будет его опыт совместного использования вычислительных ресурсов. В классическом теоретическом смысле доверенных систем – опираясь на терминологию и концепции, взятые из "Оранжевой книги", основы доверенных вычислений – система, поддерживающая MSL-компоненты, не может достичь уровня заверения выше (B1). Это связано с тем, что критерии (B2) требуют, среди прочего, как четкого определения периметра TCB, так и существования единого, идентифицируемого органа, обладающего полномочиями и правом решать вопросы доступа ко всем данным, представленным во всех доступных ресурсах ADP-системы. В очень реальном смысле применение термина "высокая надежность" в качестве описателя реализаций MSL бессмысленно, поскольку термин "высокая надежность" правильно относится к системам уровней (B3) и (A1) – и, с некоторой снисходительностью, к системам уровня (B2).

It is interesting to consider the philosophical implications of the MSL "solution path." Rather than providing MLS abilities within a classical OS, the chosen direction is to build a set of "virtual OS" peers that can be managed, individually and as a collective, by an underlying real OS. If the underlying OS (let us introduce the term maintenance operating system, or MOS) is to have sufficient understanding of MLS semantics to prevent grievous errors, such as copying data from a TOP SECRET MSL peer to an UNCLASSIFIED MSL peer, then the MOS must have the ability to: represent labels; associate labels with entities (here we rigorously avoid the terms "subject" and "object"); compare labels (rigorously avoiding the term "reference monitor"); distinguish between those contexts where labels are meaningful and those where they are not (rigorously avoiding the term "trusted computing base" [TCB]); the list goes on. One readily perceives that the MLS architecture and design issues have not been eliminated, merely deferred to a separate stratum of software that invisibly manages mandatory access control concerns so that superjacent strata need not. This concept is none other than the geminal architectural concept (taken from the Anderson Report) underlying DoD style trusted systems in the first place. What has been positively achieved by the set of MSL peers abstraction, albeit, is radical restriction of the scope of MAC cognizant software mechanisms to the small, subjacent MOS. This has been accomplished, however, at the cost of eliminating any practical MLS abilities, even the most elementary ones, as when a SECRET cleared user appends an UNCLASSIFIED paragraph, taken from an UNCLASSIFIED file, to his SECRET report. The MSL implementation would obviously require every "reusable" resource (in this example, the UNCLASSIFIED file) to be replicated across every MSL peer that might find it useful—meaning either much secondary storage needlessly expended or intolerable burden on the cleared administrator able to effect such replications in response to users' requests therefor. (Of course, since the SECRET user cannot "browse" the system's UNCLASSIFIED offerings other than by logging out and beginning an UNCLASSIFIED system afresh, one evidences yet another severe limitation on functionality and flexibility.) Alternatively, less sensitive file systems could be NFS mounted read only so that more trustworthy users could browse, but not modify, their content. Albeit, the MLS OS peer would have no actual means for distinguishing (via a directory listing command, e. g.) that the NFS mounted resources are at a different level of sensitivity than the local resources, and no strict means for preventing illegal uphill flow of sensitive information other than the brute force, all or nothing mechanism of read only NFS mounting. To demonstrate just what a handicap this drastic effectuation of "cross level file sharing" actually is, consider the case of an MLS system that supports UNCLASSIFIED, SECRET, and TOP SECRET data, and a TOP SECRET cleared user who logs into the system at that level. MLS directory structures are built around the containment principle, which, loosely speaking, dictates that higher sensitivity levels reside deeper in the tree: commonly, the level of a directory must match or dominate that of its parent, while the level of a file (more specifically, of any link thereto) must match that of the directory that catalogs it. (This is strictly true of MLS UNIX: alternatives that support different conceptions of directories, directory entries, i nodes, etc.—such as Multics, which adds the "branch" abstraction to its directory paradigm—tolerate a broader set of alternative implementations.) Orthogonal mechanisms are provided for publicly shared and spool directories, such as /tmp or C:\TEMP, which are automatically—and invisibly—partitioned by the OS, with users' file access requests automatically "deflected" to the appropriately labeled directory partition. The TOP SECRET user is free to browse the entire system, his only restriction being that—while logged in at that level—he is only allowed to create fresh TOP SECRET files within specific directories or their descendants. In the MSL alternative, where any browsable content must be specifically, laboriously replicated across all applicable levels by a fully cleared administrator—meaning, in this case, that all SECRET data must be replicated to the TOP SECRET MSL peer OS, while all UNCLASSIFIED data must be replicated to both the SECRET and TOP SECRET peers—one can readily perceive that, the more highly cleared the user, the more frustrating his timesharing computing experience will be. In a classical trusted systems theoretic sense—relying upon terminology and concepts taken from the Orange Book, the foundation of trusted computing—a system that supports MSL peers could not achieve a level of assurance beyond (B1). This is because the (B2) criteria require, among other things, both clear identification of a TCB perimeter and the existence of a single, identifiable entity that has the ability and authority to adjudicate access to all data represented throughout all accessible resources of the ADP system. In a very real sense, then, the application of the term "high assurance" as a descriptor of MSL implementations is nonsensical, since the term "high assurance" is properly limited to (B3) and (A1) systems—and, with some laxity albeit, to (B2) systems.

Межобластные решения

Системы MSL, будь то виртуальные или физические, предназначены для обеспечения изоляции между различными уровнями классификации. Следовательно, (в отличие от систем MLS), среда MSL не обладает встроенными возможностями для перемещения данных с одного уровня на другой. Для обеспечения обмена данными между компьютерами, работающими на разных уровнях классификации, на таких объектах развертываются кросс-доменные решения (CDS), которые обычно называют шлюзами или охранниками. Охранники, которые часто сами используют технологии MLS, фильтруют трафик, проходящий между сетями; однако, в отличие от коммерческого интернет-файрвола, охранник строится с соблюдением гораздо более строгих требований к надежности, а его фильтрация тщательно разрабатывается для предотвращения любой несанкционированной утечки секретной информации между локальными сетями, работающими на разных уровнях безопасности. Технологии односторонней передачи данных широко используются там, где требуется ограничить потоки данных одним направлением между уровнями, с высокой степенью уверенности в том, что данные не будут передаваться в обратном направлении. В целом, они подвержены тем же ограничениям, которые создавали проблемы для других решений MLS: строгая оценка безопасности и необходимость предоставления электронного эквивалента заявленной политики для перемещения информации между классификациями. (Перемещение информации на более низкий уровень классификации особенно сложно и обычно требует одобрения нескольких лиц.) По состоянию на конец 2005 года многочисленные платформы с высокой степенью надежности и приложения-охранники были одобрены для использования в защищенных средах. Следует отметить, что термин "высокая степень надежности", используемый здесь, следует оценивать в контексте DCID 6/3 (читайте "dee skid six three") – квазитехнического руководства по разработке и внедрению различных систем обработки секретной информации, лишенного как точной юридической строгости критериев "Оранжевой книги", так и фундаментальной математической обоснованности. ("Оранжевая книга" основана на и вытекает из логической "цепочки рассуждений", построенной следующим образом: [a] "безопасное" состояние математически определено и построена математическая модель, операции в которой сохраняют безопасное состояние, так что любая мыслимая последовательность операций, начинающаяся с безопасного состояния, приводит к безопасному состоянию; [b] отображение тщательно отобранных примитивов в последовательности операций на модели; и [c] "описательная спецификация верхнего уровня", которая отображает действия, которые могут быть выполнены в пользовательском интерфейсе (например, системные вызовы) в последовательности примитивов; но не доходит до [d] формального доказательства того, что живая программная реализация правильно реализует указанные последовательности действий; или [e] формального утверждения о том, что исполняемая, теперь "доверенная" система генерируется корректными и надежными инструментами [например, компиляторами, библиотекарями, компоновщиками].)

MSL systems, whether virtual or physical in nature, are designed to preserve isolation between different classification levels. Consequently, (unlike MLS systems), an MSL environment has no innate abilities to move data from one level to another. To permit data sharing between computers working at different classification levels, such sites deploy cross domain solutions (CDS), which are commonly referred to as gatekeepers or guards. Guards, which often leverage MLS technologies themselves, filter traffic flowing between networks; unlike a commercial Internet firewall, however, a guard is built to much more stringent assurance requirements and its filtering is carefully designed to try to prevent any improper leakage of classified information between LANs operating at different security levels. Data diode technologies are used extensively where data flows are required to be restricted to one direction between levels, with a high level of assurance that data will not flow in the opposite direction. In general, these are subject to the same restrictions that have imposed challenges on other MLS solutions: strict security assessment and the need to provide an electronic equivalent of stated policy for moving information between classifications. (Moving information down in classification level is particularly challenging and typically requires approval from several different people.) As of late 2005, numerous high assurance platforms and guard applications have been approved for use in classified environments. N. b. that the term "high assurance" as employed here is to be evaluated in the context of DCID 6/3 (read "dee skid six three"), a quasi technical guide to the construction and deployment of various systems for processing classified information, lacking both the precise legal rigidity of the Orange Book criteria and the underlying mathematical rigor. (The Orange Book is motivated by, and derived from, a logical "chain of reasoning" constructed as follows: [a] a "secure" state is mathematically defined, and a mathematical model is constructed, the operations upon which preserve secure state so that any conceivable sequence of operations starting from a secure state yields a secure state; [b] a mapping of judiciously chosen primitives to sequences of operations upon the model; and [c] a "descriptive top level specification" that maps actions that can be transacted at the user interface (such as system calls) into sequences of primitives; but stopping short of either [d] formally demonstrating that a live software implementation correctly implements said sequences of actions; or [e] formally arguing that the executable, now "trusted," system is generated by correct, reliable tools [e. g., compilers, librarians, linkers].)