что такое роль как объект конфигурации
Анализ ролей доступа
Как часто у вас бывала такая ситуация, когда нужно понять почему нет доступа к объекту конфигурации? Данный вопрос обычно решается путем открытия конфигурации и пролистывания вправо очень широкую таблицу с ролями:
Для упрощения данной задачи предназначена данная обработка, она позволяет быстро найти необходимы объект конфигурации, посмотреть какие роли используются для доступа к нему, и получить группы доступа в которые входит данная роль.
Так же обработка позволяет выбрать роль и посмотреть, на какие объекты она влияет:
либо объекты для выбранной роли на вкладке «По ролям»:
В случае работы с первой вкладкой «По объектам», на соотв. ролях по правой кнопке мыши доступно контекстное меню с пунктом «Получить группы доступа», при выборе которого выводятся группы доступа для выбранной роли:
Данная обработка тестировалась на платформах 1С:Предприятие версии 8.3.14 и выше на файл-серверном и клиент-серверном варианте.
Управление доступом: роли, права, профили, группы доступа, функциональные опции, RLS
1. Права доступа.
На самом деле все очень просто. В 1С по умолчанию запрещено всё, что не разрешено. Есть только одна сущность, отвечающая за доступ пользователя к какой-либо функциональности или данным. Эта сущность называется «Право доступа». Она является единственным элементом, отвечающим за доступ к конкретному режиму работы, справочнику, реквизиту.
Количество видов прав доступа предопределено платформой. Всего платформе есть две основные группы прав доступа. Общие для всей системы права доступа к механизмам платформы, отвечающие за доступ к определенным режимам работы платформы (Администрирование, Монопольный режим, Тонкий клиент,Интерактивное открытие внешних отчетов. ). И объектные права доступа, позволяющие работать с различными объектами конфигурации. Их количество зависит от типа объекта конфигурации. Например, у справочника есть 16 различных видов доступа (Чтение, Добавление, Изменение, Удаление. ). Для регистра сведений видов доступа всего пять. Все эти права можно установить только на уровне справочника целиком. Также можно ограничить доступ на уровне реквизитов. Но в этом случае доступна лишь часть видов прав (для справочников это права Просмотр и Редактирование).
Все права доступа связаны между собой и зависят друг от друга. Есть права более высокого и более низкого уровня. Нельзя дать право более низкого уровня, если у пользователя нет права на действия более высокого уровня.
Рассмотрим права доступа к справочнику. На данной схеме видно, что большинство прав является уточнением более общих прав. Если Право1 полностью расположено на схеме внутри прямоугольника другого Права2, то Право1 не может быть выдано без выдачи Права2. Самым общим правом является право «Чтение». Если право «Чтение» отсутствует, то недоступны и все остальные права. Если недоступно право «Добавление», то нельзя установить право «Интерактивное добавление». Однако, систему прав нельзя назвать полноценной иерархией. Например, право «Редактирование» можно дать лишь при наличии прав «Просмотр» и «Изменение». Но можно дать «Просмотр» без «Изменение» или «Изменение» без «Просмотр».
Право доступа это минимальная единица доступа. Все управление доступом сводится к выдаче пользователю нужного набора прав. Остальные объекты (роли, группы доступа) это просто дополнительная обвязка, служащая для группировки и более удобной выдачи прав доступа.
Рассмотрим схему назначения пользователям прав доступа, используемую в большинстве типовых конфигураций. В упрощенном виде ее можно представить следующим образом. Вводятся новые сущности «Профиль доступа» и «Группа доступа». В каждый профиль доступа включается несколько ролей. И каждому пользователю назначается одна или несколько групп доступа. Далее каждая группа доступа связывается с профилем доступа. В итоге мы получаем возможность указывать для пользователя не просто роли, а комплекты ролей в зависимости от выполняемых им функций.
С технической точки зрения данная система выдачи прав реализовывается с участием двух стандартных подсистем. Подсистема «Управление доступом» используется для настройки связи групп доступа с предопределенными в конфигурации ролями. Подсистема «Пользователи» используется для настройки связей пользователей ИБ с группами доступа конфигурации.
3. «Логика разрешений» как правило пересечения ролей.
Важно понимать, что в 1С общая логика управления доступом это логика разрешений. В платформе 1С вообще нет никаких механизмов запрета доступа. Есть только механизмы выдачи доступа. По умолчанию доступ ко всем данным запрещен, и настройка доступа заключается в выдаче каждому пользователю нужных ему прав. Это означает, что если какой-то ролью пользователю дано право на просмотр документов «Реализация товаров», то никакими способами нельзя это право отнять другими ролями или любыми другими механизмами платформы и конфигурации. Можно изначально выдать не полный доступ к справочнику, а отфильтровать с помощью RLS данные, на которые мы даем доступ. Но если доступ уже выдан, то забрать его другими ролями уже нельзя.
Именно поэтому при ограничении ролями доступа пользователям к справочнику очень важно проверять, что пользователю не назначена никакая другая роль на тот же справочник. Иначе первая роль даст нужный доступ, который не сможет запретить вторая.
В платформе есть возможность дать пользователю дополнительные права на время выполнения отдельной операции. Эта возможность называется «Привилегированный режим». Он позволяет пользователю выполнять действия над данными, которые ему не доступны. Однако, в платформе нет возможности даже временно уменьшить имеющиеся у пользователя права.
4. Косвенное управление доступом.
Есть отдельные механизмы, который хоть и не предназначены напрямую для управления доступом, косвенного на него влияют и могут использоваться для дополнительных ограничений. Рассмотрим их основные возможности.
4.1. Функциональные опции.
К системе управления доступом иногда относят механизм функциональных опций. Это не совсем верно, так как функциональные опции никак не влияют на доступ к данным. Это исключительно интерфейсный механизм, предназначенный для упрощения интерфейса для пользователя. Он появился в платформе 8.2 как результат усложнения функционала конфигураций. Функциональные опции предназначены для скрытия из интерфейса функционала, не используемого в данной конкретной компании или данным конкретным пользователем. Механизм влияет только на отображение данных. Из интерфейса исчезают команды, а на формах скрываются реквизиты, отключенные функциональными опциями. При этом у пользователя остается доступ ко всем этим командам и реквизитам. Он может без каких-либо проблем работать со скрытыми данными программно при помощи обработок.
Подробнее о работе с функциональными опциями можно почитать на ИТС
4.2. RLS (Record Level Security)
Все перечисленные выше механизмы влияют именно на предоставление доступа к объектам вцелом. К справочникам, документам, реквизитам справочников. Права доступа влияют на доступ к объектам, функциональные опции на отображение объектов в интерфейсе. Часто возникает задача разрешить пользователю доступ к данным справочника или документа. Но не ко всем данным, а лишь к их части. Например, разрешить доступ к документам реализации только по одной организации.
Для настройки такого разрешения есть дополнительный механизм RLS (Record Level Security). Как и следует из названия, этот механизм контроля доступа на уровне конкретных записей таблиц. Если права доступа дают доступ к таблицам вцелом (справочникам) или колонкам таблиц (реквизитам), то RLS определяет конкретные строки таблиц (записи), с которыми разрешено работать пользователю. Он позволяет определить данные, которые пользователю доступны.
С учетом общей сложности механизмов обычно достаточно сложно разобраться, что именно доступно конкретному пользователю типовой конфигурации. Для проверки выданных прав в типовых конфигурациях есть очень удобный отчет, который так и называется «Права доступа». Он анализирует все выданные пользователю права и отображает итоговый список прав выданный всеми группами доступа с учетом фильтров RLS.
4.3. Разделение данных.
Еще один механизм, который влияет на доступ к данным, это разделение данных. Этот механизм предназначен для ведения в одной физической базе данных нескольких независимых баз, имеющих общую конфигурацию и общие справочники. В отдельных очень ограниченных случаях этот механизм может рассматриваться как управление доступом. При его включении каждый пользователь может работать лишь в какой-то одной своей независимой базе, но использовать при этом общие данные.
В каком-то общем смысле этот механизм можно считать тоже фильтром на данные и частным случаем реализации RLS. В отличии от RLS разделение гораздо более жесткий механизм. И благодаря этой жесткости у разработчиков есть техническая возможности дополнительными индексами сделать такую фильтрацию без свойственных RLS замедлений работы.
Фактически RLS это просто дополнительные отборы, добавляемые автоматически к каждому запросу к базе данных. Разделение данных это добавление разделителя во все разделенные таблицы и их индексы, в том числе в кластерный. Данные группируются в разрезе разделителя, т.е. физически перераспределяются по диску в отдельные группы по каждому значению разделителя. Благодаря этому каждый пользователь работает только со своими данными, и серверу не нужно при каждом запросе физически просматривать всю таблицу. Достаточно просмотреть только область данных текущего раздела.
Однако именно из-за этого физического перераспределения данных, при работе полноправного пользователя, у которого нет фильтра по значениям разделителя, все запросы выполняются очень и очень медленно. Без значения разделителя невозможно полноценное использования индексов, поэтому объем физически считываемых с диска и обрабатываемых при каждом запросе данных может возрастать на порядки. Соответсвенно, в реальности разделение имеет смысл, только если все постоянно работающие в базе пользователи будут работать только внутри своей области.
Подробнее о разделении данных можно почитать на ИТС, а также в блоге http://howknow1c.ru.
4.4. Программный код.
Пожалуй, наиболее универсальный способ установки дополнительных ограничений это программный код. Им можно повлиять на любые механизмы платформы. Например, разработчик для ограничения доступа к документам может добавить фильтр в форму списка документов, в форму выбора, может проверять программно возможность просмотра данных документа при открытии конкретной формы документа. Разработчик в своих отчетах может наложить фильтр при отборе данных.
Однако, программным кодом нет возможности ограничить права вцелом по конфигурации. Максимум, который разработчик может сделать, это встроить ограничения в конкретные отдельные механизмы получения данных. Благодаря тому, что в 1С используется объектная модель работы с данными, программный код может гарантированно защитить данные от изменения, добавив нужные проверки в модуль объекта. Но разработчик никак не может полностью гарантировать, что пользователь точно не сможет получить информацию о чужих документах реализации другими отчетами или обработками.
Такой принцип используется, например, в расширении «Кодан». Подключаясь к конфигурации, расширение добавляет пользовательские ограничения и проверки во все справочники и документы. Оно фильтрует данные, отображаемые пользователям в списках, проверяет доступ при просмотре или изменении данных. Обеспечивает невозможность изменения запрещенных данных. Но не может фильтровать данные в отчетах или запросах.
Всегда остаются варианты получения запрещенных данных запросом, собственной обработкой или отчетом. Разве что очень жестко ограничить перечень используемого пользователем функционала конфигурации и добавить отдельный фильтр в каждый механизм (форму, обработку, отчет, запрос), разрешенный пользователю.
4.5. Сравнение вариантов.
Попробуем кратко сравнить рассмотренные варианты дополнительного ограничения данных.
Как включить
Что при этом произойдет
1. Добавить место хранения функциональной опции: константа, реквизит справочника или ресурс регистра сведений.
2. Добавить в конфигурацию функциональную опцию и указать в ней созданное ранее место хранения.
3. Указать в свойствах функциональной опции ее состав, отметить все объекты конфигурации, которые будут от нее зависеть.
4. Включить использование функциональной опции в режиме предприятия.
1. Все объекты, включенные в состав функциональной опции, перестанут отображаться в командном интерфейсе.
2. В формах и отчетах исчезнут все скрытые опцией поля.
1. Прописать фильтры RLS в каждой роле пользователя для каждого из прав, которые нужно ограничить.
Примечание: В режиме предприятия никаких действий выполнять не нужно. Фильтры применятся автоматически.
1. Настроенный фильтр будет добавляться к каждому запросу к ИБ.
2. Данные, не подходящие под фильтр RLS нельзя будет получить никакими средствами: они не будут отображаться в формах, отчетах; не будут отбираться никакими запросами.
1. Добавить в конфигурацию общий реквизит, определеяющий состав разделяемых данных.
2. Добавит два параметра сеанса: для признака использования и текущего значения разделения данных.
3. Добавить программный код, обеспечивающий включение разделения данных и заполнения текущего значение разделителя.
1. Сразу после добавления в конфигурацию возможности разделения данных физически перестроятся таблицы, для которых добавилась возможность разделения.
2. После включения разделения.
1. Сделает именно то, что написано.
Примечание: код не влияет на конфигурацию вцелом, а лишь на конкретный механизм, для которого прописываается действие
5. Итоги.
У каждого способа настройки ограничений свои плюсы и минуса. С точки зрения технологии наиболее правильный способ это грамотное разбиение на роли. Для фильтрации доступных данных надежнее всего использование RLS. Именно для этой задачи механизм предназначен. Точечные ограничения проще всего выполнять с помощью программного кода. Функциональные опции и разделение данных достаточно специфичные механизмы, не предназначенные для ограничения доступа. Хоть в некоторых случаях и могут для этого использоваться.
Объект 1С «Роли». Привилегированный режим 1С
Объект 1С «Роли»
Объект «Роли» предназначен для определения набора прав (совокупности разрешений) пользователей конфигурации (ограничения прав доступа в прикладных решениях). Роль определяет, какие действия, над какими объектами метаданных может выполнять пользователь, выступающий в этой роли.
Роль в конфигурации может соответствовать:
для работы которых предназначена данная конфигурация (например, «Администратор» или «Продавец»).
В процессе ведения списка пользователей прикладного решения каждому пользователю ставится в соответствие одна или несколько ролей (т.е. в версии 1C 8.х каждый пользователь может иметь несколько ролей).
Для каждого из объектов (справочники, документы) разработчик устанавливает свой набор прав — чтение, запись, изменение, и т.д.
По умолчанию доступ ко всем данным запрещен. Настройка доступа заключается в выдаче каждому пользователю нужных ему прав: если какой-то ролью пользователю дано право на просмотр, например, документов «Накладная», то никакими способами нельзя это право отнять (другими ролями или любыми другими механизмами платформы и конфигурации). Т.е. если доступ уже выдан, то забрать его другими ролями нельзя. Поэтому при ограничении ролями доступа пользователям к справочнику очень важно проверять, что пользователю не назначена никакая другая роль на тот же справочник.
Можно изначально выдать не полный доступ к справочнику, а отфильтровать с помощью RLS данные, на которые мы даем доступ.
При попытке пользователя выполнить действие, на которое у него нет разрешения, действие выполнено не будет, а система выдаст окно предупреждения «Нарушение прав доступа».
Настройка объекта «Роли» 1С
Окно настройки объекта «Роли» содержит две вкладки:
Настройка объекта «Роли» на вкладке «Права»
Вкладка «Права» окна настройки объекта «Роль» содержит:
Список прав на всю конфигурацию 1С:
УправлениеИтогами — управление итогами регистра бухгалтерии и регистра накопления (установка периода, по который рассчитаны итоги, и пересчет итогов).
Объекты конфигурации
Роли. Конструктор ограничения доступа к данным
Роли в системе 1С:Предприятие определяют полномочия пользователей на работу с информацией, которая обрабатывается в системе. Совокупность предоставляемых пользователю полномочий определяется, как правило, кругом его обязанностей.
В каркасной конфигурации создана роль «Администратор», добавим роль «Менеджер». Выделив в дереве объектов конфигурации ветвь Роли, из контекстного меню выбираем пункт «Добавить» и создаем роль «Менеджер», при этом открывается окно настройки прав данной роли.
Все права, поддерживаемые системой 1С:Предприятие, можно разделить на две большие группы: основные и интерактивные. Основные права описывают действия, выполняемые над элементами данных системы или над всей системой в целом, и проверяются всегда, независимо от способа обращения к данным. Интерактивные права описывают действия, которые могут быть выполнены пользователем интерактивно. Соответственно проверяются они только при выполнении интерактивных операций стандартными способами, причем в клиент-серверном варианте все проверки прав (кроме интерактивных) выполняются на сервере.
Основные и интерактивные права взаимосвязаны. Например, существует основное право Удаление, которому соответствуют два интерактивных права: Интерактивное удаление и Интерактивное удаление помеченных. Если пользователю запрещено Удаление, то и все интерактивные «удаления» также будут запрещены для него. В то же время, если пользователю разрешено Интерактивное удаление помеченных, это значит, что Удаление ему также разрешается.
Кроме того, основные права могут зависеть друг от друга. В результате образуются довольно сложные цепочки взаимосвязей, которые отслеживаются системой автоматически: как только разработчик снимает разрешение на какое-либо право, система сама снимает разрешения на все права, которые зависят от этого права. И наоборот, при установке какого-либо права разработчиком, система сама устанавливает все права, от которых это право зависит.
Например, для того, чтобы пользователь имел право интерактивного удаления помеченных, ему необходимо обладать правом просмотра и правом удаления. А право удаления, в свою очередь, подразумевает наличие права на чтение:
Пользователю может быть назначено несколько ролей. В этом случае алгоритм предоставления доступа по каждому объекту и виду права доступа будет работать следующим образом:
Среди действий над объектами, хранящимися в базе данных (справочниками, документами и т.д.), есть действия, отвечающие за чтение или изменение информации, хранящейся в базе данных. К таким действиям относятся:
Для этих действий в процессе настройки ролей могут быть заданы дополнительные условия на данные (ограничение доступа к данным). В этом случае над конкретным объектом, хранимым в базе данных, может быть выполнено запрошенное действие только в том случае, если ограничение доступа к данным для данных этого объекта принимает значение «истина». Аналогичные условия могут быть заданы и для таблиц базы данных, не имеющих объектной природы (регистров).
Для объектных таблиц и регистров сведений могут быть заданы разные ограничения для различных полей таблицы, что позволяет определять ограничения не только на уровне записей базы данных, но и на уровне отдельных ее полей:
Ограничение доступа к данным представляет собой условие, описанное на языке, который является подмножеством языка запросов. Это условие применяется для каждой записи таблицы базы данных, над которой выполняется операция. Если условие принимает значение «истина», то операция выполняется, а если нет, то не выполняется. При просмотре списков и формировании отчетов существует возможность обеспечить отображение только тех данных, доступ к которым пользователю разрешен.
Для регистров накопления, бухгалтерского учета и расчета условия позволяют разграничить доступ по значениям измерений (для регистров бухгалтерского учета по балансовым измерениям), а для объектных данных и регистров сведений условия позволяют разграничивать доступ к данным по любым полям.
Для каждого ограничения по праву «Чтение» допускается выбор поля. Выбор поля означает, что в выборке запроса будут присутствовать только данные, в которых по указанному полю будет удовлетворяться условие (проверка производится только по данному полю).
«Прочие поля» означает, что проверка выполнения условия будет производиться по каждому полю, и, если условие выполняется, данные выбираются.
Условие ограничения можно ввести вручную или создать с помощью конструктора ограничения доступа к данным. Для вызова конструктора в табличном поле «Ограничение доступа к данным» в колонке «Ограничение доступа» перейдите в режим редактирования и нажмите кнопку выбора.
На экран выводится форма конструктора:
По своей сути конструктор ограничений доступа к данным представляет собой упрощенный конструктор запросов. Он позволяет выбрать нужные таблицы и поля, задать условия связи между полями таблиц и условия на отбор исходных данных.
Параметры сеанса представляют собой объекты прикладного решения, которые предназначены для использования в ограничениях доступа к данным для текущего сеанса (но могут применяться и для других целей). Их значения сохраняются в течение данного сеанса 1С:Предприятия. Использование параметров сеанса позволяет снизить время доступа к данным при ограничении доступа на уровне записей и полей. В каркасной конфигурации создан параметр сеанса «ТекущийИсполнитель».
Существует возможность назначения привилегированных модулей. В такие модули могут быть перенесены операции, использующие данные, на которые у текущего пользователя нет прав и операции, на выполнение которых у пользователя также нет прав.
Например, пользователю могут быть назначены права, позволяющие создавать новый документ. Однако никаких прав на регистр, в котором этот документ создает движения при проведении, пользователю не дано. В такой ситуации процедура проведения документа может быть вынесена в привилегированный модуль, который выполняется на сервере без проверки прав. В результате, несмотря на то, что соответствующий регистр для пользователя недоступен, пользователь все же сможет проводить созданные им документы.