La disponibilità illimitata di hardware e software on demand consente una rivoluzione delle architetture applicative e delle modalità di sviluppo software
Gli sviluppi delle tecnologie, e dell’ICT in particolare, sono come le gallerie delle talpe: nessuno se ne accorge fino a che, all’improvviso, il terreno collassa. Questo fenomeno non è frequentissimo, ma è inevitabile ed è quello che si sta realizzando in particolare sul fronte della cloud. La nuvola è nata come infrastruttura condivisa. È dagli anni 60 che si cerca di mettere a fattor comune strumenti costosi e complessi per ridurne il costo e migliorarne l’efficacia. Con la condivisione di ambienti standard invece di avere un sistema HW/SW per ogni utente, diverso da ogni altro, si risparmiavano i costi dell’implementazione, si sfruttavano le competenze acquisite, si spendeva meno.
La nuvola si è evoluta. Da condivisione di infrastruttura si è trasformata in infrastruttura on demand. Ottenere un nuovo server “fisico” richiede tempo, denaro, pianificazione. Ottenere potenza di calcolo e spazio disco in cloud richiede minuti e una carta di credito. Il che velocizza il processo, e nella corsa eterna tra sistemisti e applicativi mette questi ultimi in grande difficoltà. Le applicazioni non si ottengono con una telefonata a un cloud provider, tanto più quando l’identità delle aziende è determinata dalle applicazioni stesse, che quindi richiedono una cura e una attenzione ancora più grandi che nel passato. E se l’identità della azienda è determinata dal software, i tempi per l’adeguamento del software si trasformano nel concetto di time-to-market.
Da qui Agile development, DevOps, e l’infrastruttura: container, Docker, Kubernetes… Tutti nomi abbastanza poco noti, specie al mondo della sicurezza, con cui tuttavia occorre fare i conti. Occorre fare alla svelta e fare bene, e qui i container, moduli che contengono un eseguibile con tutte le risorse (dati, parametri, strumenti di sistema…) che gli necessitano, giocano un grande ruolo. Poi i container devono essere messi in campo, coordinati, verificati e gestiti. Il lavoro infrastrutturale continua, solo su un piano diverso. Il cambiamento spiazzante nelle architetture applicative porta conseguenze altrettanto spiazzanti in tema di security.
In un contesto in cui la funzionalità non viene erogata da una applicazione monolitica che gira all’interno del perimetro aziendale, ma da micro servizi autonomi che girano ognuno indifferentemente su AWS, Azure, private cloud…, parlandosi tra loro, il perimetro cessa di esistere come entità “fisica”. Si parla quindi di Software Defined Perimeter. Il che significa che l’accesso da proteggere non sarà solo quello alla rete aziendale, al cui interno tutto è convenzionalmente considerato sicuro, ma ai micro servizi, che sono … non necessariamente si sa dove. Quindi il firewall aziendale non cessa di essere necessario, ma servono dei micro firewalls a livello dei singoli containers. E per la loro protezione occorrerà utilizzare meccanismi di micro segmentazione in grado di stabilire quale utente possa accedere a quali micro servizi, e quali micro servizi possano parlare con quali altri.
Usare container per il continuous deployment è una soluzione che consente i rilasci indispensabili, ma che fare per il security testing? Non solo le applicazioni sono l’azienda, e quindi hanno una maggiore criticità, ma il testing di sicurezza è una fase aggiuntiva a quelle abituali, e rallenta il ritmo. Una nuova tecnologia arriva in soccorso: si chiama Interactive Application Security Testing (IAST), e consiste nel test automatico della applicazione durante la fase del test funzionale. In sostanza, lo sviluppatore riceve informazioni sulla sicurezza del codice che ha scritto nel momento stesso in cui controlla che la funzionalità sia stata effettivamente implementata. La fase di Security Testing applicativo cessa di avere una vita a sé stante.
Paolo da Ros, membro del comitato scientifico CLUSIT
