0Pricing
Cyber Security Academy · Lezione

Vault e secret store

Centralizzare i secret con strumenti come Vault.

Vault e secret store è una lezione Cyber Security Academy gratuita su CoddyKit. Questa è la lezione 2 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Cyber Security Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Cyber Security Academy include 4 lezioni in totale.

Cosa risolve un secret store

Un secret store (o vault) è un servizio centralizzato e protetto il cui unico compito è archiviare i segreti, controllarne l'accesso e registrarlo nei log. Sostituisce i file e le variabili d'ambiente dispersi che causano la proliferazione.

Un buon gestore dei segreti offre quattro funzionalità fondamentali:

  • Archiviazione centralizzata: un'unica fonte autorevole.
  • Controllo degli accessi: policy granulari su chi e cosa può leggere ogni segreto.
  • Audit logging: un registro di ogni accesso per la risposta agli incidenti.
  • Cifratura: segreti cifrati a riposo e in transito.

Tra gli esempi figurano HashiCorp Vault, AWS Secrets Manager, Azure Key Vault e GCP Secret Manager.

Com'è strutturato HashiCorp Vault

HashiCorp Vault è un gestore open source dei segreti molto diffuso. Organizza le funzionalità in secrets engines collegabili, montati su percorsi.

  • KV engine: archivia segreti statici chiave-valore.
  • Database engine: genera credenziali dinamiche e di breve durata per i database.
  • PKI engine: emette certificati TLS su richiesta.
  • Transit engine: offre la cifratura come servizio senza esporre le chiavi.

È possibile interagire con Vault tramite un'API HTTP o la CLI. Ogni percorso è regolato da policy che stabiliscono chi può eseguire operazioni di lettura o scrittura.

# Enable a KV v2 secrets engine at the 'secret/' path
vault secrets enable -path=secret kv-v2

# Write and read a static secret
vault kv put secret/app/db password='S3cr3t' user='app'
vault kv get secret/app/db

Il modello seal/unseal

Vault protegge i propri dati tramite un meccanismo di seal/unseal. Quando Vault si avvia, è sigillato: sa dove si trovano i dati cifrati, ma non può decifrarli.

La master key che decifra l'archiviazione è a sua volta cifrata con una unseal key. Grazie a Shamir's Secret Sharing, la unseal key viene suddivisa in più shard distribuiti a operatori diversi.

Per ricostruire la chiave e rimuovere il sigillo da Vault è necessario fornire una soglia configurabile, ad esempio 3 shard su 5. Nessuna singola persona può rimuovere il sigillo da sola, proteggendo così il sistema dalla compromissione interna.

# Initialize Vault: 5 key shares, threshold of 3 to unseal
vault operator init -key-shares=5 -key-threshold=3

# Each operator supplies one shard until threshold is met
vault operator unseal <shard-1>
vault operator unseal <shard-2>
vault operator unseal <shard-3>

Autenticazione: chi è Lei?

Prima di leggere un segreto, un client deve autenticarsi per ottenere un token. Vault supporta numerosi auth methods, adattati a identità diverse:

  • AppRole per applicazioni e sistemi CI (role ID + secret ID).
  • Kubernetes utilizza il token dell'account di servizio del pod.
  • AWS/GCP/Azure IAM si affida all'identità della piattaforma cloud.
  • OIDC/LDAP per gli utenti umani tramite SSO.

Il principio fondamentale è che l'identità proviene dalla piattaforma, non da una password a lunga durata. Un pod Kubernetes dimostra la propria identità usando il token del proprio account di servizio: non c'è alcun segreto di bootstrap da esporre.

# App authenticates via AppRole to receive a token
vault write auth/approle/login \
  role_id="db-app-role" \
  secret_id="$WRAPPED_SECRET_ID"
# Response includes client_token used for subsequent reads

Autorizzazione con le policy

