Именно поэтому мы не используем в работе базу данных для хранения 2 компонентной системы накопления ошибок (тезаурус безопасности). При разработке sql-модели вводится большое количество таблиц и это не позволяет работать с данными через логику взаимодействия онтологий, оставляя только запросы на выборку данных, которые в свою очередь, получаются очень ресурсоемкими. Некоторые данные вообще невозможно представить с помощью реляционной алгебры, и они хранятся в базе в таком виде, что в дальнейшем требуется дополнительная программная обработка. Например, при описании уязвимости список продуктов, совокупность которых может привести к возникновению уязвимости, формируется с использованием логических операторов OR и AND. Список продуктов может быть любой длины. Пример структуры xml такой уязвимости показан на рисунке 5.

Рис.5. Пример представления уязвимости по стандарту CVE



На рисунке 6 изображена форма хранения уязвимости в программе Protege.

Рисунок 6. Пример класса уязвимости, реализованного в программе Protege

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

Для хранения онтологий был разработан репозиторий на базе сервера Virtuoso от компании OpenLink Software, который поддерживает как реляционную СУБД, так и хранилище триплетов тезауруса безопасности. В качестве основы для манипулирования данными используется сервис-ориентированная архитектура (SOA). Она реализует множество веб-сервисов для доступа к данным в репозитории.

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

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

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

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

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

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

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

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

Рассмотрим алгоритм, предложенный в работе: "Proposition of a Method for Assessing Similarity between Two Ontologies" за авторством Ngom A. и Kamara-Sangare F [37].

Данный алгоритм состоит из 5 шагов:

1. Определение наборов (O₁\O₂), (O₂\O₁), (O₁/\O₂), где On - это онтология; n - это индекс объекта.

2. Оценка меры семантической близости между понятиями каждого набора, определенного на шаге 1.

3. Расширение онтологии O₁ и O₂, используя набор O₁/\O₂. На этом шаге, для каждого понятия с из O₁/\O₂ мы ищем их потомков x_i(i прин N) в O₁ (соответственно в O₂) и добавляем их как потомков понятия с в O₂ (соответственно в O₁), если они не существуют в этой онтологии.

4. Далее, определяем O'₁?O'₂, которые представляют собой набор общих понятий 2 онтологий O'₁ и O'₂.

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

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

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

,



где n_i- количество понятий О_i, добавленных для расширения O_j.

Коэффициент целостности () онтологии O₁ вычисляется по формуле:

Коэффициент целостности () онтологии O₂ вычисляется по формуле:

Для вычисления меры похожести между отдельными элементами онтологий используется метод, предложенный в работе [18,19], вычисления выполняется в соответствии со схемой, представленной на рисунке 7.

Рисунок 7. Иллюстрация меры похожести понятий.



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

где c₃- это наиболее близкий общий родитель.

Таким образом, для оценки сходства между онтологиями используются наборы (O₁\O₂), (O₂\O₁) и (?), то есть различия между онтологиями O₁ и O₂ рассматриваются с помощью наборов (O₁\O₂), (O₂\O₁), а сходство между двумя онтологиями - с помощью набора(?).

Мера близости обладает следующими свойствами:

1. Симметрична, то есть = .

2. Находится в промежутке от 0 до 1.

3. Если , то

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

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



Глава 2. Проектирование безопасной архитектуры предприятия

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

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

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

Кроме того, требуется изучение всего процесса управления безопасностью, для всех существующих методов и моделей работы компании. Поэтому, прежде чем приступить к проектированию архитектуры предприятия и выделения универсальных элементов, необходимо проанализировать ряд источников и возможностей, полученных в том числе экспериментальным путём над онтологией, в том числе и в программно-ориентированном анализе структуры. Далее - исследовать предметную область безопасности и рассмотреть возникающие в ней риски для архитектурного проектирования. Управление рисками или риск-менеджмент - это процесс принятия и выполнения управленческих решений, направленных на снижение вероятности возникновения неблагоприятного результата и минимизацию возможных потерь, вызванных его реализацией (Боровкова В.А.). Выделяют четыре различных стратегии управления рисками:

1. методы уклонения от риска (отказ от рискованных проектов, работа только с надежными контрагентами);

2. методы локализации риска (контроль наиболее опасного участка деятельности, источника риска);

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

4. методы компенсации риска (применение механизмов предупреждения опасности).

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



Боровкова В.А. разделяет процесс принятия решения в ситуации риска на 8 этапов (см. рис. 8):

Рисунок 8. Процесс принятия решения в ситуации риска

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

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

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

В подходе к управлению рисками ROPE предлагается трехслойная модель (см. рис. 9), состоящая из слоя бизнес-процессов, описывающих деятельность, слоя CARE (Condition, Action, Resource, Environment) - компонентов деятельности (условия, действия, ресурсы, среда) (см. рис. 10) и TIP (ThreatImpactProcess) слоя, охватывающего угрозы, которые могут повлиять на деятельность, и контрмеры, которые могут смягчить последствия реализации рисков.

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

CARE диаграммы используются для совершенствования бизнес-процессов, основываясь на концепции ROPE. Отношения между CARE элементами выражаются линиями, которые определяются траекторией зависимости между элементами.

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



Рисунок 9. Трехслойная модель ROPE

Рисунок 10. Слой CARE в методологии ROPE

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

TIP диаграммы имеют три основные области применения:

1. поддержка при идентификации потенциальных рисков;

2. документирование и визуализация рисков;

3. определение влияния рисков с помощью моделирования.

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

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

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

Подпроцесс выявления угроз является итеративным и состоит из следующих стадий:

1. Стадия оценки. Идентификация угроз как основа для инициирования определенного набора реакций. Тип выявления определяет применяемые ответные меры.

2. Стадия применения ответных мер. Активация подпроцесса применения ответных мер.

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

1. составление базы данных угроз;

2. автоматический подбор мер по устранению рисков для соответствующей архитектуры инфраструктуры предприятия).

Подпроцесс применения контрмер состоит из следующих стадий:

1. Стадия оценки. Ситуация оценивается относительно выявленной угрозы и степенью влияния на функционирование CARE элементов.

2. Стадия применения контрмер. Выполняется минимизация влияния угроз.

3. Восстановительная стадия. Выполняется восстановительный подпроцесс.

Основная цель восстановительного подпроцесса - это восстановление функционирования CARE элементов. Этот процесс делится на краткосрочные и долгосрочные меры восстановления. Краткосрочные меры обеспечивают минимальную функциональность CARE элементов. Долгосрочные меры отвечают за восстановление полной функциональности CARE элементов.

Восстановительный подпроцесс:

1. Оценка. Выявление причин влияния на CARE элементы. Выбор требуемых восстановительных мер зависит от степени влияния угроз на функционирование CARE элементы.

2. Стадия восстановления. Применение выбранных краткосрочных и долгосрочных восстановительных мер.

В настоящий момент времени, ROPE поддерживает два подхода к моделированию: первый - TIP анализ, второй - моделирование влияния угроз на состояние CARE элементов.

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

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

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

1. угрозы устранены и CARE элементы функционируют;

2. угрозы устранены и CARE элементы не функционируют;

3. угрозы не устранены и CARE элементы не функционируют;

4. угрозы не устранены и CARE элементы функционируют.

Четвертое состояние «Угрозы не устранены и CARE элементы функционируют» возникает только как временное в процессе моделирования, так как мы предполагаем, что угрозы всегда влияют на состояние CARE элементов.

Итак, моделирование влияния угроз позволяет, во-первых, определить как изменится состояние CARE элементов и, во-вторых, определить дополнительное время и затраты, которые потребуются в результате выполнения мер по восстановлению состояния поврежденных CARE элементов.

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

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

