Segregazione dei ruoli

Internet: un mondo senza confini

Qual è una delle più grandi sfide per le aziende oggigiorno? Probabilmente è rappresentata da quei confini sempre più labili della loro rete informatica. L'accesso alla rete aziendale non è più limitato a un numero circoscritto di dipendenti. Infatti l'accesso alle informazioni e ai servizi aziendali si estende a chiunque abbia accesso a Internet. Per questo motivo molte aziende stanno aprendo i propri sistemi a clienti, partner commerciali e fornitori di servizi per abilitare modelli di self service che forniscono vantaggi economici e consentono la scelta.

Quando la parola "privacy" acquisisce una nuova accezione

Insieme con, e probabilmente, causato da questa rete in espansione stanno crescendo preoccupazioni sulla privacy. La legislazione sulla privacy sia nel settore sanitario che in quello finanziario non è mai stata più attiva. Questa legislazione richiede alle imprese di implementare controlli più severi sull'accesso alle informazioni sui clienti. La privacy introduce l'elemento di scelta, in cui i veri proprietari dei dati hanno voce nel modo in cui i loro dati vengono utilizzati.

In questa pagina discuteremo i concetti di autorizzazione attraverso l'Enterprise e presenteremo le nuove sfide del controllo degli accessi nell'ambiente attuale. Man mano che sempre più risorse di informazione vengono messe a disposizione di un numero sempre crescente di entità, i metodi tradizionali di controllo degli accessi diventano ingestibili.

Molte grandi ditte, come American Express, si stanno anche muovendo per suddividere le applicazioni di grandi dimensioni in componenti autosufficienti di piccole dimensioni. Questi componenti consentono di assemblare le applicazioni più rapidamente e sono più facili da gestire rispetto ai loro predecessori monolitici. Possono anche essere condivisi con altri componenti all'interno dell'azienda o oltre i confini dell'organizzazione. Questo ha presentato un nuovo problema per la protezione delle applicazioni. Non è più necessario che un'entità si identifichi in una singola applicazione. In un'architettura basata su componenti, un contesto di sicurezza deve essere passato insieme a tutti i componenti richiamati durante l'esecuzione di una transazione.

L'altro fattore trainante in queste aziende è l'esigenza di integrare i servizi di sicurezza in modo che siano riutilizzabili, inclusi Identity Management, autenticazione e autorizzazione. Questo requisito ridurrà il sovraccarico e la manutenzione richiesti dai sistemi attuali con sistemi di sicurezza eterogenei e politiche di sicurezza ingestibili. Questi servizi saranno esposti alle applicazioni e agli utenti per il consumo.

Panoramica sulle autorizzazioni

Uno dei requisiti più importanti di qualsiasi applicazione sicura è fornire un accesso controllato alle sue risorse. Il controllo degli accessi è un meccanismo che viene utilizzato per limitare l'accesso solo alle entità "di fiducia" che hanno bisogno di un'azienda di utilizzare una particolare risorsa. Questa cosa può garantire un accesso di controllo che contribuirà a garantire la riservatezza, l'integrità e la disponibilità delle risorse dell'applicazione.

• La riservatezza assicura che le informazioni vengano divulgate solo alle persone autorizzate. Le persone autorizzate sono determinate in base alla politica aziendale, ai regolamenti e al principio della necessità di sapere. Il principio del bisogno di sapere è un concetto in cui l'accesso alle informazioni è concesso solo quando è richiesto per completare un lavoro o un compito.

• L'integrità protegge le risorse da modifiche non autorizzate se tali modifiche sono accidentali o dannose. Una protezione per la protezione dell'integrità è l'uso del principio dei privilegi minimi. Il principio meno privilegiato garantisce che gli utenti dispongano solo delle autorizzazioni necessarie per svolgere le proprie mansioni lavorative e nient'altro.

