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

• Название: Корпоративные информационные системы
• Дата: 20.06.2022
• Размер: 1.72 Mb.
• Имя файла: 407f6cf.doc
• Тип: Документы; #606612
• страница: 20 из 27

11.8 Безопасность в CORBA

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

• 
  На кого – разработчиков системных средств или прикладных программ – возлагать главную часть обязанностей с точки зрения обеспечения безопасности?
  
• 
  Как обеспечить оптимальное сочетание универсальности решения с его гибкостью, эффективностью и надежностью?
  
• 
  Как обеспечить возможность (и простоту) использования в универсальной системе обеспечения безопасности уже хорошо зарекомендовавших себя различных технологических решений и подходов?
  
• 
  Как обеспечить взаимодействие приложений, использующих различные реализации систем обеспечения безопасности?
  
• 
  Как организовать относительно простое и удобное управление безопасностью для менеджеров информационных систем?
  
• 
  Как обеспечить взаимодействие подсистем с различными уровнями обеспечения безопасности?
  
• 
  Как удовлетворить требованиям обеспечения безопасности с учетом того, что требуемый уровень обеспечения безопасности очень сильно отличается для различных систем;
  
• 
  Как предложить разработчикам универсальное и эффективное решение по доступной цене?
  

Система обеспечения безопасности в CORBA (CORBA Security Service) должна была дать ответы на эти и многие другие вопросы. Она разрабатывалась долго, примерно в течение двух лет, и первая версия была принята в самом конце 1995 года. В ее разработке принимали участие специалисты из AT&T, DEC, Expersoft, Hewlett-Packard, IBM, Novell, Siemens, Sunsoft, Tivoli Systems и других компаний. В настоящий момент последней утвержденной является версия 1.8 (принята в марте 2002 года). Номер версии говорит о том, что с момента появления в сервис не вносилось кардинальных изменений, хотя появление новых спецификаций сервисов CORBA требовало учета новых реалий и разработки улучшенных версий Security Service.

Как и следовало ожидать, Security Service построен по «драйверному» принципу – спецификация содержит большое количество IDL-интерфейсов, не задавая существенных ограничений с точки зрения их реализаций. Особенностью Security Service является специфическая «область применения» интерфейсов. Большая их часть не интересует прикладных программистов – она предназначена, в первую очередь, для создателей самой реализации Сервиса Безопасности. Другая группа интерфейсов может использоваться прикладными разработчиками, если это необходимо в том или ином конкретном случае. Третья группа предназначена для обеспечения управления настройками системы на этапе ее функционирования и, следовательно, интересует, в первую очередь, администраторов систем, а также разработчиков утилит и приложений для администраторов.

Полная реализация всех – обязательных и необязательных – интерфейсов CORBA Security Service – является сложной, ресурсоемкой и дорогостоящей задачей. В настоящий момент на рынке присутствуют несколько достаточно полно соответствующих стандарту реализаций Security Service, такие, как ORBAsec компании Adiron, IONA OrbixSecurity, MICOSec от ObjectSecurity (соответствуют Security Level 2 версии 1.7 спецификации Security Service). Компания Borland предлагает расширенную службу обеспечения безопасности – Borland Security Service, сочетающую базовые возможности Security Service CORBA с реализацией безопасности в стандартах Java. Ограниченные реализации последних версий Security Service поставляются для TAO и других некоммерческих реализаций CORBA.

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

11.8.1 Основные понятия CORBA Security Service

Спецификация Security Service вводит несколько основных понятий, на которых основана модель обеспечения безопасности. Имеет смысл разобрать их достаточно подробно.

1. 
   Принципал (principal)
   

Принципалом называется пользователь или объект приложения, который должен быть идентифицирован в процессе взаимодействия и с которым должны быть сопоставлены его собственные права.

К сожалению, с использованием термина «принципал» часто происходит путаница. Связано это и со стилем самой спецификации, и с тем, что похожая терминология используется в Java-стандартах распределенных систем, а многие Java- технологии очень сильно связаны с CORBA.