На сегодняшний день широкое практическое применение получил подход к управлению рисками Risk-Aware Business Process Management. Данных подход к моделированию и управлению рисками основывается на проходе по всем стадиям жизненного цикла риск-безопасного моделирования (рис. 11). Исследуемый процесс моделируется с учетом возникающих рисков, риски уточняются, оцениваются и контролируются, выявляются меры по предотвращению риска.

Рисунок 11. Жизненный цикл R-BPM



2.1 Архитектура ПО и методика проектирования

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

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

Описание архитектуры программного обеспечения основано на двух методах моделирования: моделирование архитектуры программного обеспечения на основе компонентов (архитектурные компоненты), описанные в языках описания архитектуры ADLs (Клементс и др. 2002; Медвидович, Тейлор, 2000) и объектно-ориентированное моделирование, где используется унифицированный язык моделирования (UML) (Jacobson и др. 1992; Booch, Рамбо, Якобсон, 1998 ; Object Management Group, 2001). Оба метода моделирование последовательно декларируют методологию: «Object-based Software» архитектуры (OBSA) и Архитектуры программного обеспечения на основе компонентов (CBSA) (Khammaci, Smeda, Oussalah, 2005).

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

В этой части представим наиболее популярные языки описания архитектур ПО. Лидером отрасли является UML, особенно начиная с версии 2.0 (Object Management Group, 2004a ; Pilone, Питман, 2005). Наиболее распространённым форматом межпрограммного взаимодействия остаётся - стандарт - XML, который используется для представления XML-файлов, которые способствуют обмену данными об объектах внутри программ и сохраняют устойчивость утилит-конверторов.

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

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

Рисунок 12. Метамодель программной архитектуры



Компонент - это вычислительный объект или объект хранения данных, определяющий контракт (спецификацию использования) для всех его интерфейсов (предоставляемых и требующихся). Можно развернуть программный компонент независимо в виде отдельно-взятого модуля, куда третьи лица могут добавить свой дизайн переопределения программного поведения приложения-модуля (Garlan, Taylor, 1997).

Из этого определения следует:

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

2. Программный компонент может быть развернут независимо (установка на различные платформы, сотрудничество с другими комплектующие),

3. Компонент может быть типизирован и может иметь формальную семантику или быть не определён в явной форме. Он может экспортировать ограничения использования и представить функциональные или нефункциональные свойства.

Интерфейс является видимой частью компонента. Интерфейс компонента состоит из набора взаимодействий между другими компонентами и его средой работы, которые позволяет формировать систему служб процессов, внутри которой работает компонент. В объектных подходах услуги задаются как методы, а затем как интерфейс связи, построенный для инкапсуляции этих служб. Этот интерфейс состоит из набора портов, привязанный к службе, которая определяет поведение, которое должно быть достигнуто при её вызове. Можно выделить два типа портов: служебные порты (предоставляемые), которые экспортируют службы компонентов и порты требования, которые импортируют службы к компонентам.

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

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

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

Примеры соединителей включают простые формы взаимодействия, такие как туннели, процедурные вызовы, и выдача событий-нотификаций для приложений, работающих в рамках одной среды и совместимости. Соединители также могут представлять возможности для сложных взаимодействий (SQL-процедуры между базами данных и серверами приложениий) (Garlan, Монро, Wile, 2000).

Новые соединители могут быть указаны так же, как и компоненты. Например, можно указать соединители для реализации протокола конкретных коммуникаций. Медвидович (Medvidovic, Taylor, 2000) классифицировал услуги взаимодействия, предлагаемые разъемы в четырех типах. Каждый тип соединителя предлагает одну или несколько услуг взаимодействия. Эти услуги включают:

1. Службы связи,

2. Службы координации,

3. Служба преобразования: при необходимости преобразует межкомпонентные взаимодействия.

Он позволяет гетерогенным компонентам взаимодействовать. Неопределённый протокол взаимодействия - это основное препятствие в составе крупных систем. Услуги преобразования позволяют компонентам, которые не были специально разработаны для работы друг с другом, устанавливать и проводить взаимодействия по связи.



2.2 Паттерны проектирования архитектуры предприятия и язык описания компонентов безопасности и фреймворк TOGAF

