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

Доверительные отношения (trust)

Делегирование (delegation)

Авторизация (authorization)

Авторизация – это процесс принятия решения, может ли аутентифицированный принципал получить доступ к конкретному защищенному ресурсу.

Спецификация CORBA Security Service разрешает самые различные подходы выполнения авторизации. Проверка может выполняться как на стороне клиента, так и сервера. Эта проверка может быть выполнена в коде, написанном разработчиком серверного приложения, а может – на основе данных, заданных администратором безопасности системы таким образом, что приложений даже не знает о выполнении такой проверки.

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

Делегирование – это передача полномочий (прав и привилегий) при выполнении цепочки вызовов. В этом случае нужно различать «первоначального» клиента (initiator), промежуточный (intermediate) и конечный серверы (final target). Каждый промежуточный объект в последовательности вызовов выступает в роли как сервера (по отношению к объекту, который непосредственно обращается к нему), так и клиента (по отношению к следующему промежуточному или конечному серверу в цепочке вызовов). Поддерживаемые спецификацией Сервиса Безопасности варианты делегирования будут рассмотрены ниже.

В широком понимании смысла этого термина, доверительные отношения – это отношения двух участников обмена информацией, для которых можно отказаться от выполнения действий и проверок, обязательных в других случаях. Следствия установки доверительных отношений могут быть самые различные. Например, отказ от выполнения аутентификации «доверенного» клиента при его обращении к «доверенному» серверу, выполнение облегченной процедуры шифрования или даже отказ от шифрования, отказ или облегченная процедура авторизации и т.п. Часто говорят, что установка доверительных отношений между конкретными сервисами приводит к заданию «защищенного взаимодействия» (security association).

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

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

Все это приводит к тому, что спецификация делит функциональность 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 давние дружеские отношения.

Дата добавления: 2014-01-05