Мельников Д. А. - Информационная безопасность открытых систем - 2013

имеют доступ. Целевым объектом может быть, например, объект уровня ЭМВОС или Интернет-архитектуры, файл или реальная система.

Запрос доступа представляет собой операции/действия и операнды (компоненты операции/действия), которые образуют субпроцедуру в процедуре (попытке) получения доступа.

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

С целью принятия такого решения ФПРР-модуль получает запрос доступа от инициатора (как часть запроса на принятие решения) и следующие типы ВИПР:

•информация для принятия решения относительно ини­ циатора запроса доступа (ВИПР, извлекаемая из ВИУД, «привязанной» к инициатору);

•информация для принятия решения относительно целе­ вого объекта (ВИПР, извлекаемая из ВИУД, «привязан­ ной» к целевому объекту);

•информация для принятия решения относительно запро­ са доступа (ВИПР, извлекаемая из ВИУД, «привязанной» к запросу доступа).

Другая информация, поступающая на вход ФПРР-модуля, представляет собой правила ПЛУД (из ФПРР-модуля ЦБ ССБ; Security Domain Authority) и любую контекстно-зависимую ин­ формацию, необходимую для интерпретации ВИПР или поли­ тики. Примеры контекстно-зависимой информации включают местоположение инициатора, время доступа или соответствую­ щий используемый маршрут соединения.

Основываясь на эту входную информацию и, возможно, на ВИПР, оставшуюся от предыдущей процедуры принятия реше­ ния, ФПРР-модуль принимает решение разрешить или отказать

184

инициатору в установлении доступа к целевому объекту. Затем решение направляется в ФПРИ-модуль, который либо разреша­ ет передать запрос доступа целевому объекту, либо выполняет другие необходимые действия.

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

В дальнейшем полагаем, что для одного запроса доступа не­ обходима одна итерация процедуры информационного обмена между инициатором и целевым объектом, если будет получено соответствующее разрешение от ФПРИ-модуля. Несмотря на то, что некоторые запросы доступа между инициатором и целе­ вым объектом напрямую зависят от других запросов, очень ча­ сто возникает ситуация, при которой два объекта обмениваются несколькими связанными между собой запросами доступа, т.е. используют «запросно-ответный принцип» информационного обмена. В таких случаях инициатор и целевой объект при не­ обходимости меняются ролями, либо одновременно, либо попе­ ременно, и при поступлении каждого запроса доступа выпол­ няются все функции УД, и, возможно, отдельными ФПРИ- и ФПРР-модулями и на основе разных ПЛУД.

185

4.1.2.2. Другие процедуры УД

