Мандатное управление доступом

Для реализации этого принципа каждому субъекту и объекту должны сопоставляться классификационные метки, отражающие место данного субъекта (объекта) в соответствующей иерархии. Посредством этих меток субъектам и объектам должны назначаться классификационные уровни (уровни уязвимости, категории секретности и т.п.), являющиеся комбинациями иерархических и неиерархических категорий. Данные метки должны служить основой мандатного принципа разграничения доступа. КСЗ при вводе новых данных в систему должен запрашивать и получать от санкционированного пользователя классификационные метки этих данных. При санкционированном занесении в список пользователей нового субъекта должно осуществляться сопоставление ему классификационных меток. Внешние классификационные метки (субъектов, объектов) должны точно соответствовать внутренним меткам (внутри КСЗ).

КСЗ должен реализовывать мандатный принцип контроля доступа применительно ко всем объектам при явном и скрытом доступе со стороны любого из субъектов:

· субъект может читать объект, только если иерархическая классификация субъекта не меньше, чем иерархическая классификация объекта, и неиерархические категории субъекта включают в себя все иерархические категории объекта;

· субъект осуществляет запись в объект, только если классификационный уровень субъекта не больше, чем классификационный уровень объекта, и все иерархические категории субъекта включаются в неиерархические категории объекта.

Реализация мандатных правил разграничения доступа должна предусматривать возможности сопровождения изменения классификационных уровней субъектов и объектов специально выделенными субъектами. Должен быть реализован диспетчер доступа, то есть средство, осуществляющее перехват всех обращений субъектов к объектам, а также разграничение доступа в соответствии с заданным принципом разграничения доступа. При этом решение о санкционированности запроса на доступ должно приниматься только при одновременном его разрешении и дискреционными, и мандатными правилами разграничения доступа. Таким образом, должен контролироваться не только единичный акт доступа, но и потоки информации. Кроме того, по сравнению с АС, построенными на основе дискреционной политики безопасности, для систем, реализующих мандатную политику, характерна более высокая степень надежности. Это связано с тем, что МБО такой системы должен отслеживать, не только правила доступа субъектов системы к объектам, но и состояния самой АС. Т.о. каналы утечки в системах данного типа не заложены в нее непосредственно, а могут появиться только при практической реализации системы.

Ролевое разграничение

Основной идеей управления доступом на основе ролей является идея о связывании разрешений доступа с ролями, назначаемым каждому пользователю. Эта идея возникла одновременно с появлением многопользовательских систем. Однако до недавнего времени исследователи мало обращали внимание на этот принцип.

Ролевое разграничение доступа представляет собой развитие политики дискреционного разграничения доступа, при этом права доступа субъектов системы на объекты группируются с учетом их специфики их применения, образуя роли.

Такое разграничение доступа является составляющей многих современных компьютерных систем. Как правило, данный подход применяется в системах защиты СУБД, а отдельные элементы реализуются в сетевых операционных системах.

Задание ролей позволяет определить более четкие и понятные для пользователей компьютерной системы правила разграничения доступа. При этом такой подход часто используется в системах, для пользователей которых четко определен круг их должностных полномочий и обязанностей.

Роль является совокупностью прав доступа на объекты компьютерной системы, однако ролевое разграничение отнюдь не является частным случаем дискреционного разграничения, так как ее правила определяют порядок предоставления прав доступа субъектам компьютерной системы в зависимости от сессии его работы и от имеющихся (или отсутствующих) у него ролей в каждый момент времени, что является характерным для систем мандатного разграничения доступа. С другой стороны, правила ролевого разграничения доступа являются более гибкими, чем при мандатном подходе к разграничению.

Если подвести итог, то у каждой из перечисленных нами систем есть свои преимущества, однако ключевым является то, что ни одна из описанных моделей не стоит на месте, а динамично развивается. Приверженцы есть у каждой из них, однако, объективно посмотрев на вещи, трудно отдать предпочтение какой-то одной системе. Они просто разные и служат для разных целей.

Сравнительный анализ различных типов систем

