CC BY
40
0 5 10 15 20 25
Рис. 7. Теоретические графики F(t) и Z(t)
p,%
llllllliiiiiii............
Рис. 8. Гистограмма распределения интервалов времени между пропусками запросов НСД
Рис. 9. Графики функций и построенные по данным эксперимента
Таблица 3
Блок Параметр Значение Комментарии
Вся модель 1.0/мин Интенсивность потока запросов НСД первого типа
Вся модель 2.0/мин Интенсивность потока запросов НСД второго типа
Генератор транзактов 1 тнсдХ Fexp(^l) Время между смежными запросами НСД первого типа
Генератор транзактов 2 тнсд2 Fexp(^2) Время между смежными запросами НСД второго типа
Очередь 1 Ьх 20 Размер буфера МЗ1
Очередь 2 L2 20 Размер буфера МЗ2
Блок ожидания 1 Тмзх 1 с Время обработки запроса НСД первого типа
Блок ожидания 2 ТМЗ2 1 с Время обработки запроса НСД второго типа
Условное ветвление Рх 0.9 Запрос НСД распознается и отсеивается механизмом защиты с вероятностью 90%
Условное ветвление Р2 0.95 Запрос НСД распознается и отсеивается механизмом защиты с вероятностью 90%
4
3-
1-
p
Среднее время между смежными пропусками запросов НСД: тнсд = 5.047 мин.
Отклонение экспериментальных оценок /(!;), Е(1;) и Н(1;) от теоретических в среднем составило 0,1%.
Подводя итог, можно сказать, что разработанная имитационная модель СЗИ позволяет моделировать процесс защиты информации (работы СЗИ), описанный в [2]. В обоих выполненных экспериментах относительная ошибка, характеризующая расхождение характеристик СЗИ, рассчитанных теоретически и полученных в результате имитационного моделирования, составила 0,1%.
Список литературы
1. Карпов В.В. Вероятностная модель оценки защищенности средств вычислительной техники с аппаратно-программным комплексом защиты информации от несанкционированного доступа. // Программные продукты и системы. -2003. - №1. - С.31.
2. Девянин П.Н., Михальский О.О. и др. Теоретические основы компьютерной безопасности. - М.: Радио и связь, 2000.
ЦЕЛЕСООБРАЗНОСТЬ ПРИМЕНЕНИЯ WEB-СЛУЖБ В РАСПРЕДЕЛЕННЫХ АВТОМАТИЗИРОВАННЫХ СИСТЕМАХ
ВОЕННОГО НАЗНАЧЕНИЯ
А.Ф. Кеменов
В современных распределенных автоматизированных системах военного назначения (АС ВН),
как правило, должно обеспечиваться взаимодействие как между внутренними функциональными
подсистемами, так и с внешними системами - в рамках единого информационного пространства Министерства обороны РФ.
Очевидным способом построения распределенной системы является подход, при котором для связи взаимодействующих компонентов вырабатывается некий специальный формат данных, а, возможно, даже и протокол связи, и на обеих сторонах создаются программы, умеющие этот формат обрабатывать. При таком способе взаимодействия компонентов системы говорят о жестком (сильном) связывании (tight coupling). Совершенствование протоколов взаимодействия и форматов данных в такой системе в процессе развития информационных технологий требует больших финансовых и временных затрат. Тем не менее, именно таким образом связаны подсистемы большинства современных распределенных АС ВН.
В дополнение к традиционному подходу при построении современных распределенных АС ВН возможно использовать архитектуру, между компонентами которой осуществляется так называемая слабая связность (loose coupling). Слабая связность предполагает, в частности, что компонентам системы не обязательно знать, как устроены взаимодействующие с ними подсистемы, а для расширения взаимодействия нет необходимости в определении новых форматов данных и в расширении специальных протоколов связи. Эта архитектура основана на использовании так называемых web-служб [1,2].
Самый простой вариант взаимодействия с внешними системами может быть достигнут при реализации в каждой из взаимодействующих систем стандартной электронной почты по протоколу SMTP (Simple mail transfer protocol) и использование стандартных форматов сообщений. Использование документов в форматах MS Office, ставших стандартом де-факто в офисном документообороте, не следует принимать за основу. Более подходящим для этой цели является использование сообщений в формате XML (eXtensible markup language). Текстовый XML-документ имеет одинаковое представление на любой платформе, может хранить любые данные и легко передаваться по сетям передачи данных. Обмен XML-сооб-щениями положен и в основу web-служб.
Для определения особенностей web-служб рассмотрим их в сравнении с другими технологиями построения распределенных систем [2]. Наиболее известными из таких технологий являются CORBA и DCOM.
CORBA (Common object request broker architecture) - это технология создания распределенных систем в соответствии со спецификациями, предлагаемыми консорциумом OMG (Object Management Group). Спецификация CORBA 1.1 была представлена в 1991 году и стала первой серьезной технологией построения распределен-
ных систем, предлагающей реальную независимость от инфраструктуры, сетевых протоколов, операционных систем и языков программирования. В основе CORBA лежат три понятия:
- язык описания интерфейсов OMG IDL (Interface definition language), с помощью которого описываются интерфейсы всех объектов, участвующих во взаимодействии;
- брокер объектных запросов ORB (Object request broker), являющийся посредником, промежуточным звеном системы и скрывающий в себе всю сложную логику взаимодействия клиентского приложения с серверными объектами;
- протокол IIOP (Internet inter-ORB protocol), обеспечивающий транспортную поддержку для запросов клиента и ответов сервера, а также взаимодействия между ORB.
К сожалению, на практике ORB от различных производителей оказались несовместимыми (или не полностью совместимыми), что не позволило строить на основе CORBA распределенные системы, действительно не зависимые от платформы и поставщика программного обеспечения для промежуточного слоя.
DCOM (Distributed common object model) -технология создания распределенных систем, разработанная фирмой Microsoft на основе модели COM. Как известно, COM использует двоичную структуру объектов, что в некотором смысле является ее достоинством, позволяя использовать для работы различные языки программирования (С++, Visual Basic, Visual J++ и др.). С другой стороны, такая архитектура определяет и главный недостаток COM/DCOM: каждый компонент распределенного DCOM-приложения должен обязательно выполняться под управлением операционной системы Windows. Хотя Microsoft неоднократно декларировала, что DCOM будет перенесена на другие платформы, эти обещания так и не были выполнены.
Следует заметить, что, кроме CORBA и DCOM, существовали и существуют другие модели для удаленных вызовов в распределенных системах. Однако все они, обладая теми или иными ограничениями, не смогли завоевать популярности у разработчиков распределенных систем. Скажем, технология RMI (Remote method invocation) поддерживает вызов методов удаленных объектов, но только в том случае, когда и клиентская, и серверная части являются Java-приложениями. В этом качестве она с успехом используется, например, для вызова методов EJB-объектов в распределенных 12ЕЕ-приложениях (наряду с протоколом IIOP и некоторыми сервисами CORBA).
В упомянутых выше технологиях легко можно выделить некоторые общие черты. В частности, каждая из них предлагала некий транспортный протокол для обмена данными между компонен-
тами (IIOP в CORBA, RPC в DCOM), формат для передачи значений по этому протоколу (CDR, NDR), а также способ адресации серверных объектов (IOR, OBJREF). Относительные неудачи технологий во многом были вызваны сложностью и несовместимостью указанных стандартов и форматов.
Технология web-служб предполагает, что для взаимодействия распределенных систем используются распространенные коммуникационные протоколы (HTTP, SMTP), универсальный язык разметки XML, а в качестве ссылки на серверные объекты используется URI (Unified resource identifier). Обмен информацией осуществляется с помощью простого протокола доступа к объектам (Simple object access protocol, SOAP). Каждая служба описывает собственные возможности на языке WSDL (Web services description language -язык описания web-служб). Теоретически любая прикладная программа, которой требуется определенная услуга, может с помощью средств UDDI (Universal description, discovery and integration) найти соответствующую службу, по ассоциированному документу на языке WSDL определить ее функциональные возможности и немедленно обратиться к ее средствам. Все обмены являются текстовыми и не зависят от платформы. Для сравнения в таблице приведены стандарты, используемые web-службами, CORBA и DCOM.
Характеристика web-службы CORBA DCOM
Транспортный протокол HTTP, SMTP IIOP RPC
Формат сообщения SOAP (XML) CDR NDR
Способ адресации URI IOR OBJREF
Для условий построения АС ВН особое значение приобретает возможность использования web-службами прикладного транспортного протокола SMTP (или иного асинхронного протокола обмена сообщениями). Дело в том, что значительное количество унаследованных защищенных каналов передачи данных не позволяют использовать протокол TCP/IP, но могут обеспечить асинхронную передачу сообщений. Создание на границах этих каналов соответствующих шлюзов позволит использовать их для взаимодействия посредством web-служб.
Защита информации при использовании web-служб может быть произведена на основе спецификации Web services security: SOAP message security 1.0 [3], одобренной организацией OASIS (Organization for the advancement of structured information standards) в апреле 2004 г. Эта спецификация
позволяет реализовать в протоколе SOAP методы защиты целостности сообщений и сохранения их конфиденциальности, а также определяет особенности обмена информацией, касающейся защиты данных.
Стандарт Web services security обеспечивает возможность присоединения к сообщению одного из нескольких типов защитных маркеров. Маркер безопасности отправителя содержится в элементе SOAP-сообщения и состоит из ряда заявок. Отправитель заявки на некоторое конкретное имя и на определенный объем полномочий одновременно предоставляет средства для проверки правомочности этих притязаний. В большинстве случаев маркеры заверяются цифровыми подписями XML signature. Их аутентичность может проверяется несколькими способами, в частности с помощью сертификата X.509. В результате проверки сертификата подтверждается подлинность имени субъекта и его полномочий, а наличие цифровой подписи XML signature свидетельствует о том, что содержание сообщения не было изменено. В случае необходимости часть сообщения или все его содержимое могут быть зашифрованы в соответствии со стандартом XML encryption.
Реализация элементарных web-служб на основе существующих web-технологий достаточно проста и может быть выполнена как с помощью традиционных средств разработки типа Del-phi/Kylix, содержащих компоненты для формирования SOAP-сообщений, так и с помощью специализированных средств типа Java или PHP. Особенно эффективно web-службы реализуются на платформе Apache tomcat, являющейся эталонной средой для исполнения Java-сервлетов [3].
Для использования в АС ВН средства реализации web-служб должны базироваться на отечественных защищенных технологиях (платформа МСВС). Публикация Sun microsystems исходного кода Java 5 (1.5) в конце 2004 г. позволяет рассчитывать на перенос технологии Java на платформу МСВС и реализацию web-служб средствами защищенного web-сервера. При удачной реализации защищенных web-служб на платформе МСВС эта технология может быть внедрена во многих АС ВН, требующих совместимых решений по взаимодействию.
Список литературы
1. Ньюкомер Э. Веб-сервисы для профессионалов. - СПб.: Питер, 2003.
2. Разумовский К. Введение в технологию web-служб. Ч. 1. // Компьютерные вести. - № 43. - 2002 (www.kv.by/in-dex2002430601.htm).
3. Бекет Г. и др. Java: основы web-служб. - М.: Кудиц-Образ, 2004.