Формирование структуры (формата') ПЛУД. ПЛУД, как правило, разрабатывается и официально утверждается в чита­ бельной форме как совокупность наиболее общих принципов; например только администраторам и менеджерам определенно­ го ранга разрешено проверять информацию о заработной плате работников. Переход от общих принципов к конкретным прави­ лам относится к мероприятиям технического проектирования, которые должны предшествовать процедурам УД.

Формирование структуры (формата^ ВИУД. В рамках этой процедуры делается выбор относительно формата ВИУД (структур данных) и формы информационного обмена между реальными системами (синтаксические структуры). Форма­ ты ВИУД должны быть способны удовлетворять требованиям специфических ПЛУД. Отдельные форматы ВИУД могут быть приемлемыми и для внутреннего применения, и для использо­ вания между реальными системами. Для решения различных за­ дач и для взаимодействия между отдельными элементами могут использоваться различные форматы ВИУД.

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

Для прикладных систем, соответствующих ЭМВОС или Интернет-архитектуры (и, возможно, для других), наиболее подходящей структурой ВИУД является атрибутная модель, которая включает пару значений: сам атрибут и тип атри­ бута.

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

186

них специфические типы атрибутов и значения этих атрибутов, входящие в состав ВИУД. Эти объекты могут определять или изменять местоположение ВИУД в соответствии с политикой обеспечения безопасности ССБ. Размещенная объектом ВИУД может быть ограничена другой ВИУД, которая была «привя­ зана» к ней другим объектом. Размещение ВИУД в элементах ССБ является непрерывной процедурой, так как в ССБ могут появляться новые элементы.

ПРИМ ЕЧАНИЕ. Иногда административная процедура по разграничению «прав доступа» рассматривается как авторизация. Именно с этой точки зрения рассматривается понятие «размеще­ ние ВИУД у инициаторов и в целевых объектах».

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

В реальной процедуре ВИУД должна быть жестко «привя­ зана» к элементу, причем так, чтобы ФПРР-модуль, который использует ВИПР, извлекаемую из «привязанной» ВИУД, был уверен в этой информации. Таким образом, несмотря на то что размещение ВИУД в элементах является необходимым предва­ рительным условием для формирования связанной с элементом ВИУД, только ВИУД, которая «привязана» к элементу, являет­ ся действительно необходимой в реальных системах.

Привязка ВИУД к инициаторам, целевым объектам и за­ просам доступа. Привязка ВИУД к элементу (т.е. к инициатору, целевому объекту или запросу доступа) порождает надежную

187

взаимозависимость между элементом и ВИУД, размещенной в этом элементе. Для функции УД и других элементов привязка обеспечивает гарантии того, что ВИУД действительно пред­ назначена для соответствующего элемента и что невозможна какая-либо модификация, так как привязка уже выполнена. При­ вязка обеспечивается за счет применения службы обеспечения целостности. Возможно несколько способов привязки, включая те, которые зависят от местонахождения элемента и ВИУД, в то время как другие способы зависят от некоторых криптогра­ фических процедур формирования ЭЦП или вычисления КПС (seal). Целостность привязки ВИУД к элементам нуждается в собственной защите при ее размещении в системах инициатора и целевого объекта (например на основе доверия к функциям, реализуемым операционной системой, таким как защита фай­ лов и разделение процессов), а также при обмене ВИУД. Так как может быть несколько структур размещаемой в элементах ВИУД (и в рамках самих систем, и между системами), то для одной и той же ВИУД могут использовать различные способы ее привязки. Кроме того, в соответствие с некоторыми ПЛБ, мо­ жет обеспечиваться конфиденциальность ВИУД.

Так как в ССБ появляются новые элементы, привязка ВИУД к элементам является непрерывным процессом. ЦБ ССБ, его посредники или другие полномочные объекты могут удалять или добавлять привязки ВИУД по своему усмотрению, но в соответствии с действующей политикой обеспечения безопас­ ности. ЦБ ССБ может изменять привязку ВИУД к элементу, как необходимое следствие изменения политики обеспечения безопасности или атрибутов. Привязанная ВИУД может вклю­ чать указатели времени ее действия, что позволяет в целом ми­ нимизировать объем ВИУД, которая впоследствии может быть аннулирована.

Время, в которое осуществляется привязка ВИУД к элемен­ ту, и объект, от которого зависит применение того или иного способа привязки, определяется типом элемента. Инициаторы будут получать привязанную к ним ВИУД от ЦБ ССБ или его посредников только в тот момент времени, когда сами инициа­ торы будут способны организовать доступ.

188

Все целевые объекты будут получать привязанную к ним ВИУД от ЦБ ССБ или его посредников только тогда, когда они сами будут доступны. Целевые объекты, которые были сформиро­ ваны прикладным процессом от имени пользователя или другого прикладного процесса, будут получать свою, привязанную к ним ВИУД в процессе своего формирования или после него. ВИУД, привязанная к таким целевым объектам, может быть ограничена вследствие определенных условий, содержащихся в ВИУД, при­ вязанной к пользователю или прикладному процессу.

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

Преобразование ВИПР в форму, приемлемую для ФПРРмодуля. Если допускает ПЛУД и если разрешено использование способа привязки, то подмножество ВИУД, привязанной к ини­ циатору или целевому объекту, может быть отобрано инициато­ ром или целевым объектом, для использования в ФПРР-модуле с целью принятия соответствующих решений, касающихся УД. ВИУД, привязанная к одному элементу, может быть временно привязана к другому элементу, например когда один объект дей­ ствует от имени другого объекта.

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

Существуют три варианта получения ВИПР, необходимой для принятия решения относительно инициатора, целевого объ­ екта или запроса доступа:

а) ВИПР может быть предварительно размещена в одном или нескольких компонентах ФПРР-модуля после раз-

189

мещения ВИУД (содержащихся в ней значений параме­ тров);

b)ВИПР может быть извлечена из привязанной ВИУД, ко­ торая была доставлена для компонентов ФПРР-модуля в течение процедуры УД (возможно при попытке установ­ ления доступа);

c)ВИПР может быть извлечена из привязанной ВИУД, которая получена из других источников (например

уполномоченный Службы единого каталога1). Ини­ циатор или целевой объект получают необходимую с соответствующей привязкой ВИУД (которая для ФПРР-модуля неотличима от Ь)), и ФПРР-модуль получает необходимую с соответствующей привязкой ВИУД (которая для инициатора или целевого объекта неотличима от а)).

