Обмеження доступу до даних неактивне 1с. RLS – гнучке та тонке налаштування обмежень доступу до даних. Ціни компанії
У системі 1С Підприємство 8 сьогодні ми продовжимо вивчення механізму прав і заглибимося далі — в механізм RLS (обмеження прав на рівні записів).
Нижче ми розглянемо переваги та недоліки даного методу та розглянемо налаштування RLS у 1С Підприємстві 8.3 на прикладі.
1С RLS (Record Level Security) або обмеження прав на рівні запису— це права користувачів в системі 1С, яка дозволяє розділити права для користувачів у розрізі даних, що динамічно змінюються.
Найпоширеніший вид налаштування 1C RLS – обмеження видимості користувача в розрізі організацій або клієнтів (користувач бачить лише «свої» дані).
Основна перевага – наявність механізму взагалі, механізм досить складний та цікавий. Дозволяє дуже тонко розмежувати права користувачів - користувачі можуть навіть не здогадуватися про існування інших даних.
Недоліки 1С 8 RLS
Серед недоліків можна назвати помітне падіння продуктивності системи. Це викликано тим, що платформа під час побудови запиту у базі даних ускладнює будь-який запит розробника додатковими умовами.
Також серед недоліків — складність налаштування цього функціоналу та складність налагодження. 1C випустило дуже мало матеріалів з налаштування та роботи цього функціоналу. Досить важко знайти спеціаліста, який би грамотно налаштував механізм.
Настроювання обмеження прав на рівні записів 1С RLS
Обмеження прав на рівні запису (RLS) застосовується для обмеження таких типів прав:
- Читання
- Додавання
- Зміна
- Вилучення
Отримайте 267 відеоуроків з 1С безкоштовно:
Зовнішнє налаштування RLS (прав на рівні записів) схоже на складання простого . Приклад шаблону для обмеження доступу видимості документів клієнта з шапки документа:
##Якщо &ВикористовуватиОбмеженняПравДоступуНаРівніЗаписів##Тоді
ПоточнаТаблиця З #ПоточнаТаблиця ЯК ПоточнаТаблиця
ЛІВОЕ З'ЄДНАННЯ (ВИБРАТИ РІЗНІ
СкладГрупи.Посилання ЯК ГрупаКористувачів
З
Довідник.ГрупиКористувачів.КористувачіГрупи ЯК СкладГрупи
ДЕ
СкладГрупи.Користувач = &ПоточнийКористувач) ЯК ГрупиКористувачів
ПЗ (&ВикористовуватиОбмеженняПравДоступуНаРівніЗаписів)
ДЕ (&ВикористовуватиОбмеженняПравДоступуНаРівніЗаписів = БРЕХНЯ
АБО (НЕ 1 В
(ВИБРАТИ ПЕРШІ 1
1 ЯК ПолеВідбору
З
РеєстрВідомостей.ПризначенняВидівОб'єктівДоступу ЯК ПризначенняВидівОб'єктівДоступу
ДЕ
ПризначенняВідівОб'єктівДоступу.ГрупаКористувачів = ГрупиКористувачів.ГрупаКористувачів
І ВИБІР
КОЛИ ПризначенняВидівОб'єктівДоступу.ВиглядОб'єктаДоступу = ЗНАЧЕННЯ(Перерахування.ВидиОб'єктівДоступу.Контрагенти)
І ПоточнаТаблиця.#Параметр(1) ПОСИЛАННЯ Довідник.Контрагенти
І НЕ ПоточнаТаблиця.#Параметр(1) = ЗНАЧЕННЯ(Довідник.Контрагенти.ПустаПосилання)
ТОДІ ВИБІР
КОЛИ 1 В
(ВИБРАТИ ПЕРШІ 1
1
З
Довідник.Контрагенти ЯК Контрагенти ВНУТРІШНЯ З'ЄДНАННЯ РеєстрВідомостей.НалаштуванняПравДоступуКористувачів ЯК НалаштуванняПравДоступуКористувачів
ПЗ
НалаштуванняПравДоступуКористувачів.Об'єктДоступу = Контрагенти.ГрупаДоступуККонтрагенту
І НалаштуванняПравДоступуКористувачів.Вигляд Об'єктаДоступу = ЗНАЧЕННЯ(Перерахування.ВидиОб'єктівДоступу.Контрагенти)
І (НалаштуванняПравДоступуКористувачів.Користувач = ПризначенняВидівОб'єктівДоступу.ГрупаКористувачів
АБО НалаштуванняПравДоступуКористувачів.Користувач = ЗНАЧЕННЯ(Довідник.ГрупиКористувачів.ВсіКористувачі))
І НалаштуванняПравДоступуКористувачів.Запис = ІСТИНА
ДЕ
Контрагенти.Посилання = ПоточнаТаблиця.#Параметр(1))
ТОДІ ІСТИНА
Інакше брехня
КІНЕЦЬ
Інакше ІСТИНА
КІНЕЦЬ = БРЕХНЯ))
І НЕ Групи Користувачів. Група Користувачів Є NULL)
##КінецьЯкщо
По суті, цей запит щоразу додається за запитом до таблиці «#Поточна Таблиця». З чого можна уявити, яке додаткове навантаження несе у собі механізм обмеження лише на рівні записи.
Як Ви бачите, у запиті є спеціальні параметри, наприклад » &Використовувати ОбмеженняПравДоступуНаРівнеЗаписів». Ці параметри в РЛС підбираються з метаданих об'єктів — ««. Як правило, вони задаються під час старту сесії користувача.
Конструктор обмеження доступу до даних
Для зручності розробника в 1С 8.3 є спеціальна утиліта для допомоги в налаштуваннях РЛС — Конструктор обмеження доступу до даних. Він викликається з поля "Обмеження доступу". Виглядає наступним чином:
Часто виникає потреба у частковому обмеження доступу до даних. Наприклад, коли користувач повинен бачити документи лише своєї організації. У разі в 1С використовується механізм обмеження доступу лише на рівні записів (так званий, RLS – Record Level Securiy).
Наприклад припустимо, що маємо таке завдання. На підприємстві ведеться багатофірмовий облік і кожен контрагент та користувач бази даних належить до певної організації. Необхідно забезпечити доступ до довідника “Контрагенти” таким чином, щоб кожен користувач міг переглядати, редагувати та додавати контрагентів тільки своїй організації.
Для вирішення завдання будемо використовувати платформу "1С:Підприємство 8.2". Створимо нову конфігурацію у властивостях якої в якості основного режиму запуску буде вибрано варіант "Керована програма".
Далі створимо довідник “Організації” та ще два довідники – “Контрагенти” та “Користувачі” з реквізитом “Організація”. Крім довідників, нам знадобляться два параметри сеансу – “Організація” та “Користувач” (відповідних типів). Значення цих параметрів встановлюються під час запуску сеансу роботи з конфігурацією та зберігаються до його завершення. Саме значення цих параметрів ми будемо використовувати при додаванні умов обмеження доступу лише на рівні записів.
Встановлення параметрів сеансу виконується у спеціальному модулі – “Модуль сеансу”
У цьому модулі опишемо зумовлену процедуру "УстановкаПараметрів Сеансу" в якій викличемо функцію заздалегідь підготовленого загального модуля "Повні Права". Це необхідно через особливості роботи бази даних в режимі керованого додатка, коли частина програмного коду може виконуватися тільки на стороні сервера (докладно на поясненні цих принципів у цій статті я не буду зупинятися).
Код 1C v 8.х Процедура УстановкаПараметрівСеансу(ПотрібніПараметри)
ПовніПрава.ВстановитиПараметриСеанса();
КінецьПроцедури
У властивостях модуля "ПовніПрава" необхідно відзначити прапорці "Сервер", "Виклик сервера" та "Привілейований" (останнє означає, що процедури та функції цього модуля будуть виконуватися без контролю прав доступу). Текст модуля виглядатиме так:
Код 1C v 8.х Функція ВизначитиПоточногоКористувача()
ТекКористувач = Довідники.Користувачі.ЗнайтиПо Найменуванню(Ім'яКористувача(),Істина);
Повернення ТекКористувач;
КінецьФункції
Процедура ВстановитиПараметриСеансу() Експорт
ПоточнийКористувач = ВизначитиПоточногоКористувача();
ПоточнаОрганізація = Довідники.Організації.ПустаПосилання();
Якщо значенняЗаповнено(ПоточнийКористувач) Тоді
Поточна Організація = ПоточнийКористувач.Організація;
КінецьЯкщо;
ПараметриСеанса.Користувач = ПоточнийКористувач;
Параметри Сеансу. Організація = Поточна Організація;
КінецьПроцедури
Функція Параметр Сеансу Встановлено (Ім'яПараметра) Експорт
Повернення ЗначенняЗаповнене (Параметри Сеансу [Ім'яПараметра]);
КінецьФункції
Функція РольДоступнаКористувачу(Ім'яРолі) Експорт
Повернення РольДоступна(Ім'яРолі);
КінецьФункції
У модулі керованого додатка будемо перевіряти наявність користувача конфігурації в довіднику “Користувачі” (для простоти будемо шукати його за найменуванням) і завершувати роботу системи, якщо він не знайдений. Це необхідно для забезпечення заповнення параметрів сеансу.
Код 1C v 8.х Процедура ПередПочаткомРоботиСистеми(Відмова)
// всіх крім адміністратора перевірятимемо на наявність у довіднику "Користувачі"
Якщо Не ПовніПрава.РольДоступнаКористувачеві("ПовніПрава") Тоді
Якщо НЕ ПовніПрава.Параметр СеансуВстановлений("Користувач") Тоді
Попередження("Користувач """ + Ім'яКористувача() + """ не знайдено в довіднику!");
Відмова = Істина;
Повернення;
КінецьЯкщо;
КінецьЯкщо;
КінецьПроцедури
Тепер можемо перейти безпосередньо до опису обмежень доступу. Для цього створимо роль "Користувач" і перейдемо на закладку "Шаблони обмежень", де додамо новий шаблон "КонтрагентиЧитання Зміна" з наступним текстом шаблону: ДЕ Організація =Організація #Параметр(1)
Текст шаблону обмежень є розширенням мови запитів. На відміну від звичайного запиту, текст обмеження повинен обов'язково містити умову “ДЕ”. Як значення параметрів запиту (у нашому випадку це “&Організація”) використовуються значення однойменних параметрів сеансу. Конструкція виду #Параметр(1) означає, що це місце система підставить текст, переданий як перший параметр у місці використання шаблона. За допомогою наведеного шаблону буде перевірено кожний запис таблиці (у нашому випадку це буде довідник “Контрагени”). Для записів, значення реквізиту “Організація” яких збігаються із заданим у відповідному параметрі сеансу, умова описана у шаблоні буде виконуватися. Таким чином, ці записи будуть доступні для читання, зміни або додавання (залежно від того, для якого з цих прав застосовується шаблон). Продемонструю вищевикладене на прикладі.
Перейдемо на закладку “Права” ролі “Користувач” та відкриємо список прав довідника “Контрагенти”. Будемо використовувати шаблон обмежень “КонтрагентиЧитанняЗміна” для прав “Читання”, “Зміна” та “Додавання”.
Для права "Читання" будемо використовувати шаблон з параметром "АБО Це Група". У цьому користувачам цієї ролі буде дозволено читання як елементів довідника “Контрагенти” своєї організації, а й всіх груп цього довідника.
#КонтрагентиЧитанняЗміна("АБО ЦеГрупа")
Оскільки при додаванні нових елементів довідника системою виконується неявне читання зумовлених реквізитів (це потрібно, наприклад, для нумерації), необхідно забезпечити безперешкодне читання цих полів. Для цього додамо додатковий рядок з порожнім текстом обмеження до таблиці обмеження доступу до даних та перерахуємо поля, для яких діє дане правило – Посилання, Версія даних, Батько, Код.
Таким чином, завдання обмеження доступу на рівні записів вирішено. Користувачі з чинними обмеженнями отримають доступ до перегляду та редагування даних тільки своєї організації.
У програмі 1С є вбудована система прав доступу, яка знаходиться в Конфігуратор - Загальні - Ролі.
Чим характеризується дана система та у чому її основне призначення? Вона дозволяє описувати набори прав, які відповідають посадам користувачів або їх діяльності. Ця система прав доступу має статичний характер, що означає, як виставив адміністратор права доступу до 1С, і є. На додаток до статичної, діє друга система прав доступу — динамічна (RLS). У цій системі права доступу обчислюються динамічним способом, залежно від заданих параметрів у процесі роботи.
Ролі у 1С
До найпоширеніших налаштувань безпеки у різних програмах є так званий набір дозволів на читання/запис для різних груп користувачів і надалі: включення чи виключення конкретного користувача з груп. Така система, наприклад, використовується в операційній системі Windows AD (Active Directory). Система безпеки, що застосовується у програмному забезпеченні 1С, отримала назву – ролі. Що це таке? Ролі в 1С є об'єктом, який розташований у конфігурації в галузі: Загальні — Ролі. Ці ролі 1С є групи, котрим і призначаються права. Надалі кожен користувач може включатися та виключатися з цієї групи.
Клацнувши двічі мишею на назві ролі, Ви відкриєте редактор прав для участі. Зліва розташований список об'єктів, позначте будь-який з них і праворуч Вам відкриються варіанти можливих прав доступу:
- Читання: отримання записів або їх часткових фрагментів з таблиці бази даних;
- Додавання: нових записів при збереженні вже існуючих;
- Зміна: внесення змін до існуючих записів;
— видалення: деякі записи зберігаються без зміни інших.
Зазначимо, що всі права доступу можна розділити на дві основні групи — це «просто» право і таке право з додаванням характеристики «інтерактивне». Що тут мається на увазі? А річ у наступному.
У випадку, коли користувач відкриває якусь форму, наприклад обробку, і при цьому клацає на ній мишею, то програма вбудованою мовою 1С починає робити конкретні дії, видалення документів, наприклад. За дозвіл таких дій, що виконуються програмою, відповідають «просто» права 1С.
У тому випадку, коли користувач відкриває журнал і починає щось самостійно вводити з клавіатури (нові документи, наприклад), то за дозвіл таких дій відповідають «інтерактивні» права 1С. Кожному користувачеві може бути доступно відразу кілька ролей, тоді складається дозвіл.
RLS у 1С
Ви можете включити доступ до довідника (або документа) або вимкнути його. Не можна при цьому "включити трошки". Для цієї мети існує певне розширення системи ролей 1С, яке отримало назву - RLS. Це динамічна система прав доступу, яка вносить часткові обмеження в доступ. Наприклад, увазі користувача стають доступні лише документи певної організації та складу, інші він бачить.
Слід мати на увазі той факт, що систему RLS потрібно застосовувати дуже акуратно, так як у її заплутаній схемі досить непросто розібратися, у різних користувачів при цьому можуть виникати питання, коли вони, наприклад, звіряють один і той же звіт, який сформований з-під різних користувачів. Розглянемо такий приклад. Ви вибираєте певний довідник (організації, наприклад) та конкретне право (читання, наприклад), тобто Ви дозволяєте читання для ролі 1С. При цьому в дистанційній панелі Обмеження доступу до даних Вами встановлюється текст запиту, згідно з яким встановлюється Брехня або Істина, залежно від налаштувань. Зазвичай налаштування зберігаються у спеціальному регістрі відомостей.
Цей запит буде виконуватися динамічно (при спробі організувати читання), для всіх записів довідника. Це працює так: ті записи, для яких запит безпеки надав - Істина, користувач побачить, а інші - ні. Права 1С із встановленими обмеженнями, підсвічені сірим кольором.
Операція копіювання однакових налаштувань RLS здійснюється за допомогою шаблонів. Для початку Ви створюєте шаблон, назвавши його, наприклад, Мой Шаблон, у ньому Ви відображаєте запит безпеки. Потім у налаштуваннях прав доступу вказуєте ім'я цього шаблону так: «#Мій Шаблон».
Коли користувач працює в режимі 1С Підприємство, при підключенні до роботи RLS може з'явитися повідомлення про помилку виду: «Недостатньо прав» (на читання довідника ХХХ, наприклад). Це говорить про те, що RLS заблоковано читання деяких записів. Щоб це повідомлення більше не з'являлося, потрібно ввести текст Дозволити в текст запиту.
1С має вбудовану систему прав доступу (ця система називається – ролі 1С). Ця система є статичною – як адміністратор поставив права 1С, і буде.
Додатково діє динамічна система прав доступу (називається – RLS 1С). У ній права 1С динамічно обчислюються на момент роботи користувача виходячи з заданих параметрів.
Однією з найпоширеніших налаштувань безпеки в різних програмах є набір дозволів на читання/запис для груп користувачів і далі – включення або виключення користувача з груп. Наприклад, подібна система використовується у Windows AD (Active Directory).
Така система безпеки в 1С називається Ролі 1С. Ролі 1С - це , який знаходиться в конфігурації в гілці Загальні / Ролі. Ролі 1С виступають як групи, для яких призначаються права 1С. Далі користувач включається або виключається із цієї групи.
Натиснувши двічі назву ролі 1С — Вам відкриється редактор прав для ролі 1С. Зліва – список об'єктів 1С. Виділіть будь-який і праворуч відобразяться варіанти прав доступу (як мінімум: читання, додавання, зміна, видалення).
Для верхньої гілки (назва поточної конфігурації) встановлюються адміністративні права 1С та доступ на запуск різних варіантів.
Всі права 1С поділені на дві групи - "просто" право і таке ж право з додаванням "інтерактивне". Що це означає?
Коли користувач відкриває будь-яку форму (наприклад, обробку) і натискає на ній кнопку – то програма вбудованою мовою 1С виконує певні дії, наприклад, видалення документів. За дозвіл цих дій (виконуваних програмно) відповідають «просто» права 1С.
Коли користувач відкриває журнал і починає щось робити з клавіатури самостійно (наприклад, вводити нові документи) – це «інтерактивні» права 1С.
Користувачеві може бути доступно кілька ролей, тоді дозволи складаються.
Розріз можливостей встановлення прав доступу з допомогою ролей – об'єкт 1С. Тобто Ви можете або увімкнути доступ до довідника або вимкнути. Включити трохи не можна.
І тому існує розширення системи ролей 1С під назвою 1С RLS. Це динамічна система прав доступу, яка дозволяє частково обмежити доступ. Наприклад, користувач бачить лише документи щодо певного складу та організації та не бачить інші.
Обережно! При використанні заплутаної схеми RLS 1С у різних користувачів можуть бути питання, коли вони спробують звірити той самий звіт, сформований з-під різних користувачів.
Ви берете певний довідник (наприклад, організації) та певне право (наприклад, читання). Ви дозволяєте читання для участі 1С. На панелі Обмеження доступу до даних Ви встановлюєте текст запиту, який повертає ІСТИНА або БРЕХНЯ залежно від налаштувань. Настройки зазвичай зберігаються в регістрі відомостей (наприклад, регістр відомостей конфігурації Бухгалтерія НалаштуванняПравДоступуКористувачів).
Цей запит виконується динамічно (при спробі реалізувати читання) для кожного запису довідника. Таким чином, для тих записів, для яких запит безпеки повернув ІСТИНА – користувач побачить, а решта – ні.
Права 1С, куди встановлені обмеження RLS 1С – підсвічені сірим.
Копіювання тих самих налаштувань RLS 1С робиться за допомогою шаблонів. Ви робите шаблон, називаєте його (наприклад) Мій Шаблон, у ньому вказуєте запит безпеки. Далі, в налаштуваннях права доступу 1С вказуєте ім'я шаблону так: «#МойШаблон».
Під час роботи користувача в режимі 1С Підприємство, при роботі RLS 1С, може з'являтися повідомлення про помилку «Недостатньо прав» (наприклад, на читання довідника Ххх).
Це означає, що RLS 1С заблокувала читання кількох записів.
Для того, щоб такого повідомлення не з'являлося, необхідно в тексті запиту вбудованою мовою 1С використовувати слово ДОЗВОЛЕНІ ().
Наприклад:
Класичне завдання: відкрити користувачеві доступ до будь-якого об'єкта, але не до всіх елементів/документів, а лише до деяких.
Наприклад, щоб менеджер бачив звіти лише за своїми клієнтами.
Або це може бути обмеження "все, крім деяких".
Або обмеження не на довідники/документи, а на дані регістрів…
Наприклад, щоб користувачі жодним звітом не могли витягнути дані щодо виплат партнерам.
По суті - це тонка і дуже гнучка настройка "що можна бачити цього користувача, а про що йому і не потрібно здогадуватися".
Чому саме RLS?
На більшості впроваджень потрібно для різних користувачів встановити рівні доступу до інформації в базі.
У змінах за можливі права доступу до даних відповідають спеціальні об'єкти метаданих – ролі. Кожному юзеру інформаційної бази призначається одна або кілька ролей. Вони визначають, чи можливі операції з конкретними об'єктами метаданих (читання, запис, проведення тощо).
Але це не все.
Часто буває необхідно не просто відкрити/заборонити доступ до певного об'єкта, а обмежити доступ до частини даних у ньому.
Тільки за допомогою ролей вирішити таке завдання не можна– для цього реалізовано механізм обмеження доступу на рівні записів (RLS).
Обмеження є умовами, у виконанні яких дію над даними (читання, запис тощо.) буде дозволено.
– так можна обмежити доступ не до об'єкта загалом, а лише частини його даних.
Про RLS – докладніше: 8 відео та PDF
Оскільки це поширене завдання адміністрування 1С – пропонуємо подивитись більш детальні матеріали:
Обмеження доступу до даних за допомогою ролей
У цьому відео розповідається, як обмежується доступ до даних за допомогою ролей. Уточнюється, що ролі обмежують доступом до виду об'єктів інформаційної бази (окремий довідник, але з конкретні елементи довідника).
Обмеження доступу на рівні записів (RLS)
У цьому відео розповідається про механізм обмежень доступу на рівні записів (RLS), коли можна налаштувати доступ не до всього довідника в цілому, а до окремих його елементів, залежно від даних, що зберігаються в інформаційній базі. Подібні обмеження прописуються у ролях.
Реалізація обмеження доступу на рівні записів для довідника Контрагенти
У цьому відео розповідається, як у демонстраційній конфігурації «Керована програма» налаштувати доступ менеджерів лише до власних контрагентів, закріплених за ними.
Принцип роботи обмежень доступу лише на рівні записів на низькому рівні
У цьому відео розповідається, як платформа трансформує запити, які передаються для виконання на сервер СУБД, за наявності обмежень доступу на рівні записів.
Спільне застосування кількох обмежень доступу на рівні записів
Користувачеві інформаційної бази може бути призначено кілька ролей. При цьому в кожній ролі можуть бути обмеження доступу на рівні записів. У цьому відео розповідається, як поводиться система при накладенні обмежень.
У цьому відео описується перший спосіб накладання обмежень на рівні записів – метод ВСІ. При цьому, якщо у вибірку потрапляють записи, до яких доступ обмежено, буде виведено повідомлення про помилку.
Накладення обмежень методом ДОЗВОЛЕНІ
У цьому відео описується перший спосіб накладення обмежень на рівні записів – метод ДОЗВОЛЕНІ. При цьому у вибірку потраплять лише ті записи, до яких користувач має права доступу.
Ось кілька тем із курсу:
- Встановлення та оновлення платформи «1С:Підприємство 8» – ручна та автоматична, під Windows та Linux
- Автоматичний запускдля виконання регламентних операцій
- Оновлення конфігурацій з режиму користувача
- Оновлення нетипових конфігурацій. Як уникнути проблем при оновленнізмінених типових конфігурацій
- Створення власних cfu-файлів постачання
- Інструменти БСП: зовнішні форми, обробка заповнення документів і т.п.
- Використання безкоштовної СУБД PostgreSQL
- Встановлення та запуск кластера серверів 1С:Підприємство 8
- Утиліта адмініструваннядля налаштування кластера та робочих серверів
- Налаштування RLSна прикладі УПП 1.3 та ERP 2
- Що робити, якщо дані в ІБ пошкоджені
- Налаштування обмінів данимиміж конфігураціями
- Організація групової розробки
- Налаштування та використання апаратних ключів захисту
- Програмні ліцензії 1С: встановлення та прив'язка до зовнішнього обладнання
Вам у будь-якому разі колись доведеться розгортати 1С, налаштовувати резервування, права доступу, різні режими запуску, тестувати цілісність баз, забезпечувати роботу серверів тощо.
І краще це одразу робити правильно.
Щоб потім не було “…! Ну що за…! Твою ж …!” – та інших виразів жалю:)