Стандарт TOGAF был разработан The Open Group в 1995г., последняя версия TOGAF 9.1 вышла 2011 г.TOGAF - концепция, описывающая комплексный подход к планированию, разработке, реализации и управлению архитектурой предприятия. TOGAF используется такими крупными консалтинговыми организациями как Oracle, Accenture, SAP, IBM, HP, Capgemini и другими компаниями. При этом TOGAF находится в свободном доступе, а значит может быть использован любой организацией бесплатно под соответствующей лицензией.

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

TOGAF состоит из четырёх архитектурных доменов:

1. бизнес-архитектура (описывает ключевые бизнес-процессы, стратегию развития бизнеса и принципы управления);

2. архитектура уровня данных (определяет логическую и физическую структуру данных в организации);

3. архитектура уровня приложений (описывает интерфейсы приложений и способы их применения в терминах бизнес - сервисов);

4. технологическая архитектура (определяет программную, аппаратную и сетевую инфраструктуры).

Главными составными частями TOGAF являются[17]:

1. ADM-методика (Architecture Development Method), описывающая процесс разработки архитектуры;

2. руководства и методики проектирования для ADM;

3. фреймворк архитектурного описания (Architecture Content Framework), являющийся детально проработанной моделью результатов разработки;

4. архитектурный континуум организации (Enterprise Continuum), в виде репозитория архитектурных артефактов и реализаций;

5. эталонные модели TOGAF (TOGAF Reference Models);

6. фреймворк, описывающий структуру организации, её персонал, требуемые роли и уровни ответственности (Architecture Capability Framework).

Центральным элементом TOGAF является методология внедрения архитектуры (ADM), которая совмещает в себе как элементы онтологии, то есть определение основных элементов структуры и их взаимодействие, так и элементы методологии, то есть последовательность разработки, внедрения и поддержания архитектуры в актуальном состоянии.

Основные шаги TOGAF включают (см. рис. 13):

1. Этап 0: предварительная фаза.

2. Этап А: разработка видения архитектуры, включающее границы проекта, план работ, подход к проектированию, общее представление архитектуры.

3. Этап В: разработка бизнес-архитектуры предприятия.

4. Этап С: разработка архитектуры данных и архитектуры приложений.

5. Этап D: разработка технологической архитектуры.

6. Этап Е: проверка возможности реализации предложенных решений.

7. Этап F: планирование перехода к новой системе.

8. Этап G: формирование системы управления преобразованиями.

9. Этап Н: управление изменением архитектуры.



Рисунок 13. Методология внедрения архитектуры (ADM)

TOGAF предлагает собственную метамодель архитектуры (см. рис.14). Метамодель отражает состав элементов, а методология показывает преобразование этих элементов в процессе разработки и внедрения архитектуры. Метамодель может дополняться отдельными артефактами, позволяющими выстроить расширенную версию на основе базовой версии, которая будет отражать не только состав элементов, но и их взаимоотношения.

Архитектура информационных систем состоит из 2 архитектур: данных и приложений. Архитектура данных, в свою очередь, включает:

1. объекты данных;

2. логические компоненты данных;

3. физические компоненты данных.



Рисунок 14. Метамодель TOGAF

Не смотря на проработанность данной методики, TOGAF имеет и ряд следующих недостатков:

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

2. TOGAF не так детализирован, как другие методологии, особенно в сфере взаимодействия бизнеса и технологий.

2.3 Онтологический подход к проектированию, средствами Archimate

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

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

Количество инцидентов по инфраструктуре и связи - показатель призван фиксировать количество инцидентов по инфраструктуре и связи. Целевое значение показателя - 0.

Общая неработоспособность рабочих мест пользователей по инцидентам по инфраструктуре и связи - в связи с зарегистрированными инцидентами, производится подсчет часов простоя рабочих мест пользователей. Целевое значение показателя - 0.

Количество инцидентов по АСУТП - показатель призван фиксировать количество инцидентов по АСУТП. Целевое значение показателя - 0.

