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
-
Esistenza esplicita: ogni identità non umana è registrata (owner, scopo, scope, data di scadenza).
-
Vita breve prima della comodità: token/certificati vivono ore–giorni, non mesi. La rotazione è obbligo, non obiettivo di progetto.
-
La fiducia è dimostrabile: mTLS + firme + attestazioni; niente “crediamo che …”.
-
Least privilege by design: i diritti sono specifici, ben separati e scadono automaticamente.
-
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
Qual è il problema principale delle identità macchina e degli account di servizio?
Il rischio principale deriva dagli account di servizio con privilegi permanenti e segreti hard-coded, perché consentono accessi prolungati e spesso invisibili agli attaccanti.
Come si può ridurre il rischio di sicurezza degli account di servizio?
Il rischio si riduce con token a vita breve, mTLS obbligatorio e rotazione dei segreti ogni 30–90 giorni.
Chi è responsabile degli account macchina in azienda?
Ogni account macchina dovrebbe avere un owner chiaro, permessi definiti e una data di scadenza.
Come si riconosce un abuso delle identità macchina?
Gli abusi si individuano correlando identità, destinazione e orario di utilizzo e applicando la revoca automatica in caso di anomalie.
Quale policy di sicurezza è obbligatoria per i segreti?
Una policy fondamentale è bloccare le build quando vengono trovati segreti o commit non firmati.
