Restricții privind accesul la date în rolurile 1s. Drepturi de acces la SCP. RLS. Informații generale și setări. Restricționați accesul la nivel de înregistrare

Toate setările pentru drepturile utilizatorului pe care le vom face în cadrul acestui articol se află în secțiunea 1C 8.3 „Administrare” - „Setări pentru utilizatori și drepturi”. Acest algoritm este similar în majoritatea configurațiilor pe formularele gestionate. Programul 1C Accounting va fi folosit ca exemplu, dar setarea drepturilor în alte programe (1C UT 11, 1C ZUP 3, 1C ERP) se face exact în același mod.

Să mergem la secțiunea „Utilizatori” din fereastra de setări. Aici vedem două hyperlinkuri: „Utilizatori” și „Setări de conectare”. Primul dintre ele vă permite să mergeți direct la lista de utilizatori a acestei baze de informații. Înainte de a crea un utilizator nou, luați în considerare posibilele setări de conectare (hiperlink în dreapta).

În acest formular de setări, puteți seta complexitatea parolei (cel puțin 7 caractere, conținut obligatoriu de diferite tipuri de caractere etc.). Aici puteți specifica și durata parolei, perioada de valabilitate a acesteia și interzicerea accesului la program pentru utilizatorii care nu au avut activitate de o anumită perioadă de timp.

Acum puteți trece direct la adăugarea unui nou utilizator la 1C. Puteți face acest lucru făcând clic pe butonul „Creați”, așa cum se arată în imaginea de mai jos.

În primul rând, indicăm numele complet - „Antonov Dmitry Petrovici” și selectăm o persoană din directorul corespunzător. Aici puteți specifica și departamentul în care lucrează angajatul nostru.

Numele de conectare „AntonovDP” a fost înlocuit automat ca abreviere pentru numele complet „Antonov Dmitri Petrovici”. Setați o parolă și o autentificare pentru 1C Enterprise. Aici puteți specifica, de asemenea, dacă acestui utilizator îi este permis să schimbe singur parola.

Să presupunem că dorim ca Dmitri Petrovici Antonov să fie disponibil în lista de selecție atunci când începem această bază de informații. Pentru a face acest lucru, trebuie să setați steagul pe elementul „Afișați în lista de selecție”. Ca urmare, fereastra de autorizare la pornirea programului va arăta ca cea prezentată în figura de mai jos.

Să acordăm atenție unei alte setări importante din cardul ghidului utilizatorului - „Este permisă conectarea la program”. Dacă decalajul nu este setat, atunci utilizatorul pur și simplu nu va putea intra în această bază de informații.

Drepturi de acces

După completarea tuturor datelor din cardul de utilizator - Antonov Dmitry Petrovici, le vom nota și vom trece la setarea drepturilor de acces, așa cum se arată în figura de mai jos.

Înainte de a ne deschide o listă de profiluri de acces introduse anterior în program. Bifați casetele necesare.

Accesați profilurile de grup

Profilurile grupurilor de acces pot fi configurate din formularul principal pentru setarea utilizatorilor și drepturilor. Accesați secțiunea „Grupuri de acces” și faceți clic pe hyperlinkul „Profiluri de acces de grup”.

Să creăm un grup nou din formularul de listă deschis. În secțiunea tabelară din fila „Acțiuni (roluri) permise”, este necesar să bifați casetele pentru acele roluri care vor afecta drepturile de acces ale utilizatorilor incluși în grupul pe care îl creăm. Toate aceste roluri sunt create și configurate în configurator. Ele nu pot fi modificate sau create din modul utilizator. Puteți alege doar dintr-o listă existentă.

RLS: restricție de acces la nivel de înregistrare

Vă permite să configurați mai flexibil accesul la datele programului în anumite secțiuni. Pentru a-l activa, setați steag pe elementul cu același nume în formularul de setări de utilizator și drepturi.

