Размещено на http://www.allbest.ru/

РОССИЙСКАЯ ФЕДЕРАЦИЯ

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

ИНСТИТУТ МАТЕМАТИКИ И КОМПЬЮТЕРНЫХ НАУК

КАФЕДРА ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

Министерство образования и науки

Федеральное государственное бюджетное образовательное учреждение

Высшего профессионального образования

"Тюменский государственный университет"

Институт математики и компьютерных наук

Кафедра информационной безопасности

Выпускная квалификационная работа

Автоматизация процесса подачи и обработки заявок в удостоверяющий центр

Научный руководитель:

доцент, к. т. н. Е.А. Оленников

Автор работы: С.И. Худышкин

Оглавление

• Введение
• Глава 1. Положения, регулирующие работу удостоверяющего центра. обзор технологий используемых при разработке АС и угроз, возникающих при их использовании
• 1.1 Нормативная база для работы удостоверяющего центра
• 1.2 Обзор технологий, используемых для разработки системы автоматизации
• 1.3 Методы обеспечения безопасности информационных систем
• Глава 2. Разработка автоматизированной системы обработки заявок в УЦ
• 2.1 Анализ процесса обработки заявок на выдачу сертификата с целью его автоматизации
• 2.2 Проектирование общей структуры подсистемы
• 2.3 Интеграция с Microsoft Dynamic CRM 2011
• 2.4 Проектирование Web-интерфейса
• 2.5 Служба оповещения клиентов
• 2.6 Использование очередей MSMQ
• 2.7 Использование Контур-Фокус API
• 2.8 Хранение информации о банках
• Глава 3. Обеспечение безопасности автоматизированной системы обработки заявок УЦ
• Заключение
• Список литературы

Введение

Актуальность темы дипломной работы обусловлена развитием электронного документооборота, а также повсеместным использованием электронной цифровой подписи (ЭЦП) позволяющей сдавать отчетность в государственные органы, а также участвовать в тендерах через Интернет. Любое предприятие, получившее ЭЦП может отправить документы через Интернет в такие органы:

· Пенсионный фонд;

· Федеральная Налоговая Служба;

· Фонд Социального Страхования;

· Росстат.

В такой ситуации на передний план выходит качество предоставляемых услуг удостоверяющих центров (УЦ).

Удостоверяющий центр ООО "Сибтел-Крипто" стремится улучшить работу с клиентами и ведет разработки в сфере электронного документооборота. На данный момент, работа с клиентами ведется менеджерами УЦ. Для получение ЭЦП (либо другой услуги) клиент должен лично прийти в офис УЦ, либо отправить заявление на электронную почту УЦ. После этого менеджер осуществляет обработку заявления. Это процедура может занимать много времени т.к. клиент может указать неправильные данные.

В период отчетности число клиентов резко возрастает, и менеджеры не справляются с нагрузкой, однако в меж отчетный период поток клиентов умеренный, и менеджеры УЦ успевают обработать все заявки. Увеличение штата менеджеров может решить данную проблему, но также увеличит финансовые расходы компании, кроме того в меж отчетный период менеджеры не будут иметь должную нагрузку.

После анализа проблемы я пришел к выводу, что нужна автоматизация процесса обработки заявок от клиентов, благодаря которой клиенты смогут через интернет в полуавтоматическом режиме сформировать заявку на какую-либо услугу. Такой подход позволит снизить нагрузку на менеджеров УЦ.

Степень разработанности проблемы. В области автоматизации работы удостоверяющих центров успешно ведет компания ЗАО "ПФ "СКБ Контур". Ее продукты успешно применяются при работе удостоверяющего центра ООО "Сибтел-Крипто".

Основным недостатком, устранение которого и послужила целью данной дипломной работы, это необходимость автоматизации обработки заявлений от клиентов. Решения данной проблемы нет в продуктах компании "СКБ-Контур".

Цель дипломной работы состоит в автоматизации и защите процесса обработки и подачи заявок в удостоверяющий центр ООО "Сибтел-Крипто" на оказание услуг электронной отчетности.

Поставленная цель обуславливает следующие задачи:

· анализ процесса обработки заявок с целью его автоматизации;

· разработка системы автоматизации процесса обработки заявок в УЦ;

· обеспечение безопасности системы автоматизации УЦ.

Объектом исследования выступает процесс взаимодействия удостоверяющего центра с клиентом.

