Gestione dei segreti

Gestione dei segreti

1) Perché e cosa crediamo che sia un segreto?

Il segreto è tutto il materiale che porta alla compromissione del sistema o dei dati: password, API-token, OAUTH/JWT private keys, chiavi SSH, certificati, chiavi di crittografia (KEK/DEK), chiavi di firma webhook, DSN database/cache, chiavi fornitori (pagamenti, provider di posta )/SMS), cookie-sale/pepper, token bot/chat, licenze.
I segreti vivono in codice, configura, ambiente, immagini di container, CI/CD, Terraform/Ansible, Logi/Dump - compito di gestione dei segreti: la registrazione, la spedizione, l'uso della rotazione , la revoca del controllo dello smaltimento.

2) Principi di architettura

Centralizzazione. Un livello attendibile (Vault/Cloud Secret Manager/KMS) da memorizzare, rilasciare e controllare.
Privilegi minimi (PoLP). Accesso solo ai servizi/ruoli necessari, per un periodo minimo.
Una vita breve. Preferiscono i segreti dinamici/temporali con TTL/lease.
Crypto-agility. Possibilità di cambiare algoritmi/lunghezze delle chiavi senza interruzione.
Separare i segreti dal codice/immagine. Nessuna password nei repository o nelle immagini Docker.
Osservazione e verifica. Ogni operazione di rilascio/lettura di segreti viene logificata e alimentata.
Rotazione automatica. Rotazione è un processo in pipeline, non un'azione manuale.

3) Soluzioni e ruoli tipici dei componenti

KMS/HSM. Credibilità radice, crittografia/avvolgimenti chiavi (invelope).
Secret Manager/Vault. Archivio delle versioni dei segreti, ACL, controllo, segreti dinamici (DB, cloud-IAM, PKI), modelli di rotazione.
PKI/CA. Rilascia certificati mTLS/SSH/JWT di breve durata.
Agente/sidecar. Consegna di segreti nel Rantaim (file tmpfs, in-memory k/v, hot-reload).
Driver CSI/operatori. Integrazione con Kubernets (Secret Store CSI Driver, cert-manager).
Livello di crittografia in Git. SOPS/age, git-crypt (per il codice dell'infrastruttura).

4) Classificazione e criterio

• TTL/lease e rotazione
• metodo di rilascio (altoparlante vs statico), formato, supporto;
• criteri di accesso (chi/dove/perché), requisiti di mTLS e di autenticazione reciproca;
• controllo (che logifichiamo, quanti conserviamo, chi revuota);
• procedure break-glass e recensione.

5) Ciclo di vita del segreto

1. Creazione: tramite API Secret Manager con metadati (owner, tags, scope).
2. Memorizzazione: crittografata (avvelope: DEK avvolto da KMS/HSM).
3. Consegna: su richiesta di un soggetto autorizzato (OIDC/JWT, SPIFFE/SVID, mTLS).
4. Uso: esclusivamente in memoria/tmpfs; divieto di loging/dampo.
5. Rotazione per TTL o evento (compromissione); Supporto delle versioni parallele (N-1).
6. Recensione/blocco: disattivazione immediata della lease, l'account/chiave diesel nel sistema di destinazione.
7. Smaltimento: distruzione di versioni/materiale, nitida catena di controllo.

6) Segreti dinamici (consigliato per impostazione predefinita)

• Credenziali di database (Postgres/MySQL) con TTL 15-60 min.
• Chiavi temporanee cloud (AWS/GCP/Azure) per il ruolo del servizio.
• certificati SSH (durata 5-30 min), certificati X.509 (ora/giorno).
• JWT temporaneo per la firma di richieste, sessione-tickets broker.
• Pro: blast radius minimo, recensione semplificata (niente «rimarrà» nel mondo).

7) Consegna di segreti nel RENT

• Secret Store CSI Driver consente di montare i segreti da un gestore esterno a pod come file (tmpfs).
• Evitare Kubernets Secret come unica fonte (base64) di crittografia; se necessario: abilita il provider KMS per etcd.
• Agente Sidecar con lease auto e hot-reload.
• VM/Bare-metal: agente di sistema + Vault/Secret Manager, cache in memoria, TCB minimo.
• Serverless: l'integrazione del cloud con la sostituzione trasparente dei segreti come variabili ambiente/file, ma evitare invvars a lunga vita - preferibilmente file/memoria.