Операционные системы.

Flask

Операционная система Flux Advanced Security Kernel, или как ее иначе называют FLASK — это архитектура безопасности операционной системы, которая обеспечивает гибкую поддержку политик безопасности. Ранее Прототип архитектуры FLASK был реализован в исследовательской операционной системе Fluke. В связи с этим, на наш взгляд, интересно будет сказать несколько слов об истории создания FLASK В 1992 и 1993 годах исследователи Агентства национальной безопасности США и Secure Computing Corporation (SCC) работали над реализацией Distributed Trusted Mach (DTMach), отпрыском проектов TMach и Lock. DTMach интегрировал генерализацию Type Enforcement (TE) — гибкого механизма доступа в микроядро. Проект DTMach позже был продолжен в проекте Distributed Trusted Operating System (DTOS). В свою очередь, после внесения усовершенствований проект DTOS дал рождение прототипу, переданному университетам для исследований. Кроме того результатом проекта DTOS стал отчёт — формальная спецификация системы, включающий в себя: анализ политик безопасности и их характеристик, научные работы о безопасности, assurability и composability techniques операционных систем, основанных на микроядре.После завершения проекта DTOS результаты его работы были использованы в другом проекте NSA, SCC и университета Юты (University of Utah) — проекте Flux, задачей которого было перенести архитектуру безопасности DTOS в исследовательскую операционную систему Fluke. В процессе интеграции архитектуры в Fluke, она была улучшена для поддержки динамических политик безопасности. Эта улучшенная архитектура была названа Flask. Некоторые интерфейсы и компоненты Flask впоследствии были перенесены из Fluke в OSKit. Конечным итогом исследований стала реализация архитектуры Flask для операционной системы Linux в SELinux, выполненной Агентством национальной безопасности США, передавшим технологию многочисленным сообществам пользователей и разработчиков. Другими основными участниками проекта SELinux являются: NAI Labs, Secure Computing Corporation и MITRE. Некоторые компоненты и интерфейсы Flask были позже портированны из прототипа Fluke в OSKit. Архитектура Flask была реализована для операционной системы Linux (Security-Enhanced Linux, SELinux) для того, чтобы передать технологию многочисленным сообществам пользователей и разработчиков. В настоящее время архитектура Flask является основой для технологий реализации систем принудительного контроля доступа, таких как Security-Enhanced Linux (SELinux), OpenSolaris FMAC и TrustedBSD. В завершение хочется еще раз отметить, что в этой операционной система первоначально была воплощена модель мандатной политики безопасности.

Unix

История операционной системы UNIX насчитывает уже более тридцати лет. UNIX используются в военных и серьёзных промышленных системах. Модель безопасности UNIX довольно проста. В основе её лежит дискреционный механизм доступа - каждый объект в системе имеет владельца, который и устанавливает права доступа к объекту. Сами пользователи в системе фигурируют в виде процессов - программ, запущенных от их имени. Так как в операционной системе UNIX даже устройства представляются в виде файлов, достаточно для каждого из них хранить владельца и права на использование этого файла другими пользователями системы. В UNIX существует три основных права доступа: чтение, запись и исполнение. Если права чтения и записи очевидны и понятны, то право исполнения трактуется по-разному для разных типов файлов. Для простых файлов оно определяет возможность запуска содержащейся в нём программы. В UNIX исполняемые файлы могут иметь не только любое расширение, но и содержимое. 

Linux

