Recentemente AWS Lambda ha subito la prima minaccia specifica con il malware Denonia. Sebbene l’impatto di questo attacco sia stato basso, è il momento per le aziende di chiedersi quanto siano sicure le loro applicazioni serverless e come possano prepararsi a un attacco futuro.
La sicurezza delle applicazioni serverless richiede un approccio diverso rispetto ai monoliti tradizionali o alle applicazioni containerizzate. Con questo primo attacco malware, abbiamo l’opportunità di valutare quali sono le considerazioni uniche da fare per proteggere gli ambienti serverless e come possiamo tenerne conto per rafforzare il nostro approccio alla sicurezza serverless.
In che modo la mia applicazione serverless è vulnerabile?
L’architettura serverless è intrinsecamente più sicura in diversi modi. Con serverless, i fornitori di cloud sono responsabili della gestione del lavoro pesante di patch e sicurezza dell’infrastruttura. Come per l’ottimizzazione dell’allocazione delle risorse di calcolo, i fornitori di cloud sono molto più bravi di noi a proteggere l’infrastruttura, quindi affidarsi a loro è una scommessa sicura. L’utente è comunque responsabile della protezione del codice e di tutte le risorse e i componenti che compongono il sistema serverless, ma scaricare gran parte delle configurazioni e della gestione dell’infrastruttura alle piattaforme consente di concentrare tutta l’attenzione su un’area più piccola. Inoltre, le funzioni serverless sono in genere di breve durata, il che complica le cose per i potenziali aggressori, dando loro solo una piccola finestra per entrare.
D’altra parte, la natura distribuita e dinamica di serverless rende difficile individuare le minacce e risolverle rapidamente, soprattutto con la crescita degli stack tecnologici. Con i vari strumenti e servizi utilizzati per sviluppare, testare e distribuire le applicazioni serverless, questi ambienti diventano ancora più opachi. Gli sviluppatori sono costretti a setacciare enormi quantità di dati di tracciamento, log e metriche per comprendere le loro applicazioni. Con così tante risorse interconnesse, ma con una visibilità limitata, è difficile identificare e risolvere i problemi di sicurezza in modo rapido ed efficiente.
Le architetture serverless sono guidate da eventi, innescati da fonti come una chiamata API, un nuovo upload su un bucket AWS S3 o una modifica del database. Una singola applicazione può avere molte funzioni con diverse fonti di eventi e per ogni funzione invocata vengono consumati dati, rendendo il codice vulnerabile agli utenti malintenzionati. Quando il codice si muove attraverso le pipeline, da un servizio all’altro, si creano nuovi punti di ingresso per il malware che può manipolare il suo percorso. È più probabile che gli attacchi avvengano prima che i dati entrino in un bucket S3 o in un DynamoDB, quindi, sebbene la crittografia dei dati sia sempre una buona pratica, è importante adottare altre misure per limitare le vulnerabilità della vostra applicazione.
Rafforzare i controlli di accesso
I controlli di accesso e i permessi mal configurati sono i punti in cui la vostra applicazione serverless può essere più vulnerabile. Questo è stato il caso degli aggressori di Denonia, che secondo AWS hanno ottenuto l’accesso ottenendo in modo fraudolento le credenziali dell’account. Le funzioni Lambda devono essere protette con controlli di accesso e privilegi rigorosi per ridurre la superficie di attacco delle applicazioni serverless. Le architetture serverless, costituite da piccoli microservizi, possono trarre vantaggio dal principio del minimo privilegio, in base al quale si impostano autorizzazioni e criteri rigorosi per una funzione che limitano l’accesso solo agli utenti e alle risorse necessarie.
Mantenere il codice sulla sua rotta
Uno dei modi in cui il malware può danneggiare le applicazioni serverless è reindirizzare il codice in modi che lo sviluppatore non intendeva. Ad esempio, un malware come Denonia potrebbe manipolare il codice per utilizzare la potenza di calcolo per il mining di criptovalute. La scalabilità automatica e quasi infinita di serverless, che è vantaggiosa in circostanze normali, significa che il vostro ambiente scalerà automaticamente, generando istanze di funzioni Lambda aggiuntive che possono a loro volta essere compromesse e violate. Si finisce per pagare tutte le risorse che il malware utilizza per portare a termine l’attacco.
Non possiamo sempre prevedere l’andamento di una minaccia, ma possiamo imparare da come si comporta un malware come Denonia e adottare alcune misure per garantire che il nostro codice venga eseguito esattamente come previsto. La definizione di limiti ragionevoli su attività come l’autoscaling è fondamentale per garantire che non si abbiano brutte sorprese all’arrivo della prossima bolletta del cloud. Inoltre, è necessario creare degli avvisi per notificare quando ci si avvicina al limite massimo o quando un Lambda tenta di accedere a qualcosa che non dovrebbe, in modo da poter cogliere l’attività dannosa sul nascere e porvi rimedio rapidamente.
Scopri la storia completa di serverless
Le strategie di monitoraggio tradizionali, che si concentrano solo sul monitoraggio delle metriche di utilizzo delle risorse come CPU e memoria o che hanno punti oscuri quando si tratta di servizi gestiti e di terze parti, lasciano un grande vuoto quando si tratta di proteggere le applicazioni serverless. Man mano che l’applicazione cresce e la superficie di attacco diventa più ampia, affidarsi a metriche e log grezzi per il monitoraggio degli ambienti serverless vi porterà solo fino a un certo punto. Presto ci saranno troppi servizi e risorse che generano dati per capire dove il vostro codice ha preso una strada sbagliata e il vostro sistema potrebbe essere sfruttato prima che ve ne accorgiate.
La sicurezza dell’architettura serverless richiede una visibilità più completa sulle modalità di interazione tra funzioni, servizi e risorse. Il tracciamento distribuito è fondamentale per aiutarvi a capire la portata del danno, come l’utente malintenzionato è entrato e cosa ha visto. Questo metodo consente di seguire la catena di eventi della gestione delle richieste di un’applicazione, dall’innesco dell’evento alla funzione Lambda ai servizi gestiti, per individuare la fonte del rischio o dell’attacco in tempo reale.
La sicurezza serverless in futuro
I numerosi vantaggi del computing serverless ne hanno accelerato l’adozione negli ultimi anni e ora è utilizzato da una parte significativa di tutti gli sviluppatori. La comparsa di malware che colpiscono specificamente l’infrastruttura serverless è un ulteriore segno che il serverless è diventato maggiorenne. Un caso specifico di malware non rappresenta un rischio grave per le applicazioni serverless, ma evidenzia un nuovo tipo di minaccia che è particolarmente pertinente all’architettura serverless. Questa è una grande opportunità per tutti noi di prendere un momento per rivedere i nostri ambienti serverless e garantire che le migliori pratiche siano seguite per mantenere i dati dei nostri utenti e le nostre risorse al sicuro.
