- Модели управления доступом
- Дискреционное управление доступом
- Мандатное управление доступом
- Метки критичности
- Ролевое управление доступом
- Ядро RBAC
- Иерархический RBAC
Модель управления доступом – это структура, которая определяет порядок доступа субъектов к объектам. Для реализации правил и целей этой модели используются технологии управления доступом и механизмы безопасности. Существует три основных модели управления доступом: дискреционная, мандатная и недискреционная (также называемая ролевой). Каждая модель использует различные методы для управления доступом субъектов к объектам, каждая имеет свои преимущества и ограничения. Выбор оптимальной модели управления доступом следует производить на основе целей бизнеса и целей безопасности компании, а также на основе ее культуры и стиля управления бизнесом. Некоторые компании используют только одну модель, другие комбинируют их для получения необходимого уровня защиты.
Эти модели встроены в ядро различных операционных систем и во многих случаях поддерживаются приложениями. Каждая операционная система имеет ядро безопасности, которое реализует концепцию монитора обращений (reference monitor), которая зависит от встроенной в систему модели управления доступом. Для каждой попытки доступа, перед тем, как субъект сможет начать взаимодействовать с объектом, ядро безопасности проверяет правила модели управления доступом, чтобы определить, является ли запрос допустимым. В следующих разделах будет рассказано про эти различные модели доступа, поддерживающие их технологии и о том, когда их следует применять.
Если пользователь создает файл, он является владельцем этого файла. Идентификатор этого пользователя размещается в заголовке файла. Владение может быть также предоставлено определенному человеку. Система, которая использует дискреционное (избирательное) управление доступом (DAC – Discretionary Access Control) позволяет владельцу ресурса определять, какие субъекты могут использовать этот ресурс. Эта модель называется дискреционной (избирательной), т.к. управление доступом основано на решениях владельца. Часто руководители подразделений являются владельцами данных в рамках своих подразделений. Будучи владельцами, они могут решать, кому следует, а кому не следует иметь доступ к этим данным.
В модели DAC ограничения доступа основываются на авторизации пользователя. Это означает, что владельцы могут определять, какой тип доступа может быть разрешен к их объектам. Если компания использует модель DAC, сетевой администратор может разрешить владельцам ресурсов управлять доступом пользователей к своим ресурсам. Чаще всего модель DAC реализуется посредством списков контроля доступа (ACL), содержимое которых определено владельцами. Работа ACL реализуются средствами операционной системы. Это может позволить пользователям использовать информацию динамически вместо более статичного мандатного или ролевого управления доступом. Большинство операционных систем основаны на модели DAC (например, системы Windows, Linux, Macintosh и большинство систем *nix).
DAC может быть применен как к древовидной структуре директорий, так и к файлам, которые в них содержатся. Мир персональных компьютеров использует такие разрешения доступа, как «Нет доступа» (No Access), «Чтение» (Read), «Запись» (Write), «Выполнение» (Execute), «Удаление» (Delete), «Изменение» (Change), «Полный доступ» (Full Control). К примеру, атрибут «Чтение» позволяет читать файл, но не вносить в него изменения; атрибут «Изменение» позволяет читать, записывать, выполнять и удалять файл, но не менять его ACL или владельца файла; атрибут «Полный доступ» позволяет производить любые действия с файлом, разрешениями на доступ к нему и владением им.
Посредством дискреционной модели, например, Сэм может предоставить совместный доступ к диску D на своем компьютере Дэвиду, а Дэвид может скопировать с него все MP3 Сэма. При этом Сэм может заблокировать доступ к своему диску D для своего начальника, чтобы тот не знал, что Сэм тратит время и ресурсы на скачивание музыки и ее раздачу своим друзьям.
Ссылки по теме:
- A Guide To Understanding Discretionary Access Control in Trusted Systems
- Mandatory Versus Discretionary Access Control
- Discretionary Access Control
Управление доступом на основе идентификатора. Системы DAC предоставляют, либо отказывают в доступе на основе идентификации субъекта. Идентификация может быть как на уровне пользователя, так и на уровне его членства в группе. Так, например, владелец данных может предоставить доступ к своему файлу Бобу (идентификатор пользователя) и группе «Бухгалтерия» (идентификатор группы).
В модели мандатного управления доступом (MAC – Mandatory Access Control) пользователи и владельцы данных не могут самостоятельно определять, кто может иметь доступ к файлам. Окончательное решение принимает операционная система, и это решение может не совпадать с желаниями пользователя. Эта модель является более структурированной и жесткой, она основана на системе меток безопасности (security label). Пользователи получают уровни допуска (секретно, совершенно секретно, конфиденциально и т.д.), таким же способом классифицируются данные. Допуски и классы данных сохраняются в метках безопасности и являются границами для субъектов и объектов. Когда система принимает решение в процессе выполнения запроса на доступ к объекту, она основывается на уровне допуска субъекта, классификации объекта и политике безопасности системы. Правила доступа субъектов к объектам разрабатываются офицером безопасности, настраиваются администратором, реализуются операционной системой и поддерживаются технологиями безопасности.
Метки безопасности прикрепляются ко всем объектам, каждый файл, директория, устройство имеют свою метку безопасности, содержащую информацию о классе их информации. Например, если пользователь имеет уровень допуска «Секретно», а запрашивает информацию класса «Совершенно секретно», он получит отказ, поскольку его допуск не равен (и не выше) классификации.
ПРИМЕЧАНИЕ. Термины «метка безопасности» (security label), «метка критичности» и «метка чувствительности» (sensitivity labels) являются взаимозаменяемыми.Каждый субъект и объект всегда должен иметь связанную с ним метку с атрибутами, поскольку это является частью критериев принятия решения операционной системой.
Эта модель применяется в среде, в которой классификация информации и конфиденциальность чрезвычайно важны, например, в военных организациях. На базе этой модели разработаны специализированные версии Unix-систем, например, SE Linux, Trusted Solaris. Компании не могут просто переключаться между использованием DAC и MAC. Им потребуется специально приобрести для этого операционную систему, спроектированную и реализующую правила MAC. Системы DAC не понимают меток безопасности, классификации, уровней допуска и поэтому не могут применяться в организациях, которым нужна такая структура управления доступом.
Ссылки по теме:
Метки критичности
Когда используется модель MAC, каждый субъект и объект должен иметь метку критичности, также называемую меткой безопасности. Эта метка указывает на классификацию и различные категории. Классификация указывает на уровень критичности, а с помощью категорий реализуется принцип «необходимо знать» (need-to-know). Метка критичности показана на рисунке 2-10. Если кто-то имеет допуск к «совершенно секретной» информации, это вовсе не означает, что ему «необходимо знать» всю информацию с грифом «совершенно секретно».
Рисунок 2-10.Метка критичности состоит из классификации и категорий
Классификация использует иерархическую структуру, в которой один уровень является более доверенным, чем другой. Категории не используют иерархическую структуру, они представляют собой отдельные виды информации в рамках системы. Категории могут соответствовать структуре подразделений компании, проектам или уровням должностей. Классификация проводится по степени конфиденциальности информации, она зависит от среды, в которой работает компания.ПРИМЕЧАНИЕ. В реализациях MAC, система принимает решение о возможности доступа, сравнивая уровень допуска субъекта и уровень «необходимо знать» с меткой безопасности. В DAC система сравнивает идентификатор субъекта со списком ACL ресурса.Программные и аппаратные охранные средства (guard) позволяют обмениваться данными между доверенными (высокий уровень гарантий) и менее доверенными (низкий уровень гарантий) системами и средами, выполняя функции посредника между ними. Например, вы работаете на системе MAC (работающей в выделенной модели безопасности на уровне «Секретно») и вам нужно взаимодействовать с базой данных MAC (работающей в многоуровневом режиме безопасности, достигающем уровня «Совершенно секретно»). Эти две системы могут обеспечивать различные уровни защиты, и, если менее доверенная система будет напрямую взаимодействовать с более доверенной, в системе безопасности появятся уязвимости и повысятся риски компрометации. Программные охранные средства позволяют взаимодействовать системам, работающим на разных уровнях безопасности. Различные их виды могут применяться для выполнения фильтрации, обработки запросов, блокировки и обезличивания данных. Также существуют аппаратные охранные средства, представляющие собой устройства с двумя сетевыми картами, подключенными к двум разным системам, которым нужно взаимодействовать между собой. Охранные средства могут использоваться для соединения различных систем MAC или сетей, работающих в разных режимах безопасности и на разных уровнях безопасности. В большинстве случаев, менее доверенные системы могут отправлять сообщения более доверенным системам, но в обратном направлении они могут принимать только подтверждения о доставке.
Модель ролевого управления доступом (RBAC – Role-based Access Control), также называемая недискреционным управлением доступом (Nondiscretionary Access Control), использует централизованно администрируемый набор контролей, предназначенных для определения порядка взаимодействия субъекта с объектом. Этот тип модели разрешает доступ к ресурсам, основываясь на роли пользователя в компании. Это называют недискреционным подходом, поскольку назначение пользователю роли является неизбежным. Это означает, что если вам в компании назначена роль «Подрядчик», вы ничего с этим сделать не можете. Вы не определяете самостоятельно, какая роль вам будет назначена.
Более традиционное администрирование прав доступа основано на модели DAC, в которой управление доступом происходит на уровне объекта с использованием ACL. Этот подход более сложен, т.к. администратор должен перевести организационную политику компании в разрешения при настройке ACL. С ростом количества объектов и пользователей в компании у многих пользователей появляются (или остаются после изменения обязанностей) права доступа к некоторым ресурсам, которые им не требуются для работы. Это нарушает принцип минимальных привилегий и увеличивает риски компании. Подход RBAC позволяет избежать этого, так как разрешения управляются на уровне должностных ролей. В модели RBAC роль определяется в терминах операций и задач, которые она выполняет, тогда как в модели DAC описывается, какие субъекты могут иметь доступ к каким объектам.
Например, нам нужна роль аналитика. Мы разрабатываем эту роль, позволяя ей иметь доступ ко всем видам продукции и данным тестирования, а также, что более важно, определяем задачи и операции, которые эта роль может выполнять с этими данными. Когда пользователь, которому присвоена эта роль «Аналитик», делает запрос на доступ к новым результатам тестирования на файловом сервере, операционная система в фоновом режиме просматривает уровень доступа роли, прежде чем эта операция будет разрешена.
ПРИМЕЧАНИЕ. Введение ролей показывает разницу между правами, назначенными явно и неявно. В явном виде права и разрешения назначаются непосредственно конкретному пользователю. В неявном виде они назначаются роли или группе, а пользователь просто наследует эти полномочия.Модель RBAC лучше всего подходит для компаний с большой «текучестью» кадров. Если увольняется сотрудник, которому была назначена определенная роль, то новому сотруднику, который займет его место, просто назначается та же роль. Таким образом, администратору не нужно постоянно вносить изменения в ACL отдельных объектов. Ему достаточно создать определенные роли, настроить необходимые этим ролям права и разрешения, а затем назначить пользователям эти роли.
Ядро RBAC
Этот компонент должен быть интегрирован в каждую реализацию RBAC, т.к. это основа данной модели. Пользователи, роли, разрешения, операции и сессии определяются на основании политики безопасности.
- Имеются отношения «многие-ко-многим» между отдельными пользователями и привилегиями.
- Сессия является соответствием между пользователем и подмножеством назначенных ему ролей.
- Применяется традиционное, но более надежное управление доступом на основе групп.
Это надежная модель, поскольку она может включать другие компоненты в процесс принятия решений о возможности доступа, а не просто основываться на учетных данных. Например, система RBAC может учитывать время дня, местоположение роли, день недели и т.д.
Иерархический RBAC
Этот компонент позволяет администратору создать организационную модель RBAC на основе организационной структуры и функциональных разграничений, требующихся в конкретной среде. Это очень полезно, поскольку в компаниях уже есть иерархические структуры персонала. Чаще всего, чем выше вы находитесь в организационной иерархии компании, тем больше прав доступа вы имеете.
1. Ролевые отношения определяют членство пользователя в группах и наследование привилегий. Например, роль «Медсестра» может получить доступ к одному набору файлов, а роль «Лаборант» – к другому. Роль «Доктор» наследует разрешения и права доступа из обеих этих ролей и имеет дополнительные права, назначенные непосредственно роли «Доктор». Таким образом, иерархия накапливает права и разрешения различных ролей.
2. Отражает организационную структуру и функциональные разграничения.
3. Существует два типа иерархий:
- Ограниченные иерархии. Доступен только один уровень иерархии (например, Роль 1 наследует права Роли 2, но не других ролей).
- Обычные иерархии. Доступно много уровней иерархии (например, Роль 1 наследует права Роли 2 и Роли 3).
- Статическое разделение обязанностей (SSD – Static Separation of Duty) посредством RBAC. Это может использоваться для предотвращения мошенничества, предоставляя постоянный ограниченный набор привилегий (например, пользователь не может быть одновременно членом групп «Кассир» и «Контролер»).
- Динамическое разделение обязанностей (DSD – Dynamic Separation of Duties) посредством RBAC. Это может использоваться для предотвращения мошенничества, предоставляя ограничение набора возможных привилегий в рамках одной сессии (например, пользователь не может в рамках одной сессии использовать права «Кассира» и «Контролера», хотя он может быть одновременно членом обеих этих групп). Это немного сложнее. Рассмотрим пример: пользователь является одновременно членом групп «Кассир» и «Контролер», однако, если он входит в систему в качестве кассира, ему недоступны права контролера и наоборот.
- Не-RBAC. Назначение прав пользователям производится напрямую в приложениях, роли не используются.
- Ограниченное RBAC. Пользователям назначены несколько ролей, а также отдельные права в приложениях, которые не имеют функциональности ролевого управления доступом.
- Гибридное RBAC. Пользователям назначены роли, связанные с различными приложениями. Этим ролям назначены только выбранные права.
- Полное RBAC. Пользователям назначены корпоративные роли.
- Role-Based Access Control
- Role-Based Access Control Case Studies
- Role-Based Access Control on the Web
- “A Role-Based Access Control Model and Reference Implementation Within a Corporate Intranet,” by John Barkley, D. Richard Kuhn, and David Ferraiolo (first published in ACM Transactions on Information and System Security, Vol. 2, No. 1, Feb. 1999, pp. 34–64)
RBAC, MAC, DAC. Много путаницы возникает в отношении того, является ли RBAC разновидностью модели DAC или MAC. Различные источники содержат разную информацию на этот счет, но фактически RBAC является самостоятельной моделью. В 1960-х – 1970-х годах американские военные и NSA проводили много исследований модели MAC. Появившаяся в то же время модель DAC имеет свои корни в академических и коммерческих лабораториях. Модель RBAC, которая начала набирать популярность в 1990-е годы, может использоваться в комбинации с системами MAC и DAC. Получить наиболее актуальную информацию о модели RBAC можно по адресу: http://csrc.nist.gov/rbac, где размещены документы с описанием стандарта RBAC и независимой модели, с целью прояснить прояснения этой постоянной путаницы.
Модели управления доступом. Важно понимать основные характеристики трех моделей управления доступом:
- DAC – владельцы данных решают, кто имеет доступ к ресурсам. Политика безопасности реализуется с помощью ACL.
- MAC – политика безопасности реализуется операционной системой посредством меток безопасности.
- RBAC – решения о предоставлении доступа принимаются системой на основании ролей и/или должностей субъектов.
ПРИМЕЧАНИЕ. В наше время, конфиденциальность многих типов данных нуждается в защите, поэтому многие компании имеют в штате офицеров безопасности конфиденциальных данных и разрабатывают политики конфиденциальности. Современные модели управления доступом (MAC, DAC, RBAC) сами по себе не обеспечивают защиту критичных данных, вместо этого они ограничивают функции, которые пользователи могут выполнять с этими данными. Например, всем менеджерам может быть предоставлен доступ к папке, содержащей конфиденциальную информацию, но более детальные права доступа могут указывать, что они могут читать информацию о домашнем адресе клиента, но не видят его паспортные данные. Это называется ролевым управлением доступом с учетом конфиденциальности (Privacy Aware Role Based Access Control).
Комментариев нет:
Отправить комментарий