Il Cybersecurity Awareness Month si è concluso da poco. Anche quest’anno ci ha ricordato l’importanza di educare alla sicurezza informatica dipendenti e utenti finali. Ma nella community Dev qual è il livello di consapevolezza? Applichiamo sempre le Best Practice per un’architettura robusta e resistente alle violazioni? E se a volte non lo facciamo, quali sono le ragioni? 

Microservizi + Serverless + Least Privilege: la formula per app più sicure

Quando parliamo di applicazioni, partiamo da un presupposto valido nella gran parte dei casi. Adottare un’architettura a microservizi, basata su tecnologie Serverless, consente di migliorare performance e sicurezza dell’applicazione stessa. (spoiler: non è l’unico approccio possibile, ma affronteremo casi diversi in un altro post). 

Come abbiamo spiegato qui, questo paradigma permette di eseguire codice isolando dati e responsabilità di ogni microservizio, aggiungendo il vantaggio di non dover gestire i server, grazie alle tecnologie Serverless. 

Se introduciamo il Least Privilege Principle all’architettura a microservizi otteniamo un risultato che ci permette di garantire, non solo migliori performance, scalabilità e resilienza ma anche un livello ancora più elevato di sicurezza. Vediamo perché. 

Cos’è il Least Privilege Principle 

AWS definisce il Least Privilege Principle come “concedere solo le autorizzazioni necessarie per completare una specifica attività”. Suona familiare? Non è tanto diverso dall’approccio “Zero Trust” applicato alla gestione in Cloud di dati, identità e dispositivi aziendali. Ogni membro di un’organizzazione possiede le credenziali per accedere solo ai propri dispositivi ed ai file e risorse per cui è autorizzato. Lo stesso dovrebbe succedere nel codice di un’applicazione. 

Applicare il Least Privilege Principle ad ogni microservizio significa far sì che ogni componente dell’architettura abbia solo ed esclusivamente i permessi per poter svolgere la propria funzione. Il risultato è che se un singolo microservizio dovesse essere compromesso, il cosiddetto Blast Radius (cioè l’area di codice compromessa) sarebbe limitato ai privilegi di accesso del microservizio verso le altre componenti dell’applicazione. 

I permessi riferiti a ognuna di queste componenti sono definiti dalle cosiddette policy IAM (Identity and Access Management). Si tratta di oggetti in AWS che, se associati a un’identità (utenti, gruppi di utenti o ruoli) o una risorsa, ne definiscono le autorizzazioni. 

In tal modo, si controllano le identità che lavorano sul codice e che sono autorizzate, a diversi livelli, a stabilire le azioni che ogni singolo microservizio può espletare.  

Vantaggi del Least Privilege 

Ogni applicazione basata sull’approccio a microservizi si basa su una serie di funzioni e servizi che comunicano tra loro e restituiscono dei risultati. In questa struttura modulare, è cruciale limitare le autorizzazioni di ogni componente, stabilendo di volta in volta che cosa può fare quel “pezzo” di codice (microservizio) e chi può intervenire sul codice stesso. I vantaggi di questo approccio sono diversi. 

 Minori probabilità di violazione di un sistema 

Applicare i privilegi minimi rende un’applicazione molto più difficile da compromettere. Se per accedere a una risorsa nel Cloud servono specifiche autorizzazioni, quella risorsa difficilmente costituirà una porta di ingresso al sistema.  

Raggio di violazione (Blast Radius) ridotto in caso di compromissione  

Applicare il principio del Least Privilege garantisce, in caso di attacco e compromissione di un microservizio, di limitare il potenziale danno alla sola funzione svolta dal singolo microservizio. 

Al contrario, se non viene applicato il principio del Least Privilege, in caso di compromissione di un microservizio potrebbe essere possibile per l’attaccante raggiungere qualsiasi altra risorsa dell’intero sistema. 

Dati finanziari e personali più protetti 

Tra i rischi più gravi di un’intrusione c’è naturalmente la compromissione di database con dati sensibili. Applicare il Least Privilege Principle per regolare l’accesso a questi dati, riduce il rischio di perdite finanziarie per l’azienda e i suoi clienti. Permette anche di salvaguardare le informazioni personali condivise dagli utenti di un’applicazione, evitando danni a livello di fiducia e reputazione. 

Un paradigma di sviluppo orientato alla sicurezza 

Il Least Privilege Principle ha anche il merito di definire uno standard di sviluppo chiaro per i team Dev. Un approccio orientato alla Security by Design. Tuttavia, non è sempre facile applicarlo perché implica configurazioni molto complesse, in cui l’effort è spesso in contrasto con la velocità di sviluppo richiesta dal business. 