Общая неработоспособность рабочих мест пользователей по инцидентам АСУТП - в связи с зарегистрированными инцидентами, производится подсчет часов простоя рабочих мест пользователей. Целевое значение показателя - 0.

Для решения поставленной задачи, необходимо спроектировать архитектурные артефакты, разделённые в рамках стандарта TOGAF на 3 слоя: бизнес-слой, слой информационных систем и технологический слой обеспечения. При проектировании необходимо учитывать специфику мета-онтологической модели, разработанной в главе 1. А именно, логическое ядро онтологии концептуальной схемы предполагает постоянный мониторинг угроз безопасности, а также гибкую стратегию реагирования. В связи с чем, необходимо спроектировать некоторые сервисы безопасности, пригодные для широкого профиля фирм с разной предметной областью. Такие микро-сервисы имеет смысл интегрировать в сетевую инфраструктуру, размещая их на серверах приложений, баз данных и за сетевыми экранами безопасности.

Концептуально сервисы не должны представлять из себя реализацию антивирусного программного обеспечения, дублируя функционал эвристического анализатора, а быть, скорее, на подобии репозитория, хранящего онтологическую модель предприятия, вкупе с триплетами угроз. Такая система имеет некоторое сходство с Common Vulnerabilities Scoring System, однако CVSS-метрики не могут охватить все варианты угроз, а особенно человеческий фактор самих сотрудников предприятия, халатность, неосторожность, нарушение корпоративных подходов и так далее.

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

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

Рисунок 15 Вариант серверной виртуализации от компании Sun

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

Определим все возможные бизнес артефакты для работы над проектированием. Некоторые из них могут дублироваться из-за особенностей работы платформы archi. Бизнес артефакты могут быть представлены не только бизнес процессами, но и ролями и объектами. Затем определим артефакты уровня приложения, мотивации, а также аппаратного уровня.

Сгенерировов 78 артефактов в веб представлении и получив доступ к движку запросов sql - alasql (см. рис. 16), мы можем определить все возможные бизнес - артефакты. Alasql написан на javascript и работает в браузере для организации поиска по xhml файлам представления артефактов.

Рисунок 16. Сгенерированное представление модели на xhtml.

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

Рисунок 17. Сводная функциональная модель управления предприятием.



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

На рисунке 18 изображен пример ИТ-инфраструктуры.

Рисунок 18. ИТ-инфраструктура.

На рисунке 19 изображено совмещённое представление архитектуры для разных видов.

Рисунок 19. Представление архитектуры предприятия по всем видам артефактов.



Остальные диаграммы, описывающие архитектуру подробнее можно найти в приложении 1.



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

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

Система управления базой данных графов (далее - база данных графов) - это cистема управления данными с методами Create, Read, Update и Delete (CRUD), которые представляют модель данных графа. Графовые базы данных обычно создаются для использования с действующими в той же части сети OLTP-системами. Соответственно, они обычно оптимизированы для высокопроизводительных транзакций и спроектированы с учётом необходимой целостностью всех операций над данными. Важной частью систем графовых данный является обеспечение программно-ориентированной эксплуатационной доступности данных в ОЗУ ЭВМ.

Есть два свойства графовых баз данных, которые необходимо учитывать при исследовании технологии графовых баз данных:

1. Базовое хранилище графов;

2. Процесс-ориентированный движок для работы с графами напрямую.

Некоторые графические базы данных используют собственное хранилище графов, которое оптимизировано и разработано для хранения и управления онтологиями, однако не все технологии баз данных графов используют собственный граф для хранения данных вида ключ-значение. Некоторые из них сериализуют данные графа в реляционную базу данных, базу данных с ограниченным доступом или другое хранилище данных общего назначения. Некоторые определения требуют, чтобы база данных графа использовала смежные поля без индекса, что означает, что узлы физически «указывают» друг на друга в базе данных. Любая система управления базами данных, предоставляющая CRUD-операции для моделей данных графа подходит для реализации графовой базы данных.

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

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



