Часто возникают вопросы защиты конфигурации от "внешних" врагов. Но известно, что самый страшный враг – "внутренний". А самый "злобный" враг – пользователь ;-).

Я хочу затронуть тему реализации системы безопасности на V7. Эта задача иногда бывает востребована.

По настройке доступа к базе данных и по защитам конфигурации есть достаточное количество статей. Это такие средства, как терминал, SQL, PGP, внешние компоненты, ключи защиты с кодом. Жаль, что и сама V7 имеет некоторое количество уязвимостей (калькулятор, табло, пункты меню "Файл", "Сервис" и т.д.), которые возможно закрыть от пользователя только патчем движка.

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

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

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

Каждый пользователь в системе выполняет определенную роль, согласно своим должностным обязанностям. Доступ к объектам может быть настроен как по ролям, так и по конкретным пользователям. Так же доступ к объектам может быть различным: "закрыт", "просмотр", "редактирование" и т.д.

Проработка положения, какому пользователю присвоить какую роль, а какая роль имеет какие типы доступа к каким объектам по умолчанию – типичная аналитическая задача. Хотя в 95% случаев положение будет составлять "1С:программист" (а раз так, то и назовем его бизнес-аналитиком ;-).

Пара слов о технической реализации. Решений много. Приведу несколько интересных.

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

У объектов типа "документ" и "справочник" логично хранить информацию об авторе (создателе документа) и корректоре (последнем пользователе, который редактировал/перепроводил документ).

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

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

Для справочников в форме списка есть возможность не отображать "закрытые" элементы – через механизм использование списка. Правда, это решение имеет неприятности в виде проблем с основными действиями с элементами (я нарисовал свою панель инструментов с отработкой основных действий). Можно не отображать наименования "закрытых" объектов, закрывать доступ к группам.

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

Для ручной операции можно ввести похожие функции, как для документа, а можно её просто заменить "дублирующим" документом.

Журнал проводок – я закрыл его вообще. Считаю, что это пережиток от V6, неудобный и ненужный.

С отчетами посложнее. Для плана счетов можно так же использовать разделение доступа. В отчетах можно реализовать "закрытость" по счетам, а можно по аналитике.

Я использовал ещё такое решение: если при формировании, например, карточки счета встречается "закрытое" значение, то отчет просто прерывает своё формирование.

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

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

В общем, в технической реализации есть раздолье для творчества. Борьба с пользователем – это "вечная" задача. Главное, чтобы всё было скрупулезно проделано, а действия были осмысленными.

Оригинал статьи опубликован на сайте www.itland.ru