Универсальные и специализированные средства защиты. Отличия и возможность применения в корпоративных приложениях

Универсальные и специализированные средства защиты.
Отличия и возможность применения в корпоративных приложениях

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

Понятие индуктивности модели безопасности. Базовые требования к средству защиты конфиденциальной информации и требования нормативных документов. Причина возможной неоднозначности их толкования

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

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

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

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

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

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

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

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

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

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

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

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

Выводы:

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

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

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

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

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

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

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

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

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

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

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

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

Отличительной особенностью интерфейса является то, что правила доступа назначаются пользователям, а не присваиваются в качестве атрибутов файловым объектам и то, что основной разграничительной политикой является разрешительная политика ("Ресурсы, разрешенные для…"). Рассмотрим, как легко настраивать сложную разграничительную политику с использованием данного интерфейса. Так, на рис.1 одной записью мы разрешили пользователю User 1 запись и чтение только в каталог D:\Doc (заметим, что разрешить доступ одной записью можно к файловому объекту любого уровня иерархии – диск, каталог, подкаталог, файл) , а выполнение программ только из каталогов C:\Windows и C:\Program Files (одновременно запретив туда запись – реализовали замкнутую программную среду).

Аналогично реализован и интерфейс задания разграничительной политики доступа для субъекта "процесс" – нужно лишь выбрать вкладку "Процессы" (рис.2).

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

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

Рассматриваемая реализация обеспечивает и принципиальную возможность упрощения администрирования за счет использования масок. Маска - это регулярное выражение, содержащее метасимволы "*", "?" и т.п., покрывающие несколько имен ресурсов сразу, поэтому вместо внесения некоторого количества похожих имен ресурсов в списки правил разграничения доступа, вносится только одна маска, содержащая общую часть имен этих ресурсов и метасимволы, задающие правила последующего сравнения маски и имен ресурсов.

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

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

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

Таким образом, в качестве субъекта доступа может рассматриваться либо только пользователь, либо только процесс, либо "пара" – процесс и пользователь.

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

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

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

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

А что же атрибуты, вообще не нужны? Нужны, однако уже для решения иных задач защиты информации. Атрибуты должны присваиваться объектам для указания особых режимов их обработки (это уже не связано с правами пользователя). Например, атрибутами файлового объекта могут служить: "Шифрование данных при сохранении в файловый объект", "Гарантированное удаление остаточной информации при удалении или модификации (уменьшении размера) файлового объекта" и т.д. Однако эти вопросы выходят за рамки настоящей работы, их рассмотрение автор предполагает в отдельной статье, посвященной вопросам дополнительной защиты данных.

Универсальность решения в части реализации альтернативных разграничительных политик доступа к ресурсам

Альтернативные методы контроля доступа к ресурсам могут быть классифицированы следующим образом:

• Метод анализа прав доступа (избирательный контроль доступа);
• Метод анализа полномочий (или привилегий) доступа (полномочный контроль доступа).

Метод анализа прав доступа (избирательный контроль доступа).

Основу избирательного контроля доступа составляет задание прав доступа субъектов к объектам матрицей доступа. При запросе доступа механизмом управления доступом к ресурсам анализируется поле матрицы, определяемое параметрами запроса доступа – тип разрешенного доступа субъекта к объекту. Если запрос не противоречит заданным матрицей правам доступа, запрошенный доступ субъекту предоставляется, в противном случае, в запрошенном доступе субъекту отказывается (попытка доступа считается несанкционированной).

Метод анализа полномочий (или привилегий) доступа (полномочный контроль доступа).

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

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

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

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

Проанализируем данные требования.

Метки безопасности (еще называют мандатами) являются элементами линейно упорядоченного множества M = {M1,…, Mk}. Метки безопасности назначаются субъектам и объектам (группам субъектов и объектов), служат для формализованного представления их уровня полномочий. Будем считать, что чем выше полномочия субъекта и объекта (меньше их порядковый номер в линейно полномочно упорядоченных множествах субъектов и объектов - С = {С1,…, Ск} и О = {О1,…, Оk}), тем меньшее значение метки безопасности Mi, i = 1, …, k им присваивается, т.е.: M1 < M2 < M3<…Таким образом, в качестве учетной информации субъектов и объектов доступа, кроме их идентификаторов – имен, каждому субъекту и объекту задаются метки безопасности из множества M.

Контроль доступа реализуется на основе правил, определяющих отношение линейного порядка на множестве M, где для любой пары элементов из множества M, задается один из типов отношения {>,<,=} (на практике реализуется выбор подмножества M, изоморфного конечному подмножеству натуральных чисел – такой выбор делает естественным арифметическое сравнение меток безопасности).

Матрица доступа, описывающая данную модель контроля доступа, имеет следующий вид.

Для данной модели контроля доступа характерно то, что для доступа к объекту с требуемыми полномочиями i, субъект должен иметь полномочия не ниже, чем i, где i = 1,…,k (полномочия линейно упорядочены по возрастанию – чем меньше номер, тем выше полномочия).

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

Выводы.

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

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

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

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

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

Другое дело, реализация полномочного контроля доступа на основе матрицы доступа – здесь отсутствуют какое-либо жесткое задание формализации отношений, что позволяет гибко настраивать разграничительную политику доступа к ресурсам. Отметим, что практически любое противоречие здесь может быть корректно разрешимо, за счет возможности разграничивать права доступа для субъектов "процесс".

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