Важное значение в управлении организацией на основе корпоративных информационных систем (далее ИС) имеет разграничение доступа пользователей к имеющимся ИС и их элементам.
Типы моделей доступа
Разграничение доступа может быть построено на разных типах моделей:
- Дискреционная модель (англ. Discretionary Access Control, DAC). При дискреционной модели организации доступа права отдельным пользователям назначает администратор ИС, реже владельцы сущностей ИС [4].
- Мандатная модель (англ. Mandatory Access Control, MAC). Мандатная система строится на уровне доступа. Например, по восходящей степени секретности и закрытости информации могут быть уровни: «не секретно», «секретно», «совершенно секретно». Пользователь с низшим уровнем доступа не может получить доступ к сущностям ИС более высокого уровня секретности [4].
- Ролевая модель (англ. Role Based Access Control, RBAC) [2]. При ролевой модели доступ к сущностям ИС осуществляется на основе вхождения пользователей в роли. Роли могут быть выстроены как на основе отдельных персоналий, организационной структуры, так и на основе функциональных обязанностей или смешанным образом. Ролевая модель доступа из всех вышеперечисленных наиболее совершенная в силу своей гибкости [4].
- Атрибутивная модель (англ. Attribute-based Access Control, ABAC). Атрибутивная модель связывает права доступа с определенными элементами системы и их состояниями [4].
На практике используются смешанные модели, т.к. они обладают большей гибкостью. Далее будет рассмотрен пример ИС управления контентом, включающей в себя юридически значимый электронный документооборот (сокращенно СЭДО) со смешанной моделью доступа. Для целей этого примера важно дать определение информационным сущностям, используемым в ИС. Документ — это юридически значимый контент, обеспеченный юридически-значимым документооборотом, в доме числе электронным. Контент — это информация, создаваемая и распространяемая в электронно-цифровом или любом другом виде.
Смешанная модель доступа
Доступ к ИС на основе смешанной модели состоит из структур:
- Элементы системы — части ИС, к которым получают доступ роли.
- Роли — это элементы ИС, посредством которых пользователи получают разрешения в ИС. Роли могут быть персональными, системными, статическими и вычисляемыми.
- Разрешения — права, получаемые ролями в ИС.
- Условия — логика, на основании которой предоставляется доступ пользователям к ИС с помощью динамических и контекстных ролей, а также правил доступа. Дата и время — важное условие предоставления прав, т.к. права редко представляются навсегда. Состояния элементов системы — зафиксированные в ИС состояния её элементов. Состояния имеют важное значение при трансляции контента
Перечисленные структуры в рамках использования ИС состоят из различных элементов. Так, роли подразделяются:
- Статическая роль — простая групповая роль, не имеющая условий, глав и позволяющая использовать ее для настройки прав доступа в рамках различных бизнес-процессов и иерархических элементов. Статическая роль отличается от метароли, динамической и контекстной роли тем, что список сотрудников, имеющих доступ к ней, статичен, не подвержен автоматическим изменениям, связанным с какими-либо условиями, и может быть изменен только вручную.
- Организация — групповая статическая роль, верхний уровень ролевой модели организационной структуры. Важно выделять его в верхний уровень при любом масштабе организации. Это позволит подключать к ИС дочерние и привлеченные сторонние организации (далее ПСО) с набором прав, отличным от основной организации.
- Структурное подразделение — групповая статическая роль, верхний иерархический уровень организации, позволяющий создать вложенность подразделений. Структурное подразделение входит в организацию, состоит из главы, подчиненных сотрудников и дочерних подразделений. Структурными подразделениями могут быть, например, департаменты. В структурное подразделение могут входить директора структурных подразделений, заместители директоров и их секретари.
- Подразделение — групповая статическая роль, нижний иерархический уровень организации, в который входит, как правило, большая часть сотрудников организации, включая начальников отделов и их заместителей. Подразделениями могут быть, например, отделы.
- Проект — групповая роль, являющаяся частью организационной структуры, но не являющаяся частью ее основной иерархии. Подобная групповая роль может позволить настраивать доступы кросс-функциональным командам внутри организации. В отличии от статической роли может иметь главу с особыми полномочиями.
- Сотрудник — персональная роль, связанная с определенным сотрудником.
- Глава организационной структуры — руководитель структурного или обычного подразделения, а также проекта. Обычно наделен особыми полномочиями по постановке задач подчиненным сотрудникам и контролю их выполнения.
- Заместитель — особая персональная роль, которая выдается одним сотрудником для другого сотрудника с целью передачи ему собственных прав доступа к ИС, за исключением прав, полученных от другого сотрудника по замещению.
- Система — особая системная роль, предназначенная для обеспечения взаимодействия ИС или интегрируемой с ней системы с данными внутри ИС.
- Динамическая роль — вычисляемая групповая роль. Список сотрудников, имеющих доступ к ней, вычисляется на основе логики, заложенной в нее. Например, роль «Все сотрудники» в Тессе [3].
- Контекстная роль — вычисляемая групповая роль. Список сотрудников, имеющих доступ к ней, вычисляется на основе логики, заложенную в нее, с учетом контекста использования. Например, в роль «Автор документа» будут входить разные сотрудники, в зависимости от карточки контента.
- Метароль — вычисляемая роль, которая создается автоматически специальным механизмом генерации метаролей ИС. К подобным метаролям можно отнести роль «Структурное подразделение (все)», в которую входят все сотрудники одного структурного подразделения, включая дочерние подразделения.
- Администратор — эта роль является частью мандатной модели доступа. Администратор должен иметь полный доступ ко всем элементам ИС для их администрирования. В том числе он должен обладать правами на предоставление прав доступа другим пользователям ИС.
- Разработчик — эта роль является частью мандатной модели доступа. Администратор должен иметь полный доступ ко определенным элементам ИС для их разработки. В том числе он должен обладать правами на предоставление прав доступа другим пользователям ИС к тем элементам, к которым сам имеет доступ.
Примеры элементов ИС, к которым может быть осуществлен доступ:
- Клиент — первая часть трехзвенной системной архитектуры, где происходит взаимодействие пользователя с ИС. Ее обычно называют frontend или «мордой».
- Сервер — вторая часть трехзвенной системной архитектуры, где реализована основная бизнес-логика ИС, так называемый backend.
- Хранилище данных — третья часть трехзвенной системной архитектуры, где хранятся данные ИС. В широком смысле может включать в себя как отдельные базы данных, так и хранилища структурированных данных и озера слабо структурированных данных.
- Инфраструктура — весь комплекс технологий и информационных систем, обеспечивающих функционирование ИС. В современной действительности инфраструктура может иметь очень сложную архитектуру и критически важна для обеспечения заявленного SLA ИС.
- Рабочее место — основной пользовательский интерфейс ИС, выстраиваемый в зависимости от функций, которые требуется выполнять сотруднику. Например, рабочее место пользователя или администратора.
- Карточка контента — совокупная информация о контенте, представленная в интерфейсе ИС. Карточка контента может содержать:
- Идентификатор карточки;
- Состояние карточки;
- Вкладка карточки;
- Секция карточки;
- Поле карточки.
- Справочник — совокупность элементов, по наполнению которые не достаточны для создания для них отдельных карточек контента. Например, справочник состояний карточки.
- Представление — совокупность карточек контента или элементов справочника, представленные в табличном виде с возможностью поиска по ним.
- Поток работ (англ. WorkFlow) — бизнес-процессы, зафиксированные в ИС.
- Задание — отдельная задача бизнес-процесса, являющейся дочерней сущностью потока работ и связанная с выполнением определенных действий ИС или ее пользователями. Задание состоит:
- Автор;
- Исполнитель;
- Тип задания;
- Описание действий, требуемых к выполнению;
- Крайний срок выполнения.
- Файл
- Электронная подпись
- Ознакомление
- Уведомление
- Обсуждение
- Календарь
Разрешения для взаимодействия с элементами ИС:
- Запрещено — отсутствие прав на взаимодействие с контентом или элементом системы.
- Чтение — открытие контента или элемента ИС для ознакомления с ним, но без права на изменение, дополнения или удаления.
- Создание — создание и сохранение контента или элемента ИС без обязательного права не его редактирование, дополнение или удаление.
- Дополнение — дополнение контента или элемента ИС, без обязательного права на чтение или изменение существующей информации в них.
- Редактирование — изменение существующего контента или элемента ИС.
- Удаление — удаление контента или элемента ИС.
Условия предоставления прав:
- Логика функционирования системы, допустимая законами, внутренними распорядительными документами и бизнес-процессами организации, общепринятой деловой практикой и возможностями ИС.
- Дата и время предоставления и отзыва прав, количество дней и времени, на которые представляются права:
- Календарные дни;
- Рабочие дни;
- Нерабочие дни;
- Календарные часы;
- Рабочие часы;
- Определённые дни и время.
- Состояния элементов системы зависят от типа ИС и бизнес-процессов организации. Пример состояний карточек контента и заданий:
- Проект;
- На согласовании;
- Согласовано;
- На подписании;
- Подписано;
- Зарегистрировано;
- На выполнении;
- Выполнено;
- На проверке;
- Проверено.
Правила организации доступа к ИС
Некоторые практические правила организации доступа к ИС при смешанной модели с использованием ролей и атрибутов ИС:
- Ролевая модель доступа состоит из единичных и групповых ролей.
- Пользователь ИС (сотрудник или система, далее Пользователь) — это квант — неделимая минимальная сущность ролевой модели.
- Пользователи для получения разрешений в ИС обязательно должны входить хотя бы в одну групповую роль.
- Разрешения должны предоставляться только групповым ролям, а не отдельным Пользователям.
- В идеале ролевая модель должна повторять иерархическую структуру организации.
- Атрибутивная модель доступа состоит из элементов ИС и их дочерних элементов.
- Элемент ИС — это минимальная часть ИС, достаточно значимая для достижения целей существования ИС.
- Элементы ИС и их дочерние элементы могут быть в различных состояниях. Эти состояния являются одним из условий получения разрешения. Условиями получения разрешений могут быть также сценарные ветвления типа «если…, то…», циклы и другие виды условий различной степени сложности.
- В совокупности ролевая и атрибутивная модель, условия и разрешения в идеале должны представлять собой реализацию бизнес-процессов, которым служит ИС.
- Усложнение ролевой и/или атрибутивной модели усложняют всю модель доступа. Поэтому, в идеале, разрешение должно предоставляться для групповой роли, в которую напрямую входит Пользователь, на элемент ИС, а не на его дочерние элементы при соблюдении определенных условий.
- С точки зрения матрицы доступа, отсутствие условий для пары роль — атрибут свидетельствует об отсутствии прав доступа для этой пары.
Матрица доступа
Упрощенную смешанную модель прав доступа можно представить в виде плоской двумерной матрицы доступа, где по вертикали будут представлены роли, по горизонтали элементы ИС, а разрешения и условия их предоставлении на пересечении элементов ИС и ролей.
Элемент 1 ИС | Элемент 2 ИС | |
Роль 1 | Разрешение 1 (условие 1) | Разрешение 2 (условие 2) |
Роль 2 | Разрешение 3 (условие 3) | Разрешение 4 (условие 4) |
Пример.
Клиент | Сервер | Хранилище данных | … | Календарь | |
Организация | Запрещено (всегда) | Запрещено (всегда) | Запрещено (всегда) | … | Запрещено (всегда) |
Структурное подразделение | Запрещено (всегда) | Запрещено (всегда) | Запрещено (всегда) | … | Запрещено (всегда) |
Подразделение | Запрещено (всегда) | Запрещено (всегда) | Запрещено (всегда) | … | Запрещено (всегда) |
… | … | … | … | … | … |
Разработчик | Чтение (всегда), Создание (всегда), Редактирование (всегда), Удаление (всегда) | Чтение (всегда), Создание (всегда), Редактирование (всегда), Удаление (всегда) | Чтение (всегда), Создание (всегда), Редактирование (всегда), Удаление (всегда) | … | Чтение (всегда), Создание (всегда), Редактирование (всегда), Удаление (всегда) |
Другой вариант матрицы доступа — реляционная матрица. Она может быть реализована в виде таблицы по типу реляционной базы данных, где каждый атрибут можно сопоставить с таблицей-справочником его значений, а каждая строка это условия предоставления доступа. В этом варианте присутствует сложный внешний ключ из четырех атрибутов (пользователь, групповая роль, элемент ИС, дочерний элемент), а также множества атрибутов, каждое из которых соответствует одному разрешению. На пересечении строк с ключами и атрибутов-разрешений находятся условия предоставления разрешений. Одна строка этой матрицы содержит все разрешения предоставленные одному пользователю на один элемент ИС или его дочерний элемент при одном условии для одного разрешения. Эта матрица указывает на то, что одна групповая роль должна соответствовать одному сценарию развития бизнес-процесса.
Пользователь | Групповая роль | Элемент ИС | Дочерний элемент | Разрешение 1 | Разрешение 2 |
Сотрудник 1 | Роль 1 | Элемент 1 ИС | Дочерний элемент 1 элемента 1 | Условие 1 | Условие 2 |
Сотрудник 2 | Роль 1 | Элемент 1 ИС | Дочерний элемент 1 элемента 1 | Условие 1 | Условие 2 |
Система 1 | Роль 2 | Элемент 3 ИС | Дочерний элемент 1 элемента 3 | Условие 3 | Условие 4 |
Список использованных источников:
- Мандатное управление доступом и мандатный контроль целостности [В Интернете] / авт. astralinux.ru // astralinux.ru. — astralinux.ru, 12 октября 2010 г.. — https://wiki.astralinux.ru/pages/viewpage.action?pageId=153486002.
- ОС и СУБД: мандатное разграничение доступа [В Интернете] / авт. postgrespro.ru // postgrespro.ru. — postgrespro.ru, 21 июня 2017 г.. — https://postgrespro.ru/blog/media/229432?ysclid=lu45snkxt1919671585.
- Ролевая модель [В Интернете] / авт. ООО «Синтеллект» // ООО «Синтеллект». — ООО «Синтеллект», 23 марта 2024 г.. — https://mytessa.ru/docs/3.6/dev/dev/roles/.
- Как создать модель управления доступом, которая соответствует требованиям безопасности и нуждам бизнеса? [В Интернете] / авт. ООО «СОЛАР СЕКЬЮРИТИ» // ООО «СОЛАР СЕКЬЮРИТИ». — ООО «СОЛАР СЕКЬЮРИТИ», 05 октября 2023 г.. — https://rt-solar.ru/products/solar_inrights/blog/3742/.