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

4.1.1. Цель управления доступом

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

• неавторизованное (несанкционированное) использование;

• раскрытие (вскрытие);

• модификация;

• разрушение;

• отказ в обслуживании.

Частными целями УД являются:

• УД процессов (которые могут функционировать от имени пользователей или других процессов) к данным, другим процессам или вычислительным ресурсам;

• УД в рамках сетевого сегмента безопасности (ССБ) или через один или не­сколько ССБ;

• УД в соответствие с его условиями (например, зависимость от таких факто­ров, как время неудачной попытки доступа, размещение (местопо­ложение) средства доступа или маршрут доступа);

• УД, которое реагирует на изменения авторизации в течение периода дос­тупа.

4.1.2. Основные аспекты уд

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

• физические объекты (например, реальные системы);

• логические объекты (например, объекты уровней ЭМВОС или Интернет-ар­хитектуры, файлы, организации и предприятия);

• пользователи (физические лица).

УД в реальных системах может потребовать проведения целого ком­плекса процедур (мероприятий). Такими процедурами являются:

• формирование структуры ПЛУД;

• определение формата данных (информации) для УД (Access Control Infor­mation — ВИ для обеспечения УД, ВИУД-формат);

• размещение ВИУД в элементах (инициаторы, целевые объекты или за­просы доступа);

• привязка ВИУД к элементам;

• преобразование вспомогательной информации, необходимой для приня­тия решения при УД (Access Control Decision Information — ВИПР), в форму, приемлемую для реализации (выполнения) функции принятия решения о предоставлении (отказе) доступа (Access Control Decision Function — ФПРР);

• реализация функций УД;

• изменение ВИУД (в любой момент времени после размещения соответст­вующей ВИУД, включая аннулирование);

• аннулирование ВИПР.

Эти процедуры могут быть разделены на две группы:

• функциональные (преобразование ВИПР в форму, приемлемую для реали­зации ФПРР, и выполнение ФПРР);

• обеспечивающие (все оставшиеся мероприятия).

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

4.1.2.1. Реализация функций уд

На Рис. 4.1 и 4.2 представлены функции, являющиеся основополагаю­щими при УД. Другие функции могут быть необходимы в течение всей проце­дуры УД.

Основными объектами и функциями, привлекаемыми в процессе УД, яв­ляются инициатор (initiator), функция принуждения при УД (Access Control Enforcement Function — ФПРИ), ФПРР и целевой объект (target).

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

Рис.4.1. Основополагающие функции при УД

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

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

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

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

Рис.4.2. Функция принятия решения при УД

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

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

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

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

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

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

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