Какие методы управления доступом вам известны чем они отличаются

1 Введение

1.1 Цели и область применения

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

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

1.2 Используемые термины

Доступ субъекта к объекту для определенных операций.

Контейнер информации в системе

Сущность определяющая пользователя при работе в системе

Человек выполняющий действия в системе или приложение выступающее от его имени.

2 Методы управления доступом

2.1 Общее описание

Управление доступом это определение возможности субъекта оперировать над объектом. В общем виде описывается следующей диаграммой:

На данный момент существует три различных метода для управления доступом к объектам в системе:

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

Диаграмма 1: Системы контроля доступа

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

2.2 Модель дискреционного контроля за доступом

2.2.1 Общее описание

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

Гибкость DAC позволяет использовать его в большом количестве систем и приложений. Благодаря этому этот метод очень распространен, особенно в коммерческих приложениях. Очевидным примером использования DAC является система Windows NT/2k/XP (см. Диаграмму 2).

Диаграмма 2: Дискреционная модель контроля доступа Windows XP.

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

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

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

2.2.2 Формальное определение

2.3 Модель обязательного контроля за доступом

2.3.1 Общее описание

Обязательный контроль доступа управляет доступом на основе классификации объектов и субъектов системы. Каждому субъекту и объекту системы назначается некоторый уровень безопасности (УБ). Уровень безопасности объекта, как правило, описывает важность этого объекта и возможный ущерб, который может быть причинен при разглашении информации содержащейся в объекте. Уровень безопасности субъекта является уровнем доверия к нему. В простейшем случае все уровни безопасности являются членами некоторой иерархии. Например: Совершенно Секретно (СС), Секретно (С), Конфиденциально (К) и Рассекречено (Р), при этом верно следующее: СС > C > K > P, т.е. каждый уровень включает сам себя и все уровни находящиеся ниже в иерархии.

2.3.1.1 Обеспечение безопасности информации

Доступ субъекта к объекту предоставляется если выполнено некоторое условие отношения (которое зависит от типа доступа) между уровнями безопасности объекта и субъекта. В частности, должны выполняться следующие условия:

Выполнение этих условий, гарантирует, что данные высокоуровневых объектов (например Совершенно Секретно) не попадут в низкоуровневые объекта (например Рассекреченный) см. Диаграмму 3.

Диаграмма 3: Управление потоками информации для обеспечения безопасности данных

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

В описанной выше модели существует два неочевидных момента, которые ставят под вопрос непротиворечивость модели.

1. Пользователь нижнего уровня имеет право записывать в объекты всех верхних уровней. Таким образом он может переписать существующий объект своим собственным, что равносильно удалению. Этот недостаток может быть устранен путем запрета записи на более верхние уровни. При такой схеме правила будут выглядеть так:

2. Из диаграммы видно, что пользователи с более высоки уровнем доверия не могут изменять объекты с более низким уровнем безопасности. Эта проблема разрешается тем, что пользователь при доступе к различным документам может выступать от имени субъектов с различными уровнями доверия. Т.е. пользователь с уровнем доверия «С» может выступать от имени субъектов с уровнем доверия «С», «К» и «Р».

2.3.1.2 Обеспечение достоверности информации

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

Видно что критерии правил просто поменялись местами.

Диаграмма 4: Управление потоками информации для обеспечения надежности данных.

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

2.3.2 Формальное определение

Определение 1 (Сетка уровней безопасности)

Существует конечная сетка уровней доступа с заданным на ней отношением частичного порядка .

Определение 2 (Уровень безопасности)

Существуют наборы объектов и субъектов системы:

Для каждого объекта и субъекта системы существует один и только один уровень безопасности из сетки уровней безопасности определяемый функцией: ,

Определение 3 (право на чтение)

Субъект имеет право на чтение объекта если

Определение 4 (нестрогое право на запись)

Субъект имеет право на запись объекта если

Определение 5 (строгое право на запись)

Субъект имеет право на запись объекта если

2.4 Ролевая модель контроля за доступом

2.4.1 Общее описание

Ролевой метод управления доступом контролирует доступ пользователей к информации на основе типов их активностей в системе. Применение данного метода подразумевает определение ролей в системе. Понятие роль можно определить как совокупность действий и обязанностей, связанных с определенным видом деятельности. Таким образом, вместо того, чтобы указывать все типы доступа для каждого пользователя к каждому объекту, достаточно указать тип доступа к объектам для роли. А пользователям, в свою очередь, указать их роли. Пользователь, «выполняющий» роль, имеет доступ определенный для роли.

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

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

2.4.1.1 Простота администрирования

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

2.4.1.2 Иерархия ролей

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

