Sommario

L'acquisizione di HashiCorp da parte di IBM, completata nel febbraio 2025, ha spostato il baricentro del dibattito OpenTofu vs Terraform dal piano puramente tecnico a quello strategico. Nel febbraio 2026, con OpenTofu alla versione 1.12 e una base installata in crescita costante, la domanda concreta per chi gestisce infrastrutture in settori regolamentati non è più "funziona come Terraform?" ma "quali garanzie offre nel lungo periodo su licenza, roadmap e sicurezza dello state?". La risposta, su quest'ultimo punto, è oggi più chiara che mai: la cifratura nativa client-side dello state è un differenziatore reale, non un dettaglio.

Il Problema che Tutti Ignorano: lo State File in Chiaro

Chi lavora con Terraform in produzione da anni sa che il file di state è il punto più critico dell'intera catena IaC. Al suo interno si trovano output di moduli, attributi di risorse, e — inevitabilmente — secret che non si è riusciti a escludere del tutto: endpoint di database, token di servizio, chiavi SSH generate on-the-fly. La raccomandazione ufficiale è sempre stata la stessa: usare backend remoti con cifratura server-side abilitata (S3 con SSE-KMS, Azure Blob con CMK, GCS con CMEK) e bloccare l'accesso tramite IAM.

Questo approccio funziona, ma presenta due limitazioni strutturali. La prima è che la cifratura avviene lato backend, non lato client: il file viaggia in chiaro dal runner CI/CD al backend di storage, ed è leggibile in chiaro da chiunque abbia accesso al bucket con le credenziali corrette. La seconda è che in ambienti multi-team con RBAC granulare su workspaces diversi, garantire che ogni team veda solo il proprio state — e non quello altrui — diventa un esercizio di policy S3 spesso complesso da governare e sottoporre ad audit.

HashiCorp ha lasciato aperto questo issue per anni. OpenTofu lo ha chiuso nella versione 1.7 con la cifratura client-side, e nelle versioni successive l'ha maturata al punto da renderla enterprise-ready.

Come Funziona la State Encryption in OpenTofu

La cifratura è configurata direttamente nel blocco terraform (che in OpenTofu si può rinominare tofu, ma rimane compatibile) e opera prima che il file lasci il processo locale:

terraform {
  backend "s3" {
    bucket = "my-infra-state"
    key    = "prod/network/terraform.tfstate"
    region = "eu-west-1"
  }

  encryption {
    key_provider "aws_kms" "primary" {
      kms_key_id = "arn:aws:kms:eu-west-1:123456789:key/abcd-1234"
      region     = "eu-west-1"
      key_spec   = "AES_256"
    }

    method "aes_gcm" "default" {
      keys = key_provider.aws_kms.primary
    }

    state {
      method = method.aes_gcm.default
    }

    plan {
      method = method.aes_gcm.default
    }
  }
}

Il meccanismo AES-GCM garantisce non solo la confidenzialità ma anche l'integrità: qualsiasi manipolazione del file cifrato produce un errore di autenticazione prima ancora che OpenTofu provi a interpretarne il contenuto. Questo chiude un vettore di attacco documentato — la privilege escalation tramite state tampering — che nel 2023 aveva mostrato come modificare un file state per redirezionare risorse IAM verso account non autorizzati.

I key provider supportati in produzione sono AWS KMS, GCP KMS, Azure Key Vault (tramite provider external, con supporto nativo in roadmap), OpenBao, e PBKDF2 per ambienti air-gapped. La configurazione del fallback permette la migrazione tra key provider senza downtime, il che è rilevante quando si cambia cloud o si ruota la CMK per policy di compliance.

Implicazioni Enterprise tra Terraform e OpenTofu nel 2026

La scelta non è tecnica, è di governance. Sul piano funzionale, OpenTofu 1.12 è compatibile con Terraform fino alla versione 1.6: moduli, provider, sintassi HCL, formato dello state — tutto funziona senza modifiche. Le divergenze iniziano sulle feature aggiunte da ciascun progetto dopo il fork, e su questo OpenTofu ha oggi un vantaggio concreto su specifici requisiti di sicurezza.

Per un'istituzione bancaria, tre fattori pesano concretamente:

Licenza e vendor lock-in. OpenTofu è MPL 2.0, governato dalla Linux Foundation. Terraform è BSL 1.1, ora sotto IBM. Qualsiasi integrazione commerciale — pipeline CI/CD vendute come servizio, moduli distribuiti internamente tra affiliate — va valutata rispetto ai termini BSL, che vietano l'uso competitivo senza accordo commerciale. In una banca con decine di società del gruppo, questo non è un caso limite.

Cifratura dello state come requisito normativo. DORA e le linee guida EBA sull'ICT risk management richiedono che i dati sensibili siano protetti in transito e a riposo. Con la cifratura client-side di OpenTofu integrata nella pipeline GitOps — ArgoCD per Kubernetes, Atlantis o env0 per IaC — è possibile dimostrare in un audit che lo state non è mai transitato o archiviato in chiaro, nemmeno nei log del runner. Con Terraform vanilla e backend S3 standard, questa dimostrazione richiede architetture complementari più complesse.

Roadmap controllabile. OpenTofu ha un processo RFC pubblico. Le feature vengono discusse apertamente su GitHub con partecipazione della community prima dell'implementazione. Per un team che dipende da un tool IaC su migliaia di risorse, la prevedibilità della roadmap vale quanto la feature stessa.

Il trade-off che rimane a favore di Terraform è l'ecosistema di supporto enterprise: HCP Terraform, Sentinel per policy-as-code nel tier commerciale, e l'integrazione con il portafoglio IBM per chi già usa Ansible Automation Platform. Se queste integrazioni sono già in uso, la migrazione a OpenTofu ha un costo organizzativo che va quantificato, non ignorato.

Conclusione

Per un architetto che gestisce infrastruttura in un contesto bancario regolamentato, OpenTofu 1.12 non è più solo il fork open-source di Terraform, ma è uno strumento maturo con una feature di sicurezza concreta che Terraform non ha mai implementato. La cifratura client-side dello state tramite KMS, combinata con una licenza senza ambiguità commerciali e una governance trasparente, lo rende la scelta razionale per nuovi progetti o per team che devono giustificare le proprie dipendenze tecnologiche in termini di rischio vendor. La migrazione da Terraform esistente è reversibile e a basso rischio tecnico; il rischio principale è organizzativo, e va gestito come tale.