Худышкин

РОССИЙСКАЯ ФЕДЕРАЦИЯ
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ
ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
ИНСТИТУТ МАТЕМАТИКИ И КОМПЬЮТЕРНЫХ НАУК
КАФЕДРА ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ
Допустить к защите в ГАК
Заведующий кафедрой
информационной безопасности
д.т.н. профессор
А.А. Захаров
(подпись)
«___» ________20__ г.
Худышкин Семен Игоревич
Автоматизация процесса подачи и обработки заявок в удостоверяющий центр
(Выпускная квалификационная работа)
Научный руководитель:
доцент, к.т.н.
/Е.А. Оленников/
(подпись)
Автор работы:
/С.И. Худышкин/
(подпись)
Тюмень – 2014
Оглавление
Введение ................................................................................................................... 3
Глава 1. ПОЛОЖЕНИЯ, регулирующие работу удостоверяющего центра.
обзор технологий используемых при разработке АС и угроз возникаемых при
их использовании .................................................................................................... 6
1.1. Нормативная база для работы удостоверяющего центра ....................... 6
1.2. Обзор
технологий,
используемых
для
разработки
системы
автоматизации .................................................................................................... 12
1.3. Методы обеспечения безопасности информационных систем............ 21
Глава 2. Разработка автоматизированной системы обработки заявок в УЦ... 32
2.1. Анализ процесса обработки заявок на выдачу сертификата с целью его
автоматизации .................................................................................................... 32
2.2. Проектирование общей структуры подсистемы ................................... 35
2.3. Интеграция с Microsoft Dynamic CRM 2011 .......................................... 38
2.4. Проектирование Web- интерфейса ......................................................... 40
2.5. Служба оповещения клиентов ................................................................ 42
2.6. Использование очередей MSMQ ............................................................ 43
2.7. Использование Контур-Фокус API ......................................................... 44
2.8. Хранение информации о банках ............................................................. 45
Глава 3. Обеспечение безопасности автоматизированной системы обработки
заявОК УЦ.............................................................................................................. 46
Построение модели угроз .................................. Error! Bookmark not defined.
Перечень актуальных угроз и меры по обеспечению безопасности системы
.............................................................................................................................. 48
Заключение ............................................................................................................ 50
Список литературы ............................................................................................... 52
3
ВВЕДЕНИЕ
Актуальность темы дипломной работы обусловлена развитием
электронного документооборота, а также повсеместным использованием
электронной цифровой подписи (ЭЦП) позволяющей сдавать отчетность в
государственные органы, а также участвовать в тендерах через Интернет.
Любое предприятие, получившее ЭЦП может отправить документы через
Интернет в такие органы:
 Пенсионный фонд;
 Федеральная Налоговая Служба;
 Фонд Социального Страхования;
 Росстат.
В такой ситуации на передний план выходит качество предоставляемых
услуг удостоверяющих центров (УЦ).
Удостоверяющий центр ООО «Сибтел-Крипто» стремится улучшить
работу
с
клиентами
и
ведет
разработки
в
сфере
электронного
документооборота. На данный момент, работа с клиентами ведется
менеджерами УЦ. Для получение ЭЦП (либо другой услуги) клиент должен
лично прийти в офис УЦ, либо отправить заявление на электронную почту УЦ.
После этого менеджер осуществляет обработку заявления. Это процедура
может занимать много времени т.к. клиент может указать неправильные
данные.
В период отчетности число клиентов резко возрастает, и менеджеры не
справляются с нагрузкой, однако в меж отчетный период поток клиентов
умеренный, и менеджеры УЦ успевают обработать все заявки. Увеличение
штата менеджеров может решить данную проблему, но также увеличит
финансовые расходы компании, кроме того в меж отчетный период
менеджеры не будут иметь должную нагрузку.
4
После анализа проблемы я пришел к выводу, что нужна автоматизация
процесса обработки заявок от клиентов, благодаря которой клиенты смогут
через интернет в полуавтоматическом режиме сформировать заявку на какуюлибо услугу. Такой подход позволит снизить нагрузку на менеджеров УЦ.
Степень разработанности проблемы.
В области автоматизации работы
удостоверяющих центров успешно ведет компания ЗАО «ПФ «СКБ Контур».
Ее продукты успешно применяются при работе удостоверяющего центра ООО
«Сибтел-Крипто».
Основным недостатком, устранение которого и послужила целью данной
дипломной работы, это необходимость автоматизации обработки заявлений от
клиентов. Решения данной проблемы нет в продуктах компании «СКБКонтур».
Цель дипломной работы состоит в автоматизации и защите процесса
обработки и подачи заявок в удостоверяющий центр ООО «Сибтел-Крипто»
на оказание услуг электронной отчетности.
Поставленная цель обуславливает следующие задачи:
 анализ процесса обработки заявок с целью его автоматизации;
 разработка системы автоматизации процесса обработки заявок в УЦ;
 обеспечение безопасности системы автоматизации УЦ.
Объектом
исследования
выступает
процесс
взаимодействия
удостоверяющего центра с клиентом.
Предметом
исследования
в
дипломной
работе
являются
инструментальные методы для автоматизации и упрощения процесса
взаимодействия УЦ с клиентом.
Методологической и теоретической основой дипломной работы явились
труды зарубежных специалистов в области разработки информационных
систем и автоматизации процессов. В ходе работы над дипломной работой
использовалась
информация,
отражающая
содержание
законов,
5
законодательных актов и нормативных актов, постановлений Правительства
Российской Федерации, регулирующих работу удостоверяющих центров и
защиту информации.
Теоретическая значимость дипломного исследования состоит в
развитии
и
совершенствовании
методов
автоматизации
процессов
взаимодействия между клиентом и удостоверяющим центром.
Практическая значимость работы определяется тем, что ее
результаты
позволяют
повысить
качество
предоставляемых
услуг
удостоверяющим центром, а также упростит использование электронной
отчетности в государственные органы.
Новизна дипломной работы заключается в автоматизации процесса
подачи заявлений клиентов в удостоверяющий центр.
Наиболее существенные результаты, полученные в процессе
разработки, состоят в следующем:
 оптимизация бизнес процессов удостоверяющего центра;
 автоматизирован процесс оповещения клиентов о необходимости
продления услуги;
 автоматизирован процесс проверки данных клиента;
 автоматизирован процесс выставления счета клиенту.
6
ГЛАВА 1. ПОЛОЖЕНИЯ, РЕГУЛИРУЮЩИЕ РАБОТУ
УДОСТОВЕРЯЮЩЕГО ЦЕНТРА. ОБЗОР ТЕХНОЛОГИЙ
ИСПОЛЬЗУЕМЫХ ПРИ РАЗРАБОТКЕ АС И УГРОЗ
ВОЗНИКАЕМЫХ ПРИ ИХ ИСПОЛЬЗОВАНИИ
1.1.
Нормативная база для работы удостоверяющего центра
Электронная цифровая подпись
Электронная цифровая подпись (ЭЦП) – информация в электронной
форме, которая присоединена к другой информации в электронной форме
(подписываемой
информации)
или
иным
образом
связана
с
такой
информацией и которая используется для определения лица, подписывающего
информацию [1].
Применение ЭЦП
Электронная цифровая подпись предназначена для определения лица,
подписавшего электронный документ. Также является полноценной заменой
собственноручной подписи в случаях, предусмотренных законом.
Использование электронной подписи позволяет осуществить:

Контроль целостности документа. При модификации или повреждении
документа подпись станет недействительной.

Защиту от подделки документа. Контроль целостности позволяет
выявить недостоверность документа, таким образом подделывание
становится невозможным в большинстве случаев.

Невозможность отказа от авторства. Применение закрытого ключа
ЭЦП гарантирует невозможность отказа от уже совершенных действий
того, кто подписал документы. Так если происходит идентификация
владельца сертификата ключа, а автор подписи не может от неё
отказаться.
7

