Преподаватель который помогает студентам и школьникам в учёбе.

Модель «клиент - сервер» .

Содержание:

ВВЕДЕНИЕ

Клиент и сервер взаимодействую друг с другом в сети Интернет или в любой другой компьютерной сети при помощи различных сетевых протоколов, например, IP протокол, HTTP протокол, FTP и другие. Протоколов на самом деле очень много и каждый протокол позволяет оказывать ту или иную услугу. Например, при помощи HTTP протокола браузер отправляет специальное HTTP сообщение, в котором указано какую информацию и в каком виде он хочет получить от сервера, сервер, получив такое сообщение, отсылает браузеру в ответ похожее по структуре сообщение (или несколько сообщений), в котором содержится нужная информация, обычно это HTML документ.

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

Предмет исследования ˗ клиент˗сервер.

Объект исследования ˗ Распределенные системы обработки информации

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

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

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

2. Создать систему разделения, которая по выбранным методам, создаст классы и методы для удалённого вызова и отредактирует первоначальный код их вызова.

ГЛАВА 1. РАСПРЕДЕЛЕННЫЕ СИСТЕМЫ ОБРАБОТКИ ИНФОРМАЦИИ

1.1 Характерные принципы функционирования модели «Клиент - Сервер»

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

Программы-серверы являются поставщиками услуг. Они постоянно ожидают запросы от программ-клиентов и предоставляют им свои услуги (передают данные, решают вычислительные задачи, управляют чем-либо и т.п.). Сервер должен быть постоянно включен и “прослушивать” сеть. Каждая программа-сервер, как правило, может выполнять запросы от нескольких программ-клиентов^[1].

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

Итак, в общих чертах система клиент-сервер выглядит так:

Есть компьютеры, контроллеры Ардуино, планшеты, сотовые телефоны и другие интеллектуальные устройства.
Все они включены в общую вычислительную сеть. Проводную или беспроводную - не важно. Они могут быть подключены даже к разным сетям, связанным между собой через глобальную сеть, например через интернет.
На некоторых устройствах установлены программы-серверы. Эти устройства называются серверами, должны быть постоянно включены, и их задача обрабатывать запросы от клиентов.
На других устройствах работают программы-клиенты. Такие устройства называются клиентами, они инициируют запросы серверам. Их включают только в моменты, когда необходимо обратиться к серверам.

Например, если вы хотите с сотового телефона по WiFi включать утюг, то утюг будет сервером, а телефон – клиентом. Утюг должен быть постоянно включен в розетку, а управляющую программу на телефоне вы будете запускать по необходимости. Если к WiFi сети утюга подключить компьютер, то вы сможете управлять утюгом и с помощью компьютера. Это будет еще один клиент. WiFi микроволновая печь, добавленная в систему, будет сервером. И так систему можно расширять бесконечно.

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

Поэтому простая передача данных в цикле, как мы передавали данные на компьютер в некоторых предыдущих уроках, в сложных сетях совершенно невозможна. Информация передается ограниченными порциями – пакетами. На передающей стороне информация разбивается на пакеты, а на приемной “склеивается” из пакетов в цельные данные. Объем пакетов обычно не больше нескольких килобайт.

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

Пакет состоит из заголовка и информационной части. Заголовок содержит адреса получателя и отправителя, а также служебную информацию, необходимую для “склейки” пакетов на приемной стороне. Сетевое оборудование использует заголовок для определения, куда передавать пакет.

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

Каждой точке подключения устройства к сети присваивается уникальный номер – IP-адрес (Internet Protocol Address). IP-адрес присваивается не устройству (компьютеру), а интерфейсу подключения. В принципе устройства могут иметь несколько точек подключения, а значит несколько различных IP-адресов.

IP-адрес это 32х разрядное число или 4 байта. Для наглядности принято записывать его в виде 4 десятичных чисел от 0 до 255, разделенных точками. Например, IP-адрес моего сервера 31.31.196.216.

Для того чтобы сетевому оборудованию было проще выстраивать маршрут доставки пакетов в формат IP-адреса введена логическая адресация. IP-адрес разбит на 2 логических поля: номер сети и номер узла. Размеры этих полей зависят от значения первого (старшего) октета IP-адреса и разбиты на 5 групп – классов. Это так называемый метод классовой маршрутизации.

1.2 Определение сервера и клиента

