Ролевое управление доступом доклад

Обновлено: 25.06.2024

С традиционной точки зрения средства управления доступом позволяют специфицировать и контролировать действия, которые субъекты (пользователи и процессы) могут выполнять над объектами (информацией и другими компьютерными ресурсами). В данном разделе речь идет о логическом управлении доступом, которое, в отличие от физического, реализуется программными средствами. Логическое управление доступом – это основной механизм многопользовательских систем, призванный обеспечить конфиденциальность и целостность объектов и, до некоторой степени, их доступность (путем запрещения обслуживания неавторизованных пользователей).

Рассмотрим формальную постановку задачи в традиционной трактовке. Имеется совокупность субъектов и набор объектов. Задача логического управления доступом состоит в том, чтобы для каждой пары "субъект-объект" определить множество допустимых операций (зависящее, быть может, от некоторых дополнительных условий) и контролировать выполнение установленного порядка.

Отношение "субъекты-объекты" можно представить в виде матрицы доступа, в строках которой перечислены субъекты, в столбцах – объекты, а в клетках, расположенных на пересечении строк и столбцов, записаны дополнительные условия (например, время и место действия) и разрешенные виды доступа. Фрагмент матрицы может выглядеть, например, так:

"o" – обозначает разрешение на передачу прав доступа другим пользователям,

"a" – добавление информации

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

Для систем управления реляционными базами данных объект – это база данных, таблица, представление, хранимая процедура. К таблицам применимы операции поиска, добавления, модификации и удаления данных, у других объектов иные виды доступа.

Разнообразие объектов и применимых к ним операций приводит к принципиальной децентрализации логического управления доступом. Каждый сервис должен сам решать, позволить ли конкретному субъекту ту или иную операцию. Теоретически это согласуется с современным объектно-ориентированным подходом, на практике же приводит к значительным трудностям. Главная проблема в том, что ко многим объектам можно получить доступ с помощью разных сервисов (возможно, при этом придется преодолеть некоторые технические трудности). Так, до реляционных таблиц можно добраться не только средствами СУБД, но и путем непосредственного чтения файлов или дисковых разделов, поддерживаемых операционной системой (разобравшись предварительно в структуре хранения объектов базы данных). В результате при задании матрицы доступа нужно принимать во внимание не только принцип распределения привилегий для каждого сервиса, но и существующие связи между сервисами (приходится заботиться о согласованности разных частей матрицы). Аналогичная трудность возникает при экспорте/импорте данных, когда информация о правах доступа, как правило, теряется (поскольку на новом сервисе она не имеет смысла). Следовательно, обмен данными между различными сервисами представляет особую опасность с точки зрения управления доступом, а при проектировании и реализации разнородной конфигурации необходимо позаботиться о согласованном распределении прав доступа субъектов к объектам и о минимизации числа способов экспорта/импорта данных.

При принятии решения о предоставлении доступа обычно анализируется следующая информация:

идентификатор субъекта (идентификатор пользователя, сетевой адрес компьютера и т.п.). Подобные идентификаторы являются основой произвольного (или дискреционного) управления доступом ;
атрибуты субъекта ( метка безопасности , группа пользователя и т.п.). Метки безопасности – основа принудительного (мандатного) управления доступом.

Матрицу доступа, ввиду ее разреженности (большинство клеток – пустые), неразумно хранить в виде двухмерного массива. Обычно ее хранят по столбцам, то есть для каждого объекта поддерживается список "допущенных" субъектов вместе с их правами. Элементами списков могут быть имена групп и шаблоны субъектов, что служит большим подспорьем администратору. Некоторые проблемы возникают только при удалении субъекта, когда приходится удалять его имя из всех списков доступа; впрочем, эта операция производится не часто.

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

Подавляющее большинство операционных систем и систем управления базами данных реализуют именно произвольное управление доступом . Основное достоинство произвольного управления – гибкость. Вообще говоря, для каждой пары "субъект-объект" можно независимо задавать права доступа (особенно легко это делать, если используются списки управления доступом ). К сожалению, у "произвольного" подхода есть ряд недостатков. Рассредоточенность управления доступом ведет к тому, что доверенными должны быть многие пользователи, а не только системные операторы или администраторы. Из-за рассеянности или некомпетентности сотрудника, владеющего секретной информацией, эту информацию могут узнать и все остальные пользователи. Следовательно, произвольность управления должна быть дополнена жестким контролем за реализацией избранной политики безопасности.