Vă rugăm să rețineți că activarea acestei setări poate afecta negativ performanța sistemului. Ideea este că mecanismul RLS modifică toate cererile în funcție de restricțiile setate.

Să mergem la profilul de grup de acces „Grup de testare” pe care l-am creat mai devreme. Figura de mai jos arată că după activarea restricției de acces la nivel de înregistrare a apărut o filă suplimentară „Restricțiuni de acces”.

Să presupunem că dorim ca utilizatorii cărora le este atribuit grupul de testare să aibă acces la datele pentru toate organizațiile din această bază de informații, cu excepția celor specificate în profil.

În secțiunea tabelară de sus, setați restricția de acces în funcție de organizație. În partea de jos, vom preciza că nu se va asigura accesul la date (documente, directoare etc.) pentru organizația Roga SRL.

Adesea este nevoie de a restricționa parțial accesul la date. De exemplu, atunci când un utilizator trebuie să vadă documente numai pentru organizația sa. În astfel de cazuri, 1C utilizează un mecanism de restricție de acces la nivel de înregistrare (așa-numitul RLS - Record Level Securiy).

De exemplu, să presupunem că ne confruntăm cu următoarea sarcină. Întreprinderea menține o contabilitate multi-societate și fiecare contraparte și utilizator al bazei de date aparține unei anumite organizații. Este necesar să se ofere acces la directorul „Contractanți” în așa fel încât fiecare utilizator să poată vizualiza, edita și adăuga contrapartide numai în organizația sa.

Pentru a rezolva problema, vom folosi platforma „1C:Enterprise 8.2″. Să creăm o nouă configurație în proprietățile căreia opțiunea „Aplicație gestionată” va fi selectată ca mod principal de lansare.

În continuare, vom crea directorul „Organizații” și încă două directoare - „Contractanți” și „Utilizatori” cu atributul „Organizație”. În plus față de directoare, avem nevoie de doi parametri de sesiune - „Organizare” și „Utilizator” (de tipurile adecvate). Valorile acestor parametri sunt setate la începutul unei sesiuni de configurare și sunt stocate până la sfârșit. Sunt valorile acestor parametri pe care le vom folosi atunci când adăugăm condiții de restricție de acces la nivel de înregistrare.

Parametrii de sesiune sunt setați într-un modul special - „Modul de sesiune”

În acest modul, descriem procedura predefinită „SetSessionParameters” în care numim funcția modulului general pre-preparat „FullPermissions”. Acest lucru este necesar din cauza particularităților funcționării bazei de date în modul aplicație gestionată, când o parte din codul programului poate fi executată numai pe partea serverului (nu mă voi opri asupra explicarii acestor principii în acest articol).

Cod 1C v 8.x Procedură Setarea parametrilor sesiunii (parametri obligatorii)
FullPermissions.SetSessionParameters();
EndProcedure

În proprietățile modulului „FullPermissions”, bifați casetele „Server”, „Apel server” și „Privilegiat” (cel din urmă înseamnă că procedurile și funcțiile acestui modul vor fi executate fără control de acces). Textul modulului va arăta astfel:

Cod 1C v 8.x Funcția DetermineCurrentUser()
CurrentUser = Directories.Users.FindByName(UserName(), True);
Returnează Utilizatorul curent;
EndFunctions

Procedură SetSessionParameters() Export
CurrentUser = Determină CurrentUser();
CurrentOrganization = Directories.Organizations.EmptyReference();
Dacă ValueFilled(CurrentUser) Atunci
CurrentOrganization = CurrentUser.Organization;
EndIf;
SessionParameters.User = CurrentUser;
SessionParameters.Organization = CurrentOrganization;
EndProcedure

FunctionSessionParameterSet(ParameterName) Export
Returnează ValoareaCompletată(SessionParameters[ParameterName]);
EndFunctions

Funcția RoleAvailableToUser(RoleName) Export
Returnează RoleAvailable(RoleName);
EndFunctions

În modulul aplicației gestionate, vom verifica prezența unui utilizator de configurare în directorul „Utilizatori” (pentru simplitate, îl vom căuta după nume) și vom închide sistemul dacă nu este găsit. Acest lucru este necesar pentru a vă asigura că parametrii sesiunii sunt populați.

Cod 1C v 8.x Procedura de funcționare pre-sistem (Eșec)
// toți, cu excepția administratorului, vor fi verificați pentru prezența în directorul „Utilizatori”.
Dacă nu este FullPermissions.RoleAvailableToUser(„FullPermissions”), atunci
Dacă NU FullPermissions.SessionParameterSet(„Utilizator”), atunci
Avertisment ("Utilizator """ + Nume utilizator() + """ nu a fost găsit în director!");
Respingere = adevărat;
Întoarcere;
EndIf;
EndIf;
EndProcedure

Acum putem merge direct la descrierea restricțiilor de acces. Pentru a face acest lucru, creați rolul „Utilizator” și accesați fila „Șabloane de restricții”, unde adăugăm un nou șablon „AccountsReadingChange” cu următorul text șablon: WHERE Organizație = Organizație #Parametru(1)

Textul șablonului de constrângere este o extensie a limbajului de interogare. Spre deosebire de o cerere obișnuită, textul de restricție trebuie să conțină în mod necesar clauza „UNDE”. Ca valori ale parametrilor de interogare (în cazul nostru, este „&Organization”), sunt folosite valorile parametrilor de sesiune cu același nume. O construcție a formei #Parameter(1) înseamnă că sistemul va înlocui textul trecut ca prim parametru în locul în care șablonul este folosit în acest loc. Cu ajutorul șablonului dat, fiecare înregistrare a tabelului va fi verificată (în cazul nostru, va fi căutarea „Contractanți”). Pentru înregistrările a căror valoare de atribut „Organizare” se potrivește cu cea specificată în parametrul de sesiune corespunzător, condiția descrisă în șablon va fi îndeplinită. Astfel, aceste intrări vor fi disponibile pentru citire, editare sau adăugare (în funcție de care dintre aceste drepturi se aplică șablonul). Voi demonstra cele de mai sus cu exemplul nostru.

Să mergem la fila „Drepturi” a rolului „Utilizator” și să deschidem lista de drepturi din directorul „Conturi”. Vom folosi șablonul de constrângere „AccountsReadChange” pentru permisiunile „Citire”, „Schimbare” și „Adăugați”.

Pentru dreptul „Citește”, vom folosi un șablon cu parametrul „OR ThisGroup”. În același timp, utilizatorilor acestui rol li se va permite să citească nu numai elementele directorului „Conturi” al organizației lor, ci și toate grupurile acestui director.

#AccountsReadingChange(„SAU AcestGrup”)

Deoarece la adăugarea de noi elemente ale directorului, sistemul realizează o citire implicită a atributelor predefinite (acest lucru este necesar, de exemplu, pentru numerotare), este necesar să se asigure citirea nestingherită a acestor câmpuri. Pentru a face acest lucru, adăugați o linie suplimentară cu un text de restricție gol la tabelul de restricții de acces la date și enumerați câmpurile pentru care se aplică această regulă - Link, Versiune date, Părinte, Cod.

Astfel, sarcina restricționării accesului la nivel de înregistrare este rezolvată. Utilizatorii cu restricții existente vor avea acces să vizualizeze și să editeze date numai pentru organizația lor.

Platforma 1C:Enterprise 8 are un mecanism încorporat pentru restricționarea accesului la date la nivel de înregistrare. Puteți citi informații generale despre el aici. Pe scurt, RLS vă va permite să restricționați accesul la date în funcție de anumite condiții pe valorile câmpului. De exemplu, puteți restricționa accesul utilizatorilor la documente în funcție de valoarea atributului „Organizație”. Unii utilizatori vor lucra cu documente pentru organizația „Management Company”, iar restul cu organizația „Dairy Plant”. Ca exemplu.

Pregătirea

Exemplul este implementat în configurația demonstrativă a SCP 1.3. Să creăm un utilizator „Storekeeper” și să îi adăugăm rolul „Storekeeper” cu același nume.

Acum să trecem direct la setarea drepturilor de acces la nivel de înregistrare. Să trecem la interfața „Administrare utilizatori”. În meniul principal, selectați „Acces la nivel de înregistrări -> Opțiuni”. Aici bifăm caseta „Restricționați accesul la nivel de înregistrare după tipuri de obiecte”, iar în lista de obiecte selectați „Organizații”.

Astfel, am activat utilizarea RLS. Acum trebuie să-l configurați.

Controlul accesului la nivel de înregistrare nu este configurat separat pentru fiecare utilizator sau profil de permisiune. RLS este configurat pentru grupuri de utilizatori. Să adăugăm un nou grup de utilizatori, să-l numim „Depozitari”

Compoziția grupului din partea dreaptă a formularului arată o listă de utilizatori care aparțin acestui grup. Să adăugăm utilizatorul pe care l-am creat mai devreme. În stânga este un tabel cu restricții de acces. În setarea RLS, am ales ca accesul să fie limitat doar de organizații, așa că vedem un singur tip de obiect de acces. Faceți clic pe butonul „Setări de acces”. Se deschide procesarea pentru setarea permisiunilor pentru grupul curent.

În lista de obiecte de acces pentru grup, adăugați organizația „PPE „Antreprenor””. Vom lăsa neschimbat tipul de moștenire a drepturilor. Dreptul la obiectul de acces va fi setat la citire și scriere. Faceți clic pe „OK”, setările sunt gata. Tocmai am înființat RLS la nivel de organizație.

Ce vede utilizatorul

Rulați programul sub utilizatorul creat anterior și deschideți directorul „Organizații”. Iată cum va arăta lista pentru utilizatorul nostru și pentru un utilizator cu drepturi depline:

După cum putem vedea, utilizatorul depozitar vede o singură organizație pentru care am deschis accesul la citire. Același lucru este valabil și pentru documente, cum ar fi recepțiile de bunuri și servicii.

Astfel, utilizatorul nu numai că nu va vedea organizații, accesul la care nu este setat pentru el, dar nici nu va putea citi/scrie documente și alte obiecte din baza de info, pentru care drepturile în rol pe atributul „Organizație”. " sunt aranjate.

Am luat în considerare cel mai simplu exemplu de configurare a RLS. În articolul următor, vom vorbi despre implementarea mecanismului RLS în configurația „Manufacturing Enterprise Management” versiunea 1.3.

1C are un sistem de drepturi de acces încorporat (acest sistem se numește roluri 1C). Acest sistem este static - deoarece administratorul a setat drepturile la 1C, așa să fie.

În plus, există un sistem dinamic de drepturi de acces (numit - RLS 1C). În acesta, drepturile 1C sunt calculate dinamic în momentul lucrului utilizatorului, pe baza parametrilor specificați.

Una dintre cele mai comune setări de securitate în diferite programe este un set de permisiuni de citire/scriere pentru grupuri de utilizatori și apoi - includerea sau excluderea unui utilizator din grupuri. De exemplu, un sistem similar este utilizat în Windows AD (Active Directory).

Un astfel de sistem de securitate în 1C se numește Roles 1C. Rolurile 1C se află în configurația din ramura General / Roluri. Rolurile 1C acționează ca grupuri pentru care sunt atribuite drepturi 1C. Apoi, utilizatorul este inclus sau exclus din acest grup.

Făcând dublu clic pe numele rolului 1C, veți deschide editorul de drepturi pentru rolul 1C. În stânga este o listă de obiecte 1C. Selectați oricare și opțiunile pentru drepturile de acces vor fi afișate în partea dreaptă (cel puțin: citiți, adăugați, modificați, ștergeți).

Pentru ramura de sus (numele configurației curente), sunt setate drepturi administrative 1C și acces pentru a lansa diferite opțiuni.

Toate drepturile 1C sunt împărțite în două grupuri - drept „simplu” și același drept cu adăugarea „interactiv”. Ce înseamnă?

Când un utilizator deschide un formular (de exemplu, procesare) și apasă un buton pe acesta, programul în limbajul 1C încorporat efectuează anumite acțiuni, de exemplu, ștergerea documentelor. Pentru permisiunea acestor acțiuni (realizate programatic) - „pur și simplu” sunt responsabile drepturile lui 1C.

Când un utilizator deschide un jurnal și începe să facă ceva de la tastatură pe cont propriu (de exemplu, introducerea de noi documente), acestea sunt drepturi 1C „interactive”.

Un utilizator poate avea mai multe roluri disponibile, caz în care permisiunile sunt adăugate împreună.

Secțiunea despre posibilitățile de setare a drepturilor de acces folosind roluri este un obiect 1C. Adică puteți fie să activați accesul la director, fie să îl dezactivați. Nu poate fi pornit un pic.

Pentru aceasta, există o extensie a sistemului de rol 1C numită 1C RLS. Acesta este un sistem dinamic de drepturi de acces care vă permite să restricționați parțial accesul. De exemplu, utilizatorul vede doar documentele pentru un anumit depozit și organizație și nu vede restul.

Cu grija! Când se utilizează schema confuză RLS 1C, utilizatori diferiți pot avea întrebări atunci când încearcă să verifice același raport generat de la utilizatori diferiți.

Luați un anume director (ex. organizații) și un anumit drept (ex. citire). Permiteți citirea pentru rolul 1C. În panoul Restricție acces la date, setați textul interogării, care returnează TRUE sau FALSE, în funcție de setări. Setările sunt de obicei stocate în registrul de informații (de exemplu, registrul de informații de configurare Accounting UserAccessRightsSettingsUsers).

Această solicitare este executată dinamic (când se încearcă implementarea citirii), pentru fiecare intrare de director. Astfel, pentru acele înregistrări pentru care interogarea de securitate a returnat TRUE, utilizatorul o va vedea, dar restul nu.
Drepturile 1C care fac obiectul restricțiilor RLS 1C sunt evidențiate cu gri.

Copierea acelorași setări RLS 1C se face folosind șabloane. Faceți un șablon, îl denumiți (de exemplu) MyTemplate, specificați o solicitare de securitate în el. Apoi, în setările drepturilor de acces 1C, specificați numele șablonului astfel: „#MyTemplate”.

Când un utilizator lucrează în modul 1C Enterprise, când RLS 1C rulează, el poate primi un mesaj de eroare „Drepturi insuficiente” (de exemplu, pentru a citi directorul Xxx).

Aceasta înseamnă că RLS 1C a blocat citirea mai multor înregistrări.

Pentru a preveni apariția unui astfel de mesaj, este necesar să folosiți cuvântul PERMIS () în textul cererii în limbajul 1C încorporat.

De exemplu:

Programul 1C are încorporat un sistem de drepturi de acces, care se află în Configurator - General - Roluri.

Ce caracterizează acest sistem și care este scopul său principal? Vă permite să descrieți seturi de drepturi care corespund pozițiilor utilizatorilor sau activităților acestora. Acest sistem de drepturi de acces este de natură static, ceea ce înseamnă că, pe măsură ce administratorul a stabilit drepturile de acces la 1C, așa este. Pe lângă cel static, există un al doilea sistem de drepturi de acces - dinamic (RLS). În acest sistem, drepturile de acces sunt calculate în mod dinamic, în funcție de parametrii dați, în cursul activității.

Roluri în 1C

Cele mai comune setări de securitate în diferite programe sunt așa-numitul set de permisiuni de citire/scriere pentru diferite grupuri de utilizatori și în viitor: includerea sau excluderea unui anumit utilizator din grupuri. Un astfel de sistem, de exemplu, este utilizat în sistemul de operare Windows AD (Active Directory). Sistemul de securitate utilizat în software-ul 1C se numește roluri. Ce este? Roluri în 1C este un obiect care se află în configurația din ramura: General - Roluri. Aceste roluri 1C sunt grupuri pentru care sunt atribuite drepturi. În viitor, fiecare utilizator poate fi inclus și exclus din acest grup.

Făcând dublu clic pe numele rolului, veți deschide editorul de drepturi pentru rol. În stânga este o listă de obiecte, marcați oricare dintre ele și în dreapta veți vedea opțiuni pentru posibile drepturi de acces:

— citire: obținerea înregistrărilor sau a fragmentelor lor parțiale dintr-un tabel de bază de date;
- adăugarea: noi înregistrări, păstrându-le pe cele existente;
— modificare: efectuarea de modificări la înregistrările existente;
- ștergere: unele înregistrări, restul păstrând neschimbate.

Rețineți că toate drepturile de acces pot fi împărțite în două grupuri principale - acesta este un drept „simplu” și un astfel de drept cu adăugarea caracteristicii „interactive”. Ce înseamnă aici? Și treaba este următoarea.

În cazul în care utilizatorul deschide un formular, de exemplu, procesare și, în același timp, face clic pe acesta cu mouse-ul, programul în limbajul 1C încorporat începe să efectueze acțiuni specifice, de exemplu, ștergerea documentelor. Pentru permisiunea unor astfel de acțiuni efectuate de program, drepturile 1C sunt responsabile, respectiv, „pur și simplu”.

În cazul în care utilizatorul deschide jurnalul și începe să introducă ceva pe cont propriu de la tastatură (documente noi, de exemplu), atunci drepturile „interactive” 1C sunt responsabile pentru a permite astfel de acțiuni. Fiecare utilizator poate avea mai multe roluri disponibile simultan, apoi se adaugă permisiunea.

RLS în 1C

Puteți activa accesul la director (sau document) sau îl puteți dezactiva. Nu poți să-l pornești puțin. În acest scop, există o anumită extensie a sistemului de rol 1C, care se numește RLS. Acesta este un sistem dinamic de drepturi de acces care introduce restricții de acces parțial. De exemplu, doar documentele unei anumite organizații și depozit devin disponibile în atenția utilizatorului, restul nu le vede.

Trebuie avut în vedere faptul că sistemul RLS trebuie aplicat cu mare atenție, deoarece este destul de dificil de înțeles schema sa complicată și diferiți utilizatori pot avea întrebări atunci când, de exemplu, compară același raport, care este generat din diferite utilizatorii. Să luăm în considerare un astfel de exemplu. Alegeți un anume director (organizații, de exemplu) și un anumit drept (citire, de exemplu), adică permiteți citirea pentru rolul 1C. În același timp, setați textul solicitării în panoul de la distanță Restricții de acces la date, în funcție de care este setat False sau True, în funcție de setări. De obicei, setările sunt stocate într-un registru special de informații.

Această interogare va fi executată dinamic (când se încearcă organizarea citirii), pentru toate intrările de director. Funcționează astfel: acele înregistrări pentru care solicitarea de securitate le-a atribuit - Adevărat, utilizatorul va vedea, dar alții nu. Drepturile 1C cu restricții stabilite sunt evidențiate cu gri.

Operația de copiere a setărilor RLS identice se realizează folosind șabloane. Pentru început, creați un șablon, denumindu-l, de exemplu, MyTemplate, în care reflectați solicitarea de securitate. Apoi, în setările drepturilor de acces, specificați numele acestui șablon în acest fel: „#MyTemplate”.

Când un utilizator lucrează în modul 1C Enterprise, atunci când se conectează la RLS, poate apărea un mesaj de eroare precum: „Drepturi insuficiente” (pentru a citi directorul XXX, de exemplu). Aceasta indică faptul că sistemul RLS a blocat citirea unor înregistrări. Pentru a preveni apariția din nou a acestui mesaj, trebuie să introduceți cuvântul PERMIS în textul solicitării.