Kumo: A Security-Focused Serverless Cloud Simulator

Titolo

Kumo: Un Simulatore Cloud Serverless Focalizzato sulla Sicurezza

1. Il Problema

Il computing serverless offre elasticità e semplificazione del deployment, ma nasconde le decisioni di gestione dell'infrastruttura (pianificazione, condivisione delle risorse, riutilizzo dei container) che possono introdurre rischi di sicurezza significativi.

• Vulnerabilità: Le piattaforme serverless sono vulnerabili ad attacchi che sfruttano ambienti di esecuzione condivisi, in particolare:
  • Attacchi di Co-localizzazione: Un attaccante cerca di eseguire le proprie funzioni sullo stesso worker (nodo fisico) di una vittima per sfruttare canali laterali o fughe di informazioni.
  • Attacchi di Denial-of-Service (DoS): Un attaccante degrada le prestazioni della vittima o causa la perdita di invocazioni attraverso la contesa delle risorse e l'accumulo nelle code.
• Limitazioni degli Approcci Attuali:
  • Analizzare questi rischi su piattaforme di produzione è difficile a causa della scarsa osservabilità, dell'alto costo e della mancanza di controllo sperimentale.
  • Gli simulatori esistenti si concentrano principalmente su prestazioni, costi e pianificazione della capacità, mancando di modelli espliciti per gli attaccanti, metriche di isolamento e analisi del comportamento dello scheduler come meccanismo di sicurezza.

2. Metodologia: Kumo

Gli autori presentano Kumo, un simulatore a eventi discreti progettato specificamente per l'analisi della sicurezza nelle piattaforme serverless.

• Architettura e Design:

  • Modellazione Esplicita: Kumo tratta attaccanti e vittime come entità di primo piano, permettendo di tracciare le loro interazioni attraverso le risorse condivise.
  • Componenti Chiave: Il simulatore modella l'arrivo delle invocazioni, le decisioni dello scheduler, il riutilizzo dei container (avvii "cold" vs "warm"), la contesa delle risorse e il comportamento delle code.
  • Scheduler Pluggable: Le politiche di scheduling sono implementate come astrazioni modulari, permettendo di confrontare diverse strategie (es. Random, DoubleDip, Helper, OpenWhisk) senza modificare il motore di esecuzione.
  • Configurabilità: Gli esperimenti sono guidati da file di configurazione che definiscono parametri della piattaforma, carichi di lavoro, comportamenti degli attaccanti e semi casuali per la riproducibilità.

• Metriche di Sicurezza:
  Kumo raccoglie metriche specifiche per la sicurezza, tra cui:

  • Probabilità di co-localizzazione.
  • Tempo fino alla prima co-localizzazione.
  • Tasso di perdita delle invocazioni (drop rate).
  • Latenza di coda (tail latency, es. p95).

3. Contributi Chiave

1. Progettazione di Kumo: Un simulatore configurabile e guidato da eventi che modella esplicitamente la pianificazione, il riutilizzo dei container, la contesa e le code per l'analisi della sicurezza.
2. Framework di Modellazione Attaccante/Vittima: Un approccio flessibile per modellare carichi di lavoro ostili e benigni, consentendo la misurazione diretta degli impatti sulla sicurezza.
3. Studi di Caso Approfonditi: Due studi che dimostrano come le scelte dello scheduler e la gestione delle risorse a livello di sistema influenzino classi distinte di rischi di sicurezza.

4. Risultati degli Studi di Caso

Studio di Caso A: Sicurezza della Co-localizzazione

• Obiettivo: Valutare come diverse politiche di scheduling influenzino la probabilità che un attaccante e una vittima condividano lo stesso worker.
• Risultati:
  • La scelta dello scheduler è un fattore determinante. Ad esempio, lo scheduler DoubleDip (che cerca di diffondere le invocazioni) ha eliminato quasi completamente la co-localizzazione (probabilità zero).
  • Al contrario, scheduler come Random mostrano un'alta probabilità di co-localizzazione, mentre Helper e OpenWhisk (ottimizzati per il riutilizzo dei container) si posizionano in mezzo, con un rischio intermedio ma significativo.
  • Trade-off: È possibile ottenere una bassa probabilità di co-localizzazione senza necessariamente aumentare il costo degli avviamenti "cold" (cold-start), sfatando il mito che isolamento e prestazioni siano sempre in conflitto diretto.
  • Tempo di attacco: Lo scheduler influenza anche quanto velocemente un attaccante può riuscire a co-localizzarsi; alcuni scheduler ritardano l'attacco di ordini di grandezza.

Studio di Caso B: Attacchi DoS e Degrado della Disponibilità

• Obiettivo: Analizzare come l'intensità dell'attacco, le politiche di coda e la scala del cluster influenzino la disponibilità e la latenza.
• Risultati:
  • Intensità dell'Attacco: All'aumentare del carico ostile, il tasso di perdita delle invocazioni (drop rate) e la latenza di coda (p95) aumentano. Lo scheduler Helper mostra tassi di perdita più elevati rispetto a DoubleDip sotto carico, suggerendo che alcune politiche di riutilizzo concentrano la contesa creando "hotspot".
  • Lunghezza della Coda: Aumentare la capacità della coda riduce le perdite di invocazioni ma aumenta drasticamente la latenza di coda (tail latency), spostando il fallimento dalla perdita di dati al degrado delle prestazioni.
  • Scala del Cluster: L'aumento del numero di worker migliora la disponibilità, ma con rendimenti decrescenti. Una volta che la contesa delle risorse domina, la politica dello scheduler ha un impatto minore rispetto a fattori di sistema come la dimensione della coda e la capacità totale.

5. Significato e Conclusioni

• Distinzione Critica: Il lavoro evidenzia una distinzione fondamentale tra i rischi di isolamento guidati dallo scheduler (che possono essere mitigati scegliendo politiche di placement appropriate) e le vulnerabilità di esaurimento delle risorse (DoS), che dipendono da fattori di sistema come la gestione delle code e la capacità del cluster.
• Implicazioni per il Design: Gli scheduler non dovrebbero essere visti solo come ottimizzatori di prestazioni, ma come meccanismi di sicurezza configurabili. Allo stesso tempo, le difese contro il DoS richiedono strategie a livello di sistema (controllo degli accessi, dimensionamento delle code) oltre alla semplice pianificazione.
• Valore di Kumo: Kumo fornisce una base flessibile e riproducibile per esplorare i compromessi (trade-off) tra sicurezza e prestazioni nelle piattaforme serverless, permettendo ai ricercatori di testare scenari di attacco senza i costi e le limitazioni delle piattaforme di produzione reali.
• Disponibilità: Il codice sorgente di Kumo è rilasciato come software open-source e ha ricevuto il badge "Results Reproduced" (ROR-R) dal comitato di valutazione CCGRID.

In sintesi, il paper dimostra che la sicurezza serverless non è un problema monolitico: richiede un'analisi separata delle strategie di isolamento (scheduler) e della gestione della contesa delle risorse, e Kumo è lo strumento ideale per condurre tale analisi in modo sistematico.