В работе представлена объектно-ориентированная метамодель политики ролевого разграничения доступа. Основные множества и отображения описаны в терминах классов и отношений наследования и агрегации. Управление доступом (функционирование) рассмотрено с позиций метапрограммирования. Для обеспечения функционирования крупномасштабных объектов информатизации все более востребованными становятся большие информационные системы (БИС). Потребности бизнеса и государства в интеграции разрозненных информационных систем, обслуживающих эти структуры, определяют активное развитие и расширение сферы внедрения БИС. По-прежнему главной из проблем остается сложность создания и сопровождения БИС. В области программирования общепризнанным способом борьбы со сложностью системы является объектно-ориентированный подход. Так как для подсистемы безопасности БИС упомянутая проблема сложности также актуальна, объектно-ориентированные принципы постепенно распространяются и на сферу информационной безопасности [1, 2]. В настоящее время появился термин «объектно-ориентированная безопасность», понимаемый, в частности, как практика использования общих объектно-ориентированных шаблонов проектирования в качестве механизма для защиты информации [3]. Центральной задачей системы защиты информации является обеспечение конфиденциальности данных. Наиболее действенным методом решения данной проблемы считается управление доступом к информационным ресурсам. Набор правил разграничения доступа в информационной системе, который принято называть политикой управления доступом, определяет основные принципы регулирования использования всех ресурсов системы. В рамках подходов к реализации политики управления доступом ролевая модель рассматривается как объектно-ориентированное решение, способное понизить сложность администрирования системы с большим количеством пользователей и ресурсов. Тем не менее, не смотря на то, что идея объектноориентированной природы ролевой политики управления доступом не нова и заложена в эту модель изначально [4], отсутствует строгая объектно-ориентированная интерпретация ролевой политики (например в терминах объектной модели какого-либо языка программирования). Подобные идеи обсуждались в ряде работ. Так в статье [5] впервые была дана интерпретация полномочий как набора базовых классов, а ролей - как множества классов-наследников. В работе [6] авторы описывают метамодель ролевой политики управления доступом в виде иерархии классов на языке UML. Основная направленность работ по объектной интерпретации ролевой модели заключается в программной реализации ролевого принципа управления доступом в рамках той или иной информационной системы. Вместе с тем переход на объектно-ориентированную терминологию представляет собой удобный
Copyright ○ c by the paper’s authors. Copying permitted for private and academic purposes. инструмент для дальнейшей формализации ролевого подхода и получения теоретических оценок безопасности. Например, объектная модификация классических дискреционных моделей управления доступом позволила расширить класс систем, для которых доказана алгоритмическая безопасность [7], и установить взаимосвязь с мандатными моделями [8].
В данной статье для объектно-ориентированного представления ролевой политики управления доступом использованы объектная модель, допускающая множественное наследование, и механизмы метапрограммирования1. Использована терминология языка программирования С++. Выбор языка обусловлен, в частности, наличием в С++ возможности создания класса на основе нескольких базовых и наиболее распространенным синтаксисом. 1
Спецификация основных множеств и отображений Базовая модель ролевой политики управления доступом предполагает задание следующих основных элементов информационной системы [10]: ∙ множество ролей = {1, . . . , }; ∙ множество полномочий = {1, . . . , }; ∙ множество пользователей = {1, . . . , }; ∙ отображение : → 2 , которое каждой роли сопоставляет набор полномочий () ⊆ ; ∙ отображение : → 2, которое каждому пользователю сопоставляет подмножество разрешенных для авторизации ролей () ⊆ . Управление доступом заключается в авторизации пользователя в каждом сеансе работы в системе, то есть в определении множества ролей, по которым пользователь осуществляет доступ к ресурсам в данном сеансе. Формально процесс авторизации можно описать отображением : × → 2, где – множество сеансов работы в системе. При этом должно выполняться условие: (, ) ⊆ ().
Часто, при попытке объектной интерпретации ролевой модели, роли сопоставляются с классами, полномочия – с методами классов, а пользователи – с объектами (или экземплярами) классов [2]. В данной работе предлагается несколько иная спецификация ролей, полномочий и пользователей, позволяющая в большей мере отразить особенности этих элементов.
Полномочия в общем случае объединяют в себе и операции доступа, и объекты доступа (например, запросы на обработку данных в СУБД). Поэтому целесообразно интерпретировать каждое полномочие не как метод, а как отдельный класс, инкапсулирующий поля-данные и методы их обработки. Таким образом, каждому полномочию ( = 1, . . . , ) сопоставляется класс Pk.
Роль, как активная сущность, представляет собой типовой набор полномочий. Следовательно, каждой роли ( = 1, . . . , ) в объектной модели следует сопоставить класс Ri.
Множество пользователей – это также набор классов: для каждого пользователя ( = 1, . . . , ) в объектной модели создается класс Uj.
Для спецификации отображения возможны два подхода. Первый – классы-роли являются наследниками базовых классов-полномочий. Но при этом и полномочия, и роли становятся сущностями одной природы, связанными отношением наследования, которое определяется отображением . Второй подход позволяет учесть различия в понятиях «полномочие» и «роль». Предлагается между классами-ролями и классами-полномочиями установить отношение агрегации. Класс-контейнер – это класс-роль Ri. Полями класса Ri являются ссылки на объекты классов-полномочий, сопоставленных полномочиям из множества (). В данном случае агрегация предпочтительнее композиции, так как при композиции полномочие может быть частью одной и только одной роли, тогда как при агрегации полномочие может быть частью нескольких ролей.
Спецификация отображения аналогична подходу, примененному к отображению . Между классами-пользователями и классами-ролями вновь устанавливается отношение агрегации. На этот раз классом-контейнером является класс-пользователь Uj, а поля этого класса определяются ролями из множества () и представляют собой ссылки на объекты классов-ролей.
1Метапрограммирование – парадигма программирования, построенная на программном изменении структуры и поведения программ [9].
Следующим важным моментом в построении ролевой модели является вопрос о возможном делегировании полномочий между ролями. Наиболее распространены ролевые модели с иерархической организацией системы ролей. В этом случае на множестве ролей задается отношение частичного порядка « ≥ », называемое отношением доминирования/подчинения. При этом доминирование одной роли над другой подразумевает полное наследование ее полномочий. Кроме того, при авторизации пользователя на какую-либо роль , он получает полномочия и всех ролей, подчиненных . В объектной модели эти принципы в полной мере отражены в отношении наследования между классами. Диаграмма Хассе (транзитивное замыкание диаграммы отношения порядка), порожденная отношением доминирования/подчинения на множестве ролей, задает диаграмму иерархии классов R1, ..., Rn. Листовым вершинам (вершинам без исходящих дуг) диаграммы Хассе соответствуют базовые классы-роли. Далее, используя механизм множественного наследования, порождаются производные классы-роли. Одной из проблем множественного наследования является дублирование полей общего предка. Чтобы любой класс-наследник содержал один экземпляр полей класса-предка, необходимо использовать механизм виртуального наследования ( virtual-наследование).
В ролевой политике управления доступом при задании отображения с учетом ролевой иерархии возможны два подхода: листовой, когда полномочия раздаются только листовым ролям, а далее распределяются между ролями по принципу наследования, и охватный, при котором набор полномочий старших ролей может пополняться и не унаследованными полномочиями. В объектной интерпретации эти два подхода регламентируются запретом или разрешением на пополнение производных классов-ролей дополнительными (не унаследованными) полями. В объектно-ориентированных языках программирования производный класс всегда может дополнить базовый – реализован более общий охватный принцип. Поэтому, в объектной модели ролевой политики безопасности необходимо предусмотреть спецификатор наследования, запрещающий расширение множества элементов производного класса. Назовем такое наследование «нерасширяемым» (non-expandable ).
Стоит отметить, что, так как полномочия являются не методами, а полями классов-ролей, они не могут быть переопределены (изменить свое поведение) в производных классах за счет механизма виртуализации, что согласуется с требованиями безопасности.
Так как рассмотренные элементы составляют описательную часть модели, все поля и методы классовполномочий, классов-ролей и классов-пользователей должны быть скрытыми. В силу наличия отношения наследования, целесообразно использовать спецификатор доступа protected.
Соответствие между основными элементами базовой ролевой модели управления доступом и объектной спецификацией представлены в таблице 1: основные множества заданы наборами классов, а основные отображения – отношениями между классами. Стандарт ролевого управления доступом предполагает некоторый набор элементарных операторов (функций) для администрирования ролевой модели [2, 11]. Функции-операторы можно разделить на три категории: основные, вспомогательные и информационные. Эти функции легко могут быть выражены в терминах преобразования построенной системы классов. В таблице 2 представлены первые две категории.
Спецификация основных функций-операторов очевидным образом следует из объектной интерпретации основных множеств и отображений ролевой модели. Более детального обсуждения требуют операторы вспомогательной категории.
Создать / удалить роль . Создать / удалить пользователя . Приписать / ликвидировать полномочие роли . Разрешить авторизацию / запретить авторизацию пользователя на роль . Создать / удалить отношение наследования между существующими ро
Провести преобразование иерархии классов R1, ..., Rn с целью порождения наследования / свертывания иерархии для классов Ri1 (базовый класс) и Ri2 (класс-наследник). Вспомогательные операторы Осуществить простое «нерасширяемое» public-наследование класса СUj от класса Uj с перемещением требуемых для авторизации полей в интерфейс класса СUj.
Удалить класс СUj.
Заметим, что за рамками рассмотрения остались ограничения на разделение обязанностей и вспомогательные функции. При необходимости они также могут быть представлены в терминах анализа и преобразования объектной ролевой модели. 3
Пример создания классов, описывающих заданную ролевую модель Рассмотрим пример объектно-ориентированной спецификации некоторой ролевой политики управления доступом. Пусть = {1, 2, 3, 4, 5}, = {1, 2, 3, 4}, = {1, 2, 3}. Иерархия ролей представлена графом на рисунке 1. Пусть «листовым» ролям приписаны следующие наборы полномочий: (1) = {1, 2}, (2) = {1, 3}, (3) = {3, 4}. Будем считать, что полномочия по иерархии распространяются согласно листовому подходу. Тогда (4) = {1, 2, 3}, (5) = {1, 2, 3, 4}. Определены разрешенные для авторизации роли для каждого пользователя: (1) = {1, 3}, (2) = {3, 4}, (3) = {5}.
r4 r1 Описание этой ролевой модели в виде классов, связанных отношениями наследования (см. рис. 1) и агрегации, будет иметь следующий вид: class P1{}; class P2{}; class P3{};
class P4{}; }; }; }; class R4: virtual public non-expandable R1, virtual public non-expandable R2{}; class R5: virtual public non-expandable R4, virtual public non-expandable R3{}; class R1{ protected:
P1 *p1;
P2 *p2; class U1{ protected:
R1 *r1;
R3 *r3; }; class R2{ protected:
P1 *p1;
P3 *p3; class U2{ protected:
R3 *r3;
R4 *r4; }; P4 P3 P2 P1
R3 #p3: P3 #p4: P4
R2 #p1: P1 #p3: P3
R1 #p1: P1 #p2: P2 class R3{ protected:
P3 *p3;
P4 *p4; class U3{ protected:
R5 *r5; };
R4
R5
U3 #r5: R5
U2 #r3: R3 #r4: R4
U1 #r1: R1 #r3: R3
CU2 +r4: R4 Рассмотрим вариант администрирования ролевой модели. Авторизация пользователя 2 на роль 4 в текущем сеансе работы системы будет заключаться в создании следующего класса: class CU2: public non-expandable U2{ public:
using U2::r4; };
Окончательный вариант UML-диаграммы классов, сопоставленных предложенной ролевой политике управления доступом, представлена на рисунке 2.
Рис. 2: UML-диаграмма классов, соответствующих заданной ролевой модели Подводя итог, еще раз отметим, что объектная спецификация ролевой модели управления доступом проводится в терминах классов и отношений между ними: агрегации и наследования. Непосредственно управление доступом (функционирование) описывается с позиций метапрограммирования. При таком подходе стирается разница между данными и программой. Так авторизация пользователя в текущем сеансе работы системы интерпретируется как создание класса, находящегося в некотором отношении с классами существующей структуры.
Объектно-ориентированное расширение ролевой модели позволит обосновать применимость теоретических и практических результатов, полученных для ролевых политик управления доступом в компьютерных системах микроуровня, к БИС, для которых построение эффекивной подсистемы защиты информации требует особых подходов в связи с возникновением дополнительных задач в управлении доступом [12]. Список литературы
[4] Role Based Access Control (RBAC) and Role Based Security . URL: http://csrc.nist.gov/groups/SNS/ rbac/.
Role-Based Access Control Metamodel
An object-oriented role-based access control metamodel is suggested in this article. The basic sets and mappings are described in the terms of classes and relations of inheritance and aggregation. An access control is considered from the metaprogramming point of view.