2.4.1.3 Принцип наименьшей привилегии

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

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

2.4.1.4 Разделение обязанностей

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

Формально ролевую модель управления доступом можно изобразить следующим образом:

Диаграмма 5: Ролевая модель управления доступом.

Модель состоит из следующих сущностей: пользователи, роли и привилегии. Интуитивно понятно, что пользователь это либо человек, либо программа работающая от имени пользователя. Роль это вид деятельности пользователя в организации, а привилегия это разрешение на определенный доступ к одному или нескольким объектам системы.

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

2.4.2 Формальное определение

Сессия имеет следующие привилегии:

3 Анализ существующих моделей

3.1 Области применения

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

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

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

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

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

3.2 Фундаментальное различие

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

1. Настройка политики безопасности системы.

2. Определение прав доступа для субъектов и объектов в системе.

В то время как для первых двух моделей политика безопасности системы уже предопределена.

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

4 Заключение

В этой статье мы рассмотрели различные методы управления доступом:

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

5 Список литературы

[1]. Ravi S. Sandhu, Pierangela Samarati: Access Control: Principles and Practice. IEEE Comunication Magazine 1994

[2]. Osborn, S., Sandhu, R., and Nunawer, Q. Configuring Role-Based Access Control To Enforce Mandatory And Discretionary Access Control Policies. ACM Trans. Info. Syst. Security, 3, 2, 2000.

[3]. Steve Demurjian: Implementation of Mandatory Access Control in Role-based Security System. 2001

Источник

Семинар №2

Доклад 1. Формы представления ограничений доступа

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

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

Процедура приведения авторизации в действие называется управлением доступом (access control).

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

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

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

Ограничение доступа может задаваться в форме правил. На основании правила система управления доступом в любой момент времени динамически решает вопрос о предоставлении или непредоставлении доступа. Правило может строиться с учетом различных факторов, в том числе длительности сеанса связи (ограничение доступа по времени использования ресурса), возраста человека (ограничение для детей на доступ к некоторым сайтам), времени суток (разрешение на использование ресурсов и сервисов Интернета только в рабочие часы). Популярной мерой ограничения доступа в Интернет является капча (capcher), в этом случае субъекту, обратившемуся с запросом к ресурсу, предлагается ввести символы, выведенные на экран в таком искаженном виде, в котором их сможет распознать только человек — таким образом исключается доступ к ресурсам искусственных субъектов (программных систем). Другим распространенным правилом является правило, которое носит специальное название — необходимо знать (need-to-know). В соответствии с этим правилом каждый сотрудник имеет право доступа только к тем информационным ресурсам, которые ему необходимы для выполнения его служебных обязанностей.

Для ограничения доступа используются также контентно- и контекстно-зависимые правила. Например, в компании может быть принято правило, что некоторым категориям пользователей запрещается доступ к документам, содержащим те или иные ключевые слова или фразы, такие как «для ограниченного использования», «секретно» или кодовое название проекта. Ограничения могут быть наложены на доступ к ресурсам, содержащим текст на иностранном языке. Это были примеры контентно-зависимых правил. В контекстно-зависимых правилах принимаются во внимание некоторые факторы, характеризующие текущее состояние среды и/или предысторию (контекст) запроса. Простейшим правилом такого рода является отказ в доступе пользователю, который сделал подряд три безуспешных попытки аутентификации. Или доступ к некоторому сетевому ресурсу предприятия может быть запрещен, если к моменту текущего обращения пользователь выполнил несколько обращений к внешнему сайту, содержимое которого не связано напрямую с его профессиональными интересами.

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

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

ОбъектыUser 1User 2User 3File 1Читать и записыватьЧитать и записыватьЧитатьFile 2Читать и записыватьНет доступаЧитатьFile 3ЗаписыватьНет доступаЧитать

Рис. 1. Матрица прав доступа.

Матричный способ описания прав доступа теоретически дает возможность отразить все многообразие отношений субъектов и объектов системы для всех возможных сочетаний <субъект, объект, назначенные права>. Однако этот универсальный способ представления, как правило, очень сложно реализовать на практике из-за громоздкости матрицы, учитывая огромное число элементов — как субъектов, так и объектов — в вычислительной системе.

Особенностью матрицы прав доступа является не только ее большая размерность, но и наличие большого числа нулевых элементов. Такой вид матриц в математике называют разряженными. Нулевое значение здесь говорит о том, что для данного сочетания <субъект, объект>права доступа не определены, а именно такие сочетания составляют большинство в реальных системах. Свойство разреженности матрицы может быть использовано для более компактного представления правил доступа.

