Технологии встраивания функций безопасности в бизнес-процессы Текст научной статьи по специальности «Компьютерные и информационные науки»

Технологии

А.Н. Приезжая

ТЕХНОЛОГИИ ВСТРАИВАНИЯ ФУНКЦИЙ БЕЗОПАСНОСТИ В БИЗНЕС-ПРОЦЕССЫ*

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

Ключевые слова: UML модель, встраивание функций безопасности, MDA, преобразование моделей, модель системы в защищенном исполнении.

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

* Работа выполнена при поддержке РФФИ, грант № 07-07-00236.

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

На практике совмещение разнородных требований вызывает определенные трудности, поэтому за последние годы были разработаны различные методы интеграции бизнес-технологий и технологий безопасности, в частности, были предложены методы разработки, основанные на технологии Model Driven Architecture (MDA).

Описание используемых технологий

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

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

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

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

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

При использовании технологии MDA фактически одновременно разрабатываются и изменяются сразу три модели (PIM, PSM и код), представляющие разрабатываемую систему с разных точек зрения и с различными уровнями детализации.

Основные разработки в области внедрения функций безопасности

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

- UMLSec «Secure Systems Development with UML», Jan Jurjens. В работе рассматривается применение стереотипов и других расширений UML для моделирования систем безопасности;

- SecureUML «SecureUML: A UML-Based Modeling Language for Model-Driven Security», Torsten Lodderstedt, David Basin, and Jürgen Doser. Разработана метамодель языка, предназначенного для моделирования доступов к системе на основе идеологии Role Based Access Control (RBAC - ролевая политика);

- UMLpac «UMLpac: An Approach for Integrating Security into UML Class Design», Matthew J. Peterson, John B. Bowles, Caroline M. Eastman. В данной работе предлагается отдельный уровень абстракции для моделирования функций безопасности.

Также в ряде статей рассматривается применение технологии MDA в контексте интегрированной разработки систем в защищенном исполнении, в качестве примера можно привести4,5:

- «Model Driven Security for Process-Oriented Systems», David Basin, Jürgen Doser;

- «Model Driven Security from UML Models to Access Control Infrastructures», Torsten Lodderstedt, David Basin, Jürgen Doser.

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

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

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

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

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

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

Рис. 1. Создание системы в защищенном исполнении

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

Преобразование бизнес-модели системы в модель системы в защищенном исполнении осуществляется в два этапа:

1. Разработка целевой платформы - модели системы защиты информации. Одна и та же модель СЗИ может применяться для множества бизнес-моделей.

Требования к СЗИ формируются в достаточно общем виде, так как на данном этапе стоит задача построения «общей» модели СЗИ, которая будет уточняться уже при формировании модели системы в защищенном исполнении применительно к требованиям

конкретной системы. Разработанная СЗИ должна предоставлять механизмы защиты от всех определенных обладателем информации угроз безопасности системы.

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

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

1. Модель преобразования.

2. Язык разметки модели.

3. Программное средство преобразования.

Для успешного применения программного средства преобразования бизнес-модель системы должна отвечать определенным требованиям.

1. Модель должна быть класс-ориентированной.

2. Система представляет собой распределенное web-приложение.

3. Модель рассматривается в двух представлениях: логическое (Logical View) и размещения (Deployment View).

4. Модель имеет три уровня представления:

а) приложения (Application);

б) бизнес-процессов (Business Services);

в) промежуточный уровень реализации (Middleware).

5. Также в модели существуют два дополнительных представления:

а) архитектурные механизмы (Architectural Mechanisms);

б) реализация прецедентов (Use-case Realization).

6. Динамическое представление системы показано на диаграммах последовательностей.

7. Требования безопасности могут быть сформулированы применительно к классам, а не к их экземплярам.

8. В модели существуют базовые классы:

а) ApplicationForm («стартовая» страница для приложения);

б) Middleware (базовый класс для языка реализации).

Инструмент преобразования, таким образом, не является абсолютно независимым, он жестко связан со структурой защищаемой системы.

Технология MDA предполагает наличие трех моделей, в рассматриваемом случае: бизнес-модели системы, модели СЗИ и модели преобразования. Модель преобразования представляет собой UML модель реализуемой трансформации, фактически она включает две взаимосвязанные модели:

- модель инструмента разметки. Инструмент разметки модели предназначен для обозначения «точек соприкосновения» объединяемых моделей. Данная модель предназначена для

автоматизированного создания программного средства разметки;

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

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

Пакет Configurations описывает структуру Property set (наборов свойств) разработанного инструмента. Эти свойства содержатся в спецификации объекта модели (класса, атрибута, операции, ассоциации) и описывают требования безопасности к конкретным объектам модели. Эти свойства определяют порядок трансформации модели.

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

- Class, для объектов, связанных с классами;

- Attribute, для объектов, связанных с атрибутами;

- Association для объектов, связанных с ассоциациями;

- Operation для объектов, связанных с операциями.

Класс со стереотипом AttributeSet определяет набор свойств объекта (Property Set), его атрибуты определяют свойства, составляющие этот набор. Имя сгенерированного набора совпадает с именем класса, без указания типа объекта. Например, по классу

SecurityAnalysis_Class будет создан набор свойств SecurityAnalysis.

В этот набор импортируются свойства из ассоциированных классов со стереотипом PropertyList.

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

По умолчанию к каждому элементу модели применяется набор свойств SecurityAnalysis. Этот набор свойств используется при разметке модели. Инструмент Security включает в себя также набор SecurityContext, этот набор применяется к модели системы в защищенном исполнении и определяет некоторые свойства безопасности.

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

На диаграммах классов пакета Patterns смоделированы элементы, внедряемые в бизнес-модель системы, т. е. классы, ассоциации, операции и их атрибуты. Каждый класс в этом представлении имеет атрибут for, определяющий свойство набора SecurityAnalysis, от значения которого зависит создание элемента. Также классы могут иметь атрибуты, определяющие свойства создаваемого элемента модели, например, name - его имя, stereotype - стереотип.

Создаваемые в процессе преобразования ассоциации показаны на диаграмме NewAssociation, каждая ассоциация смоделирована отдельным классом, имеющим ассоциацию с тем классом, с которым она и будет создана. То есть один конец ассоциации - класс со значением TRUE свойства, указанного в атрибуте for, а второй ассоциированный класс, если стереотип ассоциации «with», а если ее стереотип «with child», то ассоциация будет создана с его дочерними классами, в соответствии со значением поля, вынесенного в ква-лификатор.

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

На диаграмме KeyClasses смоделированы классы модели СЗИ, которые замещают классы бизнес-модели, т. е. точки сопряжения моделей. Классы этой диаграммы должны иметь значение TRUE в поле key_classes.

Как было сказано выше, в модели преобразования создаются классы, описывающие свойства набора SecurityAnalysis, используемые для разметки модели. Инструмент Security представляет собой список свойств безопасности, каждое из которых имеет некий «выпадающий» список значений. В качестве примера можно привести следующие свойства:

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

need_audit - данное свойство может принимать значение TRUE или FALSE (по умолчанию FALSE). Установленное значение TRUE означает, что данная операция может подвергаться аудиту;

audit_level свойство может принимать значение 1,2,3. Таким образом, минимальный уровень аудита соответствует значению 1,

базовый - 2, а детализированный - 3. По умолчанию установлен базовый уровень аудита;

need_crypto свойство - может принимать значение TRUE или FALSE (по умолчанию FALSE). Установленное значение TRUE означает, что данный элемент требует (или может потребовать) применения шифрования;

crypto_algoritm свойство - определяет применяемый алгоритм шифрования. По умолчанию DES;

userID_control - определяет, необходимо ли проверять соответствие пользовательского идентификатора идентификатору владельца;

import_associations - свойство, определяющее необходимость импортировать связи класса (определяет порядок трансформации), по умолчанию равно TRUE.

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

Генерация модели системы в защищенном исполнении - это, иными словами, связывание бизнес-модели системы и модели системы защиты информации.

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

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

Рассмотрим в качестве примера некоторую упрощенную систему учета рабочего времени, в частности операцию save (theTimecard : Timecard, theEmployee : Employee) сохраняющую карточку учета рабочего времени.

Operation Specification for save

General ] Detail 1 Exceptions I Preconditions