Спецификация Security Service часто вместо «принципала» использует (практически как синоним) термин «субъект» (subject). Можно встретить и такую трактовку понятий «принципал» и «субъект»: субъект – это пользователь или объект, который необходимо идентифицировать перед началом собственно взаимодействия. Если субъект прошел процедуру идентификации, то с ним сопоставляются права, и этот субъект уже называется принципалом.

В Java Authentication and Authorization Service (JAAS) тоже используются термины «принципал» и «субъект», но несколько в ином значении. Кроме того, формализация этих понятий в JAAS более строгая. В JAAS субъект является совокупностью принципалов, причем под принципалом понимается некоторое имя, сопоставленное с объектом, участвующим во взаимодействии. Другими словами, один субъект (subject) JAAS может при обращении к разным сервисам выступать под разными именами, и каждое такое имя является принципалом.

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

2. 
   Аутентификация (authentication)
   

Аутентификацией называется процедура идентификации принципала – тот ли он, за кого себя выдает. Для выполнения аутентификации принципал должен предоставить не только имя, но и дополнительные атрибуты, например, пароль или сертификат. Если процедура аутентификации прошла успешно, с принципалом сопоставляются его права. Что это за права – зависит от системы администрирования, политики безопасности и т.д.

3. 
   Удостоверения (credentials)
   

Удостоверения – это набор атрибутов принципала, используемых при его аутентификации, определении прав доступа, передаче информации и в других случаях. Хорошими примерам удостоверений являются пароль или сертификат принципала. Удостоверениями часто являются привилегии (роли, группы и т.д.), сопоставленные с принципалом.

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

В системах с использованием CORBA Security Service удостоверения часто являются частью информации, неявно передаваемой по ORB (наряду с аргументами вызываемого метода, контекстом вызова и контекстом транзакции) – например, для принятия решения, имеет ли данный принципал доступ к защищенному ресурсу и/или при передаче (делегировании) полномочий при наличии цепочки вызовов.

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

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

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

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

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

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

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

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

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

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, поддерживаются иерархии доменов и объединения (федерации) доменов. Домены могут перекрываться –один и тот же объект может входить в различные домены политик, например, в один домен политик с точки зрения политик управления правами доступа и в другой – с точки зрения политик аудита.

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


Рисунок 11.5

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

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

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

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

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


Рисунок 11.6

11.8.5 Объектная модель обеспечения безопасности

Объектную модель CORBA Securtiy Service удобнее рассматривать по частям, а именно, с точки зрения различных участников процесса разработки и эксплуатации системы. Здесь мы будем рассматривать эту модель с двух точек зрения – с точки зрения разработчика приложений и администратора системы.

11.8.5.1 Модель с точки зрения разработчика

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

• 
  Определить, какие возможности поддерживаются данной реализацией сервиса (и ORB’а).
  
• 
  Задать необходимые удостоверения и привилегии принципала для последующей его аутентификации, если это необходимо.
  
• 
  Выполнить защищенный удаленный вызов.
  
• 
  Управлять режимом обеспечения безопасности на уровне промежуточных и конечных серверных объектов, управлять делегированием полномочий и принимать решение о предоставлении доступа к защищенным ресурсам.
  
• 
  Отслеживать происходящие в процессе работы системы действия.
  
• 
  Вести журнал в режиме обеспечения доказательности выполненных действий.
  
• 
  Управлять политиками безопасности для объектов.
  

Начнем с задания удостоверений и аутентификации.


Рисунок 11.7

Основой для выполнения аутентификации (если она необходима) является объект Credentials. Пути создания и настройки этого объекта могут быть различными. Например, если принципал уже аутентифицирован, то для получения объекта Credentials можно использовать интерфейс Current. Напоминаем, что интерфейсы Current, определенные в различных сервисах CORBA, в принципе предназначены для решения одной задачи, а именно: они позволяют получить доступ к информации, передаваемой по ORB, в контексте (и потоке) текущего вызова. Интерфейс Current Сервиса Безопасности обеспечивает доступ к параметрам, связанным с безопасностью (подобно тому, как интерфейс Current Сервиса Объектных Транзакций обеспечивает доступ к параметрам текущей транзакции).

