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