Esempio (Kubernets + CSI, concettuale)

yaml apiVersion: v1 kind: Pod metadata: { name: app }
spec:
serviceAccountName: app-sa # is associated with a role in Secret Manager volumes:
- name: secrets csi:
driver: secrets-store. csi. k8s. io readOnly: true volumeAttributes:
secretProviderClass: app-spc containers:
- name: app volumeMounts:
- mountPath: /run/secrets name: secrets readOnly: true

8) Integrazioni CI/CD e IaC

CI - I worker ricevono token a breve durata secondo OIDC (Workload Identity). Vietare i segreti «mascherati» che entrano nei fogli; passo «scansione delle fuoriuscite» (trofflehog/gitleaks).
Il deposito raccoglie i segreti al momento della registrazione, non li registra nei manufatti.
IaC: Terraform memorizza le variabili in Secret Manager. lo stato (state) è cifrato e limitato in base all'accesso.
SOPS/age - Per i repo, conservare i manifesti criptati, le chiavi sono gestite da KMS.

Esempio (sezioni SOPS)

yaml apiVersion: v1 kind: Secret metadata: { name: app }
data:
PASSWORD: ENC[AES256_GCM,data:...,sops:...]
sops:
kms:
- arn: arn:aws:kms:...
encrypted_regex: '^(data    stringData)$'
version: '3. 8. 0'

9) Criteri di accesso e autenticazione dei carichi di lavoro

Workload identity: SPIFFE/SPIRE, Kubernetes SA→OIDC→IAM-роль, mTLS.
Token temporanei: TTL brevi, scope stretto.
ABAC/RBAC in Secret Manager: «Chi può leggere il segreto X in Y è separato da chi può creare/rotare».
Multiforme: namespace/key-rings per affittuario; regole e rapporti separati.

10) Rotazione, versione e compatibilità

Condividi l'ID del segreto e la sua versione ('secret/app/db # v17').
Supporto di due versioni attive (N e N-1) per la rotazione senza interruzione.
La rotazione è un evento: licenziamento, compromissione, cambio di provider, migrazione di algoritmi.
Automatizzare: cron/backend di rotazione in Vault/Secret Manager + trigger Web di riavvio delle applicazioni/renning.

Mini-ricetta rotazione webhook a due righe

text
T0: we publish two secrets in the provider: current, next
T1: the application starts accepting signatures by both current and next
T2: external system switches signature to next
T3: we do next -> current, re-release new next

11) Archiviazione fuori Rate: backup e manufatti

Non entrare mai nei manufatti (immagini, archivi, dampi).
Backap Secret Manager - Crittografia, chiavi di memorizzazione fuori dallo stesso tracciato.
Etichette e scansioni DLP: rilevamento dei segreti in S3/Blob/GCS, Git, manufatti CI.

12) Osservazione, verifica e SLO

Metriche: numero di erogazioni/segreto/servizio, percentuale di lease scadute, TTL media, tempo di rotazione, tempo di convergenza (secondi/minuti prima di «accettare» la nuova versione).
Logi di controllo: chi/cosa/quando/da dove/perché; archiviazione separata, anche crittografata.
SLO: 99% delle erogazioni <200 ms; 0 fuoriuscite nei cassetti 100% dei segreti hanno owner/TTL/tag; Il 100% dei segreti critici è dinamico o rotativo da 30 giorni.
Alert: il segreto scade <7 giorni (per gli statici), l'aumento dei guasti di autenticazione al magazzino, nessuna lettura del segreto> N giorni (morto), sorgenti geo/ASN inaspettate.

13) Errori frequenti e come evitarli

I segreti sono in Git/immagini. Utilizzare SOPS/age e scanner; il criterio vieta le righe nude.
Avvvars come supporto a lungo termine. Preferire i file tmpfs/in-memory; pulire l'ambiente in caso di fork/dampo.
Gli stessi segreti per il dave/stage/prod. Dividetevi per ambienti.
Password statiche a lunga vita. Passare a dinamiche/a breve durata.
Un'unica chiave guidata per tutto. Dividere per affittuari/progetti/servizi.
Nessun hot-reload. L'applicazione richiede una finestra restart di vulnerabilità durante la rotazione.

14) Esempi di integrazioni (schematico)

Vault accesso dinamico a Postges

hcl
Vault: role -> issues the user to the database with TTL 30m and privileges only to the app path "database/creds/app-role" {
capabilities = ["read"]
}
Application requests/database/creds/app-role -> receives (user, pass, ttl)

