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


Содержание материала:

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

Здравствуйте, уважаемые посетители портала! Меня зовут Александр Омельченко, я – но вый сотрудн ик компании Cleverics. Буду заниматься проектами по внедрению решений IDM и управлению доступом. В связи с появлением нового направления в компании, хочу рассказать подробнее про связанные с управлением доступом понятия. Сегодня поговорим о наиболее популярной на сегодняшний день модели предоставления доступа – управление доступом на основе ролей, известной как RBAC (Role Based Access Control).

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

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

Идея предоставления доступа на основе ролей возникла из необходимости группировки наборов прав в какие-то отдельные сущности, которые четко давали бы понять, какой доступ есть у пользователя, с которыми было бы удобнее и понятнее работать в случае изменений как положения пользователя в организации, так и набора прав доступа пользователя. Исторически сложилось, что наборы прав стали привязывать к должностям сотрудников, по сути – к функциональным ролям. Отсюда появилось понятие роли. Первые приложения, реализующие ролевое управление доступом пользователей, начали появляться еще в 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, как единственная модель предоставления доступа, не подходит для более общей проблемы управления правами большого количества разнообразных пользователей и динамического доступа пользователей во многих системах.

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

Управление доступом на основе ролей (англ. Role Based Access Control, RBAC ) — развитие политики избирательного управления доступом, при этом права доступа субъектов системы на объекты группируются с учетом специфики их применения, образуя роли. [1] [2]

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

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

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

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

История

Элементарные формы модели RBAC были осуществлены во множестве специальных форм на многих системах, начиная с 1970-х годов. Контроль доступа на основе ролей, используемый в настоящее время происходит из модели, предложенной Ферраильо (англ. Ferraiolo ) и Куном (англ. Kuhn ) (1992) и как образцовая модель позже усовершенствованная Санди (англ. Sandhu ), Койн, Фейнштейн, и Йоман (1996).

  • 1992 — статья Ферраильо и Куна, определяющая RBAC посредством доступа только через роли, иерархии и ограничения. формальная модель;
  • 1994 — DTOS базировал опытный образец RBAC, на прототипе модели прдложенной Ферраильо, Кун, Гаврилья (англ.Gavrila )
  • 1994 — статья Nyanchama и Osborn определяет модель;
  • 1994 — файлы IBM (в Европе) первая заявка на патент в области RBAC, цитирующая Ферраильо и Куна;
  • 1995 — Ферраильо, Кугини (англ.Cugini ), Кун расширили формальную модель, введя определение форм разделения обязанностей;
  • 1996 — метод Санди для того, чтобы осуществить МАС на основе RBAC;
  • 1997—1998 — Sybase, Безопасное Вычисление,
  • 1997 — Безопасное Вычисление включает модель Ферраильо-Куна RBAC в американскую Глобальную Команду DoD и Систему управления; выходит статья Куна на тему разделения обязанностей, необходимых и достаточных условий для безопасности разделения;
  • 1997 — статья Осборна основанная на отношениях между RBAC и многоуровневой безопасностью мандатной модели политики безопасности; аннотация роли, связывающая RBAC и многоуровневую безопасность
  • 1998 — RBAC — метод Куна для того, чтобы осуществить RBAC на системе МАС;
  • 1999 — Барклей (англ.Barkley ), Ферраильо, Кун открывают исходный опытный образец RBAC для развитых веб-серверов;
  • 2000 — Санди, Ферраильо, Кун публикуют статью, определяющую объединенную модели RBAC, и предлагают стандарт RBAC;
  • 2004 — Американский Национальный Институт Стандартов, Международный Комитет по Стандартам Информационной технологии (ANSI/INCITS) принимает предложенную Санди, Ферраильо и Куном модель RBAC как единый стандарт.

Базовая модель RBAC

