3.3.9. Ролевая модель разграничения доступа к ресурсам

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

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

• Необходимый набор устройств;

• Необходимый набор приложений;

• Необходимый набор файловых объектов для хранения соответствующей информации;

• Необходимый набор сетевых ресурсов;

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

• Какую информацию, в каком виде (открытая или зашифрованная) и в какие объекты пользователь может передавать по сети;

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

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

• И многое, многое другое.

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

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

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

3.3.10. Разделительная политика доступа к ресурсам. Сессионный контроль доступа

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

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

Формирование режимов обработки категорированной информации состоит в подключении соответствующего набора ресурсов при обработке информации каждого уровня конфиденциальности.

Изолирование режимов обработки категорированной информации состоит в противодействии любой возможности изменения режима обработки (санкционированного набора ресурсов) информации каждого уровня конфиденциальности.

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

Идея реализации раделительной политики доступа к ресурсам проиллюстрирована на рис.3.18.

Рассмотрим требования к ее реализации.

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

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

• Управление монтированием устройств;

• Локализация среды исполнения – обеспечение замкнутости программной среды.

Принтеры

Внешние накопители

Сетевые ресурсы

Устройства

Компьютер

Рис.3.18. Иллюстрация реализации разделительной политики доступа к ресурсам

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

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

Требование 1. В объекте защите должен быть локализован набор ресурсов, подключение которых возможно к системе – должен быть сформирован объект защиты.

Введем основополагающее для рассмотрения принципов реализации разделительной политики доступа к ресурсам понятие «сессия» пользователя.

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

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

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

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

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

Введем следующие обозначения.

Пусть множества С = {С1,…, Ск} и О = {О1,…, Оk} – соответственно линейно упорядоченные множества субъектов и объектов доступа. В качестве субъекта доступа Сi, i = 1,…,k рассматривается как отдельный пользователь, так и группа пользователей, обладающих одинаковыми правами доступа, заметим, что на практике это могут быть как различные пользователи, так и один и тот же пользователь, обладающий различными правами доступа при различных режимах обработки информации), соответственно, в качестве объекта доступа Оi, i = 1,…,k может также рассматриваться как отдельный объект, так и группа объектов, характеризуемых одинаковыми к ним правами доступа. Пусть S = {0,Чт,Зп} – множество прав доступа, где «0» обозначает отсутствие доступа субъекта к объекту, «Чт» – разрешение доступа для чтения объекта, «Зп» – разрешение доступа для записи в объект.

В части противодействия несанкционированному понижению категории данных, с целью изменения режима их обработки (смена режима в сторону снижения категории сессии априори повышает вероятность хищения данных) широко на практике используется полномочный контроль доступа, в основе которого лежит иерархическая формализация отношения полномочий, состоящий в следующем. Иерархическая шкала полномочий вводится на основе категорирования данных (открытые, конфиденциальные, строго конфиденциальные и т.д.) и прав допуска к данным пользователей (по аналогии с понятием «формы допуска»). Будем считать, что чем выше полномочия субъекта и категория объекта, тем соответственно, меньше их порядковый номер в линейно полномочно упорядоченных множествах субъектов и объектов - С = {С1,…, Ск} и О = {О1,…, Оk}). Соответствующая формализация правил доступа субъектов к объектам при этом, как правило, сводится к следующему:

• Субъект имеет право доступа «Зп/Чт» к объекту в том случае, если полномочия субъекта и категория объекта совпадают;

• Субъект имеет право доступа «Чт» к объекту в том случае, если полномочия субъекта выше, чем категория объекта;

• Субъект не имеет прав доступа к объекту в том случае, если полномочия субъекта ниже, чем категория объекта.

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

С1 С2….Ck-1 Ck

O1 Зп/Чт 0 0 0

O2 Чт Зп/Чт 0 0

……………………….……..………………………………

.

D =

.

Ok-1 Чт Чт Зп/Чт 0

Ok Чт Чт Чт Зп/Чт

В части решения альтернативной задачи защиты информации от НСД - защиты данных от нарушения их целостности и доступности, следует рассматривать и вопросы антивирусной защиты данных. Обозначим через Pi вероятность того, что документ i-й категории «заражен» вирусом (например, макро-вирусом), при этом априори имеем: P1 < P2 <…< Pk. (чем выше категория конфиденциальности документа, тем жестче режимы его обработки, причем для режима обработки открытых документов (например, разрешен доступ в сеть Интернет) можем принять Pk = 1). Беря во внимание тот факт, что макро-вирус начинает действовать (что может нести в себе угрозу «заражения») лишь после прочтения его соответствующим приложением, и что предотвращать следует возможность «заражения» документа более высокой категории макро-вирусом из документа более низкой категории (после его прочтения приложением), получаем следующую матрицу доступа F, описывающую модель контроля доступа, реализуемую для антивирусного противодействия:

