Делегирование в CORBA Security Service

Графически возможные (согласно спецификации) схемы делегирования можно выразить следующим образом:

• Запрет делегирования.

Рисунок 11.1

Каждый промежуточный объект, участвующий в цепочке вызовов, выступает от «собственного имени» и использует свои атрибуты и привилегии.

• Простое (simple) делегирование.

Рисунок 11.2

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

• Комплексное (composite) делегирование.

Рисунок 11.3

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

• Комбинированное (combined) делегирование.

Рисунок 11.4

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

Сервис Безопасности CORBA позволяет при делегировании вводить и другие ограничения. Например, клиенты и промежуточные сервера могут делегировать только часть своих полномочий; администратор или программист может задать период времени, в течение которого можно использовать делегирование и т.д.

Для приложений, которые непосредственно не обращаются к API Security Service (Level 1), режим делегирования задается по умолчанию с использованием политик безопасности, и промежуточные объекты не могут в процессе работы приложения менять указанный способ делегирования.

Домены безопасности

Одним из важных понятий спецификации Сервиса Безопасности является понятие «домена безопасности» (security domain). Доменная структура системы обеспечения безопасности оказывает непосредственное влияние и на совместимость, и на переносимость используемых программных средств, и на уровень сложности администрирования, и на эффективность работы приложений. Спецификация различает три вида доменов безопасности:

• Технологический домен (security technology domain).

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

• Домен политик безопасности (security policy domain).

CORBA Security Service обладает очень развитой системой QoS (quality of service), т.е. средствами настройки системы с точки зрения ее оптимизации по различным критериям. Спецификация вводит большое количество политик безопасности. Поскольку в CORBA «единицей защиты» является объект, то на практике защищать каждый объект отдельно совершенно нереально. Вместо этого объекты объединяются в домены политик безопасности (этот подход используется в CORBA не только для политик безопасности, но и вообще для любых политик), и в каждом таком домене единый набор политик относится ко всем объектам данного домена. Как обычно, для управления политиками на уровне домена необходимо определить менеджера этих политик (Policy Manager). Применительно к доменам политик безопасности, такой менеджер часто называется «SecurityAuthority»

Поскольку домены политик безопасности ничем принципиально не отличаются от других доменов политик CORBA, поддерживаются иерархии доменов и объединения (федерации) доменов. Домены могут перекрываться –один и тот же объект может входить в различные домены политик, например, в один домен политик с точки зрения политик управления правами доступа и в другой – с точки зрения политик аудита.

Поскольку CORBA Security Service поддерживает два вида приложений с точки зрения их явного использования API Сервиса, то можно делить домены политик безопасности еще на две группы – домены системных политик безопасности и домены прикладных политик безопасности. Задание и использование системных политик безопасности выполняется силами ORB, Сервиса Безопасности и операционной системы, и приложения об этом может даже не знать,

Рисунок 11.5

• Домен среды безопасности (security environment domain)

Понятие «домена среды безопасности» тесно связано с «доменом политик безопасности». Домен политик – это логическая область с заданным набором политик и их значений. Домен среды – это область, в которой используется некий единый подход, который обеспечивает защиту ресурсов в соответствии с заданными политиками.

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

С точки зрения организации взаимодействия в защищенной гетерогенной среде, можно также принять во внимание отличия в реализации ORB’ов, введя тем самым, понятие «домена ORB».

Общая схема организации защищенного взаимодействия объектов с учетом наличия различных технологических доменов и доменов ORB может выглядеть так:

Рисунок 11.6