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С, налаштовувати резервування, права доступу, різні режими запуску, тестувати цілісність баз, забезпечувати роботу серверів і т.д.
І краще це відразу робити правильно.
Щоб потім не було "...! Ну що за ...! Твою ж ...! " - і інших виразів жалю :)
Кожен керівник беззастережно погодиться з тим, що кожен співробітник на підприємстві повинен мати доступ тільки до тієї інформації, яка лежить в його компетенції. Наприклад, комірнику на складі зовсім не обов'язково переглядати, які операції здійснює фінансовий директор або головний бухгалтер. Однак нерідко виникають досить тонкі ситуації, наприклад, коли програма 1С: Підприємство 8 використовується не для однієї, а для кількох підприємств. На кожному з них працюють свої співробітники, які повинні мати доступ тільки до дозволеної інформації, що відноситься до їх підприємству.
В такому випадку ідеальним помічником в забезпеченні необхідних прав доступу є технологія Record Level Security (RLS), що дозволяє надавати доступ до інформації на рівні запису.
Розглянемо приклад конкретної ситуації. До складу нашої компанії входять дві організації. Перша займається продажем програмного забезпечення, в друга - навчанням роботі з ним. Для обліку цих обох організацій ми використовуємо програмний продукт 1С: Комплексна автоматизація 8.
Наше завдання полягає в розмежуванні прав доступу до інформації співробітників двох організацій так, щоб співробітники з одними і тими ж правами могли бачити тільки те, що відноситься до організації, в якій вони працюють.
Перше, що спадає на думку при постановці даного завдання - настройка відборів на організації. Однак це рішення має два суттєвих недоліки:
- відбори доведеться налаштовувати у всіх формах програми;
- для більш чи менш кмітливого користувача абсолютно не важко буде їх відключити.
Найкращий спосіб - це розмежувати доступ користувачів на рівні записів. Як же це реалізувати?
Перше, що необхідно виконати - включити в програму можливість використання даного способу. Для цього необхідно:
У нашому випадку необхідно ввести обмеження доступу по організаціям, проте видно, що програма надає можливості набагато ширше. Наприклад, розмежувати доступ за довідниками і документами.
Аналогічний механізм реалізований і в інших прикладних рішеннях 1С:
- (Редакція 10.3)
- і 1С: Зарплата і управління персоналом 8 (редакція 2.5).
У цих програмах розмежування прав доступу здійснюється за допомогою довідника «Групи користувачів», який доступний з меню «Сервис», розділу «Налаштування доступу користувачів».
- Таким чином, в цих програмах нам необхідно всіх наших користувачів, які працюють в складі компанії, поділити на групи по організаціям.
- Потім натиснути кнопку «Налаштування доступу».
- У вікні натискаємо кнопку «Додати» і вводимо об'єкт доступу (в нашій ситуації це організація).
- Якщо нам необхідно дозволити співробітникам організації вносити дані в інформаційну базу даних, то необхідно поставити прапорець в стовпці «Запис».
Ці дії необхідно виконати для кожної організації. Після цього, кожен співробітник після входу в програму буде бачити тільки ті документи, які визначені його правами доступу за посадою і відносяться до його організації.
У програмі 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 заблоковано читання деяких записів. Щоб це повідомлення більше не з'являлося, потрібно в текст запиту ввести слово ДОЗВОЛЕНІ.
У раді приведена покрокова інструкція для настройки Record Level Sceurity (RLS) в Аксапта 3.0.
Де про це написано в Документації
Російська версія: Users Guide for Admin (Russian) _3.0.pdf (стор.126)
Англійська версія: User "s Guide for Administration (стор. 40, 101)
Вступ
Обмеження прав на рівні записів (Record Level Security - RLS) позволет обмежити доступ до записів різних груп користувачів. Наприклад, одна група менеджерів може бачити російських клієнтів, а інша - зарубіжних. Причому менеджери, які працюють з російськими клієнтами не повинні бачити зарубіжних клієнтів. Мало того, менеджери навіть бачити їх не повинні.
RLS в Аксапта працює спільно з системою настройки звичайних прав. Це означає, що для того, щоб обмежити доступ до того чи іншого поля таблиці, необхідно налаштувати звичайні права на ці таблицю. Завдання RLS - непомітно для користувача відфільтрувати записи.
Налаштування обмеження прав на рівні записів зводиться до визначення фільтрів на ті чи інші таблиці для різних груп користувачів. Якщо користувач входить в кілька груп, то фільтри об'єднуються за умовою АБО.
Мистецтво настройки прав доступу полягає в тому, щоб правильно визначити фільтри на правильні таблиці. Причому зробити це оптимальним чином, щоб не знизити продуктивність системи.
Налаштування
Перед тим, як будемо виконувати настройку обмеження прав доступу необхідно зробити попередні кроки:
Підготовча робота завершена. Зараз користувач Тест не має ніяких прав. Можна зайти в Аксапта під користувачем тест і переконається, що у нього не виходить відкрити навіть головне меню.
Можна приступати до налаштування RLS:
- Налаштуємо звичайні права для групи тстГруппа1.
- Натисніть на кнопку Запит;
Власне кажучи, все! RLS налаштований. Зараз користувач Тест отримав права на читання даних з модуля Розрахунки з клієнтами і право на створення і видалення замовлень. Крім того, на таблицю клієнтів накладено фільтр. Починаючи з цього моменту, користувачі, що належать групі тстГруппа1, зможуть побачити тільки інших клієнтів (клієнтів, для яких встановлена \u200b\u200bгрупа Інші).
перевіримо настройку
Зайдіть в Аксапта під користувачем Тест. Відкрийте список клієнтів (Головне меню \\ Розрахунки з клієнтами \\ Клієнти). Переконайтеся, що список клієнтів відображає тільки тих клієнтів, для яких встановлена \u200b\u200bгрупа з кодом ПРч.
Зверніть увагу, що в головному меню відкрилася не тільки закладка Розрахунки з клієнтами. Відкрилася також закладки Головна книга, Грошові кошти, CRM, Управління запасами, Основне. Справа в тому, що давши права на модуль клієнтів, ми торкнулися безліч таблиць з інших модулів. Так, звичайно, непотрібні закладки майже порожні. Але все одно, в реальному житті права треба давати набагато акуратніше.
Крім того, в реальному житті ніколи не з'являються закладки з незакупленних модулів. Наприклад, спробуйте відключити модуль CRM в налаштуванні конфігураційних ключів.
Спробуйте накласти фільтр "*" на групу (Встановіть мишку на колонку Група клієнтів, натисніть праву кнопку, виберіть пункт Знайти ..., введіть фільтр "*").
Спробуйте також накласти фільтр "! ПРч". Спробуйте накласти фільтри на інші поля. Переконайтеся, що фільтр по клієнтами дійсно працює правильно в усіх випадках.
Перевірте як працює RLS в звітах. Відкрийте звіт зі списком клієнтів (Головне меню \\ Розрахунки з клієнтами \\ Звіти \\ Базові дані \\ Клієнт). Спробуйте побудувати цей же звіт з фільтрами. Переконайтеся, що фільтр по клієнтам працює правильно і в звітах.
Зверніть увагу, що програмісту не потрібно нічого змінювати або переробляти, щоб в його звіті заробив RLS, якщо він в формах або для побудови звітів використовував ядро \u200b\u200bі не переважають механізм отримання даних. Якщо ж програміст вручну кодіровл запити, то йому необхідно додати виклик методу recordLevelSecurity (true) для тих таблиць, де потрібно увімкнути режим доступу на записи. Див. Докладніше керівництво розробника за ключовим словом Record Level Security.
Відкрийте замовлення. Оп! А замовлення показуються по всіх клієнтах. Чому? А тому, що в замовленнях містяться коди клієнтів, а не самі клієнти. Спробуйте перейти до основної таблиці з клієнтами - ви не зможете побачити параметри прихованих клієнтів.
Взагалі кажучи, в реальному житті для настройки обмеження на рівні прав доступу недостатньо налаштувати одну таблицю. Як правило взаємопов'язані обмеження необхідно накладати на кілька пов'язаних таблиць.
Права доступу на рівні записів діють не тільки в формах і звітах, а й у випадних списках. Відкрийте замовлення і натисніть на кнопку списку у клієнта. Так, все вірно. Користувач Тест бачить тільки інших клієнтів.
RLS для декількох груп
Тепер розглянемо ситуацію, коли необхідно налаштувати декілька різних груп з різними правами і з різними обмеженнями прав.
Припустимо, що одна група менеджерів має доступ до Іншим клієнтам (група клієнтів \u003d ПРч), а інша група менеджерів має доступ до Звичайним клієнтам (група клієнтів \u003d Тіу). Першу групу ми вже набудували. Залишається налаштувати другу групу.
Повторіть кроки 8-10. Тільки встановіть групі тстГруппа2 повні права на модуль Розрахунки з клієнтами і і в якості критерію вкажіть "Тіу" в налаштуванні RLS для групи тстГруппа2.
Для перевірки зайдіть в Аксапта під користувачем Тест і переконайтеся, що форми і звіти працюють коректно, переконайтеся, що ви отримали повні права на клієнтів і можете редагувати параметри клієнтів.
Що станеться, якщо у клієнта змінити групу? У формі клієнт буде видно до тих пір, поки він не піде за межі екранної форми. Як тільки Аксапта вважає заново дані з сервера, спрацює RLS і менеджер більше не побачить "чужого" клієнта.
Цей приклад знову показує, що права треба налаштовувати комплексно. У даній ситуації можна або заборонити менеджерам редагування поля група клієнтів, або налаштувати обмеження на рівні записів (RLS) і на таблицю з групами.
Для того, щоб деяким користувачам дозволити доступ до всього списку клієнтів, необхідно третьої групи дати права на таблицю клієнтів, але не налаштовувати RLS. Axapta дивиться на звичайні права доступу. І, якщо право доступу є, то дивиться в налаштування RLS. Якщо для даної групи і даної таблиці налаштувань RLS немає, то Аксапта показує всі записи з таблиці.
Зверніть увагу, що група тстГруппа3 не впливала на поведінку RLS до тих пір поки вона не мала прав на таблицю клієнтів. Як тільки в цій групі з'явилося право на клієнтів, так відразу ця група стала брати участь в RLS. Щоб перевірити цю тезу, приберіть права на модуль Розрахунки з клієнтами в групі тстГруппа2 і перевірте RLS для клієнта Тест. Ви побачите тільки інших клієнтів.