В общем случае, т.е. тогда, когда принципал (User на приведенном выше рисунке) должен быть аутентифицирован, но еще не аутентифицирован.

User Sponsor (который нарисован с использованием пунктирной линии потому, что это не CORBA-интерфейс, а некоторый фрагмент кода приложения) получает от пользователя необходимые данные (например, учетное имя и пароль), а затем обращается к объекту Principal Authenticator, который проводит аутентификацию и в качестве ее результата получает объект Credentials, который содержит идентификатор принципала и его привилегии. Как правило (но не обязательно!) эти действия выполняются в клиентском приложении.

После того, как все необходимые удостоверения заданы для данного принципала, они используются при выполнении защищенных вызовов. Программист может при необходимости менять эти удостоверения. Сделать это можно двумя способами: либо изменить состояние соответствующего объекта Credentials (для чего предусмотрен метол set_attributes()), либо изменив политики на уровне самой объектной ссылки обычными средствами управления политиками CORBA (за режим привилегий при вызове отвечает политика InvocationCredentialsPolicy, рисунок 9.8).


Рисунок 11.8

В обоих случаях эффект изменений распространяется на все последующие вызовы с использованием данного объекта Credentials и/или данной объектной ссылки.

Что касается собственно выполнения защищенного удаленного вызова, то здесь все внешне выглядит, как обычно – все необходимое с точки зрения параметров безопасности выполняется ORB’ом и Сервисом Безопасности без участия самих приложений – как клиента, так и сервера.


Рисунок 11.9

Security Service перехватывает вызов и с помощью интерфейса Current получает доступ ко всем атрибутам объекта Credentials.


Рисунок 11.10

Переходим на сторону сервера. Там выполняются похожие действия –Security Service перехватывают пришедший по ORB’у запрос. Получить доступ к параметрам безопасности – идентификатору принципала и его привилениям – можно с помощью вызова метода get_attributes() интерфейса Current. Далее эти привилегии используются при принятии решения, можно ли разрешить доступ данному принципалу в контексте этого вызова к данному серверному объекту (т.е. выполняется авторизация), см. рисунок 11.10.

Похожие механизмы используются и в случае, когда имеет место цепочка вызовов, т.е. некоторый промежуточный объект выступает сначала в роли сервера, а затем, при последующем вызове – уже в роли клиента. Если приложение использует API Security Service, то промежуточный объект может анализировать параметры безопасности пришедшего запроса и, в случае необходимости, менять из перед выполнением следующего вызова в цепочке. Для этой цели опять используется интерфейс Current:



Рисунок 11.11

Для получения привилегий, содержащихся в полученном запросе, удобно использовать атрибут received_credentials интерфейса Current.

Промежуточный объект может быть самостоятельным принципалом и выполнять последующий вызов «от собственного имени». Это означает, что он должен получить свой объект Credential вместо того, чтобы извлекать существующий в контексте пришедшего запроса объект с помощью Current. В этом случае промежуточный объект обращается к методу authenticate() объекта PrincipalAuthenticator, а затем настраивает его с помощью метода set_attributes() объекта Credentials.

Что касается других аспектов управления приложением – принятия решений о предоставлении доступа или выполнении аудита – то спецификация не предусматривает объявления определенных политик и не занимается строгой формализацией этих процессов. Тем не менее, CORBA Security Service предоставляет некоторые стандартные вспомогательные объекты, например, AuditChannel – логический канал вывода информации, или AuditDecision (для принятия решения, нужно ли отслеживать определенное событие), которые удобно использовать в системе аудита,

11.8.5.2 Модель с точки зрения администратора

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

• 
  Обеспечение создания защищенных объектов, сопоставленных с политиками безопасности.
  