Предметом исследования в дипломной работе являются инструментальные методы для автоматизации и упрощения процесса взаимодействия УЦ с клиентом.

Методологической и теоретической основой дипломной работы явились труды зарубежных специалистов в области разработки информационных систем и автоматизации процессов. В ходе работы над дипломной работой использовалась информация, отражающая содержание законов, законодательных актов и нормативных актов, постановлений Правительства Российской Федерации, регулирующих работу удостоверяющих центров и защиту информации.

Теоретическая значимость дипломного исследования состоит в развитии и совершенствовании методов автоматизации процессов взаимодействия между клиентом и удостоверяющим центром.

Практическая значимость работы определяется тем, что ее результаты позволяют повысить качество предоставляемых услуг удостоверяющим центром, а также упростит использование электронной отчетности в государственные органы.

Новизна дипломной работы заключается в автоматизации процесса подачи заявлений клиентов в удостоверяющий центр.

Наиболее существенные результаты, полученные в процессе разработки, состоят в следующем:

· оптимизация бизнес процессов удостоверяющего центра;

· автоматизирован процесс оповещения клиентов о необходимости продления услуги;

· автоматизирован процесс проверки данных клиента;

· автоматизирован процесс выставления счета клиенту.

Глава 1. Положения, регулирующие работу удостоверяющего центра. обзор технологий используемых при разработке АС и угроз, возникающих при их использовании

1.1 Нормативная база для работы удостоверяющего центра

Электронная цифровая подпись

Электронная цифровая подпись (ЭЦП) - информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и которая используется для определения лица, подписывающего информацию [1].

Применение ЭЦП

Электронная цифровая подпись предназначена для определения лица, подписавшего электронный документ. Также является полноценной заменой собственноручной подписи в случаях, предусмотренных законом.

Использование электронной подписи позволяет осуществить:

· Контроль целостности документа. При модификации или повреждении документа подпись станет недействительной.

· Защиту от подделки документа. Контроль целостности позволяет выявить недостоверность документа, таким образом подделывание становится невозможным в большинстве случаев.

· Невозможность отказа от авторства. Применение закрытого ключа ЭЦП гарантирует невозможность отказа от уже совершенных действий того, кто подписал документы. Так если происходит идентификация владельца сертификата ключа, а автор подписи не может от неё отказаться.

· Доказательное подтверждение авторства документа. Применение закрытого ключа ЭЦП гарантирует невозможность отказа от уже совершенных действий того, кто подписал документы. Так если происходит идентификация владельца сертификата ключа, а автор подписи не может от неё отказаться.

Виды ЭЦП предусмотренные законом РФ

Простая электронная подпись Подпись, которая посредством использования кодов, паролей или иных средств подтверждает факт формирования электронной подписи определенным лицом [1].

Неквалифицированная электронная подпись

Подпись, которая [1]:

1. получена в результате криптографических методов преобразования информации с использованием ключа электронной подписи;

2. позволяет определить лицо, подписавшее электронный документ;

3. позволяет обнаружить факт внесения изменений в электронный документ после момента его подписания;

4. создается с использованием средств электронной подписи.

Квалифицированная электронная подпись Подпись, которая соответствует всем признакам неквалифицированной электронной подписи и следующим дополнительным признакам [1]:

1. ключ проверки электронной подписи указан в квалифицированном сертификате;

2. для создания и проверки электронной подписи используются средства электронной подписи, получившие подтверждение соответствия требованиям, установленным в соответствии с настоящим Федеральным законом.

Стандарты

ГОСТ Р 34.10-2012 - стандарт определяет схему электронной цифровой подписи (ЭЦП), процессы формирования и проверки цифровой подписи под заданным сообщением (документом), передаваемым по незащищенным телекоммуникационным каналам общего пользования в системах обработки информации различного назначения [2].

Внедрение цифровой подписи на основе настоящего стандарта повышает, по сравнению с ранее действовавшей схемой цифровой подписи, уровень защищенности передаваемых сообщений от подделок и искажений [2].

Криптографическая стойкость данной схемы цифровой подписи основывается на сложности решения задачи дискретного логарифмирования в группе точек эллиптической кривой, а также на стойкости используемой хэш-функции. Алгоритмы вычисления хэш-функции установлены в ГОСТ Р 34.11-2012 [2].