Второй недостаток, который представляется основным, состоит в том, что права доступа существуют отдельно от данных. Ничто не мешает пользователю, имеющему доступ к секретной информации, записать ее в доступный всем файл или заменить полезную утилиту ее "троянским" аналогом. Подобная "разделенность" прав и данных существенно осложняет проведение несколькими системами согласованной политики безопасности и, главное, делает практически невозможным эффективный контроль согласованности.

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

Удобной надстройкой над средствами логического управления доступом является ограничивающий интерфейс, когда пользователя лишают самой возможности попытаться совершить несанкционированные действия, включив в число видимых ему объектов только те, к которым он имеет доступ. Подобный подход обычно реализуют в рамках системы меню (пользователю показывают лишь допустимые варианты выбора) или посредством ограничивающих оболочек, таких как restricted shell в ОС Unix.

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

Ролевое управление доступом

При большом количестве пользователей традиционные подсистемы управления доступом становятся крайне сложными для администрирования. Число связей в них пропорционально произведению количества пользователей на количество объектов. Необходимы решения в объектно-ориентированном стиле, способные эту сложность понизить.

Таким решением является ролевое управление доступом (РУД). Суть его в том, что между пользователями и их привилегиями появляются промежуточные сущности – роли. Для каждого пользователя одновременно могут быть активными несколько ролей, каждая из которых дает ему определенные права (см. рис. 10.2).

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

Ролевой доступ развивается более 10 лет (сама идея ролей, разумеется, значительно старше) как на уровне операционных систем, так и в рамках СУБД и других информационных сервисов . В частности, существуют реализации ролевого доступа для Web-серверов.

Ролевое управление доступом оперирует следующими основными понятиями:

пользователь (человек, интеллектуальный автономный агент и т.п.);
сеанс работы пользователя ;
роль (обычно определяется в соответствии с организационной структурой);
объект (сущность, доступ к которой разграничивается; например, файл ОС или таблица СУБД);
операция (зависит от объекта; для файлов ОС – чтение, запись, выполнение и т.п.; для таблиц СУБД – вставка, удаление и т.п., для прикладных объектов операции могут быть более сложными);
право доступа (разрешение выполнять определенные операции над определенными объектами).

Ролям приписываются пользователи и права доступа ; можно считать, что они (роли) именуют отношения "многие ко многим" между пользователями и правами. Роли могут быть приписаны многим пользователям; один пользователь может быть приписан нескольким ролям. Во время сеанса работы пользователя активизируется подмножество ролей, которым он приписан, в результате чего он становится обладателем объединения прав, приписанных активным ролям. Одновременно пользователь может открыть несколько сеансов.

Между ролями может быть определено отношение частичного порядка , называемое наследованием. Если роль r2 является наследницей r1, то все права r1 приписываются r2, а все пользователи r2 приписываются r1. Очевидно, что наследование ролей соответствует наследованию классов в объектно-ориентированном программировании, только правам доступа соответствуют методы классов, а пользователям – объекты (экземпляры) классов.

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

Можно представить себе формирование иерархии ролей, начиная с минимума прав (и максимума пользователей), приписываемых роли "сотрудник", с постепенным уточнением состава пользователей и добавлением прав (роли "системный администратор", "бухгалтер" и т.п.), вплоть до роли "руководитель" (что, впрочем, не значит, что руководителю предоставляются неограниченные права; как и другим ролям, в соответствии с принципом минимизации привилегий, этой роли целесообразно разрешить только то, что необходимо для выполнения служебных обязанностей). Фрагмент подобной иерархии ролей показан на рис. 10.3.

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

Статическое разделение обязанностей налагает ограничения на приписывание пользователей ролям. В простейшем случае членство в некоторой роли запрещает приписывание пользователя определенному множеству других ролей. В общем случае данное ограничение задается как пара "множество ролей – число" (где множество состоит, по крайней мере, из двух ролей, а число должно быть больше 1), так что никакой пользователь не может быть приписан указанному (или большему) числу ролей из заданного множества. Например, может существовать пять бухгалтерских ролей, но политика безопасности допускает членство не более чем в двух таких ролях (здесь число=3).

При наличии наследования ролей ограничение приобретает несколько более сложный вид, но суть остается простой: при проверке членства в ролях нужно учитывать приписывание пользователей ролям-наследницам.

Динамическое разделение обязанностей отличается от статического только тем, что рассматриваются роли, одновременно активные (быть может, в разных сеансах) для данного пользователя (а не те, которым пользователь статически приписан). Например, один пользователь может играть роль и кассира, и контролера, но не одновременно; чтобы стать контролером, он должен сначала закрыть кассу. Тем самым реализуется так называемое временное ограничение доверия, являющееся аспектом минимизации привилегий .