При большом числе компьютеров (десятки, сотни и даже тысячи) предприятия чаще всего полагаются на сети модели «клиент-сервер». Упрощенно можно считать, что в такой сети отдельный компьютер подключается к одному или нескольким мощным компьютерам, которые называются серверами^[2].

Сервер – это компьютер, или выполняющаяся на нём программа, которая предоставляет клиентам доступ к общим ресурсам и управляет этими ресурсами.

Клиент – пользователь (получатель) услуг и/или ресурсов, которые предоставляет сервер.

СЕРВЕР

Рисунок 1. Модель клиент-сервер

В серверных сетях серверы оснащены процессорами типа Intel Pentium 4 и сетевой операционной системой.

1.3 Роль сервера и клиента в архитектуре клиент-сервер

Роль серверов состоит в обеспечение централизованной защиты и управлении трафиком, а так же в предоставление клиентам ресурсов: информации, приложений и доступа к устройствам совместного пользования (например, к принтерам). В клиент – серверной среде в роли клиентов выступают настольные ПК (именно ПК, а не неинтеллектуальные терминалы) под управлением операционной системы типа Windows 95 или Windows NT Workstation. Как правило, клиент использует собственные вычислительные мощности для обработки информации, полученной от сервера, но полагается на сервер в части предоставления необходимых данных и приложений. Такое распределение ролей в обработке информации носит название клиентской (front - end) и серверной (back - end) обработки.

Наряду с успешным функционированием в собственной «родной» среде, сети модели клиент – сервер могут работать с микрокомпьютерами и мэйнфреймами. Именно эта гибкость в сочетании достаточно низкой (по сравнению с традиционными решениями) стоимостью и составляет привлекательность клиент – серверных сетей. Работая в такой среде на компьютере – клиенте, можно «вкушать плоды» трех разных методов обработки информации: автономной работы, взаимодействия с другими ПК сети и подключения к серверу или мэйнфрейму для доступа к хранящейся там информации^[3].

1.4 Понятие прикладных протоколов

Необходимо различать понятия сетевых приложений и протоколов прикладного уровня. Протоколы прикладного уровня являются частью (хотя и весьма большой) сетевых приложений. Рассмотрим два примера. Web является сетевым приложением, позволяющим пользователям получать web-документы по запросу и состоящим из множества компонентов, включая стандарт формата документов (HTML), браузеры (Netscape Navigator, Microsoft Internet Explorer и др.), web-серверы (например, Apache, Microsoft или Netscape), протоколы прикладного уровня. Протокол прикладного уровня для web носит название протокола передачи гипертекста (HyperText Transfer Protocol, HTTP) и описывает формат и порядок обмена сообщениями между клиентом и сервером (RFC 2646). Таким образом, HTTP является лишь частью web-приложения.

В качестве второго примера рассмотрим приложение электронной почты. Электронная почта Интернета также состоит из множества компонентов: почтовых серверов, содержащих почтовые ящики пользователей, программ для просмотра и создания электронных писем, стандартов, описывающих структуру электронных писем, протоколов прикладного уровня, регламентирующих порядок обмена сообщениями серверов между собой и с оконечными системами пользователей, а также интерпретацию полей, из которых состоят электронные письма. Основным протоколом прикладного уровня для электронной почты является протокол простой передачи сообщений (Simple Mail Transfer Protocol, SMTP). Как мы видим, SMTP (RFC 2821) — лишь часть (хотя и достаточно большая) структуры приложений электронной почты^[4].

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

□ типы используемых сообщений, например запросы и ответы;

□ синтаксис каждого из типов сообщений, описывающий поля сообщения и их разделители;

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

□ правила, описывающие события, которые вызывают генерацию сообщений.

Некоторые из протоколов прикладного доступа (HTTP, SMTP и др.) являются официально документированными в RFC. Это означает, что если разработчик нового браузера будет следовать стандарту, то браузер сможет получать документы с любого web-сервера, построенного по этому же стандарту. Тем не менее существует множество протоколов прикладного уровня, которые не стандартизированы и при этом используются для поддержки коммерческих продуктов. В частности, это характерно для Интернет-телефонии.

1.5 Представление данных в системах обработки данных

