Sandbox: come testare applicazioni in ambiente controllato

Quando un’azienda ci chiede di verificare la sicurezza di un’applicazione, la prima domanda che facciamo non riguarda l’applicazione. Riguarda dove la testiamo. È una domanda che sorprende, ma decide tutto il resto: cosa possiamo provare, quanto i risultati somiglieranno alla realtà e quale rischio corre chi ci ha chiamato mentre lavoriamo.

1. Che cos’è una sandbox
2. Perché non si testa in produzione
3. Che cosa serve preparare
4. I limiti di un ambiente isolato
5. Quando si testa comunque sul sistema reale
6. Che cosa chiedere a chi vi propone un test

Che cos’è una sandbox

Una sandbox è un ambiente isolato in cui un programma viene eseguito con risorse e privilegi limitati, senza possibilità di toccare il sistema che lo ospita. Il nome viene dai recinti di sabbia in cui i bambini giocano senza farsi male e senza rompere niente.

Il termine copre però realtà molto diverse fra loro, e conviene distinguerle perché la parola da sola non dice granché.

C’è la sandbox che il software si porta dentro: i browser eseguono ogni scheda in un compartimento separato proprio per questo motivo, e lo stesso fanno i sistemi operativi mobili con le applicazioni. Poi c’è quella dei fornitori di servizi, che mettono a disposizione un ambiente di prova dove gli sviluppatori possono lavorare senza toccare dati reali. E c’è infine la sandbox intesa come ambiente completo e isolato, costruito apposta per riprodurre un sistema e verificarci qualcosa.

È quest’ultima quella che interessa chi fa verifiche di sicurezza, ed è di questa che parliamo.

Perché non si testa in produzione

L’obiezione arriva puntuale: se voglio sapere se il mio sistema è sicuro, perché non lo verificate sul sistema vero?

La risposta ha tre parti.

La prima è il rischio operativo. Una verifica di sicurezza sollecita l’applicazione in modi che l’uso normale non prevede, e alcune di quelle sollecitazioni possono rallentarla, riempire i registri o in casi sfortunati interromperla. Su un gestionale che regge il magazzino di un’azienda manifatturiera, un’interruzione di quaranta minuti ha un costo che nessun risultato di sicurezza compensa.

La seconda riguarda i dati. Verificare un’applicazione significa interagire con quello che contiene, e se contiene dati di persone reali il problema diventa di natura diversa. Un ambiente isolato con dati fittizi rimuove la questione alla radice.

La terza è la ripetibilità. In produzione le condizioni cambiano continuamente, mentre una verifica seria richiede di poter ripetere lo stesso passaggio e ottenere lo stesso esito. Senza questo, distinguere un problema reale da un falso positivo diventa impossibile.

Che cosa serve preparare

Un ambiente di prova utile a una verifica di sicurezza non è una copia approssimativa. Deve somigliare all’originale nelle cose che contano, e le cose che contano sono meno di quante si pensi ma vanno azzeccate tutte.

Serve la **stessa versione** di ogni componente: sistema operativo, server applicativo, motore del database, librerie di terze parti. Una differenza di versione anche minore cambia quali vulnerabilità sono presenti, ed è il motivo per cui un ambiente aggiornato la settimana prima del test restituisce un risultato che non descrive la produzione.

Serve la stessa **configurazione**, che è la parte dove si sbaglia più spesso. Permessi sui file, impostazioni di autenticazione, intestazioni di sicurezza, gestione degli errori: sono tutti elementi che in produzione vengono ritoccati nel tempo da persone diverse e che nelle copie di prova tornano ai valori predefiniti.

Servono dati realistici per forma ma fittizi per contenuto. Un ambiente svuotato non permette di verificare come l’applicazione si comporta con volumi e relazioni reali, mentre uno popolato con dati veri sposta il problema invece di risolverlo.

E servono le utenze con i diversi livelli di privilegio previsti dall’applicazione, perché una parte consistente dei problemi emerge proprio nel passaggio da un livello all’altro.

I limiti di un ambiente isolato

Va detto con onestà: una verifica condotta su un ambiente di prova non è equivalente a una condotta sul sistema reale, e chi sostiene il contrario sta semplificando.

Quello che l’ambiente isolato non riproduce è il contorno. Le regole del firewall che proteggono la produzione, i sistemi che filtrano il traffico verso l’applicazione, l’integrazione con i servizi aziendali, il comportamento sotto carico reale. Un problema che in produzione sarebbe bloccato da un filtro in ambiente di prova risulta sfruttabile, e viceversa un problema che la copia non mostra potrebbe esistere sull’originale.

C’è anche la questione dell’esposizione. Il perimetro raggiungibile da internet è una caratteristica della produzione, non della copia: quali servizi rispondono, con quali versioni e da quali indirizzi si vedono. Quella parte va verificata dove sta, con una analisi delle vulnerabilità sui sistemi esposti, ed è complementare al lavoro sull’applicazione.

La conseguenza pratica è che le due attività non si sostituiscono. La verifica in ambiente isolato dice cosa c’è dentro l’applicazione, quella sul perimetro dice cosa è raggiungibile da fuori, e il quadro completo richiede entrambe.

Quando si testa comunque sul sistema reale

Nonostante tutto quanto detto, in alcuni casi la verifica va fatta sulla produzione, e succede più spesso di quanto sarebbe desiderabile.

Il caso più frequente è l’assenza di alternative. Molte aziende non hanno un ambiente di prova, oppure ne hanno uno talmente divergente dalla produzione da essere inutilizzabile. Ricostruirne uno fedele costa tempo e risorse che non sempre esistono.

Il secondo caso riguarda la natura di quello che si vuole sapere. Se la domanda è cosa vede e cosa raggiunge un attaccante che parte da internet, quella risposta si ottiene solo guardando il sistema vero: è la logica di un penetration test in modalità black box, dove chi verifica parte dalle stesse informazioni di chiunque altro.

Quando si lavora sulla produzione, però, le regole d’ingaggio diventano la parte più importante dell’incarico. Vanno concordati per iscritto il perimetro esatto, le fasce orarie, i sistemi esclusi, le attività che non verranno condotte e le persone da contattare se qualcosa si comporta in modo anomalo. È materia contrattuale prima che tecnica, ed è la differenza fra un’attività autorizzata e un incidente.

Che cosa chiedere a chi vi propone un test

Se state valutando una verifica di sicurezza sulla vostra applicazione, poche domande vi dicono molto sulla serietà della proposta che avete davanti.

Dove verrà condotta l’attività, e se su un ambiente di prova, chi si occupa di allinearlo alla produzione e con quale criterio. Quali categorie di problemi l’ambiente scelto non permette di verificare, perché la risposta “nessuna” non è credibile. Come vengono distinti i risultati confermati da quelli da validare sul sistema reale. E infine cosa succede se durante l’attività qualcosa si comporta in modo inatteso.

Sono domande che un fornitore preparato accoglie volentieri, perché la risposta fa parte del metodo. Le abbiamo affrontate anche parlando delle differenze fra i diversi approcci al penetration test, dove la scelta dell’ambiente e quella del livello di informazioni concesse a chi verifica sono due decisioni distinte che vengono spesso confuse.