С1 С2….Ck-1 Ck

O1 (P1) Зп/Чт Чт Чт Чт

O2 (P2) Зп Зп/Чт Чт Чт

……………………….……..………………………………

.

F = .

.

Ok-1 (Pk-1) Зп Зп Зп/Чт Чт

Ok (Pk) Зп Зп Зп Зп/Чт

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

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

С1 С2….Ck-1 Ck

O1 Зп/Чт 0 0 0

O2 0 Зп/Чт 0 0

………………………..…..………………………….…

.

I = .

.

Ok-1 0 0 Зп/Чт 0

Ok 0 0 0 Зп/Чт

Утверждение доказано.

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

С учетом этого может быть сформулировано следующее требование.

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

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

Утверждение 2. Сессия должна быть задана (выбрана) до начала обработки данных (данные должны загружаться – из файлового объекта, из сети и т.д. только после того, как определен режим их обработки, соответственно и загрузки, т.е. сессия).

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

Сказанное проиллюстрировано на рис.3.19.

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

Утверждение доказано.

Пользователь

Процесс

Объект

Сессия

Выбор сессии

Нет сессионных разграничений

Пользователь

Сессия

Процесс

Объект

Выбор сессии

а) Неверная схема

b) Верная схема

Рис.3.19. Альтернативные схемы выбора сессии

С учетом этого может быть сформулировано следующее требование.

Требование 3. Сессия должна быть задана (выбрана) до начала обработки данных (данные должны загружаться – из файлового объекта, из сети и т.д., только после того, как определен режим их обработки, соответственно, способы загрузки и обработки, т.е. сессия).

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

Рассмотрим альтернативные способы определения сущности «сессия» субъектом доступа.

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

Рассмотрим использование для задания сессии сущности «учетная запись».

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

Теперь рассмотрим использование для задания сессии сущности «процесс».

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

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

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

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

Теперь рассмотрим возможность включения дополнительной сущности «сессия», которая состоит во включении в схему контроля доступа к ресурсам дополнительных сущностей: субъекта «выбор сессии» и объекта «выбор сессии».

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

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

Вывод. В современных условиях разделительная политика доступа к ресурсам должна реализовываться с использованием для задания сессии сущности «учетная запись».

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

Пусть множества С = {С1,…, Ск} и О = {О1,…, Оk} – соответственно линейно упорядоченные (по категориям конфиденциальности, пусть, чем меньше порядковый номер, тем выше категория) множества сессий и ресурсов (объектов доступа). В качестве субъекта доступа Сi, i = 1,…,k рассматривается отдельная сессия (права доступа конкретного пользователя, работа которого разрешена в данной сессии, есть подмножество разрешений, заданных для сессии), в качестве объекта доступа Оi, i = 1,…,k может также рассматриваться как отдельный объект, так и группа объектов, характеризуемых одинаковыми категориями. Пусть S = {0,Дi} – множество прав доступа, где «0» обозначает отсутствие доступа субъекта к объекту, «Дi» – разрешения доступа (в зависимости от типа ресурса, например, «Чт/Зп» (Запись/Чтение) – для информационных и системных ресурсов, «В» (Выполнение) – для исполняемых файлов и т.д.) к ресурсам в i-й сессии, а L = {0,Пi} – множество привилегий пользователя, где «0» обозначает отсутствие каких-либо привилегий (т.к. доступ к ресурсам запрещен), «Пi» - привилегии пользователя (в том числе, и в части доступа) к ресурсам в i-й сессии.

Модель сессионного контроля доступа можно представить матрицей доступа S, и матрицей привилегий пользователя P, имеющими следующий вид:

С1 С2….Ck-1 Ck

O1 Д1 0 0 0

O2 0 Д2 0 0

………………………..…..………………………….…

.

S = .

.

Ok-1 0 0 Дk-1 0

Ok 0 0 0 Дk

С1 С2….Ck-1 Ck

O1 П1 0 0 0

O2 0 П2 0 0

………………………..…..………………………….…

.

P = .

.

Ok-1 0 0 Пk-1 0

Ok 0 0 0 Пk

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

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

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

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

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

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

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

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

Требование 7. Должна быть реализована разрешительная разграничительная политика доступа к ресурсам – все, что явно не разрешено, то запрещено, т.к. только в этом случае становится невозможен доступ пользователей к вновь создаваемым объектам.

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