Ограничаване на достъпа до правата на директория 1c. Ограничаване на достъпа на ниво RLS запис. Действия за ограничаване на достъпа

Програмата 1C има вградена система за права за достъп, която се намира в Конфигуратор - Общи - Роли.

Как се характеризира тази система и каква е нейната основна цел? Позволява ви да опишете набори от права, които съответстват на потребителски позиции или видове дейности. Тази система за права за достъп е статична по природа, което означава, че тъй като администраторът е задал правата за достъп на 1C, това е така. В допълнение към статичната има втора система за права на достъп - динамична (RLS). В тази система правата за достъп се изчисляват динамично, в зависимост от зададените параметри, по време на работа.

Роли в 1C

Най-често срещаните настройки за сигурност в различните програми са така нареченият набор от разрешения за четене/запис за различни потребителски групи и, в бъдеще, включване или изключване на конкретен потребител от групи. Такава система например се използва в операционната система Windows AD (Active Directory). Системата за сигурност, използвана в софтуера 1C, се нарича роли. Какво е? Ролите в 1C са обект, който се намира в конфигурацията в клона: Общи - Роли. Тези 1C роли са групи, за които са присвоени права. В бъдеще всеки потребител може да бъде включен или изключен от тази група.

Като щракнете двукратно върху името на ролята, ще отворите редактора на правата за ролята. Вляво има списък с обекти, маркирайте някой от тях и вдясно ще видите опции за възможни права за достъп:

— четене: получаване на записи или техни частични фрагменти от таблица на база данни;
— добавяне на: нови записи при запазване на съществуващи;
— модификация: извършване на промени в съществуващи записи;
— изтриване: някои записи, оставяне на останалите непроменени.

Обърнете внимание, че всички права за достъп могат да бъдат разделени на две основни групи - това е „просто“ право и това е точно право с добавяне на „интерактивна“ характеристика. Какво означава това? И смисълът е следният.

В случай, че потребителят отвори някаква форма, например обработка, и в същото време щракне върху нея с мишката, програмата на вградения език 1C започва да извършва конкретни действия, например изтриване на документи. „Просто“ правата на 1C са отговорни за разрешаването на такива действия, извършвани от програмата.

В случай, че потребителят отвори дневник и започне самостоятелно да въвежда нещо от клавиатурата (например нови документи), тогава „интерактивните“ права на 1C са отговорни за разрешаването на такива действия. Всеки потребител може да има достъп до няколко роли наведнъж, след което разрешението се сумира.

RLS в 1C

Можете да разрешите достъпа до директорията (или документа) или да го забраните. Не можете да го „включите малко“. За тази цел има известно разширение на ролевата система 1C, което се нарича RLS. Това е динамична система за права на достъп, която въвежда частични ограничения на достъпа. Например само документи на определена организация и склад стават достъпни за потребителя и той не вижда останалите.

Трябва да се има предвид, че системата RLS трябва да се използва много внимателно, тъй като нейната сложна схема е доста трудна за разбиране; различните потребители могат да имат въпроси, когато например сравняват един и същ отчет, който се генерира от различни потребители. Нека разгледаме този пример. Избирате конкретна директория (организации, например) и конкретно право (четене, например), тоест разрешавате четене за ролята на 1C. В този случай в отдалечения панел Data Access Restrictions задавате текста на заявката, според който тя се задава на False или True, в зависимост от настройките. Обикновено настройките се записват в специален информационен регистър.

Тази заявка ще бъде изпълнена динамично (при опит за организиране на четене) за всички записи в директорията. Работи по следния начин: тези записи, за които е зададена заявката за сигурност - Вярно, потребителят ще види, но други не. Правата на 1C с установени ограничения са маркирани в сиво.

Операцията по копиране на идентични RLS настройки се извършва с помощта на шаблони. Като начало създавате шаблон, като го наричате например MyTemplate, в който отразявате заявката за сигурност. След това в настройките за права за достъп посочете името на този шаблон по следния начин: „#MyTemplate“.

Когато потребител работи в режим 1C Enterprise, когато се свързва с RLS, може да се появи съобщение за грешка като: „Недостатъчни права“ (например за четене на директорията XXX). Това показва, че RLS системата е блокирана от четене на някои записи. За да предотвратите появата на това съобщение отново, трябва да въведете думата РАЗРЕШЕНО в текста на заявката.

Осмата версия на платформата 1C:Enterprise (днес 8.3) пренесе много промени по отношение на „седемте“, сред които механизмът за ограничаване на правата за достъп на ниво запис беше особено забележим. Въпреки факта, че теоретично е възможно да се направи без него, като се използват само роли, RLS ви позволява да постигнете по-фини настройки за достъп. Но за да работите правилно с този механизъм, трябва ясно да разберете неговата същност и да имате достатъчно опит в разработката в 1C.

Какво е RLS?

Същността на тази функционалност е способността на разработчика да попречи на конкретен потребител или група потребители да имат достъп до таблици или полета от таблици на база данни. Обикновено ограниченията се използват, за да се попречи на потребителите на 1C да виждат и редактират поверителна, секретна информация, например ограничаване на служителите на компания, включени в група, да преглеждат документи само за тяхната организация. Също така, механизмът за ограничаване на правата за достъп на ниво запис може да се използва за премахване на ненужна информация от интерфейса.

За да можете да пишете заявки за RLS ограничения, трябва да създадете роля или да вземете съществуваща. Настройката на RLS в 1C 8.3 може да се използва за следните потребителски действия:

Добавяне;
четене;
Изтрий;
промяна.

В допълнение към най-широките възможности за персонализиране на достъпа, RLS има и недостатъци:

Изисквания за квалификацията на разработчика, тъй като заявката трябва да бъде написана на вграден език, като се вземат предвид правилата на синтаксиса;
Липса на възможност за бързо отстраняване на грешки в условията;
Ограничени възможности за описание на логиката: твърде сложните условия все пак ще трябва да бъдат записани в модули от документи и справочници;
Във версията клиент-сървър на базата данни е възможно неявно нарастване на таблиците, включени в заявката. Освен това е много трудно да се проследи този процес;
Изисквания за ресурси. RLS ограниченията консумират много енергия на клиентската машина и сървъра;
Малко документация е свободно достъпна.

Друг проблем, който може да възникне след настройката на 1C RLS, могат да бъдат отчетите. Факт е, че разработчиците предвиждат възможни RLS ограничения и създават отчети по такъв начин, че да показват само разрешени данни. Ако потребителите имат различни конфигурирани RLS ограничения, тогава данните в отчета за едни и същи параметри може да са различни. Това може да повдигне въпроси, така че трябва да вземете предвид тези ситуации, когато проектирате отчети или пишете заявки в RLS.

Създайте RLS ограничение

За да добавите RLS ограничение, трябва да намерите желаната роля и да я отворите с двукратно щракване.

Прозорецът, който се отваря, съдържа 2 раздела: „Права“ и „Шаблони за ограничаване“. За да наложите определени ограничения върху конкретно действие, трябва да го изберете и да кликнете върху зеления плюс в долната дясна част. Ще се появи ред, в който можем да зададем ограничения на 1C RLS на езика, вграден в 1C.

Ако знаете синтаксиса на 1C (като опакото на ръката си), тогава можете да пишете директно в полето „Ограничение на достъпа“. Разработчиците на 1C предоставиха възможност за отваряне на конструктор на заявки, който ще помогне и ще предложи какви ограничения могат да бъдат направени. За да го отворите, трябва да кликнете върху бутона с три точки (Select) или F4 и ще се появи прозорец с бутона „Query Builder…“.

В прозореца, който се показва, можете да конфигурирате ограничения не само за тази директория, но и за други системни обекти. За да направите това, трябва да ги добавите в раздела „Таблици и полета“. Регистрираме ограничения в полетата на директорията „Номенклатура“ и щракнете върху „OK“. Внимавайте за имената на променливите: RLS параметрите се задават в началото на потребителската сесия и трябва да се съдържат в обекта с метаданни.

В раздела „Шаблони на ограничения“ посочвате заявки, които са необходими при копиране на същите RLS настройки в 1C 8.3. След като добавите вашия шаблон, можете да използвате името му в настройките за права за достъп.

Възможно е също така едновременно да се добавят ограничения към няколко роли. За да направите това, в конфигурационното дърво трябва да щракнете с десния бутон върху секцията „Роли“ и да изберете „Всички роли“.

Като заключение бих искал да отбележа, че тази статия е насочена към консултанти за разработчици на 1C и може да помогне предимно на тези, които вече имат опит в разработката на 1C:Enterprise. Въпреки привидната си простота, познаването на семантиката и разбирането на структурата на бизнес процесите на собственото предприятие или организацията на клиента за правилното разпределение на правата изисква определено ниво на знания и опит.

RLS- това е способността на разработчика да задава условия на таблиците на базата данни за определени потребители (потребителски групи) и да им попречи да виждат ненужни неща. Условието е от булев тип. Ако условието е вярно, тогава достъпът се предоставя, в противен случай се отказва.

RLS се използва едновременно със задаване на нормални права за достъп. Следователно, преди да започнете да конфигурирате RLS, трябва да присвоите редовни права на конфигурационни обекти.

RLS се използва за следните видове права за достъп:

Четене
Допълнение
промяна
Премахване

Как да конфигурирате RLS

Нека да разгледаме прост пример как да го конфигурирате. Екранните снимки са направени на версия 1C Enterprise 8.2 (8.2.9.356). Синтаксисът на текстовите шаблони за ограничения е описан в документацията за 8.2 в книгата „Ръководство за програмисти. Част 1“, така че няма да се спираме на него.

И така, първата стъпка е да се дефинират шаблони за ограничения за всяка съществуваща роля.

След това, въз основа на посочените шаблони, се задават ограничения за необходимите обекти. За да редактирате текста на условие, можете да използвате дизайнера на ограничения за достъп до данни.

За да редактирате множество роли, е удобно да управлявате през прозореца „Всички роли“.

Можете да използвате прозореца Всички ограничения за достъп, за да копирате условия към други роли. Шаблоните могат да се копират само ръчно към други роли.

Това е всичко. Можете да проверите резултата.

Недостатъци на използването на RLS:

Използването на механизъм за ограничаване на достъпа на ниво запис води до имплицитно увеличаване на таблиците, участващи в заявката, което може да доведе до грешки в режим клиент-сървър на базата данни.
Може да е трудно или невъзможно да се приложи сложна логика на приложението за контрол на записа. В такива случаи е по-добре да използвате условия в процедурата OnWrite().
Писането на условие (заявка) изисква определени квалификации на разработчика.
Допълнителни трудности могат да бъдат създадени от невъзможността за отстраняване на грешки в условие (заявка).

В типичните конфигурации правата на ниво запис могат да се задават интерактивно за следните обекти: организации, контрагенти, артикули, складове, подразделения, физически лица, кандидатстващи заявления и други.

Трябва да се помни, че ограниченията на правата за достъп на ниво запис са доста ресурсоемък механизъм и колкото по-сложни ограничения зададете, толкова по-бавно ще работи програмата, особено с голяма база данни.

Класически проблем: дават на потребителя достъп до обект, но не към всички елементи/документи, а само към някои.

Например, за да може мениджърът да вижда отчети само за своите клиенти.

Или може да е ограничение „всички освен някои“.
Или ограничението не е за справочници/документи, а за регистриране на данни…

Например, така че потребителите да не могат да извличат данни за плащания към партньори, използвайки какъвто и да е отчет.

По същество това е фина и много гъвкава настройка на „какво може да види този потребител и за какво не трябва да предполага“.

Защо RLS?

Повечето реализации изискват различни потребители да задават различни нива на достъп до информацията в базата данни.

В конфигурациите специални обекти на метаданни - роли - отговарят за възможните права за достъп до данните. На всеки потребител на информационна база се присвояват една или повече роли. Те определят дали са възможни операции върху конкретни обекти с метаданни (четене, писане, публикуване и т.н.).

Но това не е всичко.

Често се налага не просто отваря/отказва достъп до определен обект, а ограничава достъпа до част от данните в него.

Този проблем не може да бъде разрешен само с помощта на роли.– за целта е внедрен механизъм за ограничаване на достъпа на ниво запис (RLS).

Ограниченията представляват условия, при които ще бъде разрешено действие върху данни (четене, писане и т.н.). – по този начин можете да ограничите достъпа не до обекта като цяло, а само до част от данните му.

За RLS - по-подробно: 8 видеоклипа и PDF

Тъй като това е често срещана задача за администриране на 1C, предлагаме да разгледаме по-подробни материали:

Ограничаване на достъпа до данни с помощта на роли

Този видеоклип обяснява как да ограничите достъпа до данни с помощта на роли. Пояснява се, че ролите ограничават достъпа до тип обекти на информационната база (отделна директория, но не и конкретни елементи от директорията).

Ограничение на нивото на запис (RLS)

Това видео говори за механизма за ограничаване на достъпа на ниво запис (RLS), когато можете да конфигурирате достъп не до цялата директория като цяло, а до нейните отделни елементи, в зависимост от тези, които се съхраняват в информационната база данни. Подобни ограничения са предписани в ролите.

Внедряване на ограничения за достъп на ниво запис за директория Изпълнители

Този видеоклип обяснява как да настроите мениджърски достъп само до техните собствени контрагенти, които са им присвоени в демонстрационната конфигурация на управлявано приложение.

Как работят ограниченията за достъп на ниво запис на ниско ниво

Това видео обяснява как платформата трансформира заявки, изпратени до DBMS сървъра за изпълнение, когато има ограничения за достъп на ниво запис.

Прилагане на множество ограничения за достъп на ниво запис заедно

Потребителят на информационната база може да получи няколко роли. Освен това всяка роля може да има свои собствени ограничения за достъп на ниво запис. Този видеоклип обяснява как се държи системата, когато са наложени ограничения.

Налагане на ограничения чрез метода ALL

Това видео описва първия метод за налагане на ограничения на рекордно ниво - методът ALL. В този случай, ако изборът включва записи, до които достъпът е ограничен, ще се покаже съобщение за грешка.

Налагане на ограничения чрез метода ALLOWED

Това видео описва първия метод за налагане на ограничения на ниво рекорд - методът РАЗРЕШЕНО. В този случай само онези записи, до които потребителят има права на достъп, ще бъдат включени в селекцията.

Ето някои теми от курса:

Инсталиране и актуализиране на платформата 1C:Enterprise 8 – ръчно и автоматично, за Windows и Linux
Автоматичен стартза извършване на рутинни операции
Актуализиране на конфигурации от потребителски режим
Актуализиране на нестандартни конфигурации. Как да избегнете проблеми при актуализиранемодифицирани стандартни конфигурации
Създайте свой собствен доставка на cfu файлове
BSP инструменти: външни формуляри, обработка на попълване на документи и др.
Използване безплатна СУБД PostgreSQL
Инсталиране и стартиране сървърен клъстер 1C:Предприятие 8
Помощна програма за администриранеза настройка на клъстер и работни сървъри
Настройки RLSизползвайки примера на UPP 1.3 и ERP 2
Какво да направите, ако данните в информационната сигурност са повредени
Настройки обмен на даннимежду конфигурации
Организация групово развитие
Настройка и използване хардуерни защитни ключове
1C софтуерни лицензи: монтаж и обвързване към външно оборудване

Във всеки случай в даден момент ще трябва да разположите 1C, да конфигурирате резервации, права за достъп, различни режими на стартиране, да тествате целостта на базите данни, да осигурите работата на сървърите и т.н.

И е по-добре да го направите веднага.

За да не стане после „...! Ами какво по...! Ваш...!” – и други изрази на съжаление :)

Как да конфигурирате права за достъп в 1C 8.3?

В тази статия ще разгледаме как да работим с потребители в 1C Accounting 8.3:

създайте нов потребител
конфигуриране на права - профили, роли и групи за достъп
как да конфигурирате ограничение на правата на ниво запис (RLS) в 1C 8.3 - например по организация

Инструкциите са подходящи не само за счетоводната програма, но и за много други, изградени на базата на BSP 2.x: 1C Trade Management 11, Salary and Personnel Management 3.0, ERP 2.0, Small Firm Management и други.

В интерфейса на програмата 1C управлението на потребителите се извършва в раздела „Администриране“, в елемента „Настройване на потребители и права“:

Как да създадете нов потребител в 1C

За да създадете нов потребител в 1C Accounting 3.0 и да му зададете определени права за достъп, в менюто „Администрация“ има елемент „Настройки на потребителя и правата“. Хайде да отидем там:

Списъкът с потребители се управлява в секцията „Потребители“. Тук можете да създадете нов потребител (или група потребители) или да редактирате съществуващ. Само потребител с администраторски права може да управлява списъка с потребители.

Нека създадем потребителска група, наречена „Счетоводство“, и в нея ще има двама потребители: „Счетоводител 1“ и „Счетоводител 2“.

За да създадете група, щракнете върху бутона, маркиран на фигурата по-горе, и въведете име. Ако в информационната база има други потребители, които са подходящи за ролята на счетоводител, можете веднага да ги добавите към групата. В нашия пример няма такива, затова кликваме върху „Запазване и затваряне“.

Сега нека създадем потребители. Поставете курсора върху нашата група и щракнете върху бутона „Създаване“:

В пълното име ще въведем „Счетоводител 1“, а името за вход ще бъде зададено на „Счетоводител1“ (това ще се показва при влизане в програмата). Паролата ще бъде „1“.

Не забравяйте да се уверите, че квадратчетата „Влизане в програмата е разрешено“ и „Показване в списъка за избор“ са отметнати, в противен случай потребителят няма да се види по време на оторизация.

Оставете „Режим на стартиране“ като „Автоматично“.

Настройка на права за достъп - роли, профили

Сега трябва да посочите „Права за достъп“ за този потребител. Но първо трябва да го запишете, в противен случай ще се появи предупредителен прозорец, както е показано на снимката по-горе. Щракнете върху „Запис“, след това върху „Права за достъп“:

Изберете профил Счетоводител. Този профил е стандартен и конфигуриран с основните права, изисквани от счетоводителя. Кликнете върху „Запис“ и затворете прозореца.

В прозореца „Потребител (създаване)“ щракнете върху „Запазване и затваряне“. Създаваме и втори счетоводител. Уверяваме се, че потребителите са активирани и могат да работят:

Трябва да се отбележи, че един и същи потребител може да принадлежи към няколко групи.

Избрахме права за достъп за счетоводители от тези, които бяха включени в програмата по подразбиране. Но има ситуации, когато е необходимо да се добави или премахне някакво право. За да направите това, е възможно да създадете свой собствен профил с набор от необходими права за достъп.

Нека отидем в раздела „Профили на групи за достъп“.

Да кажем, че трябва да позволим на нашите счетоводители да видят записа в дневника.

Създаването на профил от нулата е доста трудоемко, така че нека копираме профила на „Счетоводител“:

И нека направим необходимите промени в него - добавете ролята „Преглед на дневника“:

Нека да дадем друго име на новия профил. Например „Счетоводител с добавки“. И поставете отметка в квадратчето „Преглед на регистъра на регистрацията“.

Сега трябва да променим профила на потребителите, които създадохме по-рано.

Ограничаване на правата на ниво запис в 1C 8.3 (RLS)

Нека да разберем какво означава ограничаване на правата на ниво запис или както го наричат в 1C - RLS (защита на нивото на запис). За да получите тази възможност, трябва да поставите отметка в съответното поле:

Програмата ще изисква потвърждение на действието и ще ви информира, че такива настройки могат значително да забавят системата. Често е необходимо някои потребители да не виждат документи на определени организации. Точно за такива случаи има настройка за достъп на ниво запис.

Отиваме отново в раздела за управление на профили, щракнете двукратно върху профила „Счетоводител с добавки“ и отидете в раздела „Ограничения за достъп“:

„Тип достъп“ изберете „Организации“, „Стойности на достъп“ изберете „Всички разрешени, изключенията се присвояват в групи за достъп“. Кликнете върху „Запазване и затваряне“.

Сега се връщаме в секцията „Потребители“ и избираме например потребителя „Счетоводител 1“. Щракнете върху бутона „Права за достъп“:

Чрез бутона „Добавяне“ изберете организацията, чиито данни ще се виждат от „Счетоводител 1“.

Забележка! Използването на механизъм за разделяне на правата на ниво запис може да повлияе на работата на програмата като цяло. Забележка за програмиста: същността на RLS е, че системата 1C добавя допълнително условие към всяка заявка, като изисква информация дали потребителят има право да чете тази информация.

Други настройки

Разделите „Настройки за копиране“ и „Настройки за изчистване“ не предизвикват никакви въпроси, имената им говорят сами за себе си. Това са настройки за външния вид на програмата и отчетите. Например, ако сте настроили красив външен вид за директорията „Номенклатура“, той може да бъде копиран на други потребители.

В секцията „Потребителски настройки“ можете да промените външния вид на програмата и да направите допълнителни настройки за по-лесно използване.

Квадратчето „Разрешаване на достъп до външни потребители“ ви позволява да добавяте и конфигурирате външни потребители. Например, искате да организирате онлайн магазин, базиран на 1C. Клиентите на магазина ще бъдат външни потребители. Правата за достъп се конфигурират по същия начин като обикновените потребители.

По материали от: programmist1s.ru