Per chi non lo sapesse, il termine DevSecOps è dato dall’unione delle tre particelle Dev, Sec, Ops, a indicare una strategia di sviluppo molto precisa e basata su tre processi: sviluppo, sicurezza e operatività. Si tratta, a tutti gli effetti, di un framework di produzione che non tiene conto solo dello sviluppo e messa in opera di un software applicativo, ma anche di precise metodologie dedicate alla sicurezza e al controllo del codice.
Fino all’introduzione del framework, l’implementazione di una soluzione software era relegata al paradigma DevOps, quindi di fatto il rapporto diretto (e spesso traumatico) tra la fase di sviluppo di un’applicazione e la sua pubblicazione e utilizzo.
Col DevSecOps cambia il paradigma: la sicurezza entra appieno nel ciclo di sviluppo, toccandone ogni fase. E la metodologia si è dimostrata così efficace da non essere utilizzata solo in ambito di sviluppo vero e proprio, ma in ogni contesto ove sia necessario implementare una qualche tecnologia.
Indice degli argomenti
DevSecOps: sicurezza passo dopo passo
Il framework DevSecOps nasce da un’esigenza specifica: affiancare la sicurezza a tutti i processi di sviluppo tecnologico.
Negli anni, la diffusione dei micro-servizi, delle transazioni e del cloud ha portato a una smodata accelerazione delle pratiche di sviluppo e solo in un secondo momento ci si è resi conto che tanto più forsennata era la corsa, tanto maggiori erano le problematiche che scaturivano sul versante della sicurezza.
È così che Gartner, nel 2012, ha sviluppato il modello DevSecOps. Un concetto all’apparenza semplice, ma che sottende a regole molto precise, definendo, innanzitutto, lo spazio operativo del DevOps nell’ambito della sicurezza, con un inizio e una fine ben delineate e organizzando il lavoro dei team dedicati alla sicurezza e al loro ruolo nel corso di tutto lo sviluppo.
La sicurezza non arriva più in coda allo sviluppo, ma lo accompagna passo passo; un approccio che, se da una parte offre vantaggi evidenti, dall’altra richiede anche di cambiare alcune strategie di sviluppo.
DevSecOps: vantaggi per ogni team
La principale strategia da modificare riguarda proprio i developer, che, secondo il modello DevOps, tendono a lavorare in modo incontrollato, producendo montagne di codice non verificato e, dunque, esposto a vulnerabilità e scarsa sicurezza.
Ecco perché il concetto di container, e la sua introduzione, è diventato il complemento perfetto al DevSecOps. Un container, lo ricordiamo, è un ambiente virtualizzato che, nella sua forma più elevata, rappresenta uno spazio-utente a sé e indipendente dagli altri.
Ogni applicazione è interamente stipata in container separati, accomunati solo da alcune funzioni del medesimo sistema operativo utilizzato. File binari e di configurazione, librerie e dipendenze sono incapsulate e isolate nel rispettivo container, limitando il contatto diretto col sistema operativo solo a poche e precise funzioni.
La gestione della sicurezza da parte degli sviluppatori, dunque, inizia e termina all’interno del container, il quale a sua volta può entrare nel pieno controllo del team dedicato proprio alla protezione. E in cosa consiste, questo controllo?
F5 NGINX e un nuovo concetto di load balancer
In generale, nel controllo di tutto ciò che esula dallo sviluppo in senso stretto, focalizzandosi piuttosto sulle interazioni tra il codice e l’ambiente esterno al container, con una particolare attenzione a tutto ciò che concerne l’architettura di rete in cui sono implementati i container.
Un compito complesso, per il quale, per fortuna, esistono strumenti molto efficaci. F5 NGINX è uno di questi e la sua versatilità gli consente di estendere le proprie funzioni anche ai tradizionali DevOps, sempre interessati a fornire le proprie applicazioni e micro-servizi a un bacino sempre più esteso di clienti e nel minor tempo possibile.
Volendo semplificare, F5 NGINX è un bilanciatore con prestazioni elevate e processi di configurazioni molto semplici. Di fatto, pochi click e chiamate API dichiarative consentono di integrarlo nel proprio flusso DevSecOps.
Con F5 NGINX, oltre a poter personalizzare la gestione del bilanciamento, è possibile effettuare routing basato sul protocollo HTTP, gestire il caching, verificare l’efficienza del sistema e, più di tutto, garantire la piena protezione da attacchi applicativi con il nuovo NGINX App Protect WAF, che porta il motore di un WAF leader di mercato quale F5 Advanced WAF, a bordo di NGINX.
NGINX App Protect WAF, inoltre, è il primo WAF che gira a bordo in un Ingress Controller per gli ambienti Kubernetes e Openshift.
Non un semplice bilanciatore
Il tema dei bilanciatori è molto spesso ignorato, ma F5 NGINX ne estende le funzionalità al punto che, definirlo un classico load balancer, suona molto restrittivo.
Per esempio, bilancia il traffico di TCP, UDP e HTTPS gestendo le richieste via URL, cookies e altre modalità a livello applicazione. Riduce la memory cache necessaria al funzionamento di oltre il 90% e sfrutta il micro-caching per offrire prestazioni tra le più elevate al mondo. F5 NGINX, soluzione proposta solo da partner selezionati, tra cui l’italiana Sinthera, offre un’efficienza a tutto tondo, che si traduce anche in una sicurezza che abbraccia ogni parte del processo, nel pieno spirito del DevSecOps.
A tutto questo, ovviamente, contribuisce una configurabilità maggiore, che facilita la gestione anche in attività non proprio banali come il routing del traffico verso la propria applicazione. Qualche modifica e due chiamate API e il gioco è fatto: il routing applicativo è aggiornato e una nuova versione della web application security policy è stata caricata.
Ecco, se c’è una cosa che, più di altre, va compresa della filosofia DevSecOps, è che occorre dotarsi di strumenti capaci di estendere il controllo nei suoi tre campi: Dev, Sec, Ops. Un load balancer di nuova generazione, come F5 NGINX, ne è un perfetto esempio.
Contributo editoriale sviluppato in collaborazione con Sinthera
