Вы находитесь в разделе Типовых решений систем безопасности

Вопросы корректности реализации механизмов защиты от нсд добавочными средствами

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

Исследование будем проводить посредством рассмотрения формализованных требований к механизмам защиты, применительно к ОС семейства Windows (естественно, будем говорить о технологии NT). Целью же данного исследования будет анализ того, в какой мере требуется уточнение требований, применительно к конкретному системному программному средству, соответственно, анализ того, в какой мере отсутствие подобных уточняющих требований может повлиять на вопросы корректности реализации механизма защиты. Проводя исследование, мы также попытаемся сформулировать уточняющие требования, учитывающие особенности архитектуры конкретного системного ПО. Однако, сразу оговоримся, что приводимое в работе исследование, сделанные по работе выводы и предложения являются лишь частным мнением автора (приведенным с целью обсуждения данной проблемы), которое сформировалось в результате практической работы по созданию СЗИ НСД семейства “Панцирь” (разработка ЗАО “НПП “Информационные технологии в бизнесе”).

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

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

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

Приведем формализованные базовые требования (к СВТ шестого класса защищенности) к рассматриваемому в работе механизму защиты, в соответствии с действующим сегодня нормативным документом , которые в установлены для дискреционного принципа контроля доступа:

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

Это, как раз и есть те общие формализованные требования (видим, что в них нет никаких ссылок на тип и версию системного ПО), которые мы будем далее рассматривать, в части исследования вопросов целесообразности их уточнения с учетом архитектурных особенностей системного ПО, в нашем случае – ОС Windows (технологии NT, файловая система NTFS).

Приступим к анализу этих требований.

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

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

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

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

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

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

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

Итак, разобравшись в этом вопросе, рассмотрим, как же необходимость выполнения требования: «Право изменять ПРД должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.)» сказывается на реализации дискреционного механизма управления доступом к файловым объектам для ОС Windows – какие уточняющие требования к его реализации могут быть сформулированы.

1. В разграничительной политике доступа к ресурсам, соответственно, и в схеме управления доступом не должно присутствовать сущности «Владелец» как таковой. Таким образом, субъектов доступа будем делить на пользователей (не обладающими никакими правами владения и какими-либо правами назначать и изменять ПРД) и администраторов, обладающих правом назначать (изменять) ПРД. Как следствие, механизм защиты не должен содержать сущности «Владелец», атрибутов доступа, связанных с исключаемой сущностью «Владелец», и возможностей назначения (изменения) остальных атрибутов пользователями.
2. Основным объектом доступа, для которого устанавливаются ПРД администратором, является папка (диск, каталог, подкаталог). Это вызвано тем, что администратор не может устанавливать разграничения для всех вновь создаваемых пользователями файлов. Отсюда следует, во-первых, что СЗИ НСД должна обладать возможностью устанавливать основные значимые атрибуты доступа (чтение, запись, исполнение) на папку, во-вторых, по умолчанию права доступа должны наследоваться файловыми объектами, включаемыми в папку, для которой администратором заданы ПРД, в-третьих, ПРД по разрешениям типов доступа для включающего объекта должны быть приоритетнее(именно они должны действовать) ПРД по разрешениям для включаемого объекта.

В качестве замечания остановимся на некоторых рекомендациях по реализации механизма защиты, следующих из сформулированных выше требований, которые, на наш взгляд, следует иметь в виду разработчикам СЗИ НСД.

