Security-as-Code: cosa è e come funziona l’approccio dinamico alla cyber security

Gli approcci tradizionali alla sicurezza non sono adatti quando si passa agli ambienti cloud. È un concetto che sentiamo esprimere spesso, in modi diversi ma che portano alla stessa conclusione. Il tema portante qui è l’elasticità del cloud: il fatto che le infrastrutture e le applicazioni possano, nel cloud, attivarsi, disattivarsi e modificarsi in tempo reale è un bene ma anche un rischio. Va tutto troppo veloce per la cyber security tradizionale.

E attenzione, non parliamo di una cyber security che deve difendere il cloud da attacchi mirati. È una cyber security molto più, per così dire, conservativa: le statistiche ci dicono che il più delle volte il cloud è vulnerabile perché qualche componente non funziona come deve. Le falle insomma, quando ci sono, sono create da errori, non dalla particolare bravura di qualche hacker ostile. Che semmai è bravo a sfruttare le occasioni che gli si presentano.

La risposta, secondo molti esperti di cyber security, sta nell’adottare approcci per cui la sicurezza IT va di pari passo con la velocità del cloud. Traendo ispirazione da un altro ambito che ha già vissuto i dolori di crescita della transizione al cloud delle imprese: le operations. La necessità di velocizzare la gestione e la configurazione delle risorse in cloud ha portato al modello IaC, Infrastructure-as-Code. Se facciamo lo stesso per la sicurezza, ecco nascere il modello SaC, Security-as-Code.

Vediamo meglio questo parallelo. Secondo i dettami dello IaC, tutte le operazioni collegate all’infrastruttura in cloud sono governate da policy ben precise che indicano come, con che configurazione e con che limitazioni (le condizioni possono essere molte di più, ovviamente, e di solito lo sono) una determinata risorsa viene attivata. Il “codice” dell’infrastruttura, per fare un esempio, indica che una istanza containerizzata di una certa applicazione va fatta nascere ricavando l’immagine del container da un certo repository, attivandola in un determinato cluster e dandole limiti definiti di visibilità sulle altre risorse.

Il principio chiave dello IaC è in sintesi codificare controlli e limiti di una risorsa in cloud direttamente nel processo che la attiva, senza rimandarli a dopo. Ampliamo l’ambito di questi controlli e limiti andando oltre le configurazioni tecniche in senso stretto e aggiungiamo altri controlli e policy legate direttamente alla cyber security, ed ecco – semplificando – Security-as-Code. La principale differenza tra IaC e SaC sta nel fatto che il primo è concentrato su “come è” una risorsa, il secondo tocca anche il “cosa fa”. Ad esempio che dati gestisce, con che sistemi dialoga, che servizi richiama, che rischi introduce il suo funzionamento.

Security-as-Code: il rischio di una sigla in più

Un rischio che corre l’approccio Security-as-Code è che la sua valenza si perda di fronte all’ennesimo acronimo tecnico legato al cloud. Anche perché la cloud security di “buzzword” me ha già introdotte parecchie e alcune, almeno concettualmente, si sovrappongono al SaC. Come minimo, l’approccio SaC rischia di essere catalogato come l’Infrastructure-as-Code con qualcosa in più. Ma non solo.

Le aziende che hanno anche una parte di sviluppo possono poi vedere Security-as-Code come una forma di quello che probabilmente hanno già: un ciclo DevSecOps. Se l’idea è pensare alla cyber security il prima possibile – il fantomatico “shift left” della sicurezza – allora perché non dovrebbero bastare i controlli già integrati (idealmente) nel flusso sviluppo-integrazione-delivery?

Chi propone l’approccio Security-as-Code deve quindi sottolineare bene che il suo raggio d’azione è più ampio. Non riguarda solo lo sviluppo o solo le misconfiguration ma tutto il comportamento delle ricorse in cloud. Considerato poi nell’ottica non solo di eliminare errori (come DevSecOps) e configurazioni errate (come in buona parte IaC) ma più ampiamente di garantire un comportamento corretto delle risorse stesse. Combinando controlli preventivi, controlli dinamici in tempo reale, azioni di remediation predeterminate.

Inoltre la logica, come man mano sta diventando per tutta la cyber security, è quella non solo della correttezza formale e sostanziale ma anche del risk management. Un’applicazione può magari essere sviluppata perfettamente e configurata al meglio, ma creare un rischio aziendale perché quando gestisce certi dati non lo fa secondo le policy che l’azienda si è data. Curare anche questo aspetto è parte del Security-as-Code.

Security-as-Code: pensare prima di agire

Il vero ostacolo che le aziende interessate al Security-as-Code si trovano davanti è che l’approccio richiede prima di tutto una analisi approfondita, se non proprio una ridiscussione, dei propri ambienti cloud. Non è una soluzione che si applica sull’esistente e che funziona all’istante. Come si usa dire, “out of the box”.

Per implementare un approccio Security-as-Code, spiegano gli esperti, bisogna prima valutare tutte le risorse (infrastruttura, servizi, applicazioni) che si possono attivare in cloud e poi, per ciascuna, rilevare i rischi di sicurezza e compliance che può comportare. Da questa analisi derivano i controlli e le policy che vanno codificati per eliminare o ridurre tali rischi. Un passo – la codifica – che non va sottovalutato. Non basta avere in mente una policy che sembra efficace per la sicurezza, bisogna anche saperla dettagliare esattamente in regole e controlli tali che la policy stessa poi funzioni come ce la siamo immaginata.

Questa codifica poi va fatta, ossia servono piattaforme e soluzioni che permettano di scrivere il “codice della sicurezza” e di metterlo in atto. Dato che Security-as-Code è un approccio nascente, non ci sono ancora soluzioni onnicomprensive che lo realizzino in toto. Al momento è ancora forte la connessione tra DevSecOps e SaC, quindi sono sul mercato diverse soluzioni che coprono la parte del percorso SaC più vicina alle pipeline CI/CD.

L’idea è che nel prossimo futuro Security-as-Code si presenti man mano come una offerta integrata di servizi cloud. E, possibilmente, multicloud o cloud-agnostici. I primi casi ci sono, come ad esempio il servizio Risk and Compliance as Code (RcaC) di Google Cloud. Che da parte sua, forse per non confondere questo servizio con la parte DevSecOps, preferisce parlare di PaC (Policy as Code) più che di Security-as-Code.