4.4.5.4. Варианты контекстной схемы

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

4.5. Взаимодействие с другими слб и спб

4.5.1. Аутентификация

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

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

4.5.2. Обеспечение целостности данных

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

4.5.3. Обеспечение конфиденциальности данных

СЛКН может быть востребована некоторыми ПЛБ с целью обеспечения конфиденциальности входных и выходных данных, циркулирующих между компонентами УД, например, для защиты от перехвата критической информа­ции.

4.5.4. Аудит

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

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

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

Идентифицируемость процедуры доступа в условиях анонимности может быть обеспечена следующим образом:

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

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

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

Если имеет место конфликт между желанием инициатора оставаться ано­нимным и требованием ССБ, в котором расположен целевой объект, знать па­раметр подлинности инициатора, то в доступе может быть отказано. Решение в такой конфликтной ситуации зависит от ПЛУД ССБ, в котором расположен це­левой объект.