Самым простым из таких способов является опрос (англ. polling). Способ основан на постоянном обращении клиента к серверу за новой информацией (рисунок 1). Клиентский код, выполняемый в браузере пользователя, с заданной временной периодичностью отправляет запрос, опрашивая сервер о наличии событий. Сервер формирует ответ для каждого запроса и отправляет его обратно клиенту. В случае отсутствия новых данных, сервер также сообщает об этом. Запрос к серверу выполняется с использованием подхода AJAX, что подразумевает обмен данными в «фоновом» режиме без полной перезагрузки веб-страницы.

Рисунок 1. Опрос (polling)

К очевидным недостаткам такого подхода следует отнести следующие:

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

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

К таким техникам относится другой способ обмена сообщениями, называемый длительный опросом (англ. long polling). После загрузки веб-страницы, клиентский код выполняет запрос, но сервер не отвечает и не закрывает соединение, пока не появятся новые данные или пока клиент не отключится самостоятельно. Как только данные появились – отправляется ответ и соединение закрывается. После чего клиент сразу же отправляет следующий запрос, снова запуская процесс ожидания (рисунок 2).

Рисунок 3. Длинный опрос (long-polling)

Достоинства этого метода по сравнению с классическим опросом (polling):

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

После создания объекта EventSource с указанием адреса подключения браузер отправит запрос на установление соединения серверу. Чтобы соединение успешно открылось, сервер должен ответить с HTTP-заголовком "Content-Type: text/event-stream" и не закрывать соединение. После этого сервер может отправлять в открытое соединение сообщения, когда появляется новая информация (рисунок 3).

Рисунок 4. Server-Sent Events

В Server-Sent Events включена возможность отправлять идентификатор сообщения, который помогает восстановить утраченные события в случае обрыва соединения. В поддерживающих стандарт браузерах доступен удобный событийно-ориентированный программный интерфейс (API) для обработки получаемых сообщений и ошибок.

После того как установлено соединение по протоколу WebSocket, сервер и клиент могут посылать друг другу сообщения, когда новая информация доступна на одной из сторон (рисунок 5). Таким образом, обеспечивается своевременная передача необходимой информации и поддержание ее в актуальном состоянии.

Рисунок 5. WebSocket

Протокол WebSocket подробно описан в RFC 6455 [3]. Здесь лишь отметим, что формат пакета (фрейма) данных имеет компактную структуру, обеспечивая минимум накладных расходов на передачу и повышая тем самым производительность. Кроме того, фреймы делятся на два больших типа: фреймы с данными и управляющие фреймы, предназначенные для проверки связи (ping) и закрытия соединения. Помимо передачи текстовой информации, фреймы с данными могут содержать и бинарные данные.

ГЛАВА 2. СРАВНИТЕЛЬНЫЙ АНАЛИЗ ТЕХНОЛОГИЙ ПОЛНОДУПЛЕКСНОГО СОЕДИНЕНИЯ МЕЖДУ КЛИЕНТОМ И СЕРВЕРОМ НА РАЗЛИЧНЫХ ЯЗЫКОВЫХ ПЛАТФОРМАХ

2.1 Технология Server Push

Вторая версия протокола передачи данных HTTP предоставляет функционал Server Push. Данная технология позволяет оптимизировать работу и время загрузки веб-страниц. Доступ к веб-сайтам по протоколу HTTP всегда осуществляется по шаблону «Запрос – ответ»: клиент (браузер) отправляет запрос на удаленный сервер, который с некоторой задержкой присылает ответ с запрошенным контентом.

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

Рисунок 6. Стандартный обмен данных в протоколе HTTP/1

Очевидным недостатком такого подхода является временная задержка между получением клиентом первоначального HTML-документа и остальных файлов, необходимых для корректного отображения веб-страницы. Технология HTTP/2 Server Push позволяет отправлять ресурсы клиенту до того, как тот явно их запросит. Например, если для корректного отображения веб-страницы необходим внешний файл с таблицей стилей some-styles.css, веб-сервер может передать этот файл клиенту сразу после того, как он начал передавать изначальный HTML-документ.

Рисунок 7. Обмен данных с используя технологию Server Push протокола HTTP/2

2.2 Технология Multiplexing

HTTP/2 - это бинарный протокол. Каждому HTTP/2 запросу и ответу присваивается уникальный идентификатор, называемый “идентификатор стрима”, и каждый запрос и ответ разделяется на фреймы. Идентификатор стрима используется для определения, к какому запросу или ответу принадлежит фрейм. Стрим - это набор фреймов с одинаковым идентификатором.