Для определения модели RBAC используются следующие соглашения:

  • U = Субъект (англ.Subject ) = Человек или автоматизированный агент (множество пользователей);
  • R = Роль (англ.Role ) = Рабочая функция или название, которое определяется на уровне авторизации (множество ролей);
  • P = Разрешения (англ.Permissions ) = Утверждения режима доступа к ресурсу (множество прав доступа на объекты системы);
  • S = Сессия (англ.Session ) = Соответствие между U, R и/или P
  • UA = Назначение субъекта (англ.Subject Assignment )
  • PA: R -> 2 p — функция, определяющая для каждой роли множество прав доступа; при этом для каждого p ∈ P существует r ∈ R такая, что p ∈ PA(r); (англ.Permission Assignment )
  • RH = Частично упорядоченная иерархия ролей (англ.Role Hierarchy ). RH может быть еще записана так: ≥
  • Один субъект может иметь несколько ролей.
  • Одну роль могут иметь несколько субъектов.
  • Одна роль может иметь несколько разрешений.
  • Одно разрешение может принадлежать нескольким ролям.

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

  • , при этом разрешения назначаются связям ролей в отношении «многие ко многим».
  • , при этом субъекты назначаются связям ролей и субъектов в отношении «многие ко многим».

Обозначение: x ≥ y означает, что x наследует разрешения y.

Субъект может иметь множество одновременных сессий с различными разрешениями.

Возможности и применение

Технология управления доступом на основе ролей достаточно гибка и сильна, чтобы смоделировать как избирательное управление доступом (DAC) [3] , так и мандатное управление доступом (MAC) [4]

До разработки RBAC, единственными известными моделями управления доступом были MAC и DAC: если модель была не MAC, то она была DAC, и наоборот. Исследования в 90-х показали, что RBAC не попадает ни в ту, ни в другую категорию.

Роли создаются внутри организации для различных рабочих функций. Определенным ролям присваиваются полномочия (permissions) для выполнения тех или иных операций. Штатным сотрудникам (или другим пользователям системы) назначаются фиксированные роли, через которые они получают соответствующие привилегии для выполнения фиксированных системных функций. В отличие от управления доступом на основе контекста (англ. context-based access control, CBAC ), реализация RBAC в чистом виде не принимает во внимание текущую ситуацию (такую как, например, откуда было установлено соединение).

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

Концепции иерархии ролей и ограничений позволяют создать или смоделировать контроль доступа на основе решетки (англ. lattice-based access control, LBAC ) средствами RBAC. Таким образом, RBAC может быть основанием и расширением LBAC.

В организациях с разнородной IT-инфраструктурой, содержащих десятки и сотни систем и приложений, помогает использование иерархии ролей и наследования привилегий. Без этого использование RBAC становится крайне запутанным. В статье «Дополнительные роли: практический подход к обслуживанию пользователей предприятия» [5] обсуждаются стратегии, альтернативные большому масштабу присвоения привилегий пользователям.

Современные системы расширяют старую модель NIST [6] ограничениями RBAC для развертывания на больших предприятиях. Существует несколько академических документов и по меньшей мере одна коммерческая система — Beyond NIST.

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

RBAC широко используется для управления пользовательскими привилегиями в пределах единой системы или приложения. Список таких систем включает в себя Active Directory, FreeBSD, Solaris, СУБД Oracle, , SAP R/3, Lotus Notes и множество других.

Salesforce – создание иерархии ролей

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

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

Определение иерархии ролей

В этом разделе мы обсудим, как определить иерархию ролей. Шаги описаны ниже –

Шаг 1

Чтобы создать иерархию ролей, перейдите по ссылке « Настройка» Главная → Пользователи → Роли → Настройка ролей. Иерархия ролей по умолчанию выглядит так, как показано ниже.

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

Шаг 2

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

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

Шаг 3

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

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

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

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

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

Рис. 10.2. Пользователи, объекты и роли.

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

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

