Perché i tuoi account 'svc-' sono una bomba a orologeria

By Mirko Peters · 2026-08-11

Automatically translated with AI from the original post. Read the English original

Titelbild: Why Your 'svc-' Accounts Are a Ticking Time Bomb

Bentornati al podcast e al nostro approfondimento continuo sull'architettura di sicurezza enterprise. Se la tua organizzazione è come la maggior parte, una rapida occhiata ad Active Directory o a Microsoft Entra ID rivelerà un vero e proprio cimitero di account che iniziano con "svc-", "app-" o "admin-bot". Questi account tengono in piedi i servizi, fanno scorrere i dati e mandano avanti le automazioni. Ma sono anche il punto cieco più grande della tua postura di sicurezza moderna. In questo post del blog approfondiamo la nostra ultima conversazione per spiegare perché gli account di servizio tradizionali minano completamente la tua architettura Zero Trust e perché migrare a Microsoft Entra Workload Identities sia l'unica strada da percorrere.

Per una panoramica audio completa su questo argomento, ascolta il nostro episodio di approfondimento del podcast, Replace Service Accounts with Entra Workload Identities. Ora addentriamoci nei meccanismi del rischio non umano e in come eliminarlo una volta per tutte.

TL;DR

Gli account di servizio con segreti statici e privilegi ampi sono il tuo divario di identità più grave. Workload Identities (in Microsoft Entra ID) assegnano a ogni attore non umano un'identità governata con privilegio minimo, ciclo di vita, criteri CA, rotazione e tracce di audit complete, senza interrompere le tue automazioni.

Perché gli account di servizio non reggono (e minano lo Zero Trust)

Il modello tradizionale degli account di servizio è stato progettato per un'epoca di perimetri di rete che non esistono più. Quando la fiducia si definiva in base al fatto che un dispositivo fosse collegato alla LAN aziendale, una password statica memorizzata in un file di configurazione sembrava accettabile. Oggi quella filosofia progettuale è una responsabilità.

Segreti statici e nessuna MFA -> facili da rubare, difficili da ruotare in sicurezza
Privilegi eccessivi per impostazione predefinita -> le autorizzazioni "facciamo funzionare il tutto" diventano permanenti
Nessun ciclo di vita -> account orfani o dimenticati sopravvivono a migrazioni e riorganizzazioni
Scarsa verificabilità -> "chi l'ha usato e perché?" = congetture e screenshot
Cultura delle eccezioni -> le esclusioni da CA/MFA per i bot ampliano silenziosamente la superficie d'attacco

Managed Identities: un buon passo, ma legato ad Azure

Quando le organizzazioni si rendono conto che gli account di servizio statici sono pericolosi, la prima svolta naturale è spesso verso le Azure Managed Identities. Le Managed Identities rappresentano un enorme passo avanti perché eliminano del tutto i segreti per le risorse ospitate in Azure, ma presentano limiti precisi.

✅ Accesso senza segreti per risorse native di Azure (Functions, VM, Logic Apps)
❌ Lacune per i target ibridi/di terze parti, mappatura della proprietà debole, viste di governance limitate
❌ La copertura di CA ed entitlement non è uniforme sulle superfici esterne ad Azure

Workload Identities: cosa ottieni davvero

Ed è qui che entrano in gioco le Microsoft Entra Workload Identities. Invece di trattare gli attori non umani come cittadini di seconda classe o di costringerti entro i vincoli esclusivi di Azure, le Workload Identities elevano applicazioni, script e servizi automatizzati a principal di sicurezza di prima classe.

Identità non umane di prima classe (app, script, connettori, RPA, integrazioni)
Autorizzazioni circoscritte (ruoli Graph/risorse, autenticazione solo app) con privilegio minimo
Ciclo di vita (proprietario, cadenza di revisione, flusso di dismissione) legato al processo aziendale
Conditional Access per i carichi di lavoro (controlli basati su rischio e contesto, controlli di sessione dove supportati)
Igiene delle credenziali (segreti a breve durata, certificati, criterio di rotazione delle chiavi)
Visibilità unificata (accessi, token, accesso alle risorse, cronologia delle modifiche) -> pronta per l'audit