• La disponibilità garantisce che le risorse di sistema siano accessibili quando necessario e da coloro che ne hanno bisogno.

Esistono varie forme di controllo degli accessi. Alcuni metodi limitano l'accesso fisico alle risorse mentre altri metodi implementano le procedure amministrative. Questo documento descrive l'autorizzazione che è un metodo logico implementato nel software. L'autorizzazione è l'atto di concedere a un soggetto l'accesso a un oggetto. Un oggetto fa riferimento a un'entità con un'identità conosciuta per il dominio di sicurezza e un oggetto fa riferimento a qualsiasi risorsa protetta all'interno del dominio di sicurezza. Un prerequisito di una decisione di autorizzazione è l'identificazione e l'autenticazione dell'utente che sta tentando l'accesso. Per ulteriori informazioni sull'autenticazione, consultare il white paper sull'autenticazione.

Un altro prerequisito per l'esecuzione di una decisione di autorizzazione è la definizione della politica di sicurezza. Una politica di sicurezza definisce le regole della società in merito ai privilegi di accesso e queste regole rappresentano le politiche e le pratiche dell'organizzazione nonché le leggi e i regolamenti con i quali l'organizzazione deve attenersi. La gestione dell'accesso alle risorse fa riferimento al processo di definizione di una politica, all'implementazione di una politica e all'applicazione di tale politica.

Utilizzando il modello concettuale di Anderson, un sistema di autorizzazione consiste in una politica di sicurezza e un monitor di riferimento (RF). La politica di sicurezza contiene le regole che concedono o negano l'accesso alle risorse dell'organizzazione. Il monitor di riferimento è responsabile del monitoraggio dell'accesso agli oggetti per soggetto. L'accesso agli oggetti è garantito passando attraverso il monitor di riferimento.

La RF è responsabile dell'applicazione della politica di sicurezza e dell'auditing di tutti i tentativi di accesso, sia che abbiano avuto successo o meno. Le informazioni di audit dovrebbero essere impegnate per l'archiviazione permanente prima di consentire l'accesso per garantire che non sia consentito alcun accesso fino a quando non è stata creata una registrazione di verifica permanente. Per rafforzare la responsabilità, le informazioni di controllo dovrebbero includere, ma non limitarsi a quanto segue:

  • Data e ora di accesso
  • Nome soggetto
  • Nome dell'oggetto
  • Tipo di accesso (leggi, aggiorna, ecc.)
  • Risultato di accesso (successo o fallimento)
sap-grafico1 ita
sap grafico 2 ita

Tradizionalmente, le informazioni di controllo includono l'argomento come è noto dal dominio di sicurezza locale. Oggigiorno, l'identità del soggetto potrebbe non essere nota al dominio di sicurezza che applica la politica.

Invece, tutto ciò che si può sapere sull'argomento sono attributi necessari per determinare se l'accesso è consentito. In questo caso, le informazioni di controllo devono includere un collegamento al sistema di identità che ha fornito gli attributi sull'argomento. Logicamente, il monitor di riferimento è costituito da un componente che determina se l'accesso è consentito e un componente che impone la decisione. Questi componenti sono chiamati rispettivamente punto di decisione politica (PDP) e punto di applicazione della politica (PEP).

In questa immagine, il PEP riceve la richiesta iniziale di risorse ma fa affidamento sul PDP per valutare se la richiesta debba essere soddisfatta o meno. Il PEP fornisce i dati oggetto, oggetto e operazione sulla richiesta al PDP, che trova una politica corrispondente e applica tale logica per valutare se l'accesso debba essere concesso o negato. La risposta viene rispedita al PEP, a quel punto può essere intrapresa l'azione necessaria.

Determinazione dell'accesso
Determinare se l'accesso è concesso può essere basato sulla discrezione dell'amministratore della sicurezza o può essere imposto inevitabilmente dal sistema di sicurezza. I metodi di controllo degli accessi discrezionali e non discrezionali sono due metodi distinti per determinare l'accesso.