L'autenticazione dimostra l'identità; le policy stabiliscono cosa può fare quell'identità. Le policy di Vault sono scritte in HCL e seguono il principio del privilegio minimo: concedono solo i percorsi e le capacità necessarie a un workload.

Questa policy consente a un servizio di leggere esclusivamente il proprio segreto del database e nient'altro:

Le capacità corrispondono ai verbi dell'API: read, create, update, delete e list. Negare per impostazione predefinita, concedere esplicitamente.

# policy: billing-app.hcl
path "secret/data/billing/*" {
  capabilities = ["read"]
}
path "database/creds/billing-readonly" {
  capabilities = ["read"]
}
# everything else is implicitly denied

Secret store cloud-native

Se opera su un singolo cloud, il secret store gestito dal provider elimina il carico operativo: niente seal/unseal e nessun server da aggiornare:

  • AWS Secrets Manager si integra con IAM e supporta Lambda di rotazione integrate.
  • Azure Key Vault archivia segreti, chiavi e certificati con RBAC.
  • GCP Secret Manager offre segreti versionati protetti da associazioni IAM.

L'accesso è regolato dal sistema IAM del cloud, quindi un workload legge un segreto usando il proprio ruolo esistente, senza una password separata. Il compromesso consiste nel vendor lock-in e in un supporto multi-cloud più limitato rispetto a Vault.

# Read a secret from AWS Secrets Manager (workload uses its IAM role)
aws secretsmanager get-secret-value \
  --secret-id prod/billing/db \
  --query SecretString --output text

# GCP equivalent
gcloud secrets versions access latest --secret=billing-db

Crittografia come servizio

A volte non si desidera archiviare affatto un segreto: si vogliono cifrare i dati dell'applicazione senza che l'applicazione possieda mai la chiave di cifratura. Il Transit engine di Vault fa esattamente questo.

L'applicazione invia testo in chiaro a Vault, riceve testo cifrato e non vede mai la chiave. La decifratura funziona allo stesso modo. Questo si chiama cifratura come servizio.

Il vantaggio è che le chiavi risiedono solo all'interno di Vault, possono essere ruotate centralmente e un'applicazione compromessa non può esporre una chiave che non ha mai posseduto.

# Encrypt data without the app ever seeing the key
vault write transit/encrypt/orders-key \
  plaintext=$(echo -n 'card=4111...' | base64)
# returns: ciphertext=vault:v1:abc123...

# Decrypt later
vault write transit/decrypt/orders-key ciphertext='vault:v1:abc123...'

Iniettare i segreti nei workload

Un vault è utile solo se le applicazioni possono consumare i segreti senza hardcodificare il percorso o il token. Modelli comuni di iniezione:

  • Sidecar/agent: un Vault Agent viene eseguito insieme all'applicazione, si autentica e scrive i segreti in un volume condiviso in memoria.
  • CSI driver: Kubernetes monta i segreti come file tramite il Secrets Store CSI driver.
  • SDK fetch: l'applicazione chiama direttamente l'API del vault all'avvio.

Preferisca il montaggio in un filesystem in memoria (tmpfs) alle variabili d'ambiente ed eviti di scrivere i segreti su disco, dove potrebbero rimanere persistenti.

# Vault Agent template renders a secret to an in-memory file
template {
  contents = "DB_PASS={{ with secret \"secret/app/db\" }}{{ .Data.data.password }}{{ end }}"
  destination = "/run/secrets/db.env"
}

Registrazione degli audit e responsabilità

Ogni evento di lettura, scrittura e autenticazione in un vault deve essere registrato in un registro di audit. È questo che rende difendibile la gestione dei segreti durante un incidente.

I registri di audit rispondono alle domande fondamentali: chi ha avuto accesso a quale segreto, quando e da dove. Vault applica l'hashing ai valori sensibili nei log, in modo che il registro stesso non divulghi i segreti.