Чтобы отправить запрос серверу, клиент разделяет запрос на бинарные фреймы и присваивает идентификатор стрима каждому фрейму. Затем клиент устанавливает TCP соединение с сервером, после чего начинает отправку фреймов. Сервер также отправляет ответ фреймами.

Возможность разбить HTTP запрос на независимые фреймы, расслоить их, и собрать воедино на другом конце - очень важное нововведение HTTP/2.

2.3 Технология Server-Sent Events

SSE - технология, позволяющая осуществлять передачу данных в формате text/event-stream с сервера на клиент в одностороннем порядке без дополнительных запросов от браузера и не закрывая соединение. Для получения таких событий на клиенте используется интерфейс EventSource. Основная разница с методом Polling - последний создает новое соединение на каждый запрос. Server-Sent Events - события реального времени, в этом они схожи с протоколом WebSockets. Разница состоит в одностороннем порядке передачи данных, тогда как WebSockets позволяет отправлять данные с клиента на сервер. SSE имеет ряд преимуществ:

Если соединение прерывается, интерфейс EventSource “кидает” ошибку и автоматически пытается восстановить соединение. Также, сервер может контролировать время, после которого клиент попытается восстановить соединение.
Для передачи данных используется стандартный протокол HTTP.
Клиенты могут отправлять уникальный идентификатор с сообщениями. Когда клиент будет пытаться восстановить соединение, он будет знать идентификатор последнего сообщения. Таким образом, сервер может вычислить, какие сообщения не были доставлены на клиент, и отправить их.

Простейший пример клиентского кода:

// подписка на события

var source = new EventSource('http://somesite.com/events');

// обработка сообщений

source.onmessage = function(event) {

event.data; };

Каждый объект EventSource имеет свойства:

URL - передается в конструктор класса
Request - запрос, изначально равен null
ReconnectionTime - время на восстановление соединения, мс
LastEventID - идентификатор последнего события
ReadyState - состояния соединения (connecting/open/closed)

У технологии SSE есть ряд известных недостатков. Так, например, не все современные браузеры ее поддерживают. Также для Server-Sent Events отсутствует стандартный интерфейс для реализации передачи данных с приложениями на мобильных платформах, что приводит к неконсистентности кода между проектами и отсутствию единого подхода к разработке в сообществе. В сравнении с WebSocket, недостатком Server-Sent Events является ограниченность типа передаваемой информации, а именно возможность передачи только текста в кодировке UTF-8, тогда как по протоколу WebSocket возможна передача как текста любой кодировки, так и бинарных данных. Также существенным недостатком SSE является ограниченное количество возможных одновременно открытых соединений между клиентом и сервером. Это описано в самом протоколе. Для обхода этого недостатка авторы советуют использовать сложный механизм, который подразумевает использование уникального домена для каждого соединения, или же использовать один экземпляр объекта соединения EventSource с помощью технологии “shared worker”.

Для того, чтобы оценить тренды использования приведенных выше технологий, был использован веб-сервис http://npm-stats.org. В качестве объекта исследования были взяты две самые популярные в сообществе библиотеки для языка JavaScript для Server-Sent Events и WebSocket. В первом случае это библиотека sse, во втором socket.io. В качестве временной рамки исследования был выбран период с 1 мая 2017 года по 1 мая 2018 года.

Рисунок 8. Количество загрузок пакета SSE в неделю

Рисунок 9. Количество загрузок пакета SSE в месяц

2. Socket.IO

Рисунок 10. Количество загрузок пакета Socket.io в неделю

Рисунок 11. Количество загрузок пакета Socket.io в месяц

Как видно из графиков, количество загрузок пакета socket.io значительно превышает количество загрузок пакета sse. Так, например, за апрель 2018 года библиотека socket.io была установлена более семи миллионов раз, тогда как библиотека sse была установлена сто сорок тысяч раз. Также исходя из количества загрузок можно оценить текущую и дальнейшую тенденцию использования данных технологий. Обе библиотеки на апрель 2018 года находятся на пике количества загрузок, что говорит о том, что, скорее всего, популярность обеих технологий будет расти в дальнейшем.

ГЛАВА 3. КЛИЕНТ-СЕРВЕРНЫЙ ПОДХОД К ЗАЩИТЕ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМ ИНТЕРНЕТА ВЕЩЕЙ

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

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

