Stiamo costruendo un modello di controllo degli accessi basato sui ruoli. Prima parte, preparatoria

Attualmente lavoro per un fornitore di software, in particolare soluzioni di controllo degli accessi. E la mia esperienza "di una vita passata" è collegata al lato del cliente, una grande organizzazione finanziaria. A quel tempo, il nostro gruppo di controllo degli accessi nel dipartimento di sicurezza delle informazioni non poteva vantare grandi competenze in IdM. Abbiamo imparato molto nel processo, abbiamo dovuto affrontare molti ostacoli per costruire un meccanismo funzionante per la gestione dei diritti degli utenti nei sistemi informativi dell'azienda.

Combinando la mia esperienza cliente duramente conquistata con le conoscenze e le competenze dei fornitori, desidero condividere con voi istruzioni essenzialmente passo passo: come creare un modello di controllo degli accessi basato sui ruoli in una grande azienda e cosa ciò darà di conseguenza . Le mie istruzioni sono composte da due parti: la prima riguarda la preparazione per la costruzione del modello, la seconda la costruzione vera e propria. Ecco la prima parte, quella preparatoria.

NB Sfortunatamente, costruire un modello non è un risultato, ma un processo. O meglio, addirittura parte del processo di creazione di un ecosistema di controllo degli accessi in azienda. Quindi preparati per il gioco per molto tempo.

Per prima cosa definiamolo: cos'è il controllo degli accessi basato sui ruoli? Supponiamo di avere una grande banca con decine o addirittura centinaia di migliaia di dipendenti (entità), ognuno dei quali ha dozzine di diritti di accesso a centinaia di sistemi informativi bancari interni (oggetti). Ora moltiplica il numero di oggetti per il numero di soggetti: questo è il numero minimo di connessioni che devi prima costruire e poi controllare. È davvero possibile farlo manualmente? Ovviamente no: i ruoli sono stati creati per risolvere questo problema.

Un ruolo è un insieme di autorizzazioni di cui un utente o un gruppo di utenti ha bisogno per eseguire determinate attività lavorative. Ogni dipendente può avere uno o più ruoli e ogni ruolo può contenere da una a molte autorizzazioni concesse all'utente all'interno di quel ruolo. I ruoli possono essere legati a posizioni, dipartimenti o compiti funzionali specifici dei dipendenti.

I ruoli vengono generalmente creati dalle autorizzazioni dei singoli dipendenti in ciascun sistema informativo. Quindi i ruoli aziendali globali vengono formati dai ruoli di ciascun sistema. Ad esempio, il ruolo aziendale "responsabile del credito" includerà diversi ruoli separati nei sistemi informativi utilizzati nell'ufficio clienti della banca. Ad esempio, come il principale sistema bancario automatizzato, il modulo di cassa, il sistema di gestione elettronica dei documenti, il gestore del servizio e altri. I ruoli aziendali, di regola, sono legati alla struttura organizzativa, in altre parole, all'insieme delle divisioni aziendali e delle posizioni al loro interno. Ecco come si forma una matrice di ruoli globale (fornisco un esempio nella tabella seguente).

Vale la pena notare che è semplicemente impossibile costruire un modello di ruolo al 100%, fornendo tutti i diritti necessari ai dipendenti di ciascuna posizione in una struttura commerciale. Sì, questo non è necessario. Dopotutto, un modello di ruolo non può essere statico, perché dipende da un ambiente in costante cambiamento. E dai cambiamenti nelle attività commerciali dell’azienda, che, di conseguenza, influiscono sui cambiamenti nella struttura organizzativa e nella funzionalità. E dalla mancanza di una fornitura completa di risorse, dal mancato rispetto delle descrizioni del lavoro, dal desiderio di profitto a scapito della sicurezza e da molti altri fattori. Pertanto, è necessario costruire un modello di ruolo che possa coprire fino all'80% delle esigenze degli utenti per i diritti di base necessari quando assegnati a una posizione. E potranno, se necessario, richiedere il restante 20% successivamente con domande separate.

Naturalmente potresti chiedere: "Non esistono modelli di ruolo al 100%?" Ebbene, questo accade, ad esempio, in strutture senza scopo di lucro che non sono soggette a frequenti cambiamenti - in alcuni istituti di ricerca. O in organizzazioni complesse militare-industriali con un elevato livello di sicurezza, dove la sicurezza viene prima di tutto. Ciò avviene in una struttura commerciale, ma nel quadro di una divisione separata, il cui lavoro è un processo abbastanza statico e prevedibile.