Firma JWT delle richieste (breve scadenza)

La chiave privata è memorizzata in Secret Manager; il servizio richiede un signing-token di breve durata e un agente locale firma un payload (la chiave non viene trasferita all'applicazione come stringa).

certificati SSH per gli ammiragli

Rilascio SSH-cert per 10 minuti SSO (OIDC), senza distribuzione di chiavi permanenti.

15) Sicurezza ai bordi

Loghi/trailer/metriche: igienizzatori, filtri per chiavi/pattern conosciuti; campi «riservati» - maschera in APM.
Dump/crash-report - Disattivare per impostazione predefinita; Se necessario, crittografare e pulire.
Applicazioni client/mobile: minimizza i segreti off-line, utilizza i TPM (Keychain/Keystore), il collegamento al dispositivo, il pinning TLS con display di emergenza.

16) Complaens

PCI DSS: divieto di memorizzare i segreti PAN/senza crittografia Controllo rigoroso di accesso e rotazione.
ISO 27001/SOC2: requisiti di gestione degli asset, registrazione, controllo degli accessi, modifica delle configurazioni.
Controlli GDPR/locali: minimizzazione, accesso, controllo.

17) Processi e runbook

Messa in funzione

1. Inventario dei segreti (repository, CI, immagini, runtime, backap).
2. Classificazione e tag (owner, environment, tenant, rotation-policy).
3. Selezione dello storage (Vault/Cloud SM) + integrazione con KMS/HSM.
4. Impostazione del rilascio per workload identity (OIDC/SPIRE).
5. Abilitazione di segreti dinamici per database/cloud/PKI.
6. Rotazione automatica e hot-reload; Gli alert dell'espatrio.
7. Configurazione degli scanner di perdita e di Data Catalog/DS.

Script di emergenza

Sospetto di perdita: foglio di accesso fermo, rotazione immediata, revoca certificati/chiavi, reimpostazione di token, controllo avanzato, RCA.
Non disponibile Secret Manager: cache locale in memoria con TTL ridotto, degrado delle funzioni, limitazione delle nuove connessioni, break-glass manuali.
Compromettere la chiave principale: rigenerazione key-hierarchy, rewrap di tutti i DEK, verifica di tutte le visualizzazioni per la finestra di rischio.

18) Assegno fogli

Prima di vendere

• I segreti sono stati rimossi dal codice/immagine; Gli scanner di perdita sono attivati.
• Per i segreti critici sono inclusi meccanismi dinamici.
• Spedizione tramite sidecar/CSI/tmpfs con hot-reload, senza evvars duraturi.
• Criteri IAM/ABAC configurati, mappati a workload identity.
• Rotazione automatica e versione doppia (N, N-1) per la compatibilità.
• Metriche/alert/verifiche abilitate; test di degrado superati.

Utilizzo

• Rapporto mensile: proprietari, TTL, segreti scaduti, inutilizzati.
• Rotazioni periodiche e pentestri delle vie di fuga (fogli, dampi, manufatti).
• crypto-agility e sostituzione di emergenza A/radici.

19) FAQ

C: Secret Manager è sufficiente senza KMS?
Oh: Per il livello base sì, ma è meglio usare la crittografia envelope: KEK in KMS/HSM, i segreti sono avvolti. Semplifica la recensione e la compilazione.

C: Cosa scegliere, uno statico o un altoparlante?
L'altoparlante predefinito. Lasciare lo statico solo dove non ci sono provider supportati e bruciare TTL fino a giorni/ore + rotazione automatica.

H: Come si fa a mettere i segreti in sicurezza nella microservice?
О: Workload identity → mTLS к Secret Manager → sidecar/CSI → файлы в tmpfs + hot-reload. Niente cassetti, niente invvars «per sempre».

C: È possibile mantenere i segreti in Kubernets Secret?
O: Solo se è abilitata la crittografia etcd con KMS e regole rigorose. Preferire lo storage esterno e il CSI.

C: Come cancellare l'accesso dell'inquilino?
A: Ritira/blocca i suoi criteri in Secret Manager, disabilita tutti i leases, rotazione/rigenerazione delle chiavi KMS - Disattiva l'unwrap dei relativi KEK.

• Crittografia At Rest'
• Crittografia in transit
• Gestione e rotazione delle chiavi
• Autenticazione S2S
• Firma e verifica query