Средства, с помощью которых ФПРР-модуль получает ВИУД с соответствующей привязкой, а также доставляет соот­ ветствующую ВИПР, не определены. ВИУД с соответствующей привязкой к инициатору или целевому объекту не обязательно доставляется инициатором или целевым объектом, соответст­ венно. ВИУД с соответствующей привязкой к запросу доступа не обязательно доставляется в составе запроса доступа.

1 Служба единого каталога (The Directory) представляет собой со­ вокупность открытых систем, которые кооперируются с целью форми­ рования и последующей эксплуатации логической (виртуальной) базы данных, содержащей информацию о группах объектов реального мира. Пользователи Каталога, включая физические лица и компьютерные про­ граммы, имеют возможность читать или модифицировать информацию, или ее отдельные части, если, конечно, они имеют на это разрешение. Каж­ дый пользователь, представленный в доступном сегменте Каталога, имеет прикладной программный модуль пользователя Каталога (Directory User Agent — DUA-клиент) или прикладной программный модуль, реализую­ щий протокол упрощенного доступа к Каталогу (Lightweight Directory Access Protocol Client — LDAP-клиент). Каталог является основой гло­ бальной инфраструктуры открытых ключей (Public Key Infrastructure — PKI-инфраструктура), база данных которого, в частности, содержит ин­ формацию о СЕРТ открытых ключей пользователей.

190

ФПРР-модуль должен быть способен недвусмысленно опре­ делить, что ВИПР была извлечена соответствующим ЦБ ССБ из ВИУД, привязанной к элементам.

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

Аннулирование ВИПР. После аннулирования ВИУД любые попытки использования ВИПР, извлеченной из этой ВИУД, должны заканчиваться запретом на установление доступа. Даль­ нейшее использование ВИПР, извлеченной из аннулированной ВИУД, до ее аннулирования должно предотвращаться, а любые попытки ее использования должны заканчиваться отказом в доступе. Если доступ, основанный на такой ранее извлеченной ВИПР, продолжается, а в это время ВИУД была аннулирована, то в действительности ПЛУД может потребовать, чтобы доступ был прекращен.

4.1.23. Ретрансляция ВИУД

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

На рис. 4.3 проиллюстрирована ситуация, при которой объ­ ект А запрашивает объект В, чтобы последний обеспечил доступ к объекту С. На этом рисунке не отображены некоторые компо­ ненты УД, которые могли бы участвовать в процедуре установ­ ления доступа.

191

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

Следующие примеры дают представление о диапазоне воз­ можных разновидностей ретрансляции ВИУД:

a)среди наиболее простых разновидностей объект А может запрашивать объект В с целью обеспечения доступа, и при этом ВИУД, привязанная к объекту В, будет вполне приемлемой и достаточной для доставки запроса доступа в интересах объекта А;

b)объекту А может понадобиться предоставить часть или всю ВИУД, необходимую для запроса доступа, который был бы санкционирован всеми компонентами УД:

• объект А может предоставить необходимую ВИУД путем ее передачи объекту В при запросе доступа;

• объект А может запросить предварительную автори­ зацию у объекта С до того, как он запросит объект В обеспечить доступ. В таком случае объект А мог бы предоставить ВИУД объекту С, который, в свою оче­ редь, мог бы в ответе передать объекту А соответству­ ющий маркер доступа. Этот маркер доступа может быть передан объектом А объекту В вместе с запросом доступа. Затем объект С может распознать маркер до­ ступа, как запись о предварительной авторизации.

192

На рис. 4.3 может быть показано произвольное число проме­ жуточных объектов, и говоря о ФПРИ-модуле последнего целе­ вого объекта, можно указать, что получение решения о доступе, как правило, основано на ВИУД, полученной от одного или не­ скольких участвующих в ретрансляции объектов.

Рис. 4.3. Ретрансляция ВИУД

ПРИМ ЕЧАНИЕ. Разработчик ПЛУД должен осознавать, что без обеспечения промежуточных процедур УД можно предоста­ вить доступ, который мог быть напрямую запрещен.

4 ,1,3 . Р асп р ед ел ен и е ко м п о н е н то в У Д

ФПРИили ФПРР-модуль может состоять из одного или нескольких компонентов УД. Функции УД могут быть рас­ пределены между этими компонентами на основе требований ПЛУД. Рассмотренные ранее базовые функции УД не зависят от условий расположения компонентов, связей между ними или их возможного распределения.

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

Совмещение (сильная связность) ФПРИ- и ФПРР-модулей может дать преимущества, касающиеся эффективности и свое­ временности (снижение задержки), а также может отменить

193