L'intervista

API, microservizi e container: come garantire la sicurezza delle applicazioni moderne

Giulio Roggero, co-founder e CTO di Mia Platform: Fondamentale che gli sviluppatori adottino un approccio di security by design, sia nelle AAPI sia per i microservizi. Ma strumenti come gli API Gateway da soli non garantiscono il risultato

Pubblicato il 27 Lug 2020

“Spesso chi sviluppa codice si occupa soltanto in un secondo momento degli aspetti legati alla sicurezza, ad esempio adottando strumenti di controllo. Ma questo non è sufficiente: il tema della sicurezza delle applicazioni deve essere affrontato già in fase di design”. A sottolineare l’importanza della security by design nella programmazione delle applicazioni in un’intervista a RiskManagement360 è Giulio Roggero, co-founder e CTO di Mia Platform, eccellenza internazionale del software nata a Milano. Mia-Platform offre una delle poche soluzioni al mondo – lo dicono le ricerche di Gartner –  che consente di realizzare il Digital Integration Hub, una piattaforma digitale omnicanale basata su Fast Data, microservizi e API. Per architetture di questo tipo, alla base dello sviluppo di applicazioni moderne, la sicurezza è una componente fondamentale..

Roggero, come si fa a garantire la sicurezza delle applicazioni?

“I due elementi chiave nello sviluppo degli applicativi moderni sono i microservizi e le API. I microservizi, che possono essere basati su linguaggi diversi, svolgono specifiche funzioni; le API invece si occupano di standardizzare l’esposizione delle informazioni. Per questo, la sicurezza delle applicazioni moderne passa innanzitutto per questi due elementi. A fornire una prima barriera di sicurezza sono strumenti come gli API Gateway, che permettono di eseguire il controllo degli accessi alle API e sono per questo oggi molto diffusi. Tuttavia, possono essere considerati una commodity: strumenti particolarmente utili perché svolgono funzioni essenziali, ma che non sono ormai sufficienti a garantire la sicurezza delle applicazioni, nemmeno se accompagnati da micro-gateway per la sicurezza tra gruppi di microservizi a diversi livelli.”

Quali sono gli ambiti dove ci sono più vulnerabilità e su cui è necessario focalizzare l’attenzione?

Sono essenzialmente tre: il primo tema è quello della scrittura del codice e delle librerie – in questo ambito, l’utilizzo di strumenti di analisi del codice statico e delle dipendenze è irrinunciabile. In secondo luogo è necessario considerare la vulnerabilità di container e docker image, e infine la comunicazione tra i microservizi e l’esterno. In quest’ultimo caso, per esempio, una criticità potrebbe derivare dal fatto di aver scaricato un microservizio malevolo; come posso essere sicuro che questi non vada ad  intercettare altre richieste? Le risposte a queste criticità risiedono in una serie di pratiche e strategie: seguire i principi di secure coding, adottare strategie infrastrutturali e architetturali, e organizzarsi in team cross funzionali in grado di individuare e contrastare in autonomia le minacce, e responsabili della sicurezza dell’esposizione delle API e delle informazioni – i cosiddetti “feature teams”.

Cosa intende quando parla di soluzioni infrastrutturali e architetturali?

Delle politiche infrastrutturali fanno parte la cifratura della connessione, il costante monitoraggio delle API, utilizzando ad esempio tecniche di penetration testing, la gestione e limitazione delle richieste API con il cosiddetto API Throttling, per proteggersi da attacchi Dos o Ddos, i controlli di sicurezza con  geo-IP filtering o il blocco delle chiamate da proxy anonimi, e infine l’utilizzo di VPN che consentono connessioni sicure tra le reti locali e i dispositivi client. Delle soluzioni architetturali fanno parte i già citati API gateway, che consentono di centralizzare il controllo degli accessi, l’adozione di metodi di autorizzazione token-based, l’utilizzo di una lista di controllo accessi e la buona pratica di occultamento delle informazioni negli URL. Una buona pratica che sta alla base di tutto ciò che abbiamo detto finora, inoltre, è quella di separare i canali d’interazione commerciali dai sistemi core: questo può essere fatto adottando una soluzione Digital Integration Hub, che raccoglie le informazioni da una serie di fonti dati differenti, le aggrega secondo le logiche di business e le espone ai canali attraverso API. In questo modo i sistemi sono protetti, perchè l’unico punto di ingresso è un API Gateway solido, leggero ed affidabile”.

