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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

….

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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