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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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