Использование существующих программно-аппаратных платформ, таких как Arduino, Raspberry Pi, Digi XBee и др., традиционно применяемых для прототипирования систем Интернета вещей сопряжено с наличием уязвимостей в них, обусловленных особенностями самой платформы. В продемонстрирована незащищенность устройства Arduino Yun, построенного на базе двухуровневой архитектуре со средой выполнения Arduino на базе микроконтроллера ATmega32u4 и Linux-процессором и связующим компонентом. Arduino отличающаяся открытой, достаточно гибкой и расширяемой архитектурой (в том числе возможностью запуска требовательных к ресурсам и коммуникациям Linux-приложений на некоторых видах устройств), широкими и несложными в осуществлении возможностями прошивки устройств и подключения внешних электронных компонентов (RFID-сканеров, разнообразных сенсоров физической среды, многошаговых двигателей, модулей беспроводной связи и пр.), а также большим числом доступных программных библиотек и технической документации. В Alberca) показано, что обратной стороной открытости Arduino является ее подверженность ряду атакующих воздействий. В частности, на Arduino Yun возможна атака по компрометации ОС Linux путем эксплуатации уязвимостей на нижнем уровне прошивки (скетча), что возможно вследствие отсутствия аутентификации и выполнении с root-правами команд Linux, вызываемых из скетча через bridge-компонент. При этом если нарушитель получает неограниченный доступ к файловой системе Linux, то путем модификации системных файлов он способен влиять на параметры отображения IP-адресов и имен хостов, включение/отключение ssh-аутентификации, параметры и ключи Wi-Fi, идентификаторы процессов pid, изменять bridge-компонент, вносить изменения, которые будут сохраняться даже после возврата устройства к фабричным установкам.

Еще одним примером незащищенного устройства Интернета вещей является актуальная в настоящий момент серия 2 устройств Digi XBee, организующих беспроводную коммуникацию в сенсорных сетях с изменяемой топологией. Так, несмотря на наличие функции шифрования передаваемых пакетов при помощи протокола AES, в рамках протокола ZigBee шифруется лишь полезная нагрузка, тогда как структура самого пакета оказывается незащищенной перед MITM-атаками.

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

Решаемая в работе научная задача задается следующим формальным картежом: (S, A, P, R, C, f), где S – система Интернета вещей, включающая в свой состав множество встроенных устройств с заданным программно-аппаратным обеспечением; A – модель возможных атак на систему S; P – множество показателей, включающих, в том числе, показатели защищенности, оперативности, обоснованности и ресурсопотребления, а также показатель сложности атаки; R – множество требований к защите системы на основе показателей P; C – множество компонентов клиент-серверной защиты, выбранных и реализованных с использованием показателей P. Решаемая задача состоит в построении отображения f, которое на основе значений S, A и P позволяет получить набор компонентов клиент-серверной защиты C так, чтобы удовлетворить требования R. Отличительной особенностью данной постановки задачи осуществление выбора на специфичном наборе компонентов защиты с учетом заданной системы показателей, полученных с учетом анализа модели атак на систему Интернета вещей. Необходимость требований защищенности обуславливается набором специфичных атак из A, которым подвержена система. Важность требований оперативности связана с необходимостью в режиме, близком к режиму реального времени осуществлять противодействие атакам на систему. Выполнимость требований обоснованности определяют корректность срабатывания компонентов защиты с минимизацией ошибок первого и второго рода в процессе выявления атак. Важность требований ресурсопотребления непосредственно связана с производительностью системы и вынужденными материальными затратами на процесс защиты системы.

Модель атак включает перечисление и анализ следующих разновидностей киберфизических атакующих воздействий, включающих действия на физическом и программно-информационном уровнях и классифицируемых по типу объекта атаки – элемента целевой системы: (1) атаки на устройства на базе одноплатных компьютеров, таких как Arduino Mega, Raspberry Pi и др.; (2) атаки на мобильные устройства под управлением мобильных ОС; (3) атаки на коммуникационные модули – узлы сенсорной сети (такие как Digi XBee); (4) атаки на сенсоры (RFID-сканеры, сенсоры характеристик физической среды и др.); (5) атаки на актуаторы (многошаговые двигатели, электроприводные краны, ИК-светодиоды и пр.); (6) атаки на СУБД, серверы приложений, веб-серверы, располагающиеся на устройствах системы Интернета вещей с эксплуатацией уязвимостей из существующих баз уязвимостей (таких как база CVE) и уязвимостей нулевого дня; (7) атаки на протоколы взаимодействия устройств, пользователей систем Интернета вещей. Как правило, конкретная атака на систему Интернета веще включает выполняемые совместно воздействия на физические элементы системы и воздействие на ее программную часть, в том числе программные компоненты обработчики событий безопасности устройств и компоненты GUI. При этом, ввиду направленности работы на изучение программной составляющей атак, исключительно физические воздействия, такие как физическое разрушение устройства, его отдельных модулей, проводных каналов связи и др., оставим за пределами данного исследования. Для конкретной атаки показатель ее сложности определяется экспертно и принимает одно из следующих качественных значений на основе предположений об уровне компетенции злоумышленника, его целях, объемов доступных ему ресурсов и ценности атакуемых активов.

