4.2.4. Унаследованные правила

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

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

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

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

4.2.5. Приоритет среди правил плуд

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

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

В ситуациях, когда запрос доступа «затрагивает» несколько ССБ, то должны соблюдаться принципы, на основе которых формируются ПБВ.

4.2.6. Правила плуд в режиме «по-умолчанию»

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