Рисунок 20. Примеры технологий графовых БД.

Наиболее промышленно зрелым решением является продукт компании Neo4j - Neo4j Graph technology Stack, куда входит множество решений: Neo4j Database, Neo4j Aura DBaaS, Neo4j Desktop, Neo4j Bloom, Neo4j Graph Analytics и Cypher Query Language.

Произведём сравнение основных понятий реляционных баз данных и графовых решений (см. табл. 3).

Таблица 3. Сравнение понятий реляционных и графовых баз данных

Sr.No	RDBMS	Графовая бд
1	таблицы	диаграммы
2	Ряды	Вершины
3	Столбцы и данные	Свойства и его значения
4	Ограничения	Отношения
5	присоединяется	пересечение

К достоинствам проекта СУБД Neo4j можно отнести: кроссплатформенность (Windows, GNU/Linux, Solaris, OS X), открытость исходного кода (community edition), поддержку различных схем данных (schema-free and schema-optional) и наличие широкого спектра драйверов для поддержки самых разных языков программирования (.Net, Clojure, Elixir, Go, Groovy, Haskell, Java, JavaScript, Perl, PHP, Python, Ruby и Scala).

3.1 Основные возможности языка запросов Cypher.

Язык запросов Cypher изначально разрабатывался исключительно для платформы и СУБД Neo4j, в 2007 году. Позже появился проект openСypher, стандартизирующий семантику и возможности для использования языка за пределами нативной платформы.

Cypher - это язык запросов декларативных графов, который обеспечивает выразительные и эффективные запросы, а также обновление хранилища графов. Cypher является относительно простым, но все же очень мощным языком. Сложные запросы к базе данных можно легко выразить через Cypher. Будучи декларативным языком, Cypher фокусируется на ясности семантических выражений того, что необходимо извлечь из хранилища графов, а не на том, как получить «мета объекты». Это контрастирует с императивными языками, такими как Java, языками сценариев, такими как Gremlin или расширения JRuby. В Neo4j. ряд различных подходов опирается на сложившуюся практику экспрессивных запросов. Большинство ключевых слов, таких как WHERE и ORDER BY, основаны на SQL, часть подходов заимствуется из SPARQL. Некоторые элементы из конструкции языка были взяты из таких языков общего назначения, как Haskell и Python.

Cypher заимствует свою структуру из SQL - запросы строятся с использованием различных предложений. Эти предложения объединяются в цепочки и передают промежуточные наборы результатов между собой. Например, совпадающие переменные из одного предложения MATCH будут контекстом, в котором существует следующее предложение. Язык запросов состоит из нескольких различных предложений; они описаны ниже в этом разделе.

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

Любой запрос может вернуть данные. Запросы, которые обновляют граф, не должны возвращать что-либо, но они могут вернуть либо пустое значение, либо идентификатор запроса. После всех частей запроса приходит одно заключительная операция RETURN. RETURN не является частью какой-либо части запроса - это символ точки в конце запроса. Операция RETURN содержит три подпункта: SKIP / LIMIT и ORDER BY. Если вы возвращаете элементы графика из запроса, который только что удалил их, вы удерживаете в контексте выполнения указатель, который больше не является допустимым. Операции на этом узле будут не определены.

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

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

В Cypher шаблоны появляются в нескольких местах: в операциях MATCH, CREATE и MERGE и в выражениях, определяемых пользователем языка. Каждый из них более подробно описан в документации на официальном сайте.

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

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

Рёбра записываются в виде пары квадратных скобок, по аналогии с вершинами внутри скобок задаются доп условия. [e:ACTED] - связь типа ACTED.

Направление связи задаётся с помощью стрелок следующим образом: ()-[]->() или ()<-[]-() или ()-[]-() - для случая, когда направление связи не важно

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



3.2 Построение архитектуры предприятия, с помощью онтологического подхода.