Controllo di accesso discrezionale
Il tipo più comune di controllo dell'accesso è il controllo di accesso discrezionale (DAC). Con DAC, l'accesso agli oggetti è concesso esplicitamente per nome. Un nome può essere un soggetto o un gruppo di soggetti. La distinzione principale di DAC è che l'accesso è concesso a discrezione delle persone incaricate dell'attuazione della politica di controllo degli accessi. Le persone possono essere o il proprietario delle risorse o il custode delle risorse.

In DAC, i soggetti hanno accesso esplicito alle risorse inserendo i privilegi in una matrice di controllo degli accessi (ACM). L'ACM consiste di righe di soggetti e colonne di oggetti. Le voci all'interno della matrice specificano il tipo di accesso consentito.

L'ACM di solito non è implementato in quanto tale poiché tende ad essere molto scarso quando un soggetto non ha accesso ad un oggetto. Al contrario, gli elenchi di controllo di accesso (ACL) vengono comunemente implementati. Un ACL corrisponde a una colonna nella matrice. L'elenco specifica i soggetti a cui è consentito l'accesso e il tipo di accesso consentito. Quando viene effettuato un tentativo di accesso, il monitor di riferimento cerca il soggetto nell'ACL e determina se l'accesso è consentito.

L'ACM può anche essere implementato utilizzando un elenco di capacità. Un elenco di capacità corrisponde a una riga nella matrice di accesso. Durante un tentativo di accesso, il monitor di riferimento controlla l'elenco delle capacità per determinare se l'oggetto a cui si accede è incluso nell'elenco delle capacità del soggetto. DAC consente una granularità fine nella definizione delle politiche di controllo degli accessi poiché l'accesso può essere controllato su un "oggetto" -soggetta "o" oggetto per oggetto ". Questo, tuttavia, è anche uno dei suoi punti deboli. Gestire le politiche di controllo degli accessi su base individuale può rapidamente diventare un processo noioso quando ci sono milioni di soggetti e oggetti. Inoltre, quando i doveri di un soggetto cambiano, la revoca delle autorizzazioni non è sempre ovvia.

Controllo di accesso non discrezionale
La maggior parte delle politiche di controllo degli accessi può essere descritta in base alle caratteristiche dell'oggetto o dell'oggetto a cui si accede. Ad esempio, "consenti a tutti i gestori di accedere alle informazioni sui salari" è una politica basata su una caratteristica del soggetto (soggetti che sono gestori) e dell'oggetto (oggetti relativi alle informazioni sui salari). L'implementazione di questa stessa politica con DAC richiede che l'amministratore della sicurezza Identificare prima tutti i soggetti che sono "manager" e quindi concedere a tali soggetti l'accesso esplicito a tutti gli oggetti "informazioni sui salari". Questo tipo di implementazione richiede una manutenzione costante delle politiche di controllo degli accessi. I titoli dei processi di modifica delle modifiche e le risorse vengono aggiunti ed eliminati.

Invece, i criteri di controllo degli accessi non discrezionali (NDAC) sono definiti in base agli attributi che descrivono l'oggetto o l'oggetto. NDAC impone la politica di sicurezza a tutti i soggetti del sistema poiché la decisione di autorizzazione si basa solo su questi attributi. I proprietari dei dati e i custodi non possono assegnare selettivamente le autorizzazioni per soggetto in base a quanto consentito con DAC.

Spesso, quando si determinano le autorizzazioni, è necessario prendere in considerazione una combinazione di diversi fattori. Tali fattori potrebbero includere

Attributi del soggetto

  • Ruolo
  • Livello di sicurezza
  • Organizzazione
  • Età

Attributi dell'oggetto

  • Soddisfare
  • Classificazione

Relazione tra soggetto e oggetto

  • Proprietario dell'oggetto
  • Creatore dell'oggetto