Il vantaggio principale della gestione basata sui ruoli è la semplificazione dell'assegnazione dei diritti, poiché il numero dei ruoli è notevolmente inferiore al numero degli utenti del sistema informativo. E questo vale per qualunque settore.

Prendiamo un'azienda di vendita al dettaglio: impiega migliaia di venditori, ma hanno gli stessi diritti nel sistema N e per loro verrà creato un solo ruolo. Quando un nuovo venditore arriva in azienda, gli viene automaticamente assegnato il ruolo richiesto nel sistema, che dispone già di tutte le autorizzazioni necessarie. Inoltre, con un clic puoi modificare i diritti di migliaia di venditori contemporaneamente, ad esempio aggiungere una nuova opzione per generare un report. Non è necessario fare mille operazioni per collegare un nuovo diritto a ciascun account: basta aggiungere questa opzione al ruolo e apparirà contemporaneamente a tutti i venditori.

Un altro vantaggio della gestione basata sui ruoli è l'eliminazione dell'emissione di autorizzazioni incompatibili. Cioè, un dipendente che ha un certo ruolo nel sistema non può avere contemporaneamente un altro ruolo, i cui diritti non dovrebbero essere combinati con i diritti del primo. Un esempio lampante è il divieto di combinare le funzioni di input e controllo di una transazione finanziaria.

Chiunque sia interessato a come è nato il controllo degli accessi basato sui ruoli può farlo
tuffarsi nella storia
Se guardiamo alla storia, la comunità IT ha pensato per la prima volta ai metodi di controllo degli accessi negli anni '70 del XX secolo. Anche se allora le applicazioni erano piuttosto semplici, come oggi, tutti volevano poter gestire comodamente l’accesso ad esse. Concedi, modifica e controlla i diritti degli utenti, solo per rendere più facile capire quale accesso ha ciascuno di loro. Ma a quel tempo non esistevano standard comuni, si stavano sviluppando i primi sistemi di controllo degli accessi e ogni azienda si basava sulle proprie idee e regole.

Oggi si conoscono molti modelli diversi di controllo degli accessi, ma non sono apparsi immediatamente. Soffermiamoci su coloro che hanno dato un contributo significativo allo sviluppo di quest'area.

Il primo e probabilmente il modello più semplice è Controllo degli accessi discrezionale (selettivo). (DAC – Controllo accessi discrezionale). Questo modello implica la condivisione dei diritti da parte di tutti i partecipanti al processo di accesso. Ogni utente ha accesso a oggetti o operazioni specifici. In sostanza, qui l'insieme dei soggetti dei diritti corrisponde all'insieme degli oggetti. Questo modello si è rivelato troppo flessibile e troppo difficile da mantenere: le liste di accesso alla fine diventano enormi e difficili da controllare.

Il secondo modello è Controllo accessi obbligatorio (MAC - Controllo accessi obbligatorio). Secondo questo modello, ogni utente riceve accesso a un oggetto in conformità con l'accesso concesso a un particolare livello di riservatezza dei dati. Di conseguenza, gli oggetti dovrebbero essere classificati in base al loro livello di riservatezza. A differenza del primo modello flessibile, questo, al contrario, si è rivelato troppo rigido e restrittivo. Il suo utilizzo non è giustificato quando l'azienda dispone di molte risorse informative diverse: per differenziare l'accesso alle diverse risorse sarà necessario introdurre molte categorie che non si sovrappongano.

A causa delle evidenti imperfezioni 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 policy di controllo degli accessi organizzativi. E poi è apparso il terzo modello di controllo accessi basato sui ruoli! Questo approccio si è rivelato il più promettente perché richiede non solo l’autorizzazione dell’identità dell’utente, ma anche delle sue funzioni operative nei sistemi.

La prima struttura del modello di ruolo chiaramente descritta è stata proposta dagli scienziati americani David Ferrailo e Richard Kuhn del National Institute of Standards and Technology nel 1992. Poi è apparso per la prima volta il termine RBAC (controllo degli accessi basato sui ruoli). Questi studi e descrizioni dei componenti principali, nonché le loro relazioni, hanno costituito la base dello standard INCITS 359-2012, ancora in vigore oggi, approvato dall'International Committee on Information Technology Standards (INCITS).