Воспользуемся одним из языков программирования, поддерживаемым платформой Neo4j - C#. Для этого установим IDE: Visual Studio и создадим консольный проект для реализации логистического ядра нашей онтологии. Для полноценной поддержки технологии графовой базы данных нам потребуется установить в проект nuget-пакет с поддержкой драйвера Neo4j. Это можно сделать через обозреватель решений на рисунке 21.

Рисунок 21. Обозреватель решений С#-проекта.

В проекте появилась поддержка следующих пакетов для системы: поддержка сокетов, трэдов, словарей значений и безопасности соединений из приложений с графовыми базами данных. Установленный Nuget-пакет позволяет получить доступ к реализованному функционалу языка запросов Cypher, из под классов-обёрток, созданных с помощью С#.

Одним из основных минусов работы над архитектурой, используя С# является несовместимость .NET Framework c .NET CORE, который в свою очередь является кроссплатформенным решением. Кроме того, в последней стабильной версии драйвера для .NET от Neo4j не реализована возможность конвертации кода openCypher в Cypher.

Архитектура предприятия может быть любой, в зависимости от сектора экономики, но ко всем ним подходит реализация проекта, достигнутая средствами программируемого языка программирования - семейства Lisp. Благодаря поддержке всех парадигм программирования, а также в виду своей структуры данных: код как данные, Lisp может с лёгкостью подстраиваться под любую предметную область, а изменение кода не требует радикальных изменений архитектуры абстрактного уровня. Таким образом, реализовав абстрактное логическое ядро и драйвер поддержки технологии графовых баз данных: neo4j, возможно выполнить все требования к безопасной архитектуре любого предприятия, с минимальными изменениями, в виде дополнительный правок конфигурации ПО и структуры пользовательских данных.

Среди всего семейства наибольший интерес в аспетке промышленного программирования представляет Common Lisp с свободным компилятором - Steel Bank Common Lisp (sbcl). В состав SBCL входит компилятор, который по умолчанию большую часть кода компилирует в машинный код, хотя есть возможность использовать режим интерпретатора. Большая часть SBCL написана на Common Lisp и приблизительно 10% на Си. Чтобы скомпилировать SBCL, используется одна из поддерживаемых реализаций Common Lisp (в том числе и сам SBCL), которая компилирует SBCL, и затем уже эта новая скомпилированная версия компилирует саму себя.

SBCL поддерживает аппаратные платформы: x86, x86-64, PowerPC, SPARC, Alpha, MIPS, HPPA, ARM. Система реализована под Linux для всех поддерживаемых платформ, а также под ОС Windows, Mac OS X, NetBSD, OpenBSD, FreeBSD, DragonFly BSD, Debian GNU/kFreeBSD, Solaris на платформах x86 и x86-64.

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

Для облегчения доступа к базе данных Neo4j, напишем проект драйвера на языке общего назначения - Common Lisp. Для облегчения кодовой базы воспользуемся известным репозиторием и системой управления зависимостями проекта - Quicklisp. С помощью команды: " (ql:quickload package-name)" можно установить в проект любой доступный программный пакет. Для поиска пакета из под REPL среды можно выполнить команду: "(ql:system-apropos keywords)", где keywords - ваш поисковой запрос.

Для удобства проектирования драйвера к базе данных Neo4j необходимо настроить среду разработки. Самым часто-используемым вариантом может стать сконфигурированный для Lisp текстовый редактор Еmacs вместе с поддержкой режима работа Superior Lisp Interaction Mode for Emacs (SLIME) для организации полноценной замены IDE. Альтернативным вариантом может служить редактор vim с поддержкой системы SLIMV. Сконфигурировать редактор и подсистему REPL можно самостоятельно или же воспользовавшись готовым прессетом. Для удобства и обеспечения кроссплатформенности можно использовать проект - Portacle. Запускаемая среда Portacle по-умолчанию поддерживает работу с буферами, служащими по сути динамическими слоями состояния вашего проекта и инфраструктурных элементов, построенных вокруг него. На рисунке 22 изображена главное меню программы-среды Portacle.

...