IaC scanning: la sicurezza dell'infrastructure as code

L'IaC scanning è l'analisi statica dei file che descrivono l'infrastruttura cloud (Terraform, CloudFormation, Bicep e ARM, manifest Kubernetes, chart Helm), fatta prima del deploy per trovare errori di configurazione, permessi troppo ampi e segreti in chiaro quando sono ancora righe di codice. Da sola non basta: servono anche un file di stato custodito bene, il controllo delle modifiche fatte a mano e la verifica dell'ambiente in esercizio.

Infrastructure as code: cosa cambia per la sicurezza

Con l'infrastructure as code (IaC) reti, macchine virtuali, bucket, database e permessi non si creano più a mano dalla console: si descrivono in file di testo, versionati come il codice applicativo, che uno strumento traduce in chiamate alle API del provider. Microsoft, nella documentazione DevOps, la descrive come un modello versionato che genera lo stesso ambiente a ogni deploy, nato per risolvere la deriva tra un ambiente e l'altro. HashiCorp presenta Terraform come uno strumento IaC che crea e gestisce risorse cloud e on-premise attraverso le loro API.

Per chi si occupa di sicurezza l'IaC ha due facce.

• Riduce gli errori. Nella scheda Enforce Secure Automated Deployment Practices through Infrastructure as Code (marzo 2024), la NSA osserva che il deploy manuale delle risorse cloud è lento e soggetto a errori umani che portano a configurazioni sbagliate. Con l'IaC le risorse sono definite in un posto solo, passano dalla pipeline CI/CD e, con un sistema di versionamento, lasciano un registro verificabile di ogni modifica ai template.
• Moltiplica gli errori che sfuggono. Un modulo con una regola firewall aperta o un bucket senza cifratura si ripete in ogni ambiente e in ogni account che lo usa. E i template diventano un bersaglio: la stessa NSA avverte che anche gli strumenti a cui si dà accesso ai file dei template possono essere presi di mira, da chi vuole conoscere l'infrastruttura o alterarli.

Nel Cloud Threat Horizons Report H1 2026 di Google, l'errore di configurazione come vettore di accesso iniziale negli incidenti osservati su Google Cloud è sceso dal 29,4% del primo semestre 2025 al 21% del secondo. Google legge il calo come un segno che i guardrail automatici rendono più difficile sfruttare gli errori di identità e di configurazione. L'infrastructure as code è il posto dove molti di quei guardrail si scrivono.

Cosa cerca un IaC scanner

Lo scanner legge i template senza eseguire niente e li confronta con regole scritte anch'esse come codice (policy as code). La NSA elenca le classi di problemi che le regole predefinite di questi strumenti intercettano: accessi troppo permissivi, regole firewall aperte, protocolli non sicuri, segreti in chiaro. Esempi tipici su un repository Terraform o CloudFormation:

• Rete: regole che accettano SSH, RDP o le porte dei database da qualsiasi indirizzo, risorse con un IP pubblico che non dovrebbero averlo.
• Storage e database: bucket pubblici, cifratura a riposo disattivata.
• Identità: policy IAM con azioni o risorse jolly, ruoli amministrativi dati a workload che non ne hanno bisogno.
• Log: log di audit o di accesso non attivati sulle risorse nuove.
• Segreti: password, chiavi e token scritti nei file. Checkov, per esempio, cerca credenziali AWS nei dati di avvio delle istanze EC2, nelle variabili d'ambiente delle Lambda e nella configurazione dei provider Terraform.
• Container: Dockerfile e manifest Kubernetes. Trivy, per esempio, segnala un'immagine di base senza un tag preciso.

Gli strumenti open source

