В процессе сопровождения крупных или коммерчески чувствительных баз данных «1С:Предприятие» часто возникает классическая дилемма безопасности. С одной стороны, штатному администратору (или приходящему специалисту) необходимо предоставить права на обновление конфигурации, создание пользователей и обслуживание системы. С другой стороны, бизнес хочет полностью исключить риск кражи коммерческой информации путем выгрузки базы в файл резервной копии .dt.
На стандартных форумах часто можно услышать категоричный ответ: «От администратора защиты нет». Однако, если совместить возможности платформы 1С, механизмы Библиотеки стандартных подсистем (БСП) и настройки СУБД, эту задачу можно успешно решить. В этой статье мы подробно разберем несколько практических способов реализации такого разграничения прав.
Рассмотрим по шагам все доступные варианты решения проблемы — от простых настроек прав до продвинутой кастомизации программного кода.
Прежде всего проанализируем структуру прав в Конфигураторе 1С. Очень часто разработчики совершают ошибку, выдавая администратору одну единственную роль — Полные права (включающую право Администрирование). На самом деле платформа 1С позволяет гибко разграничить полномочия администратора.
Для того чтобы администратор мог обновлять базу, но не имел технической возможности запустить процесс выгрузки в .dt, мы должны настроить его роль в Конфигураторе следующим образом:
АдминистраторБезВыгрузки).После применения этих настроек наш администратор сможет полноценно работать в Конфигураторе (вносить изменения, обновлять базу из файлов .cf или .cfu), но пункт меню «Администрирование -> Выгрузить информационную базу...» окажется для него неактивным.
Возникает логичный вопрос: если у администратора остаются права на редактирование пользователей в режиме «1С:Предприятие» (в конфигурациях на базе БСП), что помешает ему создать нового пользователя, назначить ему роль «Суперадминистратор» (с полным правом выгрузки) и выполнить коварный план?
Для предотвращения этого сценария мы можем заблокировать отображение или выбор определенных ролей. Фрилансеры часто просят за этот «секрет» предоплату, но мы разберем его техническую реализацию бесплатно.
В современных конфигурациях управление доступом осуществляется через Профили групп доступа. Сами роли напрямую пользователям в Конфигураторе не назначаются — этим управляет БСП через общий модуль ПользователиСлужебный и функцию ЗапретРедактированияРолей().
Чтобы скрыть роль «Суперадминистратор» от обычного администратора, мы можем использовать механизм Расширений конфигурации. Напишем обработчик, который будет проверять права текущего пользователя и программно отключать видимость или доступность нашей секретной роли на форме выбора.
Рассмотрим пример кода в расширении для формы элемента справочника ПрофилиГруппДоступа:
&НаСервере
&После("ПриСозданииНаСервере")
Процедура Искл_ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Проверяем, обладает ли текущий пользователь привилегией Суперадминистратора
// (например, проверяем наличие специфической роли, которая есть только у владельца)
Если Не РольДоступна("СуперАдминистраторВыгрузка") Тогда
// Перебираем доступные роли на форме профиля и скрываем/делаем неактивной целевую роль
Для Каждого СтрокаРоли Из Объект.Роли Цикл
Если СтрокаРоли.ИмяРоли = "СуперАдминистраторВыгрузка" Тогда
// Вариант 1: Делаем строку недоступной для редактирования (галочка заблокирована)
СтрокаРоли.Доступность = Ложь;
КонецЕсли;
КонецЦикла;
// Дополнительно можно удалить роль из таблицы выбора на форме, чтобы администратор её даже не видел
ТаблицаРолей = РеквизитФормыВЗначение("ДоступныеРоли");
НайденныеСтроки = ТаблицаРолей.НайтиСтроки(Новый Структура("ИмяРоли", "СуперАдминистраторВыгрузка"));
Для Каждого СтрокаИзСписка Из НайденныеСтроки Цикл
ТаблицаРолей.Удалить(СтрокаИзСписка);
КонецЦикла;
ЗначениеВРеквизитФормы(ТаблицаРолей, "ДоступныеРоли");
КонецЕсли;
КонецПроцедуры
Благодаря этому коду обычный администратор при попытке настроить права себе или другим пользователям просто не увидит роль СуперАдминистраторВыгрузка в списке доступных для выбора ролей, либо эта галочка будет для него неактивна.
Выгрузка информационной базы в файл .dt имеет одну важную техническую особенность: она требует монопольного доступа к базе данных. Платформа 1С перед началом выгрузки пытается установить монопольный режим, отключая все активные сеансы.
Выясним, как мы можем использовать эту особенность для защиты данных в клиент-серверном варианте работы:
.dt, платформа не сможет сбросить это системное подключение СУБД, монопольный режим не установится, и процесс завершится ошибкой.При таком подходе даже если администратор базы 1С каким-то образом получит полные права в Конфигураторе, СУБД физически не позволит процессу rphosts перевести базу в монопольный режим для выгрузки.
Проанализируем ситуацию глубже: если у человека есть доступ к Конфигуратору и он может писать код, то технически он всегда сможет обойти программные ограничения (например, написать внешнюю обработку, которая выгрузит данные в XML, или создать собственное расширение конфигурации, отключающее любые проверки).
Поэтому наиболее надежным и профессиональным решением является внедрение четырехконтурной архитектуры разработки и администрирования:
Резервное копирование продуктивной базы при этом настраивается автоматически на уровне СУБД (планами обслуживания SQL) силами системных администраторов инфраструктуры. Администраторы 1С к этим файлам бэкапов доступа иметь не должны.
Таким образом, сочетание правильной настройки ролей в Конфигураторе (отключение права «Администрирование»), программное ограничение видимости ролей в интерфейсе БСП и выстраивание безопасной архитектуры развертывания обновлений позволяют полностью защитить базу данных от несанкционированного копирования.