1. Обратимся к требованию: «Для каждой пары (субъект - объект) в СВТ должно быть задано явное и недвусмысленное перечисление допустимых типов доступа (читать, писать и т.д.), т.е. тех типов доступа, которые являются санкционированными для данного субъекта (индивида или группы индивидов) к данному ресурсу СВТ (объекту)». Здесь можно отметить следующее – несомненно все типы запросов механизм должен перехватывать, однако возникает вопрос, какой набор атрибутов доступа следует выносить в интерфейс СЗИ НСД – для их назначения (изменения) администратором, а какие атрибуты СЗИ НСД должна устанавливать автоматически, исходя из иных установленных атрибутов. Поясним сказанное. Например, для задания разграничительной политики (настройки механизма) можно использовать лишь три основных атрибута (запись, чтение, исполнение), остальные же значимые атрибуты (например, обзор, создание, удаление, переименование) могут устанавливаться СЗИ НСД по умолчанию, в частности, по следующей схеме. Пользователю разрешается обзор объектов, включающих разрешенный ему для доступа объект (например, если пользователю разрешается доступ к каталогу D:\User1\, ему разрешается обзор диска D:\, а на диске D:\ только каталога D:\User , пользователю разрешается создание, удаление, переименование объектов (естественно, при разрешении «на запись»), включаемых в разрешенный объект и не разрешаются подобные действия с включающим объектом (например, при разрешении доступа «на запись» в каталог D:\User1\, пользователь может создавать, удалять, переименовывать объекты в этом каталоге, но не может создавать, удалять, переименовывать объекты на диске D:\, соответственно, если объектом разграничения является файл, например, D:\User1\fail, пользователь не может удалять, переименовывать этот файл и создавать новые файлы в этом каталоге). На самом деле, проблема минимизации числа атрибутов доступа, выносимых в интерфейс СЗИ НСД, для их задания администратором, на наш взгляд, крайне важная задача. Это подтверждается тем, что в современной статистике успешных атак на защищаемые ресурсы, уязвимости системы, обусловливаемые ошибками администрирования, имеют весьма значительную долю . Поэтому, на наш взгляд, достоинством СЗИ НСД является именно обоснованная минимизация числа атрибутов доступа, выносимых в интерфейс, а не максимальное их представление в интерфейсе, с целью реализации, яко бы «тонких» настроек механизма (опять же встает задача обоснования необходимости и достаточности атрибутов, выносимых для настройки механизма в интерфейс).
2. В части упрощения задачи администрирования, что автор считает крайне важным, остановимся еще на одной проблеме. При назначении (изменении) ПРД стоит задача назначить атрибуты доступа, реализующие права пользователей на доступ к файловым объектам. Современными ОС это реализуется следующим образом – для объекта устанавливается – какие субъекты и по каким правилам могут к нему общаться. Но возможен и иной подход – можно назначать субъектам – к каким объектам и по каким правилам они могут обращаться. Это в корне меняет как собственно интерфейс настройки механизма, так и возможность установки атрибутов «по умолчанию» СЗИ НСД (меняется и сама схема хранения и обработки атрибутов при анализе запроса доступа). Здесь отметим, что во втором случае не только упрощается администрирование, причем, как в части интуитивной понятности интерфейса (права доступа, на основании которых уже и формируемые ПРД, определяются для пользователей, а не для объектов), так и в части минимизации действий (записей), производимых администратором при задании (изменении) ПРД, но и достигается выполнение требования к индуктивности модели безопасности (об этом речь пойдет ниже). По понятным причинам в ОС атрибуты присваиваются объектам – это обусловлено, как способом хранения атрибутов (например, в NTFS), так и включением в схему управления доступом сущности «Владелец» (при назначении (изменении) прав доступа к созданному файлу владелец может назначать (изменять) атрибуты файла, которым владеет, но никак не общие ПРД, установленные для другого пользователя). Для СЗИ НСД, как отмечали, сущности «Владелец» вообще не должно быть, а назначенные ПРД при любом случае из задания будут храниться в отдельном объекте (например, в файле(ах) настроек механизма).

Пример интерфейса, реализующий данные подходы к настройке механизма в КСЗИ «Панцирь» для ОС Windows 2000/XP/2003, приведен на рис.3.1



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

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

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

• ПРД может назначать (изменять) только администратор (сущность “Владелец” исключается), как следствие, пользователь не может изменить ПРД в процессе функционирования системы;
• Основной реализации разграничительной политики доступа к ресурсам является разрешительная разграничительная политика доступа: «Все, что не разрешено (явно не указано), то запрещено». В этом случае к любому объекту, для которого не заданы разграничения, в том числе и к вновь создаваемому объекту не в папке, на которую установлены разграничения, «по умолчанию» будет запрещен какой-либо доступ всем пользователям. Как следствие, основными атрибутами доступа будут: «Ресурсы, разрешенные для чтения», «Ресурсы, разрешенные для записи», «Ресурсы, разрешенные для исполнения» (см. рис.3. .

Продолжая данную тему, остановимся, на наш взгляд, на крайне важном моменте – рассмотрим требования к дискреционному принципу контроля доступа в случае его совместного использования с мандатным принципом контроля доступа (начиная с СВТ четвертого класса защищенности СВТ, в соответствии с ). Заметим, что следуя , базовые требования к дискреционному контролю доступа здесь те же, что рассматривались нами выше (они несколько дополнены, но об этом поговорим далее). Однако, здесь возникают следующие вопросы – обоими этими принципами в их трактовке, представленной в , задаются требования к реализации индуктивной модели безопасности – насколько это оправдано и к чему приводит? Рассмотрим, в чем состоят особенности реализации дискреционного принципа контроля доступа в данных приложениях. Во-первых, модель полномочного управления доступом (на основе меток безопасности, или, как называют, мандатное управление), априори являющаяся индуктивной, является частным случаем индуктивной модели дискреционного управления, что не сложно строго доказать (подобным дискреционным механизмом можно реализовать все возможности, с учетом основного назначения полномочного управления – не допустить снижения мандатного механизма, т.к. в обоих случаях реализуется принудительное управление ), и его преимущество перед дискреционным в этом случае состоит лишь в упрощении задачи администрирования, за счет использования меток. Во-вторых, одновременное использование мандатного механизма (который разграничивает доступ не между субъектами и объектами, а между категориями субъектов и объектов) и дискреционного уже предполагает реализацию дискреционным механизмом запретительной разграничительной политики доступа: «Все, что не запрещено (явно не указано), то разрешено» (в противном случае при настройке дискреционного механизма потребуется повторить все разграничения, заданные для мандатного механизма, и еще внести дополнительные разграничения для субъектов и объектов внутри категорий, т.е. не о каком упрощении администрирования в этом случае уже речь не идет, а применение мандатного механизма при этом становится просто бессмысленным – только усложняет задачу администрирования). Заметим, что для СВТ, использующих полномочное управление доступа, именно мандатный механизм призван обеспечивать индуктивность модели безопасности, являясь здесь первичным, дискреционный же механизм реализуется в дополнение к мандатному, с целью разграничения доступа внутри категории. Сказанное выше также можно рассматривать, как весьма важное уточняющее требование.

Пример интерфейса настроек дискреционного механизма, реализованного в КСЗИ «Панцирь» для ОС Windows 2000/XP/2003 в дополнение к мандатному, приведен на рис.3.2



Итак, выше мы рассматривали общие требования, без учета специфики защищаемого системного ПО. Данная специфика, в первую очередь, проявляется, когда речь заходит о следующем (в соответствии с представленными требованиями): «Для каждой пары (субъект - объект) должно быть задано явное и недвусмысленное перечисление допустимых типов доступа …» и «…должен быть применим к каждому объекту и каждому субъекту…».

Теперь, применительно к понятиям «Объект» и «Субъект» рассмотрим архитектурные особенности ОС Windows (в том числе, файловой системы NTFS), накладывающие свои уточняющие требования к корректности реализации в СЗИ НСД дискреционного принципа контроля доступа для ОС данного семейства.

1. Объект доступа.

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

Рассмотрим эти способы:

• Файловый объект идентифицируется именем, при этом:
  • Файловые объекты, задаваемые длинными именами, характеризуются той отличительной особенностью, что к ним можно обращаться, как по длинному, так и по короткому имени, например к каталогу “\Program files\” можно обратиться по короткому имени “\Progra~1\”;
  • Файловые объекты, задаваемые русскими (либо в иной кодировке) буквами, также имеют короткое имя, которое формируется с использованием кодировки Unicode (внешне они могут существенно различаться), например, короткое имя для каталога “C:\Documents and Settings\USER1\Главное меню” выглядит как “C:\Docume~1\USER1\5D29~1\”. К этим объектам также можно обратиться, как по длинному, так и по короткому имени;
• Файловый объект идентифицируется не только именем, но и своим идентификатором (ID) – индекс объекта в таблице MFT, причем некоторые программы обращаются к файловым объектам не по имени, а именно по ID.
• Файловый объект может адресовать не напрямую, а с использованием ссылок (ссылки бывают жесткие и символьные). При этом один файловый объект может содержать в себе ссылку на другой объект, и, обращаясь к первому объекту, получаем доступ, в соответствии с находящейся в нем ссылкой, ко второму объекту.

С учетом сказанного, можем сформулировать следующее уточняющее требование к корректности реализации механизма в СЗИ НСД – ПРД, задаваемые для файлового объекта, должны быть однозначно определены и действовать при любом из возможных способов идентификации объекта при обращении к нему.

Другая проблема обусловливается тем, что как собственно ОС, так и некоторые сторонние приложения не позволяют разграничить права доступа для различных пользователей к некоторым файловым объектам (если подобные ПРД назначить, то это приведет к некорректности работы системы или соответствующего приложения). В качестве примера подобного файлового объекта, доступ к которому требует дополнительных разграничений, можно отнести папку: “All Users” на системном диске. Естественно, что выполнение рассмотренного требования является обязательным при категорировании информации, в противном случае, становится невозможным противодействовать понижению категории информации.

С учетом сказанного, можем сформулировать следующее уточняющее требование к корректности реализации механизма в СЗИ НСД – СЗИ НСД должна иметь возможность собственными средствами разделять любую папку, неразделяемую системой и приложениями, между пользователями.

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

С учетом сказанного, можем сформулировать следующее уточняющее требование к корректности реализации механизма в СЗИ НСД – СЗИ НСД должна иметь возможность в полном объеме разграничивать права доступа пользователей к любому файловому объекту, вне зависимости от его функционального назначения.

Субъект доступа.

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

• Пользователь имеет возможность запуска процесса с правами другого пользователя (заметим, что при этом пользователь должен знать пароль того пользователя, с правами которого он запускает процесс, т.е. данная возможность системой (заметим – не СЗИ НСД) в каком-то смысле защищена). Например, подобную возможность в ОС Windows предоставляет утилита: runas.exe.
• Система предоставляет разработчикам приложений сервисы олицетворения. Олицетворение (impersonation) предоставляет возможность отдельному потоку выполняться в контексте защиты, отличном от контекста защиты процесса, его запустившего, т.е. действовать от лица другого пользователя. Олицетворение, например, применяется в модели программирования «клиент-сервер». При заимствовании прав сервер временно принимает профиль защиты клиента, «от лица» которого обращается к ресурсу. Тогда сервер может работать с ресурсом от имени клиента, а система защиты проводить проверку его прав доступа. Обычно серверу доступен более широкий круг ресурсов, чем клиенту, и при олицетворении поток теряет часть исходных прав доступа, запустившего его процесса. И, напротив, при олицетворении соответствующий поток может получить дополнительные права. В качестве замечания отметим, что сегодня атаки на сервисы олицетворения, с использованием ошибок в приложениях, использующих данные сервисы, составляют весьма заметную часть в перечне успешных атак на ОС Windows .

С учетом сказанного, можем сформулировать следующее уточняющее требование к корректности реализации механизма в СЗИ НСД – СЗИ НСД, в рамках реализуемого ею контроля доступа к ресурсам, должна осуществляться контроль корректности идентификации субъекта доступа (соответственно, контроль соответствия маркера доступа (access token) пользователя и потока, обращающегося к ресурсу.

Другое, на что здесь следует обратить внимание – это то, что субъекты доступа (пользователи) могут принципиально различаться по своей сути. В частности, к субъектам доступа относятся и системные пользователи (так называемые, виртуальные, которые либо всегда присутствуют в системе, например, пользователь System, либо создаются при подключении некоторого ПО, например, СУБД), так как эти пользователи также обращаются к ресурсам, следовательно и к ним могут быть применимы ПРД.

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

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

Прежде чем, попытаться подытожить и обобщить все сказанное, остановимся еще на одном моменте. Выше мы исследовали базовые требования к дискреционному принципу контроля доступа (для СВТ шестого класса защищенности). Однако, при переходе к другим классам данные требования расширяются, в частности, начиная с четвертого класса защищенности появляется требование:

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

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

Итак, обобщим полученные результаты и сделаем выводы по работе (естественно, что на основании проведенного в работе исследования требований только к одному механизму защиты). Выводы по работе.

1. Существующие формализованные требования в полном объеме и корректно (на наш взгляд, следовало бы лишь уточнить требования к дискреционному принципу контроля доступа в приложениях его совместного использования с мандатным принципом контроля доступа) формулируют требования к корректности реализации механизмов защиты добавочными СЗИ НСД для современных ОС.
2. Формализованные требования в части корректности реализации СЗИ НСД в нормативных документах не детализируются применительно к построению системы защиты для различных системных средств, отличающихся архитектурными решениями. В связи с этим, на наш взгляд, необходима разработка (например, по аналогии с тем, как это сделано в данной работе) и какая-либо формализация уточняющих требований, связанных с корректностью реализации механизмов защиты для альтернативного системного ПО, выполнение которых, как и выполнение общих требований, должно априори быть обязательным для разработчиков СЗИ НСД. Это обеспечит единообразие трактовки требований разработчиками и потребителями СЗИ НСД, приведет к повышению качества создаваемых СЗИ НСД и к повышению доверия потребителя к добавочным СЗИ НСД.
3. Подобная детализация требований позволит лучше ориентироваться потребителю в задачах защиты информации и максимально использовать возможности СЗИ НСД при разработке политики безопасности, соответственно, обладая большей информированностью о СЗИ НСД, осуществлять обоснованный выбор той из них, которая максимально соответствует его потребностям (максимально подходит для политики безопасности, предполагаемой к реализации на предприятии).
4. Ну и, наконец, дополнительная детализация требований ни в коей мере не ограничит инициативы разработчика средств защиты, поскольку речь идет не о дополнительных функциональных возможностях СЗИ НСД, а о корректности реализации основных ее свойств.

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




Читайте далее:
Шедевры
Аау повышает свою актуальность как для прошлого, так и для будущего
Мы и деревья
Построение системы видеонаблюдения и управления доступом в аэропорту пулково
Система мониторинга арм пользователей фракталь-экран 2
Многоканальные системы записи переговоров стелс лайн
Системы ip видеонаблюдения – будущее cctv
Куб. что в имени тебе моем?
Особенности национального монтажа
Удобство администрирования сзи от нсд как составляющая эффективности защиты информации в корпоративн
Особенности проектирования одномодовых волоконно-оптических линий связи
Этапы большого пути, или важные кирпичики системы ip-видеонаблюдения ,video over ip- voip,
Грудничковые хроники доктора пилюлькина
Интегрированная система безопасности на основе технологии ethernet
Контроль целостности и аудит событий