Причины возникновения

Основным предназначением КДОР является упрощение управления и надзора за безопасностью. Большое количество коммерчески успешных систем контроля доступа для центральных процессоров применяют роли для управления безопасностью. Например, роль оператора может иметь доступ ко всем ресурсам, но не может изменять разрешения на доступ, а роль аудитора может иметь доступ к контрольному журналу сделок. Это административное использование ролей можно также обнаружить в современных сетевых операционных системах, например, в Novell Netware и Microsoft Windows NT.

Нынешний всплеск интереса к КДОР сфокусировался на общей поддержке КДОР на уровне программ. В прошлом, как и сегодня, уже разработаны особые программы с встроенным в них КДОР. Существующие операционные системы и окружение дают немного возможностей для поддержки использования КДОР на уровне программ. Такая поддержка только начинает появляться в программных продуктах. Основной трудностью является разработка таких устройств, которые бы не зависели от программного обеспечения и были бы достаточно гибкими и одновременно простыми в использовании, для поддержки большого количества программ с минимальной необходимостью в настройке.

Усложненные версии КДОР имеют возможность устанавливать отношения между ролями, а также между разрешениями и ролями и между пользователями и ролями. Например, две роли могут быть определены как взаимоисключающие, поэтому один и тот же пользователь не будет допущен к обеим ролям одновременно. Роли также могут принимать отношения наследования, по которым одна роль наследует разрешения, приписанные другой роли. Эти отношения между ролями могут быть использованы для применения такой политики безопасности, в которую включено разделение обязанностей и передача полномочий. Прежде, подобные отношения должны были быть закодированными в программное обеспечение; при использовании КДОР они могут быть определены всего один раз для домена безопасности. С помощью КДОР возможно предопределить отношения роли и разрешения, что упрощает назначения пользователям предопределенных ролей. Исследование NIST [1] показывает, что разрешения, назначенные ролям, имеют тенденцию меняться относительно редко по сравнению с изменениями в распределении пользователей по ролям. Анализ также рекомендует разрешать администраторам назначать и аннулировать членство пользователей в имеющихся ролях без наделения данных администраторов полномочиями создавать новые роли или изменять назначения ролей по разрешению.

Назначение ролей пользователям обычно предусматривает наличие более низкого уровня технических навыков, чем наделение ролей разрешениями. Без КДОР, тем не менее, определить, какие разрешения даны каким пользователям, может быть затруднительно.

Стратегия контроля доступа встроена в различные компоненты КДОР, как, например, в отношения между ролью и разрешением, пользователем и ролью, ролью и ролью. Данные компоненты коллективно определяют, может ли определенный пользователь быть допущенным к определенному разделу данных в системе. Компоненты КДОР могут быть сконфигурированы непосредственно владельцем системы или косвенно соответствующими ролями, как это определено владельцем системы. Стратегия, используемая в определенной системе является общим результатом точной конфигурации различных компонентов КДОР по указанию владельца системы. Более того, стратегия контроля доступа может проходить внутреннее развитие в течение жизненного цикла системы, а в больших системах так скорее всего и происходит. Важным преимуществом КДОР является возможность модифицирования стратегии для удовлетворения изменяющихся потребностей организации.

Несмотря на то, что стратегия КДОР является нейтральной по своей сути, она непосредственно поддерживает три широко известных принципа безопасности: минимальные привилегии, разделение обязанностей и абстрагирование данных. Минимальные привилегии поддерживаются с помощью того, что КДОР можно настроить так, чтобы только те разрешения, которые требуются для функций, выполняемых членами данной роли, допускались к ней. Разделение обязанностей достигается с помощью контроля за тем, чтобы в работе, требующей особой безопасности, участвовали взаимоисключающие роли, например, требуя участия рядового бухгалтера и главного бухгалтера в процедуре выписывания чека. Абстрагирование данных поддерживается с помощью абстрактных разрешений, например, кредит и дебит для бухгалтерского объекта вместо разрешений на чтение, запись и выполнение, обычно предоставляемых операционной системой. Тем не менее, КДОР не может принудительно обеспечить выполнение этих принципов. Работник службы безопасности может настроить КДОР так, что он будет нарушать данные принципы. Кроме того, уровень поддержки абстрагирования данных определяется деталями применения.

КДОР не является панацеей от всех проблем контроля доступа. Необходимо использование более сложных форм контроля доступа в ситуациях, когда возникает необходимость контроля последовательности операций. Например, предписание покупки требует ряда шагов, необходимых до выписки заказа на поставку. КДОР не ставит перед собой целью непосредственно контролировать разрешения для подобной последовательности событий. Другие формы контроля доступа могут быть надстроены над КДОР для этой цели. Мохаммед и Дилтс [3], а также Томас и Сандху [4] уже рассматривали некоторые из этих проблем. Мы рассматриваем контроль последовательности операций лежащим за пределами КДОР, хотя КДОР может служить основанием для создания подобного контроля.

Дата добавления: 2015-12-01