Аутентификация. 
Защита информации

Технология RBAC — это механизм контроля доступа, который может быть использован в связке с существующими Веб-технологиями аутентификации и обеспечения конфиденциальности. Они включают в себя пользователь/пароль, протокол защищенных сокетов (SSL), защищенный HTTP (SHTTP), протокол технологии частных сообщений (РСТ). Информация идентификации пользователя передается в RBAC/Web от Веб-сервера. Это ответственность Веб-ссрвера аутентифицировать пользовательские идеитификационные данные и предоставить конфиденциальную передачу данных так, как сконфигурировано администратором Веб-сервера.

Использование конечным пользователем

Конечный пользователь взаимодействует с Веб-сервером, усовершенствованным с помощью RBAC/Web, в основном также, как при запросе URL (адресов), которые не контролируются RBAC/Web (см. рис. 16.3). Однако до того как доступ по адресу, контролируемому RBAC/Web, будет разрешен, пользователю необходимо установить RBAC-сессию. В процессе установки RBAC-сессии пользователь выбирает или ему назначается текущий активный набор ролей (ARS). ARS определяет разрешенные операции, которые конечный пользователь может осуществлять с контролируемыми RABC-адресами. ARS остается активным до тех пор, пока пользователь не установит новую ARS. Эта ARS и составляет сессию RBAC.

Пользователю могут быть назначены роли, которые имеют DSD взаимосвязи. В этом случае система управления сессиями позволяет пользователям выбрать подмножество из набора назначенных ролей, которые они хотят использовать в текущей сессии. Пользователям предлагается список подмножеств, которые не нарушают никаких DSDвзаимоотношений, и возможность выбрать один из них. Чтобы минимизировать количество вариантов, в списке подмножеств, взятых из набора всех возможных подмножеств назначенных пользователю ролей, содержатся наибольшие подмножества, которые не имеют DSD-взаимосвязей. Как только выбор сделан, RBAC-сессия установлена со всеми авторизованными ролями (то есть назначенные роли наряду со всеми ролями, которые назначенные роли наследуют), помещенными в ARS. Если нет никаких отношений DSD среди ролей, назначенных пользователю, то сессия RBAC автоматически устанавливается со всеми разрешенными ролями в ARS.

Рис. 16.3. Использование RBAC/Web.

Обычно сессия RBAC требует аутентификации пользователя. Если аутентификация удалена у конечного пользователя, то доступ к контролируемым RBAC-адресам запрещается. Однако аутентификация конечного пользователя и установление сессии RBAC полностью раздельные операции. Это позволяет RBAC/Web работать с любым механизмом аутентификации.

Реализация ролевой системы управления доступом с использованием объектного подхода

В Ролевой системе управления доступом (RBAC) каждая роль ассоциирована с набором операций, которые пользователь в этой роли может выполнить. Мощность RBAC как системы, управляющей доступом, состоит в том, что операцией может быть теоретически все что угодно. Это резко отличает ее от других систем доступа, в которых биты или метки связаны с информационными блоками. Эти биты или метки указывают относительно простые операции, например, — чтение или запись, которые могут быть выполнены в информационном блоке. Операции в RBAC могут быть достаточно сложными. Цель реализации RBAC — позволить операциям, связанным с ролями, быть настолько общими, насколько возможно до тех пор, пока они неблагоприятно не сужают гибкость администрирования и поведения приложения.

Рассмотрим возможную деятельность, связанную с определением и модификацией роли:

• — добавлять роль и связанные операции;
• — удалять роль и связанные операции;
• — модифицировать существующую роль:
• — добавьте операцию;
• — удалите операцию;
• — модифицируйте существующую операцию.

Информация обычно доступна для приложения через фиксированный набор операций, определенных в каком-либо механизме или процессоре, которые используются для доступа к информации. Приложения строятся, основываясь на фиксированном наборе операций, которые они регулярно выполняют. Например, в Юникс файлы доступны с помощью операций, определенных процедурами: open (), close (), read (), write (), fseek () и т. д. Таблицы в реляционной базе данных доступны с помощью операций, определенных в SQL.

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

Рис. 16.4. Реализация RBAC с многоуровневыми объектами.

Единый подход, который может быть использован для поддержания гибкого администрирования, минимизации влияния на приложение и поддержание важной возможности определения сложных операций, — это использование Объектной технологии вышеуказанным способом (см. рис. 16.4). Полный набор операций, основанных на методах доступа, связанных с механизмом хранения информации, определен и поддерживается постоянным. Эти операции доступны приложению. Эти операции становятся методами в классе базовых методов доступа (basic access methods class).

Управление доступом для класса базовых методов доступа осуществляется с помощью Ролевых классов (role class) — по одному для каждой роли. Методы ролевых классов имеют те же имена, типы и параметры, что и методы класса базовых методов доступа. Управление доступом к информации, доступной с помощью класса базовых методов доступа, находится исключительно в ролевых классах и нигде более в приложении. Содержание методов ролевых классов ограничено:

• — условиями, которые определяют доступ роли, связанной с этим классом;
• — фильтрами, которые суживают поток информации между интерфейсом приложения и базовыми методами доступа.

Если доступ ролей разрешен, то методы ролевого класса вызывают соответствующие методы класса базовых методов доступа. Если не вся информация, полученная от базовых методов доступа, разрешена роли, то та часть информации, которая не разрешена, может быть отфильтрована. Фильтрация может быть более пригодна для приложения, чем генерация нарушения доступа для целого информационного блока.

Методы класса интерфейса приложения также имеют те же имена, типы и параметры, что и методы класса базовых методов доступа. Методы объекта интерфейса приложения вызывают надлежащие методы ролевого класса. Это методы объекта интерфейса приложения, которые приложение вызывает. Используя текущую роль, связанную с приложением, методы объекта интерфейса приложения выбирают подходящий ролевой объект.

Этот подход имеет следующие преимущества:

— приложения не надо изменять при изменении параметров доступа для ролей.

Приложение использует методы класса интерфейса приложения, чьи методы имеют те же имена, типы и параметры, что методы в классе базовых методов доступа. Методы класса интерфейса приложения и методы класса базовых методов доступа фиксированы и остаются постоянными. Когда параметры доступа роли меняются, приложение сбоит лишь по причине нарушения доступа. Этот тип сбоев сравним со сбоями, обычно возникающими при изменении битов защиты информации или меток. Приложения обычно реализуются гак, чтобы правильно обрабатывать нарушения защиты.

— параметры доступа для ролей легко изменяются.

Параметры доступа для ролей находятся исключительно в ролевых классах. Значит, изменения ролевой политики не потребует изменения в самом приложении. Можно представить простой язык, подходящий для использования администраторами безопасности и данных, для выражения условий доступа, ограниченных условными выражениями и фильтрами. Процессор для этого языка мог бы генерировать ролевые объекты и размещать их в библиотеках, используемых приложениями. Большинство современных контекстов выполнения (окружений) поддерживают динамически скомпонованные библиотеки, которые подключаются при загрузке приложения в память для выполнения. Для этих приложений не надо выполнять повторную компоновку при изменении ролевых классов. Эта возможность легко менять условия доступа, связанные с ролью, позволяет быстро отвечать на изменения политики безопасности.