În prezent, lucrez pentru o companie furnizoare de software, în special soluții de gestionare a accesului. Iar experiența mea „din viața anterioară” este legată de partea clientului – o mare organizație financiară. Atunci, grupul nostru de control al accesului din departamentul de securitate a informației nu se putea lăuda cu competențe mari în IdM. Am învățat multe în proces, a trebuit să facem multe greșeli pentru a construi în companie un mecanism funcțional de gestionare a drepturilor utilizatorilor în sistemele informaționale.
Combinând experiența mea acumulată din partea clientului cu cunoștințele și competențele furnizorului, vreau să împărtășesc cu voi, în esență, un ghid pas cu pas: cum să creați un model de gestionare a accesului bazat pe roluri într-o mare companie și ce beneficii va aduce aceasta. Instrucțiunea mea este formată din două părți: prima – ne pregătim să construim modelul, a doua – construim efectiv. În fața voastră se află prima parte, pregătitoare.
N.B. Construirea unui model pe roluri este, din păcate, nu un rezultat, ci un proces. Mai exact, o parte a procesului de creare a unui ecosistem de gestionare a accesului în companie. Așa că pregătiți-vă să jucați pe termen lung.
Mai întâi, să definim – ce înseamnă gestionarea accesului bazată pe roluri? Presupunem că aveți o mare bancă cu zeci sau chiar sute de mii de angajați (subiecți), fiecare având zeci de drepturi de acces în sute de sisteme informaționale interne (obiecte). Acum, înmulțiți numărul obiectelor cu numărul subiecților – exact atât de multe relații, minim, trebuie să construiți la început și apoi să le controlați. Este posibil să faceți asta manual? Desigur că nu – pentru a rezolva această problemă, au apărut rolurile.
Rolul este un set de autorități necesar unui utilizator sau unui grup de utilizatori pentru îndeplinirea anumitor sarcini de lucru. Fiecare angajat poate avea unul sau mai multe roluri, iar fiecare rol poate conține de la una la mai multe autorități care sunt permise utilizatorului în cadrul acestui rol. Rolurile pot fi legate de anumite funcții, departamente sau sarcini funcționale ale angajaților.
Rolurile sunt create de obicei din permisiunile individuale ale angajaților din fiecare sistem informațional. Apoi, din rolurile fiecărui sistem se formează roluri de afaceri globale. De exemplu, rolul de afaceri „manager de credit” va include mai multe roluri separate din sistemele informaționale utilizate în biroul clientului băncii. Să zicem, în sisteme precum sistemul bancar automatizat principal, modulul de casierie, sistemul de gestionare a documentelor electronice, managerul de servicii și altele. Rolurile de afaceri sunt, de obicei, legate de structura organizațională - mai simplu spus, de setul de departamente ale companiei și de pozițiile din acestea. Astfel se formează matricea globală a rolurilor (un exemplu este prezentat în tabelul de mai jos).
Trebuie menționat că construirea unui model rol 100% care să ofere toate drepturile necesare angajaților fiecărei poziții dintr-o structură comercială este pur și simplu imposibilă. Și nici nu este necesar. Deoarece modelul rol nu poate fi static, pentru că depinde de mediul în continuă schimbare. Pe de altă parte, de modificările activității de afaceri a companiei, ceea ce, în consecință, influențează schimbarea structurii organizaționale și a funcționalității. Și de lipsa resurselor complete, de nerespectarea instrucțiunilor de lucru, de dorința de profit în detrimentul securității și de mulți alți factori. De aceea, trebuie construit un model de rol care să poată acoperi până la 80% din nevoile utilizatorilor în ceea ce privește drepturile de bază necesare la numirea în funcție. Iar restul de 20% ei îi pot solicita, dacă este necesar, ulterior prin cereri separate.
Desigur, puteți întreba: „Dar, nu există deloc modele rol 100%?” De ce nu, așa ceva se întâlnește, de exemplu, în structuri non-profit care nu sunt supuse schimbărilor frecvente – într-un institut de cercetare, de exemplu. Sau în organizații din industria de apărare cu un nivel ridicat de securitate, unde securitatea este pe primul loc. Există, de asemenea, și în structuri comerciale, dar în cadrul unui singur departament, al cărui proces de lucru este destul de static și previzibil.
Principalul avantaj al gestionării pe roluri este simplificarea acordării de drepturi, deoarece numărul rolurilor este semnificativ mai mic decât numărul utilizatorilor sistemului informațional. Și acest lucru este valabil pentru orice industrie.
Să luăm o companie de retail: aici lucrează mii de vânzători, dar setul de permisiuni în sistemul N este același pentru toți, iar pentru ei va fi creat un singur rol. Când un nou vânzător vine în companie, i se alocă automat rolul necesar în sistem, în care există deja toate permisiunile necesare. De asemenea, cu un singur clic, se pot schimba permisiunile pentru mii de vânzători simultan, de exemplu, se poate adăuga o nouă opțiune pentru generarea unui raport. Nu este nevoie să se facă o mie de operațiuni, legând noua permisiune de fiecare cont – este suficient să se adauge această opțiune în rol, iar ea va apărea pentru toți vânzătorii deodată.
O altă măsură a gestionării pe roluri – excluderea acordării de permisiuni incompatibile. Asta înseamnă că un angajat care are un anumit rol în sistem nu poate deține simultan un alt rol, a cărui permisiuni nu trebuie să se suprapună cu permisiunile din primul. Un exemplu clar – interdicția de a combina funcțiile de introducere și control al operațiunilor financiare.
Toți cei interesați de cum a apărut gestionarea accesului pe roluri în general pot
să facă o incursiune în istorie
Dacă ne uităm la istorie, prima dată comunitatea IT a început să se gândească la metodele de gestionare a accesului în anii '70 ai secolului XX. Deși aplicațiile erau atunci destul de simple, dar, ca și acum, tuturor le-ar fi plăcut să gestioneze accesul într-un mod confortabil. A oferi, schimba și controla drepturile utilizatorilor – pur și simplu pentru a înțelege mai ușor ce acces are fiecare dintre ei. Dar în acea vreme nu existau standarde comune, erau dezvoltate primele sisteme de gestionare a accesului, iar fiecare companie se baza pe propriile sale concepții și reguli.
Acum sunt cunoscute multe modele diferite de gestionare a accesului, dar acestea nu au apărut imediat. Să ne oprim asupra celor care au adus o contribuție semnificativă la dezvoltarea acestui domeniu.
Primul și, probabil, cel mai simplu model – Gestionarea discreționară (selectivă) a accesului (DAC – Controlul accesului discretionar). Acest model implică partajarea drepturilor de către toți participanții la procesul de acces. Fiecare utilizator are acces la obiecte sau operațiuni specifice. Practic, aici, un număr mare de subiecți ai drepturilor corespunde unui număr mare de obiecte. Acest model a fost recunoscut ca fiind prea flexibil și prea complicat de întreținut: listele de acces devin, în timp, enorme și greu de controlat.
Al doilea model este Controlul accesului obligatoriu (MAC — Controlul accesului mandat). În acest model, fiecare utilizator obține acces la un obiect conform unei permisiuni stabilite pentru un anumit nivel de confidențialitate a datelor. Prin urmare, obiectele trebuie să fie clasificate în funcție de nivelul de confidențialitate. Spre deosebire de primul model flexibil, acesta s-a dovedit a fi prea strict și restrictiv. Aplicarea sa nu se justifică atunci când într-o companie există numeroase resurse informaționale diverse: pentru a delimita accesul la diferite resurse, va fi necesar să se introducă numeroase categorii care nu se vor suprapune.
Având în vedere imperfecțiunile evidente ale acestor două metode, comunitatea IT a continuat să dezvolte modele mai flexibile și, în același timp, mai mult sau mai puțin universale pentru a susține diferite tipuri de politici organizaționale de control al accesului. Și atunci a apărut al treilea model de gestionare a accesului pe baza rolurilor! Această abordare s-a dovedit a fi cea mai promițătoare, deoarece necesită nu doar autorizarea identității utilizatorului, ci și a funcțiilor sale de lucru în sisteme.
Prima structură a modelului de roluri a fost clar descrisă de oamenii de știință americani David Ferraiolo și Richard Kuhn de la Institutul Național de Standarde și Tehnologii din SUA în 1992. Atunci a apărut pentru prima dată termenul RBAC (Controlul accesului bazat pe roluri). Aceste cercetări și descrieri ale componentelor de bază, precum și ale interacțiunii lor au stat la baza standardului în vigoare până în prezent INCITS 359-2012, aprobat de Comitetul Internațional pentru Standardele Tehnologiilor Informației (INCITS).
Standardul definește rolul ca fiind «o funcție ocupațională în contextul organizației, având o semnificație asociată în legătură cu puterile și responsabilitățile atribuite utilizatorului desemnat pentru acest rol». Documentul stabilește elementele de bază ale RBAC – utilizatori, sesiuni, roluri, permisiuni, operațiuni și obiecte, precum și relațiile și interconexiunile dintre acestea.
Standardul oferă structura minim necesară pentru a construi un model de rol – combinarea drepturilor în roluri și apoi acordarea accesului utilizatorilor prin aceste roluri. Sunt definite mecanismele prin care rolurile sunt compuse din obiecte și operațiuni, sunt descrise ierarhia rolurilor și moștenirea puterilor. Orice companie are roluri care combină puterile de bază necesare tuturor angajaților. Acestea pot include accesul la e-mail, la sistemele informatice și la portalul corporativ etc. Aceste puteri pot fi incluse într-un rol general numit «angajat», eliminând necesitatea de a enumera toate drepturile elementare în fiecare rol de nivel superior. Este suficient să se indice caracteristica de moștenire a rolului «angajat».
Ulterior, standardul a fost completat cu noi atribute de acces, legate de mediul în continuă schimbare. A fost introdusă posibilitatea de a aplica restricții statice și dinamice. Restricțiile statice implică imposibilitatea de a combina rolurile (acea introducere și control al operațiunilor menționate anterior). Restricțiile dinamice pot fi stabilite în funcție de parametrii variabili, cum ar fi timpul (ore sau zile lucrătoare/non-lucrătoare), locația (birou/casă) etc.
Separat, merită menționat controlul accesului bazat pe atribute (ABAC – Attribute-based access control). Abordarea se bazează pe furnizarea accesului prin reguli de partajare a atributelor. Acest model poate fi utilizat separat, dar adesea completează activ modelul tradițional bazat pe roluri: se pot adăuga atribute utilizatorilor, resurselor și dispozitivelor la un rol specific, precum și la timp sau locație. Aceasta permite utilizarea unui număr mai mic de roluri, introducerea de restricții suplimentare și asigurarea unui acces minim necesar, sporind astfel securitatea.
De exemplu, unui contabil i se poate permite accesul la conturi dacă lucrează într-o anumită zonă. Atunci, locația specialistului va fi comparată cu o valoare de referință specifică. Sau se poate oferi acces la conturi doar dacă utilizatorul se autentifică de pe un dispozitiv înregistrat în lista celor permise. O completare bună pentru modelul de roluri, dar care nu este utilizată frecvent din cauza necesității de a crea multe reguli și tabele de permisiuni sau restricții.
Voi da un exemplu de aplicare a ABAC din viața mea anterioară. La banca noastră erau mai multe filiale. Angajații birourilor clienților din aceste filiale efectuau operațiuni complet identice, dar trebuiau să lucreze în sistemul principal doar cu conturile din regiunea lor. La început, am început să creăm roluri separate pentru fiecare regiune – și astfel de roluri cu funcționalități repetitive, dar cu acces la conturi diferite au rezultat într-un număr foarte mare! Atunci, folosind atributul de locație pentru utilizator și legându-l de un anumit interval de conturi pentru verificare, am redus semnificativ numărul de roluri din sistem. Ca rezultat, au rămas roluri doar pentru o singură filială, care au fost replicat pentru pozițiile corespunzătoare din toate celelalte unități teritoriale ale băncii.
Acum să discutăm despre pașii pregătitori necesari, fără de care pur și simplu nu se poate construi un model de roluri funcțional.
Pasul 1. Creăm un model funcțional
Este important să începi cu crearea unui model funcțional – un document de nivel înalt în care este descris în detaliu funcționalitatea fiecărei subdiviziuni și a fiecărei funcții. De obicei, informațiile ajung aici din diferite documente: fișe de post și reglementări pentru subdiviziuni – departamente, birouri, direcții. Modelul funcțional trebuie să fie convenit cu toate subdiviziunile implicate (afaceri, control intern, securitate) și aprobat de conducerea companiei. De ce este necesar acest document? Pentru ca modelul de rol să poată face referire la el. De exemplu, dacă intenționezi să construiești un model de rol bazat pe drepturile existente ale angajaților – extrase din sistem și „uniformizate”. Atunci, la aprobarea rolurilor obținute cu proprietarul de afaceri al sistemului, poți face referire la un anumit punct din modelul funcțional, pe baza căruia se include un anumit drept în rol.
Pasul 2. Audităm sistemele IT și elaborăm un plan de prioritizare
În a doua etapă, trebuie să realizăm un audit al sistemelor IT pentru a înțelege cum este organizat accesul în acestea. De exemplu, în compania mea financiară, erau operate câteva sute de sisteme informaționale. În toate sistemele existau anumite începuturi de management al rolurilor, în majoritate – unele roluri, dar în principal pe hârtie sau în manualul sistemului – acestea erau deja depășite, iar accesul era acordat pe baza solicitărilor reale ale utilizatorilor. Evident, construirea unui model de rol imediat în câteva sute de sisteme este pur și simplu imposibilă, trebuie să începem de undeva. Am efectuat o analiză detaliată a procesului de management al accesului pentru a determina nivelul său de maturitate. În timpul analizei am dezvoltat criterii de prioritizare a sistemelor informaționale – criticitate, pregătire, planuri de decomisionare etc. Cu ajutorul acestora am stabilit ordinea de dezvoltare/actualizare a modelelor de rol pentru aceste sisteme. Apoi – le-am inclus în planul de integrare cu soluția de Management al Identității, pentru a automatiza managementul accesului.
Deci, cum putem determina criticitatea unui sistem? Răspundeți-vă la următoarele întrebări:
- Este sistemul legat de procesele operaționale de care depinde activitatea principală a companiei?
- Va afecta o deteriorare a funcționării sistemului integritatea activelor companiei?
- Care este timpul maxim de nefuncționare a sistemului, după atingerea căruia nu mai este posibilă reluarea activității?
- Poate o încălcare a integrității informațiilor din sistem să conducă la consecințe ireversibile, atât financiare, cât și de reputație?
- Criticitatea față de fraudă. Existența unei funcționalități care, în lipsa unui control suficient, poate permite desfășurarea de activități frauduloase interne/externe;
- Care sunt cerințele legislației, precum și regulile și procedurile interne pentru aceste sisteme? Vor exista sancțiuni din partea organelor de reglementare pentru nerespectare?
În compania noastră financiară am efectuat un audit în acest sens. Conducerea a elaborat o procedură de audit a Revizuirii Drepturilor de Acces pentru a analiza utilizatorii existenți și drepturile acestora, mai întâi în acele sisteme informaționale care au fost incluse pe lista priorităților. Responsabila pentru acest proces a fost desemnată unitatea de securitate. Însă, pentru a obține o imagine completă a drepturilor de acces din companie, era necesar să implicăm în proces unitățile IT și de afaceri. Și aici au început disputele, neînțelegerile, iar uneori chiar saboții: nimeni nu dorește să se desprindă de sarcinile curente și să se implice în activități, care, la prima vedere, par neclare.
N.B. Companiile mari cu procese IT bine dezvoltate sunt cu siguranță familiarizate cu procedura de audit IT – controalele generale IT (ITGC), care permit identificarea deficiențelor în procesele IT și stabilirea unui control astfel încât să îmbunătățească procesele conform celor mai bune practici (ITIL, COBIT, IT Governance etc.). Acest audit permite IT-ului și afacerii să se înțeleagă mai bine și să dezvolte o strategie comună de dezvoltare, să analizeze riscurile, să optimizeze costurile și să elaboreze abordări mai eficiente în activitate.
Unul dintre domeniile auditului este determinarea parametrilor de acces logic și fizic la sistemele informaționale. Informațiile obținute au stat la baza utilizării ulterioare pentru construirea modelului de roluri. Ca rezultat al acestui audit, am realizat un registru al sistemelor IT, în care au fost definite parametrii tehnici și oferite descrieri. În plus, pentru fiecare sistem a fost stabilit un proprietar din direcția de business, în interesul căruia acesta era exploatat: anume el era responsabil pentru procesele de business pe care acest sistem le susținea. De asemenea, a fost numit un manager al serviciului IT, responsabil de implementarea tehnică a nevoilor de business într-un anumit sistem informațional. Au fost înregistrate cele mai critice sisteme pentru companie și parametrii lor tehnici, termenele de introducere și retragere din exploatare etc. Acești parametri au fost de mare ajutor în procesul de pregătire pentru construirea modelului de roluri.
Pasul 3 Creăm metodologia
Cheia succesului oricărei acțiuni este metoda bine aleasă. De aceea, atât pentru construirea modelului de roluri, cât și pentru desfășurarea auditului, trebuie să creăm o metodologie în care vom descrie interacțiunile între departamente, vom stabiliza responsabilitățile în reglementările companiei etc.
Pentru început, trebuie să cercetăm toate documentele existente care stabilesc ordinea de acordare a accesului și drepturilor. Ideal, procesele ar trebui să fie documentate la mai multe niveluri:
- cerințele corporative generale;
- cerințele pentru domeniile de securitate informatică (depind de direcțiile de activitate ale organizației);
- cerințele pentru procesele tehnologice (instrucțiuni, matrici de acces, indicații metodologice, cerințe de configurare).
În compania noastră financiară, am descoperit multe documente învechite – a fost necesar să le aducem în conformitate cu noile procese implementate.
La cererea conducerii, a fost creat un grup de lucru, care include reprezentanți din domeniile securitate, IT, afaceri și control intern. În cerere au fost definite obiectivele creării grupului, direcția activității, durata existenței și responsabilii din fiecare parte. De asemenea, am dezvoltat o metodologie pentru realizarea auditului și un mod de a construi modelul de rol: acestea au fost aprobate de toți reprezentanții responsabili ai direcțiilor și confirmate de conducerea companiei.
Documentele care descriu procedura de desfășurare a lucrărilor, termenii, responsabilitatea etc. sunt garanția că, pe drumul către obiectivul dorit, care la început nu este evident pentru toată lumea, nimeni nu va avea întrebări de tipul „de ce facem asta, de ce ne este necesar și așa mai departe” și nu va exista posibilitatea de a „sări” sau de a încetini procesul.
Pasul 4. Fixăm parametrii modelului existent de gestionare a accesului
Compunem așa-numitul „pașaport al sistemului” în ceea ce privește gestionarea accesului. Practic, acesta este un chestionar referitor la un sistem informațional specific, în care sunt înregistrate toate algoritmii de gestionare a accesului. Companiile care au implementat deja soluții de tip IdM sunt cu siguranță familiarizate cu un astfel de chestionar, deoarece de aici începe cercetarea sistemelor.
O parte a parametrilor despre sistem și proprietarii au fost preluate în chestionar din registrul IT (vezi pasul 2, audit), dar au fost adăugate și noi:
- cum se realizează gestionarea conturilor (direct în baza de date sau prin intermediul interfețelor de programare);
- cum se conectează utilizatorii la sistem (folosind un cont separat sau utilizând un cont AD, LDAP sau altul);
- ce niveluri de acces la sistem sunt utilizate (nivel de aplicație, nivel sistem, utilizarea resurselor de fișiere în rețea de către sistem);
- descriere și parametrii servere, pe care funcționează sistemul;
- ce operațiuni de gestionare a conturilor sunt acceptate (blocare, redenumire etc.);
- pe baza căror algoritmi sau reguli este generat identificatorul utilizatorului sistemului;
- pe baza cărui atribut se poate stabili o legătură cu înregistrarea angajatului în sistemul de resurse umane (Nume, prenume, numărul de identificare sau altceva);
- toate atributele posibile ale contului și regulile de completare a acestora;
- ce drepturi de acces există în sistem (roluri, grupuri, drepturi atomice etc., dacă există drepturi încrucișate sau ierarhie);
- mecanismele de separare a drepturilor de acces (pe funcții, subunități, funcționalitate etc.);
- există în sistem reguli de delimitare a drepturilor (SOD – Segregation of Duties) și cum funcționează acestea;
- cum sunt prelucrate în sistem evenimentele de absență, transfer, concediere, actualizare a datelor despre angajați etc.
Acest listă poate continua cu detalii pe diferite parametri și alte obiecte implicate în procesul de gestionare a accesului.
Pasul 5. Creăm o descriere orientată spre afaceri a atribuțiilor
Un alt document de care avem nevoie pentru construirea modelului de roluri este un ghid al tuturor atribuțiilor posibile (drepturilor) care pot fi acordate utilizatorilor în sistemul informațional, cu o descriere detaliată a funcției de afaceri care stă în spatele acestora. Deseori, atribuțiile din sistem sunt criptate prin denumiri specifice, compuse din litere și cifre, iar angajații din afaceri nu pot înțelege ce se ascunde în spatele acestor simboluri. Apoi, aceștia se îndreaptă către serviciul IT, iar acolo… de asemenea, nu pot răspunde la întrebări, de exemplu, despre drepturi rar utilizate. Atunci este necesar să se efectueze teste suplimentare.
Este bine dacă descrierea de afaceri există deja sau chiar există o combinație a acestor drepturi în grupuri și roluri. Pentru unele aplicații, cea mai bună practică este crearea unui astfel de ghid încă din faza de dezvoltare. Dar acest lucru se întâmplă rar, așa că din nou ne îndreptăm către departamentul IT pentru a aduna informații despre toate drepturile posibile și a le descrie. Ghidul nostru va conține, în cele din urmă, următoarele:
- denumirea atribuției, inclusiv obiectul la care se aplică dreptul de acces;
- acțiunea care este permisă să fie efectuată asupra obiectului (vizualizare, modificare etc., cu posibilitatea de restricții, de exemplu, pe baza teritorială sau a grupului de clienți);
- codul atribuției (codul și numele funcției/sarcinii sistemului care pot fi executate folosind atribuția);
- descrierea atribuției (o descriere detaliată a acțiunilor în SI atunci când se aplică atribuția și consecințele acesteia pentru proces;
- starea atribuției: „Activ” (dacă atribuția este acordată cel puțin unui utilizator) sau „Inactiv” (dacă atribuția nu este utilizată).
Pasul 6 Extragem date despre utilizatori și drepturi din sisteme și le corelăm cu sursa de personal
În etapa finală a pregătirii, este necesar să extragem datele din sistemele informaționale despre toți utilizatorii și drepturile pe care le au în prezent. Aici sunt posibile două scenarii. Primul: subdiviziunea de securitate are acces direct în sistem și are unelte pentru extragerea rapoartelor corespunzătoare, ceea ce nu se întâmplă adesea, dar este foarte convenabil. Al doilea: trimitem o cerere IT-ului pentru a obține rapoartele în formatul dorit. Practica arată: a negocia cu IT-ul și a obține datele necesare din prima nu reușește întotdeauna. Este nevoie de mai multe încercări până când informația este obținută în forma și formatul dorite.
Ce date trebuie extrase:
- Denumirea contului
- Numele complet al angajatului asociat
- Starea (activ sau blocat)
- Data creării contului
- Data ultimei utilizări
- Lista drepturilor/grupurilor/rolurilor disponibile
Așadar, am obținut extragerile din sistem cu toți utilizatorii și cu toate drepturile care le sunt oferite. Și imediat am lăsat deoparte toate conturile blocate, deoarece munca de construire a modelului rolurilor se va desfășura doar cu utilizatorii activi.
Apoi, dacă în compania dumneavoastră nu există unelte automatizate pentru restricționarea accesului angajaților concediați (ceea ce este frecvent întâlnit) sau există o automatizare fragmentată, care nu funcționează întotdeauna corect, trebuie să identificăm toate "sufletele moarte". Este vorba despre conturile angajaților deja concediați, a căror drepturi nu au fost blocate din anumite motive – acestea trebuie blocate. Pentru aceasta, comparăm datele extrase cu sursa de resurse umane. Extracția resurselor umane trebuie, de asemenea, obținută în prealabil de la subdiviziunea care gestionează baza de date a resurselor umane.
Este important să rezervăm conturile pentru care nu s-au găsit deținători în baza de date a personalului, adică cele nesupravegheate. Pentru aceasta, va fi necesară data ultimei utilizări: dacă este relativ recentă, va fi totuși nevoie să căutăm deținătorii. Acestea pot include conturi ale subcontractanților externi sau conturi de serviciu, care nu sunt legate de nimeni, dar sunt asociate cu anumite procese. Pentru a determina apartenența conturilor, putem trimite emailuri la toate departamentele cu rugămintea de a răspunde. Când se găsesc deținătorii, introducem datele lor în sistem: astfel, toate conturile active sunt identificate, iar celelalte sunt blocate.
Odată ce exporturile noastre sunt curățate de înregistrările inutile și rămân doar conturi active, putem începe construcția modelului de roluri pentru un sistem informațional specific. Dar despre asta voi vorbi în articolul următor.
Autor: Liudmila Sevastyanova, manager de promovare Solar inRights
Sursa: habr.com
