{"id":87793,"date":"2020-07-10T13:41:57","date_gmt":"2020-07-10T11:41:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya"},"modified":"2020-07-10T13:41:57","modified_gmt":"2020-07-10T11:41:57","slug":"stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/stroim-rolevuyu-model-upravleniya-dostupom-chast-pervaya-podgotovitelnaya","title":{"rendered":"Costruiamo un modello di gestione degli accessi. Parte prima, preparativa","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Attualmente lavoro per un fornitore di software, in particolare nel settore delle soluzioni per la gestione degli accessi. La mia esperienza \"dalla vita precedente\" \u00e8 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 \u201cscottature\u201d per costruire un meccanismo funzionante di gestione dei diritti degli utenti nei sistemi informativi aziendali.
\n\"Costruiamo
\nUnendo 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 \u00e8 prepararsi a costruire il modello, la seconda \u00e8 costruirlo realmente. Davanti a voi c'\u00e8 la prima parte, quella preparatoria.
\n<\/a><\/noindex>
\nN.B.<\/b> La costruzione di un modello di ruoli \u00e8, sfortunatamente, pi\u00f9 un processo che un risultato. Anzi, \u00e8 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.
\n<\/i>
\nPrima di tutto, definiamo che cos'\u00e8 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. \u00c8 possibile farlo manualmente? Certo che no: \u00e8 per questo che sono nate le figure dei ruoli.<\/p>\n

Un ruolo \u00e8 un insieme di autorizzazioni necessarie a un utente o a un gruppo di utenti per svolgere determinati compiti lavorativi. Ogni dipendente pu\u00f2 avere uno o pi\u00f9 ruoli e ciascun ruolo pu\u00f2 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.<\/p>\n

\"Costruiamo
\n
\nI 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\u00e0 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 \u2013 in altre parole, a un insieme di reparti dell'azienda e alle posizioni che vi si trovano. Cos\u00ec si forma la matrice dei ruoli globale ( esempio fornito nella tabella sottostante).<\/p>\n

\"Costruiamo
\n
\n\u00c8 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, \u00e8 praticamente impossibile. E non \u00e8 nemmeno necessario. Infatti, il modello di ruolo non pu\u00f2 essere statico, poich\u00e9 dipende da un ambiente in continua evoluzione. E dal cambiamento delle attivit\u00e0 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, \u00e8 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\u00e0, se necessario, essere richiesto successivamente tramite richieste separati.<\/p>\n

Certo, puoi chiedere: \"E non esistono modelli di ruolo al 100%?\" Beh, s\u00ec, \u00e8 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 \u00e8 al primo posto. Esistono anche in strutture commerciali, ma all'interno di un singolo dipartimento, il cui lavoro \u00e8 un processo sufficientemente statico e prevedibile.<\/p>\n

Il principale vantaggio della gestione per ruolo \u00e8 la semplificazione dell'assegnazione dei diritti, poich\u00e9 il numero di ruoli \u00e8 notevolmente inferiore a quello degli utenti del sistema informatico. Questo \u00e8 valido per qualsiasi settore.<\/p>\n

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

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

Tutti coloro che sono interessati a come sia nata la gestione dei ruoli nell'accesso possono
\n immergersi in un excursus storico<\/b>
\n Se diamo un'occhiata alla storia, possiamo vedere che la comunit\u00e0 IT ha cominciato a riflettere sui metodi di gestione dell'accesso gi\u00e0 negli anni '70 del XX secolo. Anche se le applicazioni erano allora piuttosto semplici, cos\u00ec come oggi, a tutti sarebbe piaciuto gestire facilmente l'accesso a esse. Fornire, modificare e controllare i diritti degli utenti \u2013 in modo da capire pi\u00f9 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.<\/p>\n

Oggi conosciamo gi\u00e0 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.<\/p>\n

Il primo e, probabilmente, il modello pi\u00f9 semplice \u00e8 la gestione degli accessi discrezionale<\/b> (DAC \u2013 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 \u00e8 stato ritenuto troppo flessibile e complesso da gestire: le liste di accesso nel tempo diventano enormi e difficili da controllare.<\/p>\n

Il secondo modello \u00e8 Controllo degli accessi obbligatorio (MAC - Mandatory access control)<\/b>. 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 \u00e8 risultato troppo rigoroso e limitativo. La sua applicabilit\u00e0 non si giustifica quando in un'azienda ci sono molteplici risorse informative variegate: per separare l'accesso a diverse risorse, sar\u00e0 necessario introdurre molte categorie che non si sovrapporranno.<\/p>\n

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

La prima struttura della modellazione basata sui ruoli \u00e8 stata chiaramente delineata dagli scienziati americani David Ferraiolo e Richard Kuhn del National Institute of Standards and Technology degli Stati Uniti nel 1992. \u00c8 stato allora che \u00e8 emerso per la prima volta il termine RBAC (Controllo degli accessi basato sui ruoli). <\/b>Queste ricerche e le descrizioni dei componenti principali, cos\u00ec 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).<\/p>\n

Lo standard definisce il ruolo come \u00abuna funzione lavorativa nel contesto di un'organizzazione con una certa semantica correlata in relazione ai poteri e alle responsabilit\u00e0 attribuiti all'utente designato per quel ruolo\u00bb. Il documento stabilisce gli elementi chiave del RBAC - utenti, sessioni, ruoli, permessi, operazioni e oggetti, cos\u00ec come le relazioni e le interazioni tra di essi.<\/p>\n

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\u00e0 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 \u00abdipendente\u00bb, e non sar\u00e0 necessario elencare di volta in volta tutti i diritti elementari in ciascuno dei ruoli di livello superiore. Basta semplicemente indicare il segno di ereditariet\u00e0 del ruolo \u00abdipendente\u00bb.<\/p>\n

\"Costruiamo
\n
\nSuccessivamente, lo standard \u00e8 stato arricchito con nuovi attributi di accesso, legati a un ambiente in continua evoluzione. \u00c8 stata aggiunta la possibilit\u00e0 di introdurre restrizioni statiche e dinamiche. Le restrizioni statiche implicano l'impossibilit\u00e0 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.<\/p>\n

Vale la pena menzionare la gestione degli accessi basata sugli attributi (ABAC \u2014 Attribute-based access control).<\/b> L'approccio si basa sulla concessione di accesso attraverso regole di condivisione degli attributi. Questo modello pu\u00f2 essere utilizzato in modo indipendente, ma spesso integra attivamente il classico modello basato su ruoli: \u00e8 possibile aggiungere attributi degli utenti, delle risorse e dei dispositivi, nonch\u00e9 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\u00ec la sicurezza.<\/p>\n

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

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\u00e0 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\u00e0 territoriali della banca.<\/p>\n

E ora parliamo dei passaggi preparatori necessari, senza i quali non \u00e8 possibile costruire un modello di ruoli funzionante.<\/p>\n

Passo 1. Creiamo un modello funzionale<\/h2>\n

\n\u00c8 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\u00e9 il modello di ruolo possa riferirsi ad esso. Ad esempio, se si intende costruire un modello di ruolo basato sui diritti gi\u00e0 esistenti dei dipendenti, scaricati dal sistema e<\/p>\n

Passo 2. Audit dei sistemi IT e pianificazione della priorit\u00e0<\/h2>\n

\nNella seconda fase, \u00e8 necessario condurre un audit dei sistemi IT per capire come \u00e8 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 \u00e8 semplicemente impossibile, bisogna iniziare da qualche parte. Abbiamo effettuato un'analisi approfondita del processo di gestione degli accessi per determinare il livello di maturit\u00e0. Durante l'analisi abbiamo sviluppato criteri per la prioritizzazione dei sistemi informativi - criticit\u00e0, 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.<\/p>\n

Quindi, come determinare la criticit\u00e0 di un sistema? Rispondete a queste domande:<\/p>\n