В стандартной модели безопасности платформы 1С право Администрирование является достаточно «широким». Оно открывает доступ не только к управлению списком пользователей, но и к просмотру журнала регистрации, управлению сеансами и другими критически важными функциями. Часто перед разработчиком стоит задача: позволить конкретному сотруднику (например, специалисту отдела кадров или «младшему» администратору) только создавать пользователей и назначать им определенные права, не допуская его при этом к конфигуратору, тестированию и исправлению базы или выгрузке данных в .dt. В этой статье мы подробно разберем, как реализовать такое разделение прав.
Рассмотрим ситуацию: если мы просто назначаем пользователю стандартную роль с правом Администрирование, платформа автоматически дает ему возможность изменять практически любые параметры безопасности. Главная опасность здесь заключается в том, что такой «администратор пользователей» может легко создать нового пользователя с неограниченными правами (полными правами) или даже изменить пароль главному администратору системы. Чтобы этого избежать, нам нужно вынести процесс управления пользователями в контролируемое программное русло.
Проанализируем основной способ обхода ограничений платформы — использование программного интерфейса в привилегированном режиме. Этот метод позволяет выполнять операции с объектом ПользователиИнформационнойБазы даже в том случае, если у текущего пользователя нет на это прав в его роли.
Для реализации этого подхода выполним следующие шаги:
УправлениеПользователямиСервер).Пример кода в привилегированном модуле:
Процедура СоздатьНовогоПользователяПрограммно(ИмяПользователя, Пароль, СписокРолей) Экспорт
// В привилегированном режиме проверка прав платформой игнорируется
НовыйПользователь = ПользователиИнформационнойБазы.СоздатьПользователя();
НовыйПользователь.Имя = ИмяПользователя;
НовыйПользователь.Пароль = Пароль;
// Программный фильтр: запрещаем назначать роль "ПолныеПрава"
Для Каждого Роль Из СписокРолей Цикл
Если Роль.Имя <> "ПолныеПрава" Тогда
НовыйПользователь.Роли.Добавить(Роль);
КонецЕсли;
КонецЦикла;
НовыйПользователь.Записать();
КонецПроцедуры
Разберем, почему это работает. Программа выполняет запись объекта ПользователиИнформационнойБазы от имени системы, игнорируя отсутствие роли Администрирование у инициатора. При этом в коде мы можем жестко прописать любые проверки: какие роли можно назначать, какие символы использовать в пароле и т.д.
Выясним причину, по которой многие путают эти два права. В современных версиях платформы 8.3 эти права разделены:
Таким образом, если вы создадите роль, где включено Администрирование, но выключено Администрирование системы, пользователь сможет управлять списком сотрудников, но не сможет зайти в Конфигуратор или «сломать» структуру базы. Однако помните о риске «повышения прав»: такой пользователь все еще может создать себе или другому аккаунту роль с полными правами через стандартный интерфейс.
Проанализируем, как эта задача решена в типовых конфигурациях (ERP, ЗУП 3.1, БП 3.0). В составе БСП есть подсистема Пользователи. Она работает по следующему принципу:
Пользователи, но не имеющий доступа к системным настройкам.Это самый правильный путь для тиражных решений. Мы рекомендуем использовать встроенную роль АдминистраторСистемы (в понимании БСП), которая в сочетании с ограничениями на изменение определенных профилей дает нужный результат.
Рассмотрим дополнительные меры предосторожности, без которых разделение прав будет неэффективным:
1. Запрет внешних обработок
Если пользователю оставлено право ИнтерактивноеОткрытиеВнешнихОбработок, он может скачать или написать обработку, которая выполнит любой код в привилегированном режиме. Для «младшего администратора» это право должно быть строго отключено.
2. Контроль иерархии прав
При создании собственного интерфейса управления пользователями (например, через специальную обработку), важно внедрить проверку: создающий не может назначить другому пользователю те права, которых нет у него самого. Это предотвратит создание «суперпользователей» обычными кадровиками.
3. Внешняя аутентификация
Посмотрим на ситуацию шире: если ваша компания использует Active Directory (AD), администрирование можно полностью вынести за пределы 1С. В этом случае администратор 1С настраивает связь с доменом, а созданием учетных записей занимается системный администратор в AD. Пользователь в 1С создается автоматически при первом входе на основании шаблона прав.
Мы выяснили, что разделить права на администрирование пользователей и ИБ вполне реально. Основной путь — создание специализированной обработки для управления пользователями, которая взаимодействует с ПользователиИнформационнойБазы через серверный привилегированный модуль. Это позволяет полностью отобрать у пользователя опасные права уровня платформы, сохранив возможность оперативного управления доступом сотрудников.