Identità non umane: le chiavi trascurate

Management Summary

Valutazione onesta: in molti ambienti le identità macchina sono più pericolose degli account utente. Account di servizio con privilegi permanenti, segreti hard-coded, token eterni e telemetria assente sono punti di ingresso perfetti – invisibili, comodi, spesso dichiarati “tecnicamente necessari”. Chi prende sul serio Zero Trust deve verificare non solo le persone, ma anche workload, servizi e dispositivi. La strada è chiara: inventario coerente, privilegi minimi, credenziali a vita breve, rigorosa secrets rotation e mTLS applicato – dimostrato con KPI, non con dichiarazioni di intenti.

Perché le identità non umane sono sottovalutate

• Invisibilità nella quotidianità: non c’è un dipendente che “clicca male”. Per questo gli account di servizio raramente rientrano nei programmi di awareness – e sfuggono a ogni controllo.
• Comodità vs. sicurezza: privilegi permanenti e password statiche “semplicemente funzionano”. Finché non vengono copiati, trapelati o recuperati dai repo.
• Effetto di scala: un build token o un certificato IoT compromesso apre intere flotte – movimento laterale senza allarmi.
• Assenza di proprietà: chi “possiede” l’account? Dev? Ops? Business unit? Senza un owner chiaro, tutto resta in sospeso.

Debolezze tipiche

• Segreti hard-coded in codice, variabili CI/CD, template IaC → secret scanning obbligatorio, divieto di testo in chiaro, secrets store centrale, secrets rotation ≤ 30 giorni.
• Token/certificati di lunga durata → identità di workload firmate e a vita breve; rinnovo automatico, revoca in caso di anomalie.
• Account di servizio con troppi privilegi → scope rigorosi, least privilege, accesso basato su tempo o evento; niente account condivisi.
• Sicurezza di trasporto assente tra servizi → mTLS obbligatorio (verifica reciproca) con rotazione automatica dei certificati.
• Nessun inventario/nessuna telemetria → registro centrale delle identità macchina, log di utilizzo ed emissione, allarmi su pattern “impossibili”.

Principi per un’identità macchina resiliente

1. Esistenza esplicita: ogni identità non umana è registrata (owner, scopo, scope, data di scadenza).
2. Vita breve prima della comodità: token/certificati vivono ore–giorni, non mesi. La rotazione è obbligo, non obiettivo di progetto.
3. La fiducia è dimostrabile: mTLS + firme + attestazioni; niente “crediamo che …”.
4. Least privilege by design: i diritti sono specifici, ben separati e scadono automaticamente.
5. Rilevabilità: ogni utilizzo lascia correlazione (identità × destinazione × momento × fonte) – altrimenti niente impiego.

Piano di 90 giorni

Giorno 0–15 – Visibilità & criteri di stop

• Inventario completo di tutti gli account di servizio, token, certificati, API key (incl. owner, scope, scadenza).
• Policy: divieto di segreti hard-coded; durate minime; mTLS obbligatorio per percorsi service-to-service interni.
• Stabilire KPI di baseline (vedi sotto).

Giorno 16–45 – Rafforzamento & vita breve

• Introdurre/standardizzare un secrets store centrale; avviare secrets rotation automatizzata.
• Identità di workload a vita breve (credenziali firmate e a tempo) per i 3 servizi più critici.
• Attivare mTLS sui percorsi critici (verifica reciproca, auto-renew).

Giorno 46–75 – Automatizzare & cancellare

• Gate CI/CD: build fallisce con segreti hard-coded, certificati scaduti, scope eccessivi.
• Dieta dei privilegi: ridurre account di servizio sovraprivilegiati; eliminare identità inutilizzate.
• Rilevamento anomalie: uso insolito (tempo, fonte, volume) → auto-revoke + pager.

Giorno 76–90 – Consolidare & dimostrare

• Fissare cicli di rotazione (≤ 30 giorni token, ≤ 90 giorni certificati – secondo il rischio).
• Testare il processo break-glass per identità macchina (emettere, usare, revocare, auditare).
• Steering trimestrale con KPI; legare il budget all’impatto (es. “pinned rate”, “rotation rate”).

KPI che rendono misurabile la maturità

• Copertura inventario: % di identità macchina registrate con owner, scope, scadenza.
• Tasso di rotazione: % di segreti/certificati ruotati entro i cicli target.
• Punteggio di vita breve: durata mediana di token/certificati per criticità.
• Copertura mTLS: % di percorsi critici con mTLS applicato (incl. verifica reciproca).
• Igiene degli scope: quota di account di servizio con privilegi minimi (niente wildcard, niente admin-all).
• Leak/find rate: numero di segreti trovati al mese e tempo fino a revoca/rotazione.

Anti-pattern

• “Tecnicamente necessario” come scusa per privilegi permanenti – no. Dimostrare la necessità, limitarla, compensare il rischio.
• “mTLS più tardi” – più tardi significa mai. Senza verifica reciproca, la rete “interna” è un campo aperto.
• “Solo ambiente dev” – gli attaccanti amano il dev: modelli dati reali, chiavi reali, poco monitoring.
• “Non logghiamo – privacy” – la privacy non vieta il logging. Registrare in modo sobrio ma verificabile.

Checklist pratica

• Imporre secret scanning in tutti i repo/pipeline CI; fail della build in caso di ritrovamenti.
• Secrets store centrale con secrets rotation e prestiti a vita breve (just-in-time per i servizi).
• mTLS obbligatorio per servizi interni; emissione/rinnovo automatico dei certificati.
• Review dei permessi per account di servizio: minimizzare scope, impostare scadenze, assegnare owner.
• Obbligo di telemetria: correlare l’uso per identità; auto-revoke in caso di anomalie.
• Disciplina di cancellazione: rimuovere identità macchina inutilizzate – cadenza mensile.

Conclusione: l’identità è più dell’umano

Chi rafforza solo gli utenti costruisce una porta d’ingresso d’acciaio – e lascia aperta la porta laterale. Le identità macchina sono oggi la via d’attacco numero uno realistica: silenziose, scalabili, spesso senza allarmi. Con credenziali a vita breve, scope rigorosi, mTLS obbligatorio, secrets rotation praticata e KPI solidi, la sicurezza passa dall’intuizione al controllo. Tutto il resto è speranza costosa.

FAQ sul post del blog