Разработать способ контроля легальности взаимодействия двух приложений
Московский Авиационный Институт
(Государственный Технический
Университет)
Курсовая работа
по ПАЗИ
по теме:
Разработать способ контроля
легальности взаимодействия двух приложений
Выполнил:
студент гр.
4О-304С
Поздняков
Дмитрий
Москва, 2014
Введение
ООП и визуальное проектирование позволяют создавать
прикладные программы самого разного назначения. Но в настоящее время
приложения, разрабатываемые для различных предприятий и их подразделений, как
правило, должны функционировать не сами по себе, а являться частью некоторой
информационной системы. В этом случае один из основных вопросов - организация
взаимного общения приложений друг с другом и с хранилищами информации - базами
данных.
Как правило, приложения, работающие в составе информационной
системы, черпают информацию из баз данных, к которым имеют доступ и другие
приложения. При этом естественным образом создается возможность общения
приложений через данные. Например, одно приложение может записать результаты
своей работы в БД, а другое - прочитать эти данные и использовать их в своей
работе. Такое простейшее общение требует только одного - унификации данных,
форматов их хранения и языка запросов к БД. Последнее решается, чаще всего, с
помощью языка SQL.
Во многих случаях подобного общения через данные
недостаточно для эффективной работы системы. Приложение-потребитель данных не
может ждать, пока кто-то запустит приложение, поставляющее эти данные. Значит
нужна возможность запускать из одного приложения другие, передавая в них какую-то
информацию. Запуск внешнего приложения называется порождением процесса.
Дочерний процесс может выполняться в адресном пространстве родительского
процесса, т.е. как бы встраиваться в породивший его процесс, а может
выполняться в другом, собственном адресном пространстве и в другом параллельном
потоке.
Запуск из одного приложения других приложений
позволяет использовать результат работы дочернего процесса, но и только. Часто
этого мало. Требуется обмен информацией между приложениями, выполняющимися
параллельно. Причем, надо, чтобы этот обмен не зависел от того, на каком языке
написано то или иное приложение. А при работе в сети компьютеров, использующих
разные платформы (Windows, Unix, Solaris и др.), желательно обеспечить и независимость общения
от платформы.
Простейшими средствами общения, появившимися еще на
заре Windows, являются разделяемые файлы (файлы,
к которым одновременно могут получать доступ разные приложения), буфер обмена Clipboard, доступный практически всем
приложениям Windows, и технология DDE - динамического обмена данными.
Использование разделяемых файлов, баз данных и буфера обмена достаточно
актуальны и сейчас как простейшие средства связи приложений друг с другом. А
технология DDE пожалуй, уступила место более
современным способам общения.
Позднее появилась технология связывания и внедрения
объектов (Object Linking and Embedding) - OLE 1. Она позволяла создавать составные документы,
включая, например, в документ Word
таблицу Excel. На смену этой технологии пришла OLE 2, позволявшая разным программам
предоставлять друг другу свои функции. Пользуясь этой технологией, одно
приложение может не просто вызвать другое, но и обратиться к отдельным его
функциям, т.е. управлять им.
Следующим шагом на пути совершенствования способов
взаимодействия приложений друг с другом явилась разработка COM(Component Object Model) - компонентной модели объектов. Это
стандартизованное описание функций (служб) программы, к которым она дает доступ
другим программам. При этом неважно, на каких языках написаны программы и где
они выполняются: в одном потоке, в разных потоках, на разных компьютерах.
Особенно расширяет эти возможности распределенная модификация СОМ - DCOM. Основой технологии СОМ является
понятие интерфейса. Каждый объект СОМ имеет несколько интерфейсов, дающих
доступ к его функциям. Клиенту передается указатель на требуемый ему интерфейс,
после чего клиентское приложение может вызывать описанные в интерфейсе функции.
Основная часть
Понятие межпроцессного взаимодействия
Межпроцессное взаимодействие (англ. Inter-Process
Communication, IPC) - набор способов обмена данными между множеством потоков в
одном или более процессах. Процессы могут быть запущены на одном или более
компьютерах, связанных между собой сетью. IPC-способы делятся на методы обмена
сообщениями, синхронизации, разделяемой памяти и удаленных вызовов (RPC).
Методы IPC зависят от пропускной способности и задержки взаимодействия между
потоками и типа передаваемых данных.также может упоминаться как межпотоковое
взаимодействие (англ. inter-thread communication), межпоточное взаимодействие и
межпрограммное взаимодействие (англ. inter-application communication).наряду с
концепцией адресного пространства является основой для разграничения адресного
пространства.
Топология
Существует два подхода к организации маршрутов
взаимодействия интегрируемых систем. Первый - прямое взаимодействие
интегрированных систем по принципу «каждая с каждой», или «точка-точка». Второй
- взаимодействие через центральный узел; подобную звездообразную архитектуру
обычно называемую «хаб + спицы». Топология не зависит от физической архитектуры
информационной системы, а определяет логические маршруты взаимодействия и
передачи данных между интегрированными системами.
Точка-точка
При данном подходе интегрированные системы взаимодействуют
напрямую. Преимущества подхода - простота, прозрачность и отсутствие
необходимости в дополнительном программном обеспечении. Однако, есть и
недостатки. Во-первых, интегрированные приложения должны общаться с
использованием одинаковых методов взаимодействия и форматов вызовов/данных. При
изменении одного из приложений (если оно повлекло за собой изменение интерфейса
взаимодействия данного приложения) приходится модифицировать или как минимум
перенастраивать все интегрированные с ним системы. Во-вторых, в информационной
системе предприятия появляется слишком много связей, каждую из которых нужно
контролировать и поддерживать в работоспособном состоянии.
Если взаимодействующих приложений много, стоимость
сопровождения интегрированной таким образом информационной системы предприятия
становится неприемлемо высокой. Тем не менее подход «точка-точка» широко
используется. Это происходит, как правило, в тех случаях, когда при
взаимодействии конкретных приложений необходимо передавать большие объемы
данных или обеспечивать нормированное время взаимодействия, а также если
эксплуатируемые на предприятии приложения имеют встроенные средства
взаимодействия (это часто случается при внедрении нескольких систем от одного
поставщика, а также если при разработке заказных программных систем или
внедрении новых к ним изначально предъявляется требование по взаимодействию с
уже имеющимися системами).
Здесь, однако, таится опасность «ползучей» интеграции,
которая делает возможной ситуации, когда при необходимости поменять систему XYZ
неожиданно обнаруживается, что сделать этого нельзя, поскольку справочник
оргструктуры и сотрудников вашего предприятия, исторически ведущийся в XYZ,
каждую ночь реплицируется еще в десяток систем.
Хаб + спицы
Взаимодействие по типу «точка-точка» создает в
инфраструктуре предприятия слишком много связей и требует согласования
интерфейсов и форматов данных между взаимодействующими приложениями. Эти
недостатки призвана решить архитектура взаимодействия, в которой все приложения
непосредственно соединены только с центральным узлом, решающим следующие
задачи:
· организация маршрутизации
взаимодействия между интегрированными приложениями;
· преобразование форматов файлов и
данных;
· обеспечение взаимодействия приложений
с использованием разных методов и протоколов взаимодействия.
Благодаря введению промежуточного звена, уменьшается
число связей между приложениями, устраняются прямые связи, а система интеграции
становится более гибкой и дешевой в эксплуатации. Если меняется одно из
интегрированных приложений, то - при условии правильно спроектированной системы
интеграции - нужно будет модифицировать только одну связь, между данным
приложением и хабом.
Недостатком топологии «хаб + спицы» является высокая
стоимость приобретения и сложность программного инструментария, играющего роль
хаба, а также нехватка специалистов, имеющих опыт применения подобных
программных средств.
Обзор основных технологий
Буфер обмена
(clipboard)
Бу́фер обме́на (англ.
<#"787559.files/image001.gif">
Есть несколько деталей, которые отличают очереди сообщений от других
механизмов обмена данными в распределенной системе.
Доставка между клиентами одновременно не подключенными
Очередь сообщений поддерживается операционной системой
Очередь сообщений поддерживает транзакции
MSMQ 1.0 используется в Windows NT 4.0, Windows 95, and
Windows 98.
MSMQ 2.0 используется в Microsoft® Windows® 2000.
Этот протокол действительно оправдывает свое название - он обеспечивает
посылку сообщений между приложениями с помощью очереди сообщений. Основное его
отличие от стандартной очереди сообщений Windows в том, что он может работать с
удаленными процессами и даже с процессами, которые на данный момент недоступны
(например, не запущены). Доставка сообщения по адресу гарантируется. Оно
ставится в специальную очередь сообщений и находится там до тех пор, пока не
появляется возможность его доставить.
Удаленный вызов процедур (Remote Procedure Call, RPC)
Строго говоря, это не совсем технология IPC, а скорее способ значительно
расширить возможности других механизмов IPC. С помощью этой технологии общение
через сеть становится совешенно прозрачным как для сервера, так и для клиента.
Им обоим начинает казаться, что их "собеседник" расположен локально
по отношению к ним .
Удалённый
вызов процедур (или Вызов удалённых процедур) (от англ.
<http://ru.wikipedia.org/wiki/%D0%90%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%B8%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA>
Remote Procedure Call (RPC)) - класс технологий, позволяющих компьютерным
программам
<http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%D0%BD%D0%B0%D1%8F_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0>
вызывать функции <http://ru.wikipedia.org/wiki/%D0%A4%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%29>
или процедуры
<http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%B4%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0>
в другом адресном пространстве (как правило, на удалённых компьютерах). Обычно,
реализация RPC технологии включает в себя два компонента: сетевой протокол для
обмена в режиме клиент-сервер и язык сериализации
<http://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%80%D0%B8%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F>
объектов (или структур, для необъектных RPC). Различные реализации RPC имеют
очень отличающуюся друг от друга архитектуру и разнятся в своих возможностях:
одни реализуют архитектуру SOA <http://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%80%D0%B2%D0%B8%D1%81-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%B0%D1%8F_%D0%B0%D1%80%D1%85%D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%B0>,
другие CORBA <http://ru.wikipedia.org/wiki/CORBA> или DCOM <http://ru.wikipedia.org/wiki/DCOM>.
На транспортном уровне RPC используют в основном протоколы TCP
<http://ru.wikipedia.org/wiki/TCP> и UDP
<http://ru.wikipedia.org/wiki/UDP>, однако, некоторые построены на основе
HTTP <http://ru.wikipedia.org/wiki/HTTP> (что нарушает архитектуру
ISO/OSI
<http://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%82%D0%B5%D0%B2%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_OSI>,
так как HTTP <http://ru.wikipedia.org/wiki/HTTP> изначально не
транспортный протокол).
Принцип
Идея вызова удалённых процедур (Remote Procedure Call - RPC) состоит в
расширении хорошо известного и понятного механизма передачи управления и данных
внутри программы, выполняющейся на одной машине, на передачу управления и
данных через сеть. Средства удалённого вызова процедур предназначены для
облегчения организации распределённых вычислений и создания распределенных
клиент-серверных информационных систем. Наибольшая эффективность использования
RPC достигается в тех приложениях, в которых существует интерактивная связь
между удалёнными компонентами с небольшим временем ответов и относительно малым
количеством передаваемых данных. Такие приложения называются
RPC-ориентированными.
Характерными чертами вызова удалённых процедур являются:
· Асимметричность, то есть одна из взаимодействующих сторон
является инициатором;
· Синхронность, то есть выполнение вызывающей процедуры
приостанавливается с момента выдачи запроса и возобновляется только после
возврата из вызываемой процедуры.
Реализация удалённых вызовов существенно сложнее реализации вызовов
локальных процедур. Можно обозначить следующие проблемы и задачи, которые
необходимо решить при реализации RPC:
· Так
как вызывающая и вызываемая процедуры выполняются на разных машинах, то они
имеют разные адресные пространства, и это создает проблемы при передаче
параметров и результатов, особенно если машины находятся под управлением
различных операционных систем или имеют различную архитектуру (например,
используется прямой или обратный порядок байтов <http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%80%D1%8F%D0%B4%D0%BE%D0%BA_%D0%B1%D0%B0%D0%B9%D1%82%D0%BE%D0%B2>).
Так как RPC не может рассчитывать на разделяемую память, то это означает, что
параметры RPC не должны содержать указателей на ячейки нестековой памяти и что
значения параметров должны копироваться с одного компьютера на другой. Для
копирования параметров процедуры и результата выполнения через сеть выполняется
их сериализация
<http://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%80%D0%B8%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F>.
· В
отличие от локального вызова удалённый вызов процедур обязательно использует
транспортный уровень сетевой архитектуры (например TCP
<http://ru.wikipedia.org/wiki/TCP>), однако это остается скрытым от
разработчика.
· Выполнение
вызывающей программы и вызываемой локальной процедуры в одной машине
реализуется в рамках единого процесса. Но в реализации RPC участвуют как
минимум два процесса - по одному в каждой машине. В случае, если один из них
аварийно завершится, могут возникнуть следующие ситуации: при аварии вызывающей
процедуры удалённо вызванные процедуры станут «осиротевшими», а при аварийном
завершении удалённых процедур станут «обездоленными родителями» вызывающие
процедуры, которые будут безрезультатно ожидать ответа от удалённых процедур.
· Существует
ряд проблем, связанных с неоднородностью языков программирования и операционных
сред: структуры данных и структуры вызова процедур, поддерживаемые в каком-либо
одном языке программирования, не поддерживаются точно так же во всех других
языках. Таким образом имеется проблема совместимости, до сих пор не решённая ни
с помощью введения одного общепринятого стандарта, ни с помощью реализации
нескольких конкурирующих стандартов на всех архитектурах и во всех языках.
Разработка способа взаимодействия 2х приложений
В качестве способа взаимодействия приложений была выбрана технология
разделяемых файлов. В нашем примере одно приложение будет формировать XML файл, и записывать в него данные,
необходимые для работы другого приложения. Второе приложение считывает выходной
XML файл первого приложения и
обрабатывает содержащиеся в нем значения. Данная технология была выбрана в
первую очередь в виду простоты ее реализации.
Наши приложения работают на одном локальном компьютере и необходимость их
сетевого взаимодействия отсутствует. В случае, когда приложения должны будут
работать на разных компьютерах, будет нетрудно организовать взаимодействие с
применением технологии веб-сервисов. В этом случае сообщения так же будут иметь
структуру XML с небольшими изменениями, вносимыми
спецификацией SOAP. Главным отличием будет то, что одно
из приложений будет работать в качестве веб-срвиса (сервер), а другое в
качестве клиента данного веб - сервиса.
Так же в
данном примере отсутствует необходимость запуска второго приложения или
получения доступа его функционалу в рамках работы другого приложения. Для
решения этих задач лучше всего было бы воспользоваться технологией OLE/ActiveX,
которая делает возможным связывание и внедрение объектов в другие документы и
объекты.
Вопрос безопасности
Т.к. задача заключается в разработке не просто двух приложений,
взаимодействующих между собой, а в разработке способа контроля легальности
данного взаимодействия, было решено воспользоваться возможностями
криптографических функций фреймворка .NET.
Для обеспечения целостности данных мы будем использовать
криптографические цифровые подписи использующие алгоритмы с открытым ключом.
При подписывании данных с помощью цифровой подписи, другая сторона может
проверить подпись и убедиться в том, что данные поступили из соответствующего
источника и не были изменены после подписывания. Цифровые подписи обычно
применяются к хэш-кодам, которые являются отображениями некоторых массивов
данных большего размера.
Использование цифровых подписей в нашем примере решает сразу две проблемы
безопасности. Во-первых применение хеширования к исходному XML файлу гарантирует целостность данных
и предотвращает возможность их изменения третьей стороной. Хеш функции
представляют собой определенную последовательность символов, сформированную
хеш-алгоритмом на основе исходных данных. В результате изменения даже одного
символа в исходных данных приводит к получению совершенно отличной хеш-функции.
Данная особенность позволяет быть уверенным в том, что данные соответствуют хеш-функции.
Вторая проблема - невозможность быть уверенным, что данные получены от
нашего первого приложения. Злоумышленник может произвести подмену данных и
хеш-функции на свои, тогда сравнение хеш-функций не выявит нарушения
целостности. Первое приложение шифрует хеш-функцию ассимитричным алгоритмом
применяя свой закрытый ключ. Второе приложение дешифрует полученные данные
используя открытый ключ первого приложения и сравнивает полученную хеш-функцию
с вычисленной на основе полученных данных. В случае их совпадения появляется
сообщение о пройденной проверке. Применение цифровых подписей позволяет
однозначно идентифицировать автора.
Приложение
Пример XML файла
<?xml version="1.0"?>
<numbers>
<firstEl>123</firstEl>
<secondEl>33</secondEl>
<Signature
xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Transforms>
<Transform
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"
/>
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>fRa5HLoE4P8k2Bqq9/aVheND5RY=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>pV16GUJMtAYQq/qkx4EBWqhb2jyuLx1ni6z20Lp0jA16VZoU1Ltemi6MviNLm4UMbi7boSGG7bN27+vrFZJUv5o+zJBE7sC/fiZkNgQ3xQOC4cxLyrRWeuqobbWDuuut1ayG13m1hzpzWd4uxAKpnmPmMkgM3z2+BNvTUtc0RM4=</SignatureValue>
</Signature>
</numbers>
Исходный код первой программы
namespace WindowsFormsApplication5
{partial class Form1 : Form
{XmlDocument doc = new XmlDocument();Form1()
{();
}void button1_Click(object sender, EventArgs e)
{(saveFileDialog.ShowDialog() == DialogResult.OK)
{firstNumber = Convert.ToInt32(textBox1.Text);secondNumber =
Convert.ToInt32(textBox2.Text);newDec =
doc.CreateXmlDeclaration("1.0", null,
null);.AppendChild(newDec);newRoot =
doc.CreateElement("numbers");firstEl =
doc.CreateElement("firstEl");.InnerText = firstNumber.ToString();.AppendChild(firstEl);secondEl
= doc.CreateElement("secondEl");.InnerText =
secondNumber.ToString();.AppendChild(secondEl);
doc.AppendChild(newRoot);
// Создание контейнера ключей
CspParameters cspParams = new
CspParameters();.KeyContainerName = "XML_DSIG_RSA_KEY";
// Создание и сохранения в контейнере ключа
RSACryptoServiceProvider rsaKey = new
RSACryptoServiceProvider(cspParams);(doc, rsaKey);tr = new
XmlTextWriter(saveFileDialog.FileName, null);.Formatting =
Formatting.Indented;.WriteContentTo(tr);.Close();= new XmlDocument();
}
}static void SignXml(XmlDocument xmlDoc, RSA Key)
{
// Проверка аргументов(xmlDoc == null)
throw new ArgumentException("xmlDoc");(Key ==
null)new ArgumentException("Key");signedXml = new SignedXml(xmlDoc);
// Добавление ключа в SignedXml.SigningKey = Key;
// Ссылка на подписываемый элемент
документаreference = new
Reference();.Uri = "";
// Создание трансформации документа для корректного восстановления
XmlDsigEnvelopedSignatureTransform env = new
XmlDsigEnvelopedSignatureTransform();.AddTransform(env);.AddReference(reference);
// Вычисление подписи.ComputeSignature();
// Создание Xml элемента содержащего подписьxmlDigitalSignature =
signedXml.GetXml();
// Добаление подписи
в исходный документ.DocumentElement.AppendChild(xmlDoc.ImportNode(xmlDigitalSignature,
true));
}
}
}
Исходный код второй
программы
namespace WindowsFormsApplication6
{partial class Form1 : Form
{fileName;doc = new XmlDocument();numb1;numb2;sum;Form1()
{();
}void button1_Click(object sender, EventArgs e)
{(openFileDialog.ShowDialog() == DialogResult.OK)
{= openFileDialog.FileName;.Load(fileName);
}
// Создание объекта CspParameters и добавление контейнера ключей
CspParameters cspParams = new
CspParameters();.KeyContainerName = "XML_DSIG_RSA_KEY";
// Создание ключа из контейнераrsaKey = new
RSACryptoServiceProvider(cspParams);
// Проверка подписиresult = VerifyXml(doc, rsaKey);
// Отображение результатов проверки(result)
{.Show("Проверка пройдена");
}
{.Show("Проверка не пройдена");
}
}void button2_Click(object sender, EventArgs e)
{firstEl =
doc.SelectSingleNode("numbers/firstEl");=
Convert.ToInt32(firstEl.InnerText);secondEl =
doc.SelectSingleNode("numbers/secondEl");=
Convert.ToInt32(secondEl.InnerText);= numb1 + numb2;.Text = sum.ToString();
}static Boolean VerifyXml(XmlDocument Doc, RSA Key)
{
// Создание SignedXml объекта из документаsignedXml = new SignedXml(Doc);
// Поиск элемента SignaturenodeList =
Doc.GetElementsByTagName("Signature");
// Загрузка первой
записи
<signature>.LoadXml((XmlElement)nodeList[0]);
// Проверка подписиsignedXml.CheckSignature(Key);
}void Form1_Load(object sender, EventArgs e)
{
}
}
}
Список литературы