Вы находитесь в разделе Типовых решений систем безопасности
Вопросы и способы реализации полномочного ,мандатного, механизма контроля доступа к резервамДанную статью посвятим рассмотрению вопросов и способов реализации полномочного (мандатного) механизма контроля доступа к ресурсам добавочными средствами защиты от несанкционированного доступа (СЗИ НСД). Актуальность подобного исследования, на наш взгляд, обусловливается следующими тремя причинами. Во-первых, полномочный (мандатный) механизм контроля доступа к ресурсам по своей сути (обработка информации различных уровней конфиденциальности) предполагает использование на критичных объектах, к которым выставляются повышенные требования к защите информации от НСД. Во-вторых, данный механизм не реализуется большинством ОС, поэтому, как правило, его реализация возлагается на добавочные средства защиты. В-третьих, именно с реализацией данного механизма связано наибольшее количество вопросов, которые, на наш взгляд, отнюдь не всегда обоснованно решаются разработчиками добавочных СЗИ НСД. Приступая к нашему исследованию, прежде всего, уточним, что полномочный и мандатный принципы контроля доступа в общем случае это принципиально различные понятия (хотя подчас, они и воспринимаются, как синонимы). Полномочный принцип состоит в реализации определенного подхода к назначению прав доступа субъектов (пользователей) к объектам (защищаемым ресурсам). Основу данного подхода (условие его применения) составляет введение иерархии (реализованной на каких-либо принципах) объектов и субъектов доступа и полномочий на право доступа в рамках составленной иерархии. Наиболее типичным решением является введение иерархии объектов доступа на основании уровня конфиденциальности (общедоступно, для служебного использования, секретно и т.д.) хранящихся в них документов (по своей сути – на основании грифа документа), и иерархии субъектов доступа на основании их служебных обязанностей и формализованного (подтверждаемого соответствующим документом, определяющим права и обязанности субъекта) права («формы») допуска к конфиденциальным данным (например, третья, вторая и др. формы допуска). Введенная иерархия субъектов и объектов доступа позволяет ввести полномочия (формализовать права) доступа к ресурсам, например, пользователь с третьей формой допуска может обладать доступом к открытым и конфиденциальным данным, со второй формой в дополнение - к секретным данным и т.д. Т.е. полномочный принцип, являясь основой любого делопроизводства, в данном случае переносится в область компьютерной обработки информации. Попытаемся проиллюстрировать сказанное с использованием некой матрицы доступа субъектов к объектам, отображающей полномочное задание прав доступа. Введем следующие обозначения. Пусть множества С = {С1,…, Ск} и О = {О1,…, Оk} – соответственно линейно упорядоченные множества субъектов и объектов доступа. В качестве субъекта доступа Сi, i = 1,…,k рассматривается как отдельный субъект, так и группа субъектов, обладающих одинаковыми правами доступа, соответственно, в качестве объекта доступа Оi, i = 1,…,k может также рассматриваться как отдельный объект, так и группа объектов, характеризуемых одинаковыми к ним правами доступа. Введем следующую иерархию субъектов и объектов доступа: чем меньше порядковый номер j объекта, тем более высокой категории конфиденциальности документы в нем могут храниться, соответственно, чем меньше порядковый номер i субъекта, тем большими правами доступа к информации он обладает. Пусть S = {0,”Зп/Чт»,«Чт»} – множество прав доступа, где «0» обозначает отсутствие доступа субъекта к объекту, «Зп/Чт» – разрешение полного доступа «Чт» – разрешение доступа только на чтение. Тогда полномочную модель управления доступом к ресурсам можно представить матрицей доступа D, имеющей следующий вид:  Модель управления доступом формально может быть описана следующим образом - элемент (Dij) матрицы доступа D назначается следующим образом: Dij = Зп/Чт, если i = j; Dij = Чт, если i > j; Dij = 0, если i < j, где i - порядковый номер объекта (номер строки в матрице доступа), j - порядковый номер субъекта (номер столбца в матрице доступа). Видим, что данные, соответствующие полномочной модели управления доступом к ресурсам, правила разграничения доступа (ПРД) могут быть реализованы с использованием механизма избирательного (дискреционного) контроля доступа к ресурсам (при условии, что им реализуется индуктивная модель безопасности – этот вопрос рассматривался в третьей части работы). Тогда возникает вопрос – а что же такое мандатный механизм контроля доступа к ресурсам? Основу мандатного механизма составляет включение в схему управления доступом к ресурсам, так называемых, меток безопасности (иерархических, так как в системе реализуется иерархия полномочий), отображающих полномочия субъектов и объектов, при этом ПРД субъектов к объектам полностью определяются метками безопасности и правилами их обработки. Метки безопасности являются элементами линейно упорядоченного множества M = {M1,…, Mk} служат для формализованного представления их уровня полномочий. Будем считать, что чем выше полномочия субъекта и категория конфиденциальности объекта (меньше их порядковый номер в линейно полномочно упорядоченных множествах субъектов и объектов - С = {С1,…, Ск} и О = {О1,…, Оk}), тем меньшее значение метки безопасности Mi, i = 1, …, k им присваивается, т.е.: M1 < M2 < M3<… Таким образом, в качестве учетной информации субъектов и объектов доступа, кроме их идентификаторов – имен, каждому субъекту и объекту задаются метки безопасности из множества M. Разграничение доступа реализуется на основе правил, определяющих отношение линейного порядка на множестве M, где для любой пары элементов из множества M, задается один из типов отношения : {>,<,=} (на практике реализуется выбор подмножества M, изоморфного конечному подмножеству натуральных чисел – такой выбор делает естественным арифметическое сравнение меток безопасности). Рассмотрим правила разграничения доступа для полномочной модели управления доступом D, представленной выше. При этом введем следующие обозначения:
Тогда правила обработки меток безопасности состоят в следующем:
Так что же такое принципы полномочного и мандатного контроля доступа к ресурсам? Из сказанного ранее видим, что мандатный контроль доступа формализует способ назначения и обработки ПРД (в конечном счете – задает правила реализации диспетчера доступа к ресурсам) на основе меток безопасности, в то время, как принцип полномочного контроля доступа состоит в назначении прав доступа на основе введения иерархии объектов и субъектов доступа, и полномочий на право доступа в рамках составленной иерархии. Таким образом, мандатный механизм контроля доступа – это один из возможных способов реализации принципов полномочного управления доступом к ресурсам. Назначением же мандатного механизма является упрощение администрирования системы защиты, как следствие, снижение вероятности понижения уровня конфиденциальности документа в процессе его обработки на компьютере. Принципиальный вывод, который мы можем сделать на основании сказанного, состоит в том, что мандатный механизм контроля доступа к ресурсам – это самостоятельный механизм, реализующий собственным диспетчером доступа принципы полномочного управления доступом к ресурсам, формализующий способы задания и обработки ПРД на основе меток безопасности. В порядке замечания отметим, что это весьма важное заключение, позволяющее сделать вывод о наличии в СЗИ НСД мандатного механизма контроля доступа к ресурсам. Дело в том, что некоторыми разработчиками СЗИ НСД принципы мандатного контроля доступа к ресурсам трактуются весьма своеобразно, что приводит к попыткам каким-либо образом задать ПРД метками безопасности, а их обработку осуществлять дискреционным механизмом контроля доступа к ресурсам (заметим, что диспетчером доступа при этом реализуются принципы дискреционного управления доступом к ресурсам). Однако отметим, что анализировать, в какой СЗИ НСД каким образом реализуются принципы полномочного контроля доступа к ресурсам, не являлось целью настоящей работы (при желании потребитель СЗИ НСД без труда это может сделать самостоятельно – достаточно внимательно прочитать и проанализировать документацию на систему защиты). Вместе с тем, сам факт появления подобных технических решений отчасти иллюстрирует, что вопросы реализации мандатного механизма контроля доступа не столь тривиальны и требуют исследования, чем мы и займемся в работе. Прежде, чем перейти к рассмотрению вопросов реализации мандатного механизма контроля доступа к ресурсам, остановимся еще на одном важном моменте – ответим на вопрос: самодостаточен ли этот механизм, а если нет, то в чем? Основу принципа полномочного контроля доступа к ресурсам, как отмечалось, составляет назначение прав доступа субъектов к объектам на основе их полномочий. Однако в общем случае одновременно несколько пользователей могут обладать одинаковыми полномочиями, учитываемыми при назначении прав доступа, например, несколько пользователей имеют одинаковую форму допуска для работы с документами (при задании ПРД метками безопасности, им должна присваиваться одна метка, как следствие, эти пользователи должны иметь одинаковые права доступа, т.е. они могут работать с одними и теми же документами). Однако права доступа пользователей к документам могут различаться. Таким образом, использование принципа полномочного контроля доступа предполагает в дополнение к мандатному (а не наоборот, что часто имеем на практике) реализацию дискреционного (избирательного) механизма контроля доступа, в задачи которого входит разграничение доступа между субъектами, обладающими равными полномочиями, соответственно, к объектам одного уровня конфиденциальности (применительно к мандатному механизму – между субъектами, которым установлена одна метка безопасности, соответственно, к объектам, которым присвоена одна метка безопасности). В качестве замечания отметим, что шагом в данном направлении, предполагаемым мандатным принципом контроля доступа к ресурсам, является назначение неиерархических меток. При этом предполагается, что каким-либо способом можно формализовать отличия субъектов и объектов доступа одного уровня иерархии (например, бухгалтерские документы, документы, хранящие паспортные данные и т.п.). Различные неиерархические метки назначаются «различным» (в соответствии с формализованными отличиями) субъектам и объектам доступа, чем для них задаются различные ПРД (например, к бухгалтерским документам разрешается доступ только бухгалтерам). Однако, эффективность данного подхода для нас остается весьма спорной, т.к. это не исключает необходимости использования дискреционного механизма в дополнение к мандатному (остается проблема разграничения доступа к документам с одной неиерархической меткой), и, по нашему мнению, только усложняет задачу администрирования. Поэтому далее вопросы включения в схему управления доступом неиерархических меток (которые по своей сути являются дополнительным атрибутом в дискреционной схеме контроля доступа, на наш взгляд, только усложняющим задачу администрирования механизма защиты) рассматривать не будем. Другая задача, которая должна решаться дискреционным механизмом, используемым в дополнение к мандатному – это разграничения прав доступа к объектам, хранящим исполняемые файлы. Здесь появляется атрибут «исполнение», объектами же для которых здесь должны быть реализованы принципы полномочного контроля доступа, становятся процессы (исполняемые файлы процессов, разрешенных на исполнение). Осуществить же иерархического деление процессов на уровни, по крайней мере, с позиций здравого смысла, крайне затруднительно, да и ПРД здесь сводятся лишь к простейшей схеме – разрешить, либо нет исполнение процесса. С учетом сказанного, поскольку все равно использование дискреционного механизма необходимо, контроль за запуском процессов в системе, целесообразно возложить на этот механизм защиты. Рассмотрим, каковы требования к реализации мандатного механизма контроля доступа, формализуемые нормативными документами в области защиты информации . Начиная с СВТ 4 класса защищенности, СЗИ НСД должны реализовывать мандатный принцип контроля доступа к ресурсам, к которому выдвигаются следующие требования:
Для дискреционного же механизма контроля доступа одним из требований (нас интересующим в данной работе) для рассматриваемых приложений СЗИ НСД является - дискреционные ПРД для систем данного класса являются дополнением мандатных ПРД. Анализируя данные требования, видим, что они в полной мере подтверждают нашу позицию, относительно полномочного (мандатного) принципа контроля доступа к ресурсам, сформулированную ранее. Теперь перейдем к способам реализации мандатного механизма контроля доступа, рассмотрим возникающие при этом проблемы и пути их решения. В качестве замечания отметим, что, во-первых, рассмотренные в статье решения апробированы при создании семейства СЗИ НСД – КСЗИ «Панцирь» (для ОС семейства Windows) - разработка НПП «Информационные технологии в бизнесе», во-вторых, они либо уже запатентованы, либо находятся в стадии патентования, поэтому без нарушения авторских прав, рассмотренные в работе технологии не могут быть реализованы в разработках иных производителей. Блок вопросов, связанных с принципиальной возможностью реализации мандатного принципа контроля доступа в виде самостоятельного механизма защиты (с собственным диспетчером доступа), позволяющего в полном объеме разграничивать доступ к ресурсам на основе полномочной схемы. Только при решении данного вопроса можно утверждать, что дискреционный механизм может выступать в качестве дополнения к мандатному механизму (а не наоборот). Первая проблема, на которой здесь следует остановить свое внимание – это проблема разграничения прав доступа к иерархическим объектам (прежде всего, файловым объектам). Дело в том, что в качестве объекта, которому присваивается метка безопасности, может выступать логический диск, папка (каталог, подкаталог), файл. Т.е. он может, как включаться в состав других объектов, так и включать в свой состав файловые объекты. Возникает вопрос – как назначать метки безопасности иерархическим объектам? Заметим, что в требованиях, представленных выше, рекомендаций по этому поводу напрямую не дается, однако отмечается, что «КСЗ должен реализовывать мандатный принцип контроля доступа применительно ко всем объектам при явном и скрытом доступе со стороны любого из субъектов…». Отсюда делаем вывод, что всем объектам, доступ к которым в системе разрешается в принципе, должны быть присвоены метки безопасности (к неразмеченному объекту, которому не присвоена метка, доступ должен быть невозможен). То же относится и к субъектам, но об этом поговорим позже. Предлагаемый нами способ разметки иерархических объектов состоит в следующем:
Кроме того, выдвигается дополнительное правило по обработке ПРД дисперчером доступа, состоящее в следующем - запрос доступа на запись к включаемому объекту анализируется без учета прав доступа на запись включающих его объектов в иерархии. Примеры разметки иерархических объектов, иллюстрирующие применение предлагаемого способа, представлены в табл.5.1 и в табл.5. В первом случае (см. табл.5. введена трехуровневая иерархия объектов, размеченных следующим образом: первый уровень (логический диск) имеет метку 5, второй уровень (каталог) имеет метку 5, третий уровень (подкаталоги или файлы, в зависимости от способа разметки – это те объекты, к которым разграничивается доступ пользователей, имеют метки 1,2,3, . Для разметки включающих уровней иерархии достаточно установить метку 5 для первого уровня, которая будет наследоваться вторым уровнем иерархии. Второй пример (см. табл.5. отличается тем, что включающие элементы второго уровня иерархии имеют различные метки. Здесь следует установить метку 3 для соответствующего объекта второго уровня иерархии.  Из рассмотренного примера делаем вывод, что предлагаемый нами подход позволяет реализовать мандатный принцип контроля доступа в виде отдельного механизма защиты (основного) собственным диспетчером доступа (между категориями механизм обеспечивает разграничения самостоятельно - без применения дискреционного механизма).  Пример интерфейса мандатного механизма контроля доступа (к локальным и разделенным в сети файловым объектам на жестком диске и внешних носителях), реализующего рассмотренные подходы в КСЗИ «Панцирь» для ОС Windows 2000/XP/2003, приведен на рис.5.  Рассмотрим, как будет анализироваться запрос диспетчером доступа (на примере в табл.5.1, из которой видим, что в системе заведено 4 уровня меток безопасности, соответственно имеем 4 уровня конфиденциальности документов и 4 уровня допуска к ним пользователей). При обращении к включенному ресурсу большинство приложений (например, Explorer) в рамках одного запроса осуществляет последовательное обращение ко всем включающим ресурсам. Пусть к ресурсу – объекту уровня 3, обращается пользователь, которому присвоена метка Диспетчер доступа позволит пользователю обратиться по чтению к уровню 1, т.е. увидеть структуру вложений данного уровня, с целью выбора нужного объекта уровня Запись на уровень 1 будет запрещена. Диспетчер доступа позволит пользователю обратиться по чтению к уровню 2, т.е. увидеть структуру вложений данного уровня, с целью выбора нужного объекта уровня Запись на уровень 2 будет запрещена. Диспетчер доступа позволит пользователю обратиться по чтению к уровню 2, т.е. увидеть структуру вложений данного уровня, с целью выбора нужного объекта уровня Запись на уровень 2 будет запрещена. Диспетчер доступа позволит пользователю обратиться по чтению к уровню 3 к объекту с меткой 4, по записи/чтению – к объекту с меткой 3, откажет в доступе к объектам с метками 1,2. Важнейшим условием реализации требования к мандатному механизму «КСЗ должен реализовывать мандатный принцип контроля доступа применительно ко всем объектам при явном и скрытом доступе со стороны любого из субъектов» является то, что какой-либо доступ в системе возможен только к размеченным объектам (вне заданных ПРД для дискреционного механизма). Если объект не занесен в поле «Ресурсы» (см. рис. 5. , т.е. ему не присвоено никакой метки безопасности, доступ к этому объекту будет невозможен. Вторая проблема связана с тем, что нормативными документами регламентируется использование при реализации мандатного механизма контроля доступа лишь атрибутов запись и чтение. Чтобы не использовать дискреционный механизм в качестве дополнительного для установки дополнительных атрибутов для размеченных объектов, целесообразно реализовать установку ряда атрибутов СЗИ НСД автоматически. Этот вопрос мы рассматривали в третьей части статьи (применительно к реализации дискреционного механизма, где шла речь о решении задачи администрирования, посредством числа атрибутов для объектов, назначаемых администратором). Здесь целесообразно использование такого же решения. Например, для задания полномочной разграничительной политики (настройки мандатного механизма) можно использовать лишь два основных атрибута (запись, чтение), остальные же значимые атрибуты (например, обзор, создание, удаление, переименование) могут устанавливаться СЗИ НСД по умолчанию, в частности, по следующей схеме. Пользователю разрешается обзор объектов, включающих разрешенный ему для доступа объект (например, если пользователю разрешается доступ к каталогу D:\User1\, ему разрешается обзор диска D:\, а на диске D:\ только каталога D:\User , пользователю разрешается создание, удаление, переименование объектов (естественно, при разрешении «на запись»), включаемых в разрешенный объект и не разрешаются подобные действия с включающим объектом (например, при разрешении доступа «на запись» в каталог D:\User1\, пользователь может создавать, удалять, переименовывать объекты в этом каталоге, но не может создавать, удалять, переименовывать объекты на диске D:\, соответственно, если объектом разграничения является файл, например, D:\User1\fail, пользователь не может удалять, переименовывать этот файл и создавать новые файлы в этом каталоге). При реализации данного подхода уже не требуется использования дискреционного механизма для задания дополнительных атрибутов доступа к размеченным объектам. Т.е. мандатный механизм становится самостоятельным механизмом контроля доступа и в этой части, а задача администрирования принципиально упрощается. Пример интерфейса дискреционного механизма контроля доступа, используемый в качестве дополнительного к мандатному механизму, реализующего рассмотренные подходы в КСЗИ «Панцирь» для ОС Windows 2000/XP/2003, приведен на рис.5.  В этом окне заводятся мандатные уровни – метки безопасности (которые могут задаваться как цифрами, так и смысловыми интерпретациями), каждому уровню сопоставляются пользователи и объекты – этим для них назначается выбранная метка. Блок вопросов, связанных с корректностью реализации мандатного механизма контроля доступа к ресурсам. Третья проблема связана с тем, какая разграничительная политика должна использоваться в дискреционном механизме, реализуемом в дополнение к мандатному. Этот вопрос также частично был рассмотрен в третьей части работы. При этом следует учитывать два ограничения мандатного механизма (требующих дополнительное использование дискреционного механизма): не позволяет разграничивать права доступа в рамках одной категории (между субъектами, которым установлена одинаковая метка, и к объектам, которым установлена одинаковая метка), а также не позволяет (выше мы обосновывали это решение) контролировать доступ на запуск исполняемых файлов (атрибут исполнение). Принципиальным здесь является то, что для рассматриваемых задач дискреционным механизмом целесообразно реализовывать различные разграничительные политики доступа. Для разграничений внутри категории следует использовать запретительную разграничительную политику («Все, что задано – явно указано, то запрещено»), о чем мы говорили в третьей части работы, и что вызвано тем, что использование разрешительной разграничительной политики («Все что не задано – явно не указано, то запрещено») в этом случае потребует повторить средствами дискреционного механизма и все разграничения, реализованные мандатным механизмом, использование которого в этом случае становится просто бессмысленным. Для контроля же запуска исполняемых файлов (атрибут исполнение) – механизм обеспечения замкнутости программной среды, о котором мы поговорим в шестой части работы, следует использовать разрешительную разграничительную политику. Первая проблема состоит в том, в системе могут присутствовать общие для пользователей (не разделяемые средствами ОС) файловые объекты, запрет доступа к которым может привести к некорректности работы системы или приложения. В качестве примера, к таким объектам можно отнести папку Documents and Settings\All Users на системном диске. Ряд приложений для своего корректного функционирования требуют создания и сохранения временных файлов, при этом, не позволяя делать эти файлы различными для различных пользователей. В данном окне заносятся дополнительные дискреционные ПРД, в соответствии с правилами, изложенными выше.  Сразу отметим, что вопросам корректности реализации механизмов добавочных средств защиты (на примере дискреционного механизма контроля доступа к ресурсам) была посвящена третья часть нашей работы. Все сказанное там в полной мере относится и к мандатному механизму, вопросы реализации которого рассматриваются в данной работе. Однако здесь мы можем выделить и некоторые особенности для данного механизма, на которых остановимся. Предлагаемая нами технология (Патент №223412 перенаправления запросов доступа состоит в следующем. Для каждого файлового объекта, не разделяемого между пользователями системой и приложениями, создаются собственные объекты для каждого пользователя. Обращение к исходному объекту перехватывается СЗИ НСД, определяется пользователь, инициировавший обращение, после чего запрос перенаправляется к соответствующему объекту, созданному для этого пользователя (исходный неразделяемый системой и приложениями объект становится виртуальным, к нему невозможно обратиться, т.к. все подобные обращения перенаправляются). Важным в реализации технологии является то, что перенаправление запроса должно осуществляться перед выполнением анализа прав доступа. На соответствующие же объекты пользователей уже могут быть установлены свои разграничения. Таким образом, данная технология позволяет средствами СЗИ НСД разделить между пользователями любой неразделяемый ОС или приложениями файловый ресурс, обеспечивая тем самым корректность реализации полномочного контроля доступа в общем случае. Вернемся к рассмотрению матрицы доступа D (рассматривали в начале работы). При наличии неразделяемого между пользователями ресурса, например, Ok-1, матрица доступа принимает следующий вид: В качестве замечания отметим, что данный механизм имеет и самостоятельные возможности дополнительной защиты (может использоваться не только с целью обеспечения корректности реализации принципов полномочного контроля доступа к ресурса), однако рассмотрение данных вопросов выходит за рамки настоящей работы. Видим, что наличие подобного объекта делает применение полномочного контроля доступа (в том числе, мандатного механизма) просто бессмысленным (он предназначен противодействовать снижению категории документа), а систему уязвимой к угрозе снижения уровня категории документа – действительно объект Ok-1 доступен по записи и чтению всем пользователям. В простейшем случае системный диск и пользователя System в мандатную схему контроля доступа можно включить, введя соответствующую системную категорию – категория системы наименьшая, что для нас означает присвоение максимальной метки, см. пример в табл.5.3. Пример интерфейса механизма перенаправления запросов к файловым объектам, реализующего рассмотренные подходы в КСЗИ «Панцирь» для ОС Windows 2000/XP/2003, приведен на рис.5.  Как видно из табл.5.3, мы достигаем того, что пользователи не могут обратиться на запись к системному диску (его модифицировать), предполагаем, что на этом диске расположены все разрешенные к запуску процессы, включая СЗИ НСД, файлы настроек СЗИ НСД и другая информация, критичная к возможности модификации пользователями. Однако, с таким подходом связано два недостатка. Вторая проблема, которую мы рассмотрим в работе, связана с включением в мандатную схему разграничения доступа к ресурсам привилегированных пользователей, в частности, пользователя System, и системной области диска (при этом помним, что все не размеченные субъекты и объекты не должны обладать правом доступа). Разрешение данного противоречия возможно путем включения в мандатную схему управления доступом категории “Исключение” (ей присвоим нулевую метку). К этой категории могут быть отнесены, как субъекты, причем, как пользователи, так и процессы – здесь самостоятельные субъекты доступа, так и объекты доступа. Соотнесение с категорией “Исключение” означает исключение субъекта или объекта доступа из схемы мандатного контроля доступом (на размеченные таким образом субъекты и объекты доступа мандатные разграничения не действуют). Но, заметим, действуют дискреционные разграничения, которыми права исключенных субъектов и доступ к исключенным объектам могут быть разграничены. Другими словами, таким способом реализации просто разрешаются конфликты, обусловливаемые собственно самым принципом полномочного контроля доступа к ресурсам.   Первый состоит в том, что сразу ограничиваются некоторые функциональные возможности СЗИ НСД. Например, СЗИ НСД, запущенная с правами пользователя System, уже не сможет осуществить контроль целостности объекта, имеющего метку безопасности меньше, чем N. Можно привести и иные функциональные задачи, возможность решение которых ограничивается (вступает в противоречие) рассмотренной схемой мандатного контроля доступа к ресурсам. Блок вопросов, связанных с расширением функциональных возможностей мандатного механизма контроля доступа к ресурсам Первая проблема связана с тем, что в рамках рассмотренной выше модели мандатного контроля доступа пользователю назначаются фиксированные права (присваивается метка безопасности), в рамках которых он может работать на компьютере. С учетом того, что права назначаются на основе привилегий, то пользователь может выполнять действия только в рамках заданных для него привилегий. Но ведь пользователь, обладающий некоторой формой допуска, например, третьей, должен работать не только с секретной информацией. При этом заметим, что чем ниже категория обрабатываемых документов, тем естественно должны быть менее жестки ограничения по режиму их обработки: возможность передачи по сети, сохранение на внешнем носителе, печать документов и т.д. С учетом того, что пользователь, отнесенный к какой-либо категории, все обрабатываемые им документы (с различными грифами) может сохранять в одном объекте (иначе не обеспечить решение основной задачи мандатного механизма – несанкционированное понижение грифа документа), то режимы обработки всех документов в этом случае не зависят от их грифа и регламентируются правилами работы с документами максимальной категории. Естественно, это существенно ограничивает возможность использования вычислительных средств при реализации электронного документооборота, в условиях работы с документами различной категории. Второй недостаток рассмотренного выше подхода связан с тем, что привилегированным пользователям (в частности, System) разрешается полный доступ к системному диску. Данный недостаток достаточно подробно был нами исследован в первой части работы - он связан с атаками на расширение привилегий (при рассматриваемых настройках получение прав пользователя System дает злоумышленнику возможность полного управления компьютером). В части устранения данного недостатка, предлагается ввести две системные категории – одну для системного диска, другую для привилегированных настроек. Пример настроек механизма с двумя системными категориями представлен в табл.5.4. Первый подход – изменение метки (мандата) процесса. Состоит в том, что в конечном случае именно процесс обращается к ресурсу, поэтому при рассмотрении его прав доступа в эксклюзивном режиме, путем установки метки на процесс ниже, чем метка пользователя, можно обеспечить обработку пользователем информации различных категорий. Здесь можно выделить два подхода – задание статической и динамической (изменяемой) метки процессу (очевидно, что уровень допуска процесса не должен превышать уровень допуска пользователя!). При таких настройках, как представлены в табл. 5.4, всем привилегированным пользователям запрещается возможность модификации системного диска (атаки на расширение привилегий здесь уже не актуальны – привилегий нет, как таковых). Однако здесь мы вступаем в противоречие с некоторыми принципами построения ОС. В частности, чтобы ОС корректно функционировала, необходимо некоторым системным процессам разрешить запись на системный диск (эти вопросы исследованы в первой части нашей работы). Эти процессы, как самостоятельные субъекты доступа, следует исключить из мандатной схемы контроля доступа, соотнеся их с категорией «Исключение». Дискреционным же механизмом для них можно установить необходимые права доступа к ресурсам. Задание статической метки состоит в том, что администратор выделяет некоторые приложения, для которых устанавливает метку, отличную от метки пользователя. При этом приложение может работать только с документами, категория которых не превышает уровня допуска приложения. Например, можно установить соответствующую метку на приложение, обеспечивающее доступ в сеть, при этом пользователь сумеет работать с сетью при ограничении, что в сеть, вне зависимости от уровня допуска пользователя, не смогут попасть данные, категория которых выше уровня допуска приложения. Рассмотрим возможные пути расширения функциональных возможностей мандатного принципа контроля доступа, в части предоставления возможности работы пользователю с документами различных категорий. Таким образом, на наш взгляд, корректно (в общем виде – не применительно к контролю конкретного канала взаимодействия, например, буфера обмена) решить рассматриваемую задачу несанкционированного противодействия обмена процессов информации невозможно в принципе, по двум причинам: во-первых, в общем случае мы не знаем всех возможных каналов возможного обмена процессами данными (т.е. скрытых угроз – известные нам угрозы - явные), во-вторых, далеко не все подобные каналы (возможности) могут быть декларированы разработчиками прикладного ПО. При этом заметим, что мы не касаемся здесь таких приложений, как интерпретаторы команд – ПО, имеющие встроенные средства программирования (например, офисные приложения – каковы возможности макросов?), функции которых априори невозможно декларировать. Заметим, что основу данного подхода составляет включение в схему мандатного управления доступом к ресурсам субъекта процесс, как самостоятельного субъекта доступа (ему назначается метка, отличная от метки пользователя). Данное решение нами запатентовано (Патент № 220761 и рассмотрено в первой части нашей работы. Развитием рассмотренного способа (можно рассматривать в качестве альтернативного решения) является динамическое назначение метки процессу при функционировании защищаемого объекта, при этом уровень допуска процесса может задаваться непосредственно пользователем (СЗИ НСД, посредством настроек администратора, обеспечивает лишь, чтобы этот уровень не превосходил уровеня допуска пользователя). По своей сути, это тот же способ, что и описанный выше (отличие состоит лишь в том, как назначать метки процессам – в своих принципах функционирования - после назначения меток, данные способы полностью совпадают), как следствие, имеющий все перечисленные выше недостатки. При всей привлекательности данного подхода, при его использовании возникают проблемы корректности реализации мандатного механизма управления доступом к ресурсам. Действительно, в системе одновременно могут быть запущены несколько процессов, имеющих различные уровни допуска, как следствие, различные режимы обработки данных. При чем эти процессы управляются одним и тем же пользователем. Казалось бы, что в части обеспечения корректности мандатного механизма контроля доступа к ресурсам в этом случае можно реализовать контроль взаимодействия процессов через буфер обмена (в предельном случае, вообще исключить подобную возможность). Однако, отметим, что это лишь один из известных (явный) способ взаимодействия процессов, причем, как правило, декларируемый (описанный в документации на прикладное ПО). Однако существуют и иные возможности (каналы) обмена данными процессов – вот лишь некоторые из них: MMF (Memory Mapped File), Pipe (именованные и неименованные каналы), DDE (Dynamic Data Exchange), Mailslot, Winsocket, RPC, LPC, COM Data Copy (OLE), System Messages (через функции SendMessage/PostMessage). Тогда для корректной реализации механизма необходимо обеспечить контроль всех каналов межпроцессного взаимодействия, что, на наш взгляд, является трудно выполнимой задачей для добавочной СЗИ НСД. В качестве замечания отметим, что реализация данного подхода, по своей сути, превращает однопользовательский режим обработки в многопользовательский – ведь одного пользователя, работающего в системе одновременно с различными правами доступа к ресурсам, уже можно рассматривать как двух пользователей! В порядке замечания отметим, что в общем виде (или корректно), на наш взгляд, рассматриваемая задача (предотвращение понижения категории информации) решается при создании условий, предотвращающих в принципе возможность обмена процессов, запускаемых пользователями в одном сеансе, по средством реализации средствами СЗИ такого режима обработки на защищаемом компьютере, при котором предоставляется возможность одновременной регистрации в системе пользователей одного уровня допуска к информации (в предельном случае – сведение режима обработки к однопользовательскому – в сеансе может регистрироваться только один пользователь) Подробнее на этой проблеме мы остановимся в одной из последующих частей нашей работы.. Первый способ (статическое назначение меток) состоит в следующем. Для каждого сотруника, который может работать на защищаемом компьютере, в системе заводится необходимое число учетных записей (пользователей) с различными правами. Для удобства, в идентификатор пользователя можно включить уровень допуска, с которым пользователь регистрируется в системе, например: «User sec» – для обработки секретных данных, «User conf» - для обработки конфиденциальной информации и т.д. Для всех этих учетных записей назначается один и тот же пароль для входа в систему (таким образом, это не приводит к увеличению оборудования, при использовании аппаратных аутентификаторов). Далее, каждому пользователю (каждой учетной записи) назначается соответствующая метка – уровень допуска, чем осуществляются мандатные разграничения прав доступа. Если необходимо получить права на обработку информации какой-либо категории, всего лишь требуется войти в систему под соответствующей учетной записью (с необходимым расширением его имени в учетной записи, обозначающим категорию допуска к информации). При этом СЗИ НСД, с одной стороны, предоставляет возможность сотруднику самостоятельно решать, какую информацию ему необходимо обрабатывать в создаваемой им сессии (но не выше уровня допуска пользователя, это учитывается администратором при создании соответствующих учетных записей), причем режим обработки (права доступа к устройствам, к сети, к запуску приложений и т.д.) здесь уже определяются не максимальным уровнем допуска пользователя, а непосредственно категорией информации, обрабатываемой в рамках сессии, с другой стороны, СЗИ НСД при этом обеспечивается корректность реализации мандатного механизма управления доступом к ресурсам. Поэтому, на наш взгляд, возможность его практического применения также весьма ограничена - в этом случае, наверное, сложно говорить о том, что задача корректности реализации мандатного механизма управления доступом, решена в общем виде! Противники данного подхода могут нам возразить, что его реализация существенно усложняет работу сотрудника на компьютере. Действительно, для перехода к работе с документами другой категории, ему потребуется перезагрузить систему и зарегистрироваться с соответствующей учетной записью (а не запустить процесс с другими правами). На это мы можем ответить следующее – здесь нужно выбирать удобство или безопасность. В конечном счете, полномочный принцип контроля доступа призван перенести конфиденциальное (в частности, и секретное) делопроизводство на вычислительное средство. Но давайте вспомним, с какими сложностями связан доступ к документу, имеющему соответствующий гриф, на предприятии. Естественно, что, перенося принципы конфиденциального делопроизводства на вычислительные средства, мы отчасти переносим и связанные с этим неудобства для сотрудников, на наш взгляд, это вполне оправдано! Второй подход – изменение метки (мандата) пользователя. Состоит в том, что изменяются метки пользователей (процессы в данном случае не размечаются). Здесь также, как и в предыдущем случае возможны способы статического и динамического (предполагает изменение) назначения меток пользователям. В качестве развития данного подхода (в качестве альтернативного решения) можно рассмотреть способ назначения динамических (изменяемых) меток пользователям. Суть данного подхода состоит в том, что у пользователя, в момент его регистрации в системе, СЗИ запрашивается требуемый ему уровень доступа к информации в сессии (который, естественно, не может превышать максимального статического уровня). Далее, в соответствии с требованиями пользователя, его учетной записи присваивается запрашиваемая им метка – другими словами, метка пользователю назначается на сеанс в соответствии с запросом регистрирующегося пользователя. Очевидно, что данный подход несколько упрощает задачу администрирования – здесь для каждого пользователя заводится одна учетная запись, при этом ей могут назначаться различные метки (но не выше максимального заданного уровня допуска пользователя к информации). Сразу же отметим, что именно данный подход нам кажется наиболее оправданным, т.к. это, на наш взгляд, единственный подход, позволяющий корректно в общем виде реализовать мандатный механизм контроля доступа к ресурсам в рассматриваемых приложениях (именно данный подход используется нами в семействе КСЗИ «Панцирь»). Вторая проблема обусловлена тем, что, как выше отмечалось, процессу не может присваиваться иерархическая метка безопасности. Однако в общую концепцию полномочного контроля доступа к ресурсам очень хорошо вписывается следующая идея – метка может устанавливаться процессу на основании того, какой уровень защиты при обработке информации обеспечивает этот процесс. К недостаткам рассмотренного выше подхода можно отнести некоторое усложнение администрирования СЗИ, связанное с созданием дополнительных учетных записей и задания для них разграничений. В рамках данного подхода можно установить метки безопасности сетевым службам (процессов, причем эксклюзивно), как самостоятельным субъектам доступа. В соответствии с указанной меткой помеченный процесс может обращаться к объектам файловой системы и к устройствам, что реализуется мандатным механизмом управления доступом к файловым объектам. Пример мандатного разграничения доступа к внешней сети представлен в табл.5. Однако условие корректности применения данного подхода связано с выполнением требований к полноте мандатного управления, а также с разделением общих ресурсов. Поясним эту мысль. Данный подход, как и предыдущий (при выполнении необходимых мер, описанных ранее), в общем виде решает проблему несанкционированного обмена информацией процессами, т.к. в сессии запускаются процессы только пользователями (в пределе одним пользователем) с одним уровнем допуска. Однако, в отличие от предыдущего подхода, здесь возникают дополнительные проблемы с формированием различных режимов обработки для пользователя, имеющего доступ к данным различной категории, что связано с наличием только одной учетной записи для пользователя. Во-первых, это требует, чтобы любой ресурс, к которому в системе разграничивается доступ, имел мандатные разграничения прав доступа (требование к полноте разграничений). Действительно, чтобы, например, для различных по уровню допуска сессий пользователя разрешить различные на запуск процессы, с учетом того, что учетная запись пользователя в этих случаях совпадает, необходима реализация мандатных разграничений на запуск процессов, т.е. в общем случае, мандатный механизм должен быть реализован в СЗИ НСД ко всем ресурсам, определяющим режим обработки категорированной информации на защищаемом компьютере (вследствие этого возрастает и сложность администрирования). Во-вторых, здесь вновь появляется проблема управления доступом к неразделяемым системой и приложениями файловым объектам (рассматривали выше). Здесь уже недостаточно разделения этих объектов между пользователями, т.к. необходимо учитывать не только учетную запись пользователя, но и его уровень допуска в сессии (в противном случае эти файловые объекты становятся доступными пользователю из различных сессий, что создает канал снижения категории защищаемой информации). При данных настройках мандатного контроля доступа метки безопасности назначаются процессам:
Проиллюстрируем сказанное на примере. Под реализацией мандатного доступа к ресурсам сети следует понимать мандатное управление доступом к виртуальному каналу связи. В качестве такого канала здесь понимается сетевая служба, определяющая информационную технологию, например, служба открытой почты, служба конфиденциальной почты, служба обработки SQL запросов и т.д. По открытому почтовому каналу могут передаваться только объекты, которым сопоставлена метка N (только эти объекты служба сможет читать из файловой системы). Соответственно, любое получаемое по открытой почте сообщение может быть записано только в объект (например, каталог), которому сопоставлена метка N. Таким образом, может быть реализован мандатный доступ к виртуальному каналу внешней сети.  Рассмотрим предлагаемый нами подход. Будем назначать метки безопасности процессам (на основании рассмотренных выше принципов), при этом метку процесса, устанавливаемую для соответствующего исполняемого файла процесса, будем рассматривать как дополнительный атрибут дискреционного механизма контроля доступа (управление запуска исполняемого файла будем осуществлять на основании данной метки и атрибута исполнение). Это обусловлено тем, что метки здесь неиерархические. Условием же разрешения на запуск процесса (исполнения файла), будет совпадение иерархической метки пользователя и не иерархической метки процесса. Данные настройки реализуют следующую возможность взаимодействия в рамках помеченной сетевой службы (информационной технологии). По защищенному почтовому каналу (конфиденциальная почтовая служба) могут передаваться объекты, которым сопоставлены метки N и N-1, то есть только эти объекты служба сможет читать из файловой системы. С меньшей, чем N-1 меткой (например, секретные) данные по конфиденциальному каналу передаваться не могут. Соответственно, любое получаемое по защищенной почте сообщение может быть записано только в объект (например, каталог), которому сопоставлена метка N-1. В заключение отметим, думаем, что нашу точку зрения иллюстрирует и все сказанное выше, что мандатный механизм управления доступом к ресурсам наиболее сложен для понимания, обоснования его эффективности, и практической реализации (в том числе, и в части формулировки и выполнения требований к корректности его реализации) добавочными СЗИ НСД. Заметим, что на сегодняшний день нам не встречались СЗИ НСД, отнесенные к одному и тому же классу в соответствии с , в которых мандатный механизм контроля доступа был бы реализован одинаково. Авторами, как одним из разработчиков СЗИ НСД, в работе, в порядке дискуссии, высказана их собственная точка зрения, основанная на опыте создания средств защиты для ОС семейств Windows и Unix. Судя по известным нам реализациям СЗИ НСД, наша позиция во многом отлична от позиций других разработчиков, в особенности же отличаются наши технические решения, большинство из которых запатентовано. Однако возникает вопрос, как, и с какой целью, может быть реализовано данное решение, в предположении, что метки процессов (если процессы размечаются), запускаемых пользователями, должны совпадать с меткой пользователя. Вот здесь, на наш взгляд, с целью упрощения администрирования (а ведь, как отмечалось ранее, это и есть основная задача мандатного механизма контроля доступа), возможно применение неирерахических меток безопасности. Здесь уже речь идет об упрощении администрирования механизма обеспечения замкнутости программной среды (подробно об этом механизме защиты поговорим в следующей части нашей работы). Рассмотрим, в чем состоит упрощение задачи администрирования. Механизмом обеспечения замкнутости программной среды должен осуществляться контроль запуска процессов пользователями. При этом для каждой учетной записи пользователя должен формироваться список разрешенных к запуску процессов. Это весьма трудоемкая задача, особенно, если каждому сотруднику может сопоставляться несколько учетных записей, соответственно для работы с документами различных категорий (данный подход описан выше), и в системе используются приложения, обеспечивающие различный уровень защиты данных (а именно это, вообще говоря, и должно быть при реализации полномочных принципов контроля доступа). При использовании же неиерархических меток процессов, устанавливаемых на исполняемые файлы, в большой мере автоматизируется процедура задания правил разграничения доступа на запуск (исполнение файлов) процессов в системе. При этом будем помнить, что полномочное разграничение доступа требует дополнительных разграничений внутри одной категории (в данном случае, разграничений на запуск исполняемых файлов, которым присвоена одна неиерархическая метка, т.е. процессов, обеспечивающих равный уровень защиты обрабатываемой информации) средствами дискреционного контроля доступа. Читайте далее:  24 мая 2006 года 1 - 4 июня 2006 года 17 - 23 июля 2006 года 7 - 13 августа 2006 года Я помню, как все начиналось ,часть 7, 1 - 8 октября 2006 года 31 октября 2006 года 20 - 26 ноября 2006 года 01 - 10 декабря 2006 года 15 - 21 января 2007 года 5 - 11 февраля 2007 года 19 - 25 марта 2007 года
|
