Issn молодой учёныйМеждународный научный журналВыходит еженедельно 22 (156) Редакционная коллегия bГлавный редактор
 Скачать 4.99 Mb.
|
|
. #22 (156) . June 2017 137 Computer безграничный доступ служащих к хранимой информации. В своем понимании, риск — это возможность того, что произойдет какое-то негативное событие, имеющее свою оценку (размер возможного ущерба) и вероятность того, что он наступит. Риск информационной безопасности (ИБ) представляет собой возможность нарушения ИБ с неблагоприятными последствиями для организации С методологической стороны верным подходом к решению проблем ИБ является обнаружение элементов информационных взаимоотношений и заинтересованности этих элементов, которые связаны с использованием информационных систем (ИС). Обратной стороной использования современных информационных технологий являются угрозы информационной безопасности организации. Методика оценки рисков на соответствие информационной безопасности (ОРС ИБ) объектов аудита рассчитана для оценки автоматизированных ИС организаций на соответствие требованиями условиям нормативных документов. Целью методики ОРС ИБ является установление степени ИБ объектов аудита по разным сферам контроля, которая выражена в численной форме, а также определение в наибольшей степени проблематичных областей со стороны информационной безопасности. С учетом того, что оценка ИБ объектов аудита представляет собой сложную научную задачу, которая требует принятия во внимание множества разных аспектов, то максимально подходящей методикой решения задачи оценки является использование методов многокритери- альной оценки на основании иерархии признаков Для создания общего рейтингового списка формируется единая шкала степеней информационной безопас- ности. Данная методика аудита информационной безопасности обладает комплексным характером, многофункциональна и приспособлена к разным видам объектов при организации аудита информационной безопасности. Например, если есть необходимость принимать во внимание более подробную информацию об определенных аппаратных, а также программных продуктах эксперт производит оценку влияния на многофункциональные области системы ИБ. Методика ОРС ИБ состоит из трех основных стадий, каждая из которых состоит из блоков (см. рисунок Стадии I и II — являются наиболее значимыми, осуществление этих стадий производится экспертами в сфере информационной безопасности. Стадия I — формирование иерархий признаков. Он необходим для постройки системы признаков, которая может обеспечить учет совершенно всех главных аспектов требований, таких как международные, федеральные, а также отраслевые, затрагивающих ИБ компьютерных информационных систем (КИС. На этой стадии производится формировка направленности, по которой будет происходить оценка информационной безопасности КИС, в пределах направленности — разделы, в самих разделах будут созданы вопросы, те. требования. Стадия II — подготовка к экспертной оценке. Существует этапа данной стадии. Этап распределения (ранжирования) признаков. Этап формирования согласованных мнений экс- пертов. Этап распределения специализирован для размещения взвешенных показателям групповым признакам в каждой сфере контроля (область контроля, а также признакам степени соотношения внутри каждой группы. Для определения признаков применяются мнения экспертов, которые расценивают значимость разных признаков. В этой методике есть одна проблема, которая связана стем, что в разных случаях могут быть различными и разнообразными мнения экспертов. Именно для обнаружения, а также ликвидации результатов различных мнений экспертов, используется этап вычисления степени согласованности мнений экспертов. Стадия III — экспертная оценка, а также подсчет обобщенного признака по сфере контроля. Она необходима для осуществления аудита и получения оценок соответствия требованиями условиям нормативных доку- ментов. Индивидуальные показатели информационной безопасности компьютерных информационных систем основываются на оценке параметров информационной безопасности КИС с помощью контроля настроек информационных систем требованиям информационной безопасности. В этом случае может быть использован один из двух методов метод базового анализа метод углубленного (расширенного) анализа. В методе базового анализа критерий оценки — это соответствие либо несоответствие настроек компьютерных информационных систем требованиям информационной безопасности. В данной методе применяются вопро- сы-требования, которые позволяют напрямую произвести оценку соответствующего признака ИБ. Если они полностью удовлетворяют требованиям, то будет выставлено значение 1, в противном случае будет выставлено значение, если же частично удовлетворяет требованиям, будет выставлено значение в интервале от 0 до 1. Приме- тоде углубленного анализа необходимо использовать дополнительные данные, к примеру, о технических аспектах ИБ организации, которые были получены на стадии исследования экспертами, которые проводят аудит. На I стадии, стадии формирований иерархий признаков составляется иерархия признаков с 10 сферами контроля. Каждая из сфер контроля можно разделить на подразделы (разделы, которые характеризуются показателями групп PG xi (блок 1), где x — номер сферы контроля количество показателей групп (разделов) в сфере Уровень соответствия информационной безопасности по сферам контроля формируется обобщенными признаками по сферам контроля. Как говорилось ранее, каждая сфера контроля разделена на несколько подразделов, ко Молодой учёный» . № 22 (156) . Июнь 2017 г. 138 Информатика торые характеризуют разные аспекты информационной безопасности в рамках одной сферы контроля, те. формируют показатели групп. В следующем этапе в каждом подразделе строится комплекс характеристик соответствия информационной безопасности (KHS) (блок 2) — эти характеристики требований нормативных документов по информационной безопасности. В результате этих действий в каждой сфере контроля будет образована иерархическая система признаков. Эта методология организации иерархии системы признаков для каждой сферы контроля схематически изображена на рисунке В конечном итоге, комплекс характеристик соответствия информационной безопасности (KHS) сформиро- Рис. 1. Методика ОРС ИБ “Young Scientist” . #22 (156) . June 2017 139 Computer Science вываются показатели групп, в свою очередь показатели групп (PG) сформировываются в обобщенные коэффициенты по сферам контроля (OKSK), обобщенный показатель по области контроля (Далее на основании рассчитанных обобщенных коэффициентов по сферам контроля OKSK высчитывается итоговый показатель уровня информационно безопасности корпоративной информационной системы органи- зации. Данная методика аудита информационной безопасности обладает комплексным характером, многофункциональна и приспособлена к разным видам объектов при организации аудита информационной безопасности. Результаты, которые будут получены с помощью этой методики уровня соответствия информационной безопасности могут использоваться самостоятельно для анализа защищенности корпоративной информационной системы аудируемой организации, Литература: 1. Галицкий, А. В. Защита информации в сети — анализ технологий и синтез решений / А. В. Галицкий, С. Д. Рябко, В. Ф. Шаньгин. — М ДМК Пресс, 2004. — 616 с. Домарев, В. В. Безопасность информационных технологий. Системный подход / В. В. Домарев — К ООО «ТИД »ДС», 2004. — 992 с. Марков, ОН. Оценка соответствия информационной безопасности объектов требованиям нормативных документов / ОН. Марков, Е. В. Кусов, ЯМ. Гвоздик // Проблемы информационной безопасности. Компьютерные системы. — СПб.: ФГАОВО «Санкт-Петербургский политехнический университет Петра Великого, 2009. — С. Модификация архитектуры приложения, основанной на паттерне CQRS, для повышения производительности Агафонов Глеб Вадимович, аспирант; Розалиев Владимир Леонидович, кандидат технических наук, доцент; Орлова Юлия Александровна, доктор технических наук, доцент; Раюшкин Эдуард Сергеевич, студент Волгоградский государственный технический университет В работе рассматривается способ организации архитектуры приложения на основе паттерна CQRS. В основе архитектуры лежит разделение на write- и модели, которые используют SQL и NoSql базы Рис Иерархическая система показателей сферы контроля Молодой учёный» . № 22 (156) . Июнь 2017 г. 140 Информатика данных. Результатом применения архитектуры стало возможность масштабирования системы. В стуки система способна обрабатывать 700 тыс. запросов на чтение, а время отдачи данных в веб часть при такой нагрузке составляет 150 мс в среднем, что является хорошим показателем для высоконагруженного web- приложения. Ключевые слова CQRS, архитектура, приложение, масштабирование В течение нескольких лет мы разрабатывали информационный веб-портал для создания, распределения и назначения заказов. Сначала система была развернута внутри компании и пользователями являлись сотрудники, которые контролировали заказы. Заказы исходили только от одной компании. Внешние пользователи лишь могли получать информацию. Следующим этапом было масштабирование системы на нескольких заказчиков, что пропорционально увеличивало внешних пользователей. С увеличением количества пользователей портал перестал справляться с нагрузкой. В пике время отдачи данных в веб часть могло составлять 400–700 мс. После анализа было установлено, что узким местом оказалась реляционная база данных (Были проведены несколько оптимизаций) Проведена оптимизация скриптов выборки) Некоторые скрипты выборок были вынесены в хранимые процедуры SQL; 3) Была убрана ORM; 4) Была проведена оптимизация индексов. Все это некоторое время помогало, нов итоге было принято решение переводить систему на новую архитектуру. О CQRS паттерне Шаблон Command-Query Responsibility Segregation (CQRS) предлагает разделение работы с объектом (и это необязательно база данных) на Запросы (Query) и Команды. При этом необходимо соблюдать следующие правила Запросы возвращает данные и, что важно, никогда не меняют состояние объекта Команды изменяют состояние объекта, нов идеальном случае, не должны ничего возвращать. Из этого следует, что вовремя отсутствия Команд одинаковые Запросы гарантировано вернут одинаковый результат любое количество любых Запросов не изменят состояние объекта удаление Запроса из кода абсолютно прозрачно для объекта и не может дать побочных действий. Кроме того, подход, предлагаемый CQRS, позволяет сделать код приложения более понятным именно благодаря разделению Команд и Запросов. Соответственно, в дальнейшем такое приложение легче поддерживать и модифицировать. Но основным преимуществом применения CQRS является разделение хранилищ информации на два типа) Реляционное хранилище для Команд) Денормализованное хранилище для Запросов. Эволюция CQRS добавила использование пат- терна Event Sourcing (хранилище событий. Идея Event Sourcing в том, чтобы записывать каждое событие, которое меняет состояние приложения в базу данных. Таким образом получается, что хранится не состояние сущно- стей, а все события, которые к ним относятся. В обычной реляционной модели происходит манипулирование состоянием, оно храниться у в базе, и всегда есть возможность его посмотреть. В случае с Event Sourcing оперируем с состоянием сущности. Нов отличии от обычной модели это состоянием не хранится, а воспроизводится каждый раз при обращении. Большим преимуществом Event Sourcing является, то что используя его можно восстановить любое состояние системы. На рисунке 1 представлена типовая схема паттерна Проектирование архитектуры приложения При переходе на новую архитектуру важна была скорость самого перехода, а проектирование агрегатов занимало много времени, которое решено было сохранить. Как итог совместно с Event Store осталась реляционная модель данных. Event Store остался в пользование только как надежная синхронизация данных для Read модели. Далее встал вопрос каким образом из Event Store обновлять модель отвечает только за запросы ка значит, что применять Event в базу не является ее ответственностью. Для обновления Read DB был создан Event Service, который получал уведомление о новом Event, читал его си обновлял Read Следующий вопрос, который необходимо было решить надежность обновления Read DB. Использование Event Store поднимало надежность системы в том, что данные точно не будут потеряны. Но если в процессе выполнения операции в Write модели, после сохранения Event в Event Store, связь для обновления Read DB будет разорвана, то Read DB обновлена не будет. Поэтому для нотификации Event Service была выбрана очередь сообщений на основе сервиса RabbitMQ. RabbitMQ имеет два необходимы преимущества для проекта) Гарантированная доставка сообщения) Восстановление после потери связи Последний вопрос в каком виде хранить данные в Read DB. База данных для Read DB для простоты была выбрана “Young Scientist” . #22 (156) . June 2017 141 Computer Science MS SQL. База данных не имеет связей между таблицами, а вместо связей в таблицах хранятся значения. Таким образом происходит выигрыш в чтении, так как читаются плоские данные. Итоговая архитектура портала приведена на рисунке 2. Вывод Итогом новой применения новой архитектуры стало значительное увеличение нагрузки на приложение без увеличения времени ответа. Статистика показывает, что в сутки приходит в среднем 700 тысяч запросов данных, а среднее время ответа сервера составляло 150 мс. Ноу данной архитектуры есть и минусы Размер инфраструктуры увеличился в разы относительно многослойной, что увеличило затраты на проект Для обеспечения принципа согласованности в конечном счете в системе ожидается, когда данные обновятся в Read DB, что привело к увеличению на 20% времени обработки запроса на запись; Литература: 1. Greg Young — CQRS Documents by Greg Young Электронный ресурс // CQRS Documents. Режим доступа http://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf 2. Dominic Betts, Julĭn Dom̆nguez, Grigori Melnik, Fernando Simonazzi, Mani Subramanian, Foreword by Greg Young — Exploring CQRS and Event Sourcing Электронный ресурс // Режим доступа http://www.microsoft. com/enus/download/details.aspx?id=34774 3. Martin Fowler — CQRS Электронный ресурс // Режим доступа Рис Архитектура приложения, основанная на паттерне Рис Архитектура приложения Молодой учёный» . № 22 (156) . Июнь 2017 г. 142 Информатика Разработка программного модуля интеграции АТС с корпоративным порталом Селивестров Дмитрий Валерьевич, студент; Николаев Николай Александрович, студент Национальный исследовательский университет Московский институт электронной техники» С ейчас потребность в автоматизации различных процессов в компаниях стала обычным явлением. Уже становится трудно представить себе складской или бухгалтерский учет без использования специализированного программного обеспечения, торговые представители оформляют и отправляют заказы в офис прям с мобильного телефона или планшета, с помощью специального приложения. Достаточно большая часть заказов приходит с сайта уже в виде готовых к обработке документов. Но при этом взаимоотношения с клиентами, по крайней мере, в среднем и малом бизнесе, почему-то очень часто ведутся без внедрения систем автоматизации. Сотрудники компаний, работающих без использования каких-либо систем автоматизации, сами решают, как осуществлять фиксацию звонков и других видов взаимодействия с клиентами. Обычно информация о клиентах хранится одним из следующих способов запись на бумаге, электронные таблицы, запоминание информации, отсутствие фиксации. В результате возникает путаница и недопонимание среди работников компании, становится сложно определить кто должен работать стем или иным клиентом. Учет ведется только на уровне оплаченных услуг. Вследствие чего возникают трудности в проведении аналитического обзора работы целых отделов и сотрудников в частности, затрудняются работы с уже имеющимся контактами. В случае увольнения или болезни сотрудника, все его неоконченные переговоры и необработанные контакты компания может потерять, что также крайне нежелательно для эффективной работы с клиентами. Решить эти вопросы становится возможным, с помощью внедрения системы. Термин CRM образовался от английского словосочетания Customer Relationship Man- agement, переводится как управление взаимоотношениями с клиентами. система — это прикладное программное обеспечение для компаний, предназначенное для автоматизации стратегий взаимодействия с клиентами, в частности, для повышения уровня продаж, оптимизации маркетинга и улучшения обслуживания клиентов путем сохранения информации о клиентах и истории взаимоотношений сними, установления и улучшения бизнес-про- цессов и последующего анализа результатов. CRM-системы предназначены для решения следующих задач) Исключение потери потенциальных клиентов. Важно минимизировать вероятность пропуска входящего звонка или запроса. В малом и среднем бизнесе в России конкуренция очень высокая. Компаниями прилагаются значительные усилия для того, чтобы привлечь клиентов. На привлечения новых клиентов выделяется значительный бюджет по сравнению с другими затратами. И очень важно, чтобы все эти средства и усилия не пропали даром. Автоматизированные системы позволяют получить уверенность в том, что вложения принесут выгоду компании. Компания получит фиксацию каждого входящего звонка и запроса от клиента) Контроль работы сотрудников и стандартизация работы с клиентами. Без общей стандартизированной системы каждый сотрудник работает так, как он привык. Учет может вестись в электронных таблицах, записных книжках, ежедневниках. Также работники могут полагаться на собственную память или не производить никакой фиксации информации. Взаимодействие с клиентами происходит с использованием электронной почты или мобильного телефона. Из-за отсутствия единой базы клиентов и определенного формата общения сними трудно оценить контроль качества работы сотрудников. CRM- система почти полностью решает эту проблему. Информация обо всех входящих и исходящих контактах будет находиться водном месте, где она будет всегда доступна для последующего использования) Накопление статистической базы. Оно играет очень важную роль в стратегии успешного развития любого бизнеса. Благодаря использованию системы вся рабочая информация собирается водной общей базе в стандартизированном виде. В результате руководитель может анализировать статистику работы, составлять различные отчеты (многие из которых уже в готовом виде присутствуют в системах, те. анализировать работу и планировать последующую работу более осознанно) Интеграция с внешними сервисами и источниками данных. Например, интеграция системы с телефонией позволяет фиксировать все звонки, запоминать все новые контакты и анализировать качество работы колл- центра. На сайте аналитического агентства TagLine был представлен рейтинг наиболее популярных в России CRM- систем. Топ был сформирован по результатам опроса свыше 430 компаний. Первую строчку рейтинга заняла система Битрикс24, внедрением которой занимаются около 50% опрашиваемых. Битрикс24 — это система от отечественных разработчиков. Распространяется на платной основе, носу- ществует бесплатный вариант использования системы, в которой введено ограничение на число возможных пользователей и на использование некоторого функционала. Одной из самых востребованных функций на данный момент является телефония, практически любая CRM- система предоставляет возможность интеграции с различными рода автоматическими телефонными станция- ми(АТС). Отсутствие возможности фиксировать входящие и исходящие вызовы в системе является серьезным недо- статком. Задача интеграции с телефонией заключается в том, что нужно объединить работу автоматической телефонной станции и системы. В мире, в том числе ив России, все большую популярность набирает телефония, обслуживание которой производится с использованием специальных телефонных станций. IP АТС — это телефонная система, коммутирующая голосовые и видео вызовы посети. Голос и видео передаются как поток IP пакетов. Наряду с перспективными технологиями коммуникаций АТС предлагает отличное масштабирование ресурсов и повышенную надежность. Подключение к привычным аналоговым телефонным, цифровым или GSM линиям возможно с помощью опциональных недорогих дополнительного оборудования. Среди бесплатных IP АТС наиболее популярной в России является Asterisk. Ее архитектура состоит из отдельных модулей, что позволяет подключать в коммутационное поле практически любую бизнес-логику, написанную на различных языках программирования, или реализованную на собственном языке Существует два способа интеграции) Звонок совершается через веб-браузер пользователя. Обработка сигнала сперва начинается в веб-бра- узере, далее проходит через систему, после попадает в АТС. В такой реализации качество звука и скорость обработки звонка сильно зависит от используемого брау- зера и программной реализации системы) Телефония интегрируется со сторонним сервисом, например, Asterisk. При такой реализации система виртуальной телефонии строится на базе этих сервисов и к ней подключаются номера. После совершать все исходящие звонки и получать входящие можно будет через sip- телефоны, без использования браузера. При этом достигается более качественный уровень сигнала. Разрабатываемый модуль интеграции использует вторую схему интеграции. Взаимодействие АТС и модуля включает в себя два сценария. Первый сценарий — это совершение входящего вызова. На вход модуля поступает соответствующие входящему вызову данные, которые проходят валидацию для возможности их дальнейшей передачи на сохранение, и тип события, определяющий текущее состояние звонка. Второй сценарий — это совершение исходящего звонка, он аналогичен предыдущему сценарию. На рисунке 1 представлен результат проектирования архитектуры модуля. Стрелками изображены направления взаимодействия. Структуру модуля было решено разбить наследующие компоненты модуль работы с АТС отвечает за отправление управляющих команд телефонной станции модуль работы с CRM представляет сохраняемые данные и другие параметры запроса в формате JSON документа. Осуществляет отправку данных посредством Рис Структурная схема ПМ ИАП Молодой учёный» |