Introduzione alla security con GitHub

di Matteo Tumiati, in ,

In un mondo sempre più orientato ai microservizi, le complessità non aumentano solo in relazione alla capacità di sviluppo, ma sono influenzate anche da tanti fattori diversi fra loro. Tra questi, troviamo ad esempio l'architettura stessa, poiché all'aumentare del numero di servizi crescono i problemi relativi alla manutenzione e il numero di persone coinvolte, la tipologia di strategia di deployment/rilascio in produzione e, ultima ma non per importanza, la sicurezza.

Infatti, negli ultimi anni le enterprise si stanno spostando verso un mondo che basato su GitOps che, per l'appunto, va ad eliminare l'esigenza delle pipeline di continuous deployment. Ma se eliminiamo le pipeline di deployment, come possiamo assicurarci che sia tutto rilasciabile e sicuro? La domanda è molto complessa e cerchiamo di snocciolarne qualche punto nel corso di questo articolo, affrontando qualche tema chiave.

In base alla fase in cui siamo dello sviluppo delle nostre applicazioni, dobbiamo prendere delle accortezze sulla security diverse. Questo, se ci pensiamo, è normale: ci sono infatti molte analisi, come ad esempio un penetration test, che possono essere fatte solo quando il sistema è già preparato – ovvero l'infrastruttura è creata e disponibile, il software è già stato rilasciato – mentre ce ne sono altri che non necessitano nemmeno dei binari delle applicazioni, così come nel caso della static code analysis.

Indipendentemente da tutte le strategie evidenziate, quello che deve essere chiaro è che bisogna fare una analisi il prima possibile ed identificare eventuali problemi di sicurezza il prima possibile. Di fatti, se posizioniamo la stessa immagine in un grafico in cui mettiamo in chiaro gli assi del tempo e dei costi, ci troviamo davanti ad una situazione simile.

Questo significa semplicemente che prima siamo in grado di identificare potenziali problemi di sicurezza, meno tempo ci metteremo nel risolverli e meno impatto avranno sui clienti e sui costi di risoluzione.

Facendo un esempio pratico: assumiamo di avere un problema con una porta aperta sull'infrastruttura che qualcuno potrebbe sfruttare per avere accesso alla nostra infrastruttura.

Se ce ne accorgiamo in fase di design in un meeting di threat modelling, o perché stiamo analizzando dei documenti sulle best-practice di come costruire un'architettura, la risoluzione sarà abbastanza semplice ed immediata, poiché, di fatto, ci sarà sufficiente mettere come requisito della feature da sviluppare che la porta deve essere bloccata. Non avremo alcun impatto su chi utilizzerà i nostri servizi e non saremo mai esposti in nessun environment a questo problema.

Al contrario, se ci accorgiamo che la porta è aperta nell'infrastruttura in produzione poiché stiamo facendo maintenance o, peggio, perché siamo già stati attaccati da qualcuno che vuole compiere azioni malevole, gli scenari che si aprono sono diversi. Nella migliore delle ipotesi, è necessario ripartire da zero con l'assessment, verificare se è possibile chiudere la porta in questione, procedere al development effettivo e poi seguire tutto il processo fino alla risoluzione nell'environment di produzione. Nello scenario peggiore, invece, potremmo essere effettivamente stati bucati. Oltre ad eseguire tutti gli step dell'altro scenario, è necessario fare assessment per capire a quali dati qualcuno ha avuto accesso, se ha causato danni all'infrastruttura questi devono essere riparati e così via. Questo comporta sicuramente una grossa perdita di tempo in più, ma ha anche delle conseguenze in termini di costo – banalmente le persone che mantengono le infrastrutture devono essere pagate – e degli impatti sui clienti finali, che non sono valutabili a prescindere, ma che possono includere di nuovo costi (legati anche a potenziali cause legali sulle perdite di dati) e indisponibilità del servizio (di nuovo, vedi costi).

Proprio per questi motivi viene coniato il termine DevSecOps, che mette la security al centro di tutto quello che è il mondo DevOps. Oltre ad effettuare analisi manuali, diventa via via più importante includere dei security check e dei security gate all'interno dei nostri workflow automatici (Azure DevOps, GitHub o altro). Se un problema viene identificato, è fondamentale che le pipeline si blocchino e ci avvisino di conseguenza. A valle anche di quanto detto prima con un esempio pratico, è molto meglio avere falsi positivi che vengono analizzati da un team di esperti, piuttosto che reali problemi in produzione. Inoltre, è vero che le pipeline impiegheranno più tempo ad essere eseguite rispetto al normale caso senza i check di security, ma è altrettanto vero che ne potremmo pagare le conseguenze successivamente e la velocità del development è sicuramente inferiore, e quindi non giustificabile, a quelle di un sistema completamente automatizzato che porta il codice in un ambiente di produzione sicuro.

Poiché non abbiamo modo di vedere con un solo articolo il dettaglio di tutti i check di sicurezza che possiamo implementare, cerchiamo di focalizzarci su quattro pillar che si trovano a livelli differenti. Nelle prossime pagine analizzeremo per primo come rendere sicura l'infrastruttura, fino ad arrivare ad installare al suo interno dei microservizi.

5 pagine in totale: 1 2 3 4 5
Contenuti dell'articolo

Commenti

Visualizza/aggiungi commenti

| Condividi su: Twitter, Facebook, LinkedIn

Per inserire un commento, devi avere un account.

Fai il login e torna a questa pagina, oppure registrati alla nostra community.

Approfondimenti