Оперционная система Linux унаследовала от UNIX традиционную модель доступа. В отличие от коммерческих систем, таких как Microsoft Windows или Mac OS X, Linux не имеет географического центра разработки. Нет и организации, которая владела бы этой системой; нет даже единого координационного центра. Программы для Linux — результат работы тысяч проектов. Некоторые из этих проектов централизованы, некоторые сосредоточены в фирмах. Многие проекты объединяют хакеров со всего света, которые знакомы только по переписке. Создать свой проект или присоединиться к уже существующему может любой и, в случае успеха, результаты работы станут известны миллионам пользователей. Пользователи принимают участие в тестировании свободных программ, общаются с разработчиками напрямую, что позволяет быстро находить и исправлять ошибки и реализовывать новые возможности. Linux является UNIX-совместимой, однако основывается на собственном исходном коде. Именно такая гибкая и динамичная система разработки, невозможная для проектов с закрытым кодом, определяет исключительную экономическую эффективность Linux. Низкая стоимость свободных разработок, отлаженные механизмы тестирования и распространения, привлечение людей из разных стран, обладающих разным видением проблем, защита кода лицензией GPL — всё это стало причиной успеха свободных программ. Конечно, такая высокая эффективность разработки не могла не заинтересовать крупные фирмы, которые стали открывать свои проекты. Так появились Mozilla (Netscape, AOL), OpenOffice.org (ORACLE), свободный клон InterBase (Borland) — Firebird, SAP DB (SAP). IBM способствовала переносу Linux на свои мейнфреймы. С другой стороны, открытый код значительно снижает себестоимость разработки закрытых систем для Linux и позволяет снизить цену решения для пользователя. Вот почему Linux стала платформой, часто рекомендуемой для таких продуктов, как СУБД Oracle, DB2, Informix, SyBase, SAP R3, Domino. Сообщество Linux поддерживает связь посредством групп пользователей Linux. В мае 2010 года семейство операционных систем на базе ядра Linux — третье по популярности в мире на рынке настольных компьютеров. Можно выделить несколько основных областей, где нередко можно встретить Linux: Серверы, требующие высокого аптайма, Компьютеры нестандартной архитектуры (например, суперкомпьютеры) — из-за возможности быстрой адаптации ядра операционной системы и большого количества ПО под нестандартную архитектуру, Системы военного назначения (например, МСВС РФ) — по соображениям безопасности , компьютеры, встроенные в различные устройства (банкоматы, терминалы оплаты, мобильные телефоны, маршрутизаторы, стиральные машины и даже беспилотные военные аппараты) — из-за широких возможностей по конфигурированию Linux под задачу, выполняемую устройством, а также отсутствия платы за каждое устройство. Используемый в ней дискреционный метод доступа предоставляет слишком широкие возможности: любая программа, запущенная от имени пользователя, обладает всеми его правами. Развитие операционных систем не стоит на месте. Немалую роль в достижении высокого уровня безопасности Linux сыграла открытость исходных текстов и принципы разработчиков, проповедующих использование только открытых стандартов. Вокруг Linux возникло множество проектов, предоставляющих расширенные возможности по управлению доступом.

SELinux

SELinux - это расширение базовой модели безопасности операционной системы Linux, добавляющее механизм мандатного доступа. С помощью SELinux можно задать явные правила того, как субъекты (пользователи и программы) могут обращаться к объектам системы (файлы и устройства). Таким образом, можно ограничить программы, прописав возможности их поведения в виде политики , а операционная система обеспечит её соблюдение. SELinux входит в официальное ядро Linux начиная с версии 2.6. Система разрабатывается Национальным агентством по безопасности США (NSA, National Security Agency) при сотрудничестве с другими исследовательскими лабораториями и коммерческими дистрибутивами Linux. Исходные тексты проекта доступны под лицензией GPL. Мандатный доступ в SELinux реализован в рамках модели домен-тип . В этой модели каждый процесс запускается в определённом домене безопасности (уровень доступа), а всем ресурсам (файлы, директории, сокеты и т.п.) ставится в соответствие определённый тип (уровень секретности). Список правил, ограничивающих возможности доступа доменов к типам, называется политикой и задаётся один раз в момент установки системы. Описание политики в SELinux - это набор текстовых файлов, которые могут быть скомпилированы и загружены в память ядра Linux при старте системы. Возможности SELinux выходят за рамки обычных задач системного администратора. В системах со строгим контролем за обрабатываемой информацией существует необходимость разработки собственной политики безопасности, полностью соответствующей требованиям предприятия. В первую очередь, речь идёт о применении SELinux в задачах военных и спецслужб.

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