Questo per l’aspetto tecnologico. E per quello delle competenze?

Se partiamo dall’assunto che gli strumenti tecnologici ci sono e sono molti, il passo successivo è sviluppare le skill per utilizzarli e integrarli nel modo migliore, a seconda delle necessità. Spesso scegliere lo strumento giusto può essere complesso, come può esserlo anche individuare quelli che, combinati tra loro, sono in grado di dare il risultato migliore. Poi c’è la necessità, una volta scelti gli strumenti, di configurarli e inserirli nel modo più indicato nella catena di sviluppo del software, coordinandone l’utilizzo tra team differenti che hanno esperienze, competenze, esigenze e obiettivi diversi.”

Qual è la difficoltà più grande da questo punto di vista?

Si tratta essenzialmente di un tema di governance della Factory IT. Se da una parte per i piccoli team che lavorano in Agile e DevOps è tutto relativamente semplice, quando questi numeri sono più grandi e le persone e le funzioni coinvolte crescono, con loro aumentano anche le difficoltà. È frequente che si verifichi la possibilità che alcuni team non abbiano la visibilità completa sui processi e sulle vulnerabilità.”

Come si fa a evitare questo genere di problemi?

“La risposta sta prima di tutto nelle politiche: si tratta di decidere una strategia di come a livello enterprise si vogliano affrontare questi possibili problemi legati alla scrittura del codice e alle librerie, alla vulnerabilità dei container, alla comunicazione tra servizi, all’esposizione di API, e soprattutto su come si sia capaci di mettere a terra queste policy in maniera il più possibile semplice e concreta. Per esempio, linee guida semplici e intuitive dovrebbero essere messe a disposizione di tutti, anche di  chi è fuori dall’azienda, come ad esempio i fornitori esterni, con l’obiettivo di rendere lo sviluppo il più possibile rapido, sicuro e performante.”

Quale approccio avete adottato in Mia Platform sulla sicurezza?

“Il nostro ruolo  è organizzare e predisporre il modello migliore a seconda delle esigenze specifiche del cliente, valorizzando l’esperienza maturata in anni di attività su queste tecnologie in diversi settori, come ad esempio il mondo finanziario, le infrastrutture, i trasporti. Questo vuol dire selezionare e predisporre un insieme di strumenti “best of breed” (solitamente tra i dieci e i quindici) configurati e messi a disposizione dei team di sviluppo e operations attraverso la DevOps Console di Mia-Platform.. Le linee guida diventano così “vive”: non sono un faldone che prende polvere sullo scaffale, ma sono implementate by design nell’intero ciclo di vita dello sviluppo software. Il cliente avrà così a disposizione uno strumento che facilita il lavoro dei team interni e dei fornitori esterni, automatizzando le attività, e semplificando i processi. Inoltre, questo modello potrà evolvere nel tempo assecondando le esigenze sempre nuove del business e dell’IT aziendale.  Tutto questo risponde anche a un tema culturale: i team devono essere a conoscenza di quali siano, volta per volta, i rischi e di cosa si debba fare per evitarli. Questo è garantito dalla possibilità di avere ampia visibilità, in un’unica Console, di tutti i processi che al team occorre monitorare.”

Parlare di security by design è più semplice quando si costruisce un sistema da zero. Ma cosa succede quando si integrano sistemi vecchi e nuovi?

In questi casi, che sono molto diffusi, l’importante è conoscere a fondo la situazione e monitorare attentamente ciò che accade in tempo reale. Un approccio centrato sulla observability permette di individuare immediatamente i problemi attuali e i rischi potenziali, potendo così intervenire dove è necessario. Ad esempio  in tema Cloud, l’esigenza di mantenere alcune funzioni on premise è frequente e va rispettata;  l’importante è che ci sia la possibilità di isolare le parti più critiche. L’obiettivo è fare stream di dati sul Cloud, con politiche di sicurezza già implementate: in questo modo si garantisce che  tutto il nuovo set sia sicuro by design mentre ciò che è scoperto sia ben definito e soprattutto isolabile dal resto.”

New call-to-action

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

Argomenti trattati

Approfondimenti

S
sicurezza

I commenti sono chiusi.

LinkedIn

Twitter

Whatsapp

Facebook

Link