{"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, preparatoria","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Attualmente lavoro per un vendor di software, in particolare soluzioni per la gestione degli accessi. Il mio bagaglio di esperienze, nella mia \u2018vita precedente\u2019, proviene dalla parte cliente \u2013 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\u00e0 per costruire un meccanismo efficace di gestione dei diritti degli utenti nei sistemi informativi.
\n\"Costruiamo
\nUnendo la mia esperienza maturata come cliente con le competenze e le conoscenze da vendor, desidero condividere con voi un\u2019istruzione sostanzialmente passo-passo: come creare un modello di gestione degli accessi in una grande azienda e quali benefici questo porter\u00e0. La mia guida \u00e8 divisa in due parti: la prima \u00e8 la preparazione per costruire il modello, la seconda \u00e8 la sua realizzazione. Davanti a voi c'\u00e8 la prima parte, preparatoria.
\n<\/a><\/noindex>
\nN.B.<\/b> Costruire un modello di ruolo \u00e8, purtroppo, un processo e non un risultato. Piuttosto, \u00e8 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.
\n<\/i>
\nIniziamo a chiarire: che cos'\u00e8 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. \u00c8 possibile farlo manualmente? Certamente no: per risolvere questo problema sono state introduzioni i ruoli.<\/p>\n

Il ruolo \u00e8 un insieme di autorizzazioni necessarie per un utente o un gruppo di utenti per svolgere determinate attivit\u00e0 lavorative. Ogni dipendente pu\u00f2 avere uno o pi\u00f9 ruoli e ogni ruolo pu\u00f2 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.<\/p>\n

\"Costruiamo
\n
\nLe 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\u00e0 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 \u2013 in altre parole, all'insieme delle unit\u00e0 aziendali e alle posizioni al loro interno. In questo modo si forma una matrice di ruoli globali (esempio fornito nella tabella sottostante).<\/p>\n

\"Costruiamo
\n
\n\u00c8 importante sottolineare che costruire un modello di ruolo al 100%, garantendo a ciascun dipendente in una struttura commerciale tutti i diritti necessari, \u00e8 semplicemente impossibile. E non \u00e8 neanche necessario. Un modello di ruolo non pu\u00f2 essere statico, poich\u00e9 dipende da un ambiente in continua evoluzione. Inoltre, il cambiamento nell'attivit\u00e0 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, \u00e8 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.<\/p>\n

Certo, puoi chiedere: \u00abEsistono davvero modelli di ruolo al 100%?\u00bb Beh, s\u00ec, 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 \u00e8 una priorit\u00e0. A volte anche all'interno di strutture commerciali, ma in un'unit\u00e0 specifica, dove il lavoro \u00e8 un processo abbastanza statico e prevedibile.<\/p>\n

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

Prendiamo un'azienda di retail: in essa lavorano migliaia di venditori, ma il set di diritti nel sistema N \u00e8 lo stesso per tutti, e per loro verr\u00e0 creata un'unica ruolo. Quando un nuovo venditore entra in azienda, gli viene automaticamente assegnato il ruolo adeguato nel sistema, che gi\u00e0 include tutte le autorizzazioni necessarie. Inoltre, con un solo clic, \u00e8 possibile modificare i diritti per migliaia di venditori contemporaneamente, ad esempio, aggiungere una nuova opzione per la generazione di rapporti. Non \u00e8 necessario eseguire mille operazioni, collegando il nuovo diritto a ciascun account: basta inserire questa opzione nel ruolo, e apparir\u00e0 per tutti i venditori simultaneamente.<\/p>\n

Un altro vantaggio della gestione dei ruoli \u00e8 l'esclusione dell'assegnazione di autorizzazioni incompatibili. Cio\u00e8, un dipendente che ha un determinato ruolo nel sistema non pu\u00f2 avere contemporaneamente un altro ruolo, i cui diritti non devono combinarsi con quelli del primo. Un chiaro esempio \u00e8 il divieto di cumulare le funzioni di inserimento e controllo delle operazioni finanziarie.<\/p>\n

Tutti coloro che sono interessati a capire come \u00e8 nata la gestione dei diritti per ruolo possono
\n immergersi in un'escursione nella storia<\/b>
\n Guardando alla storia, \u00e8 nel corso degli anni '70 che la comunit\u00e0 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.<\/p>\n

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.<\/p>\n

Il primo e, probabilmente, il modello pi\u00f9 semplice \u00e8 la gestione degli accessi discrezionale<\/b> (DAC \u2013 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 \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 il controllo di accesso obbligatorio (MAC \u2014 Mandatory Access Control)<\/b>. 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 \u00e8 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\u00e0 necessario introdurre molte categorie che non si sovrapporranno.<\/p>\n

A causa delle evidenti imperfezioni di questi due metodi, la comunit\u00e0 IT ha continuato a sviluppare modelli pi\u00f9 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!<\/b> Questo approccio si \u00e8 rivelato il pi\u00f9 promettente, poich\u00e9 richiede non solo l'autenticazione dell'utente, ma anche le sue funzioni lavorative nei sistemi.<\/p>\n

La prima struttura della modello basato sui ruoli \u00e8 stata chiaramente descritta dai ricercatori americani David Ferraiolo e Richard Kuhn del National Institute of Standards and Technology degli Stati Uniti nel 1992. Allora \u00e8 emerso per la prima volta il termine RBAC (Role-Based Access Control). <\/b>Queste ricerche e le descrizioni dei componenti principali, cos\u00ec 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).<\/p>\n

Lo standard definisce il ruolo come \"una funzione all'interno dell'organizzazione con una certa semantica relativa ai poteri e alle responsabilit\u00e0 attribuite all'utente assegnato a quel ruolo\". Il documento stabilisce gli elementi di base dell'RBAC \u2013 utenti, sessioni, ruoli, permessi, operazioni e oggetti, nonch\u00e9 le relazioni e le interconnessioni tra di essi.<\/p>\n

Lo standard fornisce la struttura minima necessaria per costruire un modello di ruoli \u2013 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\u00e0 dei poteri. Infatti, in ogni azienda esistono ruoli che raggruppano poteri elementari necessari a tutti i dipendenti. Questo pu\u00f2 includere l'accesso alla posta elettronica, al sistema di gestione documentale, al portale aziendale e cos\u00ec 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. \u00c8 sufficiente semplicemente indicare il segno di eredit\u00e0 del ruolo \"dipendente\".<\/p>\n

\"Costruiamo
\n
\nIn seguito, lo standard \u00e8 stato aggiornato con nuovi attributi di accesso che si adattano a un ambiente in continua evoluzione. \u00c8 stata introdotta la possibilit\u00e0 di implementare limitazioni statiche e dinamiche. Le limitazioni statiche implicano l'impossibilit\u00e0 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\u00ec via.<\/p>\n

\u00c8 importante menzionare il controllo accessi basato su attributi (ABAC \u2014 Attribute-based access control).<\/b> Questo approccio si basa sull'offerta di accesso tramite regole di condivisione degli attributi. Questo modello pu\u00f2 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\u00ec la sicurezza.<\/p>\n

Ad esempio, \u00e8 possibile consentire l'accesso ai conti a un contabile se opera in una specifica regione. In questo caso, la posizione dello specialista verr\u00e0 confrontata con un valore di riferimento specifico. Oppure si pu\u00f2 dare accesso ai conti solo se l'utente si autentica da un dispositivo registrato nell'elenco di autorizzazioni. \u00c8 un buon complemento al modello di ruolo, ma viene utilizzato raramente da solo a causa della necessit\u00e0 di creare molte regole e tabelle di autorizzazioni o restrizioni.<\/p>\n

Facciamo un esempio di applicazione dell'ABAC dalla mia \u2018vita precedente\u2019. Nel nostro istituto bancario c\u2019erano 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 \u2013 e cos\u00ec abbiamo creato un numero davvero elevato di ruoli con funzionalit\u00e0 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\u00e0 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\u2019istituto.<\/p>\n

Ora parliamo dei passi preparatori necessari, senza i quali \u00e8 semplicemente impossibile costruire un modello di ruolo funzionante.<\/p>\n

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

\nIniziare con la creazione di un modello funzionale: un documento di alto livello che descriva in dettaglio le funzionalit\u00e0 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\u00e0 esistenti dei dipendenti - estratti dal sistema e \"uniformati\". Durante l'approvazione dei ruoli ottenuti con il proprietario del business, si pu\u00f2 fare riferimento a un punto specifico del modello funzionale, sul quale si basa l'inclusione di un diritto o di un altro nel ruolo.<\/p>\n

Passo 2. Auditi i sistemi IT e redatto un piano di priorit\u00e0<\/h2>\n

\nNella seconda fase, \u00e8 necessario effettuare un audit dei sistemi IT per comprendere come \u00e8 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 \u2014 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 \u00e8 semplicemente impossibile, bisogna iniziare da qualche parte. Abbiamo condotto un'analisi approfondita del processo di gestione dell'accesso per determinarne il livello di maturit\u00e0. Durante l'analisi, abbiamo sviluppato criteri di priorit\u00e0 per i sistemi informativi \u2014 criticit\u00e0, 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.<\/p>\n

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