Relazione tra il soggetto e un altro soggetto che ha una relazione con l'oggetto

  • Consulente del proprietario dell'account
  • Genitore per lo spettatore di un film

Attributi (s) dell'oggetto

  • Soddisfare
  • Classificazione

Contesto storico

  • Tentativi di accesso fallito
  • Tentativi di accesso riusciti
  • Altri materiali già accessibili

Attributi dell'oggetto

Molte volte l'accesso dipende da alcune caratteristiche del soggetto. Ad esempio, l'implementazione di una politica che stabilisce "consentire l'accesso se il soggetto è una banda 35 o superiore" è una politica che dipende da qualcosa sull'argomento, in particolare, il livello di banda. La definizione delle politiche in base agli attributi dei soggetti consente alle definizioni dei criteri di essere più concisi. Invece di concedere l'accesso esplicito a tutti i soggetti che sono in banda 35 o superiore (come nel caso del DAC), è possibile fare una dichiarazione politica. Ciò riduce anche la manutenzione necessaria in quanto i dipendenti si spostano tra le bande.

Un aspetto importante di questo esempio è che alla politica non interessa davvero conoscere la vera identità del soggetto. Un sistema di valutazione che implementa questa politica ha solo bisogno di accertare il livello di banda del soggetto da una fonte attendibile. Ciò si discosta dalle tipiche implementazioni di autorizzazione in cui il sistema di sicurezza mantiene tutti gli attributi del soggetto su cui si basano le decisioni di autorizzazione.

L'implementazione di una politica di relazione soggetto-oggetto di solito dipende da una relazione commerciale solitamente memorizzata nell'applicazione. La relazione può anche essere memorizzata nel sistema di sicurezza, tuttavia ciò richiede una duplicazione della relazione e forza un processo di sincronizzazione che è ridondante, costoso e soggetto a errori. La strategia di Adaptive Architecture Security e i modelli di progettazione di Edelen descrivono il concetto di un ruolo dinamico. I ruoli dinamici sono determinati dalle componenti aziendali in base alla relazione tra soggetto e oggetto. I componenti aziendali sono responsabili della restituzione di un ruolo dinamico al sistema di autorizzazione in base all'oggetto a cui l'oggetto sta tentando di accedere. L'utilizzo di ruoli dinamici consente di gestire relazioni complesse da componenti aziendali mantenendo al contempo la politica di autorizzazione centrale

Mentre potrebbe essere allettante implementare politiche di controllo degli accessi basate su numerosi attributi di soggetto, le politiche dovrebbero cercare di basare la politica su un numero minimo di attributi; idealmente, un attributo soggetto singolare come il ruolo. I ruoli forniscono coerenza nella definizione della politica di sicurezza e stanno diventando il metodo accettato di descrivere i diritti di accesso in applicazioni che supportano la sicurezza.

Attributi dell'oggetto

Alcune politiche di controllo accessi sono basate sul contenuto o sul contesto della risorsa a cui si accede. Utilizzando gli attributi dell'oggetto, le politiche possono essere implementate in base a un raggruppamento di oggetti. Ad esempio, "a Bob è consentito l'accesso a tutte le informazioni proprietarie" è necessario che il sistema di controllo accessi conosca qualcosa sull'oggetto. In questo esempio, la classificazione degli attributi dell'oggetto può essere utilizzata per determinare i diritti di accesso. Un altro esempio di attributi dell'oggetto combinato con RBAC è il criterio "Consenti a tutti i CSR MYCA la possibilità di reimpostare qualsiasi ID utente che abbia il servizio MYCA". In questo caso, la politica dipende sia dall'attributo del soggetto (ruolo della CSR) sia dall'attributo dell'oggetto (servizi dell'utente.)

