Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Учебник (рукопись) ''Информационная безопасност...doc
Скачиваний:
27
Добавлен:
27.09.2019
Размер:
2.77 Mб
Скачать

4.2.1. Отображение политики уд

4.2.1.1. Категории политики уд

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

4.2.1.2. Группы и роли

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

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

Группы и ролевые объекты могут использоваться иерархически в различ­ных сочетаниях объектов-инициаторов, групп и ролевых объектов.

4.2.1.3. Метки безопасности

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

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

4.2.1.4. Плуд для нескольких инициаторов

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

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

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

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

4.2.2. Обеспечение политики

Рассмотрим три аспекта из всего спектра направлений обеспечения политики.

4.2.2.1. Фиксированные политики

Фиксированными политиками являются те, которые применяются всегда и без каких-либо изменений, например по тому, что они встроены в систему.

4.2.2.2. Административно устанавливаемые политики

Административно устанавливаемыми политиками являются те, которые применяются всегда и могут быть изменены только должным образом автори­зованным персоналом.

4.2.2.3. Политики, выбираемые пользователями

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

4.2.3. Детализация и локализация

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

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