CC BY
84
УДК: 004+658 ББК: 32+65.050.2
Горбачевская Е.Н., Трубачев Е.С.
РЕАЛИЗАЦИЯ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ ПО ТЕХНОЛОГИИ CORBA В КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМАХ
Gorbachevskaya E.N., Trubachev E.S.
IMPLEMENTATION INFORMATION SECURITY OF THE TECHNOLOGY CORBA IN CORPORATE INFORMATION SYSTEMS
Ключевые слова: корпоративные информационные системы, концепции обеспечения безопасности технологии CORBA.
Keywords: corporate information systems, the concept of security technology CORBA.
Аннотация: сложность современных КИС требует подбора технологии, обеспечивающей безопасность работы с корпоративными данными. Технология CORBA является гарантом надежности и безопасности информационных ресурсов предприятия. Спецификации CORBA включают в себя основные концепции безопасного хранения и передачи данных.
Abstract: the integration of modern CIS requires the selection of technologies providing the security of the work with corporate data. Technology CORBA is a guarantee of reliability and safety of work of the enterprise. CORBA specification includes the core concept of safe storage and transmission of data.
В корпоративных информационных системах (КИС) взаимодействие осуществляется с помощью локальных и глобальных сетей. Организация безопасной и надежной передачи данных, защита от внешних и внутренних атак, защита конфиденциальности данных является сложной задачей.
Для безопасного хранения и передачи данных используется технология CORBA. Технология создана для поддержки разработки и развёртывания сложных объектноориентированных прикладных систем.
CORBA используется для осуществления взаимодействия изолированных систем, предоставляет возможность программам, написанным на различных языках программирования, работающих в разных узлах сети, взаимодействовать друг с другом так же просто, как если бы они находились в адресном пространстве одного процесса.
Спецификация CORBA предписывает объединение программного кода в объект, который должен содержать информацию о функциональности кода и интерфейсах доступа. Готовые объекты могут вызываться из других программ (или объектов спецификации CORBA), расположенных в сети.
Рассмотрим основные концепции безопасности с точки зрения распределенных систем.
Первое. Идентификация и аутентификация личности пользователя с последующей авторизацией. Необходимость определить личность пользователя, с подтверждением через пароль, ключ, смарт-карту или биометрические характеристики с целью предоставления права доступа к определенным данным, соответствующим статусу входящего.
Аутентификация необходима для установления доверительных отношений в системе. Например, если электронная банковская система требует, чтобы сведения о банке предоставлялись только держателям акций, значит, они должны пройти аутентификацию, чтобы исключить возможность попадания конфиденциальной информации в посторонние руки.
Рассмотрим работу сертификата аутентификации на примере использования в Oracle (рисунок 1). Сертификат подлинности работает следующим образом:
1. Инициированное приложение обращается к домену Oracle Tuxedo одним из следующих способов: через INS CORBA Bootstrapping механизм. Применение этого механизма рекомендуется, если вы используете клиент ORB от другого поставщика.
2. Механизм Oracle Начальная загрузка. Воспользуйтесь данным механизмом, если вы используете клиент ORB от другого поставщика. Инициированное приложение создает экземпляр объекта с Bootstrap URL в виде corbaloc://host:port or corbalocs://host:port и управляет требованием для защиты, установив атрибуты SecurityLevel2::Credentialsобъект, возвращаемый в результате выполнения SecurityLevel2::PrindpalAuthenticator: authenticate операции.
Рисунок 1 - Схема аутентификации сертификата
При применении метода SecurityLevel2::Current::authenticate(), чтобы обеспечить процесс начальной загрузки, необходимо указать, что должна быть использована проверка подлинности сертификата (таблица 1).
Таблица 1 - Шаги администратора для проверки подлинности сертификатов
Шаг Описание
1 Настройка LDAP с поддержкой службы каталога. Вам будет предложено ввести имя LDAP сервера во время установки продукта Oracle Tuxedo.
2 Установить лицензию на SSL протокол.
3 Получить цифровой сертификат и закрытый ключ для ПОР слушателя / обработчик сертификации.
4 Получить цифровые сертификаты и закрытые ключи для клиента CORBA приложений с центром сертификации.
5 Хранить закрытый ключ для клиента CORBA приложений и IIOP слушателя / обработчик в домашнем каталоге пользователя или в $ TUXDIR / udataobj / безопасность / ключи.
6 Публикация цифровых сертификатов для слушателей IIOP / Handler, CORBA приложений и сертификации в LDAP с поддержкой службы каталога.
7 Определить SEC_PRINCIPAL_NAME , SEC_PRINCIPAL_LOCATION , и SEC PRINCIPAL PASSVAR для ISL процесса сервера в UBBCONFIG файл.
8 Установить параметры безопасности в UBBCONFIG: USER AUTH , ACL или MANDATORY ACL .
9 Настроить проверку подлинности сервера (AUTHSRV) в UBBCONFIG.
10 Использовать tpusradd и tpgrpadd команды для определения пользователей и групп приложения CORBA.
11 Определить порт для связи SSL со слушателем IIOP/Handler с помощью S-опции ISL командой.
Шаг Описание
12 Включить проверку подлинности сертификата в приемнике IIOP/Handler при помощи ISL команды.
13 Создать файлы Certificate Authority (trust_ca.cer), которые определяют доверие Слушателя IIOP / Handler.
12 Создать файлы Certificate Authority (trust_ca.cer ), которые определяют доверие сертификации клиентское приложение CORBA.
13 Использовать tmloadcf команду для загрузки UBBCONFIG . Будет предложено ввести пароль из приемника IIOP / Обработчик (определен в SEC PRINCIPAL NAME).
14 При необходимости создать Peer файл правил (peer val.rul) как для приложений CORBA, так и для клиента и слушателя IIOP / Handler.
15 При необходимости изменить LDAP фильтр поиска файлов, чтобы отразить иерархию каталогов предприятия.
Рисунок 2 иллюстрирует конфигурацию приложения СОЯВА, которое использует сертификат подлинности.
Рисунок 2 - Конфигурация СОЯВА приложений при использовании сертификатов проверки подлинности
Второе. Авторизация. Под авторизацией понимается предоставление доступа к данным только ограниченному числу пользователей. Если аутентификация проверяет, кто вы такой, то авторизация проверяет, что вам разрешено, при условии, что вы тот, за кого себя выдаете. Во многих ситуациях, особенно тогда, когда дело касается доступа к данным по сети, после определения прав пользователя с помощью авторизации проводится и его аутентификация. Для того, чтобы поставить в соответствие авторизированному пользователю группу ресурсов, используются списки контроля доступа ACL (Access Control List). Достаточно большая часть времени, затрачиваемая на разработку систем, отводится именно на настройку и поддержание списков авторизации с использованием списков ACL.
Схема авторизации приставлена на рисунке 3.
КОНЕЦ
Рисунок 3 - Алгоритм авторизации пользователя
Третье. Шифрование. Необходимость использования криптографических функций для шифрования открытым или секретным ключом для обеспечения конфиденциальности информации при передаче по распределенным системам.
Под шифрованием понимается защита данных при их передаче, для этого используются криптографические функции. Шифрование основано на использовании секретного или общедоступного ключа. Шифрование с помощью общедоступного ключа требует двух ключей — личного, известного только определенному пользователю, и общего, который распространяется свободно. При шифровании с помощью секретного ключа используется всего один ключ, который, как следует из его названия, должен храниться в секрете. При шифровании с помощью открытого ключа открытый и закрытый ключи выполняют обратные функции — то, что было зашифровано с помощью открытого ключа, можно расшифровать только с помощью секретного ключа, и наоборот.
Шифрование открытым ключом происходит несколько медленнее, чем с помощью секретного, что объясняется большей сложностью применяемых алгоритмов. Поэтому общее правило таково: использовать открытый ключ для получения секретного, который будет применяться во время всего сеанса передачи данных. Именно такой подход используется протоколом SSL.
В таких системах, как DES (Data Encryption Standard) используется шифрование с помощью секретного ключа, в других системах, например RSA (Rivest Shamir Adleman), используется технология открытого ключа. На рисунке 4 представлена схема шифрования.
Четвертое. Целостность данных. Необходимость контроля соответствия полученных данных оригиналу. Средства обеспечения целостности данных должны пресекать постороннее вмешательство во время передачи сообщений. Проверка целостности может быть организована через код аутентификации сообщения или дайджест сообщения.
Под целостностью понимается соответствие оригиналу получаемых данных, а также защита соединения во время их передачи. Средства обеспечения целостности данных пресекают постороннее вмешательство во время передачи сообщений.
Для определения вмешательства или изменений состояния соединений проверяется контрольная сумма (часть
данных, используемая для представления всего сообщения) передаваемых пакетов данных.
Контрольная сумма имеет вид кода аутентификации сообщения MAC (Massage Authentication Code) или дайджеста сообщения MD (Message Digest). Контрольная сумма проверяется во время всего сеанса передачи данных.
Открытые ключи также используются в цифровых подписях сообщений — к каждому сообщению добавляется форма MAC. Этот код вычисляется с помощью применения хэш-функции к содержанию сообщения. Затем полученный код шифруется с помощью личного ключа отправителя. Получатель расшифровывает сообщение с помощью открытого ключа отправителя, после чего проверяет соответствие кода MAC содержанию сообщения. Если во время передачи сообщение повредилось, подобного соответствия нет.
Пятое. Безотказность. Необходимость неоспоримого подтверждения совершения определенных действий в системе для предотвращения попыток отказа от получения или передачи данных. Безотказность гарантирует, что пользователь не сможет запретить отправление ему сообщения. Безотказность работы обеспечивается благодаря использованию уникальных цифровых подписей, подтверждающих, что сообщение отправлено или получено конкретным пользователем. Для добавления цифровых подписей к сообщениям используются методы шифрования с помощью открытого ключа.
В качестве примера рассмотрим ситуацию. Пользователь, желая совершить покупку, связалась с сервером электронной коммерции. Для того, чтобы совершить покупку, пользователю требуется передать сведения о своей кредитной карточке через общедоступный сервер (пользователь уже проверила его "достоверность"). Пользователь хочет удостовериться в том, что сведения о ее кредитной карточке не перехватят во время передачи и не используют не по назначению. Сервер электронной коммерции требует, чтобы пользователь не смог отказаться от своего решения на последних стадиях оформления покупки и, чтобы он дал ему право снимать деньги с его кредитной карточки. И тут как раз пригодятся цифровые подписи, которые обеспечат целостность данных для пользователя и безотказность — для сервера. Для создания и добавления цифровой подписи к сообщению пользователь может прибегнуть к шифрованию открытым ключом. После получения сообщения сервер использует открытый ключ пользователя для проверки цифровой подписи и ее соответствия содержанию сообщения. Если все совпало, значит, сообщение действительно было отослано пользователем, поскольку только пользователь располагает личным секретным ключом, таким образом, обеспечивая безотказность. Соответствие цифровой подписи сообщению свидетельствует о целостности его данных.
Шестое. Делегирование прав пользователя. Необходимость использовать права пользователя. Делегирование - это передача полномочий (прав и привилегий) при выполнении цепочки вызовов. В этом случае нужно различать «первоначального» клиента (initiator), промежуточный (intermediate) и конечный серверы (final target). Каждый промежуточный объект в последовательности вызовов выступает в роли как сервера (по отношению к объекту, который непосредственно обращается к нему), так и клиента (по отношению к следующему промежуточному или конечному серверу в цепочке вызовов). Поддерживаемые спецификацией Сервиса безопасности варианты делегирования рассмотрены ниже.
Делегирование в CORBA
Графически возможные (согласно спецификации) схемы делегирования можно выразить следующим образом (рисунки 5-8).
Рисунок 5 - Запрет делегирования
Каждый промежуточный объект, участвующий в цепочке вызовов, выступает от «собственного имени» и использует свои атрибуты и привилегии.
Удостоверен\яя[ Промежуточный ^ Удостоверения клиента \ объект / клиента
Рисунок 6 - Простое (simple) делегирование
Клиент делегирует свои полномочия промежуточному серверу, который может использовать их как для разрешения (запрета) доступа к своим ресурсам, так и для передачи дальше, по цепочке вызовов. Каждый промежуточный (и конечный) сервер считает, что к нему обращается начальный клиент.
Удостоверения Удостоверения/ Промежуточный \ клиента и клиента \ объект / промежуточные . удостоверения
Рисунок 7 - Комплексное (composite) делегирование
Клиент позволяет делегировать свои полномочия дальше по цепочке вызовов, при этом промежуточный сервер может добавить к ним собственные привилегии. Если это необходимо, последующие серверы могут анализировать полученные по ORB привилегии независимо друг от друга.
Рисунок 8 - Комбинированное (combined) делегирование
Режим похож на предыдущий, за одним исключением: промежуточный объект создает обобщенные наборы атрибутов и привилегий, и последующий сервер (конечный сервер на приведенном рисунке) уже не может отличить, к какому из участвующих в цепочке вызовов объекту относятся отдельные привилегии.
Сервис безопасности CORBA позволяет при делегировании вводить и другие ограничения. Например, клиенты и промежуточные серверы могут делегировать только часть своих полномочий; администратор или программист может задать период времени, в течение которого можно использовать делегирование и т.д.
Для приложений, которые непосредственно не обращаются к API Security Service (Level 1), режим делегирования задается по умолчанию с использованием политик безопасности, и промежуточные объекты не могут в процессе работы приложения менять указанный способ делегирования.
Рассмотрим основные требования информационной безопасности технологии CORBA и примеры их реализации (таблица 2).
Свойство безопасности Требование Пример
Аутентификация Требуется перед выполнением любого безопасного действия Для систем, работающих с любыми бизнес-данными, сначала нужно удостовериться, что подключившийся пользователь является сотрудником компании, а не посторонним лицом. Это можно осуществить с помощью имени и пароля или сертификата безопасности пользователя
Авторизация Для пользователя, подразделения или группы или целой организации В рамках организации может быть общедоступной такая информация, как сведения о затратах на удовлетворение жалоб потребителей. Другие данные нужно сделать доступными только отдельным сотрудникам (например, сведения о заработной плате). Некоторые данные нужно сделать доступными определенным группам пользователей, таким как старшие менеджеры (например, сведения о годовом доходе компании)
Авторизация Списки контроля доступа могут использоваться для сервера, экземпляра объекта или операции В зависимости от способа хранения данных списки контроля доступа могут понадобиться на уровне операций, объектов или логики приложения, отвечающей за предоставление доступа к данным, например, объект, предоставляющий интерфейс для информации о доходах компании, может поддерживать операции чтения и записи такой информации. В данном случае необходимы списки контроля доступа для отдельных операций, которые позволят старшим менеджерам просматривать сведения о годовом доходе
Защита сообщений Конфиденциальность и целостность наиболее важных сведений, обрабатываемых системой Сведения из финансовых отчётов о доходах компании могут претерпеть изменения, если попадут в руки чужих аналитиков или конкурентов, в связи с чем требуется их постоянно шифровать и обеспечивать их целостность
Делегирование разрешений Требования системы к делегированию разрешений достаточно просты Например, компания использует автоматизированные схемы продаж. Договорённости о платежах регистрируются сервером финансовых записей, что приводит к автоматической продаже товара покупателю сервером продажи товаров. В этом случае, как только сервер финансовых записей сообщает о приёме платежа, он вызывает метод сервера продажи товаров для авторизации акта продажи. Все эти операции осуществляются под управлением клерка, вводящего сведения о платеже в систему
Регистрация Требуется при проведении финансовых транзакций Для всех финансовых транзакций, таких как передача платежей, квартальных отчётов о доходах, а также отчётов о расходах, регистрация выступает обязательным требованием к системе
Безотказность Требуется при совершении любых безопасных действий в системе Новые, неопытные или "заблудившиеся" пользователи могут получить доступ к "защищённым" от них ресурсам, несмотря на применение стратегии безопасности. Если такое происходит, необходимо использовать цифровые подписи и регистрацию, что заставит пользователей отвечать за любые выполненные в системе действия
Доступ к большей части информационных ресурсов в современных корпоративных системах осуществляется с помощью технологии CORBA. Рассмотрим четыре спецификации CORBA, обеспечивающие соблюдение перечисленные выше требований безопасности распределенных систем:
1. Спецификация службы безопасности CORBA. Используются существующие технологии безопасности: служба безопасности DCE (Distributed Computing Environment), протокол Kerberos для аутентификации в распределенных системах, шифрование, прикладной интерфейс службы безопасности. Служба безопасности разделяется на два уровня.
Первый уровень выполняет функции контроля доступа и аудита:
- идентификация/аутентификация пользователя с определением прав доступа;
- обеспечение целостности и конфиденциальности данных, на основе доверительных отношений и аутентификации пользователей (на уровне группы объектов и группы пользователей);
- делегирование разрешения;
- аудит безопасности событий (аутентификации сеансов, авторизация, внесение изменений в стратегию безопасности и
др.).
Служба безопасности второго уровня организует безопасность при вызове объектов и позволяет динамично контролировать использование службы безопасности:
- способность контролировать параметры, используемые безопасными вызовами, выбирать необходимый уровень защиты сообщений;
- способность изменять привилегии, определенные в разрешениях;
- способность выбирать разрешения и использовать их при обращении к объекту;
- расширенные возможности делегирования (составное делегирование);
- приложения могут определять, какие безопасности к ним применялись, включая те, за которые отвечают они или брокеры служебных запросов [1].
Различные производители брокеров объектных запросов предлагают свои вариации разработок.
2. Спецификация безопасного взаимодействия. Определяет протокол безопасного взаимодействия SecIOP (Secure InterORB Protocol). Данный протокол совместим с протоколами GIOP и IIOP. Данная спецификация должна обеспечивать безопасную реализацию работы различных служб безопасности различных производителей. Каждый объект, запущенный службой безопасности, имеет ссылку, содержащую маркер безопасности (поддерживаемые службы безопасности, уровень защиты сообщений и т.д.) с информацией для установки безопасного соединения с этим объектом. Сообщение каждого клиента содержит маркер безопасности с информацией (о клиенте, сервере, привилегиях, поддерживаемых механизмах безопасности), необходимой для установки конфиденциальности, целостности, аутентификации.
Таким образом, проведенная классификация и анализ спецификаций технологии CORBA позволяет сделать вывод. Технология CORBA прошла достаточный путь развития, чтобы удовлетворять изменившимся требованиям по обеспечению безопасности в распределенных системах. Технологии и методы, которые используются для обеспечения раЗЛИЧНЫХ
функциональных возможностей, претерпели изменения, чтобы удовлетворять требованиям, которые предъявляются Internet и распределенной природой современных корпоративных систем. По мере появления новых технологий CORBA обеспечивает новыми спецификациями, касающимися интеграции и реализации этих технологий стандартным способом, что позволяет независимым пользователям и разработчикам находить правильные решения для удовлетворения нужд конкретных систем на основе технологии CORBA. Пользователи систем могут свободно выбирать те инструменты, которые обеспечат безопасность корпоративных систем на основе технологии CORBA.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Дирк, Слама, Джейсон, Гарбис, Перри, Рассел. Корпоративные системы на основе CORBA: Уч.пос. / Пер. с англ. - М.: Издательский дом «Вильямс», 2000. - 368с.: ил.2.
2. http://www.citforum.ru.
3. http:cisco.com.
