Корпоративные информационные системы

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

11.8.2 Структура CORBA Security Service

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

Все это приводит к тому, что спецификация делит  функциональность Security Service на группы: есть интерфейсы, реализация которых  обязательна для совместимости  со стандартом, есть интерфейсы, реализация которых является необязательной. Это  не единственный критерий разделения интерфейсов на группы. Еще одним критерием является обеспечиваемый уровень совместимости различных реализаций. Очевидно, что совместимость связана с использованием определенных ограничений, отказ от которых приведет к отказу и от совместимости.

Спецификация  вводит группа интерфейсов, называемые «пакетами» (package). Определено 7 групп  таких пакетов:

1. Пакеты, определяющие  основную, наиболее затребованную  и часто используемую в реальных  системах, функциональность Сервиса  Безопасности. В эту группу входят два основных пакета (если разработчик реализации объявляет, что ORB поддерживает CORBA Security Service, то он должен реализовать хотя бы один из этих пакетов):

• Пакет уровня 1 (Level 1). Он содержит функциональность, которая обеспечивает защиту ресурсов средствами только ORB и Security Service, без явного использования Security Service API в коде самого приложения. Такие приложения в спецификации называются security unawared-приложениями, т.е. приложениями, при изучении кода которых нельзя узнать, будут ли при выполнении этого приложения задействованы механизмы обеспечения безопасности CORBA. Разумеется, в этом случае нет возможности управлять доступом к ресурсам на основе информации, которая станет известна только на этапе работы программы, например, текущего значения аргументов вызова или времени выполнения запроса.
• Пакет уровня 2 (Level 2). Функциональность сервиса на этом уровне позволяет явно управлять режимом доступа с помощью кода самого приложения. Кроме того, на уровне 2 объявлены средства администрирования, базирующиеся на использовании политик (policies) обеспечения безопасности.

2. Пакеты, определяющие  вспомогательную (optional) функциональность  Сервиса Безопасности, которая используется  только в некоторых реальных  системах. В настоящий момент в эту группу входит единственный пакет, связанный с обеспечением «доказательности» (“non-repudiation”) выполняемых действий. Эту функциональность можно трактовать как ведение журналов, в которые заносится информация о том, кто отправил данные и кто их получил. Предполагается, что надежность методов хранения такой контрольной информации такова, что на нее можно ссылаться при разрешении конфликтов даже на уровне юридических разбирательств.

3. Пакеты обеспечения  взаимозаменяемости реализаций (Security Replaceability packages). Это очень важные пакеты, которые влияют на то, насколько гибко ORB может взаимодействовать с Сервисом Безопасности (разумеется, эти пакеты интересны в первую очередь разработчикам реализаций ORB и CORBA Security Service, а не прикладным программистам). Тем не менее, знание таких особенностей реализации ORB может пригодиться на этапе выбора нужной реализации ORB.

В эту группу входят два пакета, оба обеспечивают возможность взаимодействия ORB с  различными реализациями Security Service, но разными путями:

• Обеспечение взаимозаменяемости на уровне ORB (ORB services replaceability package). При таком подходе сам ORB почти либо совсем не «общается» с сервисом безопасности – вместо этого на нем регистрируются специальные интерсепторы, которые и взаимодействуют с Сервисом Безопасности. Порядок вызова методов этих интерсепторов и их функциональности определена в этом пакете спецификации.
• Обеспечение взаимозаменяемости на уровне взаимодействия с Security Service (Security Service replaceability package). Этот пакет определяет, если можно так выразиться, «интерфейс» Сервиса Безопасности при его взаимодействии с ORB. Использование этого интерфейса приводит к тому, что ORB и Сервис Безопасности становятся максимально независимыми друг от друга, что позволяет использовать различные реализации ORB и CORBA Security Service при совместной работе. В таком режиме ORB может и не использовать интерсепторы – обращение к переносимому API из кода самого ORB’а обеспечивает определенный уровень взаимозаменяемости.

