Che cos'è la sicurezza senza server?
Indice dei contenuti
Serverless si riferisce a un modello di sviluppo nativo del cloud computing che consente agli sviluppatori di costruire ed eseguire applicazioni e servizi senza dover gestire l'infrastruttura o l'IT lato server. Le applicazioni nel modello serverless si basano su una combinazione di servizi cloud gestiti e di funzioni come servizio (FaaS) che astraggono dalla necessità di gestire, applicare patch e proteggere l'infrastruttura e le macchine virtuali.
Vantaggi dell'architettura Serverless
Entro il 2020, il 40% delle organizzazioni ha dichiarato di aver adottato completamente l'architettura serverless, secondo O'Reilly. Negli anni successivi, serverless è diventato un ambiente di esecuzione delle applicazioni dominante. Lo State of Cloud Nativo Security Report 2024 mostra un'ulteriore crescita all'orizzonte, dato che il 70% degli intervistati ha dichiarato di aver pianificato un aumento dell'uso nei prossimi 24 mesi.
L'adozione di un modello serverless è vantaggiosa per lo sviluppo delle applicazioni in diversi modi:
- Riduzione dei costi operativi: Senza server da gestire, gli sviluppatori e DevOps non devono preoccuparsi di scalare l'infrastruttura, installare e mantenere agenti o altre operazioni legate all'infrastruttura.
- Maggiore agilità: Poiché le applicazioni serverless si basano molto sui servizi gestiti per cose come i database e l'autenticazione, gli sviluppatori sono liberi di concentrarsi sulla logica aziendale effettiva dell'applicazione, che in genere viene eseguita su un FaaS, come AWS® Lambda o Google Cloud Functions.
- Costi ridotti: Con la maggior parte dei servizi utilizzati nelle applicazioni serverless, il cliente paga solo per l'utilizzo. Ad esempio, con AWS Lambda, i clienti pagano per le esecuzioni delle loro funzioni. Questo in genere ha un impatto significativo sui costi, in quanto non devono pagare per la capacità inutilizzata, come avviene con le macchine virtuali.
Le applicazioni serverless richiedono una sicurezza serverless
Ogni progresso importante nello sviluppo del software e nelle operazioni IT comporta un cambiamento nei vettori di attacco e nei rischi per la sicurezza. Agli albori della virtualizzazione verso i container, i professionisti della sicurezza hanno dovuto adattarsi e trovare nuovi modi per irrigidire, difendere e governare la loro infrastruttura. Il concetto di applicazione serverless presenta uno dei più grandi cambiamenti di paradigma mai visti per quanto riguarda la sicurezza delle applicazioni.
Tradizionalmente, le organizzazioni proteggevano le loro applicazioni affidandosi a strumenti basati sull'infrastruttura e sulla rete. Potrebbero ispezionare il traffico con un firewall, cercare di rilevare le attività dannose con un sistema di rilevamento delle intrusioni, o proteggere le applicazioni con la tecnologia di autoprotezione delle applicazioni runtime, o RASP. Anche con i container, le organizzazioni possono ancora fare affidamento sulla sicurezza dell'infrastruttura sottostante in una certa misura.
Un'applicazione serverless consiste in servizi cloud distribuiti che lavorano insieme, come ad esempio un bucket S3 che attiva una Lambda Function, che a sua volta attiva DynamoDB®. In questa architettura, non c'è spazio per i firewall, gli strumenti IDS/IPS o qualsiasi tipo di agenti di strumentazione o metodi di protezione basati su server. Invece di concentrarsi sull'ispezione della rete e sulle liste di controllo degli accessi, il modello serverless sposta l'attenzione sulla sicurezza verso le autorizzazioni IAM, la protezione comportamentale e il codice forte.
Vettori di attacco serverless
L'adozione della sicurezza serverless offre alle applicazioni un forte vantaggio dal punto di vista della sicurezza, poiché le organizzazioni non devono più preoccuparsi della sicurezza dell'infrastruttura, della rete o dell'host. Tuttavia, sono emersi nuovi vettori di attacco e gli attacchi già noti sono stati ripensati per gli ambienti serverless. Vediamo un esempio (per l'elenco completo, faccia riferimento a Top 12 Risks for Serverless Applicationsdella Cloud Security Alliance):
Iniezione di dati di eventi
Le falle di iniezione nelle applicazioni, tra i rischi più comuni ad oggi, sono state trattate in modo approfondito in molte guide sulle migliori pratiche di codifica sicura. Ad alto livello, i difetti di iniezione si verificano quando un input non attendibile viene passato direttamente a un interprete prima di essere eseguito o valutato. Nel contesto dell'architettura serverless, tuttavia, le iniezioni di eventi-dati funzionali non sono strettamente limitate all'input diretto dell'utente (come l'input da una chiamata API web). La maggior parte delle architetture serverless fornisce una moltitudine di fonti di eventi che possono innescare l'esecuzione di una funzione serverless.
Esempi di fonti di iniezione di dati di eventi includono:
- Eventi di cloud storage (ad esempio, AWS S3®, Azure Blob Storage, Google Cloud Storage)
- Eventi di database NoSQL (ad esempio, AWS DynamoDB, Azure Cosmos DB®)
- Eventi del database SQL
- Eventi di elaborazione del flusso (ad esempio, Amazon Kinesis®)
- Modifiche al codice e nuovi commit di codice del repository.
- Chiamate API HTTP
Ogni ingresso di evento può includere diversi formati di messaggio e varie parti di questi messaggi di evento possono contenere ingressi controllati da un aggressore o altrimenti pericolosi. La ricca serie di fonti di eventi aumenta la potenziale superficie di attacco e introduce complessità quando si cerca di proteggere le funzioni serverless dalle iniezioni di dati di eventi. Questo è particolarmente vero perché le architetture serverless non sono ben comprese come gli ambienti web, dove gli sviluppatori sanno quali parti del messaggio non dovrebbero essere attendibili (ad esempio, i parametri GET/POST, le intestazioni HTTP, ecc.).
Proteggere le applicazioni serverless
Una sicurezza serverless efficace si concentra sulla garanzia dell'integrità del codice, sulle autorizzazioni strette e sull'analisi comportamentale.
- Accesso e permessi: Mantenga l'accesso meno privilegiato per le funzioni serverless e altri servizi. Ad esempio, se una funzione AWS Lambda deve accedere a una tabella DynamoDB, si assicuri che possa eseguire solo l'azione specifica richiesta dalla logica aziendale.
- Scansione delle vulnerabilità: Assicuri l'integrità del codice e del modello infrastruttura-come-codice , eseguendo regolarmente una scansione per individuare le dipendenze vulnerabili di terzi, gli errori di configurazione e i ruoli troppo permissivi.
- Protezione runtime: Utilizza la protezione runtime per rilevare gli input di eventi dannosi e il comportamento anomalo delle funzioni, e limita, se necessario, la capacità di ciascuna funzione di accedere a file, host, Internet e di generare processi figli.
Domande frequenti su Serverless
L'informatica senza server, nota anche come architettura senza server, è un approccio alla progettazione del software che consente agli ingegneri di costruire ed eseguire applicazioni senza dover gestire l'infrastruttura sottostante. Invece, i fornitori di cloud forniscono server per eseguire applicazioni, database e sistemi di archiviazione per le organizzazioni digitali o cloud-native.
Function-as-a-Service, è un servizio di cloud computing che consente ai clienti di eseguire codice in risposta ad eventi, senza gestire la complessa...
L'architettura serverless è un FaaS che prevede che gli sviluppatori scrivano il codice dell'applicazione come un insieme di funzioni uniche progettate per eseguire compiti specifici in risposta a richieste HTTP o eventi simili. Una volta distribuite le funzioni sull'account del provider cloud, il provider cloud esegue la funzione su un server fornito dal provider cloud.
Esempi di servizi serverless offerti dai provider cloud sono Google Cloud Functions, AWS Lambda e Microsoft Azure Functions.
