4.5.5. Другие слб, связанные с уд

При проведении процедуры запроса доступа привлекается не только служба УД, а могут привлекаться и другие СЛБ, среди которых:

• служба аудита регистрирует (записывает) произвольную информацию о за­просе доступа;

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

• служба взимания платы гарантирует, что на счёт поступит соответствую­щая сумма, необходимая для использования доступного ресурса.

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

4.6. Обмен серт|уд между компонентами

4.6.1. Ретрансляция нескольких серт|уд

В некоторых случаях может понадобиться несколько СЕРТ|УД для обес­печения сложной ПИнО.

Рис. 4.5. Ретрансляция нескольких СЕРТ|УД

4.6.1.1. Пример

Предположим (рис. 4.5), что пользователь U обращается к прикладной системе А1, чтобы последнее запросило доступ к прикладной системе А2. Каж­дый запрос доступа формируется А1 и направляется А2. Однако, А2 может ис­пользовать службы другой прикладной системы А3 с целью удовлетворения за­проса. В свою очередь, А3 для решения этой задачи могут понадобиться службы прикладной системы А4.

Во-первых, рассмотрим взаимосвязь между А1 и А2, а также СЕРТ|УД, которые могут быть использованы при запросе доступа А1 к А2. Очевидно, что могут потребоваться два СЕРТ|УД: для пользователя U и для прикладной сис­темы А1.

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

• СЕРТ|УД, необходимые для доступа к А2 и действительные для всех проце­дур (операций);

• СЕРТ|УД, необходимые для доступа к А2 и действительные для группы (со­вокупности) процедур (операций);

• СЕРТ|УД, необходимые для доступа к А2 и действительные для одной про­цедуры (операции).

В принципе, каждый СЕРТ|УД можно получить в разных ЦБ ССБ.

СЕРТ|УД, действительные для всех процедур (операций), доставляются в фазе установления соединения или начальной фазе процедуры информацион­ного обмена.

Когда СЕРТ|УД определяют набор допустимых процедур (операций), то они остаются неизменными до тех пор, пока не будут доставлены другие СЕРТ|УД этого класса.

СЕРТ|УД, действительные для одной процедуры (операции), ограничи­ваются только этой процедурой (операцией).

4.6.1.2. Обобщение

Далее, рассмотрим взаимосвязь между А2 и А2, а также СЕРТ|УД, кото­рые могут быть использованы при запросе доступа А2 к А3. Очевидно, что мо­гут потребоваться три СЕРТ|УД: для пользователя U, для прикладной системы А1 и для прикладной системы А2.

СЕРТ|УД для пользователя U и прикладной системы А1, предназначен­ные для использования при доступе к А2, могут или не могут быть применимы и при доступе к А3. Если они применимы, то каждый из этих сертификатов мо­жет быть любым сертификатом из трёх классов, рассмотренных выше. Если же они не применимы, то пользователь U или прикладная система А1 (или оба) при запросе доступа к А2 должны получить дополнительный СЕРТ|УД для доступа к А3, который также может быть любым сертификатом из трёх классов, рас­смотренных выше.

Рассмотренная схема может быть обобщена и для взаимодействия между А3 и А4, и при этом могут понадобиться дополнительные сертификаты для U, А1 или А2.

4.6.1.3. Упрощения

Обычно необходим только СЕРТ|УД от пользователя U или от приклад­ной системы А1. СЕРТ|УД, действительные только для одной процедуры (опе­рации), используются крайне редко. СЕРТ|УД от U, предназначенный для дос­тупа к А2, может ретранслироваться системой А1, даже если последняя его не использует.

4.7. Управление доступом в ЭМВОС и Интернет-архитектуре

4.7.1. Общие положения

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

4.7.2. Использование УД внутри уровней ЭМВОС и

Интернет-архитектуры

УД касается только следующих уровней ЭМВОС и Интернет-архитек­туры:

• сетевой (3-й) уровень;

• транспортный (4-й) уровень;

• прикладной (7-й) уровень (5-ый уровень для Интернет-архитектуры).

4.7.2.1. Использование УД на сетевом уровне

УД, применяемое на сетевом уровне, позволяет управлять доступом к се­тевым узлам и/или из них, к узлам подсетей и/или из них, и к ретрансляцион­ным узлам и/или из них. УД на сетевом уровне может иметь многоцелевое применение. Например, оно позволяет оконечным системам контролировать формирование сетевых соединений или отклонять нежелательные вызовы. Кроме этого, оно позволяет одной или нескольким подсетям контролировать использование ресурсов сетевого уровня. В отдельных случаях, контроль ис­пользования ресурсов сетевого уровня связан с оплатой за пользование сетью.

Способы УД, используемые на сетевом уровне, не выходят за пределы одного и того же уровня.