Perché non è sempre semplice applicare il Least Privilege? 

Fin qui la teoria. In pratica però, quando ci troviamo di fronte ad un’architettura a microservizi dobbiamo fare i conti con un numero molto elevato di componenti che devono interagire fra di loro. 

Sviluppare un’applicazione a microservizi basata su tecnologie Serverless implica l’utilizzo di diversi servizi. Nel Cloud di AWS avremo ad esempio API Gateway, Lambda, DynamoDB, Fargate, SQS, Event Bridge, SNS, S3, OpenSearch, ecc.…i quali dovranno comunicare fra di loro. Per farlo bisognerà definire delle IAM Policy da applicare ad ogni componente che interagisce con le altre garantendo il Least Privilege Principle. 

Gestire i privilegi minimi in un’architettura così frammentata può diventare molto complesso. 

Il più delle volte, si cerca il compromesso migliore tra sicurezza e tempi di rilascio. Inoltre, sviluppare applicazioni sicure richiede competenze avanzate che non sono presenti in ugual misura in tutti i team.  

Come funzionano le policy IAM 

Una volta determinati i compiti di utenti e ruoli, le policy IAM vanno impostate per consentire loro di eseguire solo tali attività. 

Si inizia con un set di autorizzazioni minimo e si concedono autorizzazioni aggiuntive quando necessario. Questo approccio è più sicuro che iniziare con autorizzazioni che siano troppo permissive, per cercare di limitarle in un secondo momento. 

Ogni servizio AWS ha il proprio insieme di operazioni che descrive le attività che è possibile eseguire con quel servizio. Esistono diversi livelli di accesso, ad esempio “List” consente di elencare le risorse all’interno del servizio per determinare l’esistenza di un oggetto. “Read” autorizza accesso in sola lettura, ma non permette di modificare. “Write” permette di creare, eliminare o modificare le risorse del servizio. E così via. 

Per assegnare i corretti livelli di accesso, è possibile scegliere una policy basata su identità o una policy basata su risorse. 

Le policy basate su identità sono collegate a un utente, un gruppo o un ruolo IAM. Queste policy consentono di specificare cosa può fare quell’identità. Le policy basate su risorse consentono di specificare quali utenti hanno accesso a una risorsa e quali operazioni possono eseguirvi.   

Un esempio concreto 

Nel caso che segue, mostriamo un’estrema semplificazione di come applicare il principio del Least Privilege, isolando un numero limitato di utenti, risorse e relative autorizzazioni. 

Come mostrato nella figura, possiamo collegare la policy all’utente IAM di nome JohnSmith, dichiarando che questo utente è autorizzato ad eseguire operazioni di lettura ed elenco su Resource X (ad esempio una tabella di Amazon DynamoDB). 

CarlosSalazar, invece può eseguire operazioni di lettura, scrittura ed elenco su Resource Y ma gli viene rifiutato l’accesso a Resource Z. La policy basata su identità gli consente di eseguire operazioni di lettura ed elenco su Resource Y. La policy basata sulla risorsa Resource Y, inoltre, gli concede autorizzazioni di scrittura. Tuttavia, anche se la sua policy basata su identità gli consente l’accesso a Resource Z, la policy basata sulla risorsa Resource Z nega tale accesso.  

Questo avviene perché le policy basate su identità e le policy basate su risorse sono entrambe policy di autorizzazione e vengono valutate insieme. Se esiste un “Deny”, la richiesta viene negata. Quindi, AWS verificherà ogni “Allow”. Se almeno un’istruzione della policy consente l’operazione nella richiesta, la richiesta è consentita. Non importa se l’Allow è concessa dalla policy basata su identità o dalla policy basata su risorse. 

Esternalizzare o acquisire le skill per ottimizzare la sicurezza? 

Applicare i privilegi minimi garantisce una difesa solida contro le intrusioni. Tuttavia, come abbiamo visto nel precedente esempio, implica configurazioni molto complesse. Saper calibrare l’assegnazione di permessi e le condizioni di funzionamento di un’applicazione richiede esperienza e competenze specifiche avanzate. Se queste vengono a mancare, si rischia di incappare in processi di sviluppo lunghi e bloccanti che non sono direttamente collegati al core business di un’app. Oppure di esporsi a un grosso rischio di compromissione del servizio. Startup e PMI che offrono servizi digitali ottengono di solito vantaggi superiori esternalizzando questo tipo di configurazioni. Questo perché acquisire le skill necessarie comporta costi e tempi incompatibili con le logiche di business e con la necessità di rispondere velocemente alle evoluzioni del mercato.