Lo standard definisce un ruolo come "una funzione lavorativa nel contesto di un'organizzazione con alcune semantiche associate riguardanti l'autorità e la responsabilità assegnate all'utente assegnato al ruolo". Il documento stabilisce gli elementi di base di RBAC: utenti, sessioni, ruoli, permessi, operazioni e oggetti, nonché le relazioni e le interconnessioni tra loro.

Lo standard fornisce la struttura minima necessaria per costruire un modello di ruolo, combinando i diritti in ruoli e quindi garantendo l'accesso agli utenti attraverso questi ruoli. Vengono delineati i meccanismi per la composizione dei ruoli a partire da oggetti e operazioni, viene descritta la gerarchia dei ruoli e l'ereditarietà dei poteri. Dopotutto, in ogni azienda ci sono ruoli che combinano i poteri di base necessari per tutti i dipendenti dell'azienda. Potrebbe trattarsi dell'accesso a e-mail, EDMS, portale aziendale, ecc. Queste autorizzazioni possono essere incluse in un ruolo generale chiamato “dipendente” e non sarà necessario elencare più e più volte tutti i diritti di base in ciascuno dei ruoli di livello superiore. È sufficiente indicare semplicemente l'eredità caratteristica del ruolo di “dipendente”.

Successivamente lo standard è stato integrato con nuovi attributi di accesso legati ad un ambiente in continua evoluzione. È stata aggiunta la possibilità di introdurre restrizioni statiche e dinamiche. Quelli statici implicano l'impossibilità di combinare i ruoli (lo stesso input e controllo delle operazioni sopra menzionate). Le restrizioni dinamiche possono essere determinate modificando i parametri, ad esempio l'ora (ore o giorni lavorativi/non lavorativi), l'ubicazione (ufficio/casa), ecc.

Separatamente, dovrebbe essere detto su controllo degli accessi basato sugli attributi (ABAC - Controllo degli accessi basato sugli attributi). L'approccio si basa sulla concessione dell'accesso utilizzando regole di condivisione degli attributi. Questo modello può essere utilizzato separatamente, ma molto spesso integra attivamente il classico modello di ruolo: attributi di utenti, risorse e dispositivi, nonché tempo o posizione, possono essere aggiunti a un determinato ruolo. Ciò consente di utilizzare meno ruoli, introdurre restrizioni aggiuntive e rendere l'accesso il più minimo possibile, migliorando quindi la sicurezza.

Ad esempio, a un contabile può essere consentito l'accesso ai conti se lavora in una determinata regione. Quindi la posizione dello specialista verrà confrontata con un determinato valore di riferimento. Oppure puoi dare accesso agli account solo se l'utente accede da un dispositivo incluso nell'elenco di quelli consentiti. Una buona aggiunta a un modello di ruolo, ma usata raramente da sola a causa della necessità di creare molte regole e tabelle di autorizzazioni o restrizioni.

Lascia che ti faccia un esempio dell'uso di ABAC dalla mia "vita passata". La nostra banca aveva diverse filiali. I dipendenti degli uffici clienti di queste filiali eseguivano esattamente le stesse operazioni, ma dovevano lavorare nel sistema principale solo con conti nella loro regione. Innanzitutto, abbiamo iniziato a creare ruoli separati per ciascuna regione: ce n'erano tanti con funzionalità ripetitive, ma con accesso ad account diversi! Quindi, utilizzando un attributo di posizione per l'utente e associandolo a un intervallo specifico di account da esaminare, abbiamo ridotto in modo significativo il numero di ruoli nel sistema. Di conseguenza, per una sola filiale sono rimasti incarichi che sono stati replicati per i corrispondenti incarichi in tutte le altre sedi territoriali della banca.

Parliamo ora delle necessarie fasi preparatorie, senza le quali è semplicemente impossibile costruire un modello di lavoro.

Passaggio 1. Creare un modello funzionale

Dovresti iniziare creando un modello funzionale, un documento di primo livello che descriva in dettaglio la funzionalità di ciascun dipartimento e ciascuna posizione. Di norma, le informazioni provengono da vari documenti: descrizioni dei lavori e regolamenti per singole unità: dipartimenti, divisioni, dipartimenti. Il modello funzionale deve essere concordato con tutte le funzioni interessate (business, controllo interno, sicurezza) e approvato dal management aziendale. A cosa serve questo documento? In modo che il modello possa fare riferimento ad esso. Ad esempio, costruirai un modello basato sui diritti esistenti dei dipendenti, scaricati dal sistema e “ridotti a un denominatore comune”. Quindi, quando si concordano i ruoli ricevuti con l'imprenditore del sistema, è possibile fare riferimento a un punto specifico del modello funzionale, in base al quale questo o quel diritto è incluso nel ruolo.