Реализация ORB’а может не использовать ни один из этих подходов – вся необходимая функциональность может быть встроена в код реализации ORB’а. В этом случае не приходится говорить о гибкости настроек и способности ORB’а взаимодействовать с различными реализациями CORBA Security Service.

Спецификация  называет реализации ORB, которые поддерживают функциональность одного из этих пакетов, как «ORB, взаимодействующий с сервисом безопасности» (Security Ready ORB). Обратите внимание, что ORB может обеспечивать защищенное взаимодействие, но не относиться к классу Security Ready.

4. Общие средства обеспечения переносимости (Common Secure Interoperability (CSI) Feature packages). Определены три уровня переносимости:

• CSI уровня 0. Этот уровень характеризуется тем, что нет поддержки делегирования привилегий. При обращении первоначального клиента к серверному объекту передается только идентификатор этого клиента (и никакие другие атрибуты). Если этот серверный объект является промежуточным серверным объектом, т.е. обращается к другому серверному объекту, то при обработке этого последующего вызова будет использован идентификатор промежуточного объекта, а не первоначального клиента.
• CSI уровня 1. На этом уровне по-прежнему может передаваться только идентификатор первоначального клиента, но не его другие атрибуты, зато этот идентификатор может передаваться дальше по цепочке вызовов. Такое делегирование называется «неограниченным» (unrestricted). Промежуточные серверы с точки зрения прав доступа рассматриваются как первоначальные клиенты. В спецификации и литературе часто используется термин «подражание» (impersonation).
• CSI уровня 2. Этот уровень обеспечивает совместимость ORB со всей функциональностью Сервиса Безопасности. Поддерживается передача не только идентификатора принципала, но и всех его атрибутов (включая роли и группы). Возможна передача и использование привилегий сразу нескольких принципалов – так называемое «комплексное делегирование» (composite delegation).

Стоит обратить внимание на то обстоятельство, что все три уровня совместимости обеспечивают базовые возможности по защите информации.

5. Пакет обеспечения  переносимости на уровне протокола  (SECIOP Interoperability package). ORB, реализующий  функциональность этого пакета, способен генерировать и передавать информацию, связанную с защитой ресурсов, на уровне объектных ссылок и протокола GIOP. Это означает, что два SECIOP-совместимых различных ORB’а способны взаимодействовать друг с другом в защищенной среде – в случае, если они используют одни и те же (или совместимые) технологии защиты данных.

6. Пакеты используемых  механизмов обеспечения защиты (Security Mechanism packages). Как уже говорилось, CORBA Security Service позволяет использовать  качестве реализации самые различные  технологии и подходы. Тем не менее, спецификация формально оговаривает интерфейсы, связанные с применением следующих четырех стандартных протоколов:

• Протокол SPKM. Протокол позволяет использовать открытые ключи и с точки зрения поддержки и делегирования атрибутов принципала соответствует CSI уровня 0.
• Протокол GSS Kerberos. C точки зрения поддержки и делегирования атрибутов принципала соответствует CSI уровня 1.
• Протокол CSI-ECMA. C точки зрения поддержки и делегирования атрибутов принципала соответствует CSI уровня 1, хотя может при желании использоваться в соответствие с правилами CSI 1 и 0.
• Протокол SSL. C точки зрения поддержки и делегирования атрибутов принципала соответствует CSI уровня 0.

Использование трех первых протоколов требует, чтобы ORB поддерживал расширения протокола IIOP, соответствующие требованиям SECIOP. Использование SSL не предъявляет к реализации ORB каких-либо специфических требований – обеспечение защиты данных ложится на уровень транспортного протокола, т.е. более низкий логический уровень, чем уровень CORBA.

7. Последний  пакет связан с обеспечением  безопасности при взаимодействии CORBA и DCE – технологии создания  распределенных систем, с которой  у CORBA давние дружеские отношения.

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

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

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

Рисунок 11.1

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

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

 
Рисунок 11.2

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

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

 
Рисунок 11.3

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

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

 
Рисунок 11.4

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

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

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

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

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

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

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

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

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

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