ГОСТ Р 34.11-2012 - российский криптографический стандарт, "определяет алгоритм и процедуру вычисления хэш-функции для любой последовательности двоичных символов, которые применяются в криптографических методах обработки и защиты информации, в том числе для реализации процедур обеспечения целостности, аутентичности, электронной цифровой подписи (ЭЦП) при передаче, обработке и хранении информации в автоматизированных системах" [3].

Регулирование работы УЦ

Удостоверяющий центр - юридическое лицо или индивидуальный предприниматель, осуществляющие функции по созданию и выдаче сертификатов ключей проверки электронных подписей [1].

Основные документы, регулирующие работу удостоверяющего центра:

· Федеральный закон от 06.04.2011 N 63-ФЗ (ред. от 02.07.2013)"Об электронной подписи" (с изм. и доп., вступающими в силу с 01.09.2013);

· Приказ ФСБ РФ от 27.12.2011 N 795 "Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи";

· Приказ ФСБ РФ от 27.12.2011 N 796 "Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра".

Удостоверяющий центр получает статус аккредитованный после признания уполномоченным федеральным органом соответствия удостоверяющего центра требованиям закона "Об электронной подписи". Аккредитацию проводит Минкомсвязь России.

Закон "Об электронной подписи"

Данный закон регулирует отношения в области использования электронных подписей при совершении гражданско-правовых сделок, оказании государственных и муниципальных услуг, исполнении государственных и муниципальных функций, при совершении иных юридически значимых действий, в том числе в случаях, установленных другими федеральными законами [1].

Данный закон устанавливает [1]:

· требования к удостоверяющим центрам (на основании проводится аккредитация);

· виды электронных подписей;

· полномочия федеральных органов исполнительной власти в сфере использования электронной подписи;

· полномочия и обязанности удостоверяющего центра;

· порядок аккредитации удостоверяющего центра.

Приказ ФСБ РФ "Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи"

Данный приказ устанавливает какую информацию должен содержать квалифицированный сертификат.

Сертификат должен содержать [4]:

· уникальный номер квалифицированного сертификата;

· даты начала и окончания действия квалифицированного сертификата;

· фамилия, имя и отчество (если имеется) владельца квалифицированного сертификата - для физического лица, либо наименование и место нахождения владельца квалифицированного сертификата - для юридического лица, а также в случаях, предусмотренных Федеральным законом "Об Электронной Подписи", фамилия, имя и отчество (если имеется) физического лица, действующего от имени владельца квалифицированного сертификата - юридического лица на основании учредительных документов юридического лица или доверенности (далее - уполномоченный представитель юридического лица);

· страховой номер индивидуального лицевого счета (СНИЛС) владельца квалифицированного сертификата - для физического лица;

· основной государственный регистрационный номер (ОГРН) владельца квалифицированного сертификата - для юридического лица;

· идентификационный номер налогоплательщика (ИНН) владельца квалифицированного сертификата - для юридического лица;

· ключ проверки ЭП;

· наименование используемого средства ЭП и (или) стандарты, требованиям которых соответствует ключ ЭП и ключ проверки ЭП;

· наименования средств ЭП и средств аккредитованного УЦ, которые использованы для создания ключа ЭП, ключа проверки ЭП, квалифицированного сертификата, а также реквизиты документа, подтверждающего соответствие указанных средств требованиям, установленным в соответствии с Федеральным законом "Об Электронной Подписи";

· наименование и место нахождения аккредитованного УЦ, который выдал квалифицированный сертификат;

· номер квалифицированного сертификата аккредитованного УЦ;

· ограничения использования квалифицированного сертификата (если такие ограничения установлены).

Кроме того, данный приказ устанавливает порядок расположения полей в квалифицированном сертификате.

Приказ ФСБ РФ "Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра"

Требования предназначены для заказчиков и разработчиков средств электронной подписи и удостоверяющих центров при их взаимодействии между собой и с организациями, проводящими криптографические и специальные исследования таких средств, а также при их взаимодействии с ФСБ РФ, подтверждающей соответствие таких средств установленным требованиям [5].

При создании ЭП средства ЭП должны [1]:

· показывать лицу, подписывающему электронный документ, содержание информации, которую он подписывает;

· создавать ЭП только после подтверждения лицом, подписывающим электронный документ, операции по созданию ЭП;

· однозначно показывать, что ЭП создана.

При проверке ЭП средства ЭП должны:

· показывать содержание электронного документа, подписанного ЭП;

· показывать информацию о внесении изменений в подписанный ЭП электронный документ;

· указывать на лицо, с использованием ключа ЭП которого подписаны электронные документы.

