FAQ MSP: un segreto permanente di service principal non è un'identità del carico di lavoro

Gli account di automazione e le integrazioni spesso si autenticano con un segreto client di un service principal: una lunga stringa, valida per mesi, che qualsiasi script o ingegnere con accesso ad essa possa usare per agire come quell'identità. Aggiungere l'autenticazione a più fattori al lato umano di un account non cambia questo; il segreto stesso rimane una credenziale permanente con il proprio raggio di compromissione.

Perché i segreti client sono considerati legacy

Le linee guida di Microsoft sono esplicite: i service principal con segreti client dovrebbero essere considerati un approccio legacy, da sostituire con identità gestite o federate ovunque l'ambiente di hosting lo supporti. Un segreto client dovrebbe esistere solo quando un carico di lavoro non può davvero usare una credenziale più forte. Il problema non è che i segreti siano impossibili da proteggere: è che devono essere archiviati da qualche parte, ruotati secondo una pianificazione e revocati manualmente in caso di fuga, e ognuno di questi passaggi è un'occasione di errore.

Cosa elimina la federazione delle identità del carico di lavoro

La federazione delle identità del carico di lavoro consente a un carico di lavoro esterno, ad esempio una pipeline CI/CD, un cluster Kubernetes o uno script eseguito fuori da Azure, di fidarsi dei token emessi dal proprio provider di identità e di scambiarli con token di accesso Microsoft Entra di breve durata, senza che venga mai generato, archiviato o ruotato alcun segreto. Il confronto di Microsoft tra i tre modelli è diretto: i service principal federati e le identità gestite sono privi di segreti e funzionano in ambienti hosted, self-hosted e on-premises allo stesso modo, mentre i service principal basati su segreti non sono privi di segreti e comportano ancora il rischio operativo associato a qualsiasi credenziale a lunga scadenza.

Per un MSP che gestisce molti tenant dei clienti

La dimensione tenant conta tanto quanto il tipo di credenziale. Un singolo service principal condiviso tra più tenant di clienti trasforma un segreto trapelato in un incidente che coinvolge più clienti; l'identità dovrebbe essere vincolata all'ambito di un singolo tenant, indipendentemente dal modello di credenziale utilizzato. Dove la federazione non è ancora possibile, tratta il segreto client come un rischio permanente: cataloga dove viene usato, impostane la scadenza entro 90 giorni o meno e pianificane la rimozione una volta che la federazione sarà attiva.

Fonti: Microsoft Learn — Federazione delle identità del carico di lavoro, Microsoft Learn — Service principal e identità gestite.