Le 4 fasi per automatizzare la gestione del cloud

Il percorso di automazione del cloud di un professionista della sicurezza

Se mi incontrate a una conferenza, è probabile che mi sentiate dire che «la sicurezza del cloud inizia con l'architettura e finisce con l'automazione». Subito dopo aggiungo quanto sia importante adottare una mentalità cloud native, anche quando si è impantanati nella realtà di un pesante lift and shift prima che scada il contratto del data center e si spengano le luci. Per quanto sia una battuta efficace, non dice nulla su come io sia passato dall'essere un professionista della sicurezza tutto sostanza (firewall e gestione delle patch) a un cloud native dedito ad architettura e automazione. Anziché predicare dall'alto, trovo più utile descrivere il mio percorso personale e le consapevolezze tecniche maturate lungo la strada. Se siete professionisti della sicurezza, o se state cercando di aggiornare le competenze cloud di un professionista della sicurezza, è probabile che finirete per percorrere una strada molto simile.

Fase 1: automatizzare le configurazioni

Per me tutto è iniziato circa nove anni fa, quando mi è stato chiesto di creare il primo programma di formazione per la Cloud Security Alliance. Fin dall'inizio ho capito che servivano laboratori ripetibili, eseguibili ovunque nel mondo, con studenti e istruttori dalle competenze più diverse, dallo «sviluppatore» all'«auditor pusher di scartoffie». A quei tempi Amazon Web Services non aveva ancora rilasciato IAM e le VPC erano esclusivamente reti private. E concetti come l'Infrastructure as Code stavano appena diventando praticabili.

Ed eccomi lì, a cercare di capire come costruire nel cloud un laboratorio pratico con uno stack applicativo per migliaia di studenti. In modo coerente, *e* con la possibilità di aggiornarlo man mano che AWS faceva evolvere la propria tecnologia. All'epoca creare le proprie AMI era ancora un lavoro ingrato, ma poi ho scoperto le meraviglie di `cloud-init`. Un semplice script che potevo ospitare in un bucket S3, con due piccole righe che gli studenti potevano incollare nel campo User Data delle loro istanze, che configurava le istanze esattamente come serviva all'avvio. E quando gli aggiornamenti software rompevano qualcosa, mi bastava aggiornare quello script all'URL pubblicato e ogni nuova istanza avrebbe usato la nuova configurazione: magia! Pur non risolvendo il patching di ciò che era già in esecuzione, questo mi permetteva di garantire una buona esperienza al primo avvio, molto più facilmente che aggiornando e pubblicando nuove AMI. E, in un atto di totale incoscienza reputazionale, potete ancora vederne qui su S3 una versione successiva.

Il mio primo passo è stato `cloud-init`. Non è qualcosa che uso ancora, ma è stata una rivelazione poter scriptare un intero server e farlo funzionare, con un copia e incolla e un singolo file ospitato.

Fase 2: automatizzare i flussi di lavoro

Ma il passo successivo ha avuto un impatto molto maggiore. Dopo un paio d'anni di corsi pratici e di sviluppo di carichi di lavoro miei, ho iniziato a giocare con l'idea della Software Defined Security. Davanti a me c'era una cornucopia di API cloud, tutte che mi sussurravano all'orecchio «chiamami». Ho iniziato a cercare esempi e non ho trovato… nulla. Persino Security Monkey non era ancora stato rilasciato pubblicamente.

