Sicurezza Segreti — Cheat Sheet

Tag: security, secrets-management, vault, environment-variables, encryption, git-hooks

Livello: intermedio

TL;DR: Gestione sicura di credenziali, token API e certificati lungo l'intero ciclo di vita del software: prevenzione leak nel codice sorgente, secret rotation, storage cifrato e accesso runtime centralizzato.

Concetti chiave

I segreti non devono mai essere tracciati o memorizzati all'interno di repository Git, né in chiaro né mascherati.

Utilizzo obbligatorio di variabili d'ambiente (.env) escluse tramite .gitignore nei template di progetto.

Adozione di Secrets Manager centralizzati (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) per la produzione.

Separazione netta tra configurazione dell'applicazione (statica o per ambiente) e segreti crittografici.

Prevenzione attiva lato client tramite pre-commit hook con tool di rilevamento pattern (gitleaks, trufflehog).

Principio del minimo privilegio (PoLP): limitare l'accesso ai segreti ai soli servizi e ruoli strettamente necessari.

Rotazione programmata e automatizzata dei token API, password di database e coppie di chiavi asimmetriche.

Mascheramento sistematico dei valori sensibili nei log applicativi, nelle pipeline CI/CD e negli stack trace.

Differenziazione dei secret store tra ambienti di development, staging e production per confinare eventuali compromissioni.

Domande tipiche e risposte pronte

Q: Come gestisci il commit accidentale di un token o di una chiave API in Git?R: Considero il token immediatamente compromesso e procedo alla revoca e rotazione immediata, poi pulisco la cronologia Git (es. con git filter-repo) per evitare residui nella commit history.

Q: Qual è la differenza tra file .env e un Secrets Manager in cloud?R: I file .env sono utili solo per il setup locale dello sviluppatore; in produzione mi affido a secret store centralizzati che gestiscono audit trail, crittografia a riposo e rotazione automatica.

Q: Come inietti i segreti nei container Docker senza lasciarne traccia nell'immagine?R: Uso variabili iniettate esclusivamente a runtime tramite orchestratore (Docker Compose secrets o Kubernetes Secrets) ed evito direttive ENV o ARG con credenziali nei Dockerfile.

Insidie e errori comuni

Tracciare file .env o template contenenti credenziali di staging o test all'interno della repo.

Pubblicare segreti all'interno di build artifact, bundle client-side (es. bundle React/Vite) o layer Docker permanenti.

Confidare nel fatto che rimuovere un file con un nuovo commit cancelli il segreto dalla cronologia Git.

Condividere la stessa chiave crittografica o token di servizio tra l'ambiente di sviluppo e la produzione.

Stampare l'intero payload delle richieste o oggetti process.env nei log di debug o monitoraggio errori.

Snippet e comandi

# Esempio di hook pre-commit per bloccare segreti prima del commit
npx gitleaks protect --staged -v

Bash

# Verifica rapida della cronologia per identificare credenziali accidentalmente committate
npx gitleaks detect --source . -v

TypeScript

// Iniezione sicura a runtime con validazione obbligatoria all'avvio del server
function getRequiredSecret(name: string): string {
  const value = process.env[name];
  if (!value) {
    throw new Error(`Variabile d'ambiente critica mancante: ${name}`);
  }
  return value;
}

export const dbPassword = getRequiredSecret('DATABASE_PASSWORD');

Da ripassare

[ ] Configurazione di Vault o Secrets Manager con ruoli IAM specifici

[ ] Implementazione di policy di rotazione automatica con lambda o webhook

[x] Configurazione base di .gitignore e file di esempio .env.example

[x] Scansione dei repository tramite scanner CLI pre-push

Jarvis Interviews
Jarvis