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

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

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

Основу построения современных ОС (в первую очередь, ОС семейств Windows и Unix) составляет их максимальная универсализация (в работе мы не рассматриваем специализированные ОС). Эти ОС могут использоваться и в домашних условиях, и на предприятии, в том числе и для обработки конфиденциальной информации, поэтому на практике они создаются без ориентации на какие-либо определенные требования (в противном случае, "пострадает" их универсальность). Добавочные же средства защиты, по своей сути, специализированы, они изначально разрабатываются для использования в части защиты конфиденциальной информации, как следствие строятся с учетом необходимости выполнения соответствующих формализованных требований. Казалось бы, каким образом это затрагивает вопросы построения интерфейсов настройки механизмов защиты? Однако, как покажем далее - напрямую.

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

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

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

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

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

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

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

Разобравшись с формализованными требованиями, возвратимся к вопросам построения интерфейсов механизмов защиты информации.

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

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

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

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

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

Рис.1. Интерфейс настройки разграничений прав доступа к объектам файловой системы для субъекта "пользователь"


Рис.2. Интерфейс настройки разграничений прав доступа к объектам файловой системы для субъекта "процесс"

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

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

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

Другой путь к упрощению администрирования, реализованный в КСЗИ "Панцирь-К" для ОС Windows 2000/XP/2003, связан с минимизацией числа настраиваемых типов доступа - в КСЗИ их всего три: запись, чтение, выполнение. Права по остальным типам доступа (переименование, удаление, создание и т.д.) формируются КСЗИ автоматически, на основе устанавливаемых типов доступа. Действительно, если пользователю разрешено чтение файла, то по умолчанию ему запрещена его модификация, переименование, удаление, создание нового файла (то же относится и к папке). Если пользователю разрешена запись в файл, ему разрешена его модификация, запрещены удаление, переименование, создание новых файлов, если разрешена запись в папку - пользователю разрешаются любые действия внутри папки, запрещается переименование, удаление папки, создание нового файла вне папки. Априори исключены все типы и права доступа, связанные с "владением". На наш взгляд, обоснованно минимальный набор прав доступа, выносимый для настройки в интерфейс, является его большим достоинством, в части упрощения задачи администрирования механизмов защиты, следовательно именно к реализации такого подхода (а не к увеличению числа атрибутов, с целью якобы достижения высокого уровня универсальности настроек), на наш взгляд, следует стремиться разработчикам средств защиты.

В порядке иллюстрации единообразия подходов к построению интерфейсов настройки механизмов защиты в КСЗИ "Панцирь-К" для ОС Windows 2000/XP/2003, на Рис.3 представлен интерфейс настройки разграничений прав доступа к объектам реестра ОС.

Рис.3. Интерфейс настройки разграничений прав доступа к объектам реестра ОС для субъекта "пользователь"

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

В КСЗИ "Панцирь-К" для ОС Windows 2000/XP/2003 данная возможность реализована следующим образом.

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

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

Окно фильтра отображаемых настроек в КСЗИ "Панцирь-К" для ОС Windows 2000/XP/2003 представлено на Рис. 4, окно отображения настроек в текстовом виде - на Рис.5.

Рис. 4. Окно фильтра отображаемых настроек


Рис. 5. Окно отображения настроек

Говоря о функциональных возможностях интерфейса средства защиты, следует затронуть и вопрос возможности информирования пользователя о его правах доступа к ресурсам в процессе функционирования системы. В КСЗИ "Панцирь-К" для ОС Windows 2000/XP/2003 данная возможность реализуется собственно интерфейсной компонентой средства защиты и не требует какого-либо участия администратора.

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

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

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

Рис. 6. Меню проводника Explorer с установленной КСЗИ


Рис. 7. Окно отображения прав доступа пользователей к объекту

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

Более подробную информацию о разработках компании можно получить на сайте: www.npp-itb.spb.ru, либо запросить интересующие сведения по системам защиты и условиям их поставки по электронной почте: info@npp-itb.spb.ru.

Д.т.н, проф. А.Ю.Щеглов
ЗАО "НПП "Информационные технологии в бизнесе"
info@npp-itb.spb.ru

обсудить  |  все отзывы (0)
Выберите оценку 10 (изумительно) 9 (отлично) 8 (хорошо) 7 (неплохо) 6 (средненько) 5 (сойдет) 4 (так себе) 3 (слабо) 2 (плохо) 1 (отвратительно) Вернуться в раздел Перейти к рейтингу Перейти к обсуждению Вернуться к статье	[20836; 0; 0]