Доказательное подтверждение авторства документа. Применение
закрытого ключа ЭЦП гарантирует невозможность отказа от уже
совершенных действий того, кто подписал документы. Так если
происходит идентификация владельца сертификата ключа, а автор
подписи не может от неё отказаться.
Виды ЭЦП предусмотренные законом РФ
Простая электронная подпись
Подпись, которая посредством использования кодов, паролей или иных
средств подтверждает факт формирования электронной подписи
определенным лицом [1].
Неквалифицированная электронная подпись
Подпись, которая [1]:
1. получена в результате криптографических методов преобразования
информации с использованием ключа электронной подписи;
2. позволяет определить лицо, подписавшее электронный документ;
3. позволяет обнаружить факт внесения изменений в электронный
документ после момента его подписания;
4. создается с использованием средств электронной подписи.
Квалифицированная электронная подпись
Подпись, которая соответствует всем признакам неквалифицированной
электронной подписи и следующим дополнительным признакам [1]:
1. ключ проверки электронной подписи указан в квалифицированном
сертификате;
2. для создания и проверки электронной подписи используются средства
электронной подписи, получившие подтверждение соответствия
требованиям, установленным в соответствии с настоящим
Федеральным законом.
8
Стандарты
ГОСТ Р 34.10-2012 - стандарт определяет схему электронной цифровой
подписи (ЭЦП), процессы формирования и проверки цифровой подписи под
заданным сообщением (документом), передаваемым по незащищенным
телекоммуникационным каналам общего пользования в системах обработки
информации различного назначения [2].
Внедрение цифровой подписи на основе настоящего стандарта
повышает, по сравнению с ранее действовавшей схемой цифровой подписи,
уровень защищенности передаваемых сообщений от подделок и искажений
[2].
Криптографическая стойкость данной схемы цифровой подписи
основывается на сложности решения задачи дискретного логарифмирования в
группе точек эллиптической кривой, а также на стойкости используемой хэшфункции. Алгоритмы вычисления хэш–функции установлены в ГОСТ Р 34.112012 [2].
ГОСТ Р 34.11-2012 - российский криптографический стандарт,
«определяет алгоритм и процедуру вычисления хэш-функции для любой
последовательности
двоичных
символов,
которые
применяются
в
криптографических методах обработки и защиты информации, в том числе для
реализации процедур обеспечения целостности, аутентичности, электронной
цифровой подписи (ЭЦП) при передаче, обработке и хранении информации в
автоматизированных системах» [3].
Регулирование работы УЦ
Удостоверяющий центр - юридическое лицо или индивидуальный
предприниматель, осуществляющие функции по созданию и выдаче
сертификатов ключей проверки электронных подписей [1].
Основные документы, регулирующие работу удостоверяющего центра:
9
 Федеральный закон от 06.04.2011 N 63-ФЗ (ред. от 02.07.2013) «Об
электронной подписи» (с изм. и доп., вступающими в силу с
01.09.2013);
 Приказ ФСБ РФ от 27.12.2011 N 795 «Об утверждении Требований
к форме квалифицированного сертификата ключа проверки
электронной подписи»;
 Приказ ФСБ РФ от 27.12.2011 N 796 «Об утверждении Требований
к средствам электронной подписи и Требований к средствам
удостоверяющего центра».
Удостоверяющий центр получает статус аккредитованный после признания
уполномоченным федеральным органом соответствия удостоверяющего
центра требованиям закона «Об электронной подписи». Аккредитацию
проводит Минкомсвязь России.
Закон «Об электронной подписи»
Данный закон регулирует отношения в области использования
электронных подписей при совершении гражданско-правовых сделок,
оказании
государственных
и
муниципальных
услуг,
исполнении
государственных и муниципальных функций, при совершении иных
юридически значимых действий, в том числе в случаях, установленных
другими федеральными законами [1].
Данный закон устанавливает [1]:
 требования к удостоверяющим центрам (на основании проводится
аккредитация);
 виды электронных подписей;
 полномочия федеральных органов исполнительной власти в сфере
использования электронной подписи;
 полномочия и обязанности удостоверяющего центра;
 порядок аккредитации удостоверяющего центра.
10
Приказ
ФСБ
РФ
«Об
квалифицированного
утверждении
сертификата
Требований
ключа
проверки
к
форме
электронной
подписи»
Данный приказ устанавливает какую информацию должен содержать
квалифицированный сертификат.
Сертификат должен содержать [4]:
 уникальный номер квалифицированного сертификата;
 даты начала и окончания действия квалифицированного сертификата;
 фамилия, имя и отчество (если имеется) владельца квалифицированного
сертификата - для физического лица, либо наименование и место
нахождения
владельца
юридического
лица,
квалифицированного
а
также
в
сертификата
случаях,
-
для
предусмотренных
Федеральным законом «Об Электронной Подписи», фамилия, имя и
отчество (если имеется) физического лица, действующего от имени
владельца квалифицированного сертификата - юридического лица на
основании
учредительных
документов
юридического
лица
или
доверенности (далее - уполномоченный представитель юридического
лица);
 страховой номер индивидуального лицевого счета (СНИЛС) владельца
квалифицированного сертификата - для физического лица;
 основной государственный регистрационный номер (ОГРН) владельца
квалифицированного сертификата - для юридического лица;
 идентификационный номер налогоплательщика (ИНН) владельца
квалифицированного сертификата - для юридического лица;
 ключ проверки ЭП;
 наименование используемого средства ЭП и (или) стандарты,
требованиям которых соответствует ключ ЭП и ключ проверки ЭП;
 наименования средств ЭП и средств аккредитованного УЦ, которые
использованы для создания ключа ЭП, ключа проверки ЭП,
11
квалифицированного сертификата, а также реквизиты документа,
подтверждающего соответствие указанных средств требованиям,
установленным
в
соответствии
с
Федеральным
законом
«Об
Электронной Подписи»;
 наименование и место нахождения аккредитованного УЦ, который
выдал квалифицированный сертификат;
 номер квалифицированного сертификата аккредитованного УЦ;
 ограничения использования квалифицированного сертификата (если
такие ограничения установлены).
Кроме того, данный приказ устанавливает порядок расположения полей в
квалифицированном сертификате.
Приказ ФСБ РФ «Об утверждении Требований к средствам электронной
подписи и Требований к средствам удостоверяющего центра»
Требования предназначены для заказчиков и разработчиков средств
электронной подписи и удостоверяющих центров при их взаимодействии
между собой и с организациями, проводящими криптографические и
специальные исследования таких средств, а также при их взаимодействии с
ФСБ РФ, подтверждающей соответствие таких средств установленным
требованиям [5].
При создании ЭП средства ЭП должны [1]:
 показывать лицу, подписывающему электронный документ, содержание
информации, которую он подписывает;
 создавать ЭП только после подтверждения лицом, подписывающим
электронный документ, операции по созданию ЭП;
 однозначно показывать, что ЭП создана.
При проверке ЭП средства ЭП должны:
 показывать содержание электронного документа, подписанного ЭП;
12
 показывать информацию о внесении изменений в подписанный ЭП
электронный документ;
 указывать на лицо, с использованием ключа ЭП которого подписаны
электронные документы.
1.2.
Обзор технологий, используемых для разработки системы
автоматизации
SOAP – сервис
Веб-сервис (или веб - служба) — это программная система со
стандартизированными интерфейсами определяемая веб-адресом.
Веб-сервисы могут взаимодействовать как друг с другом, так и со
сторонними приложениями при помощи сообщений, основанных на
протоколах SOAP, XML-RPC, REST и других [6].
SOAP - сервис – это сервис, взаимодействие с которым происходит по
протоколу SOAP.
Рисунок 1.1. Схема работы SOAP-сервиса
Можно выделить три компонента, взаимодействующие в рамках веб-службы.
Переведём их названия как
 заказчик (service requestor);
 исполнитель (service provider);
 каталог (service broker).
13
После завершения разработки службы, исполнитель регистрирует её в
каталоге, где её могут найти потенциальные заказчики. Заказчик, найдя в
каталоге подходящую службу, импортирует оттуда её WSDL-спецификацию
и разрабатывает в соответствии с ней свое программное обеспечение. WSDL
описывает формат запросов и ответов, которыми обмениваются заказчик и
исполнитель
в
процессе
работы.
Для
обеспечения
взаимодействия
используются следующие стандарты [6]:
 XML: Расширяемый язык разметки, предназначенный для хранения
и передачи структурированных данных;
 SOAP: Протокол обмена сообщениями на базе XML;
 WSDL: Язык описания внешних интерфейсов веб-службы на базе
