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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Структура 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 давние дружеские отношения.

Делегирование в 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

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

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

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

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

Определить, какие возможности поддерживаются данной реализацией сервиса (и 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 (для принятия решения, нужно ли отслеживать определенное событие), которые удобно использовать в системе аудита,

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

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

Обеспечение создания защищенных объектов, сопоставленных с политиками безопасности.

Обеспечение работы с менеджерами доменов для таких объектов.

Управление политиками с использованием этих менеджеров доменов.

Сопоставление операций и прав доступа.

Среди всех возможных видов компонентов и сервисов, которые могут использовать политики безопасности (сами приложения, 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);

};

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

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

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.

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

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



Рисунок 11.12

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

Доказательность (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 не рассматриваются.

Интерфейс 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 <octet> 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<octet> OID;

typedef sequence<OID> 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<AttributeType> AttributeTypeList;

struct SecAttribute

{

AttributeType attribute_type;

OID defining_authority;

Opaque value; // значение зависит от defining_authority

};

typedef sequence <SecAttribute> 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 <Credentials> CredentialsList;

local interface ReceivedCredentials : Credentials { ... };

...

local interface Current : SecurityLevel1::Current

{

readonly attribute ReceivedCredentials received_credentials;

};};

Заключение

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

12. Стандарт ODBC

ODBC предназначен для предоставления прикладным разработчикам функциональных возможностей по обработке баз данных независимо от типа данных, к которым выполняется доступ, - базам данных ISAM, текстовым данным (Excel) или базам данных SQL. Эта цель достигается путем закрепления каждого драйвера ODBC за одним из предопределенных уровней соответствия. Чтобы считаться драйвером ODBC, драйвер должен соответствовать спецификациям ядра ODBC. Эти требования гарантируют, что разработчик приложения всегда может рассчитывать на одни и те же функциональные возможности независимо от того, к каким данным происходит обращение. Если формат используемых данных непосредственно не поддерживает основные функциональные возможности, драйвер ODBC должен эмулировать эти функции. С помощью ODBC можно манипулировать данными любой СУБД (и даже данными, не имеющими прямого отношения к базам данных, например данными в файлах электронных таблиц или в текстовых файлах), если для них имеется ODBC-драйвер. Для каждой используемой СУБД нужен собственный ODBC-драйвер. Говоря об ODBC, нельзя не отметить, что спецификация ODBC подразумевает несколько стандартов на ODBC-драйверы. Эти стандарты отличаются различной функциональностью, которая должна быть реализована в таком драйвере. Метод соединения с источником данных, получения сообщений об ошибках, а также стандартные интерфейсы регистрации являются общими для всех драйверов. Для обеспечения унифицированности драйверы придерживаются основных требований. Открытый интерфейс доступа к базам данных представляет собой библиотеку функций, которая позволяет прикладной программе обращаться к различным СУБД. Используя структурированный язык запросов SQL. Таким образом, разработчик прикладной программы может создавать программу для виртуальной базы данных и позволить загружаемому драйверу преобразовать логические данные в данные конкретной СУБД или систем, используемых данной прикладной программой.

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

Архитектура ODBC имеет четыре основных компонента: - прикладная программа, - диспетчер драйверов, - драйвер, - источник или источники данных.

Приложение, использующее интерфейс ODBC, выполняет следующие задачи: Запрашивает соединение с источником данных. Посылает SQL- запросы к источнику данных. Описывает область хранения и формат для результатов SQL- запросов. Запрашивает данные. Обрабатывает ошибки. Оповещает об ошибках. Осуществляет фиксацию или откат действий в режиме транзакций. Закрывает соединение с источником данных.

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

Функции интерфейса ODBC подразделяются на семь групп.

1. назначение и отмена назначения: идентификатор окружения, идентификатор соединения, идентификатор оператора

2. соединение

3. выполнение SQL-операторов

4. получение результатов

5. управление транзакциями

6. идентификация ошибок

7. смешанные функции

Теперь подробнее:

1. Назначение и отмена назначения

