Верить нельзя никому, даже себе!
…
Против лома нет приема!
…
Для любой хитрой сущности первого рода
есть сущность второго рода с винтом!
….
(три источника, три составных части
развития любой системы безопасности).
Описание проблемы:
Часто случается так, что в базе работают пользователи с полными правами, но имеют при этом «кривоватые руки». Иногда это бывают влиятельные «ответственные» лица, имеющие достаточно влияния, чтобы под благовидным предлогом «отжать» себе полные права. При этом отобрать у них полные права назад бывает нереально. Иногда это бывает из-за определенной неразберихи в системе прав, либо при начальном этапе внедрения, либо обусловленной сложившимися бизнес-процессами.
Не всегда такие пользователи ответственно относятся к своей работе. И хорошо при этом, что они по незнанию не могут натворить ничего плохого в базе. Хуже, когда кто-то из них узнает о потенциально опасных инструментах (вроде групповых обработок) и начинает жать на «Выполнить», не осознавая в полной мере последствий своих действий.
Как правило, полный доступ таким пользователям нужен для того, чтобы, не обращаясь ни к кому, что-нибудь провести, записать в базе или выполнить какую-нибудь обработку не опасного характера. Поэтому для восстановления порядка и гармонии в базе достаточно бывает ограничить доступ к фиксированному списку объектов конфигурации, имеющих критическое значение.
Предлагаемое решение:
К сожалению, в подтверждение к сказанному в эпиграфе к статье, полного и окончательного решения обсуждаемой проблемы нет. Можно предлагать лишь меры частного характера, действующие при определенных условиях и до определенной степени хитрости «сущностей первого рода».
Например, решить озвученную задачу можно методом «умножения»:
1) Создадим второй набор «полных» прав и обзовем его, допустим, роль “SA” (super-administrator).
2) В какой-нибудь удобный общий серверный модуль добавим экспортную функцию
для усиленной проверки полного доступа к базе вроде следующей:
// усиленная проверка полного доступа к базе
Функция ДоступПолный_Проверить(UserName = "", НеУчитыватьSA = Ложь) Экспорт
//для 8.1 функцию нужно поместить в привилегированный модуль
УстановитьПривилегированныйРежим(Истина); //и убрать эту строку!
Если ПустаяСтрока(UserName) Тогда
User = Неопределено;
Иначе
User = ПользователиИнформационнойБазы.НайтиПоИмени(UserName);
КонецЕсли;
ДоступПолный = ПравоДоступа("Администрирование",Метаданные,User)
И ПравоДоступа("ОбновлениеКонфигурацииБазыДанных",Метаданные,User)
И ПравоДоступа("МонопольныйРежим",Метаданные,User)
И ПравоДоступа("ИнтерактивноеОткрытиеВнешнихОбработок",Метаданные,User);
Если НеУчитыватьSA <> Истина Тогда
Если Метаданные.Роли.Найти("SA") <> Неопределено Тогда
Если User = Неопределено Тогда
ДоступПолный = ДоступПолный И РольДоступна("SA");
Иначе
ДоступПолный = ДоступПолный И User.Роли.Содержит(Метаданные.Роли["SA"]);
КонецЕсли;
КонецЕсли;
КонецЕсли;
Если Метаданные.Роли.Найти("ПолныеПрава") <> Неопределено Тогда
Если User = Неопределено Тогда
ДоступПолный = ДоступПолный И РольДоступна("ПолныеПрава");
Иначе
ДоступПолный = ДоступПолный И User.Роли.Содержит(Метаданные.Роли["ПолныеПрава"]);
КонецЕсли;
КонецЕсли;
Возврат ДоступПолный;
КонецФункции
3) С помощью указанной выше функции перед открытием форм или выполнением команд, имеющих критическое значение, проверяем наличие супер-прав и отказываем в доступе при их отсутствии.
Узкие места предлагаемого решения:
Помимо необходимости внесения изменения в конфигурацию базы, основным недостатком предлагаемого решения является то, что пользователь с «простыми» полными правами может сам себе назначить роль “SA”.
Для этого в 1С есть две стандартных возможности:
- Непосредственно в конфигураторе;
- Типовые средства управления правами в пользовательском режиме;
Допустим, средствами администрирования операционной системы (через публикацию нужных ярлыков) в конфигуратор 1С запрещено заходить, кому не следует. Тогда нам остается запретить доступ к роли “SA” через средства управления правами типовой конфигурации.
Для реализации этого запрета нужно исключить набор прав “SA” из списков ролей, предлагаемых для выбора типовыми средствами управления правами. Также нужно исключить обработку роли “SA” в тех местах кода конфигурации, где фактически изменяются права пользователей (чтобы не сбросить доступ к роли “SA”, установленный в конфигураторе).
Сделать это достаточно просто, конкретная реализация зависит от конфигурации базы.
Пример реализации запрета для конфигураций «родственных» УТ-11.1 приведен ниже.
Но это еще не все:
Пользователь с «простыми» полными правами может запустить внешнюю обработку, например, какую-нибудь консоль кода,
и с ее помощью назначить себе нужные права, выполнив простенький код:
ЯЯ = ПользователиИнформационнойБазы.ТекущийПользователь();
//ЯЯ = ПользователиИнформационнойБазы.НайтиПоИмени("Вася");
SA = Метаданные.Роли.SA;
Если НЕ ЯЯ.Роли.Содержит(SA) Тогда
ЯЯ.Роли.Добавить(SA);
ЯЯ.Записать();
КонецЕсли;
Чтобы заткнуть эту дырку, потребуется подрезать «простые» полные права:
- Запретить для «простых» полных прав запуск внешних отчетов и обработо;
- Также запретить публикацию внешних отчетов и обработок в справочнике «Дополнительные отчеты и обработки»;
Но и это еще не все (и продолжать можно до бесконечности):
Как верно подсказывает Stim213 в //infostart.ru/public/182849/, продвинутый ушлый пользователь может с помощью блокнота вставить указанный выше код в нужное место файла выгрузки данных (например, в текст кода обработчика “Перед загрузкой данных”). А затем при загрузке данных из файла в информационную базу получить себе нужные права.
Работающий пример реализации запрета доступа к роли “SA”:
Конфигурация «Управление торговлей, релиз 11.1.9.70» (версия БСП: 2.2.3.44).
Права пользователям задаются в профилях безопасности.
Для запрета доступа к роли “SA” типовыми средствами нужно сделать несколько вставок (выделены авторскими комментариями //+yuraos ) в следующие места исполняемого кода конфигурации:
Общий модуль «ПользователиСлужебный»:
Процедура ПодготовитьДеревоРолей(Знач Коллекция, Знач СкрытьРольПолныеПрава, Знач ПоказатьТолькоВыбранныеРоли, КоллекцияРолей)
Индекс = Коллекция.Количество()-1;
Пока Индекс >= 0 Цикл
Строка = Коллекция[Индекс];
ПодготовитьДеревоРолей(Строка.Строки, СкрытьРольПолныеПрава, ПоказатьТолькоВыбранныеРоли, КоллекцияРолей);
Если Строка.ЭтоРоль Тогда
Если СкрытьРольПолныеПрава
И ( ВРег(Строка.Имя) = ВРег("ПолныеПрава")
ИЛИ ВРег(Строка.Имя) = ВРег("АдминистраторСистемы")) Тогда
Коллекция.Удалить(Индекс);
Иначе
//+yuraos
Если СкрытьРольПолныеПрава И (ВРег(СокрЛП(Строка.Имя)) = "SA") Тогда
// роль SA выставляем персонально каждому в конфигураторе
Коллекция.Удалить(Индекс);
Индекс = Индекс-1;
Продолжить;
КонецЕсли;
//+yuraos
Строка.НомерКартинки = 7;
Строка.Пометка = КоллекцияРолей.НайтиСтроки(
Новый Структура("Роль", Строка.Имя)).Количество() > 0;
Если ПоказатьТолькоВыбранныеРоли И НЕ Строка.Пометка Тогда
Коллекция.Удалить(Индекс);
КонецЕсли;
КонецЕсли;
Иначе
Если Строка.Строки.Количество() = 0 Тогда
Коллекция.Удалить(Индекс);
Иначе
Строка.НомерКартинки = 6;
Строка.Пометка = Строка.Строки.НайтиСтроки(
Новый Структура("Пометка", Ложь)).Количество() = 0;
КонецЕсли;
КонецЕсли;
Индекс = Индекс-1;
КонецЦикла;
КонецПроцедуры
Процедура ОбновитьРолиВнешнихПользователей(Знач МассивВнешнихПользователей = Неопределено) Экспорт
//*****
Выборка = Запрос.Выполнить().Выбрать();
ПользовательИБ = Неопределено;
Пока Выборка.Следующий() Цикл
//+yuraos
Если ВРег(СокрЛП(Выборка.Роль)) = "SA" Тогда
// роль SA выставляем персонально каждому в конфигураторе
Продолжить;
КонецЕсли;
//+yuraos
Если ЗначениеЗаполнено(Выборка.Роль) Тогда
ПользовательИБ.Роли.Добавить(Метаданные.Роли[Выборка.Роль]);
Продолжить;
КонецЕсли;
Если ПользовательИБ <> Неопределено Тогда
ПользовательИБ.Записать();
КонецЕсли;
ПользовательИБ = ПользователиИнформационнойБазы.НайтиПоУникальномуИдентификатор(ИдентификаторыПользователейИБ[Выборка.ВнешнийПользователь]);
ПользовательИБ.Роли.Очистить();
КонецЦикла;
Если ПользовательИБ <> Неопределено Тогда
ПользовательИБ.Записать();
КонецЕсли;
//*****
КонецПроцедуры
Общий модуль «УправлениеДоступомСлужебный»:
Процедура ОбновитьРолиПользователейИБ(ОбновляемыеПользователиИБ, ПарольПользователяСервиса)
Для каждого КлючИЗначение Из ОбновляемыеПользователиИБ Цикл
РолиДляДобавления = КлючИЗначение.Значение.РолиДляДобавления;
РолиДляУдаления = КлючИЗначение.Значение.РолиДляУдаления;
ПользовательИБ = КлючИЗначение.Значение.ПользовательИБ;
ПользовательСсылка = КлючИЗначение.Значение.ПользовательСсылка;
БылиПолныеПрава = ПользовательИБ.Роли.Содержит(Метаданные.Роли.ПолныеПрава);
Для каждого КлючИЗначение Из РолиДляДобавления Цикл
//+yuraos
Если ВРег(СокрЛП(КлючИЗначение.Ключ)) = "SA" Тогда
// роль SA выставляем персонально каждому в конфигураторе
Продолжить;
КонецЕсли;
//+yuraos
ПользовательИБ.Роли.Добавить(Метаданные.Роли[КлючИЗначение.Ключ]);
КонецЦикла;
Для каждого КлючИЗначение Из РолиДляУдаления Цикл
//+yuraos
Если ВРег(СокрЛП(КлючИЗначение.Ключ)) = "SA" Тогда
// роль SA выставляем персонально каждому в конфигураторе
Продолжить;
КонецЕсли;
//+yuraos
ПользовательИБ.Роли.Удалить(Метаданные.Роли[КлючИЗначение.Ключ]);
КонецЦикла;
ЗаписатьПользователяПриОбновленииРолей(ПользовательСсылка, ПользовательИБ, БылиПолныеПрава, ПарольПользователяСервиса);
КонецЦикла;
КонецПроцедуры
И так, достаточна ли система безопасности, имеющаяся в 1С?
Чего только в платформе не придумали за последнее время.
Например под 8.3 для каждого минорного релиза
(отличающегося третьей цифрой) придуман свой режим совместимости.
А до такой простой вещи как встроенные роли безопасности,
давно имеющиеся в развитых многопользовательских системах,
как-то руки не доходят.
Также кроме системы разрешений, явно не хватает запрета доступа.
А может просто назвать профиль «Полные права», накидать туда ролей — стандартных и самописных(если надо), но не давать роль «ПолныеПрава». Тогда не надо будет дописывать никакой код в конфигурацию.
Если «сделать типовые «полные права» чуть менее полными, убрав доступ…» (пункт 4), то зачем 2 и 3? Просто поснимать нужные галки, раз уж «Полные права» и так станут не типовыми
(2) Synoecium, А если пользователь захочет изменять данные в закрытом периоде?
Таким руководителям обычно делаю права на просмотр всего-всего без права изменения. Обычно их это устраивает.
(5) kovaleks78, Вот, кстати, еще один прокол 1С. В типовых УПП, КА, БП (в других не знаю) нет роли «Полный просмотр» (например для аудиторов). Приходится делать самому
(3) ChiginAV, Есть же «Установка даты запрета изменения данных», где можно отдельным пользователям или группам пользователей установить дату запрета.
(6) ChiginAV, если все будет сразу готово, нам работы не будет! :))))
1С заботится о нас, чтобы армия программистов по всей россии с голоду не умерла. Государство тоже постоянно о нас заботится.
(7) Synoecium, да, но это не запрещает редактировать справочники.
(9) kovaleks78, А как справочники относятся к закрытым периодам? Идем в пункт (2) и ролями настраиваем.
Не понятно, почему «отобрать у них полные права назад бывает не реально», а «сделать типовые «полные права» чуть менее полными, убрав доступ к административным функциям и запуск внешних обработок» вполне возможно и подобные пользователи «проглатывают» это.
(10) Synoecium, да никак не относятся. Я и говорю, что это не поможет. Для такого руководителя проще всего создать роль, где почти на все доступ на чтение и просмотр. и выдавать ему такую роль.
(4) ChiginAV,
Речь идет не о широком ограничении доступа.
Раз пользователи отжали себе «полные права» и назад их не отдают — это бесмысленно.
(2) Synoecium,
эту стуацию по этой же причине трудно регулировать и профилями безопасности.
Просто иногда возникает необходимость выборочно закрыть доступ
к ряду опасных инструментов в базе
(типовых, а по большей частью — не типовых)
позволяющим допустим в массовом порядке удалять данные.
(1)
—
Отсутствие встроенных ролей безовасности,
кстати,
приводит к небольшому неудобсту при создании пустой конфигурации с нуля.
Пока в конфигурации не создашь роль «ПолныеПрава» (или ей аналогичную)
— ты не можешь создать в базе пользователя.
было бы проще если при этом были бы встроенные роли, доступные для выбора.
—
ну хотя примерно как в MS SQL
(5) kovaleks78,
предыстория этой статьи:
мне пришлось без особого удовольствия заняться доработкой базы,
где сидит блатная бухгалтерша.
Она не совсем понимает:
1. что перед тем как списать шины со склада
— туда сначала их надо как-то оприходовать.
2. что автомобильный прицеп или грузовик — вряд ли могут быть подразделением организации.
Зато она узнала откуда-то, что-такое групповая обработка документов
и творит ей чудеса (а виноват IT-отдел 🙂 )
—
Я решил добавить в базу ряд своих примочек для комфортной работы (не для кривых рук!)…
… вот и пришлось выдумать SuperAdmin-а, чтобы перекрыть ей к ним доступ.
(15) надо дописать логирование того, что делает бухгалтерша групповой обработкой, чтобы потом можно было тыкать ее носом туда. Иначе ит-отдел так и будет всегда виноват.
я для хитрых ограничений и проверок доступа использую подписки на события и например, РС или добавленную ТЧ в справочнике «Пользователи»
(16) kovaleks78,
1. Вообще-то 1С-8.х и так по умолчанию все пишет в журнал регистрации.
Это в 7.7 можно было «без палева»
обработкой что-нибудь грохнуть или перепровести.
2. Такого типа люди привыкли сами других носом всех тыкать
так-что IT-отдел по любому «Виновен !».
(17) Borisych,
и например, РС или добавленную ТЧ в справочнике «Пользователи»
можно пояснить ???
(0) В 1С никогда не было и наверное уже никогда не будет безопасности. Все РЛС и роли это забавные тормозистры, который предназначен только для одной цели: снять денег с клиента.
(19) например,
некоторым пользователям отрезаны некоторые счета хозрасчетного в БП 2.0 — для этого существует регистр сведений «недоступные для пользователя счета хозрасчетный» — с двумя измерениями — пользователь и счет;
на план счетов хозрасчетный наложен RLS — в котором пользователь может увидеть лишь те счета, записей по которым нет в регистре сведений по текущему пользователю, т.о. пользователь никаким образом — ни в оборотках, ни ещё где-либо не увидит (цель — 70 счет) обороты по 70-му счету и документы, в которых задействован 70-й счет.
В данной конкретной задачи также созданы дополнительные роли — «Бухгалтер с ограничением доступа к зарплатным документам» и «Доступ к зарплатным документам», которые решают поставленные задачи
(7)Synoecium, все бы хорошо, но типовой механизм «Установка даты запрета изменения данных» в нашем УПП 1.3 работает только для тех пользователей, которые в нем перечислены, а для всех остальных — не работает.
Прикольно, когда обнаруживается, что новый юзер, принятый на работу на прошлой неделе, начудил что-то в якобы давно и надежно закрытом периоде…
(22) rus128,
еще один повод, что бы тем или иным способом
выборочно блокировать потенциально опасные сервисы.
(21) >>на план счетов хозрасчетный наложен RLS
этого совершенно недостаточно для безопасности 🙁
Если у пользователя есть возможность формировать карточку счета, взаимодействующего с «запрещенным» счетом (например, 44, 71, 26, 20 взаимодействуют с 70 счетом), то он в карточке легко увидит все движения и аналитику — например, для 70 счета будет написано «Объект не найден», а вот субконто и суммы будут легко видны, т.е. легко увидеть зарплату других сотрудниеков.
в итоге никакой безопасности.
(22) rus128, а вы пробовали ввести дату запрета в ячейку напротив корня дерева пользователей, напротив «Общая дата». Насколько я помню, там система приоритетов: Если пользователь не ограничен по группе или отдельно, то действует общая дата запрета (приоритет 3), если по группе — приоритет 2, отдельно — приоритет 1. Получается работает ограничение с наименьшим по значению приоритетом.
(24) artbear, есть настройка в системе, которая убирает субконто у 70 счета. По крайней мере в УПП.
(25) Пробовали, но у нас получилось именно так, как я описал выше: пользователь, не указанный в списке, спокойно обошел и общую дату, и дату ограничения по организации (на 2-й закладке).
УПП для Украины 1.3.
Когда есть «права» на полные права.
В случае серьезного инцидента запускаем следующий механизм:
Картинно всех выводим из базы.
Восстанавливаем последнюю резервную копию. (У вас же есть резервная копия?)
Предлагаем вручную восстановить актуальность до текущего момента.
Это лучше в плане воспитания «правомочных». А то куда еще залезут в будущем…
(26) Synoecium, «настройка, которая убирает субконто по 70 счету»
Бухам это принесет огромную радость, 70 счет без расшифровки 🙁
Как правило, бухи активно работают именно с аналитикой по счетам
(29) artbear, Сдаюсь, система прав в 1с действительно отстой)
Но может мои комментарии кому-нибудь облегчат работу, когда он будет ковыряться с правами.
(6) аудиторам можно сливать копию, как вариант.