Caietul unui programator. Drepturi de acces la SCP. RLS. Informații generale și configurare Restricționarea accesului la nivel de înregistrare în 1s

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.

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.

Provocare clasică: oferi utilizatorului acces la orice obiect, dar nu tuturor elementelor/documentelor, ci doar unora.

De exemplu, ca un manager să vadă rapoarte numai pentru clienții săi.

Sau ar putea fi o limitare „totul cu excepția unora”.
Sau restricția nu este pe directoare/documente, ci pentru a înregistra date…

De exemplu, pentru ca utilizatorii să nu poată extrage date despre plățile către parteneri cu niciun raport.

De fapt, aceasta este o setare fină și foarte flexibilă „ce poate vedea acest utilizator și despre ce nu trebuie să ghicească”.

De ce RLS?

În majoritatea implementărilor, este necesar ca utilizatorii diferiți să stabilească niveluri diferite de acces la informații din baza de date.

În configurații, obiectele metadate speciale – roluri – sunt responsabile pentru posibilele drepturi de acces la date. Fiecărui utilizator al bazei de informații îi sunt atribuite unul sau mai multe roluri. Ele determină dacă operațiunile sunt posibile pe anumite obiecte de metadate (citire, scriere, glisare etc.).

Dar asta nu este tot.

Este adesea necesar nu doar deschide/interzice accesul la un anumit obiect, ci restricționează accesul la o parte a datelor din acesta.

Nu poți rezolva această problemă doar cu roluri.– pentru aceasta, este implementat un mecanism de restricționare a accesului la nivel de înregistrare (RLS).

Constrângerile sunt condiții în care va fi permisă o acțiune asupra datelor (citire, scriere etc.). - în acest fel puteți restricționa accesul nu la obiect în ansamblu, ci doar la o parte din datele acestuia.

Despre RLS - mai detaliat: 8 videoclipuri și PDF

Deoarece aceasta este o sarcină comună de administrare 1C, vă sugerăm să luați în considerare materiale mai detaliate:

Restricționarea accesului la date folosind roluri

Acest videoclip explică cum să restricționați accesul la date folosind roluri. Este clarificat faptul că rolurile restricționează accesul la tipul de obiecte de bază de informații (o căutare separată, dar nu elemente de căutare specifice).

Restricție de acces la nivel de înregistrare (RLS)

Acest videoclip vorbește despre mecanismul restricțiilor de acces la nivel de înregistrare (RLS), când puteți configura accesul nu la întregul director în ansamblu, ci la elementele sale individuale, în funcție de cele stocate în baza de date de informații. Astfel de restricții sunt prescrise în roluri.

Implementarea restricției de acces la nivel de înregistrare pentru directorul de contrapărți

Acest videoclip arată cum, în configurația demonstrativă „Aplicație gestionată”, configurați accesul managerilor doar la propriile conturi alocate acestora.

Cum funcționează restricțiile de acces la nivel de înregistrare la un nivel scăzut

Acest videoclip arată cum platforma transformă interogările transmise serverului DBMS pentru execuție atunci când există restricții de acces la nivel de înregistrare.

Aplicarea împreună a mai multor restricții de acces la nivel de înregistrare

Un utilizator al bazei de informații i se pot atribui mai multe roluri. În același timp, fiecare rol poate avea propriile restricții de acces la nivel de înregistrare. Acest videoclip explică cum se comportă sistemul atunci când sunt aplicate restricții.

Impunerea restricțiilor folosind metoda ALL

Acest videoclip descrie prima modalitate de a aplica restricțiile la nivel de înregistrare, metoda ALL. În acest caz, dacă selecția include înregistrări la care accesul este restricționat, va fi afișat un mesaj de eroare.

Impunerea de restricții folosind metoda PERMISĂ

Acest videoclip descrie prima modalitate de a aplica restricțiile la nivel de înregistrare, metoda PERMISĂ. În acest caz, numai acele înregistrări la care utilizatorul are drepturi de acces vor fi incluse în selecție.

Iată câteva subiecte de la curs:

• Instalarea și actualizarea platformei 1C:Enterprise 8 - manual și automat, sub Windows și Linux
• Pornire automată pentru a efectua operațiuni de rutină
• Actualizarea configurațiilor din modul utilizator
• Actualizarea configurațiilor non-standard. Cum să evitați problemele la actualizare configurații standard modificate
• Crează-ți propriul fișiere de livrare cfu
• Instrumente BSP: formulare externe, prelucrarea documentelor de completare etc.
• Utilizare DBMS gratuit PostgreSQL
• Instalare și lansare cluster de servere 1C: Întreprinderea 8
• Utilitate de administrare pentru a configura un cluster și servere de producție
• Setare RLS pe exemplul SCP 1.3 și ERP 2
• Ce să faci, dacă datele din IB sunt corupte
• Setare schimburi de dateîntre configurații
• Organizare dezvoltarea grupului
• Configurare și utilizare chei de securitate hardware
• Licențe software 1C: instalarea și legarea de echipamente externe

În orice caz, într-o zi va trebui să implementați 1C, să configurați rezervări, drepturi de acces, diverse moduri de lansare, să testați integritatea bazelor de date, să asigurați funcționarea serverelor etc.

Și e mai bine să o faci corect.

Pentru ca mai târziu să nu existe „…! Ei bine, ce…! A ta…!" - si alte expresii de regret :)

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, să creăm 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, vom descrie procedura predefinită „SetSessionParameters” în care vom numi 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ție RoleDisponibilă pentru export utilizator (RoleName).
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 înregistră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.