Scansione di sicurezza dell'infrastruttura come codice

Gli strumenti di Infrastructure as Code (IaC), come Terraform, AWS CloudFormation, Ansible e Helm, consentono di definire l'infrastruttura in file di configurazione sottoposti a controllo versione. Ciò offre enormi vantaggi — ripetibilità, verificabilità e automazione — ma comporta anche un rischio di sicurezza critico: le configurazioni errate nei file IaC producono infrastrutture non sicure su larga scala. Un singolo modulo Terraform configurato in modo errato e distribuito in 50 ambienti crea simultaneamente 50 sistemi vulnerabili. L'analisi della sicurezza IaC affronta questo problema verificando i file di configurazione prima della loro applicazione e integrando i controlli di sicurezza nelle prime fasi del workflow degli sviluppatori.

Gli strumenti di analisi della sicurezza cercano le configurazioni errate IaC più comuni riscontrate negli ambienti cloud reali: bucket S3 con accesso pubblico abilitato o privi di cifratura dei dati inattivi; gruppi di sicurezza con regole in ingresso 0.0.0.0/0 su porte sensibili (22, 3389, 1433); database privi di cifratura o con accessibilità pubblica; policy IAM con caratteri jolly * per risorse o azioni; CloudTrail disabilitato in una regione; chiavi KMS prive di rotazione; e load balancer con listener HTTP anziché HTTPS. Questi risultati rispecchiano da vicino i controlli eseguiti da benchmark di sicurezza cloud come CIS AWS Foundations.

Checkov (di Bridgecrew/Prisma Cloud) è un noto strumento open source di analisi statica per l’IaC, compatibile con Terraform, CloudFormation, i manifest Kubernetes, i chart Helm e i Dockerfile. Include oltre 1.000 policy predefinite, associate ai benchmark CIS, al GDPR, al SOC 2 e all’HIPAA. L’esecuzione di checkov -d . analizza tutti i file IaC nella directory corrente e genera un report con codifica a colori dei controlli superati, non superati e ignorati, indicando i percorsi delle risorse e le istruzioni per la correzione. Checkov può essere integrato nelle pipeline CI/CD per bloccare i deployment quando i controlli critici non vengono superati.

tfsec (ora parte della funzionalità di scansione IaC di Trivy) è uno scanner di sicurezza specificamente progettato per Terraform, che comprende in profondità la sintassi HCL e può quindi tracciare i valori tra moduli e file di variabili. A differenza degli scanner più semplici, tfsec è in grado di rilevare configurazioni errate quando il problema coinvolge più file, ad esempio una regola di un security group che sembra sicura se considerata isolatamente, ma che è associata a una risorsa definita in un altro file. tfsec genera risultati con livelli di gravità (CRITICAL, HIGH, MEDIUM, LOW), ID CWE e collegamenti diretti alla documentazione per la correzione, rendendo i risultati concretamente utili agli sviluppatori.

Uno dei problemi di sicurezza IaC più critici è rappresentato dai segreti codificati direttamente nei file di configurazione: password, chiavi API, chiavi private TLS e stringhe di connessione ai database salvate in Git. Poiché i repository IaC vengono spesso condivisi tra i team e conservati nella cronologia del controllo versione, un segreto salvato anche una sola volta è di fatto compromesso per sempre (la cronologia Git è immutabile). Strumenti come Checkov, detect-secrets, git-secrets e TruffleHog analizzano i file alla ricerca di pattern di segreti. La soluzione consiste nell’utilizzare variabili di input valorizzate tramite variabili d’ambiente o secret store, senza mai inserire valori direttamente nel codice.

I framework Policy as Code (PaC) consentono ai team di sicurezza di scrivere regole personalizzate sotto forma di codice e di applicarle in modo coerente. Open Policy Agent (OPA) con Conftest permette di scrivere policy Rego per convalidare qualsiasi dato strutturato, inclusi i piani Terraform, i manifest Kubernetes e i valori Helm, nelle pipeline CI/CD. HashiCorp Sentinel è integrato in Terraform Enterprise e Cloud e consente di applicare policy come “tutti i bucket S3 devono avere la crittografia abilitata” al momento della pianificazione, bloccando qualsiasi operazione apply che violi la policy. Questi strumenti permettono di codificare i requisiti di sicurezza e di sottoporli al controllo versione insieme all’infrastruttura che regolano.

