Книги, научные публикации

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В БИЗНЕСЕ АНАЛИЗ ПОДХОДОВ К ФОРМАЛЬНОЙ СПЕЦИФИКАЦИИ ПРАВИЛ КОРПОРАТИВНОЙ БЕЗОПАСНОСТИ ИС НА ОСНОВЕ ОНТОЛОГИЙ О.Р. Козырев, профессор, директор Нижегородского филиала

Государственного университета - Высшей школы экономики, e-mail: okozyrev Н.А. Климова, заместитель директора по развитию и управлению Нижегородского филиала Государственного университета - Высшей школы экономики, e-mail: nklimova М.И. Литвинцева, директор по организационной работе Государственного университета - Высшей школы экономики, e-mail: mlitvintseva

Адрес: г. Нижний Новгород, ул. Б. Печерская, д. 25/12.

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

рактически все современные организации чает за объединение и налаживание коммуникации работают сегодня с распределенной ИТ- между разнородными приложениями. Однако новые Пинфраструктурой, множеством разнородных потребности бизнеса диктуют новые условия для ин приложений, реализованных на различных плат- теграции. Динамичность бизнеса требует от ИТ ре формах и взаимодействующих между собой посред- шений гибкости и простоты управления ИТ система ствам набора интерфейсов. Традиционный подход ми, что тяжело реализуемо в рамках традиционного (например, объектно-ориентированная технология подхода. Также возникает другая серьезная проблема CORBA) к интеграции представляет собой создание Ч избыточность программных компонентов и слож промежуточного программного слоя, который отве- ность их многократного использования [1].

БИЗНЕС-ИНФОРМАТИКА №3(13)Ц2010 г.

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В БИЗНЕСЕ Для преодоления перечисленных проблем была из важнейших проблем сервис-ориентированных предложена новая концепция интеграции бизнес- решений является необходимость согласованности процессов на основе сервис-ориентированной ар- результатов выполнения автоматизируемого про хитектуры (СОА). Аналитики компании IBM дают цесса с действующими организационными полити следующее определение: СОА Ч это прикладная ками и ограничениями. Одним из примеров таких архитектура, в которой все функции определены ограничений являются правила и политики кор как независимые сервисы с вызываемыми интер- поративной информационной безопасности. По фейсами. Обращение к этим сервисам в определен- определению, данному в Национальном стандарте ной последовательности позволяет реализовать тот РФ, Информационная безопасность организации или иной бизнес-процесс [2]. Ч это все аспекты, связанные с определением, до К сожалению, практические выгоды от внедре- стижением и поддержанием конфиденциальности, ния СОА до сих пор являются неочевидными и вы- целостности, доступности, неотказуемости, подот зывают дискуссии в бизнес- и ИТ-сообществах. По четности, аутентичности и достоверности инфор результатам опроса, проведенного среди крупных мации или средств ее обработки [9].

производственных компаний консалтинговой ком- В данной работе мы выбрали для изучения воз панией BearingPointТs Wall Street, около 58% респон- можность моделирования организационных дентов ответили, что внедрение СОА внесло лишь контролей информационной безопасности, обе дополнительной сложности в их ИТ ландшафт, не- спечивающих конфиденциальность, при автома жели снизили ее;

30% отметили превышение затрат тизированном или автоматическом построении на СОА по сравнению с ожидаемым уровнем. последовательности запуска сервисов в составе По результатам независимых научных исследо- сложных СОА-решений. Проблема необходимости ваний [3, 4, 5] выделяются следующие основные моделирования организационных контролей была проблемы, возникающие при попытках построе- подробно проанализирована в [8]. Для структури ния СОА на предприятиях: несовместимость про- рованного анализа контролей разграничений пол граммных продуктов;

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

данию описания сервисов;

узкая направленность 1. Статическое разграничение полномочий. Не архитекторов на решение ИТ задач;

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

дартов;

разобщенность бизнеса и ИТ. 2. Динамическое разграничение полномочий.

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

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

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

чиков прибегают к моделированию в разных нота- d. Разграничение полномочий, основанное на циях и стилях (BPMN, UML, EPC), и выполняют истории примения. Невозможность принци ручную или автоматизированную компоновку не- палом иметь все роли, обрабатывающие один зависимых сервисов, применяя формальное опи- и тот же объект.

сание сервисов (WSDL) и языки описания потоков Однако помимо правил и политик присвоения работ, таких как, например, WS-BPEL [6]. ролей одному принципалу и отслеживания уровня Одной из актуальных научных задач в области про- риска при выдаче авторизации, в [10] выделены ав ектирования систем, основанных на СОА, является торизационные политики построения самих ролей.

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

