Serverless computing, ovvero potenza elaborativa ma senza i server. Si tratta di un modello molto efficiente per la distribuzione e il rilascio del software on demand. La crescente popolarità del serveless computing si deve alla sua semplicità ma anche ai suoi costi più ridotti e al più rapido time-to-market in una logica DevOps. Ma, come ogni altra tecnologia IT, anche in questo caso il binomio serverless computing e sicurezza è fondamentale anche se non così semplice da realizzare.
Il serveless computing richiede agli sviluppatori e ai team Ops di ripensare anche l’approccio alla sicurezza. Una corretta programmazione, infatti, deve limitare quanto più possibile qualsiasi tipo di vulnerabilità del software.
Sviluppatori prestate cura al codice delle funzioni
Per migliorare la sicurezza nell’ambito delle architetture serverless, innanzitutto è necessario utilizzare una programmazione minimalista. La compilazione del codice, infatti, deve richiedere solo le risorse necessarie ad attivare un determinato compito. Il minimalismo non solo diminuisce i potenziali vettori di attacco ma riesce anche a limitare le potenziali ramificazioni di una vulnerabilità all’interno di una funzione. In pratica, meno risorse servono a supportare una determinata funzione, meno danni potranno fare gli attaccanti che cercano di prendere il controllo di quella funzione.
Inoltre, compilare il codice per ogni funzione in modo da avere una programmazione precisa per ogni compito aiuta a separare tra di loro le funzioni: è questo tipo di isolamento a ridurre le probabilità di una vulnerabilità virale, capace di intaccare anche altre funzioni del programma.
Attenzione a limitare la programmazione delle dipendenze
Utilizzare codici che generano interdipendenze, infatti, è una cosa da valutare con molta attenzione. In genere i programmatori includono le dipendenze da repository di terze parti all’interno di codice serverless. Come precisano gli esperti, questo va fatto solo se assolutamente necessario.
I programmatori che hanno creato quel tipo di codice, infatti, possono non seguire gli stessi standard di sicurezza: nel caso possano insorgere dei problemi il programmatore, legandosi a sviluppatori terzi, poi dipenderà dal loro per tutta l’evolutiva (che difficilmente verrà portata avanti, per altro, nei tempi desiderati). Nel caso in cui le dipendenze si rendano necessarie è sempre meglio assicurarsi di includere le ultime versioni più stabili. È importante anche prestare attenzione nello stilare un inventario accurato delle dipendenze nel codice associato al serverless computing e utilizzare gli strumenti di rilevamento delle vulnerabilità per ricevere notifiche su eventuali problemi di sicurezza rilevati in tali dipendenze.
Analisi e test di routine per tutte le fasi di sviluppo
Per garantire ulteriormente la sicurezza di un’ambiente serverless computing, è necessario analizzare le funzioni per intercettare le potenziali vulnerabilità a livello di codice. Le squadre di sviluppo spesso programmano e implementano funzioni in un ambiente diverso rispetto al resto di una app: ecco perché è fondamentale ricordarsi di includere anche questa parte del codice nelle fasi di ruotine associate ai test della sicurezza.
Team di lavoro IT
L’importanza del monitoraggio degli ambienti di serverless computing può sembrare ovvia. Tuttavia, dal momento che può essere difficile monitorare correttamente questo tipo di ambienti con gli strumenti di sicurezza aziendali esistenti, i team operativi devono prestare massima attenzione.
Spesso è possibile estendere le metriche da un ambiente serverless in un sistema SIEM (Security Information and Eevent Management). La maggior parte degli strumenti legacy SIEM, però, non sono stati progettati per rilevare comportamenti anomali all’interno di quadri event-driven. Ad esempio, i SIEM tradizionali potrebbero rilevare un processo che viene eseguito in un arco di tempo ridotto e poi fermarsi in maniera anomala, perché questo tipo di comportamento non è tipico sulle infrastrutture convenzionali. Questo è il motivo per cui in un ambiente serverless le policy SIEM devono essere personalizzate per aiutare l’analisi della sicurezza. In alternativa è possibile adottare uno strumento di rilevamento progettato specificamente come PureSec o Twistlock.
Personalizzare le policy di accesso
Le piattaforme di serverless computing basate su cloud come, ad esempio, AWS Lambda, offrono policy di controllo degli accessi preconfigurate e basate sull’identità che gestiscono gli utenti che possono richiamare e monitorare le funzioni serverless. Queste politiche costituiscono un ottimo punto di partenza per la sicurezza. Le policy non si basano esclusivamente sulle configurazioni del fornitore per controllare le risorse serverless. Ecco perché sono un’opzione di default piuttosto generalista: non è progettata per soddisfare esigenze particolari o specifiche. Senza contare che i cybercriminali, conoscendo la configurazione predefinita, sapranno come trovare tutti i potenziali vettori di attacco. Molto meglio prendere la configurazione fornita dal fornitore, che garantisce la minima quantità di accessi, e partire da quella per programmare.
Autoscaling con dovizia
Un ultimo consiglio degli esperti è di utilizzare l’autoscaling con dovizia. Scalare rapidamente è un’esigenza comprensibile ma, se le squadre Ops configurano le funzioni per scalare rapidamente senza porsi dei limiti ragionevoli, gli aggressori o anche più semplicemente il codice scritto male, possono innescare un grande volume di funzioni in un breve periodo di tempo, il che comporterà un aumento dei costi significativo.
In sintesi, è necessario trovare una via di mezzo che consenta una certa scalabilità funzionale legittima, senza abusare dell’autoscaling. Ci vuole tempo per trovare questa terra di mezzo, dove gli ingegneri Ops dovranno procedere intervenendo manualmente, caso per caso.