Avevo in programma un corso per la conferenza di sicurezza Black Hat e ho deciso di usarlo come scusa per imparare Ruby e le API di AWS (tramite l'SDK Ruby). Ho finito per scrivere tre dimostrazioni:

• Un'applicazione di incident response che metteva in quarantena un'istanza, ne analizzava tutti i metadati, la bloccava usando AWS IAM, creava un'immagine di tutto lo storage e avviava un server di analisi forense pronto ad analizzare gli snapshot collegati. Faceva in 3 secondi ciò che prima mi richiedeva 30 minuti.
• Una piccola app che si collegava ad AWS e a Chef e individuava tutte le istanze che non eseguivano Chef (server «non gestiti»). Un processo che in un datacenter tradizionale poteva richiedere settimane.
• Un'altra app che apriva i security group a uno scanner Qualys, avviava una scansione e chiudeva il security group al termine.

Non avevo mai programmato in Ruby, quindi per tutte e tre ci sono voluti circa due mesi di lavoro part-time per renderle operative. Erano piuttosto semplici, ma ho imparato alcune lezioni preziose.

• La gestione delle credenziali era fondamentale e rendeva anche più difficile condividere il codice e far sì che gli altri configurassero correttamente i propri ambienti. Attingere da file di configurazione era… fastidioso. Soprattutto per aspetti come quale security group in quale regione usare come gruppo di quarantena.
• Ruby sul mio sistema locale funzionava bene, ma poi sforavo i limiti di servizio e dovevo inserire dei timer di ritardo quando eseguivo il codice in un'istanza su AWS. I limiti di servizio delle API non sono vostri amici.
• Erano tutte soluzioni davvero statiche. Per quanto fossero efficaci come demo, si riduceva comunque all'esecuzione manuale di codice da un desktop o da un'istanza. Non ha retto bene alla prova del tempo.

Le ho raccolte in un pacchetto chiamato «SecuritySquirrel» e potete trovare le versioni del 2014 su GitHub. Che ci crediate o no, quelle non sono nemmeno le originali che ho usato per un paio d'anni prima di pubblicarle.

Fase 3: automatizzare il cloud stesso

Quando AWS ha rilasciato le Rules per CloudWatch, il sabato mattina successivo ho messo insieme in circa 2 ore abbastanza codice Python da annullare qualsiasi modifica ai security group entro 10-15 secondi, inclusi filtri per definire l'ambito della difesa in base ai tag, alla VPC o a chi aveva richiesto la modifica. Potete scaricare il codice e le istruzioni e, a differenza del mio codice Ruby, funziona ancora piuttosto bene per essere codice cloud di 3 anni fa.

Da quella prima dimostrazione ho costruito una libreria di automazioni event-driven eseguite in Lambda, alcune delle quali potete scaricare. In quel pacchetto la mia preferita è `identify_internet_facing_servers.py`, che, a scopo dimostrativo, ho collegato in modo che si attivi quando premo una versione IoT di un pulsante Amazon Dash. Proprio così: mi porto in tasca un vero pulsante Easy fisico. Individua tutte le istanze con la porta 22 aperta su Internet e, con un doppio clic del pulsante, posso revocare le regole, ricevendo un messaggio di testo sul telefono quando tutto è al sicuro.

La lezione principale qui è stata inattesa. Non è che queste automazioni event-driven abbiano sostituito i miei flussi di lavoro basati su host: è che servivano a uno scopo diverso. Ho capito di essere passato dal costruire flussi di lavoro per fare le cose più rapidamente al costruire guardrail per mantenere le cose sicure in background. Entrambi hanno un valore straordinario.

Fase 4: automatizzare tutto

Il mio lavoro più recente ha riguardato l'uso di Jenkins e dell'Infrastructure as Code (principalmente CloudFormation) per rafforzare la sicurezza. Questa combinazione mi permette di automatizzare la sicurezza all'interno dell'infrastruttura e delle applicazioni stesse e di dipendere meno da strumenti esterni.

Per esempio, ho rilasciato un semplice scanner di credenziali da eseguire in Jenkins per individuare eventuali chiavi di accesso memorizzate prima ancora di avviare la build. Perché aspettare e provare a scovarle dopo? Ho poi scritto altri test harness che mi consentono di eseguire praticamente qualsiasi strumento di valutazione in Jenkins e di far fallire le build quando non superano un test di sicurezza, come una scansione di rete (consiglio da professionista: Jenkins fa fallire una build se da uno script gli inviate un exit code diverso da 0).

Tornando al punto di partenza, oggi teniamo il corso di formazione usando template CloudFormation per costruire tutti gli elementi dello stack applicativo, così gli studenti possono concentrarsi sull'aggiunta della sicurezza. Siamo passati dalla creazione di server di formazione coerenti a quella di ambienti di formazione coerenti, con AMI personalizzate che possiamo aggiornare in pochi minuti… a livello globale… con pochissimo sforzo, e con tutto il software preinstallato e pronto per la configurazione finale.

Il mio percorso nel cloud è iniziato circa nove anni fa e quello nell'automazione quasi nello stesso momento. Ho iniziato costruendo cose e poi cercando di automatizzarne delle parti, ma oggi parto dal presupposto dell'automazione. I miei primi lavori riguardavano le operation, mentre oggi sono quasi tutti incentrati sulla sicurezza. Sull'eliminare il sovraccarico operativo e permettere alla parte della mia mente dedicata alla sicurezza di concentrarsi su ciò in cui riesce meglio. Lungo la strada ho anche imparato che non tutte le automazioni sono uguali: ci sono ambiti per i guardrail, per i flussi di lavoro, per l'orchestrazione cross-platform, per l'infrastructure as code e per l'automazione delle pipeline. Tutto questo offre oggi benefici di sicurezza quasi inimmaginabili, ma siamo ancora agli inizi, in un'epoca in cui si può perdere una settimana solo per fare reverse engineering di un'API mal documentata.

Se lavorate nella sicurezza, è ora di mettervi alla prova con il codice. Se siete sviluppatori o vi occupate di operation, è ora di mettervi alla prova con la sicurezza. Perché la lezione più importante di tutte è che i giorni della sicurezza come ombrello sono finiti e sono arrivati quelli della sicurezza integrata nel tessuto.