БИЗНЕС-ИНФОРМАТИКА №3(13)Ц2010 г.

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В БИЗНЕСЕ Одним из общепринятых методов решения за- все три уровня моделирования в форме онтологий, дачи автоматического построения последователь- а также позволяют реализовать связи между уров ности запуска сервисов и последующего анализа нями моделирования путем наложения логических полученного решения является интеграция различ- ограничений. За основу моделирования организа ных моделей на основе формальных методов по- ционных контролей была взята концепция постро строения иерархий объектно-ориентированных ения контролей безопасности [8]. Предложенные моделей, метамоделей и онтологий. При этом по- в этой работе принципы моделирования органи нятие лонтология определяется, как подробное зационных контролей с применением механизмов описание структуры некоторой проблемной об- логики первого порядка были использованы в ходе ласти, которое используется для формального и анализа безопасности в данной работе. Поэтому декларативного определения ее концептуализации при моделировании контролей не разрабатывались [11].

новые собственные контроли, но применялись уже описанные в работе [8] ограничения и проверки, Задачей данной работы является определение написанные на языке Alloy.

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

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

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

системы MIT Alloy Analyzer [7]. Инструментарий и Таким образом, на первом уровне нашей модели методы ограниченного логического анализа, реали выделяются такие сущности онтологии, как Со зованные в этой системе позволяют моделировать бытие (Event), Функция (Action), и как дополне Object extends Action PolicyObject (a_post, a_pre) extends extends subject tardets [Operation] contains [Operation] calls extends extends performed_by extends Event DocumentType has_type exclusive Role (event_time) extends o_trigger has_member has_oblig e_trigger has_status extends extends has_auth Obligation o_has_instance Operatin Status Documentinstance Critical_Authorisation_Set Principal (oblig_time) parametr extends critical extends extends extends extends extends extends extends extends extends extends extends extends Completed Blocked New Approved Read Approve Create Block Delete Modify Application Person Authorisation Obligationinstance Value Рис. 1. Онтология предметной области.

БИЗНЕС-ИНФОРМАТИКА №3(13)Ц2010 г.

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В БИЗНЕСЕ ние для целей моделирования организационных assert NoRoleCompletingOneDocument { no r:Role | контролей Ч Обязательство (Obligation & Obliga all di: DocumentInstance| ((contains.di).Operation).

tionInstance).

contains.has_type in (Authorisation&subject.r).targets} Кроме данных объектов вводятся понятия ис полнителя бизнес-функции в качестве бизнес роли (Role) и понятия обрабатываемого доку Все объекты предметной области, кроме тех, мента: Документа (DocumentInstance) и Типа которые непосредственно относятся к понятиям Документа (DocumentType). Роли распределяются бизнес-процесса (Event и Action) являются подти среди принципалов (Principal), работающих а рам пами общего объекта Object, что позволяет опреде ках описываемого бизнес-процесса, которые мо лять общие для всех принципы поведения.

гут быть представлены либо Человеком (Person), Выбранный подход к моделированию бизнес либо Системой (System). Для целей дальнейшего процесса в системе Alloy позволяет описывать анализа организационных контролей информа сложные структуры с ветвлениями и циклами. Для ционной безопасности введены такие понятия:

этого в структуру объектов онтологии (сигнатуры в Политики (PolicyObject), Авторизации (Authori терминах системы Alloy) вводятся дополнительные zation), Обязательства (Obligation & ObligationIn поля с ключевыми словами, запускающими опре stance) и Критический Набор Авторизаций (Criti деленные события. С использованием этих ключе cal_Authorization_Set). Для введенных понятий на вых слов и традиционных логических связок AND, языке системы Alloy определяются ограничения OR становится возможным полностью определить (табл. 1).

логику сложного бизнес-процесса.

На третьем уровне моделирования определяются Таблица 1.

спецификации программных сервисов, существу Моделирование организационных контролей ющих в ИТ-инфраструктуре предприятия реализу на языке Alloy ющих определенную бизнес-функцию. Поскольку в предложенной методологии мы стремимся обе Тип контроля Описание на языке Alloy спечить взаимосвязь всех уровней моделирования, то описание сервисов на третьем уровне взаимос pred ss (disj r1, r2: Role) { r1->r2 in exclusive => вязано с понятиями модели второго уровня и зави some ((subject.r1 & Authorisation) - (subject.r2 & сит от конкретного бизнес-процесса. На третьем Authorisation)) Shared/Shared && уровне мы вводим два основных понятия Service и some ((subject.r2 & Authorisation) - (subject.r1 & Method. Взаимосвязь этих понятий реализована в Authorisation))} assert SS {all disj r1, r2: Role | ss[r1,r2]} системе Alloy через отношение consists_of сигнату ры Service. Каждый метод связан с определенной pred sd (disj r1, r2: Role) { бизнес-функцией на уровне 2 через отношение r1->r2 in exclusive => ss [r1,r2] && corresponds в сигнатуре Method. В дополнение к Shared/Disjoint no ((subject.r1 & Authorisation).subject - r1 - r2) && описанным отношениям вводится ограничение, no ((subject.r2 & Authorisation).subject - r1 - r2)} assert SD {all disj r1, r2: Role | sd[r1,r2]} определяющее вызов метода во время исполне ния бизнес-процесса. На языке системы Alloy это pred ds (disj r1, r2: Role){ ограничение описывается в форме факта:

r1->r2 in exclusive => ss[r1,r2] && // this is required in analysis to avoid Disjoint/Shared empty models fact Synchronisation { no (subject.r1 & Authorisation) &(subject.r2 & all s:Service |all m:Method| m in s.consists_of=>m.

Authorisation)} assert DS { all disj r1, r2: Role | ds[r1,r2]} (s.current_method_pre)= (m.corresponds).a_pre all s:Service |all m: Method | m in s.consists_of =>m.