С каждым объектом можно связать список управления доступом (Access Control List, ACL), в котором указаны только те субъекты (пользователи), которые имеют разрешение на доступ к данному объекту (ресурсу). Ясно, что количество субъектов в данном списке будет значительно меньше общего числа субъектов системы. Такие списки должны быть созданы для всех ресурсов. Способ описания прав доступа набором списков столь же универсальный и гибкий, как матрица, но вместе с тем имеет более компактный вид, так как он не включает пустые элементы матрицы. Список ACL состоит из элементов управления доступом (Access Control Element, АСЕ), каждый из которых описывает права доступа определенного пользователя к данному ресурсу. На рис. 2 список ACL состоит из трех элементов АСЕ.

Рис. 2. Список управления доступом к объекту

Права доступа могут быть определены как по отношению к ресурсам, так и по отношению к пользователям. В последнем случае его называют списком разрешений (capability). На рис. 3 показан список разрешений, которые имеет пользователь User 2 по отношению к ресурсам File 1, File 2 и File 3.

Рис. 3. Список разрешений пользователя User 2

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

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

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

Ранее мы рассматривали различные подходы к хранению и представлению информации о правах доступа, не придавая значения тому, каким образом они были назначены. Однако способ назначения прав — авторизация — существенно влияет на способ управления доступом.

Существует два основных подхода к авторизации:

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

Помимо этих методов, взятых «в чистом виде», система управления доступом может базироваться на их комбинации.

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

Одно из первых систематических изложений принципов Discretionary Access Control, DAC было предпринято в 1987 году в документе NCSC-TG-003-87, «Руководство по дискретному управлению доступом». В то время модель DAC была самой распространенной схемой управления доступом, таковой она остается и по сегодняшний день — большинство универсальных ОС реализуют дискреционную модель. В документе NCSC дается следующее определение метода DAC:

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

Отсюда следуют две главные особенности дискреционного метода:

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

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

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

Рис. 1. Просмотр и назначение дискреционных атрибутов для файла с помощью графической утилиты «Менеджер файлов» в ОССН Astra Linux SE.

Доклад 3. Мандатный метод управления доступом

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

К основным чертам мандатного метода управления доступом можно отнести следующие:

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

объектов
(файлов, каталогов)Уровень от совершенно секретно и нижеУровень от секретно и нижеУровень данных для служебного пользованияСовершенно секретноДоступ разрешен00СекретноДоступ разрешенДоступ разрешен0Данные для служебного пользованияДоступ разрешенДоступ разрешенДоступ разрешен

Рис. 1. Правило мандатного доступа, представленное в виде матрицы

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

Элементы, описывающие уровни секретности объектов или уровни допуска субъектов, называют метками безопасности (security labels). Мандатный метод управления доступом предусматривает назначение меток безопасности всем без исключения субъектам и объектам системы, чтобы в дальнейшем они использовались системой для принятия решения о допуске.

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

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

Таким образом, каждая метка безопасности состоит из двух частей (рис. 2):

Рис. 2. Структура метки безопасности объекта/субъекта

Категория относит данные к определенному виду информации. Например, разные категории могут быть присвоены материалам, относящимся к разным проектам, разным административным подразделениям, разным профессиональным группам. Одному и тому же объекту/субъекту может быть присвоено несколько категорий. Так, отчет о завершении этапа некоторой антитеррористической операции может быть отнесен не только к категории материалов, касающихся данной операции, но и дополнительно к категории материалов подразделения, занимающегося этой работой. Объекты одной категории могут быть классифицированы по-разному: например, одна часть отнесена к более высокому уровню секретности, а другая часть — к более низкому.

Уровни секретности/допуска, которых обычно не много, образуют иерархию от наивысшего до самого низкого уровня. Субъект, имеющий допуск к некоторому уровню, получает его и по отношению ко всем нижележащим уровням.

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

Рисунок 3 иллюстрирует соотношение между классификацией и категорией. Здесь разная закраска кружков служит для обозначения разных категорий объектов.

Рис. 3. Правило мандатного доступа

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

В Astra Linux Special Edition термину «классификация» соответствует «уровень». Уровни и категории в Astra Linux Special Edition можно настроить с помощью графической утилиты «Управление политикой безопасности».

Рис. 4. Категории и Уровни в окне графической утилиты «Управление политикой безопасности».

Рис. 5. Отображение и установка допустимых мандатные уровней и категорий для пользователя test100.

Надпись на вкладке МРД расшифровывается как мандатное разграничения доступа.

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

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

Метод управления доступом RBAC (Role-based Access Control), основанный на ролях, по сравнению с методами DAC и MAC более приближен к реальной жизни. Как видно из названия, основным его свойством является использование «ролей». Понятие «роль» в данном контексте ближе всего к понятию «должность» или «круг должностных обязанностей». Поскольку одну и ту же должность могут занимать несколько людей, то и одна и та же роль может быть приписана разным пользователям.

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