Fase 2. Verifichiamo i sistemi IT ed elaboriamo un piano di definizione delle priorità

Nella seconda fase, dovresti condurre un audit dei sistemi IT per capire come è organizzato l'accesso ad essi. Ad esempio, la mia società finanziaria gestiva diverse centinaia di sistemi informativi. Tutti i sistemi avevano alcuni rudimenti di gestione basata sui ruoli, la maggior parte aveva alcuni ruoli, ma per lo più su carta o nella directory di sistema: erano obsoleti da tempo e l'accesso ad essi veniva concesso in base alle effettive richieste degli utenti. Naturalmente, è semplicemente impossibile costruire un modello in diverse centinaia di sistemi contemporaneamente; bisogna iniziare da qualche parte. Abbiamo condotto un'analisi approfondita del processo di controllo degli accessi per determinarne il livello di maturità. Durante il processo di analisi, sono stati sviluppati criteri per dare priorità ai sistemi informativi: criticità, prontezza, piani per la disattivazione, ecc. Con il loro aiuto, abbiamo avviato lo sviluppo/aggiornamento di modelli di ruolo per questi sistemi. E poi abbiamo inserito dei modelli di riferimento nel piano di integrazione con la soluzione di Identity Management per automatizzare il controllo degli accessi.

Allora come si determina la criticità di un sistema? Rispondi alle seguenti domande:

• Il sistema è collegato ai processi operativi da cui dipendono le attività core dell'azienda?
• L'interruzione del sistema influenzerà l'integrità delle risorse aziendali?
• Qual è il tempo massimo di inattività consentito del sistema, raggiungimento del quale è impossibile ripristinare l'attività dopo un'interruzione?
• Una violazione dell’integrità delle informazioni nel sistema può portare a conseguenze irreversibili, sia finanziarie che reputazionali?
• Criticità per la frode. La presenza di funzionalità, se non adeguatamente controllata, può portare ad azioni fraudolente interne/esterne;
• Quali sono i requisiti legali, le regole e le procedure interne per questi sistemi? Ci saranno multe da parte delle autorità di regolamentazione per la non conformità?

Nella nostra società finanziaria abbiamo condotto un audit come questo. La direzione ha sviluppato la procedura di audit di revisione dei diritti di accesso per esaminare innanzitutto gli utenti e i diritti esistenti in quei sistemi informativi che erano nell'elenco di massima priorità. Il dipartimento di sicurezza è stato assegnato come titolare di questo processo. Ma per avere un quadro completo dei diritti di accesso in azienda, è stato necessario coinvolgere nel processo i reparti IT e aziendali. E qui sono iniziate controversie, incomprensioni e talvolta anche sabotaggi: nessuno vuole staccarsi dalle proprie responsabilità attuali e lasciarsi coinvolgere in alcune attività, a prima vista, incomprensibili.

NB Le grandi aziende con processi IT sviluppati hanno probabilmente familiarità con la procedura di audit IT - IT General Controls (ITGC), che consente di identificare le carenze nei processi IT e stabilire un controllo in modo da migliorare i processi in conformità con le migliori pratiche (ITIL, COBIT, IT Governance, ecc.) Tale audit consente all'IT e all'azienda di comprendersi meglio e sviluppare una strategia di sviluppo congiunta, analizzare i rischi, ottimizzare i costi e sviluppare approcci al lavoro più efficaci.



Una delle aree dell'audit è determinare i parametri di accesso logico e fisico ai sistemi informativi. Abbiamo preso i dati ottenuti come base per un ulteriore utilizzo nella costruzione di un modello di ruolo. Come risultato di questo audit, abbiamo avuto un registro dei sistemi IT, in cui sono stati determinati i loro parametri tecnici e sono state fornite le descrizioni. Inoltre, per ciascun sistema, è stato individuato un proprietario della direzione aziendale nel cui interesse lo stesso veniva gestito: era lui il responsabile dei processi aziendali serviti da tale sistema. È stato inoltre nominato un responsabile dei servizi IT, responsabile dell'implementazione tecnica delle esigenze aziendali per uno specifico SI. Sono stati registrati i sistemi più critici per l'azienda e i relativi parametri tecnici, i termini di messa in servizio e smantellamento, ecc.. Questi parametri sono stati molto utili nel processo di preparazione per la creazione di un modello di ruolo.