Checkov, mantenuto da Prisma Cloud, legge tra gli altri Terraform e i piani Terraform, OpenTofu, CloudFormation, Kubernetes, Helm, Bicep e ARM, con oltre mille policy predefinite per AWS, Azure e Google Cloud. Trivy, di Aqua Security, ha raccolto l'eredità di tfsec: il repository di tfsec invita a passare a Trivy, che usa lo stesso motore di scansione Terraform. KICS, di Checkmarx, è un altro progetto open source dedicato all'IaC. Più del nome contano tre domande: quali formati usate davvero, se le regole si possono scrivere su misura, se i risultati arrivano dove lavorano gli sviluppatori.

Gli strumenti dei provider

• Google Cloud. La validazione IaC di Security Command Center, nei tier Premium ed Enterprise attivati a livello di organizzazione, confronta i piani Terraform con le policy di organizzazione e i detector di Security Health Analytics già in vigore, e si integra in Cloud Build, Jenkins o GitHub Actions.
• AWS. CloudFormation Guard è uno strumento open source di policy as code che valida dati JSON o YAML contro regole dichiarative; per bloccare un'operazione lato server AWS rimanda ai CloudFormation Hooks.
• Microsoft. Defender for Cloud, attraverso Microsoft Security DevOps, esegue la scansione IaC sui repository GitHub e sui progetti Azure DevOps collegati.

Terraform security: i rischi che stanno fuori dai template

Su Terraform alcuni rischi non stanno nei file .tf, e un'analisi statica dei template non li trova.

Il file di stato contiene i segreti

HashiCorp lo scrive nella documentazione sui dati sensibili: i file di stato e di piano contengono gli attributi delle risorse, che possono includere valori sensibili come le password iniziali dei database o i token API. In locale lo stato è un file in chiaro, con dentro i segreti definiti nella configurazione. L'argomento sensitive nasconde il valore nell'output a video, ma lo lascia nello stato e nel piano: chi può leggere quei file legge i valori. Quindi:

• lo stato non va nel repository: HashiCorp chiede di escluderlo dai flussi Git;
• va in un backend remoto, con cifratura a riposo (che dipende dal backend scelto) e accessi limitati a chi esegue il deploy;
• dalla versione 1.10 Terraform offre i valori ephemeral e dalla 1.11 gli argomenti write-only: sono disponibili durante l'esecuzione, ma non vengono scritti né nello stato né nel piano.

Come togliere chiavi e password dal codice, Terraform compreso, lo spieghiamo nella guida al secrets management.

Provider e moduli sono codice di terzi

Ogni progetto Terraform scarica provider e moduli. Il file .terraform.lock.hcl registra le versioni scelte e i checksum dei provider, e Terraform si ferma con un errore se un pacchetto non corrisponde: va messo sotto versionamento e le sue modifiche vanno riviste come il resto del codice. HashiCorp precisa però che oggi il lock file traccia solo i provider. Per i moduli remoti Terraform sceglie sempre la versione più recente compatibile con i vincoli dichiarati: se si vuole sempre la stessa, serve un vincolo di versione esatto.

Le credenziali della pipeline

Chi esegue terraform apply ha di solito permessi ampi sull'intero account. Se quelle credenziali sono chiavi statiche salvate tra i segreti del CI, sono tra le più preziose dell'azienda. GitHub, nella documentazione su OpenID Connect, descrive l'alternativa: si stabilisce una relazione di fiducia con il provider cloud e il workflow chiede a ogni esecuzione un token di accesso di breve durata, senza copiare credenziali di lunga durata tra i segreti di GitHub.

Le modifiche fatte a mano

Una regola firewall aperta dalla console durante un'urgenza non compare in nessun template. HashiCorp spiega che terraform plan confronta per default lo stato con l'infrastruttura reale, e che terraform plan -refresh-only mostra le modifiche avvenute fuori dal flusso Terraform senza sovrascrivere lo stato. La NSA chiede di evitare le modifiche manuali alle risorse create via IaC, facendo passare ogni cambiamento dal template, e ricorda che il rilevamento della deriva si può far girare a mano o a intervalli regolari.