Si verifica un configuration drift quando lo stato effettivo dell’infrastruttura distribuita si discosta dalla definizione IaC, spesso perché qualcuno ha apportato manualmente una modifica tramite la console cloud. Una regola di un security group aggiunta manualmente per “sbloccare temporaneamente” il lavoro di uno sviluppatore può trasformarsi in una lacuna permanente. Gli strumenti di rilevamento del drift confrontano continuamente lo stato desiderato (i file IaC) con lo stato effettivamente distribuito e segnalano le deviazioni. AWS Config, il rilevamento del drift di Terraform Cloud e gli strumenti CSPM (Prisma Cloud, Wiz) offrono tutti questa funzionalità. Le configurazioni errate di sicurezza introdotte tramite modifiche nella console vengono così individuate prima che possano scoprirle gli aggressori.

Per infrastruttura immutabile si intende un’infrastruttura in cui server e configurazioni non vengono mai modificati sul posto; le modifiche creano invece nuove risorse (nuove AMI, nuove immagini di container) e sostituiscono quelle precedenti. In combinazione con GitOps (dove tutte le modifiche all’infrastruttura devono passare da una pull request Git, attivando i flussi di scansione e approvazione IaC), questo elimina il configuration drift per costruzione: se qualcosa non può essere modificato manualmente, non può verificarsi alcun drift. Strumenti come ArgoCD per Kubernetes e Atlantis per Terraform implementano flussi di lavoro GitOps in cui ogni deviazione attiva una riconciliazione automatica o un avviso.

La scansione di sicurezza IaC viene talvolta confusa con il SAST (Static Application Security Testing), ma i due strumenti analizzano artefatti diversi. Il SAST analizza il codice sorgente delle applicazioni (Python, Java, JavaScript) alla ricerca di vulnerabilità come SQL injection o buffer overflow. La scansione IaC analizza i file di configurazione dell’infrastruttura alla ricerca di configurazioni errate di sicurezza cloud; non coinvolge alcun codice applicativo. Una pipeline DevSecOps completa include entrambi: SAST sul codice applicativo e scansione IaC sui file dell’infrastruttura. Entrambi vengono eseguiti nella CI/CD prima di qualsiasi deployment. Alcune piattaforme unificate (Snyk IaC, Prisma Cloud) combinano la scansione delle applicazioni e dell’infrastruttura in un unico strumento.

Una scansione di sicurezza IaC efficace deve essere automatizzata e obbligatoria, non facoltativa. Un’integrazione CI/CD tipica prevede: l’esecuzione di Checkov e tfsec a ogni pull request; il fallimento della pipeline se sono presenti risultati CRITICAL; la pubblicazione dei risultati come commenti nella pull request, per renderli visibili agli sviluppatori; il mantenimento di un elenco dei risultati soppressi con motivazioni documentate; e una scansione notturna delle risorse distribuite per rilevare il drift. Gli hook pre-commit che utilizzano strumenti come pre-commit con Checkov possono individuare i problemi prima ancora che il codice raggiunga la pipeline. È importante gestire i falsi positivi: gli sviluppatori che visualizzano troppi risultati irrilevanti iniziano a ignorarli.

Il file di stato di Terraform (terraform.tfstate) contiene l’inventario completo di tutte le risorse gestite e spesso include in chiaro valori di output sensibili, come password di database, chiavi private TLS e ID delle chiavi di accesso IAM. I file di stato non devono mai essere salvati in Git. Utilizzate invece un backend remoto (AWS S3 con locking tramite DynamoDB, Terraform Cloud o lo state gestito da GitLab) con la crittografia lato server abilitata. L’accesso al backend dello stato deve essere rigorosamente controllato tramite IAM: chiunque possa leggere il file di stato può enumerare tutti i dettagli dell’infrastruttura e potenzialmente estrarre i segreti incorporati.

Verificate la vostra comprensione dei concetti di CompTIA Security+ (SY0-701) trattati in questa lezione.

In questa lezione avete imparato che le configurazioni errate dell’IaC, come bucket S3 pubblici, security group aperti e segreti codificati direttamente, vengono rilevate automaticamente da strumenti come Checkov e tfsec prima del deployment; i framework Policy as Code (OPA/Conftest, HashiCorp Sentinel) consentono di applicare i requisiti di sicurezza personalizzati dell’organizzazione come controlli automatici che bloccano la pipeline; e i file di stato Terraform devono essere archiviati in backend remoti crittografati con rigidi controlli di accesso, poiché possono contenere dettagli sensibili sulle risorse. Nella prossima lezione analizzeremo il ciclo di vita degli APT e il modo in cui le minacce avanzate persistono all’interno delle reti.