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

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

Введение

Система контроля прав доступа должна позволять:

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

Недостатки типовой системы правил 1С:

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

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

Формализация контекста операции

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

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

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

Таким образом, любой запрос на разрешение операции можно записать в виде контекста операции – объекта с набором свойств.

Формализация правил кодом

Рассмотрим способы, которыми можно анализировать контекст и выдавать заключение о допустимости операции.

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

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

Если (Конт.Фирма = «СтройВсе»)И Пользователь<>«Главбух» Тогда

Сообщить(«По фирме СтройВсе работать может только главбух»);

Возврат Ложь;

ИначеЕсли (Конт.Клиент = «ЧП Федоров»)И Пользователь =«Сидоров» Тогда

Возврат Истина;

….

При подобной реализации важно следить за порядком условий. Если в нашем примере мы переставим местам правила, то пользователь Сидоров сможет работать с документом по клиенту «ЧП Федоров», даже если документ выписан по фирме «СтройВсе».

При всей простоте такой реализации она обладает двумя недостатками:

1. Любое изменение правил приходится изменять в коде программы.
2. Нужно очень внимательно следить за порядком применения правил.

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

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

Формализация правил шаблонами

Другой способ – описание шаблонов контекста.

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

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

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

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

Осталось только решить два вопроса, которые мы и рассмотрим далее:

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

Обобщение ситуаций

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

Указание диапазона

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

Обобщение списком

Можно указать некоторый список значений.

Обобщение группой

Можно указать некоторую группу значений вместо отдельного значения, например:

Обобщение синонимом

Если имеется информация, что значение Б является синонимом значения А, то все правила, относящиеся к А, действуют и по отношению к Б.

Пусть, например, определены синонимы Иванов=Петров, тогда:

Разрешение конфликтов

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

Конфликты разной детализации

Такие конфликты разрешаются очень просто.

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

Конфликты разной общности

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

Например, всем менеджерам запрещено вводить новые товары, а Иванову, который тоже является менеджером, разрешено.

В таблице приведены частные и общие ситуации для различных способов обобщения.

Конфликты одинаковой общности

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

Например, пользователю разрешен доступ по фирме «СтройВсе», но запрещен доступ по клиенту «Иванов». Как поступить, когда пользователь работает с документом выписанным по фирме «СтройВсе» и клиентом «Иванов»?

Можно, в принципе ввести приоритеты и обрабатывать правила в порядке приоритетов (в принципе такую возможность нужно обеспечить в системе контроля прав, добавив в правила поле Приоритет – максимальный приоритет 0, затем 1 и т.д.).

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

Таким образом, если есть хоть один запрет в правилах с одинаковым приоритетом, то доступ запрещен.

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

Сложные конфликты

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

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

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

Решение конфликтов с помощью приоритетов

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

Некоторые полезные методы реализации

Роли

Удобно описывать правила не для конкретных пользователей, а для ролей пользователей. Роли удобно назначать в конфигураторе 1С 8.0 или в справочнике пользователя простым списком для 1С 7.0.

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

Действия

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

Можно указать группы действий, например «ДействияМенеджера» и назначать правила сразу на всю группу действий.

Объекты операции

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

Также некоторые виды документов лучше сгруппировать, например, создав пересекающиеся или непересекающиеся группы документов «Производственные», «Торговые», «Денежные», «Взаиморасчеты» и т.п.

Предопределенные значения

Для разрешения/запрещения доступа по конкретным фирмам можно в справочнике указывать непосредственное значение фирмы, сделав возможность указания как отдельной фирмы, так и логической (а не 1Сной) группы фирм.

То же самое касается складов и других справочников.

Прочее

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

Заключение

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

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

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

Буду благодарен за любую критику.

Пример реализации

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

Есть следующие роли Кладовщик, Менеджер, Бухгалтер, Директор, Администратор, Бэкап, Стажер.

Менеджер выписывает расходные накладные, Кладовщик отпускает по ним товар (проводит расходные накладные), Бухгалтер смотрит торговые документы и делает проводки, Директор просматривает все документы, но ничего ввести не может, Бэкап делает выгрузки-загрузки данных, работая только в конфигураторе, Администратор может все.

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

Стажер может править документы только текущим днем, менеджеры не более чем неделю назад.

Стажер входит в группу ролей Менеджер

Как видим, Иванову запрещено работать в 1С предприятии, кем бы он ни был – менеджером, стажером и т.п.

Остальные правила понятны.

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

Понятно, что редактировать этот справочник (регистр сведений) можно как вручную, так и приказами (распоряжениями).

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

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

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

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