pred dd (disj r1, r2: Role) { Disjoint/ (s.current_method_post) = (m.corresponds).a_post} r1->r2 in exclusive => ds[r1,r2] &&sd[r1,r2]} Disjoint assert DD { all disj r1, r2: Role | dd[r1,r2]} Построенная иерархия моделей была использо Также было введено дополнительное ограниче- вана для анализа информационной безопасности ние, проверяющее, что не существует такой роли, тестового бизнес-процесса, соответствующего ре которая потенциально смогла бы обработать доку- ально используемому процессу в крупной компа мент по всему жизненному циклю документа: нии (рис. 2).

БИЗНЕС-ИНФОРМАТИКА №3(13)Ц2010 г.

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В БИЗНЕСЕ Mail with Order Order (MS Excel file):

received by Order Desk - nomenclature list - quantity - counteragent address Price list: Contract Sales order regisration Order Desk Price / Delivery conditions / Discount Payment conditions Order System Price check Status: new Some prices < Minimum All prices >=Minimum Order Order block and information Status: blocked sending to Finance controller Price change Order Status:

Finance pricechanged controller Order approval Order Status:

unblocked Order is unlocked Кредитная инф.:

Кредитный лимит Текущая задолженность Order Credit limit is check System Credit limit is not Credit limit is exseeded exceed Рис. 2. Бизнес-процесс закупок в нотации EPC.

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

бизнес-процесса и требуемые для использования В результате логического анализа также была информационные элементы. получена непротиворечивая последовательность БИЗНЕС-ИНФОРМАТИКА №3(13)Ц2010 г.

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В БИЗНЕСЕ вызова программных сервисов, соответствующая его анализ на практическом примере.

изучаемому бизнес-процессу. Полученная последо- В качестве основного вывода по проделанной вательность может быть использована для автома- исследовательской работе нужно отметить, что тической генерации машинно-ориентированной использование специализированного диалекта спецификации бизнес-процесса на языке BPEL. формальной логики Relation Logic и конкретной Таким образом, в ходе этой работы было проанализи- реализации Alloy Analyzer для определения корпо ровано перспективное направление построения мно- ративных политик информационной безопасно гоагентных систем на основе сервис-ориентированной сти представляется целесообразным и многообе архитектуры. Для решения задач автоматизации инте- щающим.

грации и повышения безопасности был предложен Исследование осуществлено в рамках программы метод формальной верификации бизнес-процессов фундаментальных исследований ГУ-ВШЭ в с использованием предметной онтологии и проведен году (проекты ТЗ61.1, ТЗ.29.0).

Литература 1. Фейгин Д. Концепция СОА, электронное издатель ство Открытые системы, 30.06.2004.

2. Channabasavaiah K., Holley K., Tuggle E.M., Migrating to a service-oriented architecture, IBM, December 2003.

3. Parikh A., Gurajada M., SOA в реальности, электронное издание ERP News, 18.08.2007.

4. Почему внедрение сервис-ориентированной архитектуры требует много времени, ru/11420, электронное издание CitCity 5. Бродкин Д., л6 Острых вопросов к СОА, электронное издание ERP News, 12.08.2007.

6. Beek M. H., Bucchiarone A., Formal Methods for Service Composition, Annals of mathematics, computing and teleinformatics, vol. 1, № 5, 2007, PP 1-10.

7. Jackson D., Software Abstractions: Logic, Language, and Analysis, The MIT Press Cambridge, Massachusetts, 2006.

8. Schaad, A., A Framework for Organisational Control Principles, in Department of Computer Science. 2003, University of York, 9. Национальный стандарт РФ, Методы и средства обеспечения безопасности, Часть Концепция и мо дели менеджмента безопасности информационных и телекоммуникационных технологий, 01.06.2007, 10. Kuhn, R Mutual exclusion of roles as a means of implementing separation of duty in role-based access control systems, Proceedings of the second ACM workshop on Role-based access control, 1997, PP 23Ц30.

11. T. R. Gruber T.R, A translation approach to portable ontologies. Knowledge Acquisition, 5(2):199-220, 1993, БИЗНЕС-ИНФОРМАТИКА №3(13)Ц2010 г.

   Книги, научные публикации