Passaggio 3 Creare una metodologia

La chiave del successo di qualsiasi attività è il metodo giusto. Pertanto, sia per costruire un modello che per condurre un audit, dobbiamo creare una metodologia in cui descrivere l’interazione tra i dipartimenti, stabilire la responsabilità nelle normative aziendali, ecc.
Per prima cosa è necessario esaminare tutti i documenti disponibili che stabiliscono la procedura per la concessione dell'accesso e dei diritti. In un buon modo, i processi dovrebbero essere documentati a diversi livelli:

• requisiti aziendali generali;
• requisiti per le aree di sicurezza delle informazioni (a seconda delle aree di attività dell'organizzazione);
• requisiti per i processi tecnologici (istruzioni, matrici di accesso, linee guida, requisiti di configurazione).

Nella nostra società finanziaria abbiamo trovato molti documenti obsoleti e abbiamo dovuto adattarli ai nuovi processi in fase di implementazione.

Per ordine della direzione è stato creato un gruppo di lavoro di cui facevano parte rappresentanti dei settori sicurezza, IT, economia e controllo interno. L'ordine delineava gli obiettivi della creazione del gruppo, la direzione delle attività, il periodo di esistenza e i responsabili di ciascuna parte. Inoltre, abbiamo sviluppato una metodologia di audit e una procedura per la costruzione di un modello di riferimento: sono state concordate da tutti i rappresentanti responsabili delle aree e approvate dal management dell’azienda.

Documenti che descrivono la procedura per lo svolgimento del lavoro, scadenze, responsabilità, ecc. - una garanzia che sulla strada verso l'obiettivo caro, che all'inizio non è ovvio a tutti, nessuno avrà domande "perché lo stiamo facendo, perché ne abbiamo bisogno, ecc." e non ci sarà alcuna possibilità di “saltare giù” o rallentare il processo.

Passaggio 4. Correggere i parametri del modello di controllo degli accessi esistente

Stiamo elaborando un cosiddetto “passaporto di sistema” in termini di controllo degli accessi. Si tratta in sostanza di un questionario su uno specifico sistema informativo, in cui vengono registrati tutti gli algoritmi per il controllo dell'accesso allo stesso. Le aziende che hanno già implementato soluzioni di classe IdM hanno probabilmente familiarità con tale questionario, poiché è qui che inizia lo studio dei sistemi.

Alcuni parametri relativi al sistema e ai proprietari sono confluiti nel questionario dal registro informatico (vedi fase 2, audit), ma ne sono stati aggiunti anche di nuovi:

• come vengono gestiti i conti (direttamente nel database o tramite interfacce software);
• come gli utenti accedono al sistema (utilizzando un account separato o utilizzando un account AD, LDAP, ecc.);
• quali livelli di accesso al sistema vengono utilizzati (livello di applicazione, livello di sistema, utilizzo del sistema delle risorse file di rete);
• descrizione e parametri dei server su cui gira il sistema;
• quali operazioni di gestione dell'account sono supportate (blocco, ridenominazione, ecc.);
• quali algoritmi o regole vengono utilizzati per generare l'identificativo utente del sistema;
• quale attributo può essere utilizzato per stabilire una connessione con la scheda di un dipendente nel sistema del personale (nome completo, numero del personale, ecc.);
• tutti i possibili attributi dell'account e le regole per compilarli;
• quali diritti di accesso esistono nel sistema (ruoli, gruppi, diritti atomici, ecc., esistono diritti nidificati o gerarchici);
• meccanismi di ripartizione dei diritti di accesso (per posizione, dipartimento, funzionalità, ecc.);
• Il sistema prevede regole per la segregazione dei diritti (SOD – Segregation of Duties) e come funzionano;
• come vengono trattati nel sistema gli eventi di assenza, trasferimento, licenziamento, aggiornamento dei dati dei dipendenti, ecc.

È possibile continuare l'elenco descrivendo in dettaglio i vari parametri e altri oggetti coinvolti nel processo di controllo degli accessi.

Passaggio 5. Creare una descrizione delle autorizzazioni orientata al business

Un altro documento di cui avremo bisogno quando costruiamo un modello di ruolo è un libro di riferimento su tutti i possibili poteri (diritti) che possono essere concessi agli utenti nel sistema informativo con una descrizione dettagliata della funzione aziendale che vi sta dietro. Spesso le autorità nel sistema vengono crittografate con determinati nomi costituiti da lettere e numeri e i dipendenti aziendali non riescono a capire cosa si nasconde dietro questi simboli. Poi vanno al servizio IT e lì... anche loro non possono rispondere alla domanda, ad esempio, sui diritti utilizzati raramente. Quindi è necessario eseguire ulteriori test.

È positivo se esiste già una descrizione dell'attività o anche se esiste una combinazione di questi diritti in gruppi e ruoli. Per alcune applicazioni, la procedura migliore consiste nel creare tale riferimento in fase di sviluppo. Ma questo non accade spesso, quindi ci rivolgiamo nuovamente al reparto IT per raccogliere informazioni su tutti i possibili diritti e descriverli. La nostra guida conterrà infine quanto segue:

• nome dell'autorità, compreso l'oggetto a cui si applica il diritto di accesso;
• un'azione che è consentita su un oggetto (visione, modifica, ecc., possibilità di limitazione, ad esempio, per base territoriale o per gruppo di clienti);
• codice di autorizzazione (codice e nome della funzione/richiesta di sistema eseguibile utilizzando l'autorizzazione);
• descrizione dell'autorità (descrizione dettagliata delle azioni nell'IS quando si applica l'autorità e le loro conseguenze per il processo;
• stato del permesso: “Attivo” (se il permesso è assegnato ad almeno un utente) o “Non attivo” (se il permesso non viene utilizzato).

Passaggio 6 Scarichiamo i dati sugli utenti e sui diritti dai sistemi e li confrontiamo con la fonte del personale

Nella fase finale della preparazione, è necessario scaricare i dati dai sistemi informativi su tutti gli utenti e sui diritti di cui dispongono attualmente. Ci sono due possibili scenari qui. Primo: il dipartimento di sicurezza ha accesso diretto al sistema e ha i mezzi per scaricare i report rilevanti, cosa che non accade spesso, ma è molto comoda. Secondo: inviamo una richiesta all'IT per ricevere i report nel formato richiesto. L'esperienza dimostra che non è possibile mettersi d'accordo con l'IT e ottenere i dati necessari la prima volta. È necessario effettuare diversi approcci finché le informazioni non vengono ricevute nella forma e nel formato desiderati.

Quali dati devono essere scaricati:

• Nome utente
• Nome completo 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 download dal sistema con tutti gli utenti e tutti i diritti loro concessi. E hanno immediatamente messo da parte tutti gli account bloccati, poiché il lavoro sulla costruzione di un modello sarà svolto solo per gli utenti attivi.

Quindi, se la tua azienda non dispone di mezzi automatizzati per bloccare l’accesso ai dipendenti licenziati (questo accade spesso) o dispone di un’automazione patchwork che non sempre funziona correttamente, è necessario identificare tutte le “anime morte”. Stiamo parlando dei conti dei dipendenti già licenziati, i cui diritti per qualche motivo non sono bloccati, devono essere bloccati. Per fare ciò, confrontiamo i dati caricati con la fonte del personale. Anche lo scarico del personale deve essere ottenuto in anticipo dal dipartimento che mantiene la banca dati del personale.

Separatamente, è necessario accantonare i conti i cui proprietari non sono stati trovati nel database del personale, non assegnati a nessuno, cioè senza proprietario. Utilizzando questo elenco ci servirà la data dell'ultimo utilizzo: se è abbastanza recente dovremo comunque cercarne i proprietari. Ciò può includere account di appaltatori esterni o account di servizio che non sono assegnati a nessuno, ma sono associati a qualsiasi processo. Per sapere a chi appartengono i conti è possibile inviare lettere a tutti i dipartimenti chiedendo loro di rispondere. Una volta trovati i proprietari, inseriamo i dati su di loro nel sistema: in questo modo vengono identificati tutti gli account attivi e il resto viene bloccato.

Non appena i nostri caricamenti verranno eliminati dai record non necessari e rimarranno solo gli account attivi, potremo iniziare a costruire un modello per un sistema informativo specifico. Ma di questo vi parlerò nel prossimo articolo.

Autore: Lyudmila Sevastyanova, responsabile della promozione Solar in Rights

Fonte: habr.com