Рассматриваемый проект стандарта содержит спецификации трех категорий функций , необходимых для администрирования РУД:

Административные функции (создание и сопровождение ролей и других атрибутов ролевого доступа): создать/удалить роль/пользователя, приписать пользователя/право роли или ликвидировать существующую ассоциацию, создать/удалить отношение наследования между существующими ролями, создать новую роль и сделать ее наследницей/предшественницей существующей роли, создать/удалить ограничения для статического/динамического разделения обязанностей .
Вспомогательные функции (обслуживание сеансов работы пользователей): открыть сеанс работы пользователя с активацией подразумеваемого набора ролей; активировать новую роль, деактивировать роль; проверить правомерность доступа.
Информационные функции (получение сведений о текущей конфигурации с учетом отношения наследования). Здесь проводится разделение на обязательные и необязательные функции. К числу первых принадлежат получение списка пользователей, приписанных роли, и списка ролей, которым приписан пользователь.

Все остальные функции отнесены к разряду необязательных. Это получение информации о правах, приписанных роли, о правах заданного пользователя (которыми он обладает как член множества ролей), об активных в данный момент сеанса ролях и правах, об операциях, которые роль/пользователь правомочны совершить над заданным объектом, о статическом/динамическом разделении обязанностей.

Можно надеяться, что предлагаемый стандарт поможет сформировать единую терминологию и, что более важно, позволит оценивать РУД-продукты с единых позиций, по единой шкале.

Управление доступом на основе ролей

Ключевой особенностью ролевой модели является то, что весь доступ к информационным системам и ресурсам предоставляется только через роли. Роль – это набор прав доступа. Пользователи получают доступ только через присвоенные им роли.

Идея предоставления доступа на основе ролей возникла из необходимости группировки наборов прав в какие-то отдельные сущности, которые четко давали бы понять, какой доступ есть у пользователя, с которыми было бы удобнее и понятнее работать в случае изменений как положения пользователя в организации, так и набора прав доступа пользователя. Исторически сложилось, что наборы прав стали привязывать к должностям сотрудников, по сути – к функциональным ролям. Отсюда появилось понятие роли. Первые приложения, реализующие ролевое управление доступом пользователей, начали появляться еще в 1970х годах. В то время это были достаточно простые системы и приложения. Не было единой модели, описывающей как именно доступ предоставляется пользователю на основе его роли в организации. Системы разрабатывались различными организациями без согласованных определений и стандартов.

Универсальную модель ролевого управления доступом впервые предложили Дэвид Феррайоло и Ричард Кун из Национального Института Стандартов и Технологий США (NIST) в 1992 году. Документ давал определения основным понятиям, их отношениям и зависимостям, и представлял ролевое управление доступом (RBAC – Role Based Access Control) как альтернативу мандатному управлению (MAC – Mandatory Access Control) и избирательному управлению (DAC – Discretionary Access Control) доступом. Об этих и других моделях можно прочитать здесь. Сегодня этот документ вырос в полноценный международный стандарт INCITS 359-2012, о нём, я думаю, мы ещё расскажем подробнее.

Преимущества ролевого управления доступом

По сравнению с указанными выше моделями, ролевое управление доступом обладает рядом важных положительных свойств. Например:

Возможность построения иерархии ролей с наследованием набора прав. Это позволяет упростить ролевую модель, особенно в организациях с разнородной инфраструктурой, где используется много информационных систем. С использованием иерархии нет необходимости повторно указывать права в нескольких подобных ролях, достаточно поместить их в одну большую роль, как дочерние, указав лишь уникальные права для каждой роли.
Просто и эффективно осуществляется предоставление одинаковых прав большому количеству пользователей – достаточно назначить пользователям одну роль.
При необходимости изменения набора прав большому количеству пользователей достаточно изменить набор прав в роли.
Возможность реализации принципа разделения полномочий (SoD – Segregation of Duties). Это значительно снижает риск предоставления пользователям избыточных полномочий, например, когда две роли не могут быть в один момент времени назначены одному пользователю.

Особенности

При проектировании, внедрении и использовании ролевой модели управления доступом нужно принимать в расчёт факторы, которые могут привести к серьезным потерям времени и средств.

В таком случае трудно определить "разумно малый" набор ролей, которые отвечают за права доступа основной массы пользователей.
Непрактично создавать столько же ролей сколько пользователей – это равносильно ручному управлению доступом.

Практика применения

Ранее мы увидели, почему управление правами пользователей на основе ролевой модели может быть сложным и дорогим, и даже после успешного внедрения доставить много проблем как ИТ, так и бизнесу.

