Attualmente travagliu per un venditore di software, in particulare e soluzioni di cuntrollu di accessu. È a mo sperienza "da una vita passata" hè cunnessu cù u latu di u cliente - una grande urganizazione finanziaria. À quellu tempu, u nostru gruppu di cuntrollu di l'accessu in u dipartimentu di sicurità di l'infurmazioni ùn pudia micca vantà di grandi cumpetenze in IdM. Avemu amparatu assai in u prucessu, avemu avutu à chjappà assai bumps per custruisce un mecanismu di travagliu per a gestione di i diritti di l'utilizatori in i sistemi d'infurmazione in a cumpagnia.
Cumminendu a mo sperienza di u cliente duramente guadagnata cù a cunniscenza è e cumpetenze di u venditore, vogliu sparte cun voi essenzialmente istruzioni passo-passo: cumu creà un mudellu di cuntrollu d'accessu basatu nantu à u rolu in una grande cumpagnia, è ciò chì questu darà in u risultatu. . I mo struzzioni sò custituiti da duie parte: a prima hè pronta per custruisce u mudellu, a seconda hè in realtà custruita. Eccu a prima parte, a parti preparatoria.
NB Custruì un mudellu di rolu hè, sfurtunatamenti, micca un risultatu, ma un prucessu. O piuttostu, ancu parte di u prucessu di creà un ecosistema di cuntrollu di accessu in a cumpagnia. Allora preparate per u ghjocu per un bellu pezzu.
Prima, definiscemu - chì hè u cuntrollu di l'accessu basatu in u rolu? Supponete chì avete un grande bancu cù decine, o ancu centinaie di millaie di impiegati (entità), ognunu di quale hà decine di diritti d'accessu à centinaie di sistemi d'infurmazione bancaria interna (oggetti). Avà multiplicate u nùmeru d'uggetti da u nùmeru di sughjetti - questu hè u numeru minimu di cunnessione chì avete bisognu di prima custruisce è poi cuntrullà. Hè veramente pussibule di fà questu manualmente? Di sicuru micca - rolli sò stati creati per risolve stu prublema.
Un rolu hè un inseme di permessi chì un utilizatore o un gruppu d'utilizatori hà bisognu à fà certi travaglii di travagliu. Ogni impiigatu pò avè unu o più roli, è ogni rolu pò cuntene da unu à parechji permessi chì sò permessi à l'utilizatore in quellu rolu. I roli ponu esse ligati à pusizioni specifiche, dipartimenti o funzioni funziunali di l'impiegati.
I roli sò generalmente creati da l'autorizazioni individuali di l'impiegati in ogni sistema d'infurmazione. Allora i roli di l'affari globale sò furmati da i roli di ogni sistema. Per esempiu, u rolu di l'affari "manager di creditu" includerà parechji roli separati in i sistemi d'infurmazioni chì sò usati in l'uffiziu di u cliente di u bancu. Per esempiu, cum'è u sistema bancariu automatizatu principale, u modulu di cassa, u sistema di gestione di documenti elettronicu, u gestore di serviziu è altri. I roli di l'affari, in regula, sò ligati à a struttura urganisazione - in altri palori, à l'inseme di divisioni di l'impresa è pusizioni in elli. Hè cusì chì una matrice di rolu globale hè furmata (daghju un esempiu in a tabella sottu).
Hè da nutà chì hè simplicemente impussibile di custruisce un mudellu di rolu 100%, chì furnisce tutti i diritti necessarii per l'impiegati di ogni postu in una struttura cummerciale. Iè, questu ùn hè micca necessariu. Dopu tuttu, un mudellu di rolu ùn pò esse staticu, perchè dipende di un ambiente in constantemente cambiante. È da i cambiamenti in l'attività cummerciale di a cumpagnia, chì, per quessa, affetta cambiamenti in a struttura urganisazione è funziunalità. È da a mancanza di piena di risorsi, è da a manca di rispettu di e descrizzioni di u travagliu, è da u desideriu di prufittu à a spesa di salvezza, è da parechji altri fattori. Per quessa, hè necessariu di custruisce un mudellu di rolu chì pò copre finu à u 80% di i bisogni di l'utilizatori per i diritti basi necessarii quandu sò assignati à una pusizione. È ponu, se ne necessariu, dumandà u 20% restante più tardi nantu à applicazioni separati.
Di sicuru, pudete dumandà: "Ùn ci hè micca tali mudelli 100%?" Ebbè, perchè, questu succede, per esempiu, in strutture senza prufittu chì ùn sò micca sottumessi à cambiamenti frequenti - in certi istituti di ricerca. O in urganisazioni cumplessi militari-industriali cù un altu livellu di sicurità, induve a sicurità hè prima. Succece in una struttura cummerciale, ma in u quadru di una divisione separata, u travagliu di quale hè un prucessu abbastanza staticu è previsible.
U vantaghju principalu di a gestione basata nantu à u rolu hè a simplificazione di l'emissione di diritti, perchè u numeru di roli hè significativamente menu di u numeru di l'utilizatori di u sistema d'infurmazione. È questu hè veru per ogni industria.
Pigliemu una cumpagnia di vendita: impiega millaie di venditori, ma anu u listessu settore di diritti in u sistema N, è solu un rolu serà creatu per elli. Quandu un novu venditore vene à a cumpagnia, hè automaticamente assignatu u rolu necessariu in u sistema, chì hà digià tutte l'autorità necessarie. Inoltre, in un clic pudete cambià i diritti per millaie di venditori à una volta, per esempiu, aghjunghje una nova opzione per generà un rapportu. Ùn ci hè bisognu di fà mille operazioni, liendu un novu dirittu à ogni contu - basta aghjunghje sta opzione à u rolu, è appariscerà per tutti i venditori à u stessu tempu.
Un altru vantaghju di a gestione basata in u rolu hè l'eliminazione di l'emissione di autorizazioni incompatibili. Questu hè, un impiigatu chì hà un certu rolu in u sistema ùn pò micca simultaneamente un altru rolu, i diritti di quale ùn deve esse cumminatu cù i diritti in u primu. Un esempiu impressiunanti hè a pruibizione di cumminà e funzioni di input è cuntrollu di una transazzione finanziaria.
Qualchissia chì hè interessatu à cumu u cuntrollu di l'accessu basatu in u rolu hè ghjuntu à esse pò
immerse in a storia
Se guardemu à a storia, a cumunità IT hà pensatu prima à i metudi di cuntrollu di l'accessu in l'anni 70 di u XXu seculu. Ancu l'applicazioni eranu abbastanza simplici allora, cum'è avà, tutti vulianu veramente gestisce l'accessu à elli. Concede, cambia è cuntrullà i diritti di l'utilizatori - solu per fà più faciule per capiscenu quale accessu à ognunu di elli. Ma à quellu tempu ùn ci era micca standard cumuni, i primi sistemi di cuntrollu d'accessu sò stati sviluppati, è ogni cumpagnia era basatu annantu à e so idee è regule.
Parechji mudelli di cuntrollu d'accessu sò oghji cunnisciuti, ma ùn anu micca apparsu immediatamente. Fighjemu nantu à quelli chì anu fattu una cuntribuzione significativa à u sviluppu di sta zona.
U primu è probabilmente u mudellu più simplice hè Cuntrolla d'accessu discretionary (selettiva). (DAC - Cuntrollu d'accessu discretionary). Stu mudellu implica a spartera di diritti da tutti i participanti in u prucessu di accessu. Ogni utilizatore hà accessu à ughjetti o operazioni specifichi. In essenza, quì u settore di sughjetti di diritti currisponde à l'inseme di l'uggetti. Stu mudellu hè statu trovu troppu flexibule è troppu difficiuli di mantene: listi d'accessu eventualmente diventanu enormi è difficili di cuntrullà.
U sicondu mudellu hè U cuntrollu di l'accessu obligatoriu (MAC - Cuntrolu di l'accessu obligatoriu). Sicondu stu mudellu, ogni utilizatore riceve accessu à un ughjettu in cunfurmità cù l'accessu emessu à un livellu particulari di cunfidenziale di dati. Per quessa, l'uggetti deve esse categurizatu secondu u so livellu di cunfidenziale. A cuntrariu di u primu mudellu flexibule, questu, à u cuntrariu, risultava troppu strettu è restrittivu. U so usu ùn hè micca ghjustificatu quandu a cumpagnia hà assai risorse d'infurmazioni diffirenti: per diferenzià l'accessu à e diverse risorse, avete da intruduce parechje categurie chì ùn si sovrapponenu micca.
A causa di l'imperfezioni evidenti di sti dui metudi, a cumunità IT hà cuntinuatu à sviluppà mudelli più flessibili è à u stessu tempu più o menu universale per sustene diversi tipi di pulitiche di cuntrollu di l'accessu urganisazione. È dopu apparsu u terzu mudellu di cuntrollu d'accessu basatu in rolu! Stu approcciu hà pruvatu à esse u più prumessu perchè ùn deve micca solu l'autorizazione di l'identità di l'utilizatore, ma ancu e so funzioni operative in i sistemi.
A prima struttura di mudellu di rolu chjaramente descritta hè stata pruposta da i scientisti americani David Ferrailo è Richard Kuhn da l'Istitutu Naziunale di Standards è Tecnulugia di i Stati Uniti in 1992. Allora u terminu prima apparsu RBAC (Controllu d'accessu basatu à u rolu). Sti studii è discrizzioni di i cumpunenti principali, oltri a so rilazioni, furmò a basa di u standard INCITS 359-2012, chì hè sempre in vigore oghje, appruvatu da u Cumitatu Internaziunale di Norme di Tecnulugia di l'Informazione (INCITS).
U standard definisce un rolu cum'è "una funzione di travagliu in u cuntestu di una urganizazione cù una certa semantica assuciata in quantu à l'autorità è a rispunsabilità assignata à l'utilizatore assignatu à u rolu". U documentu stabilisce l'elementi basi di RBAC - utilizatori, sessioni, roli, permessi, operazioni è oggetti, è ancu e relazioni è interconnessioni trà elli.
U standard furnisce a struttura minima necessaria per custruisce un mudellu di rolu - cumminendu diritti in roli è poi cuncede l'accessu à l'utilizatori attraversu questi roli. I meccanismi per cumpone roli da l'uggetti è l'operazioni sò delineati, a ghjerarchia di roli è l'eredi di putenzi sò descritte. Dopu tuttu, in ogni cumpagnia, ci sò roles chì combina i puteri basi chì sò necessarii per tutti l'impiegati di a cumpagnia. Questu puderia esse accessu à e-mail, EDMS, portale corporativu, etc. Questi permessi ponu esse inclusi in un rolu generale chjamatu "impiegatu", è ùn ci sarà micca bisognu di listà tutti i diritti basi una volta è una volta in ogni rolu di livellu più altu. Hè abbastanza per indicà a caratteristica di l'eredità di u rolu di "impiegatu".
In seguitu, u standard hè stata cumplementata cù novi attributi d'accessu ligati à l'ambienti chì cambianu constantemente. A capacità d'introduce restrizioni statiche è dinamiche hè stata aghjunta. I statichi implicanu l'impossibilità di cumminà roli (u stessu input è cuntrollu di l'operazioni citati sopra). E restrizioni dinamiche ponu esse determinate cambiendu i paràmetri, per esempiu, u tempu (ore di travagliu / micca di travagliu o ghjorni), locu (uffiziu / casa), etc.
Vale a pena menzionatu separatamente cuntrollu d'accessu basatu in attributi (ABAC - cuntrollu di accessu basatu in attributi). L'approcciu hè basatu annantu à cuncede l'accessu cù e regule di spartera di l'attributi. Stu mudellu pò esse usatu separatamente, ma abbastanza spessu cumplementa attivamente u mudellu di rolu classicu: attributi di l'utilizatori, risorse è dispusitivi, è ancu tempu o locu, ponu esse aghjuntu à un certu rolu. Questu permette di utilizà menu roli, introduci restrizioni supplementari è rende l'accessu u più minimu pussibule, è dunque migliurà a sicurità.
Per esempiu, un accountant pò esse permessu di accede à i cunti s'ellu travaglia in una certa regione. Allora u locu di u specialista serà paragunatu cù un certu valore di riferimentu. O pudete dà accessu à i cunti solu se l'utilizatore accede da un dispositivu inclusu in a lista di quelli permessi. Un bonu aghjuntu à un mudellu di rolu, ma raramente utilizatu per sè stessu per a necessità di creà parechje regule è tavule di permessi o restrizioni.
Lasciami dà un esempiu di usu ABAC da a mo "vita passata". A nostra banca avia parechje filiali. L'impiegati di l'uffizii di i clienti in questi rami anu realizatu esattamente e stesse operazioni, ma avianu da travaglià in u sistema principale solu cù cunti in a so regione. Prima, avemu cuminciatu à creà roli separati per ogni regione - è ci era tanti roli tali cù funziunalità ripetiri, ma cù accessu à diversi cunti! Dopu, utilizendu un attributu di locu per l'utilizatore è associendulu cù una gamma specifica di cunti per rivisione, avemu riduciutu significativamente u numeru di roli in u sistema. In u risultatu, i roli sò stati per una sola filiera, chì sò stati replicati per i posti currispundenti in tutti l'altri divisioni territuriali di u bancu.
Avà parlemu di i passi preparatori necessarii, senza quale hè simplicemente impussibile di custruisce un mudellu di travagliu.
Step 1. Crea un mudellu funziunali
Avete da principià per creà un mudellu funziunale - un documentu di primu livellu chì descrive in dettaglio a funziunalità di ogni dipartimentu è ogni pusizioni. Comu regula, l'infurmazione entra da parechji documenti: descrizzioni di u travagliu è regulamenti per unità individuali - dipartimenti, divisioni, dipartimenti. U mudellu funziunale deve esse accunsentutu cù tutti i dipartimenti interessati (affari, cuntrollu internu, sicurità) è appruvatu da a gestione di a cumpagnia. A cosa serve stu documentu ? Cusì chì u mudellu di rolu pò riferisce à questu. Per esempiu, avete da custruisce un mudellu di rolu basatu annantu à i diritti esistenti di l'impiegati - scaricatu da u sistema è "riduciutu à un denominatore cumunu". Allora, quandu accunsenu nantu à i roles ricivuti cù u pruprietariu di l'affari di u sistema, pudete riferite à un puntu specificu in u mudellu funziunale, nantu à a basa di quale questu o quellu dirittu hè inclusu in u rolu.
Passu 2. Auditemu i sistemi IT è scrivite un pianu di priorità
À a seconda tappa, duvete fà un auditu di i sistemi IT per capisce cumu l'accessu à elli hè urganizatu. Per esempiu, a mo cumpagnia finanziaria operava parechji centu di sistemi d'infurmazione. Tutti i sistemi avianu qualchi rudimenti di gestione basata nantu à u rolu, a maiò parte avianu qualchi roli, ma soprattuttu nantu à carta o in u cartulare di u sistema - eranu longu obsoleti, è l'accessu à elli hè statu cuncessu basatu nantu à e dumande di l'utilizatori reali. Naturalmente, hè simplicemente impussibile di custruisce un mudellu di rolu in parechje centinaie di sistemi à una volta; avete da principià in qualchì locu. Avemu fattu un analisi approfonditu di u prucessu di cuntrollu di accessu per determinà u so livellu di maturità. Durante u prucessu di analisi, i criterii per a prioritizazione di i sistemi d'informazioni sò stati sviluppati - criticità, prontezza, piani di decommissioning, etc. Cù u so aiutu, avemu allineatu u sviluppu / aghjurnamentu di mudelli di rolu per questi sistemi. E dopu avemu inclusu mudelli di rolu in u pianu di integrazione cù a suluzione di Gestione di l'identità per automatizà u cuntrollu di l'accessu.
Allora cumu si determina a criticità di un sistema? Rispondi à e seguenti dumande:
- Hè u sistema ligatu à i prucessi operativi da quale dipendenu l'attività core di a cumpagnia ?
- A disrupzione di u sistema affetterà l'integrità di l'assi di a cumpagnia?
- Chì ghjè u tempu d'inattività massimu permissibile di u sistema, ghjunghje à quale hè impussibile di restaurà l'attività dopu una interruzzione?
- Una violazione di l'integrità di l'infurmazioni in u sistema pò purtà à cunsequenze irreversibili, finanziarii è di reputazione?
- Criticità à u fraud. A prisenza di funziunalità, s'ellu ùn hè micca cuntrullata bè, pò purtà à azzione fraudulenta interna / esterna;
- Chì sò i requisiti legali è e regule internu è e prucedure per questi sistemi? Ci saranu ammende da i regulatori per incunformità ?
In a nostra cumpagnia finanziaria, avemu realizatu un auditu cum'è questu. A gestione hà sviluppatu a prucedura di verificazione di l'Access Rights Review per vede l'utilizatori esistenti è i diritti prima in quelli sistemi d'infurmazione chì eranu in a lista di priorità più alta. U dipartimentu di sicurità hè statu assignatu cum'è u pruprietariu di stu prucessu. Ma per avè una stampa cumpleta di i diritti d'accessu in a cumpagnia, era necessariu di participà à i dipartimenti IT è cummerciale in u prucessu. E quì i disputi, i malintesi, è qualchì volta ancu i sabotaggi cuminciaru: nimu ùn vole sguassate da e so rispunsabilità attuale è s'impegna in certi, à u primu sguardu, attività incomprensibili.
NB Grandi cumpagnie cù prucessi IT sviluppati sò prubabilmente familiarizati cù a prucedura di auditu IT - cuntrolli generali IT (ITGC), chì vi permette di identificà carenze in i prucessi IT è stabilisce u cuntrollu in modu à migliurà i prucessi in cunfurmità cù e migliori pratiche (ITIL, COBIT, IT). Governance etc.) Un tali auditu permette à l'IT è l'affari di capiscenu megliu l'un l'altru è di sviluppà una strategia di sviluppu cumuna, analizà i risichi, ottimisate i costi, è sviluppà approcci più efficaci à u travagliu.
Una di e zone di l'auditu hè di determinà i paràmetri di l'accessu logicu è fisicu à i sistemi d'infurmazione. Avemu pigliatu i dati ottenuti cum'è una basa per un usu più in a custruzzione di un mudellu di rolu. In u risultatu di questu auditu, avemu avutu un registru di sistemi IT, in quale i so paràmetri tecnichi sò stati determinati è e descrizzioni sò datu. Inoltre, per ogni sistema, un pruprietariu hè statu identificatu da a direzzione di l'affari in i so interessi hè stata operata: era ellu chì era rispunsevuli di i prucessi di l'affari chì stu sistema serve. Hè statu ancu numinatu un capu di serviziu IT, rispunsevule per l'implementazione tecnica di i bisogni di l'affari per un IS specificu. I sistemi più critichi per a cumpagnia è i so paràmetri tecnichi, i termini di cummissione è disattivazione, ecc.. Questi paràmetri eranu assai utili in u prucessu di preparazione per a creazione di un mudellu di rolu.
Step 3 Crea una metodulugia
A chjave per u successu di ogni attività hè u metudu ghjustu. Dunque, sia per custruisce un mudellu di rolu sia per fà un auditu, avemu bisognu di creà una metodulugia in quale discrimu l'interazzione trà i dipartimenti, stabilisce a rispunsabilità in i regulamenti di a cumpagnia, etc.
Prima avete bisognu di esaminà tutti i ducumenti dispunibili chì stabiliscenu a prucedura per cuncede l'accessu è i diritti. In un bonu modu, i prucessi deve esse documentatu à parechji livelli:
- esigenze generale di l'impresa;
- esigenze per i spazii di sicurità di l'infurmazioni (secondu l'area di l'attività di l'urganizazione);
- esigenze per i prucessi tecnologichi (istruzzioni, matrici di accessu, linee guida, esigenze di cunfigurazione).
In a nostra sucietà finanziaria, avemu trovu assai ducumenti obsoleti; avemu avutu à purtàlli in cunfurmità cù i novi prucessi chì sò implementati.
Per ordine di gestione, hè statu creatu un gruppu di travagliu, chì includeva rapprisentanti di sicurità, IT, cummerciale è cuntrollu internu. L'ordine delinea i scopi di creà u gruppu, a direzzione di l'attività, u periodu di esistenza è i rispunsevuli di ogni parte. Inoltre, avemu sviluppatu una metodulugia di auditu è una prucedura per a custruzzione di un mudellu di rolu: sò stati accunsentiti da tutti i rapprisentanti rispunsevuli di e zone è appruvati da a gestione di a cumpagnia.
Documenti chì descrizanu a prucedura per a realizazione di u travagliu, i termini, e rispunsabilità, etc. - una guaranzia chì nantu à a strada di u scopu affettatu, chì in prima ùn hè micca ovvi à tutti, nimu ùn averà dumande "perchè facemu questu, perchè avemu bisognu, etc.". è ùn ci sarà micca l'uppurtunità di "saltà" o rallentà u prucessu.
Step 4. Fix i paràmetri di u mudellu di cuntrollu di accessu esistenti
Elaboremu un cusì chjamatu "passaportu di sistema" in quantu à u cuntrollu di l'accessu. In essenza, questu hè un questionnaire nantu à un sistema d'informazione specificu, chì registra tutti l'algoritmi per cuntrullà l'accessu à questu. L'imprese chì anu digià implementatu suluzioni di classi IdM sò prubabilmente familiarizati cù un tali questionnaire, postu chì hè quì chì principia u studiu di i sistemi.
Certi paràmetri nantu à u sistema è i pruprietarii scorri in u questionnaire da u registru IT (vede u passu 2, auditu), ma sò stati ancu aghjunti novi:
- cumu i cunti sò amministrati (direttamenti in a basa di dati o per interfacce di software);
- cumu l'utilizatori accede à u sistema (aduprendu un contu separatu o utilizendu un contu AD, LDAP, etc.);
- chì livelli di accessu à u sistema sò usati (livellu di applicazione, livellu di sistema, usu di u sistema di risorse di file di rete);
- a descrizzione è i paràmetri di i servitori nantu à quale u sistema funziona;
- quali operazioni di gestione di u contu sò supportati (bloccamentu, rinominazione, etc.);
- quali algoritmi o regule sò usati per generà l'identificatore di l'utilizatori di u sistema;
- chì attributu pò esse usatu per stabilisce una cunnessione cù u registru di l'impiigatu in u sistema di u persunale (nome cumpletu, numeru di persunale, etc.);
- tutti i pussibuli attributi di u contu è e regule per u cumpletu;
- quali diritti d'accessu esistenu in u sistema (ruoli, gruppi, diritti atomichi, etc., ci sò diritti nidificati o gerarchici);
- meccanismi per sparghje i diritti d'accessu (per postu, dipartimentu, funziunalità, etc.);
- U sistema hà regule per a segregazione di diritti (SOD - Segregazione di Duties), è cumu si travaglianu;
- cumu l'avvenimenti di assenza, trasferimentu, licenziamentu, aghjurnamentu di dati di l'impiegati, etc. sò processati in u sistema.
Questa lista pò esse cuntinuata, detallendu i diversi paràmetri è altri ogetti chì sò implicati in u prucessu di cuntrollu di accessu.
Passu 5. Crià una discrizzione orientata à l'affari di permessi
Un altru documentu chì avemu bisognu quandu custruisce un mudellu di rolu hè un libru di riferimentu nantu à tutti i puderi pussibuli (diritti) chì ponu esse cuncessi à l'utilizatori in u sistema d'infurmazione cù una descrizzione dettagliata di a funzione cummerciale chì si trova daretu. Spessu, l'autorità in u sistema sò criptate cù certi nomi custituiti da lettere è numeri, è l'impiegati di l'affari ùn ponu micca capisce ciò chì si trova daretu à sti simboli. Allora vanu à u serviziu di l'informatica, è quì ... ùn ponu ancu risponde à a quistione, per esempiu, nantu à i diritti raramente utilizati. Dopu un test supplementu deve esse fattu.
Hè bonu s'ellu ci hè digià una descrizzione cummerciale o ancu s'ellu ci hè una cumminazione di sti diritti in gruppi è roli. Per qualchi appiicazioni, a megghiu pratica hè di creà un tali riferenza in u stadiu di sviluppu. Ma questu ùn succede micca spessu, cusì andemu di novu à u dipartimentu di l'informatica per cullà l'infurmazioni nantu à tutti i diritti pussibuli è discrive. A nostra guida in fine cuntene i seguenti:
- nome di l'autorità, cumpresu l'ughjettu à quale hè applicatu u dirittu d'accessu;
- una azzione chì hè permessa di fà cù un ughjettu (visualizazione, cambià, etc., a pussibilità di restrizzioni, per esempiu, per basa territuriale o per gruppu di clienti);
- codice d'autorizazione (codice è nome di a funzione / dumanda di u sistema chì pò esse eseguita cù l'autorizazione);
- descrizzione di l'autorità (descrizzione dettagliata di l'azzioni in l'IS quandu applicà l'autorità è e so cunsequenze per u prucessu);
- statutu di permessu: "Active" (se u permessu hè assignatu à almenu un utilizatore) o "Non attivu" (se u permessu ùn hè micca usatu).
Passu 6 Scaricate e dati nantu à l'utilizatori è i diritti da i sistemi è paragunate cù a fonte di u persunale
In l'ultima tappa di a preparazione, avete bisognu di scaricà dati da i sistemi d'infurmazione nantu à tutti l'utilizatori è i diritti chì anu avà. Ci sò dui scenarii pussibuli quì. Prima: u dipartimentu di sicurità hà accessu direttu à u sistema è hà i mezi per scaricà rapporti pertinenti, chì ùn succede micca spessu, ma hè assai còmuda. Siconda: mandemu una dumanda à IT per riceve rapporti in u formatu necessariu. L'esperienza mostra chì ùn hè micca pussibule di ghjunghje à un accordu cù l'IT è uttene e dati necessarii a prima volta. Hè necessariu di fà parechji avvicinamenti finu à chì l'infurmazioni sò ricevuti in a forma è u formatu desiderate.
Chì dati deve esse scaricatu:
- Nome di u contu
- Nome cumpletu di l'impiigatu à quale hè assignatu
- Status (attivu o bluccatu)
- Data di creazione di u contu
- Data di l'ultimu usu
- Lista di diritti / gruppi / roli dispunibili
Cusì, avemu ricevutu scaricamentu da u sistema cù tutti l'utilizatori è tutti i diritti chì sò stati cuncessi. È immediatamente mettenu da parte tutti i cunti bluccati, postu chì u travagliu nantu à a custruzzione di un mudellu serà realizatu solu per l'utilizatori attivi.
Allora, se a vostra cumpagnia ùn hà micca un modu automatizatu per bluccà l'accessu à l'impiegati licenziati (questu succede spessu) o hà un automatizazione di patchwork chì ùn funziona micca sempre bè, avete bisognu di identificà tutte e "anime morte". Parlemu di i cunti di l'impiegati chì sò digià stati licenziati, chì i diritti ùn sò micca bluccati per una certa ragione - anu da esse bluccati. Per fà questu, paragunemu i dati caricati cù a fonte di u persunale. U scaricamentu di u persunale deve ancu esse acquistatu in anticipu da u dipartimentu chì mantene a basa di dati di u persunale.
Separatamente, hè necessariu di abbandunà i cunti chì i so patroni ùn sò micca stati truvati in a basa di dati di u persunale, micca assignati à nimu - vale à dì senza pruprietariu. Utilizendu sta lista, avemu bisognu di a data di l'ultimu usu: s'ellu hè abbastanza recente, avemu da circà i pruprietarii. Questu pò include cunti di cuntratturi esterni o cunti di serviziu chì ùn sò micca attribuiti à nimu, ma sò assuciati cù qualsiasi prucessi. Per sapè à quale appartenenu i cunti, pudete mandà lettere à tutti i dipartimenti per dumandà à risponde. Quandu i pruprietarii sò truvati, entremu dati nantu à elli in u sistema: in questu modu, tutti i cunti attivi sò identificati, è u restu hè bluccatu.
Appena i nostri caricamenti sò sguassati di registri innecessarii è restanu solu cunti attivi, pudemu cumincià à custruisce un mudellu di rolu per un sistema d'informazione specificu. Ma vi dicu nantu à questu in u prossimu articulu.
Autore: Lyudmila Sevastyanova, capu di prumuzione Solar inRights
Source: www.habr.com