О построении иерархического ролевого управления доступом

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

ЛИТЕРАТУРА

1. ГОСТ Р 53113-2008. Информационная технология. Защита информационных технологий и автоматизированных систем от угроз информационной безопасности, реализуемых с использованием скрытых каналов. Ч. 1. Общие положения. М.: Стандарты, 2008.

2. Efstathopoulos P. О. and Krohn И. О. Labels and Event Processes in the Asbestos Operating System // Proceedings of the SOOP’05. ACM, 2005.

3. Девянин П. Н. Анализ безопасности управления доступом и информационными потоками в компьютерных системах. М.: Радио, 2006. 176 с.

УДК 004.94

О ПОСТРОЕНИИ ИЕРАРХИЧЕСКОГО РОЛЕВОГО УПРАВЛЕНИЯ ДОСТУПОМ

Д. Н. Колегов

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

В моделях ролевого управления доступом семейства RBAC [1], как и в других известных ролевых моделях и их расширениях [2, 3], не используются механизмы задания и проверки разрешённых прав доступов субъекта к сущности, учитывающие уровни иерархии сущностей КС.

В реальных КС, в которых одновременно могут работать сотни пользователей, структура ролей может быть очень сложной, а количество различных прав доступа значительным — проблема реализации и администрирования системы управления доступом является чрезвычайно важной задачей [4].

Для решения этой задачи строится расширение базовой модели RBAC, содержащее в дополнение к последней следующие положения:

— задана решётка уровней иерархии КС и для каждой сущности указан уровень иерархии;

— определено множество типов сущностей КС и для каждой сущности указан её тип;

— задано множество ролей, каждая из которых представляет собой некоторое множество прав доступа к сущностям определённого типа;

— каждый субъект обладает некоторым множеством разрешённых для данного субъекта ролей;

— субъект обладает правом доступа к сущности КС в том и только в том случае, если субъект обладает ролью, в множестве прав доступа которой имеется данное право доступа к сущности данного типа и уровень иерархии субъекта не меньше уровня иерархии сущности.

Использование введённых положений позволяет значительно эффективнее и гибче реализовать механизм ролевого управления доступом по сравнению с моделями RBAC. На основе [4] опишем формальную структуру предлагаемой модели.

Основными элементами модели иерархического ролевого управления доступом, обозначаемой RBAC-H, являются:

— E = O U C — множество сущностей, где O — множество объектов, C — множество контейнеров и O П C = 0;

— U — множество пользователей, при этом пользователи по определению не являются сущностями (U П E = 0);

— S С E — множество субъект-сессий пользователей;

— T — множество типов сущностей;

— L — множество уровней иерархии сущностей;

— Rr — множество видов прав доступа;

— R — множество ролей;

— P С (Rr х T) U (Rr х E) —множество прав доступа ко всем сущностям одного типа и сущностям;

— PA : R ^ 2Р — функция прав доступа ролей, задающая для каждой роли множество прав доступа к сущностям, при этом для каждого права доступа p Е P существует роль r Е R, такая, что выполняется условие p Е PA(r);

— UA : U ^ 2r — функция авторизованных ролей пользователей, задающая для каждого пользователя множество ролей, на которые он может быть авторизован;

— type : E ^ T — функция типов сущностей;

— fe : E ^ L — функция, задающая уровень иерархии каждой сущности;

— user : S ^ U — функция принадлежности субъект-сессии пользователю, задающая для каждой субъект-сессии пользователя, от имени которого она активизирована;

— ro/es : S ^ 2r — функция текущих ролей субъект-сессий, задающая для пользователя роли, на которые авторизован активизированный от его имени данный субъект в текущей сессии, при этом в каждом состоянии системы для каждой субъект-сессии s Е S выполняется включение ro/es(s) С UA(user(s)).

Пусть X — заданное разбиение множества E. Доменом d сущностей множества E называется всякий класс из X.

Иерархией доменов называется заданное на множестве X отношение частичного порядка «^», удовлетворяющее следующим условиям:

— если для d Е X существуют di,d2 Е X, такие, что d ^ di,d ^ d2, то di ^ d2 или d2 ^ di;

— в X существует наибольший элемент.

Описанная иерархия доменов соответствует КС с иерархической древовидной структурой, отражающей организационно-управленческие отношения, и задаёт верхнюю полурешётку (X, ^).

Пусть L — множество уровней иерархии сущностей, такое, что |L| = |X| и существует биективное отображение X на L. Определим на множестве L отношение частичного порядка «^», где для любых /1,/2 Е L верно /1 ^ /2 тогда и только тогда, когда d1 ^ d2 для соответствующих d1,d2 Е X. Тогда (L, ^) — верхняя полурешётка уровней иерархии сущностей.

Аналогично модели RBAC, предполагается, что множества U, X, T, L P, R, Rr и функции UA, PA, type не изменяются с течением времени.

Пусть заданы множества E, S, X, U, T, P, R, Rr, функции PA, UA, type, user, ro/es и полурешетка (L, ^). Определим предикат can_access(s, e,p), истинный тогда и только тогда, когда выполняются следующие условия:

— fe(e) ^ fe(s);

— (p, type(e)) Е PA(ro/es(s)).

Говорят, что в КС реализовано иерархическое ролевое управление доступом RBAC-H, если любая субъект-сессия s G S пользователя user(s) G U может обладать правом доступа p G Rr к сущности e G E тогда и только тогда, когда истинен предикат can_access(s, e,p) .

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

ЛИТЕРАТУРА

1. National Institute of Standards and Technology. Role Based Access Control (RBAC) and Role Based Security. [Электронный ресурс]. Режим доступа: http://csrc.nist.gov/groups/ SNS/rbac.

2. Kuhn D. R., Coyne E. J., and Weil T. R. Adding attributes to role-based access control // IEEE Computer. 2010. No. 43(6). P. 79-81.

3. Sandhu R. S. and Mohammad A. A. A Model for Attribute-Based User-Role Assignment // Proc. 18th Annual Computer Security Applications Conf. San Diego, California, USA, December 09-13. IEEE Computer Society Washington, 2002. P. 353.

4. Девянин П. Н. Модели безопасности компьютерных систем. Управление доступом и информационными потоками: учеб. пособие для вузов. М.: Горячая линия-Телеком, 2011. 320 с.

УДК 681.322

ЛАБОРАТОРНЫЙ ПРАКТИКУМ «ОСНОВЫ ПОСТРОЕНИЯ ЗАЩИЩЁННЫХ КОМПЬЮТЕРНЫХ СЕТЕЙ» НА ПЛАТФОРМЕ CISCO PACKET TRACER

Д. Н. Колегов, Б. Ш. Хасанов

Рассматриваются вопросы организации и проведения лабораторного практикума «Основы построения защищённых компьютерных сетей» на кафедре защиты информации и криптографии Национального исследовательского Томского государственного университета [1]. Практикум представляет собой набор лабораторных работ, которые могут использоваться в рамках одноимённого курса, курса «Вычислительные сети» или курсов смежной тематики. Актуальность данного практикума определяется тем фактом, что в настоящее время компьютерные сети являются ключевой составляющей современных информационно-телекоммуникационных систем. Среди всех задач по построению компьютерных сетей важнейшей является обеспечение защищённости от угроз конфиденциальности, целостности и доступности. При этом подсистема защиты должна являться частью компьютерной сети, обеспечивающей её безопасность, как одно из возможных свойств. При таком подходе к разработке архитектуры компьютерных сетей говорят о защищённых компьютерных сетях.

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