Воробьев А.М. 388x
advertisement
РОССИЙСКАЯ ФЕДЕРАЦИЯ
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ
ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ИНСТИТУТ МАТЕМАТИКИ И КОМПЬЮТЕРНЫХ НАУК
Кафедра информационной безопасности
Допустить к защите в ГАК
Заведующий кафедрой
информационной безопасности,
д.т.н., профессор А.А. Захаров
“____” _________ 2013 г.
Воробьев Артем Максимович
Организация безопасного обмена данными между МИС
“E-Anamnesis” и независимой информационной системой по
протоколу MedML.
(Выпускная квалификационная работа)
Научный руководитель:
Доцент кафедры, к.т.н.
__________ Оленников Е.А.
Автор работы:
__________ Воробьев А.М.
Тюмень - 2013
1
СОДЕРЖАНИЕ
ВВЕДЕНИЕ ................................................................................................................................................................. 3
ГЛАВА 1. ПОНЯТИЕ ВЕБ-СЕРВИСА, ПРОТОКОЛ MEDML И ПЛАТФОРМА .NET .............................. 6
1.1.
ВЕБ-СЕРВИС И ОСНОВНЫЕ ПОНЯТИЯ ........................................................................................................... 6
1.2.
СТАНДАРТ MEDML ..................................................................................................................................... 9
1.3.
ПРЕИМУЩЕСТВА C# И ПЛАТФОРМЫ .NET ................................................................................................. 12
1.3.2. Надежность и стабильность ASP.NET .............................................................................................. 13
1.3.3. Производительность и скорость ASP.NET ......................................................................................... 13
1.3.4. Интеграция с приложениями и прочими информационными системами........................................ 13
1.3.5. Сериализация и десериализация данных .............................................................................................. 14
ГЛАВА 2. ПРОЕКТИРОВАНИЕ ОБЩЕЙ КОНЦЕПЦИИ ОБМЕНА ДАННЫМИ ................................... 16
2.1. ОПИСАНИЕ МИС «E-ANAMNESIS» ................................................................................................................. 16
2.2.
1С.BITRIX «САЙТ МЕДИЦИНСКОЙ ОРГАНИЗАЦИИ»................................................................................... 17
2.3.
ОПИСАНИЕ ПРОЦЕССА ОБМЕНА ДАННЫМИ ............................................................................................... 18
ГЛАВА 3. РЕАЛИЗАЦИЯ ВЕБ-СЕРВИСА ........................................................................................................ 21
3.1. РЕАЛИЗАЦИЯ ПРОТОКОЛА MEDML ................................................................................................................. 21
3.2.
ОБЗОР МЕТОДОВ ВЕБ-СЕРВИСА .................................................................................................................. 28
3.2.1.
Prepare_Services_Doc() ................................................................................................................... 28
3.2.2.
Prepare_Services_Schedule_Doc() ................................................................................................... 30
3.2.3.
Output_ticket (ref Документ[] orderModel) .................................................................................... 32
3.2.4.
Prepare_Organization_Doc() ........................................................................................................... 38
ГЛАВА 4. БЕЗОПАСНОСТЬ ................................................................................................................................ 40
4.1.
МОДЕЛЬ ВЕРОЯТНОГО НАРУШИТЕЛЯ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ ........................................... 41
4.1.1.
Описание возможных нарушителей .............................................................................................. 41
4.2.
ПЕРЕЧЕНЬ ОСНОВНЫХ УГРОЗ БЕЗОПАСНОСТИ ИНФОРМАЦИИ ................................................................... 42
4.2.1.
Угрозы, связанные с передаваемыми данными между МИС и сайтом, и пути их
минимизации ..................................................................................................................................................... 43
4.2.2.
Угрозы, приводящие веб-сервис в неработоспособное состояние, и пути их минимизации ... 43
4.2.3.
Угрозы, связанные безопасностью МИС и ЛВС ЛПУ, возникающие в связи с внедрением вебсервиса, и пути их минимизации..................................................................................................................... 46
4.3.
ОБЕСПЕЧЕНИЕ ЦЕЛОСТНОСТИ ДАННЫХ И ПОЛЬЗОВАТЕЛЬСКОЙ АУТЕНТИФИКАЦИИ С ПОМОЩЬЮ
ПОДПИСЕЙ XML ..................................................................................................................................................... 49
4.3.1.
Формирование цифровой подписи XML ........................................................................................ 51
4.3.2.
Проверка цифровой подписи XML ................................................................................................. 53
4.3.3.
Шифрование XML ........................................................................................................................... 55
4.3.4.
Обработка шифрования XML ........................................................................................................ 56
ЗАКЛЮЧЕНИЕ ....................................................................................................................................................... 57
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ ............................................................................................ 58
ПРИЛОЖЕНИЕ А. ОПИСАНИЕ ВЗАИМОДЕЙСТВИЯ УЧАСТНИКОВ ОБМЕНА В ФОРМАТЕ
MEDML ..................................................................................................................................................................... 60
ПРИЛОЖЕНИЕ Б. МОДЕЛЬ УГРОЗ ................................................................................................................. 65
2
Введение
Повышение качества и доступности медицинской помощи - один из
приоритетов государственной политики. Подтверждением этого является
принятая концепция развития системы здравоохранения в Российской
Федерации до 2020 года[1]. В данной концепции большое внимание уделено
вопросам
развития
и
применения
информационных
технологий
в
здравоохранении с целью повышения доступности и качества медицинской
помощи
населению.
Важнейшим
направлением
реализации
данной
концепции является развитие и применение в лечебно-профилактических
учреждениях (ЛПУ) систем типа "Электронная очередь" (ЭО), т.е. систем,
предоставляющих
возможность
самозаписи
пациентов
на
прием
к
специалистам через Интернет. Внедрение подобной системы должно
способствовать уменьшению очередей в самих поликлиниках, а так же
сократить время обслуживания каждого пациента.
В
медицинских
учреждениях
России
используется
множество
медицинских информационных систем (МИС), разработанных различными
компаниями, написанных на разных языках и имеющих разные структуры.
Большинство медицинских систем не предусматривают возможность
самозаписи через веб-сайт. Поэтому учреждения, использующие такие МИС,
при предоставлении возможности организации записи через интернет
вынуждены либо создавать собственный сайт, либо интегрировать в МИС
уже готовое решение для удаленной записи.
Одной из такой систем, не имеющей возможности записи через
интернет, является система E-Anamnises, использующаяся в Тюменском
кардиологическом центре. Эта система решает широкий спектр задач от
ведения справочной информации по работе учреждения до обеспечения
регистрации пациентов, оказанных услуг, ведения электронной истории
болезни и так далее.
3
Руководством Кардиоцентра было принято решение организовать
электронную запись через интернет, для чего использовать сайт на системе
«1С.Bitrix Сайт медицинской организации». Решение включает в себя
готовый функционал онлайн-регистратуры. Он позволяет посетителю сайта
просмотреть расписание работы специалистов медицинского учреждения и
выполнить запись на прием непосредственно с сайта. В результате
пациентам не нужно приходить в учреждение для получения талона, стоять
в очереди на прием к врачу.
1С.Bitrix имеет собственную базу данных (БД) и предоставляет
возможность записаться на прием через интернет согласно выгруженным в
нее данным.
Две эти системы могут работать автономно, однако чтобы избежать
дублирования
данных,
устаревшей
информации
и
неактуальных
справочников, необходима синхронизация.
Единый формат взаимодействия МИС и сторонних информационных
систем, в том числе и веб-сайтов – протокол MedML. Выбранный веб-сайт на
1С.Bitrix, способен осуществлять обмен данными только по данному
протоколу, что сводит к минимуму рассмотрение каких-либо других
стандартов.
Таким
образом
мы
получаем
требования
к
необходимому
синхронизующему объекту:
Универсальность. Способность осуществлять обмен данными между
системами: МИС «E-Anamnises» и «1С.Bitrix - Сайт медицинской
организации» по протоколу
MedML таким образом, чтобы
изменения структуры организации одной или другой системы не
привело к изменению веб-сервиса;
Безопасность. Обмен данными, при котором эксплуатация системы
не противоречит законодательству РФ, а именно ФЗ №152 «О
защите персональных данных».
4
Целью дипломной работы является организация безопасного обмена
данными между МИС “E-Anamnesis” и независимой информационной
системой по протоколу MedML.
Для достижения поставленной цели были сформулированы следующие
задачи:
1) Проработать общую концепцию организации обмена данными.
Обозначить подходы к реализации всех требуемых методов;
2) Разработать веб-сервис и модифицировать БД и ПО «E-Anamnesis»
для работы с данным веб-сервисом;
3) Минимизировать
возможные
угрозы
безопасности
МИС
и
передаваемых данных в связи с внедрением веб-сервиса.
5
Глава 1. Понятие веб-сервиса, протокол
MedML и платформа .NET
1.1. Веб-сервис и основные понятия
Программной системой, которая идентифицируется веб-адресом, со
стандартизированными интерфейсами, называется веб-сервисом.[2]
Веб-сервисы или веб-службы составляют концепцию приложений,
которые для взаимодействия используют стандартные протоколы сети
Интернет. Такой концептуальный подход к разработке программных систем
в настоящее время используют крупнейшие ИТ-компании, такие как: Sun,
Oracle, HP, Microsoft, IBM. Консорциум World Wide веб Consortium (W3C)
[3] стандартизирует технологии, использующиеся для реализации концепции
веб-сервисов.
Используемые стандарты для веб-сервисов:
UDDI
Универсальный
интерфейс
распознавания,
описания и интеграции. Каталог веб-служб и
сведений
о
компаниях, предоставляющих
веб-
службы во всеобщее пользование или конкретным
компаниям
WSDL
Язык описания внешних интерфейсов вебслужбы на базе XML
XML
Расширяемый
предназначенный
язык
для
хранения
разметки,
и
передачи
структурированных данных
SOAP
Протокол обмена сообщениями на базе XML
Связанность перечисленных технологий можно схематично изобразить
так:
6
составляет
XML
основу
другим
связанных
с
веб-сервисами
технологиям.
Наиболее известные и применимые в наше время протоколы
реализации веб-сервисов:
XML-RPC (XML Remote Procedure Call)
SOAP (Simple Object Access Protocol)
REST (Representational State Transfer)
Для удаленного взаимодействия с веб-сервисами используется Simple
Object
Access
взаимодействия
Protocol
(SOAP).
распределенных
программирования,
объектной
Задача
систем,
модели
SOAP
в
или
–
это
обеспечение
независимости
операционной
от
языка
системы
пользователя.
Веб-сервисы не обязаны использовать определенный транспортный
протокол, однако спецификация SOAP описывает подход, при котором
налаживается связь между SOAP-сообщениями и транспортным протоколом.
Протокол HTTP является наиболее часто используемым протокол
передачи данных SOAP-сообщений. Однако не исключено использование
таких транспортных протоколов, как: SMTP, FTP, TCP.
Согласно определению W3C, "WSDL - формат XML для описания
сетевых сервисов как набора конечных операций, работающих при помощи
7
сообщений, содержащих документно-ориентированную или процедурноориентированную информацию" [4].
WSDL-документ
хранит
описание
интерфейса
веб-сервиса
с
клиентскими приложениями. Он описывает вызов веб-сервисов, методы,
воспользовавшись которыми пользователь может получить те или иные
услуги, а так же способы обращения к используемым методам.
Universal Description, Discovery and Integration (UDDI) – это реестр
XML веб-сервисов, разработанных компаниями со всего мира. В данном
каталоге веб-сервисов пользователь может найти тот, который наилучшим
образом соответствует его требованиям. UDDI структурировано таким
образом, при котором можно осуществить поиск необходимого веб-сервиса,
а так же произвести публикацию собственно-разработанного сервиса.
Веб-сервисы принято считать программным обеспечением. Работать с
ними могут и пользователи, так и другие приложения (другие веб-сервисы).
8
1.2. Стандарт MedML
Разработчиками МИС до недавнего времени так и не был определен
унифицированный стандарт для выгрузки и загрузки данных медицинских
учреждений. HL7 - международный стандарт, с которым некоторые
единичные российские разработчики МИС начинают работать и считают его
перспективным. [5] Однако, если рассматривать реализацию решения для
каждой конкретно взятой задачи обмена информацией между МИС и вебсайтом, он обладает наборами избыточных данных, которые затрудняют
разработку и снижают эффективность приложений. Более того стандарт HL7
не полностью переведен на русский язык, что следует от американских
прародителей протокола, и мало адаптирован для российской специфики. По
перечисленным
причинам
стандарт
HL7
не
получил
широкого
распространения на российском рынке, в связи с чем многие производители
вынуждены
разрабатывать
собственные
локальные
протоколы
для
удовлетворения нужд только учреждения заказчика.
Такие ведущие компании разработчики, такие как: 1С, 1С-Битрикс и
еще ряд других используют и развивают стандарт MedML[6], который
соответствует всем требованиям российской медицинской специфики и
позволяет
эффективно
решить
задачу
по
интеграции
веб-сайта
в
медицинскую информационную систему, а также для обмена данными между
различными МИС при необходимости.
Данный протокол возник еще в конце 1990-х годах в США.
Американским врачам был необходим единый формат данных, который
позволял бы им вести записи о пациентах и передавать накопленную
информацию
друг
другу.
Все
начиналось
с
некоторых,
наиболее
используемых позиций, таких как: ФИО пациента, пол, возраст, дата
рождения, номер амбулаторной карты и тп, после чего позиции стали
дополняться по мере необходимости.
9
Российские медицинские учреждения решили перенять зарубежный
1
опыт в 2010 году
.
Такому исходу событий способствовала компания 1С,
которая представила шаблонный сайт на платформе 1С.Bitrix для ЛПУ, в
основе которого лежит стандарт MedML на русском языке. Данной
компанией было предложено несколько решений для поликлиник, которые
позволяли без труда производить обмен информацией между ЛПУ и сайтом
организации.
Протокол MedML ощутимо снижает издержки на организацию
взаимодействия информации за счет унификации обмена между веб-сайтами
и медицинскими информационными системами любых производителей.
Имея единый набор данных, медицинские информационные системы,
применяющие стандарт, смогут осуществлять обмен информацией с
интернет-сайтами не только 1С, но и других различных производителей.
Выгрузка на сайт прейскуранта медицинских услуг (прайс-листов), сведений
о кадровом составе медицинской организации, ее структуре будет возможна
непосредственно из медицинской информационной системы.
Вот лишь один из примеров данных формата MedML:
Стандарт MedML полностью соответствует требованиям Приказа Минкомсвязи РФ от 27
Декабря 2010 N 190 «Об утверждении Технических требований к взаимодействию
информационных систем в единой системе межведомственного электронного
взаимодействия».
1
10
На рисунке показана схема раздела «Услуги» в виде XML по стандарту
MedML.
Корневой узел называется «Услуга», который определяет информацию
о заказываемой услуге. Он содержит потомков, которые описывают каждую
из услуг:
ИдУслуги – идентификатор оказываемой услуги;
ИдСотрудника – массив, состоящий из одного или нескольких
сотрудников, которые выполняют заказываемую услугу так, как они
определены в разделе расписание;
ИдПомещения – массив, включающий в себя помещение или
помещения, в которых выполняется услуга;
ПериодВремени – период времени, на который заказывается услуга;
11
Цена – стоимость оказываемой услуги;
Налоги – удерживаемые со стоимости услуг налоги;
Скидки;
Пациент – клиент учреждения, записанный на данную услугу.
Формат не обязывает использовать все поля при обмене данными,
поэтому задействуются только те, которые необходимы для отлаженной
работы систем.
Подробное описание всех используемых прикладных типов указано в
приложении (Приложение А).
1.3. Преимущества C# и платформы .Net
Первая причина разработки языка С# компанией Microsoft - cоздание
компонентно-ориентированного языка для новой платформы .NET.
Вторая - это создание альтернативы языку Java. Это обусловлено тем,
что Microsoft была вынуждена отказаться от Java, по существующим на то
мотивам. Тогда они создали свой Java-подобный язык, который и получил
название C#.
ASP.NET — это технология создания веб-приложений и веб-сервисов
от компании Майкрософт. Она исполняется на платформе Net FrameWork,
которая увеличивает скорость разработки веб приложений, используя всю
мощь платформы .Net. Основным языком программирования на платформе
Net служит С#.
1.3.1. Преимущества разработки сайтов с ASP.NET
Технология
MS
ASP.NET
применяется
для
разработки
веб-
приложений, Internet-сайтов, веб-сервисов. Технология была предложена
компанией Майкрософт для тех, кто на базе ASP.NET выполняет
определенные задачи, связанные с созданием сайтов с небольшим
количеством данных, в равной степени, как и для тех, кто трудится над
созданием высоконадежного сетевого портала, рассчитанного на сотни тысяч
ежедневных посещений. Крупнейшие и популярные сайты известных
12
брендов Майкрософт, Lego, Вольво, Тойота, Хонда, Радио Свобода,
Коммерсант, L'Oreal, и других были разработаны именно на ASP.NET.
1.3.2. Надежность и стабильность ASP.NET
Огромное значение для современного бизнеса имеет отсутствие
простоев, не важно, будет это на час или несколько часов в день. Простой
приводит к серьезным убыткам, удару по репутации в деловом мире. Именно
поэтому огромную роль в работе сайта играет его надежность и устойчивость
к хакерским атакам. Встроенная защита от различных видов нападений,
предоставляет следующие возможности: SQL Injection, переполнение буфера,
XSS, изменение скрытых полей и прочие. Технология ASP.NET повышает
степень устойчивости к вредоносным действиям и различным видам
хакерских атак сайтов, построенных на ней.
1.3.3. Производительность и скорость ASP.NET
Строение
ASP.NET
как
технологии
позволяет
компилировать
программный код и все страницы сайта. Код интерпретируется в PHP
значительно медленнее и не дает нужного эффекта производительности.
Особенно это касается активного использования в разработке сайта
концепции
ООП.
Благодаря
тому,
что
в
ASP.NET
встроено
функционирование сайта на кластере сервера, при увеличении посещаемости
на сайте достигается масштабируемость.
1.3.4. Интеграция с приложениями и прочими
информационными системами
Платформа Microsoft .NET имеет множество встроенных технологий
для интеграции информационных систем и приложений, таких как службы
web, WCF, JSON, remoting, XML и пр., при этом ASP.NET существует как ее
часть. Наличие таких многочисленных решений дает возможность выбора
оптимальной технологии для каждого отдельного случая. Это обеспечит
13
отменную производительность, масштабируемость и, самое главное, безопасность.
1.3.5. Сериализация и десериализация данных
Процесс сериализации – это процесс, где байтовый поток, который
возможно сохранить в базе данных или файле, получается из объекта. Ее
сущность заключается в том, чтобы оставить состояние объекта неизменным
для того, чтобы была возможность воспроизвести его при необходимости.
В байтовом представлении объекта хранятся данные о версии, типе и
характеристиках объекта, а так же имена его сборок.
Десериализация является процессом обратным сериализации, который,
в свою очередь представляет байтовый поток в объект.
(общая схема сериализации)
Сериализацию используют для обмена данными при передаче
объектов. Именно данный метод является оптимальным для отправки того
или иного объекта с помощью веб-сервисов, чтобы передать объект между
доменами, передать объект в виде XML-строки в брэндмауер и хранить
данные для использования несколькими приложениями.
XML-сериализация так же называется двоичной. Особенность данного
типа сериализации заключается в том, что ей подвергаются даже те
элементы, которые имеют статус «только для чтения», в связи с этим
увеличивается эффективность работы. Более того двоичная сериализация
имеет удобный читабельный вид и приемлемость для грамотной и легкой
интеграции систем..
14
В XML-поток попадает содержание открытых свойств и полей объекта
либо же возвратные параметры и значения методов согласно документу,
составленным на языке XSD, определяющим схему документа.
Четко типизированные классы с открытыми полями и свойствами
создаются
при
XML-сериализации.
Классы
пространства
имен
System.Xml.Serialization необходимы для XML - десериализации и XML сериализации.
15
Глава
2.
Проектирование
общей
концепции обмена данными
2.1. Описание МИС «E-Anamnesis»
Система E-Anamnesis, внедренная в Тюменском кардиологическом
центре.
Данная система состоит из набора следующих компонентов:
Сервер базы данных – где хранятся все справочники данных по
пациентам, сотрудникам, расписанию;
Отделения, лаборатории ЛПУ и узкие специалисты – где происходит
обработка результатов исследований пациентов;
Приемное отделение и регистратура – регистрация пациентов,
формирование расписания приема врачей и запись на прием.(Рис. 1)
Рис. 1. Схема Тюменского Кардиологического Центра
16
Функция самозаписи клиентов через интернет в МИС E-Anamnesis
отсутствует. На текущий момент каждый пациент может записаться на
прием, только либо придя в регистратуру учреждения, либо позвонив в
регистратуру по телефону, однако для этого человеку нужно владеть
информацией о времени приема интересующего врача, а так же при таком
методе записи, пациент не владеет информацией о свободном времени
приема – отсутствует режим текущего состояния очереди.
2.2. 1С.Bitrix «Сайт медицинской организации»
В середине 2012 года руководством учреждения был поднят вопрос о
необходимости разработки веб-сайта, который бы носил не только
информативный характер, но и давал возможность пациентам производить
запись на прием.
В ходе исследования руководством кардиологического центра была
выбрана платформа для разработки сайта – 1С.Bitrix Сайт медицинской
организации [7]
«1С-Битрикс: Сайт медицинской организации» - типовая программная
система
отрасли
здравоохранения,
которая
позволяет
разработать
официальный веб-сайт на основе системы «1С-Битрикс: Управление сайтом».
К
функциям,
осуществляемых
сайтом,
можно
отнести
раскрытие
информации гражданам и организациям о деятельности ЛПУ:
Общая информация, структура организации, с указанием контактной и
новостной информации;
Справочник
оказываемых
услуг
с
условиями
их
оказания
и
стоимостью;
Справочник врачей, который отображает степень каждого специалиста
и опыт его работы;
Расписание приема врачей на указанный период с отображением
свободного и занятого времени;
17
Онлайн-регистратура,
с
помощью
которой
у
пациента
есть
возможность осуществить запись через интернет.
Модуль электронной записи на прием в системе 1C.Bitrix дает
возможность пользователю сайта медицинского учреждения просмотреть
график работы специалистов ЛПУ и осуществить запись на прием напрямую
с сайта, без обращения в медицинскую организацию.
Таким образом пациентам не нужно приходить на прием заранее,
чтобы занять очередь, и кроме того скорость обслуживания клиентов ЛПУ
возрастает за счет упорядоченности потока пациентов.
2.3. Описание процесса обмена данными
Для поддержания справочников по услугам, специалистам, а так же
расписания и записи на прием в актуальном состоянии необходимо
обеспечить взаимодействие двух систем, иначе актуальность данных будет
потеряна в связи с ее устареванием.
Если говорить о синхронизации двух систем, то здесь необходим выбор
способа взаимодействия систем и формата обмена данными.
Синхронизация интерпретируется как обмен данными, которые
представлены ниже:
Справочная информация - данные, которые МИС экспортирует на
сайт:
Справочник услуг, которые оказывает учреждение;
Справочник кабинетов и специалистов-врачей;
Расписание, по которому оказываются услуги;
дополнительная информация о медицинских услугах (общая
информация, время выполнения услуги, необходимая
подготовка, показания, противопоказания, информированное
согласие на выполнение услуги);
18
Оперативная информация:
данные для экспорта с сайта в МИС, которые представляют
заявку на предварительную запись на услугу:
информация о пациенте – ФИО, дата рождения и др. поля;
данные о записи пациента на исполнение услуги: услуга,
атрибуты, дата и время, специалист;
файлы импорта в сайт из МИС, содержащие следующую
информацию:
через сайт на талоны направляются заявки
выдача талонов через сайт
справочник талонов на дату с указанием занятости.
импортируемые сайтом из МИС данные по обработке заявки на
предварительную запись на услугу:
статус заявки;
результат обработки заявки;
присвоенный номер заявки.
Главной системой при организации обмена данными является МИС, на
сайте возможно только отображение справочников, а вся модификация
(добавление, удаление, обновление) списков врачей, услуг, расписания
происходит непосредственно в самой МИС, после чего информация может
передаваться на веб-сайт.
Что касается записи на прием, то веб-сайт от 1C.Bitrix имеет
возможность запрашивать разрешение записи на указанное время и
исполнять запись только после подтверждения главной системы.
Для сайта Bitrix уже реализована возможность обмена данными с МИС,
однако для этого МИС должна иметь соответствующий веб-сервис,
поддерживающий
обмен
данными
по
протоколу
MedML.
Поэтому
единственное решение для организации взаимодействия - это веб-сервис.
19
Ниже представлена схема взаимодействия двух систем.
В БД МИС был реализован набор хранимых процедур и представлений
[8], который использует веб-сервис при работе с БД. Это своего рода
интерфейс, который
можно использовать при интеграции веб-сервиса в
другую МИС, где требуется лишь организовать правильную выгрузку
представлений и вызов хранимых процедур. Так же такой подход
положительно сказывается на безопасности, о чем будет сказано в
последующих главах.
20
Глава 3. Реализация веб-сервиса
3.1. Реализация протокола MedML
веб-сервис поддерживает все функции, которые описываются в
стандарте MedML. Ниже представлена часть wsdl-файла методов веб-сервиса
21
Как видно из представленного кода, для обработки на веб-сервис
приходит только две функции.
1)
Функция - ОбработатьДокумент предназначена для заказа или
отмены услуг.
Операция
имеет
один
двунаправленный
параметр
(входной
и
выходной), который имеет тип <Документ>, интерфейс которого представлен
ниже.
22
Свойство <Операция> параметра <Документ> должно иметь значение
"Заказ услуг" или "Отмена услуг", в зависимости от необходимой функции.
Статусы услуг в документе, отправляемом wsdl-серверу, имеют
значение "Заказано" или "Отменено". После обработки wsdl-сервер
возвращает параметр <Документ>, статусы услуг в котором могут принимать
значение "Подтверждено" или "Отказано". Если статус услуги принимает
значение "Отказано", то для этой услуги заполняется поле "Комментарий" с
описанием причины отказа.
Операция возвращает в качестве результата булево значение, которое
равняется "True", если все услуги поменяли статус на "Подтверждено", или
"False", если хотя бы у одной услуги статус оказался равным "Отказано".
Операция возвращает "False" также в том случае, если не удалось
идентифицировать пациента.
2)
Функция – ПолучитьДанные, предназначена для получения
данных об организации в целом, расписании ее работы, оказываемых в ней
услугах. Кроме этого, операция может передавать документы, отменяющие
по каким-либо причинам услуги, ранее заказанные с сайта.
Операция
возвращает
значение
типа
<ИнформацияДляЗаписиНаПрием>. Содержание возвращаемого значения
зависит от параметров, переданных wsdl-серверу и от значений реквизитов
соответствующего узла плана обмена МИС с сайтом.
Операция
имеет
один
двунаправленный
параметр
(входной
и
выходной) с именем <Параметры>, который может иметь вложенные тегипараметры:
Параметр
Тип
Описание
Установка
Выгрузка
организаций
Булево
Определяет, следует ли выгружать <ВыгрузкаОрганизаций>true
данные об организации на сайт. На </ВыгрузкаОрганизаций>
сайт выгружаются список
подразделений, список
сотрудников, список медицинских
кабинетов, список врачебных
23
участков.
Выгрузка
расписания
Булево
Определяет, следует ли выгружать
расписание на сайт.
<ВыгрузкаРасписания>true
</ВыгрузкаРасписания>
Выгрузка
услуг
Булево
Определяет, следует ли выгружать
перечень медицинских услуг на
сайт.
<ВыгрузкаУслуг>true
</ВыгрузкаУслуг>
Выгрузка
Булево
пакета
предложений
Определяет, следует ли выгружать
пакет предложений на сайт. В
пакете предложений передаются
цены на медицинские услуги.
<ВыгрузкаПакетаПредложений>
true
</ВыгрузкаПакетаПредложений>
Обмен
заказами
Определяет, будут ли медицинская <ОбменЗаказами>true
информационная система и сайт
</ОбменЗаказами>
обмениваться данными о заказах.
Сайт может передавать
информацию о заказе или отмене
заказа услуг. МИС подтверждает
заказ (отмену заказа) или
уведомляет об отмене услуг, если
ранее они были заказаны через
сайт.
Булево
Обработка входящего сообщения, значения <Параметры>, происходит
при помощи веб-метода:
24
После выполнения необходимого метода обработки входного
параметра происходит сериализация возвращенного параметра по протоколу
MedML стандартными средствами [9] и передача его веб-сайту.
Сериализация имеет ключевую роль в веб-сервисе, так как сообщение
между двумя системами (1C.Bitrix и МИС) должно происходить по
протоколу MedML. В связи с этим для начала производится описание
классов, объекты для которых подвергнутся сериализации. Так как выгрузка
на сайт состоит из нескольких списков: выгрузка списка услуг, списка
25
организаций, списка врачей, расписания, изменений, то описывается каждый
из классов по отдельности.
Одним из родительских классов является
«ИнформацияДляЗаписиНаПрием».
С помощью System.Xml.Serialization.XmlElementAttribute описываются
все элементы данного класса, каждый из которых является самостоятельным
классом, на что указывает тип typeof() каждого атрибута.
26
27
3.2. Обзор методов веб-сервиса
Для организации обмена информацией реализованы следующие методы:
Метод
Prepare_Services_Doc()
Тип
возвращаемого
значения
(MedML)
Услуги
Prepare_Services_Schedule_
Doc()
Расписание
Prepare_Organization_Doc()
Организации
Output_ticket(ref Документ[] bool
orderModel)
Prepare_Offer_Doc()
Предложения
Описание
Формирование списка
услуг для выгрузки
Формирование
расписания для
выгрузки
Формирование списка
организаций,
специалистов
Формирование талона
записи в МИС
Формирование пакета
предложений
3.2.1. Prepare_Services_Doc()
Метод, формирующий список услуг организации
public Услуги Prepare_Services_Doc()
{
//Создаем объект Услуги
Услуги Servises = new Услуги();
Servises.Ид = "";
Servises.ИдОрганизации = "1";
Servises.Описание = " ";
Услуга[] usl = new Услуга[0];
IQueryable<ServicesTable> ServicesDateSet = _dataProvider.GetServices();
int j = 0;
foreach (var rec in ServicesDateSet)
{
Array.Resize(ref usl, j+1);
usl[j] = new Услуга();
usl[j].Ид = rec.Id.ToString();
usl[j].ИдОрганизации = "1";
usl[j].ИдПодразделения = " ";
usl[j].Наименование = rec.Name;
usl[j].Описание = " ";
j++;
}
Servises.Услуга = usl;
return Servises;
}
28
Так как выгрузка услуг происходит в пределах одной организации, а
именно Тюменского Кардиоцентра, то поле ИдОрганизации равно константе,
так как массив организаций состоит из одного члена. .кардиоцентр не имеет
структурных подразделений, поэтому это поле остается пустым.
Единственным важным значением является «наименование» и «ид» услуг,
которые заполняются для выгрузки после обращения к представлению,
которое содержит справочник услуг организации.
IQueryable<ServicesTable> ServicesDateSet = _dataProvider.GetServices();
- обращение к представлению таблицы Услуги. [9а]
namespace cardio_db.Entities
{
[Table(Name = "веб_serv_services")]
public class ServicesTable
{
[Column(Name="id", IsPrimaryKey = true, IsDbGenerated = true, AutoSync = AutoSync.OnInsert)]
public int Id { set; get; }
[Column(Name="name")]
public string Name { set; get; }
[Column(Name = "Vrach_id")]
public int? Vrach_id { set; get; }
[Column(Name = "TimeOnReception")]
public int TimeOnReception { set; get; }
}
}
В данном представлении передаются ИД самой услуги, ее название,
идентификатор врача, осуществляющего данную услугу и время приема.
29
3.2.2. Prepare_Services_Schedule_Doc()
Метод, формирующий расписание для выгрузки из МИС на веб-сайт.
public Расписание Prepare_Services_Schedule_Doc()
{
Расписание Schedule = new Расписание();
Schedule.Ид = SheduleId;
ЗаписьРасписания[] ScheduleRecs = new ЗаписьРасписания[0];
IQueryable<ServicesTable> ServicesDateSet = _dataProvider.GetServices();
DateTime fromDate = DateTime.Now;
DateTime toDate=fromDate.AddDays(14);
int j = 0;
//Проходим по списку услуг
foreach (var rec in ServicesDateSet)
{
Array.Resize(ref ScheduleRecs, j + 1);
ScheduleRecs[j] = new ЗаписьРасписания();
//
ScheduleRecs[j].ДоступныеУслуги = new String[1] {rec.Id.ToString()};
ScheduleRecs[j].ИдСотрудника = rec.Vrach_id.ToString()?? "";
decimal TimeOnReception = rec.TimeOnReception;
List<iCal.DateItem> ss;
ss = _dataProvider.GetServiceSchedule(rec.Id, fromDate, toDate);
ПериодРаботы[] pws = new ПериодРаботы[0];
int i=0;
foreach (var rec1 in ss)
{
Array.Resize(ref pws, i + 1);
ПериодРаботы pw = new ПериодРаботы()
{
НачалоПериода=rec1.StartDate,
КонецПериода=rec1.EndDate,
СвободноеВремяВМинутах = TimeOnReception,
СвободноеВремяВМинутахSpecified=true
};
pws[i]=pw;
i++;
}
ScheduleRecs[j].ПериодыРаботы = pws;
j++;
}
Schedule.ЗаписьРасписания = ScheduleRecs;
return Schedule;
}
По умолчанию веб-сайт делает выгрузку расписания на ближайшие 14
дней, поэтому значения полей fromDate и toDate равны текущему числу
иприбавленному к нему четырнадцати дням с помощью стандартного метода
AddDays соответственно.
IQueryable<ServicesTable> ServicesDateSet = _dataProvider.GetServices();
- выдает весь имеющийся список услуг, для которых необходимо построить
30
расписание. Для каждой из услуг создается своя «Запись расписания», в
которой прописывается ид услуги, идентификатор специалиста,
выполняющий данную услугу, TimeOnReception отвечает за время, которое
необходимо для обслуживания данной услуги.
В базе МИС информация о расписании хранится в виде правил
(Библиотека
классов
iCal)
[http://sourceforge.net/projects/dday-ical/],
по
которым осуществляется прием. Когда доктор №1 оказывает услугу №1 по
понедельникам и пятницам с 9:00 до 13:00, задается правило, которое
распространяется на все время, если иное не будет задано.
RRULE:FREQ=WEEKLY;UNTIL=20140928T000000;BYDAY=MO,FR
Функция _dataProvider.GetServiceSchedule(rec.Id, fromDate, toDate) –
возвращает все временные интервалы приема для услуги за 14 дней.
Согласно стандарту MedML такие временные промежутки хранятся с
указанием начала и окончания периода приема, а так же свободного времени
на прием. Если значение поля СвободноеВремяВМинутах равняется нулю,
значит этот период является занятым и запись на него является невозможной.
31
В данном примере изображено отображение свободных периодов для
специалиста Зайцева Д.Н. услуги «Мануальная терапия». Значение
«СвободноеВремяВМинутах» временного интервала с 9:00 до 9:30 в четверг
29 числа равняется нулю, поэтому промежуток приема отображается как
занятый.
Стандарт MedML не позволяет, как это устроено в МИС, устанавливать
правило для всего расписания, в полной мере воспользоваться данным
решением правил можно в рамках одного дня. Таким образом выгрузка
расписания на один день для одной услуги будет иметь следующий вид (на
представленном выше рисунке, расписание на 27 число):
<ИдСотрудника>001</ИдСотрудника>
<ИдПомещения> </ИдПомещения>
<ПериодРаботы>
<НачалоПериода>2013-03-27T8:00:00Z</НачалоПериода>
<КонецПериода>2013-03-27T12:00:00Z</КонецПериода>
<СвободноеВремяВМинутах>30</СвободноеВремяВМинутах>
</ПериодыРаботы>
<ДоступныеУслуги>
<ИдУслуги>00.000.01</ИдУслуги>
</ДоступныеУслуги>
3.2.3. Output_ticket (ref Документ[] orderModel)
Метод, для формирование талона записи в МИС.
public bool Output_ticket(ref Документ orderModel)
{
int proverka = 0;
int r = 0;
r = _dataProvider.rec_to_schedule(orderModel.Ид, Convert.ToInt32(orderModel.Услуги[0].ИдУслуги),
Convert.ToInt32(orderModel.Услуги[0].ИдУслуги), orderModel.Пациент.Имя, orderModel.Пациент.Фамилия,
orderModel.Пациент.Отчество,
orderModel.Услуги[0].ПериодВремени.НачалоПериода,
orderModel.Услуги[0].ПериодВремени.НачалоПериода,
orderModel.Услуги[0].ПериодВремени.КонецПериода, ref r);
if (r < 0)
{
32
orderModel.Услуги[0].Статус = СтатусУслугиТип.Отказано;
proverka++;
}
bool tf = true;
if (proverka > 0)
{
tf = false;
}
else
{
tf = true;
}
return tf;
}
После того как пациент заходит на сайт, он просматривает расписание
на необходимые даты. После чего он делает свой выбор и отправляет запрос
на запись. Сайт направляет запрос в МИС на подтверждение записи,
формируя талон, содержащий информацию как о пациенте, так и о самой
записи, поэтому после получения веб-сервисом этого талона, происходит
десериализация, подтверждение и запись в МИС.
Талон имеет следующую структуру:
<?xml version="1.0" encoding="UTF-8"?>
<ИнформацияДляЗаписиНаПрием xmlns="http://medml.ru/standard/MedML.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Документ>
<Ид>2396909670</Ид>
<Дата>2013-04-16T11:50:45</Дата>
<Операция>Заказ услуг</Операция>
<Пациент>
<Фамилия>Фамилия</Фамилия>
<Имя>Имя</Имя>
<Отчество>Отчество</Отчество>
</Пациент>
<Услуги>
<Услуга>
<ИдСотрудника>231</ИдСотрудника>
<ИдУслуги>323</ИдУслуги>
<ПериодВремени>
<НачалоПериода>2013-04-17T10:35:00</НачалоПериода>
<КонецПериода>2013-04-17T11:00:00</КонецПериода>
</ПериодВремени>
33
<Статус>Подтверждено</Статус>
</Услуга>
</Услуги>
</Документ>
</ИнформацияДляЗаписиНаПрием>
Формат MedML предусматривает специальное поле подтверждения
записи
–
поле
«Статус».
Оно
может
принимать
два
значения:
«Подтверждено», если запись на данное время произведена успешно и
«Отклонено», если запись не может быть сделана.
После того как МИС принимает талон, она проверят доступность
свободного периода, на который происходит запись. Это требуется для того,
чтобы исключить ошибку актуальности информации: с момента последней
синхронизации сайта и МИС, кто-то уже сделал запись в регистратуре
учреждения на указанное время и запись является недоступной. Так же
пациент мог забыть, что уже записан к другому специалисту на данное
время, в этом случае запись опять-таки должна быть отклонена.
Поэтому при получении талона веб-сервис вызывает процедуру
rec_to_schedule(), которая производит запись в БД МИС.
Данная процедура сначала проверяет выполняются ли два условия:
isDoctorVacant – не занято ли желаемое время другим пациентов
isPatientVacant – не записан ли пациент к другому специалисту на это
время.
При выполнении обоих условий происходит запись и значение поля
«Статус»
остается
равным
«Подтверждено»,
в
противном
случае
возвращается «Отказано» с указанием причины отказа.
В связи с тем, что запись пациентов довольно часто осуществляется
через регистратуру, актуальным вопросом является передача информации о
занятых временных интервалах расписания. Выгрузка обновившихся
позиций в расписании осуществляется периодически и инициируется
системой 1C.Bitrix. Для экономии трафика веб-сайт предусматривает
обновления за весь день только по определенной услуге для конкретного
34
специалиста. Целесообразнее было бы предусмотреть только замену статуса
свободного периода на «занятый», однако такая функция на сайте Bitrix еще
не реализована. Тем не менее даже такой подход позволяет снижать объем
передаваемого трафика с более 20МБ за все расписание, до пары сотен КБ
только обновлений.
Специально под хранение только изменений выделена отдельная
таблица в БД МИС. Она заполняется с помощью триггеров, срабатывающих
на добавление, удаление или обновление записей в главную таблицу
«Расписание», которая используется для работы МИС.
Она содержит в себе поля: дата, на которую записался пациент,
идентификатор услуги, тип услуги (в МИС возможны два типа услуг: поле
isDoctor=1, при котором запись расписания – это распорядок приема
специалиста, и isDoctor=0, когда запись на прием принадлежит пациенту) и
поле удаления, значение которого влияет на удаление записей после
выгрузки на сайт.
Перед вставкой триггер проверяет на наличие уже имеющийся записи в
данной таблице, сравнивая вставляемые данные с уже имеющимися в
таблице по всем полям. Сам процесс проверки не является ресурсозатратным,
так как при среднем количестве услуг в Кардиоцентре равным 50,
максимальное количество записей в ней может быть количество услуг,
умноженное на 14 дней, что составляет 700.
При изымании данных из данной таблицы с помощью указания
параметра «ВыгрузкаТолькоИзменений» для указанной даты по услуге
формируется полное расписание с указанием занятых временных интервалов.
public Расписание Prepare_Services_Schedule_ONLY_CHANGES_Doc()
{
Random rnd1 = new Random();
//Создаем объект Услуги
Расписание Schedule = new Расписание();
Schedule.Ид = rnd1.Next(1000000000).ToString();
ЗаписьРасписания[] ScheduleRecs = new ЗаписьРасписания[0];
IQueryable<ServicesChangesTable> ServicesDateSet = _dataProvider.GetServicesChangesTable();
int j = 0;
int[] count = new int[0];
int number = 0;
35
foreach (var rec in ServicesDateSet)
{
Array.Resize(ref count, number + 1);
count[number] = rec.DoctorObservationId;
number++;
}
foreach (var rec in ServicesDateSet)
{
DateTime fromDate = rec.EndTime;
DateTime toDate = rec.EndTime;
//Проходим по списку услуг
IQueryable<ServicesTable> ServicesDateSet1 =
_dataProvider.веб_serv_get_веб_serv_services(rec.DoctorObservationId);
foreach (var rec1 in ServicesDateSet1)
{
Array.Resize(ref ScheduleRecs, j + 1);
ScheduleRecs[j] = new ЗаписьРасписания();
ScheduleRecs[j].ДоступныеУслуги = new String[1] { rec1.Id.ToString()};
ScheduleRecs[j].ИдСотрудника = rec1.Vrach_id.ToString() ?? "";
decimal TimeOnReception = rec1.TimeOnReception;
List<iCal.DateItem> ss;
ss = _dataProvider.GetServiceSchedule(rec1.Id, fromDate, toDate);
ПериодРаботы[] pws = new ПериодРаботы[0];
int i = 0;
foreach (var rec2 in ss)
{
Array.Resize(ref pws, i + 1);
ПериодРаботы pw = new ПериодРаботы()
{
НачалоПериода = rec2.StartDate,
КонецПериода = rec2.EndDate,
СвободноеВремяВМинутах = TimeOnReception,
СвободноеВремяВМинутахSpecified = true
};
pws[i] = pw;
i++;
}
ScheduleRecs[j].ПериодыРаботы = pws;
j++;
}
IQueryable<ServicesScheduleOrderTable> Schedule_Ordered =
_dataProvider.GetScheduleOrder(fromDate, toDate);
foreach (var rec1 in Schedule_Ordered)
{
if (count.Contains(rec1.DoctorObservationId))
{
Array.Resize(ref ScheduleRecs, j + 1);
ScheduleRecs[j] = new ЗаписьРасписания();
ScheduleRecs[j].ДоступныеУслуги = new String[1] { rec1.DoctorObservationId.ToString() };
ScheduleRecs[j].ИдСотрудника =
_dataProvider.веб_serv_get_vrach_id(rec1.DoctorObservationId).ToString();
ПериодРаботы[] pws1 = new ПериодРаботы[1];
ПериодРаботы pw1 = new ПериодРаботы()
{
36
НачалоПериода = rec1.StartTime,
КонецПериода = rec1.EndTime,
СвободноеВремяВМинутах = 0,
СвободноеВремяВМинутахSpecified = true
};
pws1[0] = pw1;
ScheduleRecs[j].ПериодыРаботы = pws1;
j++;
}
}
}
Schedule.ЗаписьРасписания = ScheduleRecs;
return Schedule;
}
В данном методе сначала заполняется полное расписание по каждой
услуге по определенной дате, взятой из временной таблицы, хранящей
изменения, а затем накладываются записанные периоды.
37
3.2.4. Prepare_Organization_Doc()
Метод, формирующий список организаций и сотрудников.
public Организации Prepare_Organization_Doc()
{
Организации Organizations = new Организации();
Organizations.Ид = "test_id";
Организация[] org1 = new Организация[1];
org1[0] = new Организация();
org1[0].Ид = "1";
Сотрудник[] sotr_array = new Сотрудник[0];
IQueryable<SpecialistsTable> SotrudnikiSet = _dataProvider.GetSpecialists();
int sot = 0;
foreach (var rec2 in SotrudnikiSet)
{
Array.Resize(ref sotr_array, sot + 1);
sotr_array[sot] = new Сотрудник();
sotr_array[sot].Фамилия = rec2.FIO.ToString();
sotr_array[sot].Ид = rec2.Vrach_id.ToString();
sotr_array[sot].Описание = rec2.Special;
sot++;
}
org1[0].Сотрудники = sotr_array;
Organizations.Организация = org1;
return Organizations;
}
Как упоминалось ранее Справочник организаций состоит из одной
организации - Кардиоцентра, поэтому основную функцию, которая
выполняется данным методом – это выгрузка сотрудников. Выгружаемый на
сайт справочник состоит из фамилии, имени и отчества специалиста, которые
хранятся в едином поле .Фамилия, а так же из идентификатора врача, по
которому в последствии будет связаны таблицы расписания и услуг.
Значение поля «Описание» отвечает за должность специалиста.
IQueryable<SpecialistsTable> SotrudnikiSet = _dataProvider.GetSpecialists(); отвечает за выгрузку представления таблицы «Сотрудники» из БД МИС.
Так выглядит передаваемый МИС пакет сотрудников на веб-сайт:
<Сотрудники>
<Сотрудник>
<Фамилия>Овдин М.С.</Фамилия>
<Ид>324</Ид>
<ИдПодразделения> </ИдПодразделения>
< Описание>Врач-кардиолог</Описание >
</Сотрудник>
<Сотрудник>
38
<Фамилия>Петухов В.В.</Фамилия>
<Ид>115</Ид>
<ИдПодразделения> </ИдПодразделения>
< Описание>Врач-терапевт</Описание>
</Сотрудник>
</Сотрудники>
39
Глава 4. Безопасность
Предоставление модели угроз – это необходимое требование для
формирования необходимых условий к обеспечению информационной
безопасности обрабатываемых данных веб-сервисом, а так же для
компонентов, с которыми он взаимодействует, а конкретно локальновычислительная сеть (ЛВС) Тюменского Кардиологического центра.
Документ модели угроз используется для:
проведения анализа защищенности ИСПДн от угроз безопасности ПДн
в процессе исполнения и организации работ по обеспечению
безопасности ПДн;
нейтрализации воздействия на технические средства ИСПДн с целью
предотвращения возможности прекращения их работы;
проведения
комплекса
мероприятий,
способствующих
предотвращению несанкционированного доступа к ПДн и попадание к
лицам, которые не владеют доступом к этим данным;
разработки системы защиты ПДн, которая предполагает уменьшение
рисков по выявленным угрозам с применением способов и методов
защиты ПДн;
обеспечения контроля уровня защищенности ПДн.
Модель угроз разработана с применением следующих нормативных и
методологических документов:
Положение об обеспечении безопасности персональных данных при их
обработке
в информационных
системах
персональных
данных,
утвержденное постановлением Правительства Российской Федерации
от 17 ноября 2007 года №781;
Федеральный закон от 27 июля 2006 года №149-ФЗ «Об информации,
информационных технологиях и о защите информации»;
40
Федеральный закон от 27 июля 2006 года №152-ФЗ «О персональных
данных»[10]
4.1. Модель вероятного нарушителя
информационной безопасности
4.1.1. Описание возможных нарушителей
Все нарушители делятся на две группы по признаку принадлежности к вебсервису:
− внешние злоумышленники – лица, у которых нет прав для
нахождения в пределах контролируемой зоны, на которой размещается
оборудование
веб-сервиса.
В
качестве
внешнего
злоумышленника,
рассматривается нарушитель, не имеющий доступа к ресурсам системы,
находящимся в пределах контролируемой зоны. Он так же не может
использовать технические каналы утечки информации, так как объем
информации,
обрабатываемой
недостаточным
для
с
возможной
помощью
мотивации
веб-сервиса,
внешнего
является
нарушителя
к
осуществлению действий, направленных утечку информации по техническим
каналам утечки.
− внутренние злоумышленники – лица, обладающие привилегиями
пребывания в пределах контролируемой зоны, на которой размещается
оборудование веб-сервиса. Возможности внутреннего злоумышленника
напрямую зависят от его функций и атрибутов доступа в пределах
контролируемой зоны, а так же действующих ограничивающих факторов на
территории организации.
Ниже
приведены
возможные
способы
реализации
угроз
информационной безопасности [11]:
1)
несанкционированный
доступ
к
защищаемым
данным
при
использовании уязвимостей методов разграничения доступа;
41
2) отрицательное влияние на программно-технические составляющие
МИС через веб-сервис в результате заражения компьютерными вирусами и
другим вредоносным программным обеспечением; [11а]
3) взлом административной учетной записи веб-сервиса имеющей
необходимый нарушителю вид доступа, с использованием штатных средств;
4) кража элементов веб-сервера, носителей информации и содержащих
секретную информацию производственных отходов(списанных носителей,
распечаток и тп);
5) получение сведений о аутентификационном доступе с помощью
зрительного несанкционированного просмотра, либо подбора паролей;
6) эксплуатация незаблокированных средств администрирования вебсервера, оставленных без контроля;
7) неисправность программно-технических составляющих веб-сервиса;
8) уничтожение технических и программно-технических составляющих
веб-сервиса, а так же нанесение повреждений компонентам сервиса путем
непосредственного физического воздействия;
9) реализация несанкционированного доступа к информации в момент
ее передачи.
4.2. Перечень основных угроз безопасности
информации
В процессе разработки веб-сервиса, особое внимание уделялось
вопросу безопасности.
По результатам анализа системы обмена данными между МИС и вебсайтом мною была построена модель угроз (приложение Б).
Все угрозы можно разбить на три типа:
Угрозы, связанные с передаваемыми данными между МИС и сайтом
(кража, искажение)[12]
42
Угрозы, приводящие веб-сервис в неработоспособное состояние
(физическое и программное воздействие)
Угрозы, связанные безопасностью МИС и ЛВС ЛПУ, возникающие в
связи с внедрением веб-сервиса.
4.2.1. Угрозы, связанные с передаваемыми
данными между МИС и сайтом, и пути их
минимизации
Для минимизации этого типа угроз, мною было предложено решение
передачи обезличенных данных. Вместо персональных данных между
системами передаются идентификаторы, которые могут представлять собой
номера общих документов (СНИЛС, номер паспорта), либо специальный
номер, получаемый лично каждым пациентом в Кардиоцентре. Таким
образом кража передаваемых данных не представляет интереса для
злоумышленниками.
Согласно
статистике,
зафиксированных
случаев
искажения
передаваемых в мед учреждениях данных Тюменской области за последние
пять лет не выявлено [13], в связи с этим стоит предположить, что
злоумышленнику
будет
экономически
нецелесообразно
выполнять
модификацию данных, передаваемых от веб-сервиса к сайту.
4.2.2. Угрозы, приводящие веб-сервис в
неработоспособное состояние, и пути их
минимизации
Для минимизации угрозы физического вывода из строя веб-сервера, на
котором располагается веб-сервис, предложено расположить веб-сервер в
пределах контролируемой зоны, чтобы исключить доступ посторонних лиц.
Если
рассматривать
угрозы
вывода
из
строя
веб-сервиса
программными средствами, то наиболее актуальной является DDoS-атака.
4.2.2.1.
DDoS— атака. Атака сервера
43
Если рассматривать статистику атак на сетевые объекты, то можно
отметить
тот
факт,
что
в
начале
2000-х
годов
их
совершали
непрофессиональные программисты ради самоутверждения, то в настоящее
время атаки на рабочие станции и на серверы предприятий происходят
целенаправленно с корыстными целями. Сами нападения обуславливается
взломом большого числа рабочих машин, из числа которых выбираются
наименее защищенные, которые и формируют основу для распределенных
сетевых атак отказа обслуживания (DDoS - Distributed Denial of Service) на
рабочие станции компаний [14] нападения на которые заказывают
недоброжелатели-конкуренты.
На графике (Рис 2) отражен рост предельных потоков DDoS-атак.
Рис. 2
Если описать процесс DDoS-атаки, то он будет выглядеть таким
образом:
на рабочую станцию – жертву, в качестве которой чаще всего
выступает сервер организации поступает большое количество ложных
запросов
со
множества
компьютеров
из
сети
Интернет.
В
итоге
задействуются все мощности сервера на обслуживание атакующих запросов,
и он становится недоступным для обычных пользователей.
44
Трехуровневая архитектура, известная под именем - кластер DDoS,
используется нарушителями для проведения DDoS-атак. Она выглядит
следующим образом:
управляющая консоль (возможно
несколько консолей), та машина, которая
является главенствующей и инициирует
сигнал атаки;
Компьютеры-проводники. Компьютеры,
транслирующие сигнал об атаке на
машины-агенты, так называемые агенты"зомби". Количество компьютеров-проводников варьируется в
зависимости от масштабов атаки и может достигать отметку в сотню и
даже в тысячу компьютеров;
Агенты - "зомби".- Компьютеры-исполнители, которые атакуют сервержертву, отправляя атакующие запросы..
Специалистами информационной безопасности принято разграничивать
следующие виды DDoS-атак:
Smurf-атака—Использует три участника для атаки: атакующий,
усиливающая сеть и жертва. Направление ping-запросов ICMP (Internet
Control Message Protocol), в котором адрес отправителя является адресом
жертвы, а получателями являются все пользователи направленной
широковещательной рассылки.
UDP flood — аналог Smurf-атаки, в которой вместо ICMP-запросов
отправляются UDP пакеты (User Datagram Protocol). Данный метод
является одним из самых неопасных из всех видов DDoS-атак. При
обмене данными между компьютерами применяются нешифрованные
протоколы UDP и TCP, поэтому они легко выявляются;
TCP flood — множество TCP-пакетов отправляются на адрес жертвы, что
в свою очередь приводит к недоступности сетевых ресурсов;
45
ICMP flood— атака, аналогичная Smurf, но без использования рассылки.
DDoS-атака может повлечь за собой потерю данных, значительные
финансовые потери, утрату доверия потребителей, которые хотят произвести
запись через интернет.
Для предотвращения или устранения DDoS-атак можно прибегнуть к
нескольким методам решения:
Аппаратное
решение
проблемы:
Маршрутизаторы,
аппаратные
фаерволы от ведущих фирм производителей типа Сisco, 3com, nortel и
тп. Однако стоит отметить стоимость подобного оборудования – к
примеру, средний cisco маршрутизатор (на примере Cisco ASA 5510)
обойдется в среднем около 10 000 долларов.
Программное решение проблемы: система анализа трафика, которая
позволит своевременно узнать о начинающейся атаке и вовремя
принять меры по ее предотвращению;
Резервный веб-сервер, который содержит последнюю рабочую версию
веб-сервиса, вступающий в работу при отказе основного сервера.
Организация второго, административного, сетевого интерфейса, через
который можно получить доступ к серверу в случае забитости
основного канала.
Оптимальным вариантом являются программное решение и наличие
резервного сервера, так как оба эти варианта не являются такими
затратными,
как
аппаратное
решение,
однако
являются
не
менее
эффективными.
4.2.3. Угрозы, связанные безопасностью МИС и
ЛВС ЛПУ, возникающие в связи с
внедрением веб-сервиса, и пути их
минимизации
46
МИС является автономной системой, не имеющей выхода в интернет, и
при использовании веб-сервиса появляется выход наружу, открывается
доступ извне [15]
Для
минимизации
рисков
от
осуществления
данной
угрозы,
предлагается комплексное решение:
Во-первых, создать изолированную подсеть, состоящую из веб-сервера
и БД МИС. (Рис 3)
Рис. 3
Таким образом, даже если злоумышленник как-либо получит доступ к
веб-сервису, он не сможет нанести вред другим компонентам сети. Кроме
того, доступ к таблицам и представлениям в БД МИС будет ограничен ролью
пользователя веб-сервиса, поэтому кроме как считать данные, либо внести
новые, злоумышленник не сможет.
Во-вторых, между веб-сервисом и сайтом необходимо поставить
программный файрвол, на котором следует закрыть все порты, кроме 80, по
которому будут приходить запросы на веб-сервис. (примерная схема
представлена на рис. 4)
47
Рис. 4
Рекомендации по минимизации актуальных угроз переданы в ИТ-отдел
Тюменского кардиологического центра для изучения и применения на
практике.
48
4.3. Обеспечение целостности данных и
пользовательской аутентификации с
помощью подписей XML
Под спецификацией XML подписи подразумевается "Цифровая
подпись XML"[16], разработанная совместными усилиями организаций W3C
и IETF, имеющая статус Рекомендации W3C. Данный документ назначает
правила синтаксиса и обработки, которые запаковывают в XML-формат
данных аутентификации, целостности и пользовательской аутентификации
сообщения.
Данная концепция безопасности еще не реализована в рамках
разрабатываемого веб-сервиса, поэтому статья носит рекомендательный
характер для последующей доработки сервиса.
Допустим, что сайтом вызывается метод «ВыгрузитьРасписание» вебсервиса. Этим методом реализуется выгрузка расписания на сайт за
определенный
период,
причем
если
пользователь
имеет
права
администратора, то он может просматривать расписание с указанными в нем
записанными пациентами, информацию по которым он может просмотреть.
Вызывая метод «ВыгрузитьРасписание», веб-сайт включает в него поля
о целостности и аутентификации пользователя сообщения. После получения
вызова брандмауэру XML сервиса необходимо проверить входящее
сообщение на наличие в нем информации о том, что:
сообщение не изменилось в момент передачи на веб-сервис (проверка
целостности сообщения);
сторона,
отправляющая
запрос
является
администратором
(пользовательская аутентификация).
Если оба эти условия положительны, брандмауэр XML дает
разрешение запрашивающей стороне о переходе к серверу.
Процесс пользовательской аутентификации выглядит следующим
образом:
49
Сайт направляет в веб-сервис запрос вызова метода. Данный
содержит
всю
информацию,
которая
относится
к
запрос
обеспечению
безопасности (аутентификация и пользовательская аутентификация).
Веб-сервис защищен брандмауэром XML, принимающий все запросы,
которые направляются в этот сервер. Брандмауэр XML ведет проверку, на
идентичность полученного сообщения тому, что запрашивающая сторона
намеревалась отправить.
При условии, что целостность сообщения является не нарушенной,
брандмауэр
XML
обрабатывает
идентификационную
информацию
запрашивающей стороны данного запроса и проводит проверку на
обладание этого пользователем статусом администратора.
При
подтверждении
о
том,
что
запрашивающая
сторона
есть
администратор - брандмауэр XML дает разрешение запрашивающей
стороне о переходе к серверу.
Идентификаторы цифровой подписи XML будут включены в заголовок
запроса. Цифровая подпись является гибкой технологией, которая допускает
включение полей-идентификаторов на любую позицию XML-файла.
Три типа существующих XML-подписей:
1. заключающая в конверт (enveloping);
2. заключаемая в конверт (enveloped);
3. обособленная (detached).
XML-подпись оборачивающая данные, которые подлежат подписанию,
называется заключающая в конверт подпись. В свою очередь, когда
информация, подлежащая подписанию, оборачивает эту подпись (для
примера, когда подпись XML делается элементом данных XML, которые
подлежат подписанию), то такая подпись имеет название заключаемой в
конверт. И третий тип - когда данные
и подпись, которые необходимо
подписать, хранятся раздельно - элемент подписи и подписываемый элемент
50
остаются элементами одного уровня – данную подпись свойственно называть
обособленной.
4.3.1. Формирование цифровой подписи XML
На первоначальном этапе создается элемент Signature. Этот элемент
является ключевым, именно он оборачивает все последующие элементы
цифровой подписи XML. В примере представлено объявление пространства
имен цифровой подписи XML и заголовка SOAP.
<?xml version=”1.0”?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:ds=”http://www.w3.org/2000/09/xmldsig#”>
<SOAP-ENV:Header>
<ds:Signature>
<ds:SignedInfo>
</ds:SignedInfo>
<ds:SignatureValue>
</ds:SignatureValue>
<ds:KeyInfo>
</ds:KeyInfo>
</ds:Signature>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<s:GetScheduleTable
xmlns:s=“http://www.Websitename.com/schedule/”>
<!--Parameters passed with the method call-->
</s: GetScheduleTable>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Теперь подробнее рассмотрим дочерние звенья элемента Signature SignedInfo, SignatureValue и KeyInfo. Signature – это единственный элемент,
который включает в себя другие теги цифровой подписи XML.
Последующим действием является создание таких дочерних элементов.
Законченный компонент SignedInfo показывает то, как создается подпись
XML. ЭлементSignedInfo содержит несколько потомков, которые в свою
очередь имеют несколько бит информации, необходимой для подписи XML.
<SOAP-ENV:Header>
<ds:Signature>
51
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#GetScheduleTable">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transforms>
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>
BIUddkjKKo2...
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
</ds:SignatureValue>
<ds:KeyInfo>
</ds:KeyInfo>
</ds:Signature>
</SOAP-ENV:Header>
CanonicalizationMethod-
это
обязательная
компонента,
которая
идентифицирует алгоритм канонизации, генерация двоичных потоков для
логически эквивалентных данных XML, применимая к узлу SignedInfo до
создания подписи.
Элементу CanonicalizationMethodв принадлежит атрибут Algorithm,
который содержит в себе строку URI (http://www.w3.org/2001/10/xml-excc14n#). Данная строчка URI идентифицирует алгоритм, который описан в
спецификации W3C - "Исключительная канонизация XML" (Exclusive XML
Canonicalization).
На первоначальном этапе создается элемент CanonicalizationMethod.
Алгоритм канонизации не используется до тех пор, пока не сформируются
все его потомки, после чего он применится к узлу SignedInfo.
Следующим
потомком
элемента
SignedInfo
является
узел
SignatureMethod, поле Algorithm которого называет алгоритм, который
используется для создания криптографической подписи.
Элемент Reference – это третий потомок узла SignedInfo. SignedInfo
элемент должен иметь по крайней мере один элемент Reference.
52
Данный элемент используется для хранения информации, включающая
в себя:
Указание данных, подлежащие подписанию.
Используемый для создания дайджеста алгоритм.
Значение дайджеста.
После формирования дочерних элементов и самого узла SignedInfo
нужно
канонизировать
весь
элемент
SignedInfo
по
алгоритму,
соответствующему данному узлу. После данной операции необходимо
использовать значение дайджеста для его оборачивания в элемент
SignatureValue
Каноническая
форма
элемента
SignedInfo
используется
период
подписания в качестве данных, которые подлежат подписанию. Все дочерние
элементы элемента SignedInfo входят в эту каноническую форму.
Элемент Signature имеет еще один дочерний узел с именем KeyInfo.
Поэтому следующим шагом является создание его потомков. Дочерний
элемент KeyName содержится в узле KeyInfo. Данный элемент KeyName
является идентификатором ключа, использующийся для проверки подписи.
Данный алгоритм является примером применения спецификации
"Цифровая подпись XML. В результате получаем полное SOAP-сообщение, в
заголовке которого содержатся данные о пользовательской аутентификации
и целостности сообщения.
4.3.2. Проверка цифровой подписи XML
Проверка цифровой подписи представляет из себя три этапа:
1. Канонизация элемента SignedInfo;
53
2. Контроль целостности сообщения, для чего нужно проверить
дайджест, находящийся в узле Reference. Когда происходит проверка
дайджеста необходимо обладать информацией, которая включает в
себя:
a) Данные дайджеста, по которым идет его построение.
Нужно раскрыть атрибут Reference элемента для получения таких
данных;
b) Алгоритм, который использует дайджест. Эту информацию
хранит в себя атрибут Algorithm элемента DigestMethod. После
применения этого дайджеста нужно сравнить значение дайджеста с
содержанием элемента DigestValue;
c) Модификации, которые применимы к информации до
старта алгоритма профиля. Данные по этому вопросу содержатся в
узле Transforms. Стоит отметить, что перед получением дайджеста
данных, необходимо применить к ним эти же модификации. Если
результат проверки дайджеста становится отрицательным, то
проверка
прекращается
и
рассматривается
как
неудовлетворительная.
3. Проверка подписи. Открытый или общий секретный ключ
подписавшей стороны используется для данной проверки. Элемента
KeyInfo содержит информацию при его существовании. При
нахождении ключа, который применяется для проверки подписи,
необходимо определить подписной метод, применявшийся при
создании подписи. Он лежит в атрибуте Algorithm элемента
SignatureMethod. После этих действий нужно применить
каноническую форму SignedInfo и ключ для подтверждения величины
подписи.
54
Для генерации подписанных SOAP-сообщений в спецификации
"Цифровая подпись XML" можно использовать созданные SOAP-заголовки.
Имеющийся на стороне получателя файрвол XML перерабатывает текущий
SOAP заголовок перед тем, как отправить запрос на сервер, чтобы проверить
подпись.
4.3.3. Шифрование XML
Спецификация
конфиденциальности
шифрования
XML
XML-сообщений.
проходит
Данная
по
требованиям
спецификация
дает
возможность шифровать XML-файл целиком.
Шифрование целого XML-файла
Примером зашифрованного файла является следующий код:
Структура зашифрованного файла идентична исходному XMLдокументу за исключением значения, которая находится в узле CipherValue в
зашифрованном виде.
Алгоритм, применяемый в процессе шифрования, содержится в
корневом узле EncryptedData, так же как и другая зашифрованная
информации:
“http://www.w3.org/2001/04/xmlenc#”
–
объявление
пространства имен шифрования XML и атрибут MimeType. По нему
получатель различает зашифрованный файл от незашифрованного и при
значении этого узла равному “text/xml” –пользователю необходимо создать
структуру EncryptedData.
55
EncryptionMethod является потомком корневого элемента. Он включает
в себя атрибут Algorithm, описывающий метод шифрования. Значение
http://www.w3.org/2001/04/xmlenc#3des-cbc подразумевает алгоритм тройной
DES (Data Encryption Standard, Стандарт шифрования данных)
Элемент
KeyInfo
тот,
что
использовался
при
применении
спецификации "Цифровая подпись XML"..
CipherData является элементом EncryptedData, который содержит
элемент CipherValue с зашифрованным содержанием. Поэтому результат
шифрования XML-файла это значение поля CipherValue.
4.3.4. Обработка шифрования XML
Для получателя зашифрованного XML-файла нужно выполнить
следующие действия для расшифрования:
1. Извлечь зашифрованное значение элемента CypherValue;
2. Прочитать содержание узла EncryptionMethod;
3. Получить данные атрибута Type из EncryptedData;
4. Через KeyInfo считать информацию о ключе шифрования;
5. Расшифровать документ.
Для применения цифровой подписи XML и шифрования XML
необходимо изучить спецификацию консорциума OASIS "Безопасность вебсервисов", в которой имеется описание применении данных технологий при
обмене
SOAP-сообщениями.
Стандарт
"Безопасность
веб-сервисов"
принимает низкоуровневые элементы из приведенных выше спецификаций и
определяет синтаксис высокого уровня для оборачивания информации о
безопасности в SOAP-сообщениях.
56
ЗАКЛЮЧЕНИЕ
В ходе выполнения данной работы был разработан веб-сервис,
обеспечивающий взаимодействие систем Тюменского Кардиологического
центра и 1C.Bitrix «Сайт медицинской организации»
Данный веб-сервис предоставляет возможность подачи и обработки
записи через веб-сайт, а так же синхронизацию справочников услуг,
специалистов и расписания.
Сервис
так
же
осуществляет
возможность
выгрузки
только
изменившихся данных из МИС на сайт, что позволяет существенно снизить
трафик передаваемой информации.
При разработке веб-сервиса были проанализированы 2 существующие
системы, которые требовали синхронизации, а так же возможные методы их
взаимодействия. В результате была разработана
концепция, которая
удовлетворяет всем требованиям двух систем. Реализованный алгоритм
работы сервиса обеспечивает стабильную работу выгрузки необходимой
информации из одной системы в другую.
При проектировании работы сервиса были проработаны вопросы
безопасности, при которых были исключены и минимизированы риски
реализации угроз, связанных с кражей, уничтожением либо подменной
конфиденциальной информации.
По результатам разработки сервиса учреждению были предложены
варианты по минимизации угроз, появившихся в МИС из-за внедрения в нее
веб-сервиса.
В данный момент веб-сервис проходит тестирование Тюменским
Кардиоцентром.
предложения
по
От
представителей
усовершенствованию
этой
организации
процесса
работы
поступают
сервиса.
В
дальнейшем кроме технической поддержки проекта планируется проведение
анализа эффективности работы разработанного веб-сервиса с целью его
улучшения.
57
Список использованной литературы
1) Концепция
развития
здравоохранения
до
2020
года
-
URL:
http://www.zdravo2020.ru/concept Дата обращения: 20.05.2013
2) В. А. Филиппов Информационные взаимодействия и Web-сервисы. Ленанд - ISBN 978-5-9710-0292-5; 2009 г. – 144 c.
3) Официальный сайт World Wide веб Consortium - http://www.w3.org Дата
обращения: 20.05.2013
4) Текущая
спецификация
WSDL
-
http://www.w3.org/tr/wsdl
Дата
обращения: 20.05.2013
5) Стандарт HL7. [Электронный ресурс] / Справочно-информационный
интернет-портал www.hl7-russia.org/ 2013 - Режим доступа: http://www.hl7russia.org/, свободный. — Загл. с экрана. Дата обращения: 20.05.2013
6) Cтандарт MedML [Электронный ресурс] / Справочно-информационный
интернет-портал medml.ru,
2011.
—
Режим доступа: http://medml.ru/,
свободный. — Загл. с экрана. Дата обращения: 20.05.2013
7) “1С-Битрикс Сайт медицинской организации 12.0” [Электронный ресурс] /
Справочно-информационный интернет-портал 1c-bitrix.ru, 2001-2013. —
Режим доступа: http://www.1c-bitrix.ru/solutions/med/med.php, свободный.
— Загл. с экрана. Дата обращения: 20.05.2013
8) Дж. Грофф, П. Вайнберг SQL: Полное руководство: Пер. с англ. – 2-е изд.,
перераб. и доп. – К.: Издательская группа BHV, 2001. – 816 с.: ил
9) ЭспозитоД. MicrosoftASP.NET 2.0. Базовый курс. Мастер-класс / Пер. с
англ. – М.: Издательство «Русская Редакция»; СПб.: Питер, 2007. – 688 с.:
ил.
a) ЭспозитоД. MicrosoftASP.NET 2.0. Углубленное изучение / Пер. с англ.
– М.: Издательство «Русская Редакция»; СПб.: Питер, 2008. – 592 с.: ил.
10)
О персональных данных: Федеральный закон Российской Федерации от
27 июля 2006 г. N 152// URL: http://www.rg.ru/2006/07/29/personaljnyedannye-dok.html Дата обращения: 20.05.2013
58
11)
А. А. Захаров, Е. А. Оленников, А.В. Широких, А. М. Воробьев. О
некоторых подходах к информационной защите электронной очереди
ЛПУ. Вестник УрФО “Безопасность в информационной сфере” № 1(3) /
2012 г.
a) Воробьев
А.М.
Использование
интернет-технологий
с
целью
завладения персональными данными пользователя – БЕЗОПАСНОСТЬ
ИНФОРМАЦИОННОГО ПРОСТРАНСТВА: сборник статей. Тюмень:
Издательство Тюменского государственного университета, 2012. 412 с.
12)
Защита персональных данных: проблемы и решения / В.Коржов //
URL: www.osp.ru. - 2009. Дата обращения: 20.05.2013
13)
Электронный ресурс] / Справочно-информационный интернет-портал
iris72.ru, 2013 - Режим доступа: http://www.iris72.ru, свободный. — Загл. с
экрана. Дата обращения: 20.05.2013
14)
Крис Касперски Компьютерные вирусы изнутри и снаружи. — Питер.
— СПб.: Питер, 2006.— С. 527.
15)
«ВЕБ-сервер глазами хакера», Фленов, «БХВ-Петербург», 2007
16)
“Практическое руководство. Шифрование XML” [Электронный ресурс]
/ Справочно-информационный интернет-портал msdn.ru, 2013. — Режим
доступа: http://msdn.microsoft.com/ru-ru/library/ms229746.aspx, свободный.
— Загл. с экрана. Дата обращения: 20.05.2013
59
Приложение А. Описание взаимодействия
участников обмена в формате MedML
Участники обмена
Название
Краткая характеристика
Участникотправитель
Медицинская информационная система или система управления
сайтом, обеспечивающая возможность подготовки документов и
каталогов в электронном виде.
Участникполучатель
Медицинская информационная система или система управления
сайтом, обеспечивающая возможность приема и обработки
документов и каталогов в электронном виде.
Электронные документы
Название
Назначение
Комментарии
Каталог Услуг
Содержит
информацию о
услугах
Каталог должен иметь уникальный
идентификатор, название и содержать
информацию о владельце. Минимально
необходимой информацией о медицинской
услуге в каталоге должна быть следующая:
идентификатор услуги в каталоге,
наименование услуги. Для классификации
услуг используются группы. Если
однозначная классификация вызывает
затруднения, то разрешается включать услуги
сразу в несколько групп. Для каждой услуги
можно указать дополнительные свойства и
реквизиты (длительность выполнения услуги,
необходимая подготовка, общая информация
об услуге и т.д.).
КлассификаторУслуг
Устанавливает
правила, по
которым должны
быть описаны
услуги.
Каждый классификатор должен иметь
уникальный идентификатор, наименование и
владельца. В классификаторе определяются
свойства услуг, группы (категории) услуг и
типы цен, по которым можно формировать
прейскуранты услуг по различным
источникам финансирования. В
классификаторе, свойства могут быть
60
объявлены для каталога или/и группы. Если
свойства объявлены для каталога, то они
распространяются на все услуги в каталоге,
если свойства объявлены для группы, то
значения этих свойств устанавливаются
только для услуг группы. Для составления
собственного классификатора нужно:
составить список свойств услуг, по которым
будет производиться классификация,
составить иерархический список групп,
определить типы цен, по которым можно (или
нужно) формировать прейскуранты услуг.
Классификатор тесно увязан с каталогом – в
каталог «помещается» услуга, в
классификаторе содержится «структура»
каталога и правила описания услуг. Если
считается, что в каталоге минимальной
информации о услуге (наименование,
идентификатор) достаточно, то
классификатор указывать не нужно, но если
для услуги в каталоге указаны значения
свойств и идентификаторы групп (услуга
отнесена к определенной категории), то
нужно указать классификатор, в котором эти
свойства и группы описаны.
Организации
Содержит
информацию о
медицинских
организациях,
публикующих
информацию на
сайте
Каталог должен иметь уникальный
идентификатор, название и содержать
информацию о владельце. Каталог содержит
информация о реквизитах юридического лица
организаций, информацию о структурных
подразделениях медицинских организаций,
сотрудниках и помещениях.
Минимально необходимой информацией о
сотруднике в каталоге должна быть
следующая: реквизиты физического лица фамилия, имя, отчество, а также должность
сотрудника у контрагента. Для каждого
сотрудника можно указать дополнительные
свойства и реквизиты (научные степени и
звания, информацию об обучении и курсах
повышения квалификации и т.д.).
Минимально необходимой информацией о
помещении в каталоге должна быть
следующая: идентификатор помещения в
каталоге и наименование помещения.
Документ
Передается
информация,
необходимая для
формирования
Для отправителя и получателя ЭД –
указанные операции представляются разными
документами. Документ «Заказ услуг»
предназначен для организации записи на
61
документов,
сопровождающих
наиболее
распространенные
операции:
заказ услуг;
счет на оплату.
прием к специалисту. С помощью документа
можно организовать два способа самозаписи
на амбулаторно-поликлинический прием:
1. пациент указывает специалиста (по
специальности или
ФИО+специальность), дату и интервала
времени в который готов прийти на
прием – утром (до обеда), днем (после
обеда), вечером (после 18 часов), или
весь день, свои контактные данные.
После получения заявки представители
медицинской организации связываются с
пациентом и записывают на конкретное
время и кабинет (выделяют талон в
медицинской информационной системе);
2. пациент указывает специалиста (по
специальности или
ФИО+специальность), дату на которую
готов прийти на прием, пациенту
предлагается список из талонов
(свободных и занятых) среди которых
пациент выбирает свободный талон, свои
контактные данные. После получения
заявки представители медицинской
организации связываются с пациентом и
подтверждают факт записи пациента на
прием. Если факт записи не
подтверждается, то талон освобождается.
На одном сайте для ведения записи в разные
медицинские кабинеты могут использоваться
различные способы самозаписи на прием.
Например, к терапевту пациент может сам
себе выбирать талоны (вариант 2), а на
компьютерную томографию талон выдается
сотрудником медицинской организации
(вариант 1).
ПакетПредложений
Предложения
медицинских
услуг с указанием
цен (прайс-лист
или прейскурант
услуг).
Предложение практически совпадает с одной
строкой "обычного" прейскуранта
медицинских услуг. Предлагается
медицинская услуга по определенной цене.
Предложения группируются в пакет
предложений (например, прейскурант), в
котором задается общая часть. Пакет
предложений может описывать услуги, на
которые можно осуществлять запись
пациентов на прием через интернет. Также
пакет может описывать прейскурант платных
медицинских услуг.
Расписание
Информация о
Расписание содержит набор записей, в
62
расписании
работы
помещений и
сотрудников в
организации.
Может включать
информацию о
доступном
времени для
записи пациента
на прием
(планирование
услуги).
каждой из которых указывается помещение,
сотрудник и список непрерывных периодов
работы данного сотрудника в данном
помещении. Непрерывный период имеет
время начала и время окончания. Период
может содержать данные об объеме времени,
которое доступно для заказа услуг в данном
периоде. Размер периода может
варьироваться от 5 минут до 24 часов, в
зависимости от необходимой точности
планирования.
Сайт может запросить не все расписание
целиком, а только изменения, произошедшие
с указанного времени. В этом случае
медицинская информационная система
должна вернуть только необходимый для
обновления объем информации.
Бизнес-транзакции
Название
Назначение
Условия и периодичность
Направление
каталога (услуг,
организаций)
Отправка каталога для
публикации на сайте.
Применяются различные
способы доставки,
например, по ftp, ws-ссылки
или иной способ.
При публикации данных на сайте.
Согласно установленного
регламента между медицинской
информационной системой и
сайтом.
Направление
коммерческих
предложений
Отправка коммерческих
предложений для
публикации на сайте.
Применяются различные
способы доставки,
например, по ftp, ws-ссылки
или иной способ.
При публикации прейскурантов
(прайс-листов). Согласно
установленного регламента между
медицинской информационной
системой и сайтом.
Получение
классификатора
Получение медицинской
информационной системой
классификатора для
составления каталога услуг
или/и коммерческих
предложений. Применяются
различные способы
доставки, например, по ftp,
ws-ссылки или иной способ.
По необходимости составить
каталог или прайс-лист в
соответствии с каким-либо
классификатором (например,
отраслевым классификатором
медицинских услуг или
классификатором сайта).
Направление
документов
Отправка ЭД для
дальнейшей их обработки
При выполнении определенных
действий пользователем сайта 63
Направление
информации о
расписании работы
организаций
медицинской
информационной системой.
выполнение самозаписи, запрос
счета на оплату медицинских
услуг, на которые осуществлена
запись.
Отправка каталога для
публикации на сайте.
Применяются различные
способы доставки,
например, по ftp, ws-ссылки
или иной способ.
При публикации данных на сайте, а
так при обновлении данных о
расписании. Согласно
установленного регламента между
медицинской информационной
системой и сайтом.
64
Приложение Б. Модель угроз
Наименован
ие угрозы
Вероят Возможнос Опаснос Актуальн
Меры по
ность
ть
ть
ость
противодействию угрозе
реализ реализации угрозы
угрозы
Технические Организа
ации
угрозы (Y)
ционные
угрозы
(Y2)
Угрозы несанкционированного доступа к информации
Угрозы уничтожения, хищения аппаратных средств ИСПДн носителей
информации путем физического доступа к элементам ИСПДн
Вывод из
Низкая Низкая
Средняя Неактуаль Охранная
Пропускн
строя узлов
ная
сигнализация ой режим
ПЭВМ,
Решетки на
Охрана
каналов
окна
связи
Металлическа
я дверь
Кодовый
замок
Несанкцион Средня Средняя
Средняя Неактуаль Система
Ремонт в
ированный
я
ная
защиты от
организац
доступ к
НСД
ия
информации
Шифрование имеющих
при
данных
лицензию
техническом
на защиту
обслуживан
информац
ии (ремонте,
ии
уничтожени
Акт
и) узлов
установки
ПЭВМ
средств
защиты
Несанкцион Низкая Средняя
Низкая
Неактуаль Настройка
Инструкц
ированное
ная
средств
ия
отключение
защиты
админист
средств
ратора
защиты
безопасно
сти
Технолог
ический
процесс
обработк
и
Акт
установки
средств
защиты
Угрозы хищения, несанкционированной модификации или блокирования
информации за счет несанкционированного доступа (НСД) с применением
программно-аппаратных и программных средств (в том числе программноматематических воздействий);
65
Компьютерн
ые вирусы
Средня
я
Средняя
Высокая Неактуаль Антивирусное Инструкц
ная
ПО
ия
пользоват
еля
Инструкц
ия
ответстве
нного
Инструкц
ия
админист
ратора
безопасно
сти
Технолог
ический
процесс
обработк
и
Инструкц
ия по
антивирус
ной
защите
Акт
установки
средств
защиты
Высокая Неактуаль
Сертифик
ная
ация
Недеклариро Низкая
ванные
возможност
и
системного
ПО и ПО
для
обработки
персональны
х данных
Установка
Средня
ПО не
я
связанного с
исполнение
м
служебных
обязанносте
й
Низкая
Средняя
Высокая Неактуаль Настройка
ная
средств
защиты
Инструкц
ия
пользоват
еля
Инструкц
ия
ответстве
нного
Наличие
аппаратных
закладок в
приобретаем
ых ПЭВМ
Низкая
Высокая Неактуаль
ная
Сертифик
ация
Низкая
66
Внедрение
аппаратных
закладок
посторонни
ми лицами
после начала
эксплуатаци
и ИСПДн
Внедрение
аппаратных
закладок
сотрудникам
и
организации
Ddos-атака
Средня
я
Низкая
Высокая Неактуаль Защита
ная
помещения
Опломби
рование
Средня
я
Средняя
Высокая Неактуаль
ная
Опломби
рование
Средня
я
Средняя
Средняя
Актуальн
ая
Программные
блокираторы
трафика
Использо
вание
аппаратн
ых
анализато
ров
трафика
Угрозы не преднамеренных действий пользователей и нарушений безопасности
функционирования ИСПДн и СЗПДн в ее составе из-за сбоев в программном
обеспечении, а также от угроз неатропогенного (сбоев аппаратуры из-за
ненадежности элементов, сбоев электропитания) и стихийного (ударов молний,
пожаров, наводнений и т.п.) характера.
Утрата
Низкая Низкая
Низкая
Неактуль
Инструкц
ключей
ная
ия
доступа
пользоват
еля
Инструкц
ия
админист
ратора
безопасно
сти
Выход из
Средня Средняя
Средняя Неактуль
Резервиро
строя
я
ная
вание
аппаратноданных;
программны
настройка
х средств
вспомогат
ельного
сервера
Сбой
Низкая Средняя
Средняя Неактуаль Использовани Резервное
системы
ная
е источника
копирова
электроснаб
бесперебойно ние
жения
го
электропитан
ия
Угрозы несанкционированного доступа по каналам связи
Несанкцион Высока Высокая
Высокая Актуальн Межсетевой
Инструкц
67
ированный
доступ через
сети
международ
ного обмена
к ЛВС
организации
я
а
экран
ия
пользоват
еля
Инструкц
ия
админист
ратора
безопасно
сти
Акт
установки
средств
защиты
Организа
ция
выделенн
ой сети
для вебсервиса и
БД МИС
Угрозы перехвата при передаче по проводным (кабельным) линиям связи
Перехват за Низкая Низкая
Низкая
Неактуал Шифрование Технолог
переделами
ьная
ический
с
процесс
контролируе
мой зоны
68