В каких же случаях, несмотря на перечисленные особенности, организация доступа на основании ролей оправдывает себя? Во-первых, в рамках одной системы, где возможное количество комбинации прав довольно невелико, и как следствие, несложно управлять малым количеством ролей. На самом деле, использование RBAC уже давно считается лучшей практикой при разработке приложений, серверов баз данных и операционных систем. Во-вторых, в организациях, где достаточно большое количество пользователей имеет одинаковые права. Например, кассиры в банках, продавцы в розничной торговле и сетях быстрого питания, бухгалтерия и т.д. В каждом из этих примеров нескольких ролей достаточно для предоставления доступа тысячам пользователей.

Следует отметить также, что неизбежны ситуации, когда мы можем смоделировать роли для достаточно большого числа пользователей, при этом в той же организации останутся пользователи, чьи права определить в рамках ролевой модели затруднительно, либо вообще невозможно. Нужно понимать, что одно лишь использование RBAC – не панацея, необходимо параллельно продумывать и другие способы предоставления доступа – это динамические правила, запросы прав доступа, анализ атрибутов пользователей. Подробнее об этом я могу рассказать в следующих заметках.

Резюмируя, можно сказать следующее — RBAC является полезным решением для некоторых конкретных проблем: управление пользователями в одном каталоге или управление большими группами пользователей с одинаковыми правами. Но RBAC, как единственная модель предоставления доступа, не подходит для более общей проблемы управления правами большого количества разнообразных пользователей и динамического доступа пользователей во многих системах.

Введение

Рост компании = ужесточение контроля

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

Любые избыточные права доступа сотрудников ведут к увеличению риска утечки информации. Наверняка, каждый из вас сталкивался со следующей ситуацией: сотрудник решает уволиться и перед уходом копирует на флэшку всю ту информацию, к которой имеет доступ (авось, пригодится!). Если сотрудник в организации достаточно давно, то за время работы, скорее всего, у него накопилось огромное количество привилегий доступа к различным информационным ресурсам компании, которые он получал, участвуя в проектах, выполняя поручения руководства и свои ежедневные обязанности. Риск потери конфиденциальной информации очень велик и последствия могут быть различными - начиная от потери репутации компании и заканчивая уголовным преследованием. Поэтому большинство компаний с ростом численности сотрудников усиливают меры по контролю за правами их доступа. Происходит ужесточение политики ИБ, так как увеличиваются риски утечки информации.

Одним из первых этапов по упорядочиванию процесса выдачи прав к информационным системам – ввод системы согласования заявок.

Рисунок 1. Ввод системы согласования заявок

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

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

Инвентаризация прав доступа

Давайте остановимся подробнее на последних операциях.

Представьте, что нужно узнать, к каким ресурсам имеет доступ сотрудник, работающий в организации пять лет. Сколько это займет времени? 15-20 минут? А если необходимо провести проверку 50 сотрудников?

Информационные системы:

Active Directory
Файловые ресурсы
ERP-системы (1С, SAP, IBM, Microsoft)
CRM (Microsoft, IBM, amoCRM, SugarCRM)
СЭД (БОСС-референт, IBM lotus, Directum)

Рисунок 2. Типовой доступ сотрудника к информационным системам предприятия

Для чего же необходимо производить инвентаризацию доступа? Основная задача – обеспечение сотрудникам необходимых и достаточных прав доступа для работы. Это права доступа строго необходимые для выполнения должностных обязанностей на текущий момент. Инвентаризация позволяет выявить привилегии, которые на данный момент исполнения обязанностей сотрудника не являются необходимыми.

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

Чаще всего запрос и согласование доступа осуществляется в системе электронного документооборота, с помощью корпоративной почты или веб-портала, либо просто по телефону. После того, как запрос согласован, доступ выдан, заявка отправляется в архив, если таковой существует. При этом механизме оперативного отслеживания существующих полномочий сотрудника чаще всего нет. В таких ситуациях единственная возможность выявить текущие права доступа сотрудников – проведение оперативной или плановой инвентаризации.

Наиболее оптимальным решением проблемы инвентаризации существующих прав доступа – использование ролевой модели и типового доступа. Давайте рассмотрим подробнее эти понятия.

Типовой доступ

Рисунок 4. Использование шаблонных групп, ролей и профилей

Ролевая модель

Ролевая модель (RBAC) – использование формализованных шаблонов на предприятии, которые содержат необходимые полномочия для осуществления определенной деятельности. Для решения большинства задач организации существуют ролевые полномочия, присваиваемые сотрудникам. Например:

В рамках ролевой модели доступа на основе матрицы доступа в разрезе подразделений и должностей используется такие сущности, как: бизнес-роли, должностной доступ и, в исключительных случаях, индивидуальный доступ

Должностной доступ представляет собой набор базовых прав, которые имеют сотрудники одного отдела на одной должности. Зачастую, это минимально необходимые привилегии для выполнения рабочих обязанностей.

Рисунок 5. Использование шаблонов должностного доступа

Например: создание учетной записи в AD для входа в домен, создание корпоративного почтового ящика, выделения доступа к корпоративной папке отдела на файлообменнике и регистрация в профильной информационной системе с базовыми правами (ERP, CRM, СЭД).

Бизнес-роль

Бизнес-роли включают в себя типовой доступ, который сотрудник запрашивает (либо ему выдается) для выполнения определенных функций – участия в проекте, выполнения поручений руководства, командировка.

Рисунок 6. Использование шаблонов бизнес-ролей

Индивидуальный доступ

Индивидуальный доступ необходим для решения конкретных задач, поставленных руководителем, это дополнительные права, которые сотрудник запрашивает с помощью интерфейса самообслуживания: веб-портала, ITSM-системы и пр.

При применении ролевой модели доступа, количество индивидуальных прав обычно составляет 5-10% от общего количества привилегий.

Данная схема позволяет значительно снизить объем производимой инвентаризации, так как есть права, характерные для должностей, которые априори присутствуют у сотрудника и в большинстве случаев достаточны для работы. Так же есть типовые права, если сотрудник участвует в проекте на определенной роли.

Рисунок 7. Процесс предоставления индивидуальных прав доступа

Сертификация доступа

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

Есть другой вид переаттестации, когда доступ подтверждается не руководителем, а согласующими лицами, которые утверждали первоначальный доступ.

Рисунок 8. Утверждение индивидуальных прав доступа

Работа с несоответствиями

Как правило, в IDM-решении присутствуют механизмы отслеживания, так называемых, несоответствий. Несоответствие – это изменение прав доступа сотрудников, изменение атрибутов ресурсов и информационных систем в обход процедуры согласования и без уведомления сотрудников службы ИБ.

Рисунок 9. Отслеживание несоответствий в правах доступа

IDM-решения производят мониторинг информационных систем на предмет изменения состояний, после чего соотносят эти изменения с заявками, созданными в IDM.

Рисунок 10. Мониторинг изменений доступа в информационных системах

Рисунок 11. Несоответствие прав доступа фиксируются системой

Заключение

По статистике около 70% утечек конфиденциальной информации происходит по вине сотрудников организации. Любые меры по противодействию утечкам информации делятся на два типа: превентивные меры и защитные.

Защитные меры – использование:

Превентивные меры – инвентаризация, ресертификация и мониторинг прав доступа сотрудника. Основная задача - обеспечение сотрудникам необходимых и достаточных прав доступа для работы. Это позволяет минимизировать риски по утечке информации.

Контроль существующих прав доступа
Построение матрицы доступа
Мониторинг изменений ИС

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

Подписывайтесь на канал "Anti-Malware" в Telegram, чтобы первыми узнавать о новостях и наших эксклюзивных материалах по информационной безопасности.

управление доступом субъектов к объектам на основе списков управления доступом или матрицы доступа. Субъект с определенным правом доступа может передать это право любому другому субъекту.

На курсе "Операционные системы" вы работали с этой моделью доступа.

Пример: когда вы расписываете доступ к файлу, вы указываете

имя владельца файла (субъект)
права на чтение
права на запись
права на запуск на выполнение

пользователь
программа выполняющаяся под именем пользователя

файлы
каталоги
внешние накопители (CD,DVD,USB и т.д.)
принтер
сетевой адаптер

Рис. Дискреционное управление доступом

простата реализации
гибкость (пользователь может описать доступ к своим ресурсам)

излишняя детализированность (приводит к запутанности)
сложность администрирования
пользователь может допустить ошибку при назначении прав

Пример дискреционного управления доступом к файлам в LINUX.

Мандатное управление доступом ( Mandatory access control, MAC )

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

Рис. Мандатное управление доступом

простата построения общей схемы доступа
простата администрирования

проблема разграничения пользователей одного уровня
пользователь не может назначать доступ к объекту

Мандатная модель не реализована в Windows, но можно поставить дополнительные средства защиты (например: Secret Net, Аккорд и т.д.).

Ролевое управление доступом (Role Based Access Control, RBAC)

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

Читайте также: