Executive summary
Gestire l'infrastruttura informatica attraverso configurazioni scritte e versionate, anziché tramite interventi manuali, è diventato un requisito operativo per le organizzazioni che devono garantire ambienti ripetibili, verificabili e modificabili in modo controllato. Questo articolo analizza i principali strumenti e approcci che consentono di descrivere, registrare e applicare automaticamente la configurazione di server, reti e servizi, esaminando le differenze tra linguaggi progettati appositamente per questo scopo e linguaggi di programmazione di uso generale. Dall'analisi emerge che la scelta dello strumento è meno determinante della maturità delle pratiche operative adottate, in particolare il tracciamento centralizzato dello stato reale dell'infrastruttura, il rilevamento sistematico delle discrepanze tra configurazione attesa e realtà, e l'applicazione di verifiche automatiche di sicurezza e conformità prima di ogni modifica.
Background
Il paradigma Infrastructure as Code (IaC) formalizza la pratica di definire, versionare e applicare la configurazione dell'infrastruttura attraverso artefatti testuali trattati con le medesime discipline del codice applicativo: controllo di versione, revisione tra pari, testing automatizzato e deployment continuo. Morris [1] identifica il principio fondamentale nell'idea che "tutto ciò che serve per costruire, gestire e far evolvere l'infrastruttura è definito come codice e applicato attraverso processi automatizzati", distinguendo esplicitamente questo approccio sia dalla gestione manuale tradizionale sia dall'automazione parziale basata su script ad hoc.
Le radici storiche del paradigma precedono la formalizzazione attuale. Strumenti di configuration management come CFEngine (1993), Puppet (2005) e Chef (2009) hanno introdotto il concetto di stato desiderato per i singoli nodi, ma operavano prevalentemente a livello di configurazione del sistema operativo e dei pacchetti software installati. La svolta concettuale avviene con l'emergere del cloud computing e delle API programmatiche dei provider: quando l'intera infrastruttura, reti virtuali, istanze di calcolo, database gestiti, bilanciatori di carico, diventa provisionabile attraverso chiamate API, la distinzione tra "infrastruttura" e "software" si dissolve, e il codice diventa il mezzo naturale per gestire entrambi. La Twelve-Factor App methodology [2], pubblicata nel 2011 da Wiggins e dal team di Heroku, anticipava questa convergenza con il principio della configurazione esternalizzata nell'ambiente e della parità tra ambienti di sviluppo e produzione, requisiti che gli strumenti IaC moderni hanno reso operativi su scala.
L'adozione industriale ha raggiunto una scala significativa. Secondo l'HashiCorp State of Cloud Strategy Survey 2023, l'86% delle organizzazioni intervistate considera l'IaC importante o molto importante per la propria strategia cloud [3]. Il mercato globale degli strumenti IaC è stato valutato 847 milioni di dollari nel 2023, con una proiezione di crescita a un tasso composto annuo del 24,4% fino al 2030 [4]. Questa crescita riflette una transizione strutturale: l'IaC non è più una pratica di nicchia adottata da team DevOps avanzati, ma un requisito operativo per qualsiasi organizzazione che gestisca infrastruttura cloud su scala.
La domanda centrale che questo articolo affronta è: quali sono i paradigmi, gli strumenti e le pratiche operative che definiscono lo stato dell'arte dell'Infrastructure as Code, quali trade-off comportano le diverse scelte architetturali, in particolare nella gestione dello stato, nel rilevamento della deriva e nel testing, e come si struttura un ecosistema IaC maturo e resiliente?
Paradigmi: dichiarativo e imperativo
La distinzione architetturale fondamentale nell'ecosistema IaC riguarda il modello di specifica della configurazione. Il paradigma dichiarativo descrive lo stato desiderato dell'infrastruttura (what) e delega allo strumento la determinazione delle operazioni necessarie per raggiungerlo (how). Il paradigma imperativo specifica la sequenza di operazioni da eseguire, lasciando al programmatore la responsabilità di gestire la logica di convergenza, l'idempotenza e la gestione degli errori. La distinzione non è puramente accademica: influenza profondamente la testabilità, la prevedibilità e la manutenibilità delle configurazioni IaC su scala [1, 5].
Il modello dichiarativo: HCL e i domain-specific language
Terraform, sviluppato da HashiCorp e rilasciato nel 2014, ha consolidato il paradigma dichiarativo attraverso l'HashiCorp Configuration Language (HCL), un domain-specific language progettato specificamente per la descrizione di risorse infrastrutturali [5]. In HCL, l'operatore dichiara risorse e le loro proprietà; il motore di Terraform costruisce un grafo delle dipendenze, calcola il piano di esecuzione (plan) e applica le modifiche necessarie per convergere dallo stato attuale allo stato desiderato. AWS CloudFormation [6] adotta un modello analogo basato su template JSON o YAML, con il vincolo di operare esclusivamente nell'ecosistema AWS.
Il punto di forza del modello dichiarativo risiede nella prevedibilità: dato uno stato corrente e una configurazione desiderata, il piano di esecuzione è deterministico e ispezionabile prima dell'applicazione. Questa proprietà è particolarmente rilevante in ambienti di produzione, dove la possibilità di esaminare le modifiche prima dell'applicazione (plan review) costituisce un meccanismo di sicurezza critico. Il limite simmetrico è l'espressività: HCL offre costrutti per iterazione (for_each, count) e condizioni, ma la logica complessa, generazione dinamica di configurazioni, integrazione con sistemi esterni, pattern di astrazione avanzati, richiede workaround che rendono il codice fragile e difficile da mantenere [7].
Il modello programmatico: dichiarativo con linguaggi general-purpose
Il termine "imperativo" è frequentemente utilizzato per descrivere l'alternativa al modello DSL-dichiarativo, ma la distinzione è più sfumata. Pulumi [7] rappresenta l'alternativa architetturale più matura al modello DSL: consente di definire l'infrastruttura utilizzando linguaggi di programmazione general-purpose, TypeScript, Python, Go, Java, C#, ma mantiene un motore dichiarativo sottostante che gestisce il grafo delle risorse e la convergenza dello stato. L'operatore utilizza costrutti imperativi del linguaggio (cicli, condizioni, funzioni) per descrivere lo stato desiderato, non per eseguire operazioni infrastrutturali direttamente. Il risultato è un modello ibrido che si potrebbe definire "dichiarativo nella semantica, imperativo nella sintassi". L'operatore scrive codice infrastrutturale con gli stessi strumenti, librerie e pattern di astrazione del codice applicativo: classi, interfacce, funzioni generiche, gestione degli errori tipizzata.
I vantaggi di questo approccio emergono in scenari di complessità elevata. La generazione dinamica di configurazioni (ad esempio, creare un numero variabile di risorse basato su dati esterni), l'integrazione con SDK e API durante la fase di provisioning, e la possibilità di applicare pattern di software engineering consolidati (factory, strategy, dependency injection) alla definizione dell'infrastruttura sono operazioni naturali in un linguaggio general-purpose e artificiose in un DSL [7]. Il bacino di competenze disponibili è inoltre significativamente più ampio: JavaScript conta oltre 17 milioni di sviluppatori, Python 15 milioni, Go 3 milioni, mentre HCL richiede un investimento di apprendimento dedicato.
Il costo di questa flessibilità è una superficie di complessità più ampia. Un linguaggio general-purpose consente di introdurre effetti collaterali, stato mutabile e logica non idempotente nella definizione dell'infrastruttura, errori che un DSL puro previene strutturalmente. La disciplina del team e le pratiche di code review diventano pertanto più critiche quando si adotta un approccio imperativo.
AWS CDK: il modello ibrido
AWS Cloud Development Kit (CDK) [8] propone un modello intermedio: l'operatore definisce l'infrastruttura in un linguaggio general-purpose (TypeScript, Python, Java, C#, Go), ma il CDK sintetizza la configurazione in template CloudFormation che vengono poi applicati dal motore dichiarativo di CloudFormation. L'astrazione avviene attraverso constructs organizzati in tre livelli: L1 (mapping diretto 1:1 con le risorse CloudFormation), L2 (astrazioni con valori predefiniti conformi alle best practice e metodi di supporto) e L3 (pattern architetturali completi che compongono risorse multiple) [8].
Il vantaggio del CDK risiede nella combinazione di espressività del linguaggio general-purpose con la prevedibilità del motore dichiarativo CloudFormation. Il limite è il vincolo all'ecosistema AWS: a differenza di Terraform e Pulumi, CDK non supporta nativamente provider cloud multipli.
Il panorama degli strumenti
La sezione precedente ha analizzato i paradigmi di specifica. Si esamina ora ciascuno strumento nella prospettiva delle caratteristiche operative, dell'ecosistema e dell'evoluzione recente.
Terraform e il modello provider
Terraform ha definito il modello architetturale di riferimento per gli strumenti IaC multi-cloud. Il suo design separa il core engine, responsabile del parsing HCL, della costruzione del grafo delle dipendenze, della gestione dello stato e dell'esecuzione del piano, dai provider, plugin che implementano la comunicazione con le API specifiche di ciascun servizio (AWS, Google Cloud, Azure, Kubernetes, GitHub, Datadog e oltre 4.000 altri) [5]. Questa architettura a plugin consente a Terraform di gestire risorse eterogenee all'interno di una singola configurazione, un vantaggio significativo in ambienti multi-cloud e hybrid-cloud.
Il linguaggio HCL è progettato per bilanciare leggibilità e funzionalità. I module consentono il riuso e l'incapsulamento di configurazioni complesse, mentre i workspace forniscono un meccanismo per gestire ambienti multipli (sviluppo, staging, produzione) dalla stessa codebase. Terraform detiene una quota di mercato stimata intorno al 33% nel segmento degli strumenti di gestione dell'infrastruttura secondo l'HashiCorp State of Cloud Strategy Survey [3], con un ecosistema consolidato di moduli condivisi attraverso il Terraform Registry.
OpenTofu: il fork open-source
Nell'agosto 2023, HashiCorp ha modificato la licenza di Terraform dalla Mozilla Public License 2.0 (MPL) alla Business Source License (BSL), una licenza che limita l'uso commerciale da parte di prodotti concorrenti [9]. La decisione ha catalizzato la creazione di OpenTofu, un fork open-source promosso da un consorzio di aziende (Gruntwork, Spacelift, Harness, env0, Scalr) e successivamente adottato dalla Linux Foundation. Dall'aprile 2025, OpenTofu è parte della Cloud Native Computing Foundation (CNCF) [9].
OpenTofu mantiene la compatibilità con l'HCL di Terraform e con l'ecosistema di provider e moduli esistente, basandosi sull'ultima versione open-source di Terraform (1.6.x) come punto di partenza. Le versioni successive hanno introdotto funzionalità differenzianti: la versione 1.7 ha aggiunto la crittografia nativa dello stato (state encryption) e le funzioni definite dal provider; la versione 1.8 ha esteso queste capacità; la versione 1.11 ha introdotto i valori effimeri (ephemeral values), che consentono a segreti e credenziali di esistere solo in memoria senza essere mai persistiti nel file di stato [9]. Con oltre 10 milioni di download e un ecosistema di 3.900+ provider e 23.600+ moduli, OpenTofu rappresenta un'alternativa concreta per le organizzazioni che richiedono garanzie di licenza open-source senza vincoli commerciali.
La divergenza tra Terraform e OpenTofu pone un problema di governance dell'ecosistema IaC. Le organizzazioni devono valutare non solo le funzionalità tecniche, ma anche la stabilità della licenza, la velocità di evoluzione della community, e il rischio di incompatibilità futura tra i due fork.
AWS CloudFormation: il servizio nativo
CloudFormation [6] occupa una posizione architetturalmente distinta: anziché essere uno strumento esterno che interagisce con le API del provider, è un servizio nativo di AWS che gestisce il ciclo di vita delle risorse direttamente all'interno della piattaforma. I template (JSON o YAML) descrivono stack di risorse, e CloudFormation si occupa della creazione, dell'aggiornamento e della cancellazione in modo coordinato, gestendo automaticamente le dipendenze e il rollback in caso di errore.
Le evoluzioni recenti hanno affrontato limiti storici significativi. Nel 2024, AWS ha introdotto l'optimistic stabilization, riducendo i tempi di creazione degli stack fino al 40%, e la validazione anticipata delle proprietà delle risorse per consentire un fallimento rapido prima dell'inizio del provisioning [10]. Nel 2025, il stack refactoring ha abilitato lo spostamento di risorse tra stack, la suddivisione di stack monolitici in componenti più piccoli, e la rinominazione dei nomi logici delle risorse all'interno di uno stack, operazioni precedentemente impossibili senza ricreare le risorse [10]. L'integrazione con AWS CDK trasforma CloudFormation da strumento di basso livello a piattaforma su cui costruire astrazioni di livello superiore.
Pulumi: l'approccio programmatico
Pulumi [7] si posiziona come alternativa paradigmatica all'approccio DSL. Oltre alla scelta dei linguaggi general-purpose, Pulumi introduce il concetto di Automation API, che consente di integrare le operazioni IaC all'interno di applicazioni software arbitrarie, ad esempio, un portale self-service che provisiona ambienti on-demand, o un sistema di testing che crea e distrugge infrastruttura come parte della test suite. La versione 4.0 ha introdotto l'Incremental State Processing, che riduce i tempi di deployment fino al 60% per infrastrutture di larga scala (1.000+ risorse), affrontando un limite storico degli strumenti IaC nella gestione di grafi di risorse molto ampi [7].
Il testing nativo rappresenta un differenziatore significativo. Pulumi supporta unit test, property test e integration test utilizzando i medesimi framework disponibili per il linguaggio scelto (pytest per Python, Jest per TypeScript, testing per Go), consentendo di verificare la configurazione dell'infrastruttura con la stessa profondità e gli stessi strumenti utilizzati per il codice applicativo [7].
Gestione dello stato
La gestione dello stato (state management) è il problema architetturale più critico e meno visibile dell'ecosistema IaC. Lo stato è la rappresentazione persistente della corrispondenza tra le risorse dichiarate nel codice e le risorse effettivamente esistenti nell'infrastruttura. Senza uno stato affidabile, lo strumento IaC non può determinare quali modifiche applicare, quali risorse creare e quali eliminare [1, 5].
Il file di stato di Terraform
Terraform persiste lo stato in un file JSON (terraform.tfstate) che contiene l'identificativo univoco, gli attributi e i metadati di ogni risorsa gestita [5]. Il file di stato svolge tre funzioni critiche: il mapping tra identificativi logici (definiti nel codice HCL) e identificativi fisici (assegnati dal provider cloud), la cache dei valori degli attributi per ottimizzare le operazioni di plan senza interrogare le API del provider, e il tracciamento delle dipendenze tra risorse per determinare l'ordine corretto di creazione e distruzione.
La gestione locale del file di stato, la configurazione predefinita di Terraform, è inadeguata per qualsiasi scenario collaborativo o di produzione. I problemi principali sono tre. Primo, il file di stato contiene informazioni sensibili in chiaro: password di database, chiavi API, endpoint interni. Secondo, la modifica concorrente da parte di operatori multipli produce corruzione dello stato. Terzo, la perdita del file di stato disconnette completamente lo strumento dalla conoscenza dell'infrastruttura esistente, rendendo impossibile la gestione successiva senza un processo manuale di ricostruzione (state import) [5, 11].
Backend remoti e state locking
La soluzione architetturale standard prevede l'utilizzo di un backend remoto per la persistenza dello stato con meccanismi di locking per la prevenzione dell'accesso concorrente [5, 11]. In ambiente AWS, la configurazione tipica prevede un bucket S3 per la persistenza (con versionamento abilitato per il recupero da modifiche involontarie e crittografia server-side per la protezione dei dati sensibili) e una tabella DynamoDB per il locking distribuito. Quando un'operazione terraform apply viene eseguita, Terraform acquisisce un lock sulla tabella DynamoDB; se il lock è già detenuto da un'altra operazione, la seconda operazione fallisce con un errore esplicito anziché procedere con il rischio di corrompere lo stato [11].
HCP Terraform (il servizio gestito di HashiCorp) e i backend equivalenti di altri provider centralizzano la gestione dello stato aggiungendo funzionalità enterprise: storico delle versioni dello stato con possibilità di rollback, controllo degli accessi granulare, audit log delle modifiche, e integrazione con i flussi di approvazione. OpenTofu estende il modello con la crittografia nativa dello stato, una funzionalità assente in Terraform, che consente di cifrare il file di stato prima della persistenza sul backend, riducendo il rischio di esposizione di dati sensibili anche in caso di compromissione del backend di storage [9].
Strategie di partizionamento dello stato
In infrastrutture di dimensione significativa, la gestione dello stato in un singolo file diventa un collo di bottiglia operativo. Un file di stato che traccia migliaia di risorse produce tempi di plan e apply dell'ordine dei minuti, aumenta il raggio d'impatto di ogni modifica, e crea contesa tra i team che operano su componenti logicamente indipendenti [1, 11].
La pratica consolidata prevede il partizionamento dello stato in unità indipendenti allineate ai confini architetturali dell'infrastruttura. Una strategia comune separa lo stato in livelli: infrastruttura di rete (VPC, subnet, routing), piattaforma (cluster Kubernetes, database gestiti, code di messaggi) e applicazione (deployment, servizi, configurazioni specifiche). Ogni livello mantiene il proprio stato e il proprio ciclo di vita, con dipendenze gestite attraverso data source che leggono gli output dello stato di altri livelli senza creare accoppiamento nella gestione. Questa separazione riduce il raggio d'impatto delle modifiche, consente cicli di approvazione indipendenti per livelli con profili di rischio diversi, e migliora la parallelizzazione del lavoro tra team [1].
Rilevamento della deriva
La configuration drift, la divergenza tra lo stato dichiarato nel codice IaC e lo stato effettivo dell'infrastruttura, è un problema sistemico che mina il principio fondamentale dell'IaC: la configurazione dichiarata nel codice è la fonte di verità (source of truth) dell'infrastruttura [1, 12]. La deriva si manifesta quando modifiche all'infrastruttura avvengono al di fuori del flusso IaC: interventi manuali attraverso la console del provider cloud, script ad hoc eseguiti per risolvere urgenze, modifiche apportate da altri strumenti di automazione, o azioni automatiche del provider stesso (aggiornamenti di sicurezza, migrazione di risorse).
Meccanismi di rilevamento
Il rilevamento della deriva opera confrontando lo stato atteso (registrato nel file di stato) con lo stato attuale (interrogato attraverso le API del provider). Terraform implementa questo meccanismo nel comando terraform plan: il confronto tra stato atteso e stato reale produce un piano di esecuzione che evidenzia le discrepanze. Se non sono state apportate modifiche al codice ma il piano non è vuoto, le differenze sono attribuibili a drift [5, 12].
CloudFormation offre un meccanismo di drift detection integrato che opera a livello di stack e di singola risorsa, confrontando le proprietà attuali delle risorse con i valori definiti nel template. Nel 2025, AWS ha migliorato la gestione del drift di configurazione come parte delle funzionalità di sicurezza del deployment [10]. Strumenti specializzati come Driftctl (ora parte di Snyk) estendono il concetto identificando risorse cloud che esistono al di fuori della gestione IaC, risorse create manualmente che non sono tracciate da alcun file di stato [12].
Drift detection continuo e automazione
Il rilevamento della deriva come operazione manuale e occasionale è insufficiente: il drift si accumula silenziosamente tra un'esecuzione e l'altra. L'approccio maturo prevede l'esecuzione periodica e automatizzata del rilevamento, integrata nella pipeline CI/CD, con notifiche quando vengono rilevate discrepanze [12]. Una ricerca recente ha proposto l'integrazione di motori di Natural Language Processing con analisi predittiva per il rilevamento proattivo del drift in ambienti multi-cloud, con un'architettura duale composta da un motore NLP che interpreta documenti di policy non strutturati per generare dinamicamente regole Policy-as-Code, e un modello predittivo che analizza la telemetria in tempo reale e i dati storici per anticipare le derive prima che si manifestino [13].
Le implicazioni operative della deriva non gestita sono significative. Uno stato che non riflette la realtà rende il piano di esecuzione inaffidabile: modifiche apparentemente sicure possono produrre effetti imprevisti perché il punto di partenza è diverso da quello registrato. In ambienti regolamentati, la deriva costituisce inoltre una violazione dei requisiti di conformità, poiché l'infrastruttura effettiva non corrisponde alla configurazione approvata e documentata.
Testing dell'infrastruttura
L'applicazione sistematica del testing al codice infrastrutturale è un'area in rapida evoluzione che riflette la maturazione del paradigma IaC. Rahman et al. [14] hanno identificato otto categorie di difetti nei script IaC attraverso l'analisi qualitativa di 1.448 commit relativi a difetti in repository open-source di OpenStack, includendo una categoria specifica dell'IaC, i difetti di idempotenza, che causano provisioning errato quando lo stesso script viene eseguito più volte. Tra i 66 professionisti intervistati, il 79% ha confermato l'esistenza di difetti legati all'idempotenza nella pratica quotidiana.
Analisi statica e policy-as-code
Il livello base del testing IaC è l'analisi statica, che esamina il codice senza eseguirlo. Chiari et al. [15] hanno condotto una survey sistematica delle tecniche di analisi statica per l'IaC, classificando gli strumenti in base alle tecniche utilizzate, alle categorie di difetti rilevate e alle piattaforme supportate. Gli strumenti operativi si distribuiscono su un continuum di profondità.
terraform validate verifica la correttezza sintattica e semantica della configurazione HCL senza accedere allo stato o alle API del provider. TFLint estende questa verifica con regole specifiche per provider che rilevano configurazioni valide sintatticamente ma problematiche operativamente (ad esempio, tipi di istanza deprecati o regioni non disponibili). Checkov [16] e tfsec (ora integrato in Trivy) implementano analisi di sicurezza basate su librerie di policy predefinite che coprono standard come CIS, PCI-DSS e GDPR, verificando proprietà come l'assenza di credenziali hard-coded, la crittografia abilitata su risorse di storage, e la restrizione degli accessi di rete.
Open Policy Agent (OPA) [17] rappresenta il livello più espressivo dell'analisi statica. OPA è un motore di policy general-purpose che valuta regole scritte in Rego, un linguaggio dichiarativo progettato per la definizione di policy complesse su strutture dati arbitrarie. Applicato all'IaC, OPA consente di definire vincoli organizzativi che vanno oltre le verifiche di sicurezza predefinite: limiti di costo (nessuna istanza superiore a un determinato tipo), vincoli di conformità (tutte le risorse devono avere tag specifici), e policy architetturali (le risorse di database devono risiedere in subnet private). Le policy OPA possono essere versionate e testate come codice, realizzando il paradigma Policy-as-Code [17].
Rahman et al. [18] hanno esteso l'analisi ai pattern di sviluppo, identificando anti-pattern ricorrenti nelle attività di sviluppo IaC che correlano con l'introduzione di difetti. L'analisi, condotta su 2.138 script open-source e validata con 51 professionisti, fornisce evidenze empiriche su quali pratiche di sviluppo, indipendentemente dallo strumento specifico, aumentano o riducono il rischio di difetti.
Testing funzionale e di integrazione
Oltre l'analisi statica, il testing funzionale verifica il comportamento dell'infrastruttura provisionata. Terratest [19], una libreria Go sviluppata da Gruntwork, implementa un pattern di test che provisiona l'infrastruttura reale in un ambiente isolato, esegue verifiche sul risultato (connettività di rete, risposta dei servizi, configurazione delle risorse), e distrugge l'infrastruttura al termine del test. Questo approccio fornisce la massima confidenza, l'infrastruttura viene testata nel suo ambiente reale, ma con costi significativi in termini di tempo di esecuzione (minuti o decine di minuti per test), costo delle risorse cloud provisionate, e complessità di gestione della pulizia in caso di fallimento dei test.
Terraform ha introdotto un framework di testing nativo a partire dalla versione 1.6, con file .tftest.hcl che supportano test a livello di plan (verificano il piano di esecuzione senza applicarlo) e test a livello di apply (provisionano e verificano le risorse in un ambiente effimero). Questo approccio riduce la dipendenza da strumenti esterni ma non elimina la necessità di test di integrazione che verifichino il comportamento end-to-end dell'infrastruttura.
La piramide del testing IaC, per analogia con la piramide del testing software, prevede una base ampia di verifiche statiche (rapide, economiche, ad alta copertura), uno strato intermedio di test sul piano di esecuzione (validazione della logica senza provisioning), e un vertice ristretto di test di integrazione su infrastruttura reale (lenti, costosi, ma ad alta confidenza).
graph TB
A["Integration test su infrastruttura reale<br/><i>Terratest, Pulumi integration test</i><br/>Alta confidenza · Costo elevato · Minuti"] --- B
B["Test sul piano di esecuzione<br/><i>terraform plan, .tftest.hcl, Pulumi preview</i><br/>Confidenza media · Costo nullo · Secondi"] --- C
C["Analisi statica e policy-as-code<br/><i>Checkov, tfsec/Trivy, OPA, TFLint</i><br/>Ampia copertura · Costo nullo · Secondi"]
style A fill:#d32f2f,color:#fff,stroke:none
style B fill:#f57c00,color:#fff,stroke:none
style C fill:#388e3c,color:#fff,stroke:none
Figura 1, Piramide del testing IaC: la base ampia rappresenta le verifiche rapide e automatizzabili, il vertice le verifiche ad alta confidenza ma costose.
La maturità di un'organizzazione nell'adozione dell'IaC si misura, tra l'altro, dalla completezza e automazione di questa piramide.
Sicurezza e anti-pattern
La sicurezza nell'IaC presenta una superficie di attacco specifica che richiede attenzione dedicata. Rahman e Williams [20] hanno identificato sette categorie di security smell negli script IaC attraverso l'analisi qualitativa di 1.726 script, implementando successivamente SLIC (Security Linter for Infrastructure as Code scripts) e applicandolo a 15.232 script di 293 repository open-source. L'analisi ha rilevato 21.201 occorrenze di security smell, di cui 1.326 istanze di password hard-coded, un anti-pattern che espone credenziali nel sistema di controllo versione e, nel caso di Terraform, nel file di stato in chiaro.
Categorie di vulnerabilità
Le categorie di security smell identificate da Rahman e Williams [20] includono: password e segreti hard-coded nel codice sorgente, uso di protocolli di comunicazione non cifrati (HTTP anziché HTTPS, connessioni di database senza TLS), assenza di validazione dell'integrità dei dati, configurazioni di rete eccessivamente permissive (security group con accesso 0.0.0.0/0), e mancata applicazione del principio di minimo privilegio nelle policy di accesso. Queste categorie si manifestano trasversalmente negli script IaC indipendentemente dallo strumento specifico, suggerendo che il problema è radicato nelle pratiche di sviluppo piuttosto che nelle caratteristiche degli strumenti.
La crittografia dello stato rappresenta un'area di particolare criticità. Il file di stato di Terraform contiene attributi delle risorse in chiaro, incluse password di database, chiavi API e certificati TLS. La crittografia del backend di storage (ad esempio, SSE-S3 o SSE-KMS per i bucket S3) protegge i dati a riposo, ma non durante il transito o l'accesso da parte di operatori autorizzati. La crittografia nativa dello stato introdotta da OpenTofu [9] affronta questo problema a un livello più fondamentale, cifrando il contenuto del file di stato prima della persistenza, in modo che anche l'accesso diretto al backend di storage non esponga dati sensibili.
Governance e compliance
La complessità della governance IaC cresce con la scala dell'organizzazione. La combinazione di OPA per le policy architetturali [17], Checkov per le verifiche di sicurezza predefinite [16], e la drift detection continua [12] forma un framework di compliance che opera su tre dimensioni: prevenzione (le policy bloccano le configurazioni non conformi prima dell'applicazione), rilevamento (la drift detection identifica le deviazioni post-deployment), e correzione (il riallineamento automatico o assistito dell'infrastruttura allo stato dichiarato). In ambienti regolamentati, questo framework sostituisce l'auditing manuale periodico con una verifica continua e automatizzata, trasformando la compliance da checkpoint a proprietà intrinseca del processo di gestione dell'infrastruttura.
Limiti e problemi aperti
Nonostante la maturità raggiunta dagli strumenti, l'ecosistema IaC presenta limiti strutturali che meritano analisi esplicita.
La complessità della migrazione tra strumenti è un problema concreto. Le configurazioni scritte in HCL non sono portabili verso Pulumi o CloudFormation senza riscrittura sostanziale. Anche la migrazione tra Terraform e OpenTofu, teoricamente trasparente, diventa non banale man mano che i due progetti divergono nelle funzionalità. L'assenza di un formato di specifica IaC indipendente dallo strumento vincola le organizzazioni alla scelta iniziale più di quanto il paradigma "as Code" suggerirebbe.
La scalabilità dello stato rimane problematica. Infrastrutture con decine di migliaia di risorse producono file di stato di centinaia di megabyte, con tempi di refresh che possono raggiungere diversi minuti. Il partizionamento dello stato mitiga il problema ma introduce complessità nella gestione delle dipendenze cross-stato. L'Incremental State Processing di Pulumi [7] rappresenta un approccio promettente, ma il problema non è risolto in modo generale.
Il testing end-to-end dell'IaC è intrinsecamente costoso. A differenza del testing software, dove l'esecuzione dei test è rapida e gratuita, il testing dell'infrastruttura richiede il provisioning di risorse reali con costi monetari e temporali significativi. Approcci di mocking e simulazione esistono ma non garantiscono la stessa confidenza dei test su infrastruttura reale, creando un trade-off irriducibile tra velocità del feedback e affidabilità della verifica.
La gestione del drift in ambienti multi-team presenta sfide organizzative oltre che tecniche. Quando team multipli operano su componenti diversi della stessa infrastruttura, la distinzione tra drift legittimo (modifiche apportate da un altro team attraverso il proprio flusso IaC) e drift illegittimo (modifiche manuali non autorizzate) richiede processi e convenzioni che gli strumenti attuali supportano solo parzialmente.
Infine, la curva di apprendimento organizzativa non deve essere sottovalutata. L'adozione dell'IaC non è un problema puramente tecnologico: richiede un cambiamento nei processi operativi, nelle responsabilità dei team, e nella cultura dell'accesso all'infrastruttura. Le organizzazioni che adottano gli strumenti senza trasformare i processi ottengono benefici marginali e rischiano di introdurre complessità senza raccoglierne il valore.
Riferimenti
[1] K. Morris, Infrastructure as Code: Dynamic Systems for the Cloud Age, 2nd ed., O'Reilly Media, 2021.
[2] A. Wiggins et al., "The Twelve-Factor App," 2011 (open-sourced 2024). https://12factor.net/
[3] HashiCorp, "State of Cloud Strategy Survey 2023," 2023. https://www.hashicorp.com/en/resources/state-of-cloud-strategy-survey-2023
[4] Grand View Research, "Infrastructure as Code Market Size and Share Report, 2030," 2024. https://www.grandviewresearch.com/industry-analysis/infrastructure-as-code-market-report
[5] HashiCorp, "Terraform Documentation: State," 2026. https://developer.hashicorp.com/terraform/language/state
[6] AWS, "AWS CloudFormation Documentation," 2026. https://docs.aws.amazon.com/cloudformation/
[7] Pulumi, "Pulumi Documentation," 2026. https://www.pulumi.com/docs/
[8] AWS, "AWS Cloud Development Kit (CDK) v2 Developer Guide," 2026. https://docs.aws.amazon.com/cdk/v2/guide/home.html
[9] OpenTofu, "OpenTofu Documentation," Linux Foundation / CNCF, 2026. https://opentofu.org/docs/
[10] AWS DevOps Blog, "AWS CloudFormation 2025 Year in Review," 2025. https://aws.amazon.com/blogs/devops/aws-cloudformation-2025-year-in-review/
[11] AWS Prescriptive Guidance, "Terraform on AWS: Backend Best Practices," 2025. https://docs.aws.amazon.com/prescriptive-guidance/latest/terraform-aws-provider-best-practices/backend.html
[12] Snyk, "How to Detect and Prevent Configuration Drift in IaC," 2025. https://snyk.io/articles/infrastructure-as-code-iac/detect-prevent-configuration-drift/
[13] "Predictive Drift Detection and Remediation in Multi-Cloud Infrastructure Using NLP-Driven Compliance Models," 2025. https://www.researchgate.net/publication/400081468
[14] A. Rahman, E. Farhana, C. Parnin, and L. Williams, "Gang of Eight: A Defect Taxonomy for Infrastructure as Code Scripts," in Proc. ICSE, 2020. https://doi.org/10.1145/3377811.3380409
[15] M. Chiari, M. De Pascalis, and M. Pradella, "Static Analysis of Infrastructure as Code: a Survey," in Proc. IEEE ICSA-C, 2022. https://arxiv.org/abs/2206.10344
[16] Bridgecrew / Palo Alto Networks, "Checkov: Policy-as-Code for Infrastructure," 2026. https://www.checkov.io/
[17] Open Policy Agent, "OPA Documentation," CNCF, 2026. https://www.openpolicyagent.org/docs/latest/
[18] A. Rahman, E. Farhana, and L. Williams, "The 'as Code' Activities: Development Anti-patterns for Infrastructure as Code," Empirical Software Engineering, vol. 25, 2020. https://doi.org/10.1007/s10664-020-09841-8
[19] Gruntwork, "Terratest: Automated Tests for Infrastructure Code," GitHub repository, 2026. https://github.com/gruntwork-io/terratest
[20] A. Rahman and L. Williams, "The Seven Sins: Security Smells in Infrastructure as Code Scripts," in Proc. ICSE, 2019. https://doi.org/10.1109/ICSE.2019.00033