🥇Costruiamo un modello di ruolo per la gestione degli accessi. Parte prima, preparatoria

Attualmente lavoro per un fornitore di software, in particolare nel settore delle soluzioni per la gestione degli accessi. La mia esperienza "dalla vita precedente" è legata al lato del cliente, ovvero a una grande organizzazione finanziaria. All'epoca, il nostro gruppo per il controllo degli accessi nel dipartimento di sicurezza informatica non poteva vantare grandi competenze in IdM. Abbiamo imparato molto durante il processo, e ci sono volute diverse “scottature” per costruire un meccanismo funzionante di gestione dei diritti degli utenti nei sistemi informativi aziendali.

Unendo la mia esperienza maturata con il cliente alle conoscenze e competenze del fornitore, voglio condividere con voi una sorta di istruzioni passo dopo passo: come creare in una grande azienda un modello di gestione degli accessi basato sui ruoli e quali vantaggi ne deriveranno. Le mie istruzioni si dividono in due parti: la prima è prepararsi a costruire il modello, la seconda è costruirlo realmente. Davanti a voi c'è la prima parte, quella preparatoria.

N.B. La costruzione di un modello di ruoli è, sfortunatamente, più un processo che un risultato. Anzi, è addirittura parte del processo di creazione di un ecosistema di gestione degli accessi all'interno dell'azienda. Pertanto, dovete prepararvi a un lavoro a lungo termine.

Prima di tutto, definiamo che cos'è la gestione degli accessi basata sui ruoli. Supponiamo che abbiate una grande banca con decine, se non centinaia di migliaia di dipendenti (soggetti), ciascuno dei quali ha decine di diritti di accesso in centinaia di sistemi informativi interni (oggetti). Ora moltiplicate il numero di oggetti per il numero di soggetti: esattamente tante connessioni, almeno, dovete prima costruire e poi controllare. È possibile farlo manualmente? Certo che no: è per questo che sono nate le figure dei ruoli.

Un ruolo è un insieme di autorizzazioni necessarie a un utente o a un gruppo di utenti per svolgere determinati compiti lavorativi. Ogni dipendente può avere uno o più ruoli e ciascun ruolo può contenere da una a molte autorizzazioni, che sono concesse all'utente nell'ambito di tale ruolo. I ruoli possono essere collegati a specifiche posizioni lavorative, reparti o compiti funzionali dei dipendenti.

I ruoli vengono generalmente creati a partire dai singoli diritti del dipendente in ciascun sistema informatico. Successivamente, dai ruoli di ciascun sistema si formano le business role globali. Ad esempio, la business role "gestore del credito" comprenderà diversi ruoli singoli nei sistemi informatici utilizzati nell'ufficio clienti della banca. Diciamo, in sistemi come il principale sistema bancario automatizzato, il modulo cassa, il sistema di gestione dei documenti elettronici, il service manager e altri. Le business role, di solito, sono legate alla struttura organizzativa – in altre parole, a un insieme di reparti dell'azienda e alle posizioni che vi si trovano. Così si forma la matrice dei ruoli globale ( esempio fornito nella tabella sottostante).

È importante notare che costruire un modello di ruolo al 100%, garantendo a tutti i dipendenti di ogni posizione nella struttura commerciale tutti i diritti necessari, è praticamente impossibile. E non è nemmeno necessario. Infatti, il modello di ruolo non può essere statico, poiché dipende da un ambiente in continua evoluzione. E dal cambiamento delle attività aziendali dell'azienda, che a sua volta influisce sulla modifica della struttura organizzativa e delle funzioni. E dall'assenza di un completo approvvigionamento di risorse, e dalla mancata osservanza delle istruzioni sui doveri, e dalla ricerca di profitto a scapito della sicurezza, e da molti altri fattori. Pertanto, è necessario costruire un modello di ruolo che possa soddisfare fino all'80% delle esigenze degli utenti relativamente ai diritti di base necessari all'assunzione di una posizione. E il restante 20% potrà, se necessario, essere richiesto successivamente tramite richieste separati.

Certo, puoi chiedere: "E non esistono modelli di ruolo al 100%?" Beh, sì, è possibile trovarli, ad esempio, in strutture non commerciali, che non subiscono frequenti cambiamenti, come in qualche istituto di ricerca. Oppure in organizzazioni della difesa con alti livelli di sicurezza, dove la sicurezza è al primo posto. Esistono anche in strutture commerciali, ma all'interno di un singolo dipartimento, il cui lavoro è un processo sufficientemente statico e prevedibile.