Разрешения приписываются ролям, а не отдельным пользователям или группам пользователей (рис. 1). А уже затем те или иные роли приписываются пользователю. Например, в системе управления доступом, развернутой в банке, всем юристам приписана роль «юрист», трейдерам — роль «трейдер», менеджерам — роль «менеджер» и т. д. Процесс определения ролей должен включать тщательный анализ того, как функционирует организация, какой набор функций должен выполнять работник, имеющий ту или иную должность. Каждой из ролей назначаются права доступа, необходимые и достаточные пользователям для выполнения служебных обязанностей, обусловленных приписыванием к данной роли.

Рис. 1. Схема авторизации в системах управления доступом на основе ролей

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

Все пользователи, играющие одну и ту же роль, имеют идентичные права. Изменение производственной ситуации — расширение бизнеса, внедрение новых технологий, продвижение сотрудника по служебной лестнице или перевод в другое подразделение и др. — все это может вызвать аннулирование одной роли пользователя и приписывание ему другой роли. Такой подход упрощает администрирование прав доступа: вместо необходимого в методах DAC и MAC отслеживания и обновления прав каждого отдельного пользователя в методе RBAC достаточно изменить роль или заменить одну роль другой.

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

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

Иерархия ролей создается определением для них отношений, называемых наследованием: в соответствии с этим определением если роль R2 является наследницей R1, то все права роли R1 приписываются к правам роли R2, а все пользователи роли R2 приписываются к пользователям роли R1 (рис. 2). Таким образом, установление отношений наследования является еще одним способом наделения пользователя правами наряду с явным назначением пользователю некоторой роли.

Рис. 2. Отношение наследования ролей: а — независимые роли; б — роль R2 является наследницей роли R1

Отношения наследования относятся к типу «многие ко многим», то есть у одной роли может быть несколько наследниц и одна роль может быть наследницей нескольких ролей.

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

Рис. 3. Фрагмент организационной структуры предприятия

Такой организационной структуре может быть поставлена в соответствие ролевая структура, полученная в результате установления между ролями отношений наследования (рис. 4). Роль «сотрудник» представляет собой общие, наличествующие у всех сотрудников организации права. Должность менеджера по работе с клиентами добавляет к должностным обязанностям рядового сотрудника отдела ОРК еще ряд функций. Например, менеджер обязан разрабатывать план увеличения клиентской базы, что требует доступа к некоторым финансовым документам. Находящийся с ним на одном уровне менеджер отдела развития (ОР) также нуждается в расширении прав доступа к информационным ресурсам по отношению к рядовым сотрудникам отдела О Р. После установления отношений наследования с ролями «сотрудник ОРК», «сотрудник ОТР», «сотрудник ФО» и «директор» все общие права сотрудников оказались неявным образом добавлены к этим ролям-наследницам, а их пользователи соответственно переместились наверх. Наследники следующей ступени — роли «менеджер ОРК» и «менеджер ОТР» — сами являются предшественниками для роли «директор по развитию», которая, таким образом, аккумулировала права этих двух ролей.

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

Рис. 4. Структура ролей, образованная отношениями наследования

Чтобы избежать подобных ситуаций, в методе RBAC предусмотрен специальный механизм, накладывающий ограничения на приписывание ролей пользователям. Этот механизм действует следующим образом. Совокупность ролей, относительно совмещения которых нужно устанавливать ограничения, объединяется в устойчивую группу, и к ней приписывается число-ограничитель. В нашем случае это группа ролей <«инженер», «сотрудник финансового отдела»>, которой должен быть приписан ограничитель 1. Если теперь администратором будет сделана попытка приписать пользователю обе эти роли, то система заблокирует его действия.

Итак, к характерным особенностям ролевого управления доступом можно отнести следующее:

Метод RBAC нельзя отнести к хорошо масштабируемым. Он эффективно работает в пределах единой системы или приложения, таких, например, как FreeBSD, Solaris, СУБД Oracle, MS Active Directory, но на больших предприятиях, имеющих тысячи сотрудников, поддержание множества ролей с их отношениями наследования становится сложной и запутанной задачей. Занимая промежуточное положение между мандатным и дискреционным методами, ролевое управление доступом уступает им обоим в масштабируемости. В мандатном методе централизованный характер принятия решений (который не способствует масштабируемости) компенсируется простотой выполняемого алгоритма назначения прав. В дискреционном же методе, напротив, сложность механизма наделения правами компенсируется распределенным характером процедуры принятия решений.

Источник