Che cos'è la sicurezza serverless?

Che cos'è l'informatica senza server?

L'informatica senza server si riferisce a un modello di cloud computing in cui il fornitore di cloud gestisce il server e gestisce dinamicamente l'allocazione delle risorse della macchina. AWS Lambda Functions, Google cloud Functions e Azure Functions sono framework serverless popolari che costruiscono applicazioni.

Un'architettura serverless offre il vantaggio di una scalabilità automatizzata e quasi infinita. Pochissimo si frappone tra gli sviluppatori e il codice distribuito, il che accelera il time to market e rende più facile la manutenzione e il test delle singole funzioni. Infine, la quantità effettiva di risorse applicative consumate influisce sul prezzo, il che significa che lei paga solo per ciò che utilizza, con conseguente riduzione dei costi.

Serverless rappresenta un ulteriore spostamento di responsabilità dal cliente al fornitore di cloud. Non essendo coinvolta alcuna infrastruttura, c'è una riduzione significativa dei costi generali delle operazioni.

Spostare la gestione dell'infrastruttura al suo provider cloud le consente di concentrarsi sullo sviluppo di soluzioni al servizio della sua organizzazione e dei suoi clienti. La aiuta a mantenere il focus sui suoi vantaggi competitivi unici, e spesso si traduce in un risparmio sui costi non solo di calcolo, ma anche di spostamento delle persone allo sviluppo.

In che modo Serverless migliora la sicurezza?

Ecco alcuni punti chiave:

1. I fornitori di cloud gestiscono il sistema operativo, la sicurezza del runtime e le patch. Nell'implementazione di applicazioni serverless, lei cede il controllo della maggior parte dello stack al suo fornitore di cloud, che fornisce servizi come la gestione delle chiavi. Non possiede più l'hardening di OS, i diritti di amministrazione, SSH e la segmentazione. AWS, Microsoft e Google sono affidabili nel mantenere le loro parti dello stack patchate e protette, quindi dare loro una porzione più ampia dello stack migliora certamente le cose da questo punto di vista.
2. Inesistente/Effimero. Inoltre, la natura effimera e apolide del calcolo senza server rende la vita degli attaccanti più difficile. Le funzioni serverless come AWS Lambda vengono eseguite per pochi secondi e poi muoiono. I contenitori vengono riciclati. Il fatto che le funzioni serverless vadano e vengano, non avendo memoria, riduce il rischio di attacchi a lungo termine.
3. Visibilità dell'applicazione Serverless - Il vantaggio. Il fatto che le applicazioni serverless siano strutturate come un gran numero di piccole funzioni nel cloud offre una fantastica opportunità per la sicurezza. Gli strumenti per la sicurezza delle applicazioni spesso si spingono fino a livelli incredibili per analizzare e strumentare l'applicazione confezionata, solo per poter osservare o filtrare il flusso interno dell'applicazione.
4. Microservizio più piccolo = Capacità di costruire ruoli adeguati e minimi per ogni funzione. Il passaggio a microservizi più piccoli consente di eseguire un IAM a grana più fine. Ha l'opportunità di applicare politiche di sicurezza a ciascuno di questi piccoli elementi, che possono ridurre in modo significativo la sua superficie di attacco.

Finché una funzione all'interno di un contenitore ha bisogno di accedere alla lettura da S3, anche tutte le funzioni all'interno di quel contenitore avranno questo privilegio. Con AWS Lambda, ha l'opportunità di applicare privilegi a singole funzioni e di garantire che tali privilegi siano limitati solo all'ambito minimo necessario. Se c'è una vulnerabilità in una delle sue funzioni, un aggressore otterrà l'accesso solo alle capacità limitate di quella funzione, non all'ampio set di permessi da concedere a un contenitore.

Cosa sono le sfide di Serverless Security?

Con il cambiamento della struttura delle applicazioni serverless, sorgono alcune nuove sfide.

