3. Роль Читатель – эта Роль дается пользователю, который не имеет право редактировать какие либо данные. Этому пользователю разрешено просматривать данные протоколов и генерировать отчеты для их просмотра
Рубрики блога
- База тестов по Электробезопасности для ДНД ЭБ и ТБ 4
- Другие материалы 22
- Методики испытаний (измерений) 54
- Новости 108
- Программы испытаний (измерений) 25
- Руководство по программе ДНД ЭТЛ Профессионал .Нет 15
- Справка по работе с программным комплексом ДНД Конструктор Однолинейных Схем 3
- Справка по работе с программой ДНД Наряд-Допуск ПРО 15
- Справка по работе с программой ДНД Электробезопасность и ТБ 7
- Справка по работе с программой ДНД ЭТЛ Профессионал .Нет 24
- Справка по работе с редактором тестов к ДНД Электробезопасность и ТБ 4
- Статьи 6
Последнее видео на нашем YouTube канале
ПОПУЛЯРНЫЕ IT-ПРОФЕССИИ | Кто такие айтишники?
Наши Контакты
ИП Рыженков Д.Н.
Россия, Иркутская обл. г. Братск
ОГРНИП: 309380534100021
ИНН: 380506515557
EMail:
Сот. телефон: доступен по этой ссылке →
Последние сообщения на форуме
Ответ на: Создание наклеек на щиты для аппаратов защиты Обновите программу до версии 1.0.13: От Денис, 2 месяца назад
Создание наклеек на щиты для аппаратов защиты В руководстве пользователя указана возможность создания. От Electroas, 2 месяца назад
Ответ на: Добавить автоматический выключатель на секционный выключатель. Такого функционал пока нет в программе. М. От Денис, 3 месяца назад
Добавить автоматический выключатель на секционный выключатель. Здравствуйте, можно ли добавить автоматический выключат. От _Alex_, 3 месяца назад
Источник: www.etlpro.ru
Роль в программе это
В данной работе рассматриваются способы хранения информации о правах доступа к различным частям программ и данных. Работа может быть интересна программистам, реализующим многопользовательские системы.
Термины
При создании приложения, которое используют несколько пользователей, возникает задача ограничения доступа. Существует несколько способов решения этой задачи. Выбор оптимального способа зависит от дополнительных условий и особенностей приложения.
Самый простой способ ограничения доступа — когда есть список пользователей, которым разрешено работать со всей программой целиком. Для его реализации потребуется одна таблица с полем «пользователь». Проверке на входе в программу — единственная проверка.
- пользователь;
- программа;
- функция программы
часть программы, позволяющая пользователю выполнить некоторое осмысленное и нужное действие. - право;
пользователю может быть дано или не дано право использовать некоторую функцию программы. - роль (набор прав);
- группа пользователей.
1. Пользователи, права, роли и группы
Роли и группы могут быть использованы как дополняющие друг друга (ортогональные) концепции. Поэтому есть четыре варианта их применения: не использовать ни одну из них, использовать по только группировку пользователей, использовать только группировку прав, использовать группировку пользователей и прав одновременно.
1.1. Набор прав
В этом случае некоторому пользователю дается (или не дается) право выполнять некоторую операцию. Так как операции и пользователи связаны отношением «многие — ко — многим» здесь потребуются уже три таблицы: «пользователи», «операции», «пользователь имеет право на операцию».
1.2. Группы пользователей
В случае если программой пользуется большое количество пользователей, то назначать права каждому пользователю становится неудобно. Тогда вводят понятие «группа пользователей». Сначала пользователей объединяют в группы (например, на территориальной основе, по возрастному признаку, совершеннолетние — несовершеннолетние), а затем определяют права для групп.
При этом при добавлении нового пользователя в систему вместо назначения ему прав достаточно просто добавить пользователя в нужную группу. Пользователи и группы в общем случае связаны соотношением «многие — ко — многим». При этом иногда возникает потребность запретить какое-то право отдельному пользователю группы. Кроме того, права могут назначаться как группам, так и отдельным пользователям. Для этого потребуется следующая структура:
1.3. Ролевая модель
Если у программы много функций, которые удобно логически сгруппировать, то вводят понятие «роль» — набор функций, необходимых для выполнения некоторой работы. Так, например, для программы автоматизации школы такими ролями могут быть «ученик», «учитель», «родитель», «завуч». Пользователь может иметь несколько ролей, например, быть одновременно учителем и родителем. Т.е. пользователи и роли связаны отношением «многие — ко — многим», так же как и пользователи и группы в схеме с группами пользователей. В обеих схемах можно не давать возможности назначать индивидуальным пользователям индивидуальные права. В этом случае потребуется такая схема:
1.4. Модель с ролями и группами
Чтобы обеспечить максимальную гибкость для ограничения доступа ролевую модель и группы пользователей объединяют в общую модель. В этом случае роли могут назначаться группам, что еще уменьшает объем администрирования.
В итоге получается тетраэдр, в вершинах которого находятся пользователи, группы, роли и права, а на ребрах — таблицы для моделирования отношения «многие — ко — многим»
1.5. Оптимизация
1.5.1. Маски прав
Если прав фиксированное количество, то можно завести в таблицах «пользователь-право», «группа-право» и «роль-право» дополнительные поля, например по одному полю на каждое право. Тогда таблицу «право» можно сделать подразумеваемой. Если прав меньше 32, то можно все дополнительные поля объединить в одно и назвать это «маской прав».
1.5.2. Эффективные права
Кроме того, можно вычислить эффективные права и добавить поле в таблицу «пользователь-право». Это потребует обновления этого поля при каждом изменении других таблиц, однако существенно ускорит проверку прав.
2. Объекты
Права в программе могут разграничиваться не только по функциям, но и по объектам. К примеру, один и тот же пользователь может иметь право «только чтение» для одной папки и «полный доступ» для другой папки.
2.1. Права на объекты
В этом случае права должны даваться не вообще, а на конкретные объекты. Однако так как на разные объекты могут даваться одинаковые права, то можно воспользоваться следующей структурой:
Т.е. дополнить таблицу «пользователь — право» колонкой, в которой будет указано, к какому объекту это право дано. Точно так же должны быть расширены таблицы: роль-право, группа-право и группа-роль. Таким образом, разграничивая доступ к объектам, мы добавляем новое измерение к модели.
Если же позволить назначать права не только на объекты, но и на группы объектов (т. к. назначать права на каждый объект в отдельности трудоемко), то получаем шесть сущностей (пользователь, группа, право, роль, объект, группа), которые объединяются восемью тройными связями. Восемью, так как у нас три пары сущностей, а 2^3 = 8. Еще есть три двойные связи (право-роль, пользователь-группа и объект-группа).
Это подводит к мысли — нельзя ли обойтись общей таблицей «право на»?
2.2. Иерархии объектов
Объектов, как правило, очень много, существенно больше, чем пользователей и прав. Поэтому объекты не только объединяют в группы, но и организовывают в иерархии (вероятно, появятся системы, в которых группы и роли так же образуют иерархии). Иерархию можно изобразить в виде дерева. При этом права могут назначаться непосредственно листу или узлу, либо могут браться права узла более близкого к корню. Это называется наследованием прав.
В случае наследования прав возникает вопрос — что делать, если установлен флаг «права наследуются» и права определены непосредственно для самого объекта. Одно из решений — объединять такие права (как на допуск, так и на недопуск), другое — не позволять определять права для объекта, если установлен флаг «права наследуются».
В случае если берутся либо права предка, либо права объекта, можно завести у объекта поле — откуда брать права. Это поле является кешем и должно обновляться при изменении поля «права наследуются» у объекта и у его предков.
Заключение
В данной работе рассмотрены различные схемы хранения информации о правах доступа. Для конкретной системы нужно строить свою схему исходя из требований по быстродействию и уровню ограничения доступа.
Источник: citforum.ru
Управление ролями пользователей
Разграничение доступа на основе ролей (ролевая модель управления или RBAC) – популярный подход, использующийся в различных информационных системах (далее – ИС), приложениях и сервисах: базах данных, программах учета, CRM, облачных платформах и так далее. Например, RBAC применяется для управления полномочиями пользователей в Kubernetes, в Yii2, SELinux («Линукс» с повышенной безопасностью), Exchange Server и множестве других решений, которые используются компаниями из разных сфер. Управление доступом на основе ролей можно организовать и в других ИС (приложениях), даже если это не предусмотрено разработчиками «в базе». Делается это с помощью IdM-системы. Практически все решения этого класса (и Solar InRights, в частности) ориентированы как раз на использование RBAC с возможностью «подмешивания» других моделей.
Роли в ролевой модели и управление ими
Один из главных плюсов ролевого управления доступом – гибкость. С его помощью также можно смоделировать другие модели (например, DAC или MAC). Также RBAC является основанием или расширением для LBAC (управление доступом на основе решетки). За счет этого модель получила широкое распространение и популярность у компаний из разных сфер.
Ей даже посвящено несколько международных стандартов. Основные из них: INCITS 359-2012, INCITS 494-2012, INCITS 459-2011.
Предоставление пользователям доступа к информационным системам/ресурсам в RBAC и наделение их полномочиями осуществляется через роли.
Роль – это совокупность прав доступа, на основе которых проверяется возможность выполнения пользователем того или иного действия в целевой информационной системе. Также ее описывают как круг пользователей/сотрудников, которым может быть поручена определенная функция.
Роли в целевых информационных системах повторяют бизнес-роли в компании (т. е. RBAC позволяет выстроить систему управления доступом практически в полном соответствии с корпоративной иерархией и структурой компании). Они могут быть простыми (разрешать какое-то одно действие) и составными (объединять множество операций и полномочий). Одному сотруднику может присваиваться любое количество ролей (в зависимости от должности). За счет этого и обеспечивается гибкость: например, работникам на одинаковых должностях можно предоставлять различные полномочия.
В качестве примера роли можно рассмотреть пользователя root в Unix-подобных системах. Это – суперпользователь, который обладает неограниченными полномочиями. Такую роль могут использовать разные администраторы системы.
Операции по управлению ролями пользователей
В современных IdM-системах реализованы различные функции по управлению ролями. Например, в Solar InRigts с ними можно производить следующие действия:
- Создание. Это процесс привязки роли к целевой информационной системе (далее – ИС) и определения возможностей/полномочий, которые она предоставляет пользователю, которому назначена.
- Анализ. Позволяет быстро оценить, в каких системах авторизован сотрудник компании и какие права ему там предоставлены. За счет этого специалист по информационной безопасности или руководитель в любой момент времени владеет полной картиной, касающейся доступов и полномочий сотрудников компании в разных ИС.
- Изменение, активация, деактивация. При изменении состава роли происходит автоматическое централизованное изменение полномочий/доступов пользователей, которым она назначена. Это экономит немало времени на внесении необходимых изменений.
- Объединение по группам (каталогам). В больших компаниях с множеством сотрудников при использовании RBAC образуются сложные многомерные модели. Благодаря возможности объединения ролей по группам обеспечивается их максимальное приближение к штатной структуре, упрощается поиск нужной информации о пользователях, их правах/доступах/полномочиях.
- Установка запретов на сочетание полномочий. Это обеспечивает управление SoD-конфликтами. Запреты на сочетание полномочий/доступов могут устанавливаться как в рамках какой-то одной роли, так и между ними.
Важно учитывать, что роль может включать в себя должностной, типовой или индивидуальный доступ, и выстраивать процессы управления, отталкиваясь от этого. Должностной – это набор полномочий, который предоставляется сотрудникам одного подразделения на одинаковых должностях (например, роль с таким доступом может звучать как «Менеджер отдела продаж»).
Типовой предоставляется с учетом специфики работы сотрудника или для выполнения определенных функций (например, «Менеджер отдела продаж филиала N»). Индивидуальный предоставляется для решения конкретной задачи, поставленной работнику. При использовании RBAC таких доступов не должно быть более 5–10% от общего количества. В противном случае управлять полномочиями становится сложнее и модель от ролевой больше отклоняется в сторону дискреционной (DAC).
Еще одна важная составляющая процесса управления ролями пользователей – их регулярный аудит или ресертификация. Он сводится к проверке соответствия полномочий пользователей в ИС назначенным им ролям. Это позволяет выявлять доступы и права, полученные дополнительно по отдельным заявкам и принять решение об изменении/дополнении стандартных ролей. Или же проводится проверка на соответствие полномочий той или иной роли действующему функционалу работника или подразделения, чтобы вовремя скорректировать ролевую модель. Также за счет этого обнаруживаются неактивные учетные записи, которые могут стать источниками инцидентов в сфере информационной безопасности, избыточные полномочия и другие ситуации, которые могут привести к нарушению ИБ компании.
Возможно ли ручное управление ролями пользователей в компании? Вполне. Но все зависит от количества сотрудников и ИС, использующихся в организации. Опыт показывает, что вручную управление возможно в компаниях с количеством сотрудников до 100 человек. Если сотрудников около 500 – это будет значительно труднее.
Если штат еще больше – свыше 1000, – на управление в ручном режиме уйдет немало времени и лучше подумать о внедрении IdM или аналогичного решения. ПО этого класса позволяет реализовать в компании ролевую RBAC и обеспечить эффективное управление процессами, связанными с предоставлением доступа к корпоративной информации.
Источник: rt-solar.ru