Invii i registri di audit a un sistema separato e a prova di manomissione (SIEM), così un attaccante che compromette l'host del vault non può anche cancellare le prove di ciò a cui ha avuto accesso.

# Enable a file audit device (HMAC-hashes secret values)
vault audit enable file file_path=/var/log/vault/audit.log

# Forward to a SIEM/syslog endpoint for tamper resistance
vault audit enable syslog tag="vault" facility="AUTH"

Proteggere il vault

Un archivio centralizzato concentra il rischio: se il vault cade, cade tutto. Lo renda il suo asset più critico e lo protegga con il massimo rigore:

  • Esegua il servizio con TLS su tutti gli endpoint; non esponga mai l'API senza cifratura.
  • Mantenga il vault su una rete privata, protetta da rigide regole firewall.
  • Abiliti auto-unseal tramite un KMS cloud per evitare la gestione manuale degli shard, ma protegga attentamente quella chiave KMS.
  • Utilizzi TTL brevi per i token e lease rinnovabili, in modo che i token rubati scadano rapidamente.
  • Applichi tempestivamente le patch e monitori i registri di audit per rilevare anomalie.

Il vault sostituisce molti punti di guasto con un unico punto estremamente ben difeso.

Scegliere l'archivio giusto

Non esiste uno strumento migliore in assoluto: scelga l'archivio in base al proprio ambiente:

  • Un singolo cloud, esigenze semplici: utilizzi il gestore nativo (AWS/Azure/GCP) per ridurre al minimo l'overhead operativo.
  • Multi-cloud o on-prem: HashiCorp Vault offre un'astrazione coerente e portabile.
  • Necessità di segreti dinamici o di cifratura come servizio: i motori di Vault sono i più completi.
  • Uso intensivo di Kubernetes: combini un archivio con il driver CSI o con un operator come External Secrets.

Qualunque sia la sua scelta, l'obiettivo è lo stesso: un'unica fonte autorevole, sottoposta ad audit e con accesso controllato, al posto dei segreti in chiaro sparsi.

Verifica rapida

Verifichi la sua comprensione del modello di protezione di Vault.

Riepilogo: vault e archivi di segreti

Ha imparato a sostituire i segreti sparsi con un archivio centralizzato e sottoposto ad audit.

  • Un archivio di segreti offre archiviazione centralizzata, controllo degli accessi, registrazione degli audit e cifratura.
  • HashiCorp Vault utilizza motori dei segreti collegabili e un modello seal/unseal protetto dallo Shamir's Secret Sharing.
  • I metodi di autenticazione ricavano l'identità dalla piattaforma (Kubernetes, IAM, AppRole), mentre le policy applicano il principio del privilegio minimo.
  • Gli archivi cloud-native (AWS, Azure, GCP) rinunciano alla portabilità in cambio di un overhead operativo ridotto.
  • Il motore Transit offre la cifratura come servizio, così le app non devono mai conservare le chiavi.
  • Inietti i segreti nella memoria tramite agent o CSI, registri ogni accesso e protegga il vault come il suo asset più critico.

Nella prossima lezione renderemo i segreti ancora più sicuri generandoli dinamicamente e facendoli durare poco.

Domande Frequenti

La lezione «Vault e secret store» è gratuita?

Sì — il testo completo di «Vault e secret store» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Cyber Security Academy, passa a CoddyKit PRO. Il corso Cyber Security Academy include 4 lezioni in totale.

Cosa imparerò in «Vault e secret store»?

Centralizzare i secret con strumenti come Vault. Eserciti Cyber Security Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Cyber Security Academy?

Non è richiesta alcuna esperienza precedente. Cyber Security Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 2 di 4.

Quanto tempo richiede la lezione «Vault e secret store»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Cyber Security Academy?

Sì. Ogni lezione Cyber Security Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Il problema della proliferazione dei secret
  2. Vault e secret store
  3. Secret dinamici e leasing
  4. Rotazione e rilevamento delle chiavi
← Torna a Cyber Security Academy