1. La visibilità della sicurezza diventa più difficile. La quantità totale di informazioni e il numero di risorse aumentano con serverless. Questo ostacola la capacità di dare un senso a tutti i dati. Con un miliardo di eventi nel registro ogni giorno, è difficile ottenere l'intelligenza dalle montagne di dati per una vera osservabilità.
2. Protocolli, vettori e punti di attacco si sono moltiplicati per ogni funzione, e Protocollo = un potenziale punto di attacco. Ciò richiede approcci unici per la sicurezza di Google Functions, Azure Functions e AWS Lambda.
3. Più risorse = più permessi da gestire. Più risorse equivalgono a più autorizzazioni da gestire, creando sfide nel determinare le autorizzazioni per tutte queste interazioni. La tecnologia automatizzata è in grado di rilevare i rischi di configurazione e di generare automaticamente le autorizzazioni per le funzioni di minor privilegio.
4. Osservabilità nelle applicazioni serverless - La sfida. Le app serverless utilizzano servizi diversi da vari fornitori di cloud, su più versioni e regioni. Per comprendere la superficie di attacco e i rischi potenziali, è necessaria una visione completa dell'intero ecosistema serverless. Man mano che la sua app si diffonde, questa visione incentrata sulla sicurezza può essere sempre più impegnativa da costruire e mantenere.

Dove distribuire Serverless Security?

Con le applicazioni serverless, non c'è alcun posto dove collocare la sicurezza classica come WAF, firewall e IDS. Costruire muri tra gli aggressori e le risorse non è semplice per diversi motivi.

1. Se da un lato l'implementazione più rapida e frequente può essere molto positiva, dall'altro la velocità di serverless può sollevare nuove sfide nella configurazione della sicurezza.
2. Gli strumenti di sicurezza potrebbero aggiungere tempo all'elaborazione, che deve moltiplicare per tutte le richieste. Fortunatamente, la maggior parte delle best practice di Serverless Security non richiede tempi di elaborazione aggiuntivi.
3. Erosione del perimetro. L'applicazione tradizionale aveva un confine chiaro. L'esterno e l'interno erano distinti e potevamo effettuare la sicurezza sul perimetro. Sebbene non sia ideale che la sicurezza rimanga esclusivamente sul perimetro, era comunque possibile costruire un muro.

Le applicazioni serverless sono più porose e a grana fine. Composte da decine o centinaia di funzioni, le applicazioni serverless sono piccoli microservizi con le proprie politiche, ruolo, API, audit trail, ecc. Questo cambia la superficie di attacco, invece di un piccolo numero di punti di ingresso con molte funzionalità nascoste dietro ognuno di essi, ora ci sono più punti di ingresso, ognuno con una piccola parte dell'app dietro di esso. Per difendere la sua applicazione ora è necessario pensare a ogni punto di ingresso.

Diversi eventi possono attivare delle funzioni, come ad esempio:

• Eventi di archiviazione in cloud (ad es. AWS S3, Azure Blob storage, Google cloud Storage)
• Elaborazione dei dati del flusso (ad es. AWS Kinesis)
• Modifiche ai database (ad es. AWS DynamoDB, Azure CosmosDB)
• Modifiche al codice (ad es. AWS CodeCommit)
• Notifiche (ad esempio, SMS, e-mail, IoT)

Cosa sono le minacce di Serverless Security?

Mentre le motivazioni degli attaccanti rimangono le stesse, le tattiche che utilizzeranno con le applicazioni serverless devono cambiare. Di seguito sono riportate alcune delle minacce di Serverless Security uniche per questa nuova architettura applicativa.

1. La minaccia di funzioni troppo privilegiate

Con l'applicazione serverless, ha l'opportunità di applicare i privilegi alle singole funzioni e di garantire che tali privilegi siano limitati solo all'ambito più piccolo necessario. Questo può consentirle di ridurre in modo significativo la sua superficie di attacco, nonché di mitigare l'impatto di qualsiasi attacco.

Purtroppo, una recente ricerca di Check Point ha rilevato che la grande maggioranza degli sviluppatori non sta sfruttando questa opportunità. La nostra ricerca ha scoperto che il 98% delle funzioni nelle applicazioni serverless sono a rischio, con il 16% considerato "grave". Inoltre, la maggior parte di queste funzioni sono dotate di più permessi di quelli necessari, che potrebbero essere rimossi per migliorare la sicurezza della funzione e dell'applicazione.