1.2 Обзор технологий, используемых для разработки системы автоматизации

SOAP-сервис

Веб-сервис (или веб - служба) - это программная система со стандартизированными интерфейсами определяемая веб-адресом.

Веб-сервисы могут взаимодействовать как друг с другом, так и со сторонними приложениями при помощи сообщений, основанных на протоколах SOAP, XML-RPC, REST и других [6].

SOAP - сервис - это сервис, взаимодействие с которым происходит по протоколу SOAP.

Рисунок 1.1 Схема работы SOAP-сервиса

Можно выделить три компонента, взаимодействующие в рамках веб-службы. Переведём их названия как

· заказчик (service requestor);

· исполнитель (service provider);

· каталог (service broker).

После завершения разработки службы, исполнитель регистрирует её в каталоге, где её могут найти потенциальные заказчики. Заказчик, найдя в каталоге подходящую службу, импортирует оттуда её 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> </ 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 году. Она состоит из двух частей:

· 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.

Европейская ассоциация по стандартизации информационных и вычислительных систем ЕСМА International http: //www.ecma-international.org/ 13 декабря 2001 году приняла в качестве стандарта язык С# и некоторые компоненты среды CLR и библиотеки FCL. Этот стандарт позволил сторонним компаниям разработать ЕСМА-совместимые версии этих технологий под архитектуру других процессоров и операционных систем. Компания Novell выпускает платформу Moonlight http: //mono-project.com, реализацию платформы 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).

Метаданные - это набор таблиц содержащие описание типов и методов, определенных в модуле, а также указывается, на что ссылается управляемый модуль. 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.

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

· Модели. Объекты модели представляют собой части приложения, в которых реализуется логика домена данных приложения. Часто объекты модели извлекают и хранят состояние модели в базе данных. Например, объект продукта может извлекать данные из базы, обрабатывать их и затем записывать обновленные данные в таблицу продуктов на сервере SQL Server. В небольших приложениях модель обособляется чаще на концептуальном, а не на физическом уровне. Например, если приложение используется только для считывания данных из набора и их отправки в представление, в нем не требуется наличие уровня физической модели и связанных с ней классов. В этом случае набор данных играет роль объекта модели.

· Представления. Представления - это компоненты, предназначенные для отображения пользовательского интерфейса приложения. Обычно пользовательский интерфейс создается на основе данных модели. В качестве примера можно привести представление редактирования таблицы продуктов, в котором отображаются текстовые поля, раскрывающиеся списки и флажки в соответствии с текущим состоянием объекта продукта.

· Контроллеры. Контроллеры - это компоненты, обеспечивающие взаимодействие с пользователем, работу с моделью и, в конечном итоге, выбор представления для отображения пользовательского интерфейса. В приложении MVC представление используется только для отображения данных. Обработка взаимодействия с пользователем и ответ на ввод данных осуществляется контроллерами. Например, контроллер обрабатывает значения строк запроса и передает их в модель, которая, в свою очередь, выполняет запрос к базе данных с использованием предоставленных значений.

Платформа MVC позволяет создавать приложения с обособлением различных аспектов (логика ввода данных, бизнес-логика и логика пользовательского интерфейса), обеспечивая при этом слабые связи между этими элементами. В этой платформе каждый вид логики размещается на обособленном уровне приложения. Логика пользовательского интерфейса принадлежит представлению. Логика ввода принадлежит контроллеру. Бизнес-логика принадлежит модели. Такое разделение обеспечивает облегчает построение приложения, поскольку позволяет концентрироваться на каждом аспекте реализации отдельно. Например, можно сконцентрироваться на представлении, не обращая внимания на бизнес-логику.

Помимо упрощения разработки платформа MVC также позволяет упростить тестирование приложений по сравнению с веб-приложениями на основе веб-форм ASP.net. Например, в веб-приложении на основе веб-форм ASP.net один и тот же класс используется для отображения выходных данных и реакции на ввод данных пользователем. Написание автоматизированных тестов для приложений на основе веб-форм ASP.net может быть сопряжено со сложностями, поскольку, например, для тестирования отдельной страницы потребуется создать экземпляры класса страницы, всех ее дочерних элементов управления, а также всех зависимых классов в приложении. Из-за необходимости создания такого большого числа экземпляров классов для запуска страницы зачастую бывает трудно разрабатывать тесты, ориентированные на проверку отдельных фрагментов приложения. В связи с этим тестирование приложений на основе веб-форм ASP.net может быть более сложным по сравнению с приложениями MVC. Кроме того, для проведения тестов приложения на основе веб-форм ASP.net требуется веб-сервер. В платформе MVC реализуется разделение компонентов, и активно используются интерфейсы, что позволяет тестировать отдельные компоненты в изоляции от остальных компонентов платформы.

