FAQ MSP: tieni separati gli accessi umani e macchina tra i tenant

Gli MSP che gestiscono accessi tecnici e automazione su decine di tenant di clienti affrontano una versione specifica di un problema di settore in crescita: le identità non umane — account di servizio, chiavi API, token di automazione — devono essere governate in modo diverso dagli esseri umani che le creano.

Perché le NHI richiedono una governance separata

Il progetto Non-Human Identity Top 10 di OWASP osserva che le identità macchina non sono intrinsecamente legate a una persona e che i controlli di sicurezza umani comuni, come l'MFA, non si applicano in modo diretto. La discrepanza riguarda soprattutto il ciclo di vita: quando un tecnico se ne va, il suo account viene di solito disattivato nel giro di poche ore, ma gli account di servizio e le chiavi API che ha creato possono continuare a funzionare con permessi completi a meno che qualcuno non li trovi e li revochi esplicitamente. Poiché le identità non umane possono superare di gran lunga gli account umani negli ambienti moderni, un MSP che governa entrambi allo stesso modo lascia di fatto non gestita la sua popolazione di identità più numerosa.

Meglio a breve durata che permanenti

La raccomandazione coerente di OWASP e della Cloud Security Alliance è di sostituire i segreti a lunga durata con token effimeri e a breve scadenza che si invalidano automaticamente, invece di credenziali che funzionano indefinitamente una volta emesse. Un token a lunga durata trapelato dà a un attaccante tempo illimitato; un token che scade in minuti o ore limita il danno anche in caso di fuga.

Cosa significa nel modello multi-tenant di un MSP

• Usa provider di identità o service principal distinti per i tecnici umani rispetto all'automazione.
• Non permettere mai che una credenziale di emergenza di un tecnico funga anche da credenziale di servizio per una pipeline.
• Collega i token macchina a un singolo tenant del cliente — non emettere mai una chiave permanente che copra tutti i tenant.
• Mantieni la durata dei token misurata in minuti o ore e ruotali a ogni cambiamento di personale o automazione.
• Registra la classe di identità (umana o non umana) insieme all'ID del tenant su ogni record di accesso.

La soluzione non è un singolo strumento ma un'abitudine di governance: tratta l'automazione come una popolazione di identità a sé, con un proprio ambito di privilegi minimi per tenant, invece che come un'estensione del tecnico che l'ha configurata.

Fonti: OWASP Non-Human Identities Top 10, Cloud Security Alliance — Defining Non-Human Identity.