Nell'analisi delle funzioni, Check Point assegna un punteggio di rischio a ciascuna funzione. Questo si basa sulle debolezze della postura scoperte e tiene conto non solo della natura della debolezza, ma anche del contesto in cui si verifica. Dopo aver analizzato decine di migliaia di funzioni in applicazioni live, abbiamo scoperto che la maggior parte delle applicazioni serverless non vengono semplicemente distribuite in modo sicuro come dovrebbero per ridurre al minimo i rischi. I maggiori problemi di postura della sicurezza che Check Point ha scoperto sono le autorizzazioni non necessarie, mentre i restanti riguardano il codice e le configurazioni vulnerabili.

2. L'attacco del Giorno della Marmotta

Il fatto che le funzioni serverless siano effimere e di breve durata rende più difficile per gli attaccanti persistere nella sua applicazione a lungo termine. Inoltre, questo è uno dei tanti vantaggi di sicurezza di serverless. Tuttavia, il fatto che questo renda la vita più difficile agli aggressori non significa che interromperanno gli attacchi; cambieranno semplicemente la strategia.

La breve durata delle funzioni serverless significa che le minacce di Serverless Security possono cambiare forma. Gli aggressori possono costruire un attacco molto più breve che si limita a rubare, ad esempio, alcuni numeri di carta di credito. Questo singolo ciclo di attacco si ripete continuamente, in quello che noi chiamiamo l'attacco del "Giorno della Marmotta".

3. Avvelenare il pozzo

Nonostante la breve durata di vita delle risorse cloud-native, gli aggressori possono ancora trovare il modo di ottenere una persistenza a lungo termine nella sua app. Un modo in cui gli aggressori possono aggirare la natura effimera delle applicazioni serverless è un attacco a monte, o "avvelenamento del pozzo".

Le applicazioni cloud-native tendono a comprendere molti moduli e librerie con codice proveniente da una varietà di fonti di terze parti. Gli aggressori lavorano per includere codice maligno nei progetti comuni. Poi, dopo aver avvelenato il pozzo, il codice maligno nelle sue app cloud può chiamare casa, ricevere istruzioni e scatenare il caos.

4. Aumento del tempo per la configurazione di Serverless Security

Anche se non si tratta esattamente di una "minaccia" per la sicurezza, è piuttosto una sfida e un possibile ostacolo ai suoi sforzi per proteggere l'architettura serverless.

Serverless offre il vantaggio di una maggiore velocità di sviluppo delle applicazioni. Sfortunatamente, l'approccio tradizionale alla sicurezza, in cui gli sviluppatori scrivono codice e pacchettizzano i carichi di lavoro, e le operazioni di sicurezza mettono in atto controlli di sicurezza attorno a questi carichi di lavoro, non funziona per i serverless.

Se gli sviluppatori devono aspettare che la sicurezza apra per loro le porte, i ruoli IAM o i gruppi di sicurezza, il vantaggio di una maggiore velocità si erode rapidamente. Troppo spesso la soluzione consiste nell'eliminare i SecOps dall'equazione, il che potrebbe essere un rischio.

D'altra parte, la configurazione delle autorizzazioni per la miriade di risorse serverless e le interazioni tra di esse è un compito che richiede molto tempo. Inoltre, 'spendere' il tempo degli sviluppatori per la configurazione della sicurezza può diventare rapidamente costoso, oltre a non essere l'uso ideale del loro tempo. Sfruttando l'automazione, come la Piattaforma CloudGuard, può aumentare Serverless Security senza dedicare quantità eccessive di tempo agli sviluppatori.

5. Aumento del tempo per il trattamento di sicurezza

Un altro vantaggio di serverless è che si paga solo per ciò che si consuma effettivamente, il che può comportare una riduzione dei costi. Tuttavia, pagare proprio per ciò che si utilizza significa che qualsiasi aumento dei tempi di elaborazione farà lievitare i costi.

Un eccesso di configurazione dell'app sec nella sua applicazione potrebbe potenzialmente aggiungere lavoro extra alle sue funzioni, con conseguente aumento dei costi. Sebbene l'aggiunta di tempo di elaborazione per la sicurezza sia un investimento saggio, richiede un'implementazione adeguata per evitare un aumento eccessivo e non necessario dei costi.

Simile al precedente Aumento del tempo per la configurazione di Serverless Security, non è esattamente una minaccia, ma più una sfida che dovrà affrontare durante la protezione della sua architettura serverless.