Il principio dei privilegi minimi (“Least privilege”) si basa sull’idea che a un’entità dovrebbero essere concessi solo i privilegi di cui ha bisogno per portare a termine il suo lavoro.
Concedendo solo i permessi che sono sufficienti, in contrasto coi “desiderata”, sono notevolmente ridotte le potenzialità di abuso e/o uso improprio da parte di utenti e applicazioni.
Indice degli argomenti
Configurare i privilegi di applicazioni, utenti e dispositivi
Nel caso di un’applicazione, ciò di solito significa eseguirla con un account di servizio, in un container o mediante chiamate di sistema virtualizzate (come nel caso delle jail) e via dicendo.
Nel caso di un utente, si manifesta comunemente con policy come “solo gli account degli sviluppatori ancora assunti possono accedere al codice sorgente”.
Anche i dispositivi devono essere sottoposti a questo principio, anche se spesso assumono analoghe policy delle applicazioni e/o degli utenti a cui erano stati assegnati originariamente.
Un altro effetto dell’adozione dei privilegi minimi è che se si ha necessità di un account con maggiori poteri, lo si può concedere solo per un tempo “t” prefissato dai sysadmin.
Least privilege: dati al sicuro da accessi non autorizzati col principio del privilegio minimo
Un attento controllo degli accessi
È importante identificare in maniera certosina quali azioni richiedono quali privilegi, in modo che potranno essere eventualmente concessi in maniera precisa e tracciata allor quando si dovesse manifestare la reale necessità.
Questo tipo di approccio va un passo oltre le semplici revisioni del controllo degli accessi (“ACL review”) effettuate dai più comuni sistemisti e analisti S.O.C., C.E.R.T. e M.S.S.P..
Ciò significa che gli utenti dovranno dedicare maggior tempo all’esecuzione di azioni utilizzando account utenti non privilegiati.
Quando saranno necessari privilegi elevati, l’utente dovrà eseguire tali azioni con un account separato con privilegi più elevati.
Su un singolo host, l’elevazione dei propri privilegi di solito si ottiene imponendo l’autenticazione dell’utente. Ad esempio, su un sistema Unix, invocando un comando anteponendolo con il comando sudo verrà chiesto all’utente di inserire una password prima di eseguire quel comando con un differente ruolo (l’analogo meccanismo nel mondo Microsoft è attuabile mediante il comando runas).
Negli ambienti basati su GUI, all’utente verrà mostrata una finestra di dialogo che gli chiede la password prima di eseguire l’operazione richiesta: imponendo quindi un’interazione con l’utente, in tal modo viene attenuata (attenzione: attenuata, non del tutto eliminata) la potenzialità di sfruttamento da parte di software malevolo (malware e affini).
Zero Trust Security, gestire la fiducia con l’autenticazione forte: ecco come
Zero Trust Security e privilegi minimi
In un’architettura Zero Trust Security, gli utenti dovrebbero operare in modo simile in una modalità con ridotti privilegi di rete per la maggior parte del tempo, elevando i loro permessi solo quando necessario e per effettuare qualche operazione critica.
Ad esempio, un utente autenticato potrebbe accedere liberamente in lettura alla share dell’azienda o interagire con il software di pianificazione del progetto, invece, l’accesso a software e sistemi critici di produzione dovrebbe richiedere un’ulteriore conferma che l’utente o il sistema operativo dell’utente non siano stati compromessi.
Per azioni a basso rischio, l’elevazione dei privilegi può essere costituita da semplici azioni come la richiesta di una seconda credenziale all’utente, ad esempio un secondo token o l’invio di una notifica push al telefono dell’utente.
Diversamente, per azioni ad alto livello, si può valutare una conferma attiva da un peer tramite richieste out-of-band all’utente.
Configurare correttamente le applicazioni
Analogamente agli utenti, anche le applicazioni dovrebbero essere configurate per avere il numero minimo di privilegi necessari per operare in Rete.
Purtroppo, di default le applicazioni distribuite in ambienti aziendali non vengono configurate al rispetto di questo principio: o per la difficoltà dei sysadmin di definire policy efficaci per mitigare il rischio delle applicazioni, oppure a causa del presupposto che l’obiettivo più probabile sia la compromissione degli utenti, è diventato un luogo comune disabilitare i framework di sicurezza informatica delle applicazioni, framework che invece dovrebbero proteggere l’infrastruttura.
Al di là del tradizionale approccio ai privilegi per utenti e applicazioni, le architetture di rete Zero Trust Security valutano anche i privilegi dei device in rete. È la combinazione dell’utente o dell’applicazione e il dispositivo utilizzato che determina il livello di privilegio concesso.
Unendo il privilegio di un utente al dispositivo utilizzato per accedere alle risorse, le architetture di rete basate su ZTS sono in grado di mitigare gli effetti della perdita o della compromissione di credenziali.
L’assegnazione dei privilegi in una rete ZTS
L’assegnazione dei privilegi in una rete ZTS è più dinamica rispetto alle reti tradizionali, in cui alla fine si converge su policy che rimangono fondamentalmente statiche per molto tempo.
Se sorge l’esigenza di nuovi use case, o il richiedente farà pressione per un cambio di policy, oppure, molto più spesso, gli utenti chiederanno a qualcuno con privilegi maggiori (uno o più sysadmin ad esempio) di eseguire quell’operazione per loro.
Questa definizione statica delle policy presenta due problemi: in primo luogo, nelle organizzazioni e aziende più permissive (quante ne abbiamo in Italia nel settore della P.A.?), il privilegio aumenterà nel tempo, diminuendo gli indubbi benefici dell’applicazione del principio dei privilegi minimi.
In seconda istanza, ai sysadmin viene concesso un maggiore potere, che di fatto porta da sempre gli attackers a prendere di mira proprio gli account dei sysadmin.
Una rete ZTS, al contrario, utilizza molti attributi di attività in rete per determinare fattori di rischio per le richieste d’accesso.
Questi attributi possono essere temporali (accessi al di fuori della normale attività lavorativa del tal o tal altro utente possono risultare inusuali), geografico (accesso da una posizione e/o da una postazione diversa rispetto a dove l’utente è stato tracciato l’ultima volta o negli ultimi X mesi) o anche comportamentale (accessi effettuati a risorse a cui l’utente di norma non accede).
Considerando tutti i possibili scenari e dettagli di un tentativo di accesso, determinare se il tentativo è o meno autorizzabile può essere più complesso e granulare del fornire una banale risposta binaria (si, no).
Ad esempio, l’accesso a un database da parte di un determinato utente dalla sua posizione abituale durante il normale orario di lavoro verrebbe concesso, ma l’accesso da una nuova posizione in orari di lavoro diversi potrebbe esigere dall’utente di autenticarsi utilizzando un fattore di autenticazione addizionale.
Conclusioni
La possibilità di regolare i rischi e gli accessi in base a fattori di rischio (potremmo parlare di “rischiosità” dell’attività) è una delle numerose caratteristiche che rendono più sicure le reti basate su architetture ZTS.
Ridefinendo dinamicamente le policy d’accesso, queste reti sono in grado di rispondere autonomamente ad attacchi noti e sconosciuti da parte di attackers umani o automatizzati.
