Модели контроля доступа.

Спецкурс (8 семестр) «Безопасность систем баз данных»
Специальность «Информатика»
1 из 12
Лекция 3. Модели контроля доступа.
1. Введение
Итак, различают две главные модели контроля доступа:
- избирательный, дискреционный (discretionary, DAC)
Определение1 [Bishop1, стр.53]. Если отдельный пользователь может установить
механизм контроля доступа для разрешения или запрета доступа к объекту, такой
механизм называется избирательным, или контролем доступа, основанным на
идентификации (identity-based access control, IBAC)
- обязательный (mandatory, MAC)
Определение2 [Bishop, стр.53]. Когда некоторый механизм системы регулирует доступ
к объекту, и отдельный пользователь не может изменить параметры этого доступа,
такой механизм контроля называется обязательным. Но к сожалению, случайно, этот
же механизм назван был контролем доступа, основанным на правилах (rule-based
access control, RBAC), тем самым вызвав путаницу с «настоящим» механизмом RBAC.
Кроме этих моделей, известны и такие:
- модель китайской стены (The Chinese Wall Model) комбинирует элементы DAC и MAC.
- RBAC («настоящий» RBAC) – один из видов DAC моделей, но считается нейтральным
относительно выбора стратегии безопасности
- модель Biba (The Biba model) делает акцент на контроле целостности
- модель информационного потока (The Information-Flow model) обобщает идеи,
лежащие в основе MAC моделей.
2. Избирательная модель, DAC
Стратегии DAC управляют доступом субъектов к объектам на основе идентификации
субъектов, идентификации объектов и разрешений. Когда система получает запрос на
доступ, механизм контроля доступа проверяет, есть ли разрешение, уполномачивающее
субъект обращаться к объекту. Такие механизмы действуют избирательно, т.к. они
разрешают субъектам выдавать другим субъектам полномочия для доступа им нужных
объектов.
К достоинствам избирательной модели относят: гибкость в терминах определения
стратегии и поддержка всеми операционными системами и СУБД.
К недостаткам относят обычно отсутствие контроля над потоком информации (т.е.
возможны атаки «троянских коней»).
Harrison, Ruzzo и Ullman (HRU2) предложили несколько важных концепций:
- понятие системы полномочий (иначе, системы авторизации)
- понятие надежности (safety)
Для описания HRU-модели необходимо:
– S – множество субъектов
–
O – множество объектов
– R – множество прав доступа
– матрица доступа M = (Mso)sS, oO
– элемент Mso - подмножество R определяющее права, которые субъект s имеет на
объект o
1
2
Bishop M. Introduction to Computer Security.
Harrison M., Ruzzo W., Ullman J. Protection in Operating Systems. Communications of the ACM 19(8), 1976.
308816520
Спецкурс (8 семестр) «Безопасность систем баз данных»
Специальность «Информатика»
2 из 12
HRU-модель употребляет шесть примитивных операций для управления множеством
субъектов, множеством объектов и матрицей доступа:
– enter r into Mso
– delete r from Mso
– create subject s
– delete subject s
– create object o
– delete object o
Команды в HRU-модели имеют вид:
command c(x1,.....,xk)
if r1 in Ms1,o1 and
if r2 in Ms2,o2 and
.
.
.
if rm in Msm,om
then op1,.....,opn
end
Индексы s1,.....,sm и o1,.....,om – субъекты и объекты, которые появляются как
параметры команды c(x1,.....,xk). Условие команды проверяет, есть ли конкретное право
доступа, условие может быть пустым. Если все условия выполняются, тогда
выполняется и последовательность примитивных операций. Каждая команда содержит
как минимум одну операцию. Команды, содержащие ровно одну операцию, называются
моно-операционными командами.
Примеры команд для HRU-модели:
command create_file (s,f)
create f
enter o into Ms,f
enter r into Ms,f
enter w into Ms,f
end
command grant_read (s,p,f)
if o in Ms,f
then enter r into Mp,f
end
Система прикрытия (protection system) для HRU-модели определяется как конечное
множество прав и конечное множество команд. Т.о. система прикрытия является
системой состояний(state) и переходов(transition).
Под состоянием(state) в системе вообще понимают набор текущих значений всех
ячеек памяти, всех вторичных хранилищ данных, всех регистров и других компонентов
системы.
Под состоянием(state) в системе прикрытия понимают подмножество состояния
системы, являющегося матрицей доступа.
Последствия команды представляются как изменения элементов матрицы контроля
доступа (будем обозначать М’ ). Т.о. матрица доступа описывает состояние системы
прикрытия.
Определение3. Говорят, что состояние, иначе, матрица доступа М, пропускает право
r (допускает утечку права), если существует команда c, которая добавляет право r в
элемент матрицы доступа, который ранее не содержал это право.
Формально, существуют s и o, такие что rМso, а после выполнения команды c, rМso.
308816520
Спецкурс (8 семестр) «Безопасность систем баз данных»
Специальность «Информатика»
3 из 12
К состоянию в HRU-модели применимо понятие «надежности». Что это значит?
Определение4. Доступ к
собственности невозможен.
ресурсам
без
возникновения
претензий
на
право
Определение5. Пользователь должен быть в состоянии показать, будет ли то действие,
которое он собирается выполнить (например, забрать право) вести к утечке этого
права к действительно неавторизованным субъектам.
Проблема, объясняющая необходимость введения понятия надежности, такова:
«Пусть объект s планирует выдать субъекту s’ право r на объект o. Возникает вопрос, а
не может ли матрица доступа, в ее текущем состоянии, быть такой, что введение права
r в элемент Мs’ o также предполагает введение этого права в какой-нибудь другой
элемент.»
Пример ненадежной системы прикрытия:
Пусть система прикрытия построена двумя командами:
command grant_execute (s,p,f)
if o in Ms,f
then enter x into Mp,f
end
command modify_own_right (s,f)
if x in Ms,f
then enter w into Ms,f
end
Предположим, Bob разработал приложение, и он бы хотел, чтобы это приложение
пользователи могли бы запускать, но не изменять. Если теперь выданы такие
полномочия:
- Bob: grant_execute (Bob, Tom, P1)
- Tom: modify_own_right (Tom, P1)
То в матрице доступа в элементе MTom,P1 будет право w, чего изначально Bob не хотел.
Определение 6. Дана система прикрытия и право r. Говорят, что начальная
конфигурация Q0 ненадежна для r (или, допускает утечку r), если существует
конфигурация Q и команда c, такая что
- Q достижима из Q0
- команда c приводит к утечке права r.
Говорят также, что Q0 надежна для r, если неверно, что Q0 ненадежна для r.
Или:
Определение 6’. Состояние системы прикрытия, иначе говоря, ее матрица M, является
надежной по отношению к праву r, если не существует последовательности команд,
которая смогла бы перевести М в состояние, допускающее утечку права r.
Теорема.
Дана матрица доступа М и право r, проверка надежности М по отношению к праву r
является неразрешимой задачей.
Это означает, что не существует эффективного алгоритма проверки надежности
матрицы доступа. Но, в отдельных случаях, ситуация лучше.
А именно, проблема надежности разрешима для моно-операционных систем прикрытия;
разрешима для моно-условных монотонных3 систем прикрытия; неразрешима для дву3
Монотонность - …
308816520
Спецкурс (8 семестр) «Безопасность систем баз данных»
Специальность «Информатика»
4 из 12
условных монотонных систем прикрытия.
Результат разрешимости проблемы безопасности иллюстрирует важный принцип
безопасности – принцип экономии механизма:
- если проектируется сложная система, которая представлена может быть только
сложной моделью, становится сложно найти доказательства безопасности;
- в худшем случае (в случае неразрешимости), универсального алгоритма проверки
безопасности для всех возможных случаев не существует.
Другие теоретические модели:
- модель «взять-выдать» (“take-grant” model, Jones A., Lipton R., Snyder L.)
- модель схематического прикрытия (Sandhu R.)
- модель типизированной матрицы доступа (Sandhu R.)
Модель DAC широко исследована в области СУБД, более того, первая DAC модель была
разработана для реляционных баз данных (Griffiths и Wide).
Разработано много расширений этой модели.
Гибкость модели DAC придается с помощью введения разных типов разрешений:
позитивных и негативных, сильных и слабых, неявных и явных, контекст-зависимых.
Рассмотрим вкратце каждую пару типов разрешений.
Начнем с позитивных и негативных разрешений. Позитивные разрешения – на
выдачу разрешения, негативные разрешения – на запрет. Такие разрешения полезны
для определения исключений из стратегии безопасности и для усиления контроля над
отдельным критически важным элементом данных.
При использовании негативных разрешений главная проблема – это конфликты
авторизации:
+
Главная проблема:
Конфликт
Главными решениями являются:
- вообще не допускать конфликтов
- преимущество при обработке отдается негативным разрешениям
- преимущество при обработке отдается позитивным разрешениям
- преимуществ нет
- наиболее детальным разрешениям отдается преимущество
Обратимся к слабым и сильным разрешениям.
Сильные разрешения не могут быть переопределены. Слабые разрешения – могут быть
переопределены другими слабыми или сильными разрешениями.
Неявные и явные разрешения.
Некоторые модели контроля доступа поддерживают т.н. неявные разрешения. Неявные
разрешения могут быть вычислены/порождены либо с помощью множества правил
распространения (propagation rules), вовлекающих иерархии субъектов, объектов и
полномочий, либо с помощью правил порождения (derivation rules).
308816520
Спецкурс (8 семестр) «Безопасность систем баз данных»
Специальность «Информатика»
5 из 12
Пример правил порождения:
«Ann может читать файл F1 из таблицы, если Bob имеет явный запрет на эту
операцию».
«Tom имеет для файла F2 все те же привилегии, что и Bob».
Правила порождения есть способ явно выразить множество требований безопасности.
Эти правила часто выражены с помощью различных средств логического
программирования. Для этих целей проводились сравнительные исследования
выразительной силы разных языков. Наиболее приемлемыми все же будут языки
наподобие или основанные на SQL или на XML.
Контекст-зависимые разрешения.
Контекст-зависимый контроль доступа позволяет изменять разрешения на доступ к
объекту в зависимости от контекста, в котором употребляется этот объект.
Такой способ доступа более применяется в СУБД. Например, в РСУБД, поддерживающей
контекст-зависимый контроль доступа, возможно разрешить субъекту доступ к
информации только если этим субъектом является сотрудник с уровнем зарплаты не
выше 30 000 у.е., и т.д.
Применение контекст-зависимого подхода в СУБД может быть организовано с помощью:
- привязки предиката (или булевой комбинации предикатов) к разрешениям
- определения представления (вида, view), в котором выбирать объекты, чей контекст
удовлетворяет некоему условию, и затем выдачи разрешения на это представления,
вместо разрешения на объект.
DAC модели - для СУБД или для ОС?
В СУБД DAC модели позволяют защитить большее количество объектов, на разном
уровне (на уровне отношений, кортежей, отдельных атрибутов), защитить логическую
структуру (отношений, представлений) вместо защиты физических файлов, на разных
уровнях СБД можно применить разные требования безопасности, разную защиту можно
организовывать на основании семантики данных.
«Троянские программы»
Процесс P
……………
read O1
……………
……………
write O2
O1
(Ada,r,O1)
O2
(Ada,r,O2), (Ada,w,O2),
(Bob,r,O2)
DAC модели неспособны защитить данные от троянских программ, встроенных в
приложения. Поэтому, были разработаны MAC модели.
Обязательная модель контроля доступа
MAC модель определяет разрешение на доступ, который субъекты могут применить к
объектам, на основании классификации субъектов и объектов.
308816520
Спецкурс (8 семестр) «Безопасность систем баз данных»
Специальность «Информатика»
6 из 12
Этот тип безопасности также называют многоуровневой безопасностью (multilevel
security).
СУБД, удовлетворяющие критериям многоуровневой безопасности, называются СУБД с
многоуровневой безопасностью (MLS/DBMSs). В основе многих таких СУБД лежит
модель Белла и Ла Падулы (Bell and La Padula Model, BLP).
Модель Белла и Ла Падулы
Элементами модели являются:
- объекты – пассивные сущности, содержащие информацию, нуждающуюся в скрытии
- субъекты – активные сущности, требующие доступа к объектам (пользователи,
процессы)
- режимы доступа (access modes) – типы операций, выполняемых субъектами над
объектами:
- read - операция чтения
- append – операция модификации
- write – одновременно и чтение и модификация
Субъектам назначены уровни очистки (clearance), и субъекты могут работать только
на уровнях выше либо равных назначенного им уровня очистки.
Объектам назначены уровни чувствительности (sensitivity).
Уровни очистки и уровни чувствительности вместе называются классами доступа.
Класс доступа состоит из двух компонентов: уровня безопасности и множества
категорий.
Уровень безопасности – это элемент полностью упорядоченного множества.
Например,
{Top Secret (TS), Secret (S), Confidential (C), Unclassified (U)},
где TS > S > C >U
Множество категорий – это множество элементов, зависящих от области приложения, в
которой данные должны использоваться.
Например,
{Army, Navy, Air Force, Nuclear}
Класс доступа ci = (Li, SCi) доминирует над классом доступа ck = (Lk, SCk),
обозначается как ci ≥ ck, если выполняются два условия:
–
–
Li ≥ Lk
уровень безопасности ci больше или равен уровню безопасности ck
SCk  SCi множество категорий ci включает в себя множество категорий ck
Если Li ≥ Lk и SCk  SCi, будем говорить, что ci строго доминирует над ck .
ci и ck называются несравнимыми (ci <> ck), если ни ci ≥ ck, ни ck ≥ ci.
Например.
Даны классы доступа
c1 = (TS, {Nuclear, Army})
c2 = (TS, {Nuclear})
c3 = (C, {Army})
• c1 ≥ c2
• c1 > c3
(TS > C and {Army}  {Nuclear, Army})
• c2 < > c3
Состояние системы описывается парой (A, L), такой что:
- A – множество текущих доступов: троек вида (s,o,m), где субъект s изучает
возможность доступа m к объекту o, например, (Bob, o1, read)
- L – функция уровня: она связывает с каждым элементом системы его класс доступа.
Так, если О – множество объектов, S – множество субъектов, C – множество классов
доступа, тогда функция уровня L : O  S  C
308816520
Спецкурс (8 семестр) «Безопасность систем баз данных»
Специальность «Информатика»
7 из 12
На BPL модели введены несколько «аксиом» (они лишь ограничивают применение
функций уровня).
Свойство простой безопасности (no-read-up): состояние (A, L) удовлетворяет
свойству простой безопасности, если для каждого элемента a=(s,o,m)  A выполняется
одно из следующих условий:
1. m = append
2. m = read или m=write и L(s) ≥ L(o)
Например, субъект с классом доступа (C, {Army}) не может просмотреть объекты с
классами доступа (C, {Navy, Air Force}) или (U, {Air Force}).
Свойство простой безопасности предупреждает попытки субъектов просматривать
данные с классами доступа доминирующими или несравнимыми с классом доступа
субъекта. Т.о. гарантируется, что субъекты имеют доступ только к той информации, для
которой у них есть необходимый класс доступа.
Свойство * (звездочка, no-write-down): состояние (A, L) удовлетворяет свойству *
если для каждого элемента a=(s,o,m)  A выполняется одно из следующих условий:
1. m = read
2. m = append и L(o) ≥ L(s)
3. m = write и L(o) = L(s)
Например, субъект с классом доступа (C, {Army, Nuclear}) не может просмотреть
объекты с классами доступа (U, {Army, Nuclear}).
Свойство * предупреждает потоки информации к объектам с более низким классом
доступа или к объектам с несовместимыми классами доступа.
Для системы безопасности оба свойства ДОЛЖНЫ выполняться в любом состоянии
системы.
Итак, еще раз:
– свойство простой безопасности – субъект имеет доступ на чтение объекта если его
класс доступа доминирует над классом доступа объекта;
– свойство * - субъект имеет право записи в объект, если класс доступа субъекта
доминирует над классом доступа объекта.
Тем не менее, даже в таком виде BPL модель не свободна от недостатков.
Пример:
Полковник имеет уровень очистки (Secret, {Nuclear, Army}).
Майор имеет уровень очистки (Secret, {Army}).
Полковник должен послать письмо майору. Полковник не может создать/записать
документ который бы имел класс доступа (Secret, {Army}), поскольку такой документ
нарушит свойство *(!).
Для того, чтобы решить эту проблему, в BPL модели предусмотрен механизм: каждый
субъект имеет максимальный класс доступа и текущий класс доступа с такими
особенностями: субъект может изменить свой класс доступа; текущий класс доступа
должен быть доминированным максимальным классом доступа.
Пример применения этой модели реализован в DG/Unix системе B2.
В2 как известно – это класс оценки безопасных систем, определенный как часть
документа TCSEC (Trusted Computer System Evaluation Criteria, Критерии Оценки
Доверительных Компьютерных Систем), известного также как Оранжевая книга (Orange
Book).
DG/Unix предоставляет средства обязательного контроля доступа
- метка MAC обозначает уровни безопасности
- эти метки расставляются по умолчанию, но можно определять другие метки.
Первоначально,
- процессам (пользователям) назначается MAC метка «родителя». Начальные
метки назначенные пользователям, хранятся в базе данных авторизации и
аутентификации.
- Объектам назначаются метки по создании. Явные метки хранятся как часть
308816520
Спецкурс (8 семестр) «Безопасность систем баз данных»
Специальность «Информатика»
8 из 12
атрибутов, неявные метки определяются по родительскому каталогу.
Проблема каталога.
Процесс p, обладающий классом доступа MAC_A, пытается создать файл /tmp/readme.
Файл /tmp/readme существует, но имеет класс доступа MAC_В. Допустим, MAC_В
доминирует над MAC_А (MAC_В ≥ MAC_А). Создание файла невозможно, но теперь
процесс р знает, что файл с именем readme существует и имеет больший класс доступа,
что не всегда допустимо.
Предпринимается действие, блокирующее подобные выводы: только программы с
классом доступа таким же как у каталога, могут создавать файлы.
Но такое действие и ограничение – слишком жесткие (Почему?)
Решением может быть такое: в каталоге заведено множество подкаталогов, по одному
на каждый класс доступа. Т.о. пользователю видны каталоги, соответствующие его
классу доступа. И когда процесс р создает /tmp/readme, на самом деле создается
/tmp/dir/readme, где dir – каталог, соответствующий классу MAC_A. Все обращения
процесса р к /tmp на самом деле относятся к /tmp/dir.
Такая проблема каталогов иллюстрирует важный момент: иногда недостаточно просто
скрыть содержимое объекта. Существование этого объекта тоже может быть скрытым.
Подводя итог рассмотрения модели Белла и Ла Падулы, отметим, что это очень
значимая модель, используемая и в СУБД, и в ОС. К критике модели можно отнести
такие:
- она имеет дело только с конфиденциальностью, но не с целостностью
- в модели могут быть скрытые (covert) каналы.
Скрытые каналы.
Скрытый
канал
позволяет
передавать
информацию,
нарушая
стратегию
многоуровневой безопасности.
Такой канал – это поток информации, неконтролируемый механизмом безопасности.
Скрытые каналы разделяют на две большие категории: каналы времени (timing
channels) и каналы хранения (storage channels).
В каналах времени информация переносится по некоторому расписанию событий или
процессов. В каналах хранения не требуется временной синхронизации, и информация
передается путем обращения к системной информации.
Например,
Хорошо известный скрытый канал основан на использовании 2PL контроля
конкуренции.
Даны две транзакции, T_low и T_high, соответственно низкого и высокого классов
доступа. Рассмотрим элемент данных d1, имеющий низкий класс доступа. Допустим,
других транзакций в данный момент нет.
Пусть транзакция T_high запрашивает блокировку чтения на d1. Такая блокировка
разрешена, т.к. других транзакций пока нет.
Пусть теперь транзакция T_low желает изменить/записать этот же элемент данных. Она
запрашивает блокировку чтения на d1.
Поскольку транзакция T_high удерживает блокировку чтения на d1, транзакция T_low
должна ждать, пока T_high не освободит d1. Т.о. выборочными запросами на чтение
данных с низким классом доступа, транзакция T_high может регулировать задержки в
работе транзакции T_low.
Поскольку T_high также имеет полный доступ к данным с высоким классом доступа, эти
задержки могут использоваться транзакцией T_high для передачи информации с
высоким классом доступа транзакции T_low (!). Таким образом, образуется временной
канал между двумя транзакциями.
Механизм контроля доступа, предложенный в BPL модели, не защищен против атак
через скрытые каналы. Т.о. многоуровневые системы защиты должны разрабатываться
с требованием закрытия всех скрытых каналов.
Проблема разработки алгоритмов контроля доступа свободных от временных каналов
широко изучалась. Например, в Trusted Oracle используется механизм синхронизации,
308816520
Спецкурс (8 семестр) «Безопасность систем баз данных»
Специальность «Информатика»
9 из 12
основанный на 2PL в комбинации с технологиями мультиверсионности. Однако было
доказано, что такой алгоритм не генерирует сериализуемых историй.
Другие модели контроля доступа.
Модель «Китайская стена» (The Chinese Wall)
Модель фокусируется на решении проблемы конфликта интересов.
Конфликт интересов – проблема, известная в финансовом мире. Допустим, есть некий
аналитик рынка (маркетолог), работающий в финансовой фирме, предоставляющей
услуги для бизнес структур. Аналитик должен сберегать конфиденциальность
информации, данной ему клиентами фирмы; это означает, что аналитик не может
давать советы корпорациям, для которых ему известна внутренняя информация об их
конкурентах. В то же время, этот аналитик вполне свободно может давать
рекомендации корпорациям, которые не являются конкурентами, а также
предоставлять общую информацию о состоянии рынка.
Стратегия Китайской стены предложена Brewer и Nash в 1989 году. Мотивацией
работы было исключение ситуации, когда чувствительная информация о компании
раскрывается
конкурирующим
компаниям
через
посредничество
финансовых
консультантов.
Идея стратегии – динамически устанавливать права доступа пользователю в
зависимости от того, к чего пользователь уже имел доступ.
Субъектами стратегии являются: активные сущности, обладающие защищенными
объектами.
Объектами – данные, организованные в соответствии с тремя уровнями:
- информация
- множества данных (dataset)
- классы конфликтов интересов (Conflict-of-Interest, CoI)
Правами доступа являются правила чтения и правило записи.
Классификация данных
Правило чтения
Субъект S имеет право чтения на объект О, если:
- О находится в том же множестве данных, что и объект, к которому уже обращался S.
или
- О принадлежит к CoI, из которого S еще не получал никакой информации.
Например, для Джона:
Сравнение с моделью Bell-La Padula:
Стратегия Китайской стены – комбинация свободного выбора и обязательного контроля
Вначале субъект свободно обращается к тому объекту, к которому он хочет. Как только
первый выбор сделан, для этого субъекта строится Китайская стена вокруг того
множества данных, к которому принадлежит объект.
Такая стратегия комбинируется со стратегиями DAC.
Правило записи.
Правило чтения не защищает от скрытых потоков информации. Например,
Джон имеет доступ к Oil A и Bank B. Джейн имеет доступ к Oil B и Bank A. Если Джон
разрешено чтение Oil A и запись в Bank A, он может передавать информацию об Oil A
которая затем может быть прочитана Джейн.
308816520
Спецкурс (8 семестр) «Безопасность систем баз данных»
Специальность «Информатика»
10 из 12
Итак,
Субъект S имеет право записи на объект О, если
- S может читать О в соответствии с правилом чтения
и
- ни один объект не был прочитан S из другого множества данных по отношению к тому
множеству данных, куда осуществляется запись.
Т.о. в соответствии с правилом записи: поток информации ограничен множеством
данных одной компании, владеющей этим потоком.
Brewer и Nash обнаружили, что аналитики должны быть в состоянии сравнивать
информацию, которая у них есть, с такой же информацией из других корпораций. Было
предложено решение, чтобы ограничения доступа были повышены для санированной
(sanitized) информации.
Модель Китайской стены имеет некоторые недостатки, например правило записи
является очень сильным ограничением, во-первых. поскольку пользователь, который
читает объекты из более чем одного множества данных, не обладает правом записи ни
на один объект, и во-вторых, пользователь имеет права чтения и записи только на одно
множество данных.
Модель контроля доступа, основанная на ролях (Role Based Access Control,
RBAC).
Одной из актуальнейших проблем при управлении большими системами является
сложность администрирования системы безопасности. Как только количество субъектов
и объектов становится большим, количество авторизаций становится сверхбольшим.
Более того, если сообщество пользователей – динамично, количество операций
grant/revoke становится крайне трудно обрабатывать.
Конечные пользователи часто не являются владельцами информации, к которой им
разрешен доступ. Реальным владельцем объектов данных является фирма или
корпорация.
Контроль часто основывается на функциях сотрудников, а не владении данными.
В качестве альтернативы подходам DAC и MAC предлагается подход RBAC – для того,
чтобы упростить задачу управления контролем доступа и обеспечить функциональноориентированный контроль доступа.
Базовые концепции RBAC:
Роли представляют функции внутри данной организации. Авторизации выдаются не
конктерным пользователям, а ролям.
Пользователи, т.о. просто авторизуются чтобы «играть» соответствующую роль, и
выполняют авторизацию для роли.
К достоинствам RBAC можно отнести такие:
- поскольку роли представляют организационные функции, модель RBAC прямо
поддерживает стратегии безопасности организации
- выдача и отзыв авторизаций пользователя значительно упрощается
- RBAC модели являются стратегия-независимыми.
Поставщики СУБД давно используют в своих продуктах элементы модели RBAC с разной
степенью реализации. Отчасти благодаря этому, существует некая договоренность о
стандарте на модель RBAC. Например, модель NIST [Sandhu, Ferraiolo, Kunn, 2000]
является первым претендентом на такой стандарт. Другим претендентом является
модель ANSI. American national standard for information technology – role based access
control. ANSI INCITS 359-2004, February, 2004.
Модель NIST.
308816520
Спецкурс (8 семестр) «Безопасность систем баз данных»
Специальность «Информатика»
11 из 12
Различает три главных уровня возрастающих возможностей:
- базовый RBAC, еще называемый плоским (flat)
- иерархический RBAC
- RBAC с ограничениями (constrained)
Базовыми понятиями RBAC являются пользователь, роль, разрешение и сессия.
Пользователь – определяется как человек, машина, процесс, интеллектуальный
автономный агент, и т.п.
Роль – определяется как функция внутри контекста организации с ассоциированной
семантикой, учитывающей уровень (authority) и ответственности (responsibility).
Разрешение (permission) – это режим доступа, который может быть применен к
объектам в системе. И объекты и режимы доступа – домен-независимы. Например, в
случае с базой данных, множество объектов включает таблицы, столбцы, строки, а
режимы доступа – операции добавления, обновления и удаления.
Сессия – это конкретный экземпляр соединения пользователя с системой, который
определяет подмножество активированных ролей. В каждый момент времени, один
пользователь может активировать разные сессии. При входе пользователя в систему,
ему сопоставляется некоторая сессия, и в течение этой сессии пользователь может
потребовать активизации одной или нескольких ролей из тех, для которых у него есть
авторизация. Пользователь получает все разрешения, ассоциированные с ролью, как
только создается сессия.
Базовый RBAC.
Разрешения
Множества, функции и отношения
Сессии
Понятие сессии довольно абстрактно: «отображение между пользователем и
активированным подмножеством ролей, которые назначены пользователю».
Отличия касаются количества одновременно активируемых ролей:
- активируется единственная роль (single-role activation, SRA)
- активируется несколько ролей (multiple-role activation, MRA) – в одной сессии
может активироваться несколько ролей и для ограничения параллельной
активации некоторых ролей может использоваться динамическое разделение
обязанностей.
Иерархический RBAC.
Иерархии ролей – естественный способ организовать роли для отображения структуры
организации относительно authority и ответственности.
Модель
Пример иерархии ролей
Семантика
Наследование
пользователей
(user
inheritance,
UI):
все
пользователи,
авторизованные на роль r также авторизуются на любую роль r’: r  r’.
Наследование разрешений (permission inheritance, PI): роль r авторизована для всех
разрешений, для которых любая роль r’, такая что r  r’ – авторизована.
Наследование активаций (activation inheritance, AI): активация роли r автоматически
активируется все роли r’, такие что r  r’. Такой способ наследования может
использоваться только если разрешены MRA-сессии.
RBAC с ограничениями
308816520
Спецкурс (8 семестр) «Безопасность систем баз данных»
Специальность «Информатика»
12 из 12
RBAC с ограничениями – это модель RBAC с возможностью поддержки стратегий
разделения обязанностей (separation of duties, SoD).
Ограничения могут быть
статическими (static SoD) и динамическими (dynamic SoD).
Стратегии разделения обязанностей усиливают стратегию конфликта интересов,
используемую для предотвращения попыток пользователя превысить обоснованный
уровень авторизации, соответствующий их должности. Также, стратегии разделения
обязанностей гарантируют, что все ошибки, связанные с запретами внутри
предприятия, имеют причины только в коллизиях между индивидуалами.
Определения стратегии разделения понятия:
Определение ANSI: «разделение ответственности для чувствительной информации
таким образом, что ни один индивидуал, действуя в одиночку, не сможет
скомпрометировать безопасность системы обработки данных»
Определение (циркуляр А-123 госкомитета США по Управлению и Бюджету) US Office of
Management and Budget’s Circular A-123: «Ключевые обязанности и ответственности
при авторизации, обработке, записи и просмотре внутриофисных транзакций
госкомитета должны быть распределены между индивидуалами».
Статические ограничения при разделении обязанностей:
- устанавливают ограничения на множество ролей и в частности на из возможность
формировать RA отношения
- никакому пользователю не может быть назначено t или более ролей во множестве
ролей m
- предотвращают возможность конкретному индивидуалу быть авторизованным на
выполнения слишком многих ролей.
- эти ограничения могут быть усилены в зависимости от пользователей, назначенных
на каждую роль.
Динамические ограничения при разделении обязанностей:
- устанавливают лимит количества ролей, которые пользователь может активировать в
одной сессии
Например,
- ни один пользователь не может активировать
t или более ролей из
множества ролей внутри одной сессии этого пользователя
- если пользователь использовал роль r1 в некоторой сессии, он не может
использовать роль r2 в этой же сессии
Спецификация функций и администрирования системы в RBAC
Административные операции: создание, удаление и поддержка элементов и отношений.
Административные обзоры: запросы.
Функции системного уровня: создание сессий пользователей, активация/деактивация
ролей, применение ограничений, вычисление решений о доступе.
308816520