Идентификатор окружения определяет базу данных, идентификатор соединения определяет соединение с базой данных и идентификатор оператора определяет отдельный SQL-оператор.

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

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

Идентификатор оператора. Этот идентификатор, который относится к типу HSTMT, указывает на область памяти для информации о SQL-операторе. Прикладная программа должна запрашивать идентификатор оператора прежде, чем она выдаст SQL-запрос. В то время как каждый идентификатор оператора связывается с единственным идентификатором соединения, каждый идентификатор соединения может иметь один или более связанных с ним идентификаторов операторов.

Соединение

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

Выполнение операторов SQL

Существует два способа определения и выполнения SQL-операторов: с предварительной подготовкой и непосредственный.

Получение результатов

Этот набор функций управляет восстановлением данных из результирующего множества SQL-оператора и восстанавливает такую информацию о результирующем множестве как: описание какого-нибудь столбца результирующего множества и его атрибутов, получение следующей строки результирующего множества, подсчет числа строк, на которые воздействует оператор SQL, и т.д.

Управление транзакцией

Эта функция позволяет завершить транзакцию или осуществить откат к началу транзакции.

Идентификация ошибок

Функция идентификации ошибок возвращает информацию об ошибке, которая связана с указанным идентификатором.

Смешанные функции

Смешанные функции в этой группе позволяют попытаться завершить выполнение SQL-оператора.

13. Технология COM

COM (Component Object Model) - это объектная модель компонентов. Данная технология является базовой для технологий ActiveX и OLE. Технологии OLE и ActiveX - всего лишь надстройки над данной технологией. В качестве примера можно привести объект TObject, как базовый объект VCL Delphi. Точно так же технология СОМ является базовой по отношению к OLE и ActiveX.

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

Технология СОМ работает с так называемыми СОМ-объектами. СОМ-объекты похожи на обычные объекты визуальной библиотеки компонентов Delphi. В отличие от объектов VCL Delphi, СОМ-объекты содержат свойства, методы и интерфейсы.

Обычный СОМ-объект включает в себя один или несколько интерфейсов. Каждый из этих интерфейсов имеет собственный указатель.

Технология СОМ имеет два явных преимущества:

создание СОМ-объектов не зависит от языка программирования. Таким образом, СОМ-объекты могут быть написаны на различных языках;

СОМ-объекты могут быть использованы в любой среде программирования под Windows. В число этих сред входят Delphi, Visual C++, C++Builder, Visual Basic, и многие другие.

Хотя технология СОМ обладает явными плюсами, она имеет также и минусы, среди которых зависимость от платформы. То есть, данная технология применима только в операционной системе Windows и на платформе Intel.

Все СОМ-объекты обычно содержатся в файлах с расширением DLL или OCX. Один такой файл может содержать как одиночный СОМ-объект, так и несколько СОМ-объектов.

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

Технология СОМ реализуется с помощью СОМ-библиотек (в число которых входят такие файлы операционной системы, как OLE32.DLL и OLE-Aut32.DLL). СОМ-библиотеки содержат набор стандартных интерфейсов, которые обеспечивают функциональность СОМ-объекта, а также небольшой набор функций API, отвечающих за создание и управление СОМ-объектов.

В Delphi реализация и поддержка технологии СОМ называется каркасом Delphi ActiveX (Delphi ActiveX framework, DAX). Реализация DAX описана в модуле Axctris.

13.1 Развитие СОМ-технологий

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

Самыми первыми попытками решить эту непростую задачу были буфер обмена, разделяемые файлы и технология динамического обмена данными (Dynamic Data Exchange, DDE).

После чего была разработана технология связывания и внедрения объектов (Object Linking and Embedding, OLE). Первоначальная версия OLE 1 предназначалась для создания составных документов. Эта версия была признана несовершенной и на смену ей пришла версия OLE 2. Новая версия позволяла решить вопросы предоставления друг другу различными программами собственных функций. Данная технология активно внедрялась до 1996 года, после чего ей на смену пришла технология ActiveX, которая включает в себя автоматизацию (OLE-автоматизацию), контейнеры, управляющие элементы, Web-технологию и т. д.

...