• 
  Обеспечение работы с менеджерами доменов для таких объектов.
  
• 
  Управление политиками с использованием этих менеджеров доменов.
  
• 
  Сопоставление операций и прав доступа.
  

Среди всех возможных видов компонентов и сервисов, которые могут использовать политики безопасности (сами приложения, ORB, реализации Сервиса Безопасности CORBA, другие сервисы), спецификация подробно описывает только то, что происходит на уровне ORB.

local interface SecurityManager { readonly attribute Security::MechandOptionsList supported_mechanisms; readonly attribute CredentialsList own_credentials; readonly attribute RequiredRights required_rights_object; readonly attribute PrincipalAuthenticator principal_authenticator; readonly attribute AccessDecision access_decision; readonly attribute AuditDecision audit_decision; ... CORBA::Policy get_security_policy (in CORBA::PolicyType policy_type); };

Прежде чем рассматривать подробнее модель администрирования, необходимо ознакомиться с основными политиками безопасности.

11.8.6 Основные политики безопасности

CORBA Security Service определяет следующие основные стандартные политики безопасности:

• 
  Политика предоставления доступа при вызове (Invocation access policy).
  

const CORBA::PolicyType SecClientInvocationAccess = 1; const CORBA::PolicyType SecTargetInvocationAccess = 2; module SecurityAdmin { interface AccessPolicy : CORBA::Policy { ... } interface DomainAccessPolicy : AccessPolicy { ... } ... };

• 
  Политика аудита при выполнении вызова (Invocation audit policy). Эта политика позволяет указать, какие события в процессе выполнения вызовов нужно отслеживать в системе аудита.
  

const CORBA::PolicyType SecClientInvocationAudit = 4; const CORBA::PolicyType SecTargetInvocationAudit = 5; module SecurityAdmin { interface AuditPolicy : CORBA::Policy { … } ... };

• 
  Политика выполнения удаленного вызова (Secure Invocation policy), которая, в частности, позволяет определить необходимость установки доверительных отношений и уровень защиты информации (Quality of Protection).
  

const CORBA::PolicyType SecClientSecureInvocation = 8; const CORBA::PolicyType SecTargetSecureInvocation = 9; module SecurityAdmin { interface SecureInvocationPolicy : CORBA::Policy { … } ./.. };

• 
  Политика делегирования при выполнении вызова (Invocation delegation policy); позволяет задать поведение промежуточного объекта, участвующего в цепочке вызовов, с точки зрения делегирования удостоверений.
  

const CORBA::PolicyType SecDelegation = 7; module SecurityAdmin { interface DelegationPolicy : CORBA::Policy { … } ... };

• 
  Политика предоставления доступа для приложения (Application access policy). Эта политика отличается от Invocation access policy тем, что может использоваться непосредственно приложением и не обязана находиться под управлением менеджера домена политик безопасности. Invocation-политики управляются и используются не приложением, а ORB’ом.
  

const CORBA::PolicyType SecApplicationAccess = 3;

• 
  Политика аудита для приложения. Как и предыдущая политика, она предназначена для использования (управления режимом аудита) непосредственно из приложения.
  

const CORBA::PolicyType SecApplicationAudit = 6;

• 
  Политика доказательности (Non-repudiation policy). Определяет режимы генерации и контроля свидетельств о событиях. За ее использование отвечает приложение, а не ORB.
  

const CORBA::PolicyType SecNonRepudiation = 10;

• 
  Политика конструирования (Construction policy), которая позволяет определить, нужно ли создавать новый домен политик безопасности при создании нового объекта с определенными политиками (CORBA::SecConstruction). Политика применяется в момент создания объектной ссылки объектным адаптором POA.
  

11.8.6.1 Управление политиками безопасности на уровне приложения

