HashiCorp Vault 1.0: secrets management per l'era cloud

DataGovern

Piattaforma di compliance integrata GDPR + NIS2 + EU AI Act. Cross-Regulation Gap analysis, dashboard board-ready, on-premise.

Scopri DataGovern →

Cyber Security

Consulenza CISO-as-a-service: postura, roadmap di remediation, supporto continuativo.

Scopri →

Il problema dei segreti

Applicazioni moderne devono accedere a decine di risorse protette — database, API esterne, servizi cloud, chiavi crittografiche. Ogni credenziale è un segreto. Storicamente questi segreti sono stati gestiti male: hardcoded nel codice, committati accidentalmente su Git, distribuiti via email, memorizzati in file di configurazione non cifrati. Le fughe di credenziali sono una categoria ricorrente di data breach.

HashiCorp Vault — annunciato nel 2015 e portato alla versione 1.0 il 4 dicembre 2018 — offre una risposta strutturale: un segreto central store con API, cifratura, controllo accessi, audit trail, e — caratteristica distintiva — dynamic secrets generati on-demand. Licenza MPL 2.0 (fino al 2023, quando HashiCorp passerà a BSL).

Secrets Engine e dynamic secrets

Vault non è solo un “key-value store cifrato”. Il concetto chiave sono i Secrets Engine:

• Key-Value (KV) — secrets statici versionati
• Database — genera credenziali temporanee per PostgreSQL, MySQL, MongoDB, MSSQL, Oracle. Il client chiede mysql-readonly, Vault crea un utente MySQL con password random e TTL definito (es. 1 ora). Scaduto, Vault lo elimina
• AWS / GCP / Azure — genera credenziali cloud temporanee
• PKI — Vault agisce come CA interna, emettendo certificati short-lived
• SSH — certificati SSH per host o utenti
• Transit — encryption-as-a-service: l’applicazione invia dati a Vault per cifratura/decifratura, senza mai accedere alla chiave
• TOTP — generazione e verifica di codici OTP

Le dynamic secrets cambiano il modello: invece di una password DB permanente che rischia di trapelare, ogni applicazione riceve credenziali uniche a vita breve. Una compromissione ha impatto limitato.

Auth Methods

Vault separa autenticazione da autorizzazione. Le auth methods supportate:

• Token — il metodo interno di Vault
• AppRole — per applicazioni (role ID + secret ID)
• AWS/GCP/Azure — IAM-based auth per workload cloud
• Kubernetes — ServiceAccount JWT come credenziale
• LDAP/AD, OIDC, GitHub, Userpass
• TLS Certificates, Okta

Dopo l’auth, policy HCL definiscono cosa il chiamante può fare. Le policy sono fine-grained fino al singolo path/operation.

Architettura

Vault è un singolo binario Go. Memorizza lo stato su uno storage backend (Consul, etcd, S3, PostgreSQL, file, Raft integrato dalla 1.4). Tutti i dati sono cifrati con una master key, sigillata a runtime — il processo vault unseal richiede quorum di unseal keys distribuite ai custodi.

Alta affidabilità via Vault HA — più istanze in cluster, con un leader attivo.

Integrazione ecosistema

Al 2018-2019 Vault è integrato profondamente con:

• Kubernetes — vault-k8s injector per iniettare secrets come env var o file in pod
• Terraform — provider che gestisce Vault come IaC
• CI/CD — integrazione con Jenkins, GitLab, GitHub Actions
• Prometheus — metrics endpoint

Modello open core

Il Vault Open Source (MPL 2.0) è gratuito. Vault Enterprise aggiunge: namespace (multi-tenant), performance replication, disaster recovery, Entropy Augmentation (FIPS), EncryptionSpaces (DR-specific), hardware security module support.

Nel contesto italiano

Al 2018-2019 l’adozione italiana di Vault è rapida in aziende con infrastruttura cloud-first:

• Fintech e banche digitali — secrets management per microservizi
• PA innovative — alcuni progetti regionali di cloud privato
• Telco — gestione certificati PKI interni
• ISP e MSP — come componente di offerta managed security

Riferimenti: HashiCorp Vault 1.0 (4 dicembre 2018). Licenza MPL 2.0. Secrets Engines (KV, Database, PKI, Transit, AWS/GCP/Azure). Auth Methods (Token, AppRole, Kubernetes, OIDC). Integrazione con Consul, Terraform, Kubernetes.