Наличие слабых связей между тремя основными компонентами приложения MVC также позволяет повысить эффективность параллельной разработки. Например, представление, логика контроллера и бизнес-логика в модели могут разрабатываться тремя разными разработчиками.

1.3 Методы обеспечения безопасности информационных систем

Информационная безопасность - это процесс обеспечения конфиденциальности, целостности и доступности информации [8].

· Конфиденциальность - обеспечение доступа к информации только авторизованным пользователям.

· Целостность - обеспечение достоверности и полноты информации и методов ее обработки.

· Доступность - обеспечение доступа к информации и связанным с ней активам авторизованных пользователей по мере необходимости [8].

Существующие методы обеспечения информационной безопасности можно разделить на два класса:

· организационно-правовые методы;

· технические методы.

К правовым методам относятся документы, регулирующие все аспекты информационной безопасности, такие как [8]:

· международные договоры РФ;

· Конституция РФ;

· законы федерального уровня (включая федеральные конституционные законы, кодексы);

· Указы Президента РФ;

· постановления правительства РФ;

· нормативные правовые акты федеральных министерств и ведомств;

· нормативные правовые акты субъектов РФ, органов местного самоуправления и т.д.

Основные технические методы:

· авторизация (этот метод позволяет создавать группы пользователей, наделять эти группы разными уровнями доступа к сетевым и информационным ресурсам и контролировать доступ пользователя к этим ресурсам);

· идентификация и аутентификация;

· криптография;

· протоколирование и аудит;

· экранирование (разделение информационных потоков между различными информационными системами);

· физическая защита;

· поддержка текущей работоспособности (резервное копирование, управление носителями);

Под угрозой безопасности автоматизированной системы (АС) понимается возможные действия, способные нанести ущерб ее безопасности.

Атака на автоматизированную систему - это поиск и/или использование злоумышленником той или иной уязвимости системы. Иными словами, атака - это реализация угрозы безопасности [9].

Для АС угрозы следует классифицировать прежде всего по аспекту информационной безопасности (доступность, целостность, конфиденциальность) против которого они направлены в первую очередь:

· угрозы нарушения доступности (отказ в обслуживании), направленные на создание такой ситуации, при которой доступ к ресурсам ИС заблокирован либо работоспособность информационной системы нарушена;

· угрозы нарушения целостности информации, обрабатываемой в информационной системе, направленные на ее изменение или искажения с целью нарушения ее качества либо уничтожения. Данная угроза особенно актуальна для систем передачи данных и систем телекоммуникации. Нарушение целостности информации может быть преднамеренным, а также воздействием окружающей среды;

· угрозы нарушения конфиденциальности, направленные на разглашение конфиденциальной или секретной информации. При реализации этих угроз информация становится известна лица, которые не должны иметь к ней доступ [9].

Данные виды угроз можно считать первичными, поскольку их реализация ведет к воздействию на защищаемую информацию.

Классификация сетевых атак

Существует четыре основных категории сетевых атак:

· атаки доступа;

· атаки модификации;

· атаки типа "отказ в обслуживании";

· комбинированные атаки.

Атака доступа

Атака доступа - это попытка получения злоумышленником информации, на которую у него нет разрешения. Данная атака направлена на нарушение конфиденциальности информации. К таким атакам относятся:

· подслушивание (Sniffing);

· перехват (Hijacking);

· перехват сеанса (Session Hijacking).

Подслушивание (Sniffing). В основном данные передаются по компьютерным сетям в незащищенном формате, что позволяет злоумышленнику, получившему доступ к сети, подслушивать трафик. Для подслушивания в компьютерных сетях используют сниффер пакетов. Данная программа позволяет перехватывать все сетевые пакеты, передаваемые в пределах отдельной сети.

Сфера применения таких программ довольно широка. В настоящее время снифферы используются для диагностики неисправностей и анализа трафика. Также с помощью сниффера можно узнать конфиденциальную, а также полезную для развития атаки информацию. Это возможно по причине того, что многие сетевые службы (Telnet, FTP, SMTP, POP3 и т.д.) передают данные в открытом виде, никак их не защищая от прослушивания.