Le politiche di accesso possono spesso essere descritte sulla base di una relazione tra soggetto e oggetto. Ad esempio, l'affermazione "consenti ad ogni titolare di carta di accedere per visualizzare il proprio saldo della carta" è una definizione concisa di una politica di sicurezza. La stessa politica potrebbe essere implementata con DAC utilizzando diversi milioni di dichiarazioni:

"Consentire a Bob di visualizzare il saldo della carta per la carta 3746 123456 01001"
"Consenti a Alice di visualizzare lo storico delle transazioni per la scheda 3782 123456 01001"
"Consentire ad Elaine di eseguire qualsiasi azione sulla carta" 3731 123456 01001 "
...
Questa non è un'implementazione molto efficiente poiché richiede una costante manutenzione della politica di sicurezza. È anche possibile che il vero intento della politica di sicurezza sia perso. Cosa succede se ad Alice viene concesso l'accesso alla carta sbagliata? Se Alice riceve una nuova carta, deve aspettare che qualcuno o qualche processo aggiunga la sua carta all'ACL. Invece, la vera politica di sicurezza dipende da una relazione tra soggetto e oggetto. In questo esempio, la politica di sicurezza rappresenta la relazione tra Alice e il saldo della carta per la carta 3782 123456 01001.

Relazione soggetto-oggetto-oggetto

