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

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

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

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

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

Управление соединением

Соединение  двунаправленное в смысле потока данных, но оно не является симметричным в плане обмена сообщениями GIOP. Сообщения Request, LocateRequest иCancelRequest могут посылаться только клиентом. Сообщения Reply, LocateReply и CloseConnection - только сервером. Сообщение ErrorMessage может быть послано обеими сторонами. Через соединение для обмена в соответствии с протоколом GIOP могут посылаться только сообщения GIOP.

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

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

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

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

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).