В 2001 году Национальный институт стандартов и технологий США предложил проект стандарта ролевого управления доступом (см. http://csrc.nist.gov/rbac/), основные положения которого мы и рассмотрим.

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

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


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

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

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

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

Рис. 10.3. Фрагмент иерархии ролей.

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

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

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

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

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

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

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

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

Не нашли то, что искали? Воспользуйтесь поиском:

Управление Ролями 101

Эта статья поможет Вам, когда Вы захотите разобраться, как работает опция Ролей и ассоциированных разрешений в Discord. Здесь мы поговорим о

  1. Цвета Ролей
  2. Иерархия Ролей
  3. Разрешения Канала

Часть первая: Цвета Ролей

Вначале это не будет сразу заметно, но очень полезным — это касается того, как роли себя ведут во вкладке ролей. Чтобы все упростить:

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

Это касается не только самих разрешений, но и цвета тоже! Вы можете увидеть разницу достаточно просто здесь:

Даже если я имею все три роли, «Cool Kids» самая высшая роль, поэтому я получу обалденный розовый цвет, у BOXES и у меня те же самые роли за исключением Cool Kids, поэтому он наследует следующую по важности роль и цвет — «Chicken», и сиреневый цвет.

Вы можете поменять местами роли и их положение на метафорическом тотемном столбе:

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

Вы так же увидите цвет Вашей наивысшей роли в в списке пользователей:

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

Часть вторая: Иерархия Ролей

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

Линейная иерархия ролей:

Роли следуют линейной иерархии. Или, если выражаться простым языком, «метафорический тотемный столб» сейчас является более буквальным на практике.

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

Администратор:

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

Управлять Ролями:

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

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

Важное замечание о добавлении ролей: роль @everyone сейчас служит, как базис для всех добавленных ролей. Хотите, чтобы кто-либо на Вашем сервере добавлял каналы по своему усмотрению? Делегируя «Manage Channels» с испольованием @everyone автоматически предоставит такое разрешение permission всем остальным ролям, которые были созданы. Любая роль, которая делегирована с использованием @everyone будет распространяться на всех несмотря на делегирование высших ролей.

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

Блокирование/Удалить/Название Иерархии:

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

Часть три: Разрешения канала

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

Клонировать канал:

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

Создание текстовых каналов с эксключивными ролями:

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

1. Во-первых, отменяется разрешение «читать сообщения» для роли с использованием @everyone в рамках действия этого нового канала, канал становится недоступным и невидимым.

2. Также, добавляется исключение для избранной роли (ролей). Вы увидите оба эти измнения, которые отобразятся на экране Разрешений Канала.

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

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

FossDoc Администратор. Группы пользователей

Группы делятся на два вида:

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

Описание встроенных групп

Встроенные группы пользователей и их назначение приведены в таблице:

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

Просматривать историю могут только те пользователи, которые входят в данную группу

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

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

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

Эта группа является частью программного продукта FossLook

Ответственные редакторы общих папок В отличие от группы «Ответственные редакторы общедоступных папок пользователей» пользователи данной группы имеют возможность создавать общедоступные папки в корне общих папок. Эта группа является частью программного продукта FossLook
Отдел кадров Группа пользователей, которые могут видеть и редактировать личные данные других сотрудников, например, такие как описание, фотографии. Изменять должность, руководителя. А так же, при подключенном модуле «Почта Интернет», добавлять адрес электронной почты пользователя
Право закрытия документов В карточке документа есть поля «Дата закрытия документа» и «Инициатор закрытия документа». Пользователи данной группы имеют право устанавливать значения в эти поля
Право коррекции сроков в поручениях Пользователи данной группы могут изменять сроки исполнения любых поручений
Право накладывать резолюцию Пользователи данной группы могут создавать резолюции. Запись о резолюции добавляется на закладку «Резолюции» карточки документа
Право оправки поручений от имени другого лица В отличие от группы «Операторы исполнения», данные пользователи могут только отправлять поручения от имени других без визирования
Право подписи документов В эту группу входят пользователи, у которых есть право подписи документов. Запись о подписи документа добавляется на закладку «Подпись документа»
Право просмотра всех маршрутов Пользователи данной группы могут просматривать все маршруты документов. По умолчанию пользователи могут видеть только маршруты, в которых они участвуют
Право удалять маршруты в документах Все пользователи, состоящие в данной группе, при включенной соответствующей опции смогут удалять любые маршруты в любых документах
Регистраторы Члены данной группы могут регистрировать документы. Запись о регистрации появляется на закладке «Регистрационные записи»
Редактирование групп рассылок Право на редактирование групп рассылок. Группа рассылок – это именованная группа пользователей, которым одновременно можно отправить документ
Редакторы справочников подсистемы физических лиц Пользователи этой группы имеют возможность редактировать справочник физических лиц. Данный справочник используется при работе с обращениями граждан

Группы пользователей, созданные администратором

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

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

Форма свойств группы пользователей

Введите наименование группы в поле «Группа». Нажмите кнопку Добавить участников и в появившемся диалоге выберите пользователей (или группы пользователей), которые будут входить в создаваемую группу:

Диалог выбора пользователей или групп пользователей

Нажмите ОК.

Место роли в модели бизнес-процесса

Выбранные пользователи появятся в списке «Члены группы»:

Форма свойств группы. Выбраны пользователи – члены группы

Нажмите Cохранить изменения на форме свойств группы.

Роли пользователей

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

Закладка «Роль сотрудника» Выбор ролей


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

Основные и опциональные группы доступа для выбранной роли

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

1 Введение

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

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

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

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

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

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

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

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

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

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

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

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

  • Дискреционный метод контроля доступа
  • Обязательный метод контроля доступа
  • Ролевой метод контроля доступа.

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

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

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

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

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

Средства Дискреционного Контроля за Доступом (Discretionary Access Control — DAC) обеспечивают защиту персональных объектов в системе. Контроль является дискреционным в том смысле, что владелец объекта сам определяет тех, кто имеет доступ к объекту, а также вид их доступа.

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

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

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

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

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

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

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

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

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

Средства Обязательного Контроля за Доступом (Mandatory Access Control — MAC). Контроль является обязательным в том смысле, что пользователи не могут изменять стратегию MAC в отношении объектов. При создании объекта система автоматически присваивает ему атрибуты MAC, и изменить эти атрибуты может только администратор, имеющий соответствующие полномочия. Средства MAC не позволят пользователю случайно или преднамеренно сделать информацию доступной для лиц, которые не должны обладать ею.

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

Основная идея ролевой модели контроля за доступом (Role-Based Access Control — RBAC) основана на максимальном приближении логики работы системы к реальному разделению функций персонала в организации.

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

Из диаграммы видно, что связи «Назначение ролей пользователям» и «Назначение привилегий» принадлежат типу много в много. Пользователь может иметь несколько ролей и несколько пользователей могут принадлежать одной роли. Аналогично несколько привилегий могут принадлежать одной роли и несколько ролей могут иметь одну и ту же привилегию. Также в этой модели присутствует частично упорядоченное множество — иерархия ролей. На этом множестве задано отношение принадлежности где для ролей x и y, x > y означает что роль x наследует привилегии роли y. Это отношение транзитивно.

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

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

и — непересекающиеся наборы ролей и административных ролей

и — непересекающиеся наборы привилегий и административных привилегий.

  • — Привилегия -> Роль отношение много в много.

— Привилегия -> Административная роль отношение много в много.

  • — Пользователь -> Роль отношение

— Пользователь -> Административная роль отношение

  • — частично упорядоченная иерархия ролей

— частично упорядоченная иерархия административных ролей.

  • — функция ставящая в соответствие каждой сессии пользователя (постоянного на время жизни сессии)

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

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

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

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

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

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

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

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

Профиль 3/6. Мученик – ролевая модель.

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

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

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

Системы с ролевым управлением доступом целесообразно использовать в больших организациях, со сложной иерархией и большим количеством разделяемых операций. В такой системе данные обычно принадлежат не пользователю а системе. И управление доступом к ресурсам основывается не на принадлежности ресурса, а на функциях пользователя в организации. Вообще говоря, ролевой метод управления доступом является модификацией модели обязательного, но он не основан на многоуровневой системе требований к безопасности. Также важно понимать, что 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

Идентификация и аутентификация, управление доступом

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

Основные понятия

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

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

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

Таблица 10.1. Фрагмент матрицы доступа

Файл Программа Линия связи Реляционная таблица
Пользователь 1 orw с системной консоли e rw с 8:00 до 18:00
Пользователь 2 a

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

В 2001 году Национальный институт стандартов и технологий США предложил проект стандарта ролевого управления доступом (см. http://csrc.nist.gov/rbac/), основные положения которого мы и рассмотрим.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Административные роли

На этой странице

Adobe Admin Console позволяет организациям задавать гибкую административную иерархию, которая обеспечивает строгий контроль над доступом к продуктам Adobe и их использованием. Верхнюю ступень в иерархии занимают один или несколько системных администраторов, учетные записи которых были созданы на этапе развертывания установки. Эти системные администраторы могут делегировать полномочия другим администраторам, сохраняя при этом контроль над установкой в целом.

Основные преимущества административных ролей для организаций:

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

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

Административную иерархию можно использовать для приведения в соответствие с потребностями организации. Например, организация может поручить управление правами на Adobe Creative Cloud и Adobe Marketing Cloud разным администраторам. Кроме того, администраторам можно поручить управление правами пользователей из разных подразделений.

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

Привилегированный пользователь организации; может выполнять любые задачи администрирования в Admin Console.

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

Управляет продуктами, назначенными данному администратору, и выполняет все связанные задачи администрирования, а именно:

  • Создание профилей продуктов.
  • Добавление пользователей и групп пользователей в организацию (но не удаление).
  • Добавление или удаление пользователей и групп пользователей из профилей продуктов.
  • Добавление или удаление администраторов профилей продуктов из профилей продуктов.
  • Добавление или удаление других администраторов продукта из продукта.
  • Добавление или удаление администраторов группы из групп.

Управляет описаниями групп пользователей, назначенных данному администратору, и выполняет все связанные задачи администрирования, а именно:

  • Добавление или удаление пользователей из групп.
  • Добавление или удаление администраторов группы пользователей из групп.
Роль Описание
Системный администратор
Администратор продукта
Администратор профилей продуктов Управляет описаниями профилей продуктов, назначенных данному администратору, и выполняет все связанные задачи администрирования, а именно:

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

Подробный список разрешений и прав для каждой роли администратора см. в разделе Разрешения.

Добавление администратора

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

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

В консоли Admin Console выберите Пользователи > Администраторы . Отобразится список существующих администраторов.

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

Нажмите Добавить администратора . Откроется мастер Добавить администратора .

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

Дайджест психологических исследований

Страницы

24.03.2015

Как иерархия в группе влияет на её эффективность?

Иерархия является одной из базовых культурных ценностей. Два самых известных и влиятельных подхода к пониманию культурных ценностей включают иерархию в число основных. Шварц определяет иерархию как подчёркивание легитимности неравного распределения власти, ролей и ресурсов. Представители иерархических культур соблюдают правила и обязательства, регламентированные иерархией ролей и демонстрируют уважение к начальству [1]. Хофстеде использует концепт дистанции власти – степень того, насколько представители сообщества принимают неравенство в распределении власти [2].

Существует два взгляда на влияние иерархии на эффективность группы. Первый постулирует, что иерархия – это хорошо: чётко определённые роли в группе, хорошая координация членов группы, интеграция информации в одном центре, меньшее количество конфликтов. В соответствии со вторым иерархия – это плохо: ограничивает возможность высказывать мнение для членов группы с низким статусом, снижает чувство психологический безопасности, затрудняет коммуникацию. Группа исследователей под руководством Adam Galinsky недавно опубликовала в PNAS статью [3], в которой проверила правоту обеих позиций.

Самое примечательное в их исследовании – это данные, с которыми она работали. Исследователи проанализировали данные по 5,104 экспедициям (всего 30,625 альпинистов) из 56 стран, совершившим восхождения в Гималаях с 1905 по 2012 годы. В анализ были включены только монокультурные экспедиции, состоящие только из представителей одной культуры. В среднем в одной экспедиции было 7 человек, из которых в среднем до вершины добрались только 2–3 альпиниста, 549 (около 1.8%) погибли. Хотя бы одна смерть была в каждой из 12 экспедиций (около 8%). Именно эти реальные показатели – достижение экспедицией вершины и количество погибших её членов – и рассматривались в качестве реальных параметров эффективности экспедиций.

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

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

Таким образом, результаты этого исследования эмпирически подтверждают оба взгляда на влияние иерархии на эффективность группы. Она действительно увеличивает групповую эффективность, но за это увеличение группа платит определённую цену, которая может быть довольно высокой (как в случае групп альпинстов). _______________________________________________
[1] Schwartz, S. (1999). A Theory of Cultural Values and Some Implications for Work. Applied Psychology: An International Review, 48(1), 23. doi:10.1080/026999499377655

[2] Hofstede, G. (2001). Culture’s Consequences: International Differences in Work-related Values (Sage, Thousand Oaks, CA), 2nd Ed.

[3] Anicich, E. M., Swaab, R. I., & Galinsky, A. D. (2015). Hierarchical cultural values predict success and mortality in high-stakes teams. Proceedings of the National Academy of Sciences, 112(5), 1338–1343. doi:10.1073/pnas.1408800112

Salesforce – создание иерархии ролей

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

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

Определение иерархии ролей

В этом разделе мы обсудим, как определить иерархию ролей. Шаги описаны ниже –

Шаг 1

Чтобы создать иерархию ролей, перейдите по ссылке « Настройка» Главная → Пользователи → Роли → Настройка ролей. Иерархия ролей по умолчанию выглядит так, как показано ниже.

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

Шаг 2

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

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

Шаг 3

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

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

Топ-пост этого месяца:  Урок 9. Постраничная навигация комментариев
Добавить комментарий