A volte la relazione tra soggetto e oggetto non è diretta. La politica "Consenti a un broker del cliente di eseguire operazioni per conto del cliente" è un esempio in cui il soggetto (broker) non ha una relazione diretta con l'oggetto (conto di intermediazione del cliente). Invece, il broker ha una relazione con il cliente (è il broker del cliente) e il cliente ha la relazione con l'oggetto (è il proprietario dell'account). È con questa relazione indiretta che l'accesso è garantito.

sap grafico 2 ita

È anche possibile che la relazione soggetto-soggetto non sia diretta. Considerare il caso in cui l'assistente del broker (Para-planner) richiede un accesso limitato all'account del cliente. La politica potrebbe essere definita come "consentire al Parallelettore del broker di visualizzare i saldi dei conti di tutti i clienti del broker.

sap grafico 4 ita

Questi tipi di politiche di relazione possono essere applicate utilizzando DAC, tuttavia la politica non può essere dichiarata in modo conciso. Ad esempio, tutti i progettisti di Para possono ottenere un accesso esplicito agli account che gestiscono a discrezione dell'amministratore della politica. Tuttavia, quando i clienti cambiano broker o i paracadutisti vengono assegnati a diversi broker, la politica di sicurezza deve essere modificata per riflettere tali cambiamenti. È importante sottolineare che, sebbene il controllo dell'accesso basato sulla relazione possa essere molto potente, può anche essere estremamente inefficiente se le relazioni non vengono implementate in modo efficiente. Si presume che le applicazioni implementino un'adeguata quantità di denormalizzazione di queste relazioni per fornire un accesso efficiente per componenti aziendali e di sicurezza.

Delegata

La delega è l'atto di trasferire i propri diritti di accesso a un altro soggetto. L'oggetto potrebbe essere un altro utente del sistema o un processo che agisce per conto dell'utente. La delega è il caso specifico di una relazione soggetto-soggetto. Ad esempio, "Bob può inviare e-mail per conto di Alice mentre è in vacanza" crea una relazione tra Alice e Bob. Bob è il delegato di Alice mentre è via in vacanza.

Le autorizzazioni che vengono passate possono essere temporanee o indefinite. Il delegante si riserva il diritto di revocare le autorizzazioni di accesso in qualsiasi momento. I diritti possono anche essere delegati temporaneamente e quindi automaticamente revocati dal sistema o dalle applicazioni in una data specifica o dopo un periodo specificato. Poiché la delega comprende l'assegnazione di un'attività, una funzione di lavoro, un'applicazione o un'intera identità e può essere basata sul contesto, le informazioni rilevanti per la delega, compreso il contesto, sarebbero parte integrante del sistema di gestione delle identità.

Le autorizzazioni delegate sono concesse a discrezione dei soggetti che già possiedono le autorizzazioni da delegare. Un soggetto non deve essere autorizzato a delegare le autorizzazioni che non hanno già.

Anche il diritto di delegare deve essere controllato. La politica deve specificare gli argomenti a cui è consentito eseguire la delega e le autorizzazioni che possono essere delegate. La politica dovrebbe anche specificare il livello di delega consentito. Ad esempio, se Alice delega le sue funzioni email a Bob, Bob può delegare a sua volta tali autorizzazioni a Bill? La delega eseguita a discrezione di un utente non è semplice quanto la definizione di una relazione tra un delegante e un delegato. Considera il caso in cui Bob delega le sue funzioni di posta elettronica ad Alice. Bob vuole concedere ad Alice il diritto di leggere la sua e-mail e il calendario, ma ad Alice è vietato inviare e-mail per conto di Bob o aggiornare il suo calendario. In questo caso, il sistema di controllo accessi deve mantenere le regole definite da Bob. Queste regole possono essere diverse dalle regole di delega che altri utenti del sistema decidono di utilizzare. Nel caso di delega discrezionale, le politiche di sicurezza concise che utilizzano le relazioni non si applicano più. Invece, le politiche di controllo degli accessi discrezionali devono essere implementate.

Richiedi contesto

Molte politiche di controllo degli accessi tengono conto del contesto della richiesta. Le politiche che applicano restrizioni temporali e di origine sono esempi di questi tipi di politiche. Ad esempio, "le operazioni di intermediazione possono avvenire solo durante le ore di negoziazione" impone un limite di tempo. Esempi di restrizioni all'origine sono "le politiche di sicurezza possono essere amministrate solo dall'indirizzo IP 10.70.5.5." O "la richiesta deve avvenire su una connessione che fornisce riservatezza." Questi tipi di politiche assicurano che la richiesta provenga da una posizione sicura o protetta connessione. Un altro esempio di contesto di richiesta è una politica che richiede una password da inviare insieme alla richiesta. In questo caso, un attributo sulla richiesta deve essere confrontato con un attributo dell'oggetto.

Concorso storico

Le politiche di controllo dell'accesso possono anche essere basate su eventi che sono già accaduti. Un esempio di questo tipo di politica è noto come Muro cinese di sicurezza. Questa politica tenta di prevenire i conflitti di interesse limitando l'accesso alle informazioni in base a ciò che il soggetto ha già visualizzato. Questa politica viene implementata classificando le informazioni in categorie di conflitto di interesse. Una volta che un soggetto ha visualizzato informazioni in una particolare classe, un "muro" è costruito attorno a tutte le altre informazioni della stessa classe. Al soggetto è vietato per sempre di visualizzare le informazioni della stessa classe. Questo tipo di politica viene solitamente implementato presso società di consulenza in cui ai dipendenti viene impedito di visualizzare informazioni simili da parte di società diverse. Un altro esempio di utilizzo del contesto storico è durante l'applicazione di una separazione dinamica della politica del dazio. Alcune politiche vietano che lo stesso soggetto dal sistema tenga conto degli eventi storici verificatisi in una transazione. La separazione dinamica dei compiti (DSD) è descritta in maggior dettaglio nella prossima sezione.

Discretionary Access Cont

grafico 4 ita

L'RBAC può anche essere utilizzato per attuare una politica di separazione dei compiti. La separazione dei compiti è un concetto di sicurezza che suddivide le attività aziendali in attività separate in modo che a un individuo non sia consentito di completare da solo le operazioni di business. Ad esempio, non è desiderabile concedere privilegi a chi invia le spese e approvare le spese alla stessa persona. Assegnare entrambe le capacità allo stesso individuo può portare a conflitti di interesse quando gli approvatori sono autorizzati ad approvare i propri report di spesa, riducendo la garanzia di integrità dei dati. Per rafforzare la separazione dei compiti, alcune implementazioni di RBAC limitano i ruoli che possono essere attivati ​​contemporaneamente o per una determinata transazione.

Molti prodotti dei fornitori ora includono il supporto per RBAC, ma attualmente non vi è alcun consenso su quali funzionalità sono richieste per supportare i sistemi RBAC. Ferraiolo e Sandhu e altri hanno presentato uno standard per RBAC all'Istituto nazionale degli standard e della tecnologia. Questa proposta definisce i componenti principali dell'RBAC insieme alle specifiche della funzione. I componenti principali dello standard NIST sono specificati nelle seguenti sezioni.
Core RBAC
Core RBAC definisce i requisiti di assegnazione ruolo utente e ruolo permesso. Queste relazioni possono essere molte-a-molti, cioè un utente può essere assegnato a più di un ruolo e un singolo ruolo può avere molti utenti. Inoltre, è possibile assegnare un'autorizzazione a più ruoli e assegnare un ruolo a più autorizzazioni. Le autorizzazioni rappresentano le operazioni che possono essere eseguite sugli oggetti.

Core RBAC

Esso richiede anche funzionalità per la revisione delle assegnazioni dei ruoli utente. Sebbene non richiesto dal core RBAC, la revisione delle assegnazioni dei permessi di ruolo in aggiunta all'assegnazione del ruolo utente può essere utile per determinare i diritti associati a un ruolo. Core RBAC include anche la nozione di sessione. Le sessioni consentono l'attivazione e la disattivazione selettiva dei ruoli a discrezione dell'utente. Quando una sessione è attivata, un sottoinsieme dei ruoli assegnati all'utente diventa il set di ruoli attivo. L'utente acquisisce le autorizzazioni di tutti i ruoli all'interno del set di ruoli attivo. Il set di ruoli attivo può includere tutti i ruoli di cui l'utente è membro o un sottogruppo di questi ruoli, tuttavia l'implementazione deve consentire a un utente di esercitare contemporaneamente le autorizzazioni da più ruoli. Errore! Fonte di riferimento non trovata. descrive la relazione tra utenti, ruoli e sessione dell'utente. Descrive anche la relazione tra un ruolo e un insieme di permessi (PRMS). In questo diagramma, un permesso è rappresentato come una relazione tra un'operazione e un oggetto.

grafico 5 ita

Il concetto di attivazione dei ruoli aiuta a rafforzare il principio dei privilegi minimi. Ciò garantisce che l'utente non abbia più accesso di quanto necessario per eseguire un'attività specifica. Un utente può essere autorizzato a svolgere funzioni aggiuntive attivando un altro ruolo ma è limitato ai privilegi consentiti dal set di ruoli attivo. Questo può aiutare a proteggere da azioni indesiderate da parte dell'utente. Core RBAC specifica essenzialmente la funzionalità che è possibile ottenere utilizzando il controllo di accesso tradizionale basato su gruppi in cui i gruppi sono analoghi ai ruoli. Gli utenti sono assegnati ai ruoli essendo membri di un gruppo. L'accesso (privilegio) viene quindi assegnato dal gruppo. Per supportare il core RBAC, gli utenti devono poter essere membri di più di un gruppo contemporaneamente.

RBAC e gerarchie

Molte volte le stesse autorizzazioni devono essere assegnate a più di un ruolo. Questo è spesso il risultato della gerarchia naturale di un'organizzazione. Ad esempio, un supervisore deve poter svolgere gli stessi compiti del personale di cui è responsabile. Inoltre, il supervisore è autorizzato a svolgere compiti aggiuntivi come l'amministrazione delle buste paga. Sarebbe inefficiente e potrebbe portare a incongruenze nella politica per duplicare i privilegi comuni per il supervisore quando un ruolo è già stato definito. Le gerarchie di ruolo consentono ai ruoli di ereditare le autorizzazioni di altri ruoli.

grafico 6 ita

MAC

L'RBAC può essere utilizzato per implementare politiche di separazione dei compiti. Con la separazione dei compiti, agli utenti viene impedito di assumere l'appartenenza simultanea a ruoli in cui potrebbero insorgere conflitti di interesse. Static Separation of Duty (SSD) applica il vincolo nel momento in cui un utente viene assegnato al ruolo. La proposta NIST suggerisce l'uso di una coppia {role-set, n} per limitare l'assegnazione del ruolo. Il set di ruoli contiene ruoli in cui potrebbero insorgere conflitti e n rappresenta il numero di ruoli del set che è possibile assegnare contemporaneamente. Ciò consente l'implementazione di politiche in cui un utente è autorizzato a assumere due dei tre ruoli in conflitto, ma non è in grado di assumere tutti i ruoli nel set.

Il modello Bell-Lapadula (BLM) richiede che l'autorizzazione di un soggetto debba essere uguale o maggiore del livello di sicurezza dell'oggetto letto (read-down). Un soggetto è anche impedito di scrivere su oggetti classificati a livelli inferiori ma può scrivere su oggetti a livelli uguali o superiori rispetto ai propri. In questo modello, le informazioni tendono a fluire a livelli più alti. L'intenzione di BLM è di mantenere la riservatezza delle informazioni. Il modello Biba è il coniugato logico del modello BLM. Questo modello è destinato a proteggere l'integrità dei dati. Biba usa gli stessi meccanismi per controllare l'accesso, ma la relazione è invertita. Ai soggetti è permesso leggere oggetti a livelli più alti ma non gli è permesso cambiare oggetti a livelli più alti. A causa della sua inflessibilità, il MAC non è tipicamente distribuito commercialmente. È descritto in questo white paper come un esempio di un altro tipo di controllo di accesso non discrezionale.

Esecuzione della decisione

L'applicazione di una decisione di autorizzazione può essere implementata tramite codice dell'applicazione personalizzato, dal contenitore in cui viene eseguita l'applicazione o in qualche punto lungo il percorso di accesso all'oggetto. Quando il contenitore dell'applicazione impone la sicurezza, il contenitore richiama implicitamente chiamate al sistema di sicurezza per determinare se l'accesso è consentito. Questo è solitamente il metodo desiderato perché la sicurezza non può essere aggirata. L'accesso a tutte le risorse deve richiamare la sicurezza. Questo è un esempio di sicurezza dichiarativa.

Molte volte la sicurezza dichiarativa non è sufficiente quando si applicano policy di sicurezza a grana fine. Quando devono essere applicate policy a grana fine, lo sviluppatore dell'applicazione deve richiamare esplicitamente le chiamate di sicurezza. Questo è considerato sicurezza programmatica. La sicurezza programmatica è solitamente meno desiderabile perché si affida al programmatore per implementare il codice che invocherà il sistema di sicurezza. Ciò porta spesso a maggiori costi di sviluppo e manutenzione per l'applicazione, nonché a potenziali accessi non autorizzati alle risorse. Le chiamate di sicurezza richiamate dal contenitore vengono solitamente sottoposte a test più rigorosi e sono soggette a un numero di modifiche inferiore rispetto alla sicurezza integrata dell'applicazione. Per questo motivo, la sicurezza dichiarativa pone meno rischi. Altre volte, il contenitore non è in grado di interpretare la semantica della politica. Ad esempio, la politica "chiunque sia l'oggetto di un documento è autorizzato a visualizzarlo" pone un problema per la maggior parte della sicurezza richiamata dal contenitore poiché il contenitore deve sapere come determinare l'oggetto del documento. Le nuove tecnologie, come XACML, rendono la sicurezza dichiarativa un'opzione realistica. Con queste tecnologie, gli attributi inclusi nella richiesta possono essere analizzati e utilizzati nella decisione di autorizzazione