Il problema: account di servizio trattati come account utente

Chiunque amministri un dominio Active Directory da più di qualche anno conosce la scena: un vecchio account di servizio con password impostata per non scadere mai, usato da tre applicazioni diverse, con permessi accumulati nel tempo che nessuno ricorda più il perché siano stati concessi. Quando arriva il momento di ruotare quella password — magari a seguito di un audit di sicurezza o di un incidente — si scopre che dipende da lei anche un servizio di backup dimenticato, un task pianificato su un server satellite e una voce di configurazione cifrata in un vault che nessuno aggiorna da anni.

Il problema di fondo è concettuale, prima ancora che tecnico: un account di servizio non è un account utente travestito. Un account utente rappresenta una persona che si autentica interattivamente ed è responsabile delle proprie azioni; un’identità di workload rappresenta un’applicazione, un servizio Windows, un task pianificato o un job che deve autenticarsi senza che nessuno sia fisicamente presente. Trattare le due cose allo stesso modo — stessa policy di password, stesso processo di provisioning, stesso ciclo di vita — è la causa principale di gran parte dei problemi di gestione delle identità che si vedono in produzione.

La gerarchia corretta per scegliere l’identità di un workload

Prima di creare l’ennesimo account utente con “non scade mai” spuntato, vale la pena seguire un ordine di preferenza ormai consolidato nelle best practice Microsoft:

1. gMSA (Group Managed Service Account): la scelta di default per qualsiasi workload supportato che gira su uno o più server domain-joined. La gestione della password è completamente automatica e trasparente ad Active Directory, e lo stesso gMSA può essere condiviso da un gruppo di host (utile per farm IIS o cluster di servizi).
2. sMSA (Standalone Managed Service Account): quando il servizio è vincolato a un singolo host e non serve la condivisione tipica del gMSA.
3. Account utente dedicato: da usare solo come ultima spiaggia, quando il software non supporta i Managed Service Account (capita ancora con applicazioni legacy), e comunque dopo aver verificato in un ambiente di test che non ci siano alternative.
4. Account virtuale o locale: quando il servizio non ha bisogno di accedere a risorse di dominio, evitando di coinvolgere Active Directory laddove non serve.

Su Azure il discorso è concettualmente identico ma la soluzione cambia nome: al posto del gMSA si usa una Managed Identity (assegnata dal sistema o dall’utente), che elimina del tutto la necessità di gestire segreti per l’autenticazione verso i servizi Azure supportati (Key Vault, Storage, SQL Database e decine di altri). Il principio è lo stesso: se esiste un meccanismo gestito dalla piattaforma che elimina la password dall’equazione, va preferito a qualsiasi credenziale gestita manualmente.

Creare un gMSA in pratica

Per chi non lo avesse mai fatto, ecco il flusso minimo in PowerShell per predisporre e distribuire un gMSA:

# Sul primo controller di dominio, crea la KDS Root Key (una tantum per foresta)
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

# Crea il gMSA
New-ADServiceAccount -Name "svc-webapp01" `
    -DNSHostName "svc-webapp01.contoso.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "WebServers"

# Sull'host che ospiterà il servizio
Install-ADServiceAccount -Identity "svc-webapp01"
Test-ADServiceAccount -Identity "svc-webapp01"

Una volta superato il test, il servizio Windows o il pool applicativo IIS può essere configurato per girare con l’identità CONTOSO\svc-webapp01$ senza che nessun amministratore debba mai più digitare o annotare una password per quell’account.

I quattro guasti tipici da evitare

L’esperienza operativa mostra che la maggior parte degli incidenti legati alle identità di workload ricade in quattro categorie:

• Dipendenze nascoste alla rotazione password: la password viene cambiata in Active Directory ma non in ogni servizio dipendente, task pianificato, file di configurazione cifrato, voce di vault o connettore remoto che la utilizza — risultato: un’ondata di errori di autenticazione a cascata.
• Credenziali condivise tra workload diversi: un account “comodo” viene riutilizzato per un secondo servizio, poi un terzo; i suoi permessi si accumulano e la mappa delle dipendenze si espande fino a diventare ingestibile.
• Account orfani: nessuno sa più spiegare a cosa serva un account, quando sia stato usato l’ultima volta o cosa succederebbe disabilitandolo — quindi resta attivo indefinitamente, per timore.
• Over-permissioning: i permessi vengono concessi per “far funzionare la cosa” durante un deploy urgente e non vengono mai più rivisti né rimossi.

Guardrail operativi per ogni identità di workload

Indipendentemente dalla tecnologia scelta, ogni identità di workload dovrebbe avere:

• Proprietà documentata: un owner tecnico e uno di business identificabili, non “il team infrastruttura” in senso vago.
• Least privilege reale: solo i diritti strettamente necessari, con rimozione delle appartenenze a gruppi privilegiati ereditate per errore in fase di provisioning.
• Confini di logon espliciti: nega l’accesso interattivo dove non serve (Deny log on locally / Deny log on through Remote Desktop Services) e limita l’account agli host e contesti di servizio approvati.
• Monitoraggio dedicato: alert su logon da host inaspettati, tentativi di accesso interattivo, cambi di privilegio o pattern anomali di errori di autenticazione — un account di servizio che tenta un logon RDP è quasi sempre un segnale di compromissione.

Vale anche la pena distinguere i cicli di vita: un account persona segue i processi di onboarding, trasferimento e offboarding legati alle risorse umane; un’identità di workload dovrebbe invece seguire il ciclo di vita dell’applicazione che rappresenta — deploy, change, ritiro — e finire disabilitata quando quell’applicazione viene dismessa, non restare “per sicurezza” a tempo indeterminato.

Il processo di migrazione da account utente a identità gestita

Quando si eredita un ambiente pieno di account utente usati come service account, la migrazione va condotta con calma, un workload alla volta:

1. Riprodurre lo scenario in un ambiente di test rappresentativo.
2. Installare/autorizzare il gMSA (o configurare la Managed Identity) sugli host previsti.
3. Concedere solo i diritti effettivamente documentati come necessari.
4. Configurare gli SPN richiesti (il gMSA li gestisce automaticamente; un account utente richiede setspn manuale).
5. Validare in sequenza: salute del servizio, autenticazione Kerberos, accesso alle risorse, esecuzione dei task pianificati, comportamento in failover.
6. Passare in produzione una unità recuperabile alla volta, non tutto insieme.
7. Conservare la configurazione precedente finché il cambio non è stato accettato in modo stabile.
8. Definire in anticipo una condizione di stop chiara: se qualcosa va storto, si torna all’identità nota-buona invece di improvvisare credenziali diverse su nodi diversi.

È un lavoro che richiede pazienza, ma il risultato — niente più password condivise su fogli Excel, rotazioni automatiche, audit trail chiari — ripaga ampiamente lo sforzo iniziale, sia in ambiente on-premises con gMSA sia in Azure con Managed Identity.

Fonte originale

Articolo di riferimento: Service Account vs User Account: Default to a Managed Identity for Workloads — Petri IT Knowledgebase.