Matrice di confronto (in sintesi)

Funzionalità	Account di servizio	Managed Identity	Workload Identity
Segreti	Password statiche	Senza segreti (Azure)	Senza segreti o a breve durata + rotazione
Ambito	Ampio / simile a un utente	Centrato su Azure	Qualsiasi carico di lavoro (app, script, connettori)
CA / Rischio	Raramente applicato	Limitato	Basato su criteri, dove supportato
Ciclo di vita	Ad hoc	Base	Proprietario + revisioni + dismissione
Audit	Scarso	Log di Azure	Traccia centralizzata di accessi ed entitlement

Pattern architetturali (casi d'uso comuni)

Implementare le identità dei carichi di lavoro richiede di mapparle correttamente sui pattern della tua architettura. Ecco come si applicano ai carichi di lavoro aziendali più comuni:

Connettori di Power Platform / flussi cloud -> Assegna una identità del carico di lavoro per ogni integrazione; concedi solo gli ambiti di Graph/Dataverse necessari.
App line-of-business (API web, daemon) -> Registrazione app + certificato; usa ruoli dell'app e Graph app-only; applica i CA dove possibile.
Script di automazione (Azure Automation, GitHub Actions, DevOps) -> Usa credenziali federate (OIDC), senza segreti archiviati.
Processi cross-tenant / B2B -> Un'identità del carico di lavoro dedicata per ogni confine di tenant; isola i diritti e la registrazione dei log.

Playbook di migrazione (90 giorni, senza drammi)

Gestire centinaia di account di servizio legacy può sembrare insormontabile. Per questo serve un playbook di migrazione strutturato, che copra 90 giorni e si concentri sulla riduzione del rischio.

Fase 1 — Scoperta e triage (settimane 0–3)

Inventaria gli accessi e gli oggetti non umani: svc-*, app-*, cassette postali condivise, registrazioni app, segreti in scadenza tra meno di 90 giorni.
Associa ogni elemento a un proprietario, uno scopo aziendale, i target, le autorizzazioni e la dipendenza dagli account di emergenza.
Classifica per rischio: password statiche, ruoli globali, assenza di proprietario, rotazione non recente.

Fase 2 — Converti prima i casi ad alto rischio (settimane 4–8)

Crea un'identità del carico di lavoro per ogni integrazione (non riutilizzarla).
Sostituisci l'autenticazione con password con certificati o credenziali federate; definisci la rotazione.
Passa alle autorizzazioni app-only; rimuovi quelle delegate dall'utente dove non sono necessarie.
Applica i criteri di Accesso condizionale per gli accessi dei carichi di lavoro (dove supportato).
Implementa le revisioni di accesso (trimestrali) e la proprietà nel CMDB/ITSM.

Fase 3 — Dismissione e governance (settimane 9–12)

Disabilita i vecchi account di servizio, monitora per 14 giorni, quindi eliminali.
Applica standard di creazione: convenzione di denominazione, proprietario, classificazione dei dati, cadenza delle revisioni.
Aggiungi avvisi: accessi anomali, identità inattive da oltre 30/60/90 giorni, segreti in scadenza.
Integra i controlli sulle identità nella CI/CD (policy-as-code).

Accesso condizionale e autorizzazioni (linee guida pratiche)

Una delle funzionalità più potenti delle moderne piattaforme di identità è la possibilità di applicare linee guida specificamente pensate per gli attori non umani. Separando i criteri per identità umane e per carichi di lavoro, eviti che i bot generino avvisi di "viaggio impossibile" e blocchi comunque il traffico malevolo.

Criteri separati per identità umane e identità dei carichi di lavoro; blocca l'accesso interattivo per i carichi di lavoro.
Posizioni denominate / restrizioni di rete per l'accesso app-only, dove possibile.
Diritti a tempo limitato (PIM per i ruoli dell'app dove disponibile; revisioni di accesso pianificate).
Ambiti: preferisci i ruoli dell'app o i ruoli specifici per risorsa rispetto ai diritti a livello di directory.

Registrazione e audit (cosa mostrare all'auditor)

Quando i responsabili della conformità e gli auditor bussano alla porta, non accettano più fogli di calcolo o rassicurazioni verbali su chi può accedere agli script di backend. Devi poter dimostrare la governance in modo immediato, con una registrazione centralizzata.

Proprietario dell'app o del carico di lavoro, scopo, sensibilità dei dati
Log di accesso (accessi delle entità di servizio), destinatario del token, IP, app client
Assegnazioni di ruolo (chi ha approvato, quando è stata certificata)
Cronologia delle credenziali (tipo, ultima rotazione, scadenza)
Ciclo di vita: creato/modificato/disabilitato/eliminato con l'autore della modifica

Dashboard KPI (dimostra il miglioramento)

Per mantenere nel tempo il sostegno della leadership, monitora e riporta gli indicatori chiave di prestazione che dimostrano la riduzione del rischio delle identità non umane.

% di identità non umane con proprietario + cadenza di revisione (obiettivo ≥ 95%)
Account di servizio orfani (obiettivo -> 0)
Segreti con più di 90 giorni (obiettivo -> 0; preferisci certificati/credenziali federate)
Ampiezza dei ruoli app-only (numero di "Directory.ReadWrite.All" -> in calo)
Risultanze di audit sugli accessi non umani (trimestre su trimestre ↓)

Anti-pattern da eliminare

Mentre ripulisci l'ambiente, assicurati che i team non tornino alle vecchie abitudini. Elimina subito questi anti-pattern:

Riutilizzare un singolo account di servizio generico su più sistemi
Incorporare password in script, web.config o Key Vault senza alcun criterio di rotazione
Assegnare Global Admin / Owner «per sicurezza» per far funzionare i processi
Eccezioni «temporanee» a CA che non scadono mai

Vittorie rapide (questa settimana)

Non serve aspettare l'avvio di un grande progetto per migliorare la postura di sicurezza. Ecco quattro vittorie rapide che puoi realizzare già questa settimana:

Assegna i tag Owner, System e Data Class a ogni identità non umana.
Passa un processo ad alto rischio alle credenziali federate (GitHub OIDC -> Entra).
Sostituisci un account di servizio condiviso in Power Automate con una workload identity.
Crea un report delle entità servizio con segreti in scadenza o scaduti e pianifica degli avvisi.

Domande frequenti (risposte rapide)

Le workload identity interrompono i processi legacy on-prem?
No: fai da ponte con autenticazione app-only, certificati o servizi di broker, e ritira le password gradualmente.

Posso applicare Accesso condizionale alle sessioni di accesso non umane?
Sì, per i flussi supportati (accessi tramite entità servizio). Usa i segnali di rete, posizione e dispositivo dove applicabili e blocca l'accesso interattivo.

Come evito la proliferazione?
Una workload identity per integrazione (non per team). Imponi nome + proprietario + revisioni al momento della creazione e automatizza la pulizia delle identità inattive.

E Power Platform?
Usa entità servizio / workload identity per i connettori e Dataverse; smetti di usare account utente condivisi.

Conclusione

Non puoi risolvere il rischio degli account di servizio solo con la rotazione delle password. Entra Workload Identities portano l'accesso non umano nello stesso modello di Zero Trust, ciclo di vita e audit che già pretendi per le persone, senza interruzioni né interventi eroici. Inizia dagli account «svc-» più rischiosi, convertili in workload identity governate e fai in modo che le eccezioni tornino a essere davvero eccezioni.

Se ti è piaciuto questo articolo, non perdere la discussione completa nel nostro episodio del podcast, Replace Service Accounts with Entra Workload Identities. Iscriviti allo show per altri approfondimenti sulle strategie di sicurezza enterprise di Microsoft 365 e Azure!