Attualmente lavoro per un vendor di software, in particolare soluzioni per la gestione degli accessi. Il mio bagaglio di esperienze, nella mia ‘vita precedente’, proviene dalla parte cliente – una grande organizzazione finanziaria. All'epoca, il nostro team di controllo accessi nel dipartimento di sicurezza informatica non poteva vantare grandi competenze in IdM. Abbiamo imparato molto sul campo, affrontando anche molte difficoltà per costruire un meccanismo efficace di gestione dei diritti degli utenti nei sistemi informativi.
Unendo la mia esperienza maturata come cliente con le competenze e le conoscenze da vendor, desidero condividere con voi un’istruzione sostanzialmente passo-passo: come creare un modello di gestione degli accessi in una grande azienda e quali benefici questo porterà. La mia guida è divisa in due parti: la prima è la preparazione per costruire il modello, la seconda è la sua realizzazione. Davanti a voi c'è la prima parte, preparatoria.
N.B. Costruire un modello di ruolo è, purtroppo, un processo e non un risultato. Piuttosto, è una parte del processo di creazione di un ecosistema di gestione degli accessi all'interno dell'azienda. Quindi preparatevi a un gioco a lungo termine.
Iniziamo a chiarire: che cos'è la gestione degli accessi basata sui ruoli? Immaginate di avere una grande banca con decine, se non centinaia di migliaia di dipendenti (soggetti), ognuno dei quali ha dozzine di diritti di accesso a centinaia di sistemi informativi interni (oggetti). Ora moltiplicate il numero di oggetti per il numero di soggetti: ecco quante connessioni, almeno, dovete prima costruire e poi controllare. È possibile farlo manualmente? Certamente no: per risolvere questo problema sono state introduzioni i ruoli.
Il ruolo è un insieme di autorizzazioni necessarie per un utente o un gruppo di utenti per svolgere determinate attività lavorative. Ogni dipendente può avere uno o più ruoli e ogni ruolo può contenere da una a molte autorizzazioni concesse all'utente nell'ambito di quel ruolo. I ruoli possono essere legati a determinate posizioni, reparti o funzioni lavorative.
Le funzioni vengono solitamente create a partire dai singoli diritti di accesso degli impiegati in ogni sistema informativo. Successivamente, dalle funzioni di ciascun sistema si formano ruoli aziendali globali. Ad esempio, il ruolo aziendale di "manager dei prestiti" includerà diverse funzioni nei sistemi informativi utilizzati presso l'ufficio clienti della banca. Ad esempio, nei sistemi come il principale sistema bancario automatizzato, il modulo cassa, il sistema di gestione documentale elettronica, il service manager e altri. I ruoli aziendali sono generalmente legati alla struttura organizzativa – in altre parole, all'insieme delle unità aziendali e alle posizioni al loro interno. In questo modo si forma una matrice di ruoli globali (esempio fornito nella tabella sottostante).
È importante sottolineare che costruire un modello di ruolo al 100%, garantendo a ciascun dipendente in una struttura commerciale tutti i diritti necessari, è semplicemente impossibile. E non è neanche necessario. Un modello di ruolo non può essere statico, poiché dipende da un ambiente in continua evoluzione. Inoltre, il cambiamento nell'attività commerciale dell'azienda influisce sulla struttura organizzativa e sulle funzioni. Ci sono anche fattori come la mancanza di risorse opportunamente assegnate, il mancato rispetto delle procedure di lavoro, la ricerca del profitto a scapito della sicurezza e molti altri elementi. Pertanto, è necessario costruire un modello di ruolo in grado di soddisfare fino all'80% delle esigenze degli utenti in termini di diritti di base necessari per la posizione. I restanti 20% potranno essere richiesti separatamente in seguito, se necessario.
Certo, puoi chiedere: «Esistono davvero modelli di ruolo al 100%?» Beh, sì, si possono trovare in strutture non profit che non subiscono frequenti cambiamenti, come in un istituto di ricerca. Oppure in organizzazioni della difesa con un alto livello di sicurezza, dove la protezione è una priorità. A volte anche all'interno di strutture commerciali, ma in un'unità specifica, dove il lavoro è un processo abbastanza statico e prevedibile.
Il principale vantaggio della gestione per ruoli è la semplificazione dell'assegnazione dei diritti, poiché il numero di ruoli è significativamente inferiore al numero di utenti del sistema informatico. Questo vale per qualsiasi settore.
Prendiamo un'azienda di retail: in essa lavorano migliaia di venditori, ma il set di diritti nel sistema N è lo stesso per tutti, e per loro verrà creata un'unica ruolo. Quando un nuovo venditore entra in azienda, gli viene automaticamente assegnato il ruolo adeguato nel sistema, che già include tutte le autorizzazioni necessarie. Inoltre, con un solo clic, è possibile modificare i diritti per migliaia di venditori contemporaneamente, ad esempio, aggiungere una nuova opzione per la generazione di rapporti. Non è necessario eseguire mille operazioni, collegando il nuovo diritto a ciascun account: basta inserire questa opzione nel ruolo, e apparirà per tutti i venditori simultaneamente.
Un altro vantaggio della gestione dei ruoli è l'esclusione dell'assegnazione di autorizzazioni incompatibili. Cioè, un dipendente che ha un determinato ruolo nel sistema non può avere contemporaneamente un altro ruolo, i cui diritti non devono combinarsi con quelli del primo. Un chiaro esempio è il divieto di cumulare le funzioni di inserimento e controllo delle operazioni finanziarie.
Tutti coloro che sono interessati a capire come è nata la gestione dei diritti per ruolo possono
immergersi in un'escursione nella storia
Guardando alla storia, è nel corso degli anni '70 che la comunità IT ha cominciato a riflettere su metodi di gestione degli accessi. Sebbene le applicazioni fossero piuttosto semplici all'epoca, come oggi, c'era un forte desiderio di gestire gli accessi in modo semplice. Fornire, modificare e controllare i diritti degli utenti era fondamentale per comprendere con chiarezza quali accessi possedeva ciascuno di loro. Tuttavia, a quel tempo non esistevano standard comuni, venivano sviluppati i primi sistemi di gestione degli accessi, e ogni azienda si basava sulle proprie idee e regole.
Oggi sono conosciuti diversi modelli di gestione degli accessi, ma non sono emersi tutti in una volta. Concentreremo la nostra attenzione su quelli che hanno dato un contributo significativo allo sviluppo di questo campo.
Il primo e, probabilmente, il modello più semplice è la gestione degli accessi discrezionale (DAC – Controllo di accesso discrezionale). Questo modello implica la condivisione dei diritti da parte di tutti i partecipanti al processo di accesso. Ogni utente ha accesso a specifici oggetti o operazioni. In sostanza, un gran numero di soggetti di diritti corrisponde a un gran numero di oggetti. Questo modello è stato ritenuto troppo flessibile e complesso da gestire: le liste di accesso nel tempo diventano enormi e difficili da controllare.
Il secondo modello è il controllo di accesso obbligatorio (MAC — Mandatory Access Control). In questo modello, ogni utente ottiene accesso a un oggetto in base all'autorizzazione concessa per un determinato livello di riservatezza dei dati. Di conseguenza, gli oggetti devono essere categorizzati in base al livello di riservatezza. A differenza del primo modello flessibile, questo si è rivelato troppo rigido e restrittivo. La sua applicazione non si giustifica quando l'azienda ha molte risorse informative diverse: per delimitare l'accesso a diverse risorse, sarà necessario introdurre molte categorie che non si sovrapporranno.
A causa delle evidenti imperfezioni di questi due metodi, la comunità IT ha continuato a sviluppare modelli più flessibili e relativamente universali per supportare diversi tipi di politiche organizzative di controllo degli accessi. Fu allora che nacque il terzo modello di controllo degli accessi basato sui ruoli! Questo approccio si è rivelato il più promettente, poiché richiede non solo l'autenticazione dell'utente, ma anche le sue funzioni lavorative nei sistemi.
La prima struttura della modello basato sui ruoli è stata chiaramente descritta dai ricercatori americani David Ferraiolo e Richard Kuhn del National Institute of Standards and Technology degli Stati Uniti nel 1992. Allora è emerso per la prima volta il termine RBAC (Role-Based Access Control). Queste ricerche e le descrizioni dei componenti principali, così come le loro interrelazioni, hanno posto le basi per lo standard attualmente in vigore INCITS 359-2012, approvato dal Comitato Internazionale per gli standard della tecnologia dell'informazione (INCITS).
Lo standard definisce il ruolo come "una funzione all'interno dell'organizzazione con una certa semantica relativa ai poteri e alle responsabilità attribuite all'utente assegnato a quel ruolo". Il documento stabilisce gli elementi di base dell'RBAC – utenti, sessioni, ruoli, permessi, operazioni e oggetti, nonché le relazioni e le interconnessioni tra di essi.
Lo standard fornisce la struttura minima necessaria per costruire un modello di ruoli – unendo i diritti in ruoli e successivamente concedendo accesso agli utenti tramite questi ruoli. Vengono identificati i meccanismi di composizione dei ruoli a partire da oggetti e operazioni, descritti la gerarchia dei ruoli e l'eredità dei poteri. Infatti, in ogni azienda esistono ruoli che raggruppano poteri elementari necessari a tutti i dipendenti. Questo può includere l'accesso alla posta elettronica, al sistema di gestione documentale, al portale aziendale e così via. Questi poteri possono essere inclusi in un singolo ruolo generale chiamato "dipendente", evitando di dover elencare ogni volta i diritti elementari in ciascuno dei ruoli di livello superiore. È sufficiente semplicemente indicare il segno di eredità del ruolo "dipendente".
In seguito, lo standard è stato aggiornato con nuovi attributi di accesso che si adattano a un ambiente in continua evoluzione. È stata introdotta la possibilità di implementare limitazioni statiche e dinamiche. Le limitazioni statiche implicano l'impossibilità di combinare ruoli (il controllo delle operazioni menzionato in precedenza). Le limitazioni dinamiche possono essere determinate da parametri variabili, come il tempo (ore/giorni lavorativi/non lavorativi), la posizione (ufficio/casa) e così via.
È importante menzionare il controllo accessi basato su attributi (ABAC — Attribute-based access control). Questo approccio si basa sull'offerta di accesso tramite regole di condivisione degli attributi. Questo modello può essere utilizzato separatamente, ma spesso integra attivamente il modello classico basato su ruoli: a un determinato ruolo possono essere aggiunti attributi di utenti, risorse e dispositivi, oltre a quelli temporali o di posizione. Questo consente di utilizzare meno ruoli, introdurre ulteriori limitazioni e garantire un accesso minimo sufficiente, aumentando così la sicurezza.
Ad esempio, è possibile consentire l'accesso ai conti a un contabile se opera in una specifica regione. In questo caso, la posizione dello specialista verrà confrontata con un valore di riferimento specifico. Oppure si può dare accesso ai conti solo se l'utente si autentica da un dispositivo registrato nell'elenco di autorizzazioni. È un buon complemento al modello di ruolo, ma viene utilizzato raramente da solo a causa della necessità di creare molte regole e tabelle di autorizzazioni o restrizioni.
Facciamo un esempio di applicazione dell'ABAC dalla mia ‘vita precedente’. Nel nostro istituto bancario c’erano diversi filiali. Gli impiegati degli uffici clienti in queste filiali eseguivano operazioni assolutamente identiche, ma dovevano lavorare nel sistema principale solo con i conti della loro regione. Inizialmente, abbiamo iniziato a creare ruoli distinti per ogni regione – e così abbiamo creato un numero davvero elevato di ruoli con funzionalità ripetitive, ma con accesso a conti diversi! Poi, utilizzando l'attributo di posizione dell'utente e collegandolo a un intervallo specifico di conti per i controlli, abbiamo notevolmente ridotto la quantità di ruoli nel sistema. Alla fine, sono rimasti solo i ruoli per una singola filiale, che sono stati replicati per le corrispondenti posizioni in tutte le altre filiali dell’istituto.
Ora parliamo dei passi preparatori necessari, senza i quali è semplicemente impossibile costruire un modello di ruolo funzionante.
Passo 1. Creiamo un modello funzionale
Iniziare con la creazione di un modello funzionale: un documento di alto livello che descriva in dettaglio le funzionalità di ogni sottosezione e di ciascun ruolo. In genere, le informazioni vengono estratte da vari documenti, come le descrizioni delle mansioni e i regolamenti relativi a singole aree: reparti, uffici, dipartimenti. Il modello funzionale deve essere approvato da tutte le parti interessate (business, controllo interno, sicurezza) e ratificato dalla direzione dell'azienda. A cosa serve questo documento? Serve per consentire al modello ruolo di fare riferimento ad esso. Ad esempio, se si prevede di costruire un modello ruolo basato sui diritti già esistenti dei dipendenti - estratti dal sistema e "uniformati". Durante l'approvazione dei ruoli ottenuti con il proprietario del business, si può fare riferimento a un punto specifico del modello funzionale, sul quale si basa l'inclusione di un diritto o di un altro nel ruolo.
Passo 2. Auditi i sistemi IT e redatto un piano di priorità
Nella seconda fase, è necessario effettuare un audit dei sistemi IT per comprendere come è organizzato l'accesso a essi. Ad esempio, nella mia azienda finanziaria erano in uso diverse centinaia di sistemi informativi. In tutti i sistemi esistevano alcuni rudimenti di gestione dei ruoli, nella maggior parte dei casi qualche ruolo, ma principalmente su carta o nel manuale del sistema — erano ormai obsoleti e l'accesso veniva concesso in base alle richieste effettive degli utenti. Naturalmente, costruire un modello di ruolo in diverse centinaia di sistemi è semplicemente impossibile, bisogna iniziare da qualche parte. Abbiamo condotto un'analisi approfondita del processo di gestione dell'accesso per determinarne il livello di maturità. Durante l'analisi, abbiamo sviluppato criteri di priorità per i sistemi informativi — criticità, prontezza, piani per il dismissione, ecc. Con questi criteri abbiamo definito l'ordine di sviluppo/aggiornamento dei modelli di ruolo per questi sistemi. Successivamente, abbiamo incluso i modelli di ruolo nel piano di integrazione con la soluzione di Identity Management, per automatizzare la gestione degli accessi.
Quindi, come determinare la criticità del sistema? Rispondete a queste domande:
- Il sistema è collegato ai processi operativi su cui dipende l'attività principale dell'azienda?
- Un'interruzione del funzionamento del sistema influenzerà l'integrità degli asset dell'azienda?
- Qual è il tempo massimo di inattività consentito per il sistema, oltre il quale non è possibile ripristinare le operazioni dopo un'interruzione?
- Un compromesso dell'integrità delle informazioni nel sistema può portare a conseguenze irreversibili, sia finanziarie che reputazionali?
- Criticità riguardo alla frode. Presenza di funzionalità che, se non adeguatamente controllate, potrebbe consentire atti fraudolenti interni/esterni;
- Quali sono i requisiti legislativi e le regole e procedure interne per questi sistemi? Ci saranno sanzioni da parte delle autorità di regolamentazione per il mancato rispetto?
Nella nostra azienda finanziaria abbiamo condotto un audit in questo modo. La direzione ha sviluppato una procedura di Audit della Revisione dei Diritti di Accesso per gestire gli utenti esistenti e i diritti inizialmente nelle informazioni dei sistemi che erano stati inseriti nella lista delle priorità più alte. Il dipartimento della sicurezza è stato designato come il proprietario di questo processo. Tuttavia, per avere un quadro completo dei diritti di accesso in azienda, era necessario coinvolgere anche i reparti IT e business. Ed è qui che sono iniziati i dissidi, le incomprensioni e a volte persino il sabotaggio: nessuno vuole distaccarsi dai propri doveri attuali e impegnarsi in attività che a prima vista sembrano poco chiare.
N.B. Le grandi aziende con processi IT ben sviluppati conoscono sicuramente la procedura di audit IT – IT general controls (ITGC), che permette di identificare lacune nei processi IT e stabilire controlli per migliorare le procedure in linea con le best practice (ITIL, COBIT, IT Governance, etc.). Questo tipo di audit consente a IT e business di comprendere meglio le reciproche esigenze e di elaborare una strategia di sviluppo comune, analizzare i rischi, ottimizzare i costi e sviluppare approcci di lavoro più efficienti.
Una delle aree di audit è la determinazione dei parametri di accesso logico e fisico ai sistemi informativi. I dati raccolti sono stati utilizzati come base per ulteriori sviluppi nella costruzione del modello di ruoli. Questo audit ha portato alla creazione di un registro dei sistemi IT, nel quale sono stati definiti i loro parametri tecnici e fornite descrizioni. Inoltre, per ogni sistema è stato identificato un proprietario dal settore business, il quale era responsabile dei processi aziendali supportati da quel sistema. È stato anche nominato un manager del servizio IT, responsabile dell'implementazione tecnica delle esigenze di business in ciascun SI. Sono stati registrati i sistemi più critici per l'azienda, così come i loro parametri tecnici, le tempistiche di ingresso e uscita dall'operatività, e altro. Questi parametri hanno fornito un grande aiuto nel processo di preparazione alla costruzione del modello di ruoli.
Passo 3 Creiamo la metodologia
La chiave del successo in qualsiasi impresa è un metodo ben scelto. Pertanto, sia per costruire un modello di ruolo che per condurre un audit, è necessario creare una metodologia in cui descriviamo le interazioni tra i reparti, fissiamo le responsabilità nei regolamenti aziendali, e così via.
In primo luogo, è necessario esaminare tutti i documenti esistenti che stabiliscono le modalità di accesso e i diritti. Idealmente, i processi dovrebbero essere documentati su più livelli:
- requisiti aziendali generali;
- requisiti per le aree di sicurezza informatica (dipendono dalle aree operative dell'organizzazione);
- requisiti per i processi tecnologici (istruzioni, matrici di accesso, indicazioni metodologiche, requisiti per le configurazioni).
Nella nostra azienda finanziaria, abbiamo trovato molti documenti obsoleti – è stato necessario adeguarli ai nuovi processi in fase di implementazione.
Su richiesta della direzione, è stato creato un gruppo di lavoro, composto da rappresentanti dei settori sicurezza, IT, business e controllo interno. Nella richiesta sono state definite le finalità della creazione del gruppo, l'indirizzo delle attività, la durata dell'esistenza e i responsabili di ciascun settore. Inoltre, abbiamo sviluppato una metodologia per la conduzione dell'audit e un ordine per la costruzione del modello di ruolo: tali documenti sono stati approvati da tutti i rappresentanti responsabili dei vari settori e ratificati dalla direzione aziendale.
I documenti che descrivono le procedure di lavoro, le scadenze, le responsabilità, ecc. sono la chiave affinché, nel percorso verso l'ambizioso obiettivo, che inizialmente non è chiaro a tutti, nessuno sollevi domande del tipo 'perché lo facciamo, a cosa serve, ecc.' e non ci sia la possibilità di 'sfuggire' o rallentare il processo.
Passo 4. Registriamo i parametri del modello di gestione degli accessi esistente.
Creiamo quello che si chiama il «passaporto del sistema» per la gestione degli accessi. In sostanza, si tratta di un questionario relativo a un sistema informativo specifico, in cui sono registrati tutti gli algoritmi di gestione degli accessi. Le aziende che hanno già implementato soluzioni di tipo IdM probabilmente conoscono questo tipo di questionario, poiché è da qui che inizia lo studio dei sistemi.
Alcuni parametri sul sistema e sui proprietari sono stati trasferiti nel questionario dal registro IT (vedi passo 2, audit), ma ne sono stati aggiunti di nuovi:
- come viene gestita la gestione degli account (direttamente nel DB o tramite interfacce programmatiche);
- come gli utenti accedono al sistema (utilizzando un account separato o sfruttando le credenziali AD, LDAP o altro);
- quali livelli di accesso al sistema vengono utilizzati (livello applicativo, livello di sistema, utilizzo delle risorse di file di rete da parte del sistema);
- descrizione e parametri server, su cui opera il sistema;
- quali operazioni di gestione degli account sono supportate (blocco, rinomina, ecc.);
- secondo quali algoritmi o regole viene generato l'identificativo dell'utente del sistema;
- Quale attributo può essere utilizzato per stabilire un legame con la registrazione del dipendente nel sistema delle risorse umane (nome e cognome, numero identificativo o altro);
- Tutti gli attributi possibili della registrazione e le regole per la loro compilazione;
- Quali diritti di accesso esistono nel sistema (ruoli, gruppi, diritti atomici, ecc., ci sono diritti nidificati o gerarchici);
- Meccanismi di separazione dei diritti di accesso (per posizioni, reparti, funzioni, ecc.);
- Nel sistema ci sono regole di delimitazione dei diritti (SOD - Segregation of Duties) e come funzionano;
- Come vengono gestiti nel sistema eventi di assenza, trasferimento, cessazione, aggiornamento dei dati dei dipendenti, ecc.
È possibile continuare questo elenco con dettagli su vari parametri e altri oggetti coinvolti nel processo di gestione degli accessi.
Passo 5. Creiamo una descrizione dei poteri orientata al business
Un altro documento di cui avremo bisogno per costruire il modello di ruolo è un manuale sulle possibili autorizzazioni (diritti) che possono essere conferiti agli utenti nel sistema informativo, con una descrizione dettagliata della funzione aziendale sottostante. Spesso, le autorizzazioni nel sistema sono codificate in determinati nomi composti da lettere e numeri, e i dipendenti aziendali non riescono a comprendere cosa si cela dietro a questi simboli. Così si rivolgono al servizio IT, dove… anche lì non possono rispondere a domande, ad esempio, sui diritti raramente utilizzati. A questo punto, è necessario eseguire test aggiuntivi.
Va bene se la descrizione aziendale è già presente o se esiste anche un raggruppamento di questi diritti in gruppi e ruoli. Per alcune applicazioni, è considerata una buona pratica creare un tale manuale già nella fase di sviluppo. Ma ciò non accade spesso, quindi torniamo al dipartimento IT per raccogliere informazioni su tutti i diritti possibili e descriverli. Alla fine, il nostro manuale conterrà quanto segue:
- nome dell'autorizzazione, inclusa l'oggetto a cui si applica il diritto di accesso;
- azione consentita su un oggetto (visualizzazione, modifica, ecc., possibilità di limitazione, ad esempio, in base al territorio o al gruppo di clienti);
- codice delle autorizzazioni (codice e nome della funzione/richiesta di sistema che possono essere eseguite utilizzando l'autorizzazione);
- descrizione dell'autorizzazione (descrizione dettagliata delle azioni nel sistema informatico quando si applica l'autorizzazione e le loro conseguenze per il processo;
- stato dell'autorizzazione: "Attivo" (se l'autorizzazione è assegnata ad almeno un utente) o "Non attivo" (se l'autorizzazione non viene utilizzata).
Passaggio 6 Estraiamo dai sistemi i dati sugli utenti e i diritti e li confrontiamo con la fonte del personale
Nella fase finale di preparazione, è necessario estrarre i dati dai sistemi informativi riguardanti tutti gli utenti e i permessi attualmente in loro possesso. Sono possibili due scenari. Primo: il dipartimento di sicurezza ha accesso diretto al sistema e dispone degli strumenti per estrarre i relativi rapporti, il che è raro, ma molto conveniente. Secondo: inviamo una richiesta all'IT per ricevere i rapporti nel formato necessario. La pratica dimostra che concordare con l'IT e ottenere i dati necessari al primo tentativo non è spesso possibile. Sono necessari diversi approcci finché le informazioni non vengono ricevute nella forma e nel formato desiderati.
Quali dati devono essere estratti:
- Nome dell'account
- Nome e cognome del dipendente a cui è assegnato
- Stato (attivo o bloccato)
- Data di creazione dell'account
- Data dell'ultimo utilizzo
- Elenco dei diritti/gruppi/ruoli disponibili
Quindi, abbiamo ricevuto le estrazioni dal sistema con tutti gli utenti e con tutti i diritti loro concessi. E abbiamo subito messo da parte tutti gli account bloccati, poiché il lavoro per costruire il modello di ruolo sarà effettuato solo per gli utenti attivi.
In seguito, se la vostra azienda non dispone di strumenti automatizzati per revocare l'accesso ai dipendenti licenziati (una situazione piuttosto comune) o ha una automazione patchwork che non sempre funziona correttamente, è necessario identificare tutte le "anime morte". Ci si riferisce agli account di dipendenti già licenziati, i cui diritti non sono stati bloccati per qualche motivo, e che devono essere disattivati. A tal fine, confrontiamo i dati estratti con la fonte delle risorse umane. È necessario anche ottenere in anticipo l’estrazione delle risorse umane dal reparto responsabile della gestione della base dati del personale.
È necessario separare gli account di cui non si conoscono i proprietari, ovvero quelli non assegnati a nessuno, considerati abbandonati. Per questo elenco sarà necessaria la data dell'ultimo utilizzo: se è abbastanza recente, sarà comunque necessario cercare i proprietari. Qui possono rientrare gli account di appaltatori esterni o le credenziali aziendali non assegnate, ma legate a qualche processo. Per determinare a chi appartengono gli account, si possono inviare lettere a tutti i dipartimenti chiedendo di rispondere. Una volta trovati i proprietari, inseriamo i loro dati nel sistema: in questo modo tutti gli account attivi vengono identificati, mentre gli altri vengono bloccati.
Una volta che le nostre estrazioni sono state ripulite da voci superflue e rimangono solo gli account attivi, possiamo procedere alla creazione di un modello di ruoli per un sistema informatico specifico. Ma di questo parlerò già nel prossimo articolo.
Autore: Lyudmila Sevastyanova, manager per la promozione di Solar inRights
Fonte: habr.com
