PaaS security significa valutare la sicurezza di tutto l’ecosistema associato a questo tipo di soluzioni in cloud, includendo API annesse e connesse e tutte le funzionalità di sicurezza informatica garantite in vario modo dai cloud provider. Dal momento che sempre più aziende sfruttano i vantaggi delle piattaforme Platform as a Service, affrontare le potenziali vulnerabilità e minacce che possono compromettere la sicurezza di applicazioni e dati affidati alle nuvole è diventato fondamentale.
Minacce e problemi della sicurezza PaaS
Le piattaforme PaaS sono obiettivi molto attraenti per gli hacker perché, se non presidiate dal punto di vista della sicurezza informatica, possono fornire le chiavi per accedere a un’ampia gamma di applicazioni e dati. I principali punti di attenzione sono:
- Vulnerabilità della piattaforma: il cybercrime può sfruttare le vulnerabilità della piattaforma o delle applicazioni in esecuzione sulla piattaforma per ottenere il controllo del sistema o rubare dati sensibili.
- Vulnerabilità delle applicazioni: gli sviluppatori che creano applicazioni utilizzando piattaforme PaaS se non utilizzano pratiche di codifica sicure aprono la porta al cybercrime. Ciò può influire non solo sulla sicurezza della singola applicazione e dell’intero ecosistema PaaS.
- Visibilità limitata: con l’aumento della complessità dell’infrastruttura PaaS, diventa più difficile ottenere visibilità, rilevare vulnerabilità e minacce e capire come mitigarle. Serve molta attenzione e grandi competenze.
A differenza di altri modelli cloud, alcune misure di sicurezza sono particolarmente utili specificamente per il PaaS, ad esempio le aree in cui i team di sicurezza devono concentrarsi su tutta la parte applicativa. Ciò rende il PaaS molto più difficile da proteggere rispetto ad altri modelli cloud: in primo luogo perché la sicurezza delle applicazioni non è un’area in cui la sicurezza informatica non si è mai focalizzata con la dovuta attenzione e preparazione fino a oggi. Dal momento che in quest’ambito non esistono contromisure standardizzate le iniziative devono essere allineate al caso d’uso specifico, il che riporta il tema di una preparazione che ancora non vede preparati la maggior parte degli esperti di sicurezza.
PaaS security: ci sono provider e provider
Come già accennato, le pratiche legate alla catena di fornitura del cloud e le relative sfide in termini di sicurezza si applicano al PaaS nella stessa misura in cui si applicano ad altri software e servizi legati alle nuvole. Occorre analizzare e valutare nel dettaglio le trattative contrattuali con i provider, validando i loro ambienti, i loro processi e le loro certificazioni come, ad esempio, la ISO 27001, la loro presenza nel registro CSA STAR, SOC 2 e via dicendo. Ciò potrebbe includere anche l’identificazione dei modelli di sicurezza in uso e degli strumenti rilevanti per la sicurezza che il fornitore mette a disposizione del cliente. Analisi e assessment quando si sceglie un fornitore PaaS servono a comprendere qual è il modello di sicurezza di cui si usufruirà. Come sottolineano gli esperti, ciò che può sembrare abbastanza semplice, quando si tratta di sicurezza può diventare davvero molto complesso.
Oltre a capire come funziona la piattaforma e importante sapere cosa fare per proteggere i propri dati. La PaaS security, infatti, non è di esclusiva responsabilità del fornitore. Proteggere la sicurezza di un ambiente Paas richiede di smarcare una checklist per verificare:
- Quali controlli di accesso offre il provider, a quale livello di granularità opera e cosa è necessario quotidianamente per proteggere le applicazioni.
- Quale tipo di crittografia è disponibile e quali sono i passaggi pratici per abilitarla per ciascun tipo di carico di lavoro.
- Se il fornitore offre backup e ripristino di emergenza come parte del proprio servizio e, in caso contrario, come il cliente dovrebbe gestire queste preoccupazioni.
- Quali punti di integrazione hanno i framework PaaS con altre applicazioni o sistemi cloud e chi è responsabile della prevenzione delle minacce alla sicurezza che affliggono tali sistemi.
Di seguito andiamo ad approfondire meglio le cose da fare e gli errori da evitare.
Le sfide principali delle piattaforme PaaS
Una delle principali fonti di complessità è che il PaaS è spesso parte di uno sviluppo di applicazioni più ampio, che supportano sia le applicazioni aziendali interne che software e servizi offerti dalle stesse aziende a clienti o partner. Ad esempio, le organizzazioni potrebbero utilizzare il PaaS per:
- Semplificare lo sviluppo delle API RESTful
- Fornire servizi applicativi
- Come metodologia architetturale per avvicinare la logica agli utenti finali
- Implementare servizi di uso comune, ad esempio database relazionali, in modo indipendente dall’implementazione
Come presidiare la PaaS security
In estrema sintesi, un sistema PaaS, analogamente ad altri ambienti in cloud, deve affrontare le stesse minacce alla sicurezza, tra cui l’isolamento del sistema e delle risorse, le autorizzazioni a livello di utente, la gestione dell’accesso degli utenti e la protezione contro i comuni attacchi cloud, come malware e ransomware. Tuttavia, sussistono alcune differenze dal punto di vista delle minacce e della loro mitigazione.
#1 Configurazioni
I team addetti alla sicurezza devono considerare le numerose impostazioni e opzioni di configurazione rilevanti per la sicurezza, avendo contezza di cosa significhino e di come interagiscano tra loro e con l’applicazione. Oltre a comprendere il profilo di rischio occorre valutare in che modo le impostazioni effettuate rafforzano o interferiscono o meno con esso. Non è raro che alcune impostazioni siano meno intuitive del previsto. In alcuni casi, ciò può tradursi in un indebolimento del livello di sicurezza.
#2 Variazioni delle condizioni di servizio
È importante anche rimanere allineati alle varie modifiche che possono essere apportate al servizio, comprese le funzionalità deprecate, le modifiche all’implementazione e le notifiche da parte del fornitore di servizi. Ognuna di queste variazioni, infatti, può influire sulla sicurezza.
#3 Stack management
Nella maggior parte delle situazioni PaaS, i team hanno meno opportunità di affrontare considerazioni sulla sicurezza ai livelli più bassi dello stack. In un’applicazione inviata a un host controllato direttamente da un’azienda, ad esempio un carico di lavoro virtuale in un modello IaaS, i team possono scegliere di indirizzare i livelli inferiori dello stack per compensare le aree problematiche ai livelli più alti. Poiché l’organizzazione non ha il controllo sui livelli inferiori dello stack in PaaS, non ha più l’opportunità di mettere in atto queste soluzioni tampone.
#4 Frizioni software
In quarto luogo, il PaaS è un software e tutti i software possono presentare vulnerabilità. La logica è quella del compromesso: se è vero che le implementazioni PaaS permettono alle organizzazioni di non doversi più preoccupare di tutti gli oneri di gestione delle patch e degli aggiornamenti di sicurezza, dal momento che utilizzano una serie completamente nuova di servizi che implementano il PaaS, non è infrequente avere problemi lato software.
#5 Sviluppo applicativo
Le Platform as a Service vengono spesso utilizzato per supportare direttamente la creazione di applicazioni, durante le quali possono verificarsi numerosi problemi di progettazione, logica, codifica e implementazione. Per quanto specifici all’attività di sviluppo specifici e indipendenti dallo stack su cui è costruita l’applicazione, anche questo aspetto della Paas security va presidiato e gestito.
5 best practice per la sicurezza PaaS
Le strategie di sicurezza PaaS variano a seconda dell’ambiente aziendale, del contesto industriale e operativo. Tuttavia, esistono cinque best practice per la sicurezza PaaS che possono essere applicate in quasi ogni situazione. L’integrazione dei cinque passaggi seguenti può contribuire a garantire che le applicazioni vengano create ed eseguite in modo sicuro con un investimento relativamente ridotto.
1. Iniziare con la modellazione delle minacce
Che si tratti di PaaS o di qualsiasi altro ambito di programmazione, la sicurezza delle applicazioni dovrebbe iniziare sempre con una modellazione delle minacce. Questo processo sistematico scompone la progettazione di un software nelle sue componenti, per consentire di analizzare il modo in cui queste parti interagiscono per l’aggressore. La valutazione dei componenti dell’applicazione e dei rischi associati consente ai modellatori di minacce di delineare le fasi di mitigazione per correggere eventuali vulnerabilità scoperte.
Indipendentemente da quali fornitori PaaS vengano utilizzati o per quale scopo, la creazione di un modello di minaccia sistematico aggiunge valore. Se necessario, i team di sicurezza possono aggiornare i metodi di test della sicurezza delle applicazioni per estendere il modello di minaccia ai microservizi e all’architettura mesh.
2. Crittografare i dati inattivi e in transito
La maggior parte delle offerte PaaS consentono o richiedono ai clienti di crittografare i dati in transito. Questo è per una buona ragione. Le API REST, che comunicano utilizzando HTTPS come trasporto, rappresentano oggi lo stile architettonico standard di riferimento nello sviluppo di applicazioni, soprattutto in un contesto cloud.
I dati archiviati, al contrario, vengono affrontati in modo meno ubiquitario. A seconda dell’applicazione in fase di sviluppo e del suo profilo di rischio, i team dovrebbero prevenire l’esposizione dei dati nella misura del possibile tenendo conto delle misure di prevenzione gestite dal personale del fornitore di servizi che amministra il servizio. Ciò aiuta a garantire la protezione dei dati anche in caso di compromissione del fornitore di servizi sottostante.
Un modo per contribuire a sostenere questi obiettivi è utilizzare la crittografia. Ove possibile, crittografare sempre i dati archiviati, siano essi dati dei clienti o informazioni sulla configurazione o sulla sessione. In un contesto PaaS, la crittografia dei dati inattivi potrebbe richiedere ai team di sicurezza di adottare strumenti specifici per le API dei fornitori PaaS. Dopo aver crittografato i dati inattivi e in transito, prestare attenzione alla gestione dei segreti. Ciò vale per le chiavi create e utilizzate per implementare la crittografia dei dati inattivi, nonché per le password, i token API e altri elementi che devono essere mantenuti sicuri.
3. Mappare e testare le interazioni nel flusso aziendale
L’utilizzo di più provider cloud più che un’eccezione è una regola. Questo vale sia per il PaaS che per altri casi d’uso del cloud. Ad esempio, un’azienda potrebbe utilizzare il serverless sull’edge per i test A/B, AWS Lambda per implementare la logica aziendale, Heroku per servire l’interfaccia utente e così via. Creare e aggiornare costantemente un diagramma completo delle interazioni è fondamentale. Questo processo supporta anche la best practice numero 1 succitata della PaaS security, poiché la modellazione delle minacce implica la creazione di un diagramma del flusso di dati per rappresentare il modo in cui interagiscono i componenti.
Per garantire che tutti gli elementi siano completamente coperti durante i test di penetrazione, i team di sicurezza dovrebbero testare sistematicamente ciascun elemento in modo olistico e isolato. L’utilizzo della Guida al test della sicurezza Web di OWASP può aiutare in questo processo.
4. Considerare la portabilità per evitare il lock-in
Una sfida unica con il PaaS è che le funzionalità supportate, come le API sottostanti, i servizi di sicurezza e persino la scelta del linguaggio, dipendono dallo specifico PaaS in uso. Ad esempio, un provider PaaS potrebbe supportare Java e Python, mentre un altro potrebbe supportare Go, C# e JavaScript. Per problemi di lockin, i clienti PaaS raramente possono passare da un PaaS a un’altra piattaforma concorrente, il che avviene in parte anche a causa delle API utilizzate. È importante utilizzare un linguaggio comunemente supportato da diversi fornitori perché massimizza la portabilità e riduce al minimo i vincoli. Ciò è particolarmente vero se si considerano fornitori più piccoli e di nicchia. I linguaggi utilizzati di frequente, come C#, Python e Java, sono in genere supportati da tutti i provider. È opportuno creare anche wrapper attorno alle API di nicchia per implementare un livello di astrazione tra un’applicazione o un servizio e le API di nicchia sottostanti perché, in questo modo, se si cambia fornitore basta apportare una sola modifica, anziché centinaia o migliaia.
5. Sfruttare le funzionalità di sicurezza specifiche della piattaforma
Sempre e comunque, è necessario comprendere quali opzioni sono le funzioni di sicurezza disponibili e, ove possibile, abilitarle. Alcune piattaforme potrebbero fornire un firewall per applicazioni Web o un gateway applicazione che può essere attivato per proteggere meglio applicazioni e servizi. Altri potrebbero offrire funzionalità di registrazione e monitoraggio avanzate. I leader della sicurezza informatica devono identificare quali opzioni di sicurezza vengono offerte e trarne vantaggio. Sempre e in ogni caso è fondamentale mantenere una strategia di gestione delle identità e delle credenziali, implementando i modelli cloud offerti dal provider di:
- gestione dell’identità e degli accessi
- autorizzazione
- autenticazione
Il tutto assicurandosi di integrarli nei processi back-end per l’accesso da parte dell’amministrazione o dello sviluppatore, nonché nell’applicazione stessa.
