Scansione IaC: un'opportunità di apprendimento fantastica e trascurata

Tutto ciò che leggi sull'infrastruttura come codice (IaC) è incentrato su come funziona o sul motivo per cui vuoi assicurarti che stia effettivamente costruendo nel modo in cui desideri che si costruisca.

Queste sono aree critiche. Ma stiamo pensando abbastanza a come utilizziamo questo approccio nella nostra organizzazione?

As Melinda Marchi da ESG afferma in un rapporto aziendale, "l'83% delle organizzazioni ha registrato un aumento delle configurazioni errate dei modelli IaC" mentre continuano ad adottare la tecnologia.

Lo sappiamo dal lavoro svolto dalla Cloud Security Alliance ("Principali minacce al cloud computing: Egregious Eleven“) e altri, le configurazioni errate continuano a essere un rischio maggiore nel cloud.

IaC è supportato per ridurre
configurazioni errate sistematizzando la creazione dell'infrastruttura, aggiungendo un livello di rigore e un processo che assicuri che i team stiano costruendo ciò che vogliono e solo ciò che vogliono. Se circa l'83% delle squadre non lo vede, c'è un problema più profondo in gioco.

Nei team più piccoli, uno in cui le parti Dev e Ops della filosofia DevOps sono insieme, ha senso. IaC consente a questi piccoli team di utilizzare lo stesso linguaggio (codice) per descrivere tutto ciò che stanno facendo.

Questo è il motivo per cui stiamo vedendo astrazioni di livello ancora più elevato rispetto a strumenti come Terraform o AWS CloudFormation nel AWSCDK e progetti come cdk8s. Quelle astrazioni di alto livello sono più comode per gli sviluppatori.

Una prospettiva operativa/SRE/piattaforma di un servizio cloud sarà molto diversa dalla prospettiva di uno sviluppatore dello stesso servizio. Uno sviluppatore esaminerà un servizio di accodamento e si tufferà nella sua interfaccia: un semplice endpoint da aggiungere e uno da leggere? Venduto. Questa è un'integrazione facile.

Questa prospettiva operativa mira a trovare i bordi. Quindi, quando questa coda raggiunge il suo limite? Le prestazioni sono costanti o cambiano radicalmente sotto carico?

Sì, ci sono preoccupazioni sovrapposte. E sì, questa è una visione semplificata. Ma l'idea regge. IaC risolve molti problemi, ma può anche creare e amplificare la disconnessione tra i team. Ancora più importante, può evidenziare il divario tra l'intenzione di ciò che stai cercando di costruire e la realtà di ciò che hai costruito.

Di conseguenza, è qui che spesso aumentano i problemi di sicurezza.

La maggior parte degli strumenti, commerciali o open source, è incentrata sull'identificazione di elementi che non vanno nei modelli di infrastruttura. La sezione
è un buon costrutto. Fabbricazione questo
sarebbe male. Questi strumenti mirano a generare questi risultati come parte della pipeline di integrazione continua/fornitura continua (CI/CD).

È un ottimo inizio. Ma fa eco allo stesso problema linguistico.

Chi parla e chi ascolta?

Quando uno strumento IaC evidenzia un problema, chi lo affronterà? Se è il team di sviluppo, dispone di informazioni sufficienti per sapere perché questo è stato segnalato come problema? Se si tratta del team operativo, le conseguenze del problema sono descritte nel rapporto?

Per gli sviluppatori, ciò che accade spesso è che si limiteranno a regolare la configurazione per far passare il test IaC.

Per le operazioni, in genere si tratta di verificare se i test vengono superati. Se lo sono, passa all'attività successiva. Non è un colpo per nessuna delle due squadre; piuttosto, evidenzia il divario tra aspettative e realtà.

Quello che serve è il contesto. Gli strumenti di sicurezza IaC forniscono visibilità su ciò che sta per (si spera) essere costruito. L'obiettivo è fermare i problemi prima entrano in produzione.

Gli odierni strumenti di sicurezza IaC stanno evidenziando problemi reali che devono essere affrontati. Prendere l'output di questi strumenti e arricchirlo con un contesto aggiuntivo specifico per il team responsabile del codice è un'opportunità perfetta per un'automazione personalizzata.

Ciò contribuirà anche a colmare il divario linguistico. L'output dei tuoi strumenti è essenzialmente in una terza lingua, solo per rendere le cose più complicate, e deve essere comunicato in un modo che abbia senso per un pubblico di sviluppo o operativo. Spesso entrambi.

Ad esempio, quando una scansione segnala che una regola del gruppo di sicurezza non ha una descrizione, perché è importante? Solo ricevere un avviso che dice "Aggiungi una descrizione per il contesto" non aiuta nessuno a costruire meglio.

Questo tipo di flag è una grande opportunità per educare i team che stanno costruendo nel cloud. L'aggiunta di una spiegazione secondo cui le regole del gruppo di sicurezza devono essere il più specifiche possibile riduce la possibilità di attacchi dannosi. Fornire riferimenti ad esempi di regole forti. Chiamalo senza conoscere l'intenzione e gli altri team non possono testare la validità della conferma di sicurezza.

La sicurezza è responsabilità di tutti, quindi riconoscere il divario linguistico tra sviluppatori e operazioni evidenzierà opportunità come questa per aggiungere semplici automazioni che forniscano approfondimenti ai tuoi team. Ciò contribuirà a migliorare ciò che stanno costruendo e, di conseguenza, porterà a migliori risultati di sicurezza.

L'autore

mark-nunnikhoven-headshot_150x125_2_(1).jpg

Sono uno scienziato forense, relatore e analista tecnologico che cerca di aiutarti a dare un senso al mondo digitale e al suo impatto su di noi. Per gli utenti di tutti i giorni, il mio lavoro aiuta a spiegare quali sono le sfide del mondo digitale. Quanto è grande l'impatto che l'utilizzo dei social media ha sulla tua privacy? Cosa significa quando tecnologie come il riconoscimento facciale iniziano a essere utilizzate nelle nostre comunità? Aiuto a rispondere a domande come questa e altre. Per le persone che costruiscono tecnologia, le aiuto ad applicare una lente di sicurezza e privacy al loro lavoro, in modo che possano consentire agli utenti di prendere decisioni più chiare sulle loro informazioni e comportamenti. C'è una montagna di confusione quando si tratta di privacy e sicurezza. Non dovrebbe esserci. Rendo la sicurezza e la privacy più facili da capire.

Timestamp:

Di più da Lettura oscura