Sistemi di Autorizzazione = definizione e attuazione di una politica di controllo degli accessi
Modelli di Gestione delle Autorizzazioni
CBAC-Content Based Access Control: i privilegi variano dal contesto (modalità di accesso,
fonte di una connessione, autenticazione,strumento usato) con cui i soggetti chiedono
l’accesso (varia nel tempo)
RBAC-Role Based Access Control: accesso basato sul ruolo dei soggetti in un contesto
(insieme di regole di business,capacità tecniche, dati trattati), comprende un servizio di
controllo accessi e un gestore delle policy
ABAC (Attribute): considera gli attributi addizionali aggiunti ai ruoli per ogni
utente,risorsa,azione e contesto
Assegnazione ruoli->Autorizzazione ruoli->Autorizzazione transazioni
MAC-Mandatory Access Control: un’entità superiore (es. SO o DBMS) attribuisce per livelli i
privilegi ai soggetti in relazione alla loro affidabilità (gerarchico-militare)
Chinese Wall: struttura compartimentale con conflitti di interesse, una classe di soggetti
può accedere solo a un sottoinsieme delle informazioni di un’altra classe
DAC-Discretionary Access Control: i proprietari degli oggetti concedono o revocano i
privilegi ai soggetti (es. Unix file mode)
ACL-Access Control List: regole che determinano i privilegi dei soggetti sugli oggetti
definendo per ogni oggetto una lista soggetto-azione (es. permessi file sui dischi)
Come si realizza il Controllo Accessi: come si svolgono le operazioni di controllo degli accessi
Il soggetto deve innanzitutto identificarsi e autenticarsi al sistema, perchè si possa applicare una regola di controllo degli accessi. Quando il soggetto richiede l’uso di un oggetto, il sistema verifica la corripondenza fra la funzionalità richiesta e i diritti assegnati.Se la corrispondenza è positiva, il sistema stabilisce che l’operazione è autorizata.
I privilegi definiti sull'oggetto sono articolati anche in relazione al ruolo del soggetto. Può essere:
resto del mondo
Appartenente allo stesso gruppo del proprietario
Proprietario
Ad ogni soggetto è attribuito un insieme di privilegi sul sistema, un insieme di diritti sulle risorse del sistema
I diritti possono essere assegnati allo specifico utente quindi all'utenza che sta sul sistema oppure si definiscono dei privilegi assegnati a dei gruppi e poi si andranno a definire le associazioni fra gli utenti e i singoli gruppi.
Per ogni oggetto quindi sono definiti privilegi che i soggetti/gruppi hanno su di essi in termini di operazioni possibili.
mediante la definizione di azioni che hanno come scopo proteggere le risorse, le informazioni, che appartengono agli utenti ma soprattutto all'azienda la quale con tali informazioni può erogare i propri servizi, per le proprie finalità di business.
attraverso appropriate misure di sicurezza
Principi applicabili al Controllo Accessi
La separazione dei ruoli. Le attività che consentono di effettuare operazioni critiche devono essere separate a livello funzionale o individuale per evitare quanto più possibile che lo stesso soggetto possa portarle a compimento in autonomia.
Minimo privilegio: concessi solo privilegi necessari al contesto
Need to know: accesso a informazioni strettamente necessarie
Obiettivi del Controllo Accessi
concedere o negare specifiche autorizzazioni (dire cosa si può fare o cosa non si può fare) per ottenere e utilizzare informazioni (un gruppo di risorse sul sistema che in qualche modo consentono di manipolare informazioni), sulla base di requisiti di business e di sicurezza.
Requisiti di sicurezza = gli obiettivi di sicurezza che l'azienda definisce per il proprio funzionamento.
Requisiti di business = il modo con cui l'azienda funziona e i servizi che deve fornire alla propria clientela o al proprio interno
Autorizzazione = privilegio o atto di garantirlo
Il privilegio è una modalità di accesso ad/utilizzo di una risorsa di un sistema
I privilegi vengono definiti per le risorse, cioè informazioni o risorse hardware
I privilegi possono essere garantiti a un soggetto (utente, programma o processo)
Protocollo Kerberos
In caso di compartimentazione in più domini, è necessario prevedere la cross-realm authentication.
All’aumentare dei realm, Kerberos diventa inefficiente e poco scalabile, per il numero di passaggi di autenticazione ed il numero di chiavi da gestire per AS, TGS e RTGS.
Per accedere a un servizio che appartiene ad un altro realm, l’utente deve:
Contattare il RTGS per accedere al servizio remoto, l’utente può avere accesso a servizi remoti;
Contattare il TGS per accedere al RTGS;
Accedere all’AS per richiedere l’uso del TGS;
Siccome ogni realm ha un proprio AS e un proprio TGS, è necessario che per accedere a un realm diverso dal proprio si abbia un R(remoto)TGS (parallelismo con l’ambasciata).
Criticità di kerberos: l’autenticazione centralizzata può causare alcuni problemi come:
Server centrale rischia di diventare il collo di bottiglia dell’intera infrastruttura;
Sistema è esposto ad attacchi DoS (Denial of Service);
Sicurezza dell’accesso dipende da un unico sistema;
Per l'accesso ad n servizi, Kerberos prevede l’esistenza di un servizio aggiuntivo: il TGS Ticket Granting Server.
La risposta spedita dal TGS contiene la nuova session key per la comunicazione con il servizio richiesto
L’utente effettua una richiesta per accedere al servizio al TGS: la risposta è cifrata non con la password utente ma con la session key che l’AS ha rilasciato per la comunicazione con il TGS.
La session key utilizzata tra utente e TGS (creata da AS) rimane valida per alcune ore (di solito 8). Questa chiave di sessione può rimanere in cache al posto della password dell’utente.
Dopo aver ottenuto il ticket, l’utente lo utilizza per richiedere al TGS un Ticket Granting Ticket (TGT) per ogni servizio a cui vuole accedere.
Per accedere a un servizio l’utente chiede all’AS un ticket per accedere al TGS seguendo la procedura già descritta.
L'utente che intende accedere a un servizio si presenta all’AS, dichiarando la propria identità (autenticazione) e il nome del servizio stesso (richiesta). L’AS fornisce un ticket crittografato, accessibile solo all’utente e al servizio, per accedere al servizio. Il ticket non è riutilizzabile.
Il server può a sua volta generare un ticket analogo al BOX2 da inviare al client per comprovare la sua identità. Diversamente, l’utente non può sapere se sta dialogando con il servizio legittimo, oppure sia in corso un attacco di Man-in-the-Middle.
Il servizio quindi decifra BOX2 dal quale estrae la Session Key e con la medesima decifra il BOX3. Quindi il servizio autorizza l’accesso all’utente se la decifratura ha successo e la data inserita corrisponde al tempo di macchina corrente (spesso l’intervallo può essere ampio e i diversi ticket, in un attacco replay, che possono arrivare possono venire autorizzati).
L’utente non può accedere al BOX2, quindi ne crea un terzo (BOX3) nel quale inserisce la data e ora corrente e la session key. Per accedere al servizio, l’utente invia BOX2 e BOX3 al servizio.
L’utente riceve i due BOX dall’AS, decifra BOX1 con la propria password dalla quale estrae la session key.
Il ticket Kerberos è composto da due parti:
BOX 2
Questi elementi sono cifrati con la password del servizio
Sessione key (medesima del BOX1);
Nome dell’utente;
BOX 1
Questi elementi sono cifrati con la password dell’utente;
Session key;
Nome del servizio richiesto;
l’authentication server è l’unica entità che gestisce la procedura di autenticazione-autorizzazione in un “realm” (reame/dominio)
le chiavi di accesso non viaggiano mai non crittografate
Vi è un unico sistema per gestire gli account
Kerberos usa le OTP per l’accesso ai servizi.
si basa su RFC4120
autenticazione centralizzata (unica piattaforma d’accesso per tanti sistemi distribuiti)
È un protocollo per le architetture AAA.
Framework AAA
Componenti AAA
LDAP (Lightweight Directory Access Protocol)
per l’interrogazione e la modifica
dei servizi di directory (standard 4511). Comprende la Directory LDAP, repository delle
utenze che mantiene i profili di accesso e le politiche applicabili
LDAP è basato sullo standard RFC4511 che eredita dalla famiglia X.500 il formato dei dati, del naming e delle richieste che è possibile inviare. Rispetto allo standard X.500 il protocollo LDAP è più leggero.
Directory server
Raccoglie informazioni eterogenee da fonti diverse per rappresentarle in
modo uniforme.
Associa ad una entry tutti i dati relativi a un’entità dell’organizzazione
Authentication server o AS
È un componente per l’autenticazione distribuita (perché la si fa in un unico punto ma permette poi di accedere ai diversi sistemi distribuiti), mantiene un archivio di utenze con le relative credenziali.
per dialogare con i diversi sistemi utilizza protocolli standard come RADIUS/TACACS+ e Kerberos
unisce in un unico framework, in modo coordinato ed omogeneo, le funzionalità di Autenticazione, Controllo Accessi (Autorizzazione) e Accounting
Accounting
Consiste nella raccolta, registrazione, monitoraggio, log e analisi dei dati relativi all’autenticazione, all’accesso ed all’uso delle risorse.
Autorizzazione
Il client è autorizzato ad accedere alle risorse, è definita una politica di controllo degli accessi il cui obiettivo è concedere o negare autorizzazioni per utilizzare o ottenere informazioni sulla base dei requisiti di business e sicurezza
Autenticazione
Il client dichiara la propria identità al server e viceversa (biunivoca - mutua autenticazione), si autentica il canale di comunicazione
è un framework per il controllo accessi alle risorse di un'organizzazione.
Gli ISP e gli operatori di telefonia mobile necessitano di un sistema per
autorizzare un utente (remoto) ad usufruire delle proprie infrastrutture solamente dopo averlo
autenticato; e una volta verificatene le credenziali, devono poter eseguire un monitoraggio delle
risorse e dei contenuti fruiti, allo scopo di addebitare i servizi.