Взаимодействие с Сервисом Безопасности CORBA – явное или неявное – начинается с момента создания объектной ссылки на CORBA-объект при работе в защищенной среде. Как всегда, фабрикой CORBA-объектов являются объектные адаптеры (POA). В этот момент ORB сопоставляет объектную ссылку с разными видами доменов безопасности – политик безопасности, технологическими доменами, доменами среды. После получения объектной ссылки приложение может использовать стандартные методы типов CORBA::Object, DomainManager, CORBA::Policy для управления политиками. Графически это можно изобразить следующим образом:


Рисунок 11.12

По объектной ссылке можно получить список Менеджеров доменов, с которым сопоставлен данный объект, и найти менеджер (объект DomainManager), который отвечает за нужную политику. Метод DomainManager::get_domain_policy() обеспечивает получение объекта Policy с параметрами для указанной политики. Дальнейшая установка нужного состояния Policy-объекта зависит от того, с какой политикой необходимо работать – в CORBA Security Service предусмотрены различные интерфейсы для работы с различными политиками:

1. 
   Доказательность (non-repudiation)
   

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

По сути, поддержка доказательности сводится к ведению защищенной базы данных, в которую заносятся записи, связанные с фиксацией создания, отправки, получения и использования удаленных сообщений. Спецификация Сервиса Безопасности определяет следующие виды деятельности, информация о выполнении которых сохраняется в БД:

enum EvidenceType { SecProofofCreation, SecProofofReceipt, SecProofofApproval, SecProofofRetrieval, SecProofofOrigin, SecProofofDelivery, SecNoEvidence };

Важнейшими типами событий являются Creation (создание сообщения) и Receipt (его получение адресатом).

Заносимая в БД информация о событии обычно содержит тип события и сопоставленное с ним описание. Описание включает множество параметров, в том числе информацию о принципале, о дате и времени работы с событием и т.д. Интерфейсы обеспечения доказательности содержат методы, которые позволяют создать описание на основе его параметров.

Несколько слов о соотношении средств обеспечения доказательности в CORBA Security Service и более общих моделях обеспечения доказательности.

Существуют стандарты таких моделей. Графическое представление модели ISO-стандарта приведено на рисунке ниже:


Рисунок 11.13

Серым цветом выделен компонент, включенный в систему обеспечения доказательности CORBA в данной версии спецификации. Основная функциональность, обеспечиваемая этим компонентом:

• 
  Генерация информации о происходящих событиях.
  
• 
  Контроль (verification) этой информации.
  
• 
  Генерация запроса для информации, связанной с отправленным событием.
  
• 
  Получение запроса для информации, связанной с полученным событием.
  
• 
  Анализа информации о событии.
  

Другие аспекты обеспечения доказательности – собственно обеспечение хранения информации в БД и извлечение ее оттуда, обеспечение доставки этой информации компонентам или пользователем, непосредственно принимающим решения в случае конфликтов, само разрешение конфликтов на основе полученной информации – в спецификации CORBA Security Service не рассматриваются.

2. 
   Интерфейс Current
   

Обычно разработчики прибегают к использованию API Security Service в тех случаях, когда нужно отслеживать действия в системе и сохранять информацию об этом, предоставлять права доступа с учетом большого количества информации (в том числе той, которая известна только на момент выполнения вызова) или при организации взаимодействия с унаследованными системами.

Одним из наиболее важных интерфейсов Сервиса Безопасности является интерфейс Current - точнее, таких интерфейсов даже два – они определены в разных модулях. Это интерфейсы SecurityLevel1::Current и SecurityLevel2::Current. Получение доступа к интерфейсу Current выполняется стандартным образом, с помощью вызова для ORB метода resolve_initial_references() с аргументом «SecurityCurrent».Как обычно, после вызова метода resolve_initial_references() нужно выполнить преобразование типа результата к нужному интерфейсу Current. При преобразовании к SecurityLevel2::Current необходимо предварительно убедиться, что реализация поддерживает этот уровень. Получить информацию о реализации можно с помощью вызова метода CORBA::ORB::get_service_information(), задав в качестве параметра типа CORBA::ServiceType значение константы CORBA::Security. Метод возвращает одно из следующих значений:

module Security { const CORBA::ServiceOption CommonInteroperabilityLevel0 = 10; const CORBA::ServiceOption CommonInteroperabilityLevel1 = 11; const CORBA::ServiceOption CommonInteroperabilityLevel2 = 12; };

На уровне Security Level 1 интерфейс Current содержит единственный метод, который позволяет получить список атрибутов безопасности в контексте выполняемого защищенного вызова:

module SecurityLevel1 { local interface Current : CORBA::Current { Security::AttributeList get_attributes (in Security::AttributeTypeList attributes); }; };

Единственный метод возвращает связанный с контекстом вызова список атрибутов безопасности указанных типов.

IDL-объявления основных типов выглядят так:

module Security { typedef string SecurityName; typedef sequence Opaque; // Объявления констант для Security Service Options const CORBA::ServiceOption SecurityLevel1 = 1; const CORBA::ServiceOption SecurityLevel2 = 2; const CORBA::ServiceOption NonRepudiation = 3; const CORBA::ServiceOption SecurityORBServiceReady = 4; const CORBA::ServiceOption SecurityServiceReady = 5; const CORBA::ServiceOption ReplaceORBServices = 6; const CORBA::ServiceOption ReplaceSecurityServices = 7; const CORBA::ServiceOption StandardSecureInteroperability = 8; const CORBA::ServiceOption DCESecureInteroperability = 9; // Service options for Common Secure Interoperability const CORBA::ServiceOption CommonInteroperabilityLevel0 = 10; const CORBA::ServiceOption CommonInteroperabilityLevel1 = 11; const CORBA::ServiceOption CommonInteroperabilityLevel2 = 12; ... // Расширяемые семейства (families) для стандартных типов данных struct ExtensibleFamily { unsigned short family_definer; unsigned short family; };

typedef sequence OID; typedef sequence OIDList; typedef unsigned long SecurityAttributeType;

// Общие атрибуты (family = 0) const SecurityAttributeType AuditId = 1; const SecurityAttributeType AccountingId = 2; const SecurityAttributeType NonRepudiationId = 3; // Атрибуты привилегий (family = 0) const SecurityAttributeType _Public = 1; const SecurityAttributeType AccessId = 2; const SecurityAttributeType PrimaryGroupId = 3; const SecurityAttributeType GroupId = 4; const SecurityAttributeType Role = 5; const SecurityAttributeType AttributeSet = 6; const SecurityAttributeType Clearance = 7; const SecurityAttributeType Capability = 8; struct AttributeType { ExtensibleFamily attribute_family; SecurityAttributeType attribute_type; }; typedef sequence AttributeTypeList; struct SecAttribute { AttributeType attribute_type; OID defining_authority; Opaque value; // значение зависит от defining_authority }; typedef sequence AttributeList; }

Таким образом, метод SecurityLevel1::Current::get_attributes() возвращает, по сути, состояние объекта Credentials, сопоставленного с выполняемым вызовом. На уровне Level1 вызов этого метода обычно выполняется самим ORB’ом.

На уровне Level 2 появляется дополнительная функциональность, связанная с явным управлением процессом обеспечения безопасности:

module SecurityLevel2 { ... local interface Credentials { Credentials copy (); void destroy(); readonly attribute Security::InvocationCredentialsType credentials_type; readonly attribute Security::AuthenticationStatus authentication_state; readonly attribute Security::MechanismType mechanism; attribute Security::AssociationOptions accepting_options_supported; attribute Security::AssociationOptions accepting_options_required; attribute Security::AssociationOptions invocation_options_supported; attribute Security::AssociationOptions invocation_options_required; ... boolean set_attributes ( in Security::AttributeList requested_attributes, out Security::AttributeList actual_attributes ); Security::AttributeList get_attributes ( in Security::AttributeTypeList attributes ); ... }; typedef sequence CredentialsList; local interface ReceivedCredentials : Credentials { ... }; ... local interface Current : SecurityLevel1::Current { readonly attribute ReceivedCredentials received_credentials; }; };

Заключение

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