DevOps o non DevOps? Di sicuro di problema non si tratta, anzi con il termine DevOps si intende un approccio smart alla cooperazione tra team di sviluppo di applicazioni e servizi (sviluppo e operation) con un unico obiettivo, quello di rendere il business più agile e favorire la miglior user experience possibile per il cliente.
Le ragioni della nascita del DevOps
Il concetto di DevOps non è certamente nato oggi, ma già nel lontano 2009 quando per rispondere a esigenze specifiche su tutto il processo di sviluppo, i team di DEv. e Operation hanno avanzato l’ipotesi di una cooperazione più stretta, proprio per superare alcune en passe riguardo: riduzione drastica dei tempi del testing delle applicazioni; centinaia di rilasci nella stessa giornata; eliminazione dell’errore umano, etc.. Tuttavia è proprio oggi che le ragioni del business, sempre più orientato all’innovazione e a un time to market veloce, stabiliscono i ritmi in grado di accelerare approcci, processi e operatività in termini di evoluzione del metodo dando un impulso significativo a nuove sinergie di coworking.
Come ogni nuovo approccio culturale si richiede ai team coinvolti un lavoro di squadra che storicamente ha sempre ceduto il passo a metodi e metodologie di lavoro dei singoli team rendendo le due aree di competenza ben distinte e separate, scelta che oggi può dimostrare molte problematiche intrinseche al risultato e al prodotto finito e che un approccio condiviso in tutte le fasi dello sviluppo (sviluppo, testing, distribuzione e produzione) tenta invece di risolvere.
Se da una parte il trend è decisamente a favore verso un incremento di attenzione alle nuove sfide in ambito sviluppo, dall’altra certamente la messa in pratica dell’operatività è più faticosa e non per mancanza di supporto tecnologico o di realtà tra vendor e partner Ict che hanno investito competenze specifiche in questa direzione, ma ancora una volta le motivazioni risiedono in un ostacolo culturale difficile da elaborare e superare.
Come funziona il modello DevOps
Il motore trainante del modello DevOps è l’automazione dei processi di software development e delivery organizzati attraverso una pipeline CI/CD. Obiettivo principale: creare ambienti in cui il ciclo di build, test e release delle applicazioni di software business sia il più rapido possibile, con frequente rilascio di nuove versioni, sempre più sicure e affidabili. Questo processo dinamico di continuous integration (CI) coinvolge principalmente la fase di creazione e di rilascio del software. Il CI fa uso di strumenti (di automazione) che consentono agli sviluppatori di andare costantemente a verificare la buona qualità di tutta la loro base codice, man mano che questa evolve. ll passo successivo allo sviluppo di una nuova versione di un’applicazione è la sua distribuzione deploy continuous delivery (CD) cioè quella parte dell’automatismo in regime DevOps che esula dallo sviluppo software e si rivolge alla messa in produzione della soluzione.
La CD utilizza tutta una serie di strumenti che consentono di lavorare in ciclo iterativo, in maniera tale da rendere subito il valore sviluppato disponibile per clienti e utilizzatori finali. Questa fase è fondamentale perché potrebbe permettere di realizzare un vantaggio competitivo. Va da sé che un ciclo iterativo automatizzato permette di automatizzare anche tutti i processi delle suite di test e di verifica di compliance (aderenza agli standard di sviluppo). Tutto ciò migliora l’affidabilità complessiva del prodotto software e del ciclo di sviluppo. L’automazione verifica infatti l’aderenza ad alcuni standard di qualità, e nel caso in cui questa non ci fosse, le barriere di qualità rifiutano il passaggio in delivery di alcune parti. Questa fase di automatic testing e può essere applicata in diversi momenti del ciclo DevOps perché verifica in modo costante gli aggiornamenti al software, ma altri test vengono realizzati per verificare modifiche all’infrastruttura e garantire un’elevata affidabilità e produttività.
La logica delle architetture DevOps
Nel DevOps, logiche più tradizionali e monolitiche cedono il passo a nuovi criteri architetturali come i container, microservizi e orchestratori, così mentre l’architettura monolitica tenta di raggruppare tutto in un singolo programma, i microservice sono responsabili di un solo compito e operano indipendentemente l’uno dall’altro. In logica DevOps ogni microservizio funziona come entità separata con il vantaggio che il cambiamento di ciascun microservizio non abbia impatto sugli altri, il che garantisce una maggiore flessibilità dal momento che è più facile distribuire con regolarità nuove versioni dei microservizi.
I microservice containerizzati sono poi gestiti da orchestratori di container in grado di automatizzare la distribuzione, la gestione, il ridimensionamento, il networking e la disponibilità delle applicazioni.
I vantaggi sono molteplici: dal deployment semplificato, un container è una sorta di “pacchetto” che include al proprio interno l’applicazione e tutto quel che serve per eseguirla, quindi sarà facilmente distribuibile all’interno di diversi ambienti operativi senza ulteriori sforzi di configurazione, ai tempi di avvio più rapidi dal momento che viene virtualizzato il solo sistema operativo, inoltre consente l’ottimizzazione dei carichi di lavoro e la duttilità delle prestazioni del sistema, che potrà adattarsi in modo estremamente flessibile alle esigenze dell’azienda.
Da quanto descritto è evidente che ragionare in termini DevOps convince sempre più sviluppatori e aziende a condividere un metodo, un’architettura condivisa e quindi un approccio comune, anche solo per ottimizzare i processi o per ragioni di business. Ma il ciclo per essere virtuoso, ha ancora un aspetto fondamentale da considerare ed eventualmente integrare e cioè quello della sicurezza intrinseca delle applicazioni da cui il termine DevSecOPs.
DevSecOps, la sicurezza
Già nel 2012 Gartner definì la sicurezza in un contesto applicativo un “must to have” che mai come oggi, a fronte di nuovi modelli organizzativi aziendali: cloud, mobility, smart working, delocalizzazioni e nuovi canali digitali, è necessario non sottovalutare ma anzi costituisce sempre più un passaggio obbligato.
Nel 2018 sono triplicate le vulnerabilità nelle web app rispetto al 2017: lo rivela il report di Positive Technologies, che trae la sua analisi dai dati delle valutazioni sulla sicurezza delle applicazioni svolte nel corso del 2018, inoltre nel report si dichiara: “La maggior parte delle applicazioni web ha un basso livello di sicurezza, l’83% delle vulnerabilità sono vulnerabilità del codice, anche quelle criticamente pericolose”.
E ancora, il rapporto 2017 OAD (Osservatorio Attacchi Digitali in Italia) evidenzia come principale e più diffusa causa di attacco la vulnerabilità dei software e delle infrastrutture utilizzate dall’applicazione.
Questo suggerisce che durante lo sviluppo non si presta sufficiente attenzione alla sicurezza, inoltre, molte applicazioni non proteggono dall’accesso non autorizzato, il che permette a un aggressore di ottenere privilegi e di agire più liberamente all’interno del sistema.
Secondo l’opinione degli analisti di Forrester, solo con l’incorporazione dei tool di Static application security testing (SAST) e di Dynamic application security testing (DAST) negli strumenti e nei processi di sviluppo (al pari di altri controlli per la qualità del software) si avrà un evidente miglioramento della sicurezza delle applicazioni, ma l’integrazione nel ciclo di rilascio del software è ancora oggi difficile da far comprendere.
A fronte di quanto esposto, le applicazioni aziendali quindi possono rappresentare un facile bersaglio per il cybercrime, finendo in cima all’elenco degli obiettivi per attacchi provenienti dall’esterno compromettendo dati e sistemi con una escalation di problematiche e danni per le aziende e per gli utenti.
È evidente che per prevenire rischi legati alle vulnerabilità dei sistemi e applicazioni sarà necessario integrare la sicurezza come elemento contestuale nell’approccio DevOps tenendo sempre ben presente che l’obiettivo di avere i team che agiscono in cooperation (sviluppo, security, operations) hanno sempre un unico obiettivo e cioè quello di rilasciare un prodotto che riesca a soddisfare la customer experience degli utenti in termini di funzionalità, disponibilità, integrità e sicurezza.
DevOps, la protezione dei dati
Ultimo aspetto, ma non per importanza è la Security by Design che il GDPR integra nei punti programmatici art.25: laddove il business preveda attività di progettazione (ad es. di un applicativo, di un sito e-commerce, etc) o di erogazione di servizi. Dobbiamo mettere in atto sin dalla progettazione, e prima che inizi il trattamento dei dati, tutte le misure tecniche ed organizzative necessarie ad attuare i principi di protezione dei dati (by design). Questo implica che si faccia una seria valutazione dei rischi, opportunamente documentata (ad es. in fase di progettazione di un software o di un applicativo da vendere sul mercato.
Se i processi di sviluppo stanno man mano prendendo sempre più consapevolezza nel pianificare organicamente processi che vedono coinvolti i vari team di sviluppo, cosa diversa succede per la sicurezza native relegata e assimilata, in questo ambito, a un collo di bottiglia e lasciata molto spesso al margine dei processi.
Sarà anche questo un processo di integrazione lento ma inesorabile soprattutto perché ogni passo avanti verso una maturità culturale, implica sempre importanti nuove opportunità verso l’innovazione.
