Совместное использование моделей безопасности.
В реальных автоматизированных системах редко встречаются системы защиты, ориентированные исключительно на обеспечение конфиденциальности или исключительно на обеспечение целостности информации. Как правило, система защиты должна сочетать оба механизма – а значит, при построении и анализе этой системы будет необходимым совместное использование нескольких формальных моделей безопасности.
Рассмотрим в качестве примера возможные варианты совместного использования моделей Белла-ЛаПадулы и Биба.
1. Две модели могут быть реализованы в системе независимо друг от друга. В этом случае субъектам и объектам независимо присваиваются уровни секретности и уровни целостности.
2. Возможно логическое объединение моделей за счёт выделения общих компонентов. В случае моделей Биба и Белла-ЛаПадулы таким общим компонентом является порядок разграничения доступа в пределах одного уровня секретности (рис. 2.5.1).
3. Возможно использование одной и ой же решётки уровней как для секретности, так и для целостности. При этом субъекты и объекты с высоким уровнем целостности будут располагаться на низких уровнях секретности, а субъекты и объекты с низким уровнем целостности – на высоких уровнях секретности (рис. 2.5.2).
Последняя реализация позволяет, например, разместить системные файлы на нижнем уровне иерархии, что обеспечит их максимальную целостность, не акцентируя внимание на излишней в данном случае секретности.
Ролевое управление доступом. Критерий безопасности системы при применении ролевой модели.
Ролевая модель управления доступом содержит ряд особенностей, которые не позволяют отнести её ни к категории дискреционных, ни к категории мандатных моделей.
Основная идея реализуемого в данной модели подхода состоит в том, что понятие «субъект» заменяется двумя новыми понятиями:
− пользователь – человек, работающий в системе;
− роль – активно действующая в системе абстрактная сущность, с которой связан ограниченный и логически непротиворечивый набор полномочий, необходимых для осуществления тех или иных действий в системе.
Классическим примером роли является root в Unix-подобных системах – суперпользователь, обладающий неограниченными полномочиями. Данная роль по мере необходимости может быть
задействована различными администраторами.
Основным достоинством ролевой модели является близость к реальной жизни: роли, действующие в АС, могут быть выстроены в полном соответствии с корпоративной иерархией и при этом привязаны не к конкретным пользователям, а к должностям – что, в частности, упрощает администрирование в условиях большой текучки кадров.
Управление доступом при использовании ролевой модели осуществляется следующим образом:
1. Для каждой роли указывается набор полномочий, представляющий собой набор прав доступа к объектам АС.
2. Каждому пользователю назначается список доступных ему ролей.
Отметим, что пользователь может быть ассоциирован с несколькими ролями – данная возможность также значительно упрощает администрирование сложных корпоративных АС.
Перейдём к формальному описанию системы. Введём следующие обозначения:
− U – множество пользователей;
− R – множество ролей;
− P – совокупность полномочий на доступ к объектам (реализованная, например, в виде матрицы доступа);
− S – множество сеансов работы пользователей с системой
Управление доступом реализуется с использованием следующих отображений:
− PA ⊆ P × R - отображение множества полномочий на множество ролей, задающее для каждой роли установленный набор полномочий;
− UA ⊆U × R - отображение множества пользователей на множество ролей, определяющее набор ролей, доступных данному пользователю;
− user : S →U - функция, определяющая для сеанса s∈ S текущего пользователя u ∈U : user(s) = u ;
− roles : S →{R} - функция, определяющая для сеанса s∈ S набор ролей из множества R , доступных в данном сеансе: roles s {r user s r UA} i i ( ) = | ( ( ), )∈ ;
− permissions : S →{P} - функция, задающая для сеанса s∈ S набор доступных в нём полномочий (иначе говоря, совокупность полномочий всех ролей, доступных в данном сеансе):
U{ }
( )
( ) | ( , )
r roles s
i i permissions s p p r PA
∈
= ∈ .
Взаимосвязь пользователей, ролей, полномочий и сеансов показана на рис. 2.6.
Критерий безопасности системы при использовании ролевой модели звучит следующим образом: система считается безопасной, если любой пользователь в системе, работающий в сеансе s∈ S , может осуществлять действия, требующие полномочий p∈ P , только в том случае, если p∈ permissions(s) .
На практике управление доступом в АС при использовании ролевой модели осуществляется главным образом не с помощью назначения новых полномочий ролям, а путём задания отношения UA – т.е. путём определения ролей, доступных данному пользователю.
Подходы к распределению ролей могут быть различными и определяются спецификой организации, однако в большинстве случаев реализуется один из двух вариантов:
1. Создание иерархических ролей, полностью копирующих корпоративную иерархию и сохраняющих отношения между ролями, существующие в реальном мире.
2. Использование взаимоисключающих ролей, позволяющих эффективно реализовать разделение обязанностей.
Во всех случаях использование ролевой модели позволяет значительно повысить эффективность администрирования сложных автоматизированных систем, поэтому данный подход чрезвычайно популярен.