Semantics | Postconditions ] Files Security

S*: [ A Edit Set,,., |

Model Properties

" 1 Name | Value | Source 1

" onjsystem_start False Override

" import False Override

* need_audit True Override

' need_erypto True Override

~ need_hesh Tiue Override

* hash_with_time True Override

" needjogin True Override

' login False Override

SecurityAdmin False Override

System,-dmin False Override

* System False Override

' User True Override

" Admin False Override

' cjypto_algoritm DES Override

* hash_algoritm MDE Override

Operation 5 pec'fi cation for save

üeneral I Detail j Exceptons ] Precondtons

Semaiticä | Postconditions ] Files Secjnty

S* 1 Edt Sel... j

Mode Properties

' j Marne | Valus i Source 1 <»

~ 1 success True Ovemce

* 2succî$s True Ovem'ce

* 3succï$s True Ovemce

' lenor False Ovemce

* 2етог True Ovemce

Зетог True Ovemce

* loDaect True Ovemce

' 2o3iect True Ovemce

* 3o3iect True Ovemce

- lui True Ovemce

-......2u1........................ True Ovemce

' fuser True Ovemce

* 2usef True Ovemce

' 3user True Ovemce

~ audi evel 1 Ovemce

T user! С condnol True Ovemce

Рис. 2. Свойства безопасности операции save (theTimecard : Timecard, theEmployee : Employee)

Предположим, к операции save предъявляются следующие требования:

Операция save (theTimecard : Timecard, theEmployee : Employee) выполняется только по требованию пользователя соответственно on_system_start=FALSE. Вызывать операцию save (theTimecard : Timecard, theEmployee : Employee) могут только пользователи, прошедшие аутентификацию (need_login= TRUE, login=FALSE).

Сохранять или изменять карточку учета рабочего времени могут только работники, т. е. пользователи (RestrictedUser), соответственно значение TRUE имеет только свойство User, так как пользователь имеет право изменять только свою карточку учета времени - свойство userID_control=TRUE.

Так как карточка учета рабочего времени непосредственно связана с процессом начисления заработной платы работнику, все ее изменения должны фиксироваться (need_audit=TRUE). Данная операция подвержена аудиту на всех уровнях аудита: минимальном, базовом и детализированном (audit_level=1).

Так как операция save (theTimecard : Timecard, theEmployee : Employee) может быть вызвана любым пользователем платежной системы, возможна передача информации по открытым каналам.

Система должна гарантировать целостность карточки учета рабочего времени как при хранении в системе, так и при передаче по сети. Таким образом, при вызове операции save (theTimecard : Timecard, theEmployee : Employee) должно обеспечиваться шифрование при передаче по сети (need_crypto= TRUE, crypto_algoritm= DES), контроль целостности при передаче по сети (hash_with_time) при хранении (needhash) и используемый алгоритм хеширования hash_algoritm=MD5.

После применения скрипта преобразования класс PayrollDB Manager получает ряд дополнительных операций и связей, в частности операции generateEvent(), mtegrityControl(), HashWithTime, а также ассоциации с классами безопасности.

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

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

а) до преобразования;

Полученная модель системы в защищенном исполнении была проверена встроенными средствами IBM Rational Rose 2006 (проверка на соответствие модели правилам языка UML). Также была проведена проверка полученной модели с точки зрения ее содержания с использованием неформальных методов проверки. В результате проверки установлено, что модель системы в защищенном исполнении выполняет требуемые бизнес-функции, оставаясь в рамках выработанной политики безопасности, и корректна с точки зрения языка UML.

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

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

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

Примечания

1 JurjensJ. Secure Systems Development with UML: Springer Academic Publishers, 2004. 319 p.

2 Matthew J. Peterson, John B. Bowles, Caroline M. Eastman. UMLpac: An Approach for Integrating Security into UML Class Design. 6 p.

3 Lodderstedt T, Basin D., DoserJ.. SecureUML: A UML-Based Modeling Language for Model-Driven Security. 15 p.

4 Basin D, DoserJ. Model Driven Security for Process-Oriented Systems. 10 p.

5 Lodderstedt T, Basin D, Doser J. Model Driven Security from UML Models to Access Control Infrastructures. 48 p.