XML;
 UDDI: Универсальный интерфейс распознавания, описания и
интеграции (Universal Discovery, Description and Integration).
Инструмент для расположения описаний веб-сервисов (WSDL) для
последующего их поиска другими организациями и интеграции в
свои системы.
SOAP (Simple Object Access Protocol) – протокол разработанный на базе XML,
с
целью
обмена
информацией
в
распределенных
системах.
SOAP
устанавливает стандарт взаимодействия клиент-сервер и регламентирует, как
должен осуществляться вызов, передаваться параметры и возвращаемые
значения.
Пример SOAP запроса:
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getPerson xmlns="http://warehouse.example.com/ws">
<personID>1</ personID>
14
</ getPerson>
</soap:Body>
</soap:Envelope>
В приведенном примере запроса вызывается метод getPerson, которому
передается параметр personID.
Пример SOAP ответа:
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getPersonResponse
xmlns="http://warehouse.example.com/ws">
<getPersonResult>
<personID>1</personID>
<personName>Иванов Иван</personName>
<Position>Инженер</ Position >
<Age>45</Age>
</getPersonResult>
</getPersonResponse>
</soap:Body>
</soap:Envelope>
Данный пример возвращает информацию о запрашиваемом человеке, его
имя, должность и возраст.
Для передачи SOAP сообщений могут использоваться любые протоколы и
продукты, например, протоколы HTTP, HTTPS, SMTP.
Платформа .Net
.NET Framework – платформа от компании Microsoft для разработки
программного обеспечения, выпущенная в 2002 году. Она состоит из двух
частей:
15
 CLR (Common Language Runtime) общеязыковой исполняющей
среды;
 FLC (Framework Class Library) библиотеки классов.
CLR - это модель программирования, используемую во всех типах
приложений. CLR имеет собственный загрузчик файлов, диспетчер памяти,
система безопасности, пул потоков и другое. Кроме того, CLR предоставляет
объектно-ориентированную модель программирования, определяющую, как
выглядят и ведут себя типы и объекты [7].
FCL - это объектно-ориентированный API-интерфейс, используемый
всеми моделями приложений. В данной библиотеке содержатся определения
типов, классов и методов которые позволяют выполнять ввод/вывод, работать
с потоками, сетью и т. п. Естественно, что все эти определения типов
соответствуют существующей CLR в модели программирования [7].
На сегодняшний день существует несколько версий среды CLR. Это
серверная версия, которая выполняется на 32-разрядной системе Windows под
архитектуру х86, а также на 64-разрядной системе Windows под архитектуры
х64 и IA64. Еще предлагается версия под платформу Silverlight, которая
реализована на основе программного кода серверной версии среды CLR.
Также существует облегченная версия .NET Framework для мобильных
телефонов и устройств на базе ОС Windows Mobile и Windows СЕ, которая
называется .NET Compact Framework.
Европейская ассоциация по стандартизации информационных и
вычислительных систем ЕСМА International1 13 декабря 2001 году приняла в
качестве стандарта язык С# и некоторые компоненты среды CLR и библиотеки
FCL. Этот стандарт позволил сторонним компаниям разработать ЕСМАсовместимые версии этих технологий под архитектуру других процессоров и
операционных систем. Компания Novell выпускает платформу Moonlight 2,
1
2
http://www.ecma-international.org/
http://mono-project.com
16
реализацию платформы Silverlight которая, ориентирована на операционные
системы UNIX.
Существуют компиляторы для многих языков программирования
поддерживающие данную платформу, ниже приведен не полный список:
 .Net: C++/CLI;
 C#;
 Visual Basic;
 JScript;
 J# (компилятор для языка Java);
 Python;
 Php.
