Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Теоретические основы защиты информации. Учебное пособие
.pdf
Операция представляет собой команду или блок команд, кото-
Операции Субъекты
рый может быть вызван при выполнении роли и является субъектом для ограничений в КДБР.
Авторизованный в некоторой роли пользователь потенциально
имеет право выполнять операции, ассоциированные с этой ролью.
Отношения между пользователями, операциями и ролями могут
быть описаны в следующей форме (рис. 10.3):
role-operations(r : roles) = {множество операций, ассоцииро-
ванных с ролью r}
operation-objects(op: operation) = {множество объектов систе-
мы, к которым можно применить операцию ор}.
Рис. 10.3. Соотношение множеств операции
10.2. Роли и иерархия ролей
Во многих организациях существует много общих операций,
выполняемых всеми служащими. Следовательно, можно упростить
администрирование системы, определив данные операции для
каждой создаваемой роли. Как следствие для облегчения администрирования и придания более естественной структуры политике
безопасности КДБР может включать иерархию ролей. Иерархия
ролей определяет роли, имеющие уникальные атрибуты и, возможно, включающие прочие роли, так что одна роль может включать операции и ограничения, ассоциированные с другой ролью.
Пример иерархии ролей приведен на рис. 10.4.
На данном рисунке показано, что специалист содержит роли
кардиолог и ревматолог
Это означает, что кардиолог и ревматолог могут выполнять
все операции доступа (к соответствующим объектам с соответствующими ограничениями), определенные для специалиста, без
необходимости для администратора системы явно задавать их.
141
Доктор
Специалист
РевматологКардиолог
Рис. 10.4. Пример иерархии ролей
Иерархия ролей может быть представлена с помощью выражения ((R
, RI) >), где R
I+1
, является непосредственным наследни-
I+1
ком RI и знак > означает «содержит». Иерархия ролей может быть
описана следующим образом.
Правило 1 (иерархия ролей). Если субъект авторизован для
роли (rj) и эта роль содержит другую роль (ri), то субъект авторизован для доступа к роли ri.
s : subject, ri, rj: roles : rj authorized-roles (s) & rj ri => ri
authorized-roles (s).
10.3. Авторизация и активация роли
При ассоциации пользователя с ролью обычно требуется выполнение следующих ограничений:
– пользователю может быть дано не больше привилегий, чем
ему необходимо для выполнения работы;
– роль не является взаимоисключающей для роли, для доступа
к которой пользователь уже авторизован;
142
– численные ограничения, которые связаны с ролью, не превышаются.
Первое положение связано с принципом наименьших привилегий. Для реализации данного принципа администратору системы
необходимо определить множество функций, необходимых пользователю, а также минимум привилегий, необходимых для выполнения данных функций. В вычислительных системах, не применяющих КДБР (например, в системах, основанных на дискреционной
модели доступа), иногда затруднительно определить набор минимально необходимых привилегий, а следовательно, применить
принцип наименьших привилегий. В КДБР данный принцип реализуется на основании понятия роли и иерархии ролей.
Второе положение поддерживает политику статического разделения обязанностей или так называемый конфликт интересов.
Это означает, что пользователь, авторизованный для выполнения
некоторой роли, должен не быть авторизованным для выполнения
другой роли. К примеру, одному и тому же пользователю не могут
быть назначены роли бухгалтера и аудитора. Данное ограничение
может быть записано следующим образом:
mutually-exclusive-authorization(r : roles) = {множество ролей,
взаимоисключающих роль r).
Правило 2 (статическое разделение обязанностей). Роль, доступ к которой получает пользователь, не является взаимоисключающей с ролью, для которой пользователь уже авторизован.
s: subject, rp rj: roles : и role-members(ri) & и rolemembers(rj) ri ≠ mutually- exclusive-authorization(rj).
Третье положение определяет емкость роли.
Правило 3 (кардинальность). Емкость роли не может быть
превышена при добавлении нового члена роли.
r: roles : membership-limit(r) ≥ number-of-members(r).
В данном выражении membership-limit(r) определяет максимальное количество пользователей, которые могут быть связаны
с ролью r. С использованием этого правила может быть ограничено количество пользователей, связанных с ролью. В качестве примера использования данного правила может быть задано ограничение, определяющее запрет наличия в системе более одного администратора.
143
Когда пользователь инициирует сессию в системе, он может
быть ассоциирован с одной или несколькими ролями из множества
ролей, членом которых он является. Авторизация пользователя является необходимым, но не всегда достаточным условием для выполнения операций с полномочиями роли, т. е. активации этой роли. В зависимости от политики безопасности роль может быть активизирована, если:
– пользователь, авторизованный для роли, потребовал активации;
– требуемая операция авторизована для роли, которая запрашивается для активации;
– активация роли взаимно не противоречит любой роли, активной для пользователя.
Дадим определение функции, разрешающей субъекту исполнить операцию под управлением КДБР, а также зависимости, описывающей активные роли для субъекта:
ехес : (s : subject, op : operation) = {TRUE, если и только если s
может исполнить операцию ор, иначе FALSE}
active-roles (s : subject) = {список активных ролей для s}.
Активная роль для субъекта должна входить в список ролей,
для которых он авторизован, что описывается следующим правилом.
Правило 4 (авторизация для роли). Субъект никогда не может
иметь активной роли, если он не авторизован для нее.
s : subject, op : operation : active-roles(s) authorized-roles(s).
Правило 5 (исполнение роли). Субъект может исполнить операцию, только если он действует в активной роли, к которой принадлежит данная операция.
s : subject, op : operation : exec(s, op) exec(s, roleoperations(active-roles(s))).
КДБР обеспечивает администратору системы возможность организации динамического разделения обязанностей. Для этого
можно определить функцию:
mutually-exclusive-activation(r: roles) = {множество активных ролей, которые являются несовместимыми с запрашиваемой
ролью r}.
Динамическое разделение обязанностей в КДБР определяется
следующим образом.
144
Правило 6 (динамическое разделение обязанностей). Субъект
может активизировать роль, если она не является несовместимой с
ролью, в которой пользователь уже активен.
s : subject, rij : roles : i, j : ri active-roles(s) & rj active-
roles(s) & ri ≠ mutually- exclusive-activation(rj).
Правило 7 (авторизация для операции). Субъект может исполнить операцию, только если операция разрешена для роли, являющейся активной для субъекта.
s: subject, op : operation, r : roles : exec(s, op) & r activeroles(s) op role- operations(r).
10.4. Операционное разделение обязанностей
и доступ к объектам
КДБР может использоваться администраторами систем для
организации политики операционного разделения обязанностей.
Данная политика безопасности требует, чтобы все операции, ассоциированные с некоторой функцией системы, не могли исполняться единственным пользователем. Операционное разделение обязанностей можно записать с помощью следующей функции:
function-operations(f: function) = {множество операций, требуемых для выполнения функции f).
Правило 8 (операционное разделение обязанностей). Роль
может быть ассоциирована с операцией, требуемой для выполнения функции в системе, если роль является авторизованной для
субъекта и не была связана с операциями, предназначенными для
выполнения других операций функции.
s : subject, r : role, f: function : (function-operations(f) role-
operations(r)).
Следующая функция в КДБР используется для контроля доступа субъектов к объектам:
access (s : subject, о : object) = {TRUE, если субъект имеет до-
ступ к объекту, иначе FALSE).
Правило 9 (авторизация доступа к объектам). Субъект имеет
доступ к объекту, если только существует роль, являющаяся членом активного множества ролей субъекта, которой разрешена операция с правом доступа к объекту.
s : subject, о : object access(s, о) r: roles, op : operation : r
active-roles(s) & op role-operations(f) & о operation-objects(op).
145
Семейство моделей КДБР
ДокторСпециалист
Ревматолог
Кардиолог
Рассмотрим семейство моделей КДБР. В данное семейство
входят следующие модели:
RBAC0 – базовая модель КДБР;
RBAC1 – включает требования модели RBAC0 и концепцию
иерархии ролей;
RBAC2 – включает требования модели RBAC0 и ограничения,
налагаемые на различные компоненты, включаемые в модель, –
статическое и динамическое разделение обязанностей (модели
RBAC1 и RBAC2 – развитые модели – сравнивать между собой
нельзя);
RBAC3 – объединяющая модель, включает требования моделей RBAC1 и RBAC2 (и, согласно свойству транзитивности, модели
RBAC0).
Взаимоотношение моделей семейства КДБР показано на
рис. 10.5.
Рис. 10.5. Семейство моделей КДБР
146
Контрольные вопросы
1. На каком уровне системы обычно реализуется контроль до-
ступа, базирующийся на ролях?
2. Поясните сущность основных понятий, используемых в ро-
левых моделях доступа.
3. Какими выражениями определяются отношения между
пользователями, субъектами и ролями?
4. Приведите пример иерархии ролей.
5. Каким образом может быть иерархия ролей?
6. Какие ограничения обычно требуется выполнить при ассо-
циации пользователя с ролью?
7. Существует ли алгоритм эмуляции в рамках моделей дис-
креционного и мандатного доступа моделей из семейства КДБР?
8. Существует ли алгоритм эмуляции в рамках моделей семей-
ства КДБР моделей дискреционного и мандатного доступа?
147
11. ИДЕНТИФИКАЦИЯ И АУТЕНТИФИКАЦИЯ
Для того чтобы политики разграничения доступа могли связать пользователей системы с их представлением в вычислительной системе, необходимо наличие некоторого механизма, позволяющего определить это соответствие пользователей и их представлений. Данный механизм называется механизмом идентификации/аутентификации. Таким образом, механизм идентификации/аутентификации является основой для механизмов разграничения доступа.
Процесс регистрации пользователя в любой системе состоит
из трех взаимосвязанных последовательно выполняемых процедур:
идентификации, аутентификации и авторизации.
Идентификация – процедура распознавания субъекта по его
идентификатору. В процессе регистрации субъект предъявляет
свой идентификатор системе, которая проверяет его наличие в своей базе данных. Субъекты с известными системе идентификаторами считаются легальными (законными), остальные относятся к нелегальным.
Аутентификация – процедура проверки подлинности субъекта, которая позволяет достоверно убедиться в том, что субъект,
предъявивший свой идентификатор, на самом деле является именно тем субъектом, идентификатор которого он использует. Для
этого он должен подтвердить факт обладания некоторой информацией, которая может быть доступна только ему одному (пароль,
ключ и т. п.).
Авторизация – процедура предоставления субъекту определенных прав доступа к ресурсам системы после прохождения им
процедуры аутентификации. Для каждого субъекта в системе
определяется набор прав, которые он может использовать при обращении к ее ресурсам.
Для того чтобы обеспечить управление и контроль над данными процедурами, дополнительно используются процессы администрирования и аудита.
Администрирование – процесс управления доступом субъектов к ресурсам системы. Данный процесс включает:
148
создание идентификатора субъекта (учетной записи поль-
зователя) в системе;
управление данными субъекта, используемыми для его
аутентификации (смена пароля, издание сертификата и т. п.);
управление правами доступа субъекта к ресурсам системы.
Аудит – процесс контроля (мониторинга) доступа субъектов к
ресурсам системы, включающий протоколирование действий
субъектов при их доступе к ресурсам системы в целях обнаружения несанкционированных действий.
Таким образом, в общем случае речь идет о пяти основных
процедурах предоставления доступа к информации. При этом возможен различный подход к расстановке приоритетов при выполнении этих процедур.
11.1. Роль и задачи аутентификации
Независимо от типа системы аутентификации в ней всегда
присутствуют пять элементов.
Первый элемент – конкретный человек или процесс, который
должен проходить аутентификацию, – субъект доступа.
Второй элемент – опознавательный знак, идентификатор, который выделяет этого человека или этот процесс среди других.
Третий элемент – отличительная характеристика (аутенти-
фикатор), подтверждающая принадлежность идентификатора
субъекту доступа.
Четвертый элемент – владелец системы (администратор), который несет ответственность за использование системы, и в разграничении авторизованных пользователей и остальных полагается
на механизм аутентификации.
Пятый элемент – механизм аутентификации, который позво-
ляет проверить присутствие отличительной характеристики.
При успешном прохождении аутентификации субъекту доступа должны быть выданы некоторые права (привилегии).
Для этого служит механизм управления доступом. С помощью
этого же механизма субъект доступа лишается прав (привилегий),
если аутентификация была неуспешной.
Примером аутентификации является вход физического лица в
систему по паролю. Физическое лицо – это человек, которому раз-
149
решено пользоваться компьютером. Обычно в системе физическому лицу назначается символическое имя или идентификационный
код пользователя, который мы будем называть именем пользова-
теля. Например, если пользователь является авторизованным
пользователем системы, то администратор присваивает ему имя
пользователя «Пользователь». Отличительной характеристикой
пользователя будет его секретный пароль, например, «qwerty».
Данная процедура знакома, так как в процессе регистрации компьютер выдает запрос на ввод имени пользователя и пароля. Процесс включает в себя процедуру аутентификации, т.е. сравнение
пароля, введенного с клавиатуры, с паролем, установленным либо
самим пользователем, либо администратором системы. Процедура
завершается успешно, если оба пароля совпадают. В этом случае
механизм управления доступом разрешает пользователю продолжать работу на компьютере, и система использует имя пользователя каждый раз, когда ей требуется решение службы управления
доступом к защищенному ресурсу.
Рассматривая проблемы защиты компьютеров, следует всегда
проводить различие между тем, что мы хотим сделать, и тем, что
мы в действительности делаем.
Первый вопрос «чего мы хотим» обычно озвучивают в виде
целей защиты. Например, целью шайки сорока разбойников была
защита добычи от воровства. В этом они полагались на механизм
защиты – дверь пещеры. В вычислительной системе целью владельца системы является предоставление доступа только авторизованным (законным) пользователям.
На практике же всегда существует зазор между тем, что мы
хотим, и что происходит на самом деле. Так, замок позволяет войти каждому, у кого есть экземпляр нужного ключа, однако посторонние смогут войти тоже, если мы не предотвратим попадание
к ним ключа.
Это может оказаться трудным делом, особенно если те, кого
мы стремимся не впустить с помощью замка, действительно хотят
попасть внутрь. Более того, мы не всегда можем позволить себе
поставить замки на все на свете. Часто имеется один большой замок на входной двери, и нам приходится доверять тем, кого мы
впустили внутрь.
150
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]