Il principale vantaggio della gestione per ruolo è la semplificazione dell'assegnazione dei diritti, poiché il numero di ruoli è notevolmente inferiore a quello degli utenti del sistema informatico. Questo è valido per qualsiasi settore.

Prendiamo un'azienda di vendita al dettaglio: ci lavorano migliaia di venditori, ma il set di diritti nel sistema N è identico per tutti, e verrà creata solo un'unica funzione. Se arriva un nuovo venditore in azienda, gli verrà automaticamente assegnato il ruolo necessario nel sistema, in cui sono già disponibili tutti i poteri richiesti. Allo stesso modo, con un click è possibile cambiare i diritti per migliaia di venditori contemporaneamente, ad esempio, aggiungendo una nuova opzione per la generazione di report. Non è necessario effettuare mille operazioni, associando il nuovo diritto a ciascun record – è sufficiente inserire questa opzione nel ruolo, e apparirà a tutti i venditori contemporaneamente.

Un altro vantaggio della gestione dei ruoli è l'esclusione dell'assegnazione di poteri incompatibili. Cioè, un dipendente che ha un certo ruolo nel sistema non può avere contemporaneamente un altro ruolo i cui diritti non dovrebbero essere compatibili con quelli del primo. Un esempio lampante è il divieto di accorpamento delle funzioni di inserimento e di controllo delle operazioni finanziarie.

Tutti coloro che sono interessati a come sia nata la gestione dei ruoli nell'accesso possono
immergersi in un excursus storico
Se diamo un'occhiata alla storia, possiamo vedere che la comunità IT ha cominciato a riflettere sui metodi di gestione dell'accesso già negli anni '70 del XX secolo. Anche se le applicazioni erano allora piuttosto semplici, così come oggi, a tutti sarebbe piaciuto gestire facilmente l'accesso a esse. Fornire, modificare e controllare i diritti degli utenti – in modo da capire più facilmente quale accesso avesse ciascuno di loro. Ma all'epoca non esistevano standard comuni, si stavano sviluppando i primi sistemi di gestione degli accessi, e ogni azienda si basava sulle proprie idee e regole.

Oggi conosciamo già molti modelli diversi di gestione dell'accesso, ma non sono emersi tutti immediatamente. Ci concentreremo 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 degli accessi discrezionale). Questo modello implica la condivisione dei diritti da parte di tutti i partecipanti al processo di accesso. Ogni utente ottiene accesso a specifici oggetti o operazioni. Di fatto, qui molti soggetti di diritti corrispondono a molti 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 è Controllo degli accessi obbligatorio (MAC - Mandatory access control). In questo modello, ogni utente ottiene accesso a un oggetto in base al permesso rilasciato per un determinato livello di riservatezza dei dati. Di conseguenza, gli oggetti devono essere classificati in base al livello di riservatezza. A differenza del primo modello flessibile, questo è risultato troppo rigoroso e limitativo. La sua applicabilità non si giustifica quando in un'azienda ci sono molteplici risorse informative variegate: per separare l'accesso a diverse risorse, sarà necessario introdurre molte categorie che non si sovrapporranno.

A causa dell'evidente imperfezione di questi due metodi, la comunità IT ha continuato a sviluppare modelli più flessibili e, allo stesso tempo, più o meno universali per supportare diversi tipi di politiche organizzative di controllo degli accessi. Ed è allora che è emerso il terzo modello di controllo degli accessi basato sui ruoli! Questo approccio si è dimostrato il più promettente, poiché richiede non solo l'autorizzazione dell'identità dell'utente, ma anche delle sue funzioni lavorative nei sistemi.

La prima struttura della modellazione basata sui ruoli è stata chiaramente delineata dagli scienziati americani David Ferraiolo e Richard Kuhn del National Institute of Standards and Technology degli Stati Uniti nel 1992. È stato allora che è emerso per la prima volta il termine RBAC (Controllo degli accessi basato sui ruoli). Queste ricerche e le descrizioni dei componenti principali, così come le loro interrelazioni, sono alla base dello standard in vigore ancora oggi INCITS 359-2012, approvato dal Comitato Internazionale per gli Standard nella Tecnologia dell'Informazione (INCITS).