Рисунок 1.2. Процесс компиляции файлов
Результатом компиляции файлов, написанных на разных языках
программирования, но поддерживающими CRL будет управляемый модуль
(managed module). Данный модуль является исполняемым файлов, для работы
которого требуется CLR.
CLR совместимые компиляторы генерируют IL-код, также его называют
управляемым кодом. Это связано с тем, что CLR управляет его жизненным
циклом и выполнением. Кроме IL-кода каждый CLR совместимый компилятор
должен создавать для каждого управляемого модуля метаданные (metadata).
17
Метаданные – это набор таблиц содержащие описание типов и методов,
определенных в модуле, а также указывается, на что ссылается управляемый
модуль. IL-код всегда связан с метаданными, т.к. компилятор генерирует их
одновременно и связывает в управляемый модуль.
Исполнение кода
Чтобы выполнить какой-либо IL-код он должен быть преобразован в
машинные
команды.
Этим
занимается
JIT-компилятор
(Just-in-time
compilation) CLR.
JIT-компиляция – это преобразование промежуточного кода (IL-кода) в
машинный код во время выполнения программы.
Скомпилированный код уничтожается после завершения работы
приложения, это связано с тем, что JIT-компилятор хранит машинные
команды в динамической памяти. При повторном или параллельном запуске
приложения JIT-компилятор заново скомпилирует IL-код в машинные
команды.
Снижение производительности, связанное с работой JIT-компилятора,
для большинства приложений незначительное. Основная масса приложений
во время работы обращается к одним и тем же методам. Производительности
снижается только при первом обращении к методу. Также JIT – компилятор
оптимизирует машинный код по примеру компилятора C++, такая
преобразование занимает больше времени при компиляции, но при
исполнении такого кода производительность выше.
Инструменты
Среды разработки, поддерживающие .NET:
 Microsoft Visual Studio (C#, Visual Basic .NET, Managed C++, F#);
 SharpDevelop;
 MonoDevelop.
18
ASP.NET MVC
В архитектуре Model-View-Controller (MVC) предполагает разделение
приложения на три компонента: модель, представление и контроллер.
Платформа ASP.NET MVC предлагает альтернативный подход для создания
веб-приложений. Платформа ASP.NET MVC имеет упрощенную архитектуру
с
расширенными
возможностями
тестирования.
Платформа
MVC
определяется в пространстве имен System.Web.Mvc и является базовой
частью пространства имен System.Web.
Платформа MVC представляет собой стандарт разработки, хорошо
знакомый многим разработчикам. Некоторые типы веб-приложений более
эффективно работают на базе платформы MVC. Другие приложения попрежнему могут использовать платформу ASP.NET, построенную на основе
веб-форм и обратной передачи. В некоторых типах веб-приложений могут
применяться одновременно оба подхода, поскольку они не являются
взаимоисключающими.
Платформа MVC содержит следующие компоненты:
Рисунок 1.3. Компоненты MVC
19
 Модели. Объекты модели представляют собой части приложения, в
которых реализуется логика домена данных приложения. Часто объекты
модели извлекают и хранят состояние модели в базе данных. Например,
объект продукта может извлекать данные из базы, обрабатывать их и
затем записывать обновленные данные в таблицу продуктов на сервере
SQL Server. В небольших приложениях модель обособляется чаще на
концептуальном, а не на физическом уровне. Например, если
приложение используется только для считывания данных из набора и их
отправки в представление, в нем не требуется наличие уровня
физической модели и связанных с ней классов. В этом случае набор
данных играет роль объекта модели.
 Представления. Представления — это компоненты, предназначенные
для отображения пользовательского интерфейса приложения. Обычно
пользовательский интерфейс создается на основе данных модели. В
качестве примера можно привести представление редактирования
таблицы продуктов, в котором отображаются текстовые поля,
раскрывающиеся списки и флажки в соответствии с текущим
состоянием объекта продукта.
 Контроллеры. Контроллеры — это компоненты, обеспечивающие
взаимодействие с пользователем, работу с моделью и, в конечном итоге,
выбор представления для отображения пользовательского интерфейса.
В
приложении
MVC
представление
используется
только
для
отображения данных. Обработка взаимодействия с пользователем и
ответ на ввод данных осуществляется контроллерами. Например,
контроллер обрабатывает значения строк запроса и передает их в
модель, которая, в свою очередь, выполняет запрос к базе данных с
использованием предоставленных значений.
Платформа MVC позволяет создавать приложения с обособлением
различных аспектов (логика ввода данных, бизнес-логика и логика
20
пользовательского интерфейса), обеспечивая при этом слабые связи между
этими элементами. В этой платформе каждый вид логики размещается на
обособленном уровне приложения. Логика пользовательского интерфейса
принадлежит представлению. Логика ввода принадлежит контроллеру.
Бизнес-логика
принадлежит
модели.
Такое
разделение
обеспечивает
облегчает построение приложения, поскольку позволяет концентрироваться
на
каждом
аспекте
реализации
отдельно.
Например,
можно
сконцентрироваться на представлении, не обращая внимания на бизнеслогику.
Помимо упрощения разработки платформа MVC также позволяет
упростить тестирование приложений по сравнению с веб-приложениями на
основе веб-форм ASP.NET. Например, в веб-приложении на основе веб-форм
ASP.NET один и тот же класс используется для отображения выходных
данных
и
реакции
на
ввод
данных
пользователем.
Написание
автоматизированных тестов для приложений на основе веб-форм ASP.NET
может быть сопряжено со сложностями, поскольку, например, для
тестирования отдельной страницы потребуется создать экземпляры класса
страницы, всех ее дочерних элементов управления, а также всех зависимых
классов в приложении. Из-за необходимости создания такого большого числа
экземпляров классов для запуска страницы зачастую бывает трудно
разрабатывать тесты, ориентированные на проверку отдельных фрагментов
приложения. В связи с этим тестирование приложений на основе веб-форм
ASP.NET может быть более сложным по сравнению с приложениями MVC.
Кроме того, для проведения тестов приложения на основе веб-форм ASP.NET
требуется
веб-сервер.
В
платформе
MVC
реализуется
разделение
компонентов, и активно используются интерфейсы, что позволяет тестировать
отдельные компоненты в изоляции от остальных компонентов платформы.
Наличие слабых связей между тремя основными компонентами приложения
MVC также позволяет повысить эффективность параллельной разработки.
21
Например, представление, логика контроллера и бизнес-логика в модели
могут разрабатываться тремя разными разработчиками.
1.3.
Методы обеспечения безопасности информационных систем
Информационная
безопасность
–
это
процесс
обеспечения
конфиденциальности, целостности и доступности информации [8].
 Конфиденциальность – обеспечение доступа к информации только
авторизованным пользователям.
 Целостность – обеспечение достоверности и полноты информации и
методов ее обработки.
 Доступность – обеспечение доступа к информации и связанным с ней
активам авторизованных пользователей по мере необходимости [8].
Существующие методы обеспечения информационной безопасности
можно разделить на два класса:
 организационно-правовые методы;
 технические методы.
К правовым методам относятся документы, регулирующие все аспекты
информационной безопасности, такие как [8]:
 международные договоры РФ;
 Конституция РФ;
 законы федерального уровня (включая федеральные конституционные
законы, кодексы);
 Указы Президента РФ;
 постановления правительства РФ;
 нормативные правовые акты федеральных министерств и ведомств;
22
 нормативные правовые акты субъектов РФ, органов местного
самоуправления и т. д.
Основные технические методы:
 авторизация (этот метод позволяет создавать группы пользователей,
наделять эти группы разными уровнями доступа к сетевым и
информационным ресурсам и контролировать доступ пользователя к
этим ресурсам);
 идентификация и аутентификация;
 криптография;
 протоколирование и аудит;
 экранирование
(разделение
информационных
потоков
между
различными информационными системами);
 физическая защита;
 поддержка
текущей
работоспособности
(резервное копирование,
управление носителями);
Под угрозой безопасности автоматизированной системы (АС) понимается
возможные действия, способные нанести ущерб ее безопасности.
Атака на автоматизированную систему – это поиск и/или использование
злоумышленником той или иной уязвимости системы. Иными словами, атака
– это реализация угрозы безопасности [9].
Для АС угрозы следует классифицировать прежде всего по аспекту
информационной
безопасности
(доступность,
целостность,
конфиденциальность) против которого они направлены в первую очередь:
 угрозы нарушения доступности (отказ в обслуживании), направленные
на создание такой ситуации, при которой доступ к ресурсам ИС
заблокирован либо работоспособность информационной системы
нарушена;
23
 угрозы нарушения целостности информации, обрабатываемой в
информационной системе, направленные на ее изменение или
искажения с целью нарушения ее качества либо уничтожения. Данная
угроза особенно актуальна для систем передачи данных и систем
телекоммуникации. Нарушение целостности информации может быть
преднамеренным, а также воздействием окружающей среды;
 угрозы нарушения конфиденциальности, направленные на разглашение
конфиденциальной или секретной информации. При реализации этих
угроз информация становится известна лица, которые не должны иметь
к ней доступ [9].
Данные виды угроз можно считать первичными, поскольку их реализация
ведет к воздействию на защищаемую информацию.
Классификация сетевых атак
Существует четыре основных категории сетевых атак:
 атаки доступа;
 атаки модификации;
 атаки типа «отказ в обслуживании»;
 комбинированные атаки.
Атака доступа
Атака доступа – это попытка получения злоумышленником информации,
на которую у него нет разрешения. Данная атака направлена на нарушение
конфиденциальности информации. К таким атакам относятся:
 подслушивание (Sniffing);
 перехват (Hijacking);
 перехват сеанса (Session Hijacking).
24
Подслушивание
компьютерным
(Sniffing).
сетям
в
В
основном
незащищенном
данные
формате,
передаются
что
по
позволяет
злоумышленнику, получившему доступ к сети, подслушивать трафик. Для
подслушивания в компьютерных сетях используют сниффер пакетов. Данная
программа позволяет перехватывать все сетевые пакеты, передаваемые в
пределах отдельной сети.
Сфера применения таких программ довольно широка. В настоящее время
снифферы используются для диагностики неисправностей и анализа трафика.
Также с помощью сниффера можно узнать конфиденциальную, а также
полезную для развития атаки информацию. Это возможно по причине того,
что многие сетевые службы (Telnet, FTP, SMTP, POP3 и т. д.) передают данные
в открытом виде, никак их не защищая от прослушивания.
Перехват (Hijacking). Активная атака благодаря, которой злоумышленник
перехватывает информацию в момент передаче между пользователем и
сетевой
службой.
С
помощью
данной
атаки
можно
перехватить
аутентификационные данные передаваемые пользователем при условии, что
они передаются в открытом формате. Если учесть, что многие пользователи
имеют одну пару логин/пароль для входа в различные информационные
системы, то злоумышленник перехватив данные может получить доступ к
другим ресурсам.
Перехват сеанса (Session Hijacking). При завершении аутентификации на
сайте пользователю выдается сессионный ключ, который предается при
каждом обращении к ресурсу. Данный вид атаки заключается в перехвате
сессионного ключа, таким образом злоумышленник может выполнять
действия от имени пользователя, пока не истечет время жизни сессионного
ключа.
Нужно
отметить,
что
злоумышленник
не
получает
аутентификационных данных, которые можно использовать после завершения
жизни сессионного ключа.
25
Атака модификации
Атака
модификации
–
это
попытка
неправомочного
изменения
информации. Такая атака возможна везде, где существует или передается
информация; она направлена на нарушение целостности информации [9]. К
таким атакам относятся:
 изменение данных;
 добавление данных;
 удаление данных.
Атака «отказ в обслуживании»
Атака «отказ в обслуживании» не нацелена на получение доступа к
информации или сети. Главная цель данной атаки сделать недоступным
атакуемый ресурс (web-приложение, сеть компании) для пользователей. Это
достигает за счет превышения допустимых пределов функционирования сети,
операционной системы или ресурса [9].
Совершение DoS-атак возможно по причине слабости архитектуры
системы (сети, приложения). В случаях с web-серверным приложением DoSатака может быть выполнена путем открытия максимального числа
соединений с web-приложением тем самым не давая подключиться обычным
пользователям.
Если для совершения атаки используется множество устройств, то
данная атака называется распределенной атакой «отказ в обслуживании»
(DDoS-атака).
Данный вид атаки прост в реализации, в то же время достаточно
эффективен, при успешной реализации злоумышленник может нанести
большой вред организации и пользователям.
Отказ в доступе к информации. В результате DoS-атаки, направленной
против информации, последняя становится непригодной для использования.
26
Информация уничтожается, искажается или переносится в недоступное место
[9].
Отказ в доступе к приложениям. Другой тип DoS-атак направлен на
приложения, обрабатывающие или отображающие информацию, либо на
компьютерную систему, в которой эти приложения выполняются. В случае
успеха подобной атаки решение задач, выполняемых с помощью такого
приложения, становится невозможным [9].
Отказ в доступе к системе. Общий тип DoS-атак ставит своей целью
вывод из строя компьютерной системы, в результате чего сама система,
установленные на ней приложения и вся сохраненная информация становятся
недоступными [9].
Отказ в доступе к средствам связи. Целью атаки является
коммуникационная среда. Целостность компьютерной системы и информации
не нарушается, однако отсутствие средств связи лишает пользователей
доступа к этим ресурсам [9].
Комбинированная атака
При комбинированной атаке, для достижения цели злоумышленник
применяет несколько видов атак.
Подмена доверенного субъекта. Данная атака заключается в подмене
IP-адреса с целью получения доступа к защищенной информации иди
ресурсам, а также для сокрытия личности злоумышленника при реализации
других атак. Реализация данной атаки возможно если аутентификация
пользователя происходит по базе IP-адресов.
Атака эксплойта.
компьютерная
Эксплоит (exploit -
программа,
фрагмент
эксплуатировать) – это
программного
кода
или
последовательность команд, использующие уязвимости в программном
обеспечении и применяемые для проведения атаки на компьютерную систему
[9]. Результатом данной атаки может быть: нарушение функционирования,
получения контроля над системой.
27
Выделяют два вида эксплоитов:
 удаленный. Для работы эксплоита не нужен доступ к атакуемой
системе т.е. возможно выполнить через сеть;
 локальный. Для работы эксплоита нужен доступ к атакуемой
системе. В этом случае, обычно целью является получения прав
администратора.
Парольные атаки. Целью данных атак является завладение пары
логин/пароль от учетной записи пользователя. Для этого злоумышленник
может использовать такие атаки, как:
 ip-спуфинг;
 сниффинг;
 полный перебор.
Атака полного перебора заключается в подборе пароля к ресурсу путем
перебора большого числа вариантов.
Угадывание ключа. Цель атаки подобрать криптографический ключ
необходимы для расшифровки. Для выполнения требуется большое
количество ресурсов.
Атаки на уровне приложений. Атака, использующая уязвимости в
прикладном программном обеспечении (FTP, Web-сервер). Вероятность
данной атаки никогда нельзя исключать т.к. специалисты по безопасности
регулярно находят новые уязвимости.
Фишинг (Phishing). Цель данной атаки, получение конфиденциальных
данных пользователя таких как, пароли, номера кредитных карт, PIN-кодов.
Для этого злоумышленник создает точную копию сайта одного из банков.
Затем производится спам-рассылка, в письме содержится информация о
необходимости зайти на сайт банка и обновить свои данные. Пройдя по
ссылке, указанной в письме, пользователь попадает на ложный сайт, где
28
вводит нужную информацию. Таким образом злоумышленник может
получить доступ электронной почте, а иногда к банковскому счету человека.
Применение ботнетов. Ботнет – это сеть компьютеров, зараженных
вредоносной
программой
поведения
Backdoor.
Backdoor
позволяет
киберпреступникам удаленно управлять зараженными машинами (каждой в
отдельности, частью компьютеров, входящих в сеть, или всей сетью целиком)
без ведома пользователя. Такие программы называются ботами [9]. Используя
захваченные компьютеры злоумышленник может использовать для других
атак (например, DDoS-атака). Как правило пользователь не подозревает, что
его компьютер используется злоумышленником.
Уязвимости в Web-приложениях
Для выполнения атаки на web-приложение злоумышленник использует
уязвимости, ниже приведен список наиболее популярных уязвимостей [10]
web-приложений.
Fingerprinting
Позволяет идентифицировать операционную систему и программное
обеспечение, что позволит подготовить плацдарм для атаки.
Cross-Site Scripting (XSS)
Позволяет внедрить вредоносный код в веб-страницу приложения. При
эксплуатации данной уязвимости атака производится не на сервер, а на
клиента. Выделают два вида XSS-уязвимостей: активная и пассивная.
Для выполнения пассивной XSS требуется дополнительное действие от
жертвы (пример: клик по специальной ссылке). Это связано с тем, что скрипт
не хранится на сервере.
Для выполнения активной XSS от жертвы не требуется выполнения
дополнительных действий т.к. скрипт хранится на сервере и будет срабатывать
при открытии страницы сайта.
29
Brute Force
Позволяет
подобрать
учетные
данные
пользователя
перебором
возможных вариантов. Одним из примеров такой уязвимости служит форма
входа на сайт при этом количество попыток неверного ввода пары
логин/пароль не ограничено.
SQL Injection
Позволяет выполнить произвольный запрос к базе данных, путем
внедрения произвольного SQL-кода. Данная уязвимость возникает при
некорректной обработки параметров в SQL-запросе. Пример:
String q = Request.Params[“q”];
String sql = “SELECT * FROM Users WHERE name=”+q;
Данный пример уязвим к SQL Injection, злоумышленник может в качестве
параметра передать любой значение и сформировать любой запрос в базу
данных. Пример эксплуатации уязвимости, в качестве параметра q
злоумышленник передал строку:
‘admin’; INSERT INTO Users (username, password) VALUES (‘superuser’, ‘123’);
После конкатенации строк получится запрос:
SELECT * FROM Users WHERE name=‘admin’; INSERT INTO Users (username,
password) VALUES (‘superuser’, ‘123’);
Это позволит выполнить два запроса в базу данных, выполнив тем самым
добавление нового пользователя.
Cross-Site Request Forgery
Данный тип атак направлен на имитирование запроса пользователя к
стороннему сайту. Для осуществления данной атаки, жертва должна быть
авторизована на том сервере, на который отправляется запрос, и этот запрос
не должен требовать какого-либо подтверждения со стороны пользователя,
который не может быть проигнорирован или подделан атакующим скриптом
[11].
30
Credential/Session Prediction
Вычисляется
идентифицирующее
или
угадывается
индивидуальную
уникальное
сессию
или
значение,
пользователя,
подвергающегося атаке.
Многие веб-сайты разработаны так, что подтверждают подлинность и
отслуживают пользователя, когда связь впервые установлена. Чтобы сделать
это, пользователи должны подтверждать их подлинность веб-сайту, обычно
используя пару логин/пароль Конечно, вместо передачи этих секретных
данных назад и вперед с каждой транзакцией, веб-сайты создают уникальный
«идентификатор сессии» (session ID), чтобы в дальнейшем распознавать
пользовательскую сессию с проверенной подлинностью. Последующие
сообщения между пользователем и веб-сайтом сопровождаются этим
идентификатором сессии, которая имеет статус проверенной подлинности.
Если злоумышленник, сможет вычислить или угадать идентификатор сессии
другого пользователя, вполне вероятно, он воспользуется этим для своих
преступных деяний.
Server Misconfiguration
Данная уязвимость возникает, когда администратор использует
стандартную (по умолчанию) конфигурацию сервера, что во многом упрощает
задачу проведения и развития атаки.
Information Leakage
Данная уязвимость возможна, когда сервер показывает важную
информацию, например, подробную информацию об ошибках, которая может
быть использована для дальнейшего развития атаки.
Path Traversal
Данная уязвимость позволяет получить доступ к файлам, директориям и
командам, находящимся вне основной директории Web-сервера.
URL Redirector Abuse
31
Данная уязвимость возникает при использовании внешних ресурсов для
перенаправления.
Пример:
http://original_site.com/redirect.html?q=http://external_site.com/exte
rnal_page.html
В данном примере для перенаправления в качестве параметра (параметр q)
передается абсолютный путь до ресурса.
32
ГЛАВА 2. РАЗРАБОТКА АВТОМАТИЗИРОВАННОЙ
СИСТЕМЫ ОБРАБОТКИ ЗАЯВОК В УЦ
2.1.
Анализ процесса обработки заявок на выдачу сертификата с
целью его автоматизации
Процедура подачи заявления в УЦ на подключение какой-либо услуги для
большинства клиентов является трудоемкой. На данный момент подача
заявления состоит из следующих шагов:
1. загрузка бланка заявления с сайта УЦ;
2. заполнение бланка заявления;
3. отправка заявления по E-mail менеджеру УЦ;
4. проверка данных в заявлении менеджером УЦ;
5. выставление счета клиенту.
При заполнении заявления клиент может допустить ошибку. Менеджер УЦ
отклонит такое заявление и свяжется с клиентом с просьбой исправить ошибку
и выслать заявление повторно.
Рисунок 2.1. Схема процесса подачи заявления клиентом
33
Менеджер тратит много времени на проверку заявлений и выявления
ошибок. Если заявление содержит верные данные менеджер формирует заявку
и счет.
Из приведенной схемы (Рис. 2.1) видно, что для ускорения процесса
нужно автоматизировать следующие шаги:
 заполнение заявления клиентом;
 проверки заявления менеджером.
Данные шаги являются наиболее трудоемкими в процессе подачи и
обработки заявления.
По моему мнению, для автоматизации данных шагов необходимо
разработать сайт приема заявок, с помощью которого клиент, сможет
заполнять форму в режиме онлайн. По завершению заполнения, будет
происходить
автоматическая
проверка
введенных
данных,
в
случае
корректности клиент получить на e-mail счет, иначе клиенту будет показано
сообщение об ошибке. Последовательность действий со стороны клиента
приведена на Рис.2.2.
Для проверки введенных данных, а также для формирования заявки и
счета необходимо выполнять запросы в CRM-систему. Также нужно
производить оповещение клиента с помощью e-mail и sms-сообщений при
следующих событиях:
 выставление счета
 информирование о завершении услуги
Такой подход позволит:
 сократить время заполнения формы;
 сократить время ожидания результата проверки заявки;
 снизить вероятность ошибки.
34
Для приема заявок от клиентов имеющих сертификат необходимо
разработать кабинет, позволяющий просматривать список оказываемых услуг,
продлевать
услуги.
Вход
должен
осуществляется
по
сертификату.
Последовательность действий приведена на Рис.2.3.
После автоматизации процесс подачи заявок должен содержать следующие
шаги:
1. клиент должен зайти на сайт приема заявок;
2. клиент должен заполнить форму заявки;
3. автоматическая проверка данных клиента;
4. при удачной проверке на e-mail клиента придет автоматически
сформированный счет для оплаты;
5. в случае не удачно проверки клиент увидит сообщение об ошибке.
Форма онлайн заявки должна содержать следующие элементы:
 выпадающие списки;
 автоматическое заполнение полей;
 ограничения на вводимые символы, в зависимости от поля;
 ограничения на длину вводимого значения в поле формы.
Рисунок 2.2. Схема автоматизированного процесса подачи заявления
клиентом
35
Рисунок 2.3. Схема подачи заявления на продление услуги
После анализа процесса подачи и обработки заявки в удостоверяющий
центр приходим к выводу о необходимости разработки системы обработки
заявок от клиентов (ОЗК). которая позволит реализовать описанные выше
требования. Данная система будет расширением существующие CRMсистемы.
2.2.
Для
Проектирование общей структуры подсистемы
реализации
сформированных
требований,
разрабатываемая
подсистема должна включать следующие функции:
 форма заполнения заявки для новых клиентов;
 форма продления для услуги для клиентов;
 интеграция с системой по работе с клиентами УЦ.
Для реализации данных функций разрабатываемая система ОУК должна
сдержать следующие компоненты:
 веб-сайт;
 модуль интеграции с CRM-системой;
36
 модуль взаимодействия с сервисом «Контур-Фокус» и базой данных
банков РФ;
 служба оповещения клиентов;
 система подачи заявлений.
Рисунок 2.4. Общая структура системы автоматизации
Веб-сайт
Данный компонент является точкой входа для клиента, с помощью него
клиент будет осуществлять все действия по заполнению заявок. Веб-сайт
должен разделятся на два части, открытая и закрытая.
Открытая часть доступна всем пользователям интернета и позволять с
формировать заявку на подключение услуги. При составлении заявки от
пользователя требуется предоставить следующую информацию:
 название организации;
 ИНН, КПП;
 ОРГН;
 юридический и фактический адрес;
 телефон, e-mail;
 ФИО руководителя, должность;
37
 банковские реквизиты;
 данные лица на которого выдается сертификат (ФИО, ИНН, СНИЛС,
должность);
 выбор органов для отчетности.
При заполнении формы заявки, производится автоматическое заполнение
основных полей, что сократит время заполнения и уменьшит вероятность
ошибок.
Закрытая часть доступна только клиентам, которые имеют сертификат
выданный данным удостоверяющим центром. После входа клиент может
просматривать список услуг и сертификатов действующие на данный момент
и срок их завершения. Также клиент может продлить действующую услугу
или подключить новую.
Модуль интеграции с CRM-системой
Данный модуль необходим для взаимодействия с Microsoft Dynamic CRM
2011. Все полученный данные полученные от клиента будут хранится в CRMсистеме. Этот подход выбран для упрощения структуры системы, а также
данное решение повысит надежность системы исключив избыточные
элементы. Сервер с CRM-системой находится в локальной сети УЦ.
Модуль взаимодействия с сервисом «Контур-Фокус» и базой данных
банков РФ
Данный модуль необходим для взаимодействия со сторонними
сервисами и базой данных. При заполнении формы заявки, производится
автоматическое заполнение основных полей, что сократит время заполнения и
уменьшит вероятность ошибок. В качестве источников информации,
используется система «Контур-Фокус», которая позволяет получить выписки
из Единого государственного реестра юридических лиц и индивидуальных
предпринимателей. Для получения информации о банке клиента используется
справочник банковских идентификационных кодов.
38
Служба оповещения клиентов
Данный компонент выполняет следующие функции:
 информирования клиентов о статусе их заявлений;
 информирования о сроке истечения действия сертификатов или
завершения услуг;
 повышения безопасности использования кабинетом УЦ.
Система подачи заявлений
Это компонент который формирует заявку на основании данных
предоставленных клиентом при заполнении формы и передает на обработку в
CRM систему.
В качестве платформы для разработки данной системы выбран .Net
Framework версии 4.5 и язык программирования C# (Си Шарп), в качестве
среды разработки Microsoft Visual Studio 2013. Для разработки web-сайта
выбрана технология ASP.NET MVC.
2.3.
Интеграция с Microsoft Dynamic CRM 2011
Интеграция с Microsoft Dynamic CRM является важной частью разработки
системы т.к. для хранения данных будут использоваться инструменты CRM
системы. Также для полноценной автоматизации подачу заявления нужно
встроить во внутренние бизнес процессы удостоверяющего центра.
Для интеграции с сервисами в Dynamic CRM используется SOAP сервис.
Для работы с данным сервисов и форматом XML сообщений компания
Microsoft выпустила набор инструментов (Microsoft Dynamics CRM 2011 SDK)
который позволяет делать запросы и управлять бизнес процессами в CRM
системе.
Пример создания клиента и авторизации для CRM системы [12]:
39
clientCredentials = new ClientCredentials();
clientCredentials.Windows.ClientCredential = new
System.Net.NetworkCredential(username, password, domain);
cachedConfig =
ServiceConfigurationFactory.CreateConfiguration<IOrganizationService>({CRM_UR
L});
OrganizationServiceProxy client = new
OrganizationServiceProxy(cachedConfig, clientCredentials);
Пример запроса на получение информации о подключенных услугах у
клиента:
<fetch version=""1.0"" output-format=""xml-platform"" mapping=""logical""
distinct=""false"">
<entity name=""new_ser"">
<attribute name=""new_serv"" />
<attribute name=""new_history"" />
<attribute name=""new_dend"" />
<attribute name=""new_dbegin"" />
<attribute name=""new_serid"" />
<order attribute=""new_serv"" descending=""false"" />
<filter type=""and"">
<condition attribute=""new_account_new_ser"" operator=""eq""
value=""{0}"" />
<condition attribute=""new_dbegin"" operator=""not-null"" />
</filter>
</entity>
</fetch>
Для выполнения запросы нужно выполнить следующий код:
client.RetrieveMultiple(new FetchExpression(String.Format({XML},
accountId)));
Кроме получения данных должна быть возможность сохранять данные не
нарушая внутреннею структуру бизнес процессов компании. Пример общего
запроса на сохранение данных:
<Update xmlns='http://schemas.microsoft.com/crm/2007/WebServices'>
<entity xsi:type='{entityName}'>
<fieldName>{fieldValue}</fieldName>
40
</entity>
</Update>
Сущностей (Entity) в CRM системе может быть создано много, и они могут
быть связаны между собой. Запросы выполняются асинхронно с
использование ключевых async/await. Данная возможность появилась в C#
4.5, такой подход облегчат работу с асинхронными методами.
Интеграция заключается в разработки библиотеки для работы с
конкретными сущностями CRM системы, список основных методов:
 получение данных о клиенте по сертификату;
 получение данных о сертификатах и услугах клиента;
 получение данных о контактных лицах клиента;
 получение активных заявок клиента;
 добавление заказа от клиента;
 добавление клиента;
 добавление контактного лица.
2.4.
Проектирование Web- интерфейса
Web-интерфейс важная часть системы автоматизации, именно через него
будет происходить работа клиента. Важной задачей является сделать его
простым и интуитивно понятным для клиента.
Для проектирования интерфейса использовались следующие технологии:
HTML, CSS, Javascript. Для ускорения разработки был применен Twitter
Bootstrap, это свободный набор инструментов для создания сайтов и вебприложений. Включает в себя HTML и CSS шаблоны оформления для
типографики, веб-форм, кнопок, меток, блоков навигации и прочих
компонентов веб-интерфейсов, включая JavaScript расширения.
41
Рисунок 2.4. Главная страница
На главной странице пользователю предлагается выбрать действие:
 зайти в кабинет УЦ (будет рассмотрен ниже)
 составить заявление
При составлении заявления пользователю открывается страница на
которой нужно по шагам ответить на вопросы. После этого формируется
заявление и отправляется в УЦ.
Рисунок 2.5. Пример одного шага при составлении заявления
42
Рисунок 2.6. Страница показывающая подключенные услуги и сертификаты
Примечание: Интерфейс может меняться в процессе развития сервиса
2.5.
Служба оповещения клиентов
Для оповещения клиентов используются два вида рассылок электронные
письма (E-mail) и SMS рассылки. Электронные письма рассылаются в
случаях:
 после составления заявления отправляется с информацией, которая
указана в заявлении;
 при отклонении заявления по каким-либо причинам;
 напоминание о необходимости продления услуги.
SMS сообщения рассылаются в следующих случаях:
 при входе в личный кабинет владельцу сертификата приходит
сообщения;
 напоминание о необходимости продления услуги.
43
Для создания такого инструмента будет разработана Windows-служба,
которая будет рассылать сообщения. Рассылка будет осуществляться по
следующей схеме:
 один раз в день отправляется на e-mail письмо и sms-сообщение тем
клиентам, у которых осталось 2 недели до окончания срока действия
услуги;
 отправляется sms-сообщение при входе в личный кабинет.
Взаимодействие со службой будет осуществляться с помощью очередей
сообщений (MSMQ). Такой подход позволит оперативно взаимодействовать
со службой рассылки.
2.6.
Использование очередей MSMQ
В операционной системе Windows доступна служба очередей сообщений
MSMQ (Microsoft Message Queuing). Очередь сообщений создана для
взаимодействия приложений в распределенной среде. Для работы с очередями
была написана вспомогательный класс (класс-обертка) для упрощенной
работы, в котором используется стандартная библиотека (разработанная
компанией Microsoft) и входит в .Net Framework и доступна в пространстве
имен System.Messaging. В результате использование очередей сообщений
упростилось, пример работы с классом [13]:
var rs = new MQReceiver();
rs.ReceivedMessage += rs_ReceiveMessage;
rs.Start();
Метод, который срабатывает при получении сообщения:
private void rs_ReceiveMessage(MQReceiver sender, MQMessage message) {
if (message.IsMail) {
mailsender.SendMailAsync(message, r =>{
if (r.Status == TaskStatus.RanToCompletion) {
AddLog("Mail sended to " + message.Address);
}else{
44
if (r.Exception != null&&r. Exception.InnerException!=null)
{ AddLog(r.Exception.InnerException.Message); }}});
}else{
smssender.Send(message, r =>{
if (r.Status == TaskStatus.RanToCompletion) {
AddLog("SMS sended to " + message.Address);
}else{
if (r.Exception != null){
AddLog(r.Exception.InnerException.Message);
}}});}}
2.7.
Использование Контур-Фокус API
Для автоматизации процесса заполнения заявлений будет использоваться
сервис Контур-Фокус. У данного сервиса есть не публичное API, которое
доступно только партнерам компании «СКБ-Контур».
Работа с сервисом организована следующим образом:
 при заполнении клиент указывает ИНН организации;
 при формировании заявления выполняется GET запрос на сервис
Контур-Фокус, передавая ИНН клиента;
 в ответ на запрос сервис возвращает информацию об юридическом
лице.
Пример запроса на получения информации:
https://focus-api.kontur.ru/api?inn=7203158243&key={api-key}
Пример неполного ответа:
{"items": [
{
"inn": "7203158243",
"kpp": "720301001",
"ogrn": "1057200596970",
"okpo": "76822710",
"fullName": "Общество с ограниченной ответственностью \"СибтелКрипто\"",
"shortName": "ООО \"Сибтел-Крипто\"",
45
"statusText": "Действующее",
[…]
}]}
Описание параметров:
iin – ИНН организации о которой запрашивается информация.
key –уникальный ключ, который выдается партнерам компании «СКБКонтур».
2.8.
Хранение информации о банках
Для удобства пользователя, а также сокращения числа ошибок, при
заполнении информации о банке клиента используется автоматическое
заполнение. При вводе банковского идентификационного кода (БИК)
информация о названии и корреспондентском счет берется из базы данных.
В качестве сервера базы данных используется MS SqlServer. Данная БД
состоит из одной таблицы, ниже перечислены основные поля:
 Id – идентификатор записи;
 Name – название банка;
 Adr – адрес банка;
 Bik – БИК банка;
 Tels – телефоны банка.
Пример запроса:
https://o.ke72.ru/PublicApi/GetBankByBik?bik=044525225
Ответ сервера в формате JSON:
[{"Name":"ОАО \"СБЕРБАНК РОССИИ\"", "Bik":"044525225",
"KS":"30101810400000000225",
"Address":"УЛ.ВАВИЛОВА,19","City":"МОСКВА","Tel":"(495)5005550,88005555550"}]
После получения ответа от сервера, заполнение полей производится при
помощи JavaScript.
46
ГЛАВА 3. ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ
АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ ОБРАБОТКИ
ЗАЯВОК УЦ
Разработанная
система
является
расширением
CRM
-
системы
используемой в УЦ. Все необходимые мероприятия по обеспечению ИБ
действующий УЦ были проведены соответствующими специалистами до
разработки системы ОЗК.
Очевидно, после внедрения системы ОЗК список актуальных угроз
расширяется, т.к. появляется дополнительный объект для реализации угроз
информационной безопасности, которые ранее не были учтены.
В данной дипломной работе анализируются угрозы информационной
безопасности, возникающие в связи с внедрением подсистемы автоматизации
обработки заявок, не затрагивая безопасность основной информационной
системы УЦ в целом.
Модель нарушителя
Для системы ОЗК нарушителей можно разделить на две группы:
 Внутренний нарушитель – физическое лицо, имеющий доступ к
основной информационной системе УЦ.
 Внешний нарушитель – физическое лицо, не имеющий доступ к
основной
информационной
системе
УЦ.
Взаимодействие
с
разработанной системой автоматизации осуществляется через
Интернет.
Внутренний нарушитель
В качестве внутренних нарушителей я рассматриваю лиц, являющихся
работниками УЦ и имеющих доступ к CRM-системе в УЦ. К этой группе
относятся:
47
 системный администратор основной ИС УЦ (Категория 1);
 менеджер по работе с клиентами (Категория 2);
 оператор (Категория 3).
Лица, относящиеся к категории 1, потенциально могут реализовывать
угрозы ИБ, используя возможности по непосредственному доступу к
защищаемой информации, обрабатываемой и хранимой в ИС УЦ, а также к
техническим и программным средствам ИС [14].
Лица, категории 2 имеют доступ CRM-системе, в которой хранится
информация о клиентах УЦ.
Лица, категории 3 имеют доступ к локальной сети УЦ.
Нарушители категории 2 и 3 исключаются из актуальных ввиду
архитектурных
решений,
примененных
при
разработке
системы
автоматизации. Данные решения позволили исключить взаимодействие
нарушителей данных категорий с рассматриваемой системой.
К
нарушителям
категории
1,
применяться
комплекс
особых
организационных мер по их подбору, принятию на работу, назначению на
должность
и
контролю
выполнения
функциональных
обязанностей.
Предполагается, что в число лиц категорий 1 будут включаться только
доверенные лица и поэтому указанные лица исключаются из числа вероятных
нарушителей [14].
Внешний нарушитель
К данной группе относятся лица, взаимодействующие с системой ОЗК
удаленно, через сеть Интернет.
Предполагается, что лица данной группы относятся к вероятным
нарушителем.
48
Цели реализации угроз информационной безопасности
Основными
информационными
ресурсами,
обрабатываемыми
в
подсистеме являются следующие.
1. Целевая информация
 персональные данные клиентов УЦ;
 информация
о
подключенных
услугах
и
сертификатах
выданных УЦ.
2. Технологическая информация:
 конфигурационные файлы;
 средства и принципы защиты, применяемые в подсистеме.
Основными целями реализации угроз для злоумышленника могут быть
нарушением целостности, конфиденциальности и доступности информации о
клиентах УЦ.
Целью нарушения конфиденциальности информации злоумышленником
может быть получение базы клиентов УЦ. Факт разглашения данной
информации может послужить поводом для репутационных потерь, а также
оттока клиентов.
Целью
нарушения
целостности
и
доступности
информации
злоумышленником, может быть желание приостановить работу УЦ, что
скажется на финансовых показателях удостоверяющего центра и клиентов
данной организации.
Перечень актуальных угроз и меры по обеспечению безопасности
системы
В данном списке содержатся угрозы актуальные для системы ОЗК.
Выбор производился на основании базовой модели безопасности угроз [15].
Актуальность данных угроз обусловлено мнением экспертов в области ИБ.
49
Угрозы «Анализа сетевого трафика» с перехватом передаваемой во
внешние сети и принимаемой из внешних сетей информации
Для противодействия данным угрозам используются защищенные каналы
связи. Передача информации между клиентом и системой ОЗК, а также между
CRM-системой и системой ОЗК с использованием шифрования.
Угрозы сканирования, направленные на выявление типа операционной
системы ИСПДн, сетевых адресов рабочих станций, открытых портов и
служб, открытых соединений и др.
Для противодействия данным угрозам проведены следующие меры:
 произведена настройка Firewall таким образом, чтобы сетевые порты,
кроме 443 были закрыты;
 удалена информация из заголовков http-ответа сервера способная
раскрыть платформу разработки и версии ПО;
 была изменено название переменной для хранения сессии в cookies
пользователя.
Угрозы выявления паролей
Для противодействия данным угрозам используются защищенные каналы
связи.
Угрозы получения НСД
Для противодействия данным угрозам были применены следующие
методы:
 вход в закрытую часть сайта ОЗК производится по сертификату;
 фильтрация запросов в CRM-систему;
 доступ к серверу по RDP с определенных IP-адресов;
 обновление системы.
Угрозы типа «Отказ в обслуживании»
50
Для противодействия данным угрозам были проведены следующие
мероприятия:
 использование параметризированных запросов в БД MS Sql Server;
 использование CAPTCHA для предотвращения отправки большого
числа заявок;
 обновление системы.
Угрозы удаленного запуска приложений
Для противодействия данным угрозам были проведены следующие
мероприятия:
 установка антивирусного ПО.
Также были проведены мероприятия по предотвращению следующих
уязвимостей:
 Cross-Site
Request
Forgery.
Данная
уязвимость
решается
использованием инструментов, которые входят в платформу разработки
(ASP.NET MVC). Для устранения данной уязвимости нужно передавать
специальные маркеры при каждом запросе, что предотвращает подделку
запроса от пользователя.
 Cross-Site Scripting (XSS). Данную уязвимость позволяет избежать
путем проверки содержимого запросов, а также экранирования при
выводе
информации
пользователю.
Данные
функции
по
предотвращению XSS входят в выбранную платформу разработки
(ASP.NET MVC).
ЗАКЛЮЧЕНИЕ
В
результате
проделанной
работы
была
разработана
система
автоматизации обработки заявок от клиентов в удостоверяющий центр на
оказание услуг электронной отчетности в государственные органы РФ. Данная
51
система позволяет получить услугу отчетности в следующие государственные
органы:
 Федеральная Налоговая Службаx;
 Пенсионный фонд;
 Фонд Социального Страхования;
 Росстат;
 Росприроднадзор.
Для достижения цели был проведен анализ бизнес процессов УЦ по
обработке заявок и выявлены места для автоматизации.
Также были выполнены меры по обеспечению информационной
безопасности разработанной системы.
Система автоматизации внедрена в удостоверяющем центре ООО
«Сибтел-Крипто» и проходит тестирование.
52
СПИСОК ЛИТЕРАТУРЫ
1. Федеральный закон от 06.04.2011 N 63-ФЗ "Об электронной подписи".
2013.
2. ГОСТ Р 34.10-2012. Процессы формирования и проверки электронной
цифровой подписи. 2012.
3. ГОСТ Р 34.11-2012. Функция хэширования. 2012.
4. Приказ ФСБ РФ от 27.12.2011 N 795 "Об утверждении Требований к
форме квалифицированного сертификата ключа проверки электронной
подписи". 2011.
5. Приказ ФСБ РФ от 27.12.2011 N 796 "Об утверждении Требований к
средствам
электронной
подписи
и
Требований
к
средствам
удостоверяющего центра". 2011.
6. // Веб-служба - Википедия: [сайт]. URL: http://ru.wikipedia.org/wiki/
Веб_служба (дата обращения: 20.Январь.2014).
7. Рихтер Д. CLR via C#. Программирование на платформе Microsoft.NET
Framework 4.0 на языке C#. Питер, 2012.
8. // Информационная безопасность - Википедия: [сайт]. [2006]. URL: http://
ru.wikipedia.org/wiki/Информационная_безопасность (дата обращения:
20.Январь.2014).
9. Ф. Ш.В. Защита информации в компьютерных системах и сетях. Москва:
ДМК Пресс, 2012.
10. // Статистика уязвимостей корпоративных информационных систем за
2012
год:
[сайт].
[2013].
URL:
http://www.ptsecurity.ru/download/
analitika_web.pdf (дата обращения: 26.Января.2014).
11. // Подделка межсайтовых запросов - Википедия: [сайт]. [2007]. URL: http:/
/ru.wikipedia.org/wiki/Подделка_межсайтовых_запросов (дата обращения:
20.Январь.2014).
53
12. // MSDM - Microsoft Dynamics CRM Sdk: [сайт]. URL: http://
msdn.microsoft.com/en-us/library/hh547453.aspx
(дата
обращения:
8.Январь.2014).
13. // MSDN - Reliable Messaging with MSMQ and.NET: [сайт]. [2002]. URL:
http://msdn.microsoft.com/en-us/library/ms978430.aspx (дата обращения:
9.Январь.2014).
14. России М. Методические рекомендации по составлению Частной модели
угроз безопастности персональных данных при их обработке в
информационных
системах
персональных
данных
учреждений
здравоохранения, социальной сферы, труда и занятости. Москва. 2009.
15. ФСТЭК. Базовая модель угроз безопасности персональных данных при их
обработке в информационных системах персональных данных. 2008.
16. // URI - Википедия: [сайт]. [1990]. URL: http://ru.wikipedia.org/wiki/URI
(дата обращения: 20.1.2014).
17. // HTTPS - Википедия: [сайт]. [2000]. URL: http://ru.wikipedia.org/wiki/
HTTPS (дата обращения: 20.Январь.2014).
18. RFC 2068 — Протокол Передачи Гипертекста – HTTP/1.1 [Электронный
ресурс] // RFC 2.0 — Русские Переводы RFC: [сайт]. [1997]. URL: http://
rfc2.ru/2068.rfc (дата обращения: 20.Январь.2014).