Dove mettere i controlli: dal commit al cloud

1. Nella pull request. La scansione commenta la modifica e la revisione di un'altra persona fa il resto. La NSA suggerisce di separare chi propone le modifiche ai template da chi le approva, in modo che nessuno possa fare entrambe le cose da solo.
2. Sul piano, prima dell'apply. Scansionare il piano Terraform, e non solo i file sorgente, permette di valutare variabili e moduli già risolti: è il formato che usa la validazione IaC di Google Cloud ed è tra quelli che legge Checkov. Se un controllo critico fallisce, il deploy si ferma: la NSA indica la policy as code come un modo per verificare le risorse prima del deploy e farlo fallire quando un componente non è configurato bene.
3. Sul repository stesso. L'accesso in scrittura ai template va trattato come un accesso amministrativo al cloud. Per la NSA, chi non può modificare una risorsa a mano non deve poterne modificare nemmeno il template, e l'accesso va protetto con MFA o con il controllo a due persone.
4. A livello di organizzazione. Le service control policy di AWS Organizations, le policy di organizzazione di Google Cloud e Azure Policy fissano limiti che valgono anche per chi passa dalla console, e fermano ciò che sfugge alla pipeline.
5. Nell'ambiente in esercizio. Log e monitoraggio continuo sulle risorse create via IaC, per accorgersi delle modifiche non autorizzate, come raccomanda la NSA, e un controllo continuo della postura del cloud.

Il limite dell'analisi statica: tanti risultati, poco contesto

Il template dice come è configurata una risorsa, non se è raggiungibile da internet, quali dati contiene o quale identità la usa. Per questo uno scanner acceso su un repository esistente produce spesso un elenco lungo, e decidere da dove partire richiede il contesto del cloud reale. Restano poi fuori le risorse create senza IaC: la NSA nota che il deploy manuale rende difficile tenerne traccia e alimenta lo shadow IT, cioè risorse che nessuno monitora.

Qui l'IaC scanning si collega alla CNAPP, che guarda insieme codice e ambiente in esercizio e riporta un problema trovato nel cloud alla riga di codice che l'ha generato. Wiz, di cui AmagisTech è partner, lavora in questo modo: Wiz Cloud si collega agli account cloud via API, senza agenti; Wiz Code analizza i template IaC (Terraform, CloudFormation, Kubernetes), cerca i segreti, riporta i rischi del cloud alla loro origine nel codice e propone le correzioni nell'IDE, nelle pull request e nelle pipeline (Wiz, How to Evaluate Wiz: Common FAQs). I problemi che si trovano più spesso nel cloud, con o senza IaC, li abbiamo raccolti negli errori di configurazione cloud.

E la compliance?

Il D.Lgs. 138/2024, che recepisce la NIS2 in Italia, all'art. 24, comma 2, lettera e) mette tra gli elementi minimi delle misure di gestione del rischio la sicurezza dell'acquisizione, dello sviluppo e della manutenzione dei sistemi informativi e di rete. Nella ISO/IEC 27001:2022 i controlli dell'Annex A più vicini sono l'8.9 (Configuration management), l'8.25 (Secure development life cycle), l'8.32 (Change management) e l'8.4 (Access to source code). Con l'IaC buona parte dell'evidenza esiste già: la storia del repository dice chi ha cambiato cosa, quando e chi l'ha approvato.

In sintesi

L'infrastructure as code porta la configurazione del cloud nel codice, e con lei gli errori. L'IaC scanning li ferma prima del deploy, ma va completato: stato di Terraform cifrato e con accessi stretti, versioni di provider e moduli fissate, credenziali della pipeline a breve durata, niente modifiche a mano e controllo della deriva, guardrail a livello di organizzazione. Per sapere quanto il cloud in esercizio corrisponde ai template, e quali problemi contano davvero, puoi partire da una fotografia del cloud con Wiz.