Перехват (Hijacking). Активная атака благодаря, которой злоумышленник перехватывает информацию в момент передаче между пользователем и сетевой службой. С помощью данной атаки можно перехватить аутентификационные данные передаваемые пользователем при условии, что они передаются в открытом формате. Если учесть, что многие пользователи имеют одну пару логин/пароль для входа в различные информационные системы, то злоумышленник перехватив данные может получить доступ к другим ресурсам.

Перехват сеанса (Session Hijacking). При завершении аутентификации на сайте пользователю выдается сессионный ключ, который предается при каждом обращении к ресурсу. Данный вид атаки заключается в перехвате сессионного ключа, таким образом злоумышленник может выполнять действия от имени пользователя, пока не истечет время жизни сессионного ключа. Нужно отметить, что злоумышленник не получает аутентификационных данных, которые можно использовать после завершения жизни сессионного ключа.

Атака модификации

Атака модификации - это попытка неправомочного изменения информации. Такая атака возможна везде, где существует или передается информация; она направлена на нарушение целостности информации [9]. К таким атакам относятся:

· изменение данных;

· добавление данных;

· удаление данных.

Атака "отказ в обслуживании"

Атака "отказ в обслуживании" не нацелена на получение доступа к информации или сети. Главная цель данной атаки сделать недоступным атакуемый ресурс (web-приложение, сеть компании) для пользователей. Это достигает за счет превышения допустимых пределов функционирования сети, операционной системы или ресурса [9].

Совершение DoS-атак возможно по причине слабости архитектуры системы (сети, приложения). В случаях с web-серверным приложением DoS-атака может быть выполнена путем открытия максимального числа соединений с web-приложением тем самым не давая подключиться обычным пользователям.

Если для совершения атаки используется множество устройств, то данная атака называется распределенной атакой "отказ в обслуживании" (DDoS-атака).

Данный вид атаки прост в реализации, в то же время достаточно эффективен, при успешной реализации злоумышленник может нанести большой вред организации и пользователям.

Отказ в доступе к информации. В результате DoS-атаки, направленной против информации, последняя становится непригодной для использования. Информация уничтожается, искажается или переносится в недоступное место [9].

Отказ в доступе к приложениям. Другой тип DoS-атак направлен на приложения, обрабатывающие или отображающие информацию, либо на компьютерную систему, в которой эти приложения выполняются. В случае успеха подобной атаки решение задач, выполняемых с помощью такого приложения, становится невозможным [9].

Отказ в доступе к системе. Общий тип DoS-атак ставит своей целью вывод из строя компьютерной системы, в результате чего сама система, установленные на ней приложения и вся сохраненная информация становятся недоступными [9].

Отказ в доступе к средствам связи. Целью атаки является коммуникационная среда. Целостность компьютерной системы и информации не нарушается, однако отсутствие средств связи лишает пользователей доступа к этим ресурсам [9].

Комбинированная атака

При комбинированной атаке, для достижения цели злоумышленник применяет несколько видов атак.

Подмена доверенного субъекта. Данная атака заключается в подмене IP-адреса с целью получения доступа к защищенной информации иди ресурсам, а также для сокрытия личности злоумышленника при реализации других атак. Реализация данной атаки возможно если аутентификация пользователя происходит по базе IP-адресов.

Атака эксплойта. Эксплоит (exploit - эксплуатировать) - это компьютерная программа, фрагмент программного кода или последовательность команд, использующие уязвимости в программном обеспечении и применяемые для проведения атаки на компьютерную систему [9]. Результатом данной атаки может быть: нарушение функционирования, получения контроля над системой.

Выделяют два вида эксплоитов:

· удаленный. Для работы эксплоита не нужен доступ к атакуемой системе т.е. возможно выполнить через сеть;

· локальный. Для работы эксплоита нужен доступ к атакуемой системе. В этом случае, обычно целью является получения прав администратора.

Парольные атаки. Целью данных атак является завладение пары логин/пароль от учетной записи пользователя. Для этого злоумышленник может использовать такие атаки, как:

· ip-спуфинг;

· сниффинг;

· полный перебор.

Атака полного перебора заключается в подборе пароля к ресурсу путем перебора большого числа вариантов.

Угадывание ключа. Цель атаки подобрать криптографический ключ необходимы для расшифровки. Для выполнения требуется большое количество ресурсов.

Атаки на уровне приложений. Атака, использующая уязвимости в прикладном программном обеспечении (FTP, Web-сервер). Вероятность данной атаки никогда нельзя исключать т.к. специалисты по безопасности регулярно находят новые уязвимости.

Фишинг (Phishing). Цель данной атаки, получение конфиденциальных данных пользователя таких как, пароли, номера кредитных карт, PIN-кодов. Для этого злоумышленник создает точную копию сайта одного из банков. Затем производится спам-рассылка, в письме содержится информация о необходимости зайти на сайт банка и обновить свои данные. Пройдя по ссылке, указанной в письме, пользователь попадает на ложный сайт, где вводит нужную информацию. Таким образом злоумышленник может получить доступ электронной почте, а иногда к банковскому счету человека.

Применение ботнетов. Ботнет - это сеть компьютеров, зараженных вредоносной программой поведения Backdoor. Backdoor позволяет киберпреступникам удаленно управлять зараженными машинами (каждой в отдельности, частью компьютеров, входящих в сеть, или всей сетью целиком) без ведома пользователя. Такие программы называются ботами [9]. Используя захваченные компьютеры злоумышленник может использовать для других атак (например, DDoS-атака). Как правило пользователь не подозревает, что его компьютер используется злоумышленником.

Уязвимости в Web-приложениях

Для выполнения атаки на web-приложение злоумышленник использует уязвимости, ниже приведен список наиболее популярных уязвимостей [10] web-приложений.

Fingerprinting

Позволяет идентифицировать операционную систему и программное обеспечение, что позволит подготовить плацдарм для атаки.

Cross-Site Scripting (XSS)

Позволяет внедрить вредоносный код в веб-страницу приложения. При эксплуатации данной уязвимости атака производится не на сервер, а на клиента. Выделают два вида XSS-уязвимостей: активная и пассивная.

Для выполнения пассивной XSS требуется дополнительное действие от жертвы (пример: клик по специальной ссылке). Это связано с тем, что скрипт не хранится на сервере.

Для выполнения активной XSS от жертвы не требуется выполнения дополнительных действий т.к. скрипт хранится на сервере и будет срабатывать при открытии страницы сайта.

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].

Credential/Session Prediction

Вычисляется или угадывается уникальное значение, идентифицирующее индивидуальную сессию или пользователя, подвергающегося атаке.

Многие веб-сайты разработаны так, что подтверждают подлинность и отслуживают пользователя, когда связь впервые установлена. Чтобы сделать это, пользователи должны подтверждать их подлинность веб-сайту, обычно используя пару логин/пароль Конечно, вместо передачи этих секретных данных назад и вперед с каждой транзакцией, веб-сайты создают уникальный "идентификатор сессии" (session ID), чтобы в дальнейшем распознавать пользовательскую сессию с проверенной подлинностью. Последующие сообщения между пользователем и веб-сайтом сопровождаются этим идентификатором сессии, которая имеет статус проверенной подлинности. Если злоумышленник, сможет вычислить или угадать идентификатор сессии другого пользователя, вполне вероятно, он воспользуется этим для своих преступных деяний.

Server Misconfiguration

Данная уязвимость возникает, когда администратор использует стандартную (по умолчанию) конфигурацию сервера, что во многом упрощает задачу проведения и развития атаки.

Information Leakage

Данная уязвимость возможна, когда сервер показывает важную информацию, например, подробную информацию об ошибках, которая может быть использована для дальнейшего развития атаки.

Path Traversal

Данная уязвимость позволяет получить доступ к файлам, директориям и командам, находящимся вне основной директории Web-сервера.

URL Redirector Abuse

Данная уязвимость возникает при использовании внешних ресурсов для перенаправления.

Пример:

http://original_site.com/redirect.html? q=http://external_site.com/external_page.html

В данном примере для перенаправления в качестве параметра (параметр q) передается абсолютный путь до ресурса.

Глава 2. Разработка автоматизированной системы обработки заявок в УЦ

2.1 Анализ процесса обработки заявок на выдачу сертификата с целью его автоматизации

Процедура подачи заявления в УЦ на подключение какой-либо услуги для большинства клиентов является трудоемкой. На данный момент подача заявления состоит из следующих шагов:

1. загрузка бланка заявления с сайта УЦ;

2. заполнение бланка заявления;

3. отправка заявления по E-mail менеджеру УЦ;

4. проверка данных в заявлении менеджером УЦ;

5. выставление счета клиенту.

При заполнении заявления клиент может допустить ошибку. Менеджер УЦ отклонит такое заявление и свяжется с клиентом с просьбой исправить ошибку и выслать заявление повторно.

Рисунок 2.1 Схема процесса подачи заявления клиентом

Менеджер тратит много времени на проверку заявлений и выявления ошибок. Если заявление содержит верные данные менеджер формирует заявку и счет.

Из приведенной схемы (Рис. 2.1) видно, что для ускорения процесса нужно автоматизировать следующие шаги:

· заполнение заявления клиентом;

· проверки заявления менеджером.

Данные шаги являются наиболее трудоемкими в процессе подачи и обработки заявления.

По моему мнению, для автоматизации данных шагов необходимо разработать сайт приема заявок, с помощью которого клиент, сможет заполнять форму в режиме онлайн. По завершению заполнения, будет происходить автоматическая проверка введенных данных, в случае корректности клиент получить на e-mail счет, иначе клиенту будет показано сообщение об ошибке. Последовательность действий со стороны клиента приведена на Рис. 2.2.

Для проверки введенных данных, а также для формирования заявки и счета необходимо выполнять запросы в CRM-систему. Также нужно производить оповещение клиента с помощью e-mail и sms-сообщений при следующих событиях:

· выставление счета

· информирование о завершении услуги

Такой подход позволит:

· сократить время заполнения формы;

· сократить время ожидания результата проверки заявки;

· снизить вероятность ошибки.

Для приема заявок от клиентов имеющих сертификат необходимо разработать кабинет, позволяющий просматривать список оказываемых услуг, продлевать услуги. Вход должен осуществляется по сертификату. Последовательность действий приведена на Рис. 2.3.

После автоматизации процесс подачи заявок должен содержать следующие шаги:

1. клиент должен зайти на сайт приема заявок;

2. клиент должен заполнить форму заявки;

3. автоматическая проверка данных клиента;

4. при удачной проверке на e-mail клиента придет автоматически сформированный счет для оплаты;

5. в случае не удачно проверки клиент увидит сообщение об ошибке.

Форма онлайн заявки должна содержать следующие элементы:

· выпадающие списки;

· автоматическое заполнение полей;

· ограничения на вводимые символы, в зависимости от поля;

· ограничения на длину вводимого значения в поле формы.

Рисунок 2.2 Схема автоматизированного процесса подачи заявления клиентом

Рисунок 2.3 Схема подачи заявления на продление услуги

После анализа процесса подачи и обработки заявки в удостоверяющий центр приходим к выводу о необходимости разработки системы обработки заявок от клиентов (ОЗК). которая позволит реализовать описанные выше требования. Данная система будет расширением существующие CRM-системы.

2.2 Проектирование общей структуры подсистемы

Для реализации сформированных требований, разрабатываемая подсистема должна включать следующие функции:

· форма заполнения заявки для новых клиентов;

· форма продления для услуги для клиентов;

· интеграция с системой по работе с клиентами УЦ.

Для реализации данных функций разрабатываемая система ОУК должна сдержать следующие компоненты:

· веб-сайт;

· модуль интеграции с CRM-системой;

· модуль взаимодействия с сервисом "Контур-Фокус" и базой данных банков РФ;

· служба оповещения клиентов;

· система подачи заявлений.

Рисунок 2.4 Общая структура системы автоматизации

Веб-сайт

Данный компонент является точкой входа для клиента, с помощью него клиент будет осуществлять все действия по заполнению заявок. Веб-сайт должен разделятся на два части, открытая и закрытая.

Открытая часть доступна всем пользователям интернета и позволять с формировать заявку на подключение услуги. При составлении заявки от пользователя требуется предоставить следующую информацию:

· название организации;

· ИНН, КПП;

· ОРГН;

· юридический и фактический адрес;

· телефон, e-mail;

· ФИО руководителя, должность;

· банковские реквизиты;

· данные лица на которого выдается сертификат (ФИО, ИНН, СНИЛС, должность);

· выбор органов для отчетности.

При заполнении формы заявки, производится автоматическое заполнение основных полей, что сократит время заполнения и уменьшит вероятность ошибок.

Закрытая часть доступна только клиентам, которые имеют сертификат выданный данным удостоверяющим центром. После входа клиент может просматривать список услуг и сертификатов действующие на данный момент и срок их завершения. Также клиент может продлить действующую услугу или подключить новую.

...