Построена комбинированная доменно-ориентированная модель защиты программной части устройств от атакующих воздействий для систем Интернета вещей. Отличия данной модели от существующих доменно-ориентированных представлений, в которых специфицируются проблемно-предметные домены для каждого защитного функционала (как например, домен защищенных коммуникаций, домен пользовательской аутентификации и пр.); данная модель представляет комбинированное представление доменов знаний, ориентированных на конкретные разновидности устройств системы. Так декомпозиция системы на отдельные устройства и их модули позволяет проанализировать атакующие воздействия на каждый из них в соответствии с построенной моделью атак, после чего отобрать и проанализировать лишь те их комбинации, которые могут приводить к критически-важным инцидентам информационной безопасности, возникновению которых нужно противодействовать и реагировать на них. Так, модель раскрывает следующую последовательность действий по моделированию средств защиты: S → R → C, где целевая система S, требования R и компоненты защиты C специфицируются с использованием языка XML. В отличие от существующих UML-моделей средств защиты, ориентированных на визуальный анализ с возможностью генерации базовых шаблонов для написания программного кода компонентов защиты, основанная на XML доменно-ориентированная модель ориентирована на комбинирование компонентов защиты в соответствии с показателями компонентов защиты (в т. ч. нефункциональными показателями) и сложностью каждой из возможных атак.

Разработаны следующие алгоритмы клиент-серверной защиты: (1) алгоритм мониторинга сетевого трафика устройств системы Интернета вещей на основе правил; (2) алгоритм проверки корректности структуры сетевых пакетов трафика между устройствами; (3) алгоритм сигнатурного анализа трафика.

В соответствии с алгоритмом (1) на коммуникационных портах устройств производится съем информации и ее отправка на сторону доверенного сервера в виде данных событий безопасности для их последующего группового анализа. При обнаружении какой-либо известной аномалии на основе анализа характеристик трафика (таких как число полученных пакетов на некоторый коммуникационный интерфейс, число открытых портов, на которые поступили данные) доверенный сервер производит уведомление о возможной инциденте компонента-диспетчера информационной безопасности системы. В качестве признаков атаки сканирования используется правило, фиксирующее получение 3–4 пакетов более чем на 10 открытых портов устройств системы. Подобные правила формулируются также для выявления DoS-атак, атак аномальной активности злонамеренного ПО на устройстве и др.

Алгоритм (2) применяется для проверки корректности структуры пакетов трафика между устройствами. Для каждого типа устройств сформированы шаблоны генерируемых на нем пакетов данных с указанием размеров и диапазонов некоторых ключевых полей, отклонения от которых могут быть признаками replay-атак, атак имперсонализации, инъекции злонамеренного или модифицированного трафика и пр. Алгоритм (3) построен на сигнатурном методе распознавания злонамеренного трафика с использованием аппарата конечных автоматов.

Разработаны модели и программные интерфейсы для построения инфраструктуры серверной части защиты систем Интернета вещей с использованием технологии Apache Hadoop на основе паттерна Map-Reduce. Выбор данной технологии для реализации облачных вычислений обусловлен необходимостью групповой обработки данных клиент-серверных алгоритмов защиты на стороне доверенного сервера. Программные интерфейсы включают наполнение методов map и reduce для алгоритмов анализа сетевого трафика между устройствами системы, тогда как модели задают способ распараллеливания обработки данных и их свертку в следующий кортеж <anomaly_type, devices, detected>, где anomaly_type – тип аномалии, devices – набор устройств, в трафике которых данная аномалия была обнаружена, detected – логическое значение, определяющее наличие или отсутствие данной аномалии. Данное программно-техническое решение ориентировано на применение bash-скриптов в качестве средств автоматизации.

Разработанные алгоритмы защиты были опробованы на примере фрагмента мобильной коммуникационной самоорганизующейся сети на базе устройств Digi XBee. Удаленный контроль состояния устройств программно-аппаратного прототипа системы подтвердил применимость предложенных методов для реализации функций проверки корректности систем Интернета вещей и, как следствие, повышения защищенности таких систем.

ЗАКЛЮЧЕНИЕ

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

В ходе данной научно-исследовательской работы были достигнуты все поставленные цели и связанные задачи исследования.

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

Биячуев, Т. А. Безопасность корпоративных систем: учеб. пособие / Т. А. Биячуев. – СПб.: СПб ГУ ИТМО, 2014. – 161 с.
Браун, С. Виртуальные частные сети : учеб. пособие / С. Браун. – М: Лори, 2015. – 481 с.
Романец, Ю. В. Защита информации в компьютерных системах и сетях: Учебное пособие / Ю.В.Романец, П.А.Тимофеев, В.Ф.Шаньгин. – М. : Ифра-М, 2015. – 304 с.
Дворский, М. Н. Техническая безопасность объектов предпринимательства : Учебное пособие / М. Н. Дворский, С. Н. Палатченко. – М. : А-депт, 2016. – 304 с.
Десницкий В.А., Котенко И.В. Формирование экспертных знаний для разработки защищенных систем со встроенными устройствами // Проблемы информационной безопасности. Компьютерные системы. - № 4. - 2015. - С. 35–41.
Abera T., Asokan N., Davi L. Invited: Things, trouble, trust: On building trust in IoT systems // Proceedings of 53nd ACM/EDAC/IEEE Design Automation Conference (DAC). - 2016. - Р. 1–6.
Alberca C., Pastrana S., Suarez-Tangil G., Palmieri P. Security analysis and exploitation of arduino devices in the internet of things // In Proceedings of the ACM International Conference on Computing Frontiers (CF '16). - 2016. ч Р. 437–442.
Desnitsky V., Chechulin A., Kotenko I., Levshun D., Kolomeec M. Application of a technique for secure embedded device design based on combining security components for creation of a perimeter protection system // In proceedings of 24th Euromicro International Conference on Parallel, Distributed, and Network-Based Processing (PDP 2016). - 2016. - Р. 609–616.
Kong L., Liu X. mZig: Enabling Multi-Packet Reception in ZigBee // In Proceedings of the 21st Annual International Conference on Mobile Computing and Networking (MobiCom '15). - 2015. - Р. 552–565.
Madakam S., Ramaswamy R., Tripathi S. Internet of Things (IoT): A Literature Review // Journal of Computer and Communications. - vol. 3. - 2015. - Р. 164–173.
Shapsough S., Qatan F., Aburukba R., Aloul F., Al Ali A. R. Smart grid cyber security: Challenges and solutions // In proceedings of 2015 International Conference on Smart Grid and Clean Energy Technologies (ICSGCE). - 2015. - Р. 170–175.
Villari M., Al-Anbuky A., Celesti A, Moessner K. Leveraging the Internet of Things: Integration of Sensors and Cloud Computing Systems // International Journal of Distributed Sensor Networks. - vol. 12. - № 7. – 2016, Р. 1–4.
Vylegzhanina V., Schmidt D.C., White J. Gaps and future directions in mobile security research // In Proceedings of the 3rd International Workshop on Mobile Development Lifecycle (MobileDeLi 2015). - 2015. - Р. 49–50.

Биячуев, Т. А. Безопасность корпоративных систем: учеб. пособие / Т. А. Биячуев. – СПб.: СПб ГУ ИТМО, 2014. – 161 с. ↑
Браун, С. Виртуальные частные сети : учеб. пособие / С. Браун. – М: Лори, 2015. – 481 с. ↑
Романец, Ю. В. Защита информации в компьютерных системах и сетях: Учебное пособие / Ю.В.Романец, П.А.Тимофеев, В.Ф.Шаньгин. – М. : Ифра-М, 2015. – 304 с. ↑
Дворский, М. Н. Техническая безопасность объектов предпринимательства : Учебное пособие / М. Н. Дворский, С. Н. Палатченко. – М. : А-депт, 2016. – 304 с. ↑