Lo standard definisce il ruolo come «una funzione lavorativa nel contesto di un'organizzazione con una certa semantica correlata in relazione ai poteri e alle responsabilità attribuiti all'utente designato per quel ruolo». Il documento stabilisce gli elementi chiave del RBAC - utenti, sessioni, ruoli, permessi, operazioni e oggetti, così come le relazioni e le interazioni tra di essi.

Lo standard fornisce una struttura minima necessaria per costruire un modello basato su ruoli - combinazione dei diritti in ruoli e successivamente concessione dell'accesso agli utenti tramite questi ruoli. Vengono definiti i meccanismi per costruire ruoli da oggetti e operazioni, descritte la gerarchia dei ruoli e l'ereditarietà dei poteri. Infatti, in qualsiasi azienda ci sono ruoli che combinano le elementari attribuzioni necessarie a tutti i dipendenti dell'azienda. Questo potrebbe essere l'accesso alla posta elettronica, al sistema di gestione documentale, al portale aziendale, ecc. Questi poteri possono essere inclusi in un unico ruolo generale chiamato «dipendente», e non sarà necessario elencare di volta in volta tutti i diritti elementari in ciascuno dei ruoli di livello superiore. Basta semplicemente indicare il segno di ereditarietà del ruolo «dipendente».

Successivamente, lo standard è stato arricchito con nuovi attributi di accesso, legati a un ambiente in continua evoluzione. È stata aggiunta la possibilità di introdurre restrizioni statiche e dinamiche. Le restrizioni statiche implicano l'impossibilità di sovrapporre i ruoli (quella stessa introduzione e controllo delle operazioni menzionata in precedenza). Le restrizioni dinamiche possono essere definite da parametri variabili, come il tempo (ore o giorni lavorativi/non lavorativi), la posizione (ufficio/casa), ecc.

Vale la pena menzionare la gestione degli accessi basata sugli attributi (ABAC — Attribute-based access control). L'approccio si basa sulla concessione di accesso attraverso regole di condivisione degli attributi. Questo modello può essere utilizzato in modo indipendente, ma spesso integra attivamente il classico modello basato su ruoli: è possibile aggiungere attributi degli utenti, delle risorse e dei dispositivi, nonché del tempo o della posizione a un determinato ruolo. Questo consente di utilizzare meno ruoli, introdurre restrizioni aggiuntive e rendere l'accesso minimalmente sufficiente, aumentando così la sicurezza.

Ad esempio, si può consentire l'accesso ai conti a un contabile se lavora in una determinata regione. In tal caso, la posizione dello specialista verrà confrontata con un valore di riferimento specifico. Oppure si può concedere l'accesso ai conti solo se l'utente si autentica da un dispositivo registrato tra quelli autorizzati. È un buon complemento al modello basato sui ruoli, ma viene utilizzato raramente da solo a causa della necessità di creare molti regole e tabelle di autorizzazione o limitazione.

Vi porto un esempio di applicazione dell'ABAC dalla mia "vita passata". Nel nostro banco c'erano diverse filiali. Gli impiegati degli uffici clienti in queste filiali svolgevano operazioni assolutamente identiche, ma dovevano lavorare nel sistema principale solo con i conti della loro regione. Inizialmente abbiamo iniziato a creare ruoli separati per ogni regione, e ce n'erano davvero moltissimi con funzionalità ripetitive, ma con accessi a conti diversi! Poi, utilizzando l'attributo della posizione per l'utente e collegandolo a un specifico intervallo di conti per il controllo, abbiamo significativamente ridotto il numero di ruoli nel sistema. Alla fine sono rimasti solo i ruoli per una filiale, che venivano replicati per le corrispondenti posizioni in tutte le altre unità territoriali della banca.

E ora parliamo dei passaggi preparatori necessari, senza i quali non è possibile costruire un modello di ruoli funzionante.

Passo 1. Creiamo un modello funzionale

È utile iniziare creando un modello funzionale: un documento di alto livello che descrive in dettaglio le funzioni di ciascun dipartimento e di ciascun ruolo. Di norma, le informazioni in esso contenute provengono da vari documenti: mansioni e normative relative ai singoli dipartimenti - uffici, divisioni, dipartimenti. Il modello funzionale deve essere approvato da tutti i dipartimenti interessati (business, controllo interno, sicurezza) e convalidato dalla direzione dell'azienda. A cosa serve questo documento? Serve affinché il modello di ruolo possa riferirsi ad esso. Ad esempio, se si intende costruire un modello di ruolo basato sui diritti già esistenti dei dipendenti, scaricati dal sistema e

Passo 2. Audit dei sistemi IT e pianificazione della priorità

Nella seconda fase, è necessario condurre un audit dei sistemi IT per capire come è organizzato l'accesso a essi. Ad esempio, nella mia azienda finanziaria erano utilizzati diverse centinaia di sistemi informativi. In tutti i sistemi c'erano alcuni accenni alla gestione dei ruoli, nella maggior parte c'erano dei ruoli, ma principalmente su carta o in un database obsoleto, e l'accesso veniva concesso in base alle richieste effettive degli utenti. Naturalmente, costruire un modello di ruolo in centinaia di sistemi contemporaneamente è semplicemente impossibile, bisogna iniziare da qualche parte. Abbiamo effettuato un'analisi approfondita del processo di gestione degli accessi per determinare il livello di maturità. Durante l'analisi abbiamo sviluppato criteri per la prioritizzazione dei sistemi informativi - criticità, prontezza, piani di dismissione, ecc. Con questi criteri abbiamo stabilito l'ordine di sviluppo/aggiornamento dei modelli di ruolo per questi sistemi. E poi abbiamo integrato 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à di un sistema? Rispondete a queste domande:

Il sistema è collegato ai processi operativi da cui dipende l'attività principale dell'azienda?
La violazione del funzionamento del sistema influirà sull'integrità degli attivi aziendali?
Qual è il massimo tempo di inattività consentito del sistema, oltre il quale non è possibile ripristinare l'attività dopo un'interruzione?
La violazione dell'integrità delle informazioni nel sistema può portare a conseguenze irreversibili, sia finanziarie che reputazionali?
Criticità per frodi. La presenza di funzionalità, il cui controllo insufficiente può permettere azioni fraudolente interne/esterne;
Quali sono i requisiti di legge e le procedure interne per questi sistemi? Ci saranno sanzioni da parte dei regolatori per la non conformità?

Nella nostra azienda finanziaria abbiamo condotto un audit in questo modo. La direzione ha sviluppato la procedura di audit Review dei Diritti di Accesso, per chiarire la situazione degli utenti esistenti e dei diritti inizialmente in quei sistemi informatici inclusi nella lista delle priorità. La responsabilità di questo processo è stata assegnata al dipartimento di sicurezza. Ma per avere un quadro completo dei diritti di accesso in azienda è stato necessario coinvolgere il dipartimento IT e quello commerciale. Ed è qui che sono iniziati i conflitti, il fraintendimento e a volte anche il sabotaggio: nessuno vuole staccarsi dalle proprie responsabilità attuali e impegnarsi in attività che, a prima vista, sembrano incomprensibili.

N.B. Le grandi aziende con processi IT sviluppati conoscono sicuramente la procedura di audit IT – controlli generali IT (ITGC), che consente di identificare le carenze nei processi IT e stabilire controlli per migliorare i processi secondo le best practice (ITIL, COBIT, IT Governance, ecc.). Tale audit permette a IT e business di comprendere meglio l'uno dell'altro e sviluppare una strategia comune di crescita, analizzare i rischi, ottimizzare i costi e sviluppare approcci lavorativi più efficaci.

Una delle direzioni dell'audit è la determinazione dei parametri di accesso logico e fisico ai sistemi informativi. I dati raccolti sono stati utilizzati come base per l'ulteriore utilizzo nella costruzione del modello di ruolo. Come risultato di questo audit abbiamo creato un registro dei sistemi IT, in cui sono stati definiti i loro parametri tecnici e fornita una descrizione. Inoltre, per ogni sistema è stato designato un proprietario dall'area aziendale, nel cui interesse è stato utilizzato: è proprio lui a rispondere per i processi aziendali che questo sistema gestiva. È stato anche nominato un manager IT, responsabile dell'implementazione tecnica delle esigenze aziendali in un determinato IS. Sono stati registrati i sistemi più critici per l'azienda e i loro parametri tecnici, le date di inizio e di cessazione dell'operatività, ecc. Questi parametri sono stati di grande aiuto nel processo di preparazione alla costruzione del modello di ruolo.

Fase 3 Creazione della metodologia

La chiave del successo di qualsiasi iniziativa è il metodo scelto correttamente. Pertanto, sia per la costruzione del modello di ruolo che per la conduzione dell'audit, è necessario creare una metodologia, in cui descriveremo l'interazione tra le divisioni, stabiliremo le responsabilità nei regolamenti dell'azienda, ecc.
Per iniziare, è necessario esaminare tutti i documenti disponibili che stabiliscono l'ordine di concessione di accesso e diritti. Idealmente, i processi dovrebbero essere documentati a più livelli:

requisiti aziendali generali;
requisiti per le aree di sicurezza informatica (dipendenti dalle aree di attività dell'organizzazione);
requisiti per i processi tecnologici (istruzioni, matrici di accesso, direttive metodologiche, requisiti per le configurazioni).

Nella nostra azienda finanziaria abbiamo trovato molti documenti obsoleti – è stato necessario aggiornarli secondo i nuovi processi implementati.

Su ordine della direzione è stato creato un gruppo di lavoro, composto da rappresentanti dei settori della sicurezza, IT, business e controllo interno. Nell'ordine sono stati definiti gli obiettivi della creazione del gruppo, le aree di attività, la durata dell'esistenza e i responsabili di ciascun lato. Inoltre, abbiamo sviluppato una metodologia per la conduzione dell'audit e un modo per costruire il modello di ruolo: questi sono stati concordati da tutti i rappresentanti responsabili dei settori e approvati dalla direzione dell'azienda.

I documenti che descrivono le modalità di lavoro, le scadenze, le responsabilità, ecc. sono la garanzia che, nel percorso verso l'obiettivo desiderato, che all'inizio non è evidente per tutti, nessuno avrà domande come «perché lo facciamo, di cosa abbiamo bisogno e simili» e non ci sarà l'opportunità di «scappare» o ritardare il processo.

Passo 4. Registriamo i parametri del modello di gestione degli accessi esistente

Prepariamo quello che viene chiamato "passaporto del sistema" in materia di gestione degli accessi. In sostanza, si tratta di un questionario relativo a un particolare sistema informativo, in cui sono registrati tutti gli algoritmi di gestione degli accessi ad esso. Le aziende che hanno già implementato soluzioni della classe IdM conoscono sicuramente questionari simili, poiché è da lì che inizia l'analisi dei sistemi.

Parte dei parametri sul sistema e sui proprietari è stata trasferita nel questionario dal registro IT (vedi passo 2, audit), ma sono stati aggiunti anche nuovi parametri:

come avviene la gestione degli account (direttamente nel DB o tramite interfacce di programmazione);
come gli utenti accedono al sistema (utilizzando un account separato o utilizzando un account AD, LDAP o altro);
quali livelli di accesso al sistema sono 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, rinominazione, ecc.);
secondo quali algoritmi o regole viene generato l'identificativo dell'utente del sistema;
su quale attributo è possibile stabilire un collegamento con la registrazione del dipendente nel sistema di gestione del personale (Nome e Cognome, numero di registrazione o altro);
tutti gli attributi possibili dell'account e le regole per il loro completamento;
quali diritti di accesso esistono nel sistema (ruoli, gruppi, diritti atomici e altro, ci sono diritti annidati o gerarchici);
meccanismi di separazione dei diritti di accesso (per posizione, divisioni, funzionalità, ecc.);
ci sono nella sistema regole per la segregazione dei diritti (SOD – Segragazione dei Doveri), e come funzionano;
come vengono gestiti nel sistema eventi di assenza, trasferimento, licenziamento, aggiornamento dei dati sui dipendenti, ecc.

È possibile continuare questo elenco con dettagli su vari parametri e altri oggetti coinvolti nel processo di gestione dell'accesso.

Passo 5. Creiamo una descrizione delle autorizzazioni orientata al business

Un altro documento di cui abbiamo bisogno per costruire il modello di ruolo è il catalogo di tutte le possibili autorizzazioni (diritti) che possono essere concesse agli utenti nel sistema informativo con una descrizione dettagliata della funzione aziendale sottostante. Spesso, le autorizzazioni nel sistema sono criptate con nomi specifici composti da lettere e numeri, rendendo difficile per i dipendenti aziendali capire cosa si nasconde dietro questi simboli. Così, si rivolgono al dipartimento IT, dove... non possono nemmeno rispondere a domande su diritti raramente utilizzati. Questo richiede ulteriori test.

È positivo se la descrizione aziendale è già presente o se esiste anche una combinazione di questi diritti in gruppi e ruoli. Per alcune applicazioni, la prassi migliore è creare un tale catalogo già nella fase di sviluppo. Tuttavia, ciò non accade spesso, quindi ci rivolgiamo nuovamente al dipartimento IT per raccogliere informazioni su tutti i diritti possibili e descriverli. Il nostro catalogo conterrà alla fine quanto segue:

nome dell'autorizzazione, incluso l'oggetto a cui si applica il diritto di accesso;
azione che è consentito eseguire con l'oggetto (visualizzazione, modifica, ecc., possibilità di restrizione, ad esempio, per territorio o per gruppo di clienti);
codice dell'autorizzazione (codice e nome della funzione/richiesta del sistema, che possono essere eseguiti usando l'autorizzazione);
descrizione dell'autorizzazione (descrizione dettagliata delle azioni nel sistema informativo all'applicazione dell'autorizzazione e delle loro conseguenze per il processo;
stato dell'autorizzazione: "Attivo" (se l'autorizzazione è stata assegnata a almeno un utente) o "Non attivo" (se l'autorizzazione non è in uso).

Passo 6 Esportiamo dai sistemi dati su utenti e diritti e li confrontiamo con la fonte del personale

Nella fase finale della preparazione, è necessario estrarre i dati dai sistemi informativi su tutti gli utenti e i diritti che hanno attualmente. Qui ci sono due scenari possibili. Primo: il reparto sicurezza ha accesso diretto al sistema e dispone di strumenti per estrarre i rapporti pertinenti, cosa che accade raramente, ma è molto comoda. Secondo: inviamo una richiesta all'IT per ottenere rapporti nel formato desiderato. La pratica dimostra che è difficile accordarsi con l'IT e ottenere i dati necessari al primo tentativo. È necessario fare alcuni tentativi finché le informazioni non vengono ottenute nel formato e modo richiesti.

Quali dati devono essere estratti:

Nome dell'account
Nome e cognome dell'impiegato a cui è assegnato
Stato (attivo o bloccato)
Data di creazione dell'account
Data dell'ultimo utilizzo
Elenco dei diritti/gruppi/ruoli disponibili

Quindi, abbiamo ottenuto le estrazioni dal sistema con tutti gli utenti e con tutti i diritti loro assegnati. E abbiamo subito messo da parte tutti gli account bloccati, poiché il lavoro per costruire il modello di ruolo sarà effettuato solo con utenti attivi.

Poi, se nella vostra azienda non ci sono strumenti automatizzati per chiudere l'accesso ai dipendenti licenziati (cosa che accade spesso) o c'è un'automazione frammentata che non sempre funziona correttamente, è necessario identificare tutte le "anime morte". Si parla degli account di dipendenti già licenziati, i cui diritti non sono stati bloccati per qualche motivo, e devono essere bloccati. Per questo, confrontiamo i dati estratti con la fonte di personale. L’estrazione del personale deve anche essere previamente ottenuta dal dipartimento che gestisce il database delle risorse umane.

È necessario separare gli account per i quali non si sono trovati i proprietari nel database del personale, che non sono assegnati a nessuno, ossia siano abbandonati. Per questo elenco avremo bisogno della data dell'ultimo utilizzo: se è piuttosto recente, dovremo comunque cercare i proprietari. Qui possono rientrare gli account dei fornitori esterni o gli account di servizio, non assegnati a nessuno, ma collegati a processi specifici. Per chiarire la pertinenza degli account, si possono inviare lettere a tutti i reparti con la richiesta di farsi avanti. Quando i proprietari saranno trovati, inseriamo i loro dati nel sistema: in questo modo tutti gli account attivi saranno identificati, mentre gli altri verranno bloccati.

Non appena i nostri caricamenti sono stati ripuliti da registrazioni superflue e rimangono solo gli account attivi, possiamo procedere con la costruzione di un modello di ruolo per un sistema informativo specifico. Ma di questo parlerò già nel prossimo articolo.

Autore: Lyudmila Sevastyanova, manager per la promozione di Solar inRights

Fonte: habr.com