Un account di servizio è un'utenza usata da un programma, non da una persona: serve al gestionale per scrivere nella banca dati, al sistema di backup per lavorare di notte, a un'integrazione per scambiare dati tra due applicazioni. Il problema è che questi account nascono per far funzionare qualcosa in fretta e poi nessuno li guarda più: accumulano privilegi, perdono il proprietario e restano attivi per anni. Rimetterli in ordine si può, con un censimento graduale che non blocca i sistemi.
Cosa sono gli account di servizio e a cosa servono
Ogni sistema aziendale conosce due famiglie di account. Gli account personali appartengono a una persona: hanno un nome, un responsabile, un percorso di abilitazione all'ingresso e di revoca all'uscita. Gli account di servizio appartengono a un programma o a una funzione automatica: il gestionale che aggiorna la banca dati, il sito che legge gli ordini, il job che ogni notte copia i file, il connettore che sincronizza due applicazioni.
La differenza pratica è importante. Un account personale segue il ciclo di vita di chi lo usa: se la persona cambia ruolo o lascia l'azienda, l'account viene aggiornato o chiuso (su questo tema vedi la revoca degli accessi quando un dipendente esce). Un account di servizio non ha un ciclo di vita naturale: finché il programma funziona, nessuno si pone la domanda. E proprio qui nascono i problemi.
Tra i casi d'uso tipici e legittimi: l'account con cui il software di contabilità accede al database, quello usato dal sistema di backup per leggere i dati da copiare, quello di un'integrazione tra gestionale e magazzino, quello di un servizio di stampa o di scansione documenti. Sono account necessari. Il punto non è eliminarli, ma trattarli con la stessa disciplina degli account delle persone.
Perché gli account di servizio accumulano privilegi nel tempo
Il meccanismo è quasi sempre lo stesso, e non nasce da cattive intenzioni. Quando si installa un programma nuovo, l'obiettivo è farlo funzionare: all'account di servizio vengono concessi privilegi ampi «per evitare problemi», magari quelli di amministratore, perché restringerli richiede tempo e prove. Poi il programma funziona, la tentazione di toccare qualcosa che funziona è zero, e l'account resta com'è.
Negli anni si aggiungono altri strati: il fornitore che aveva creato l'account non lavora più con voi; il programma viene sostituito ma il vecchio account resta attivo «per sicurezza»; nessuno sa più con precisione quali sistemi lo usino. Il risultato è un account con poteri ampi, nessun proprietario e nessuna scadenza. Se le sue credenziali finiscono nelle mani sbagliate, chi le usa si presenta ai sistemi come un'utenza legittima e poco osservata.
Il principio correttivo è noto come privilegi minimi: ogni account — di persona o di servizio — dovrebbe avere solo i permessi necessari al suo compito. I Cross-Sector Cybersecurity Performance Goals di CISA, un insieme volontario di buone pratiche pensato anche per organizzazioni piccole e medie, lo citano tra gli obiettivi fondamentali. E la pubblicazione NIST SP 800-207 chiarisce il punto di principio: ogni soggetto che accede a una risorsa va autenticato e autorizzato, che sia una persona, un dispositivo o un servizio; non esiste fiducia ereditata «perché gira su un nostro server». (I CPG di CISA nascono nel contesto statunitense delle infrastrutture critiche: qui li usiamo come riferimento di buone pratiche, non come obbligo per le aziende italiane.)
I segnali di un account di servizio fuori controllo
Alcuni indizi suggeriscono che un account di servizio merita attenzione:
- Nessun proprietario. Chiedendo in giro, nessuno sa dire chi risponde di quell'account o quale programma lo usa.
- Privilegi sproporzionati. Ha diritti di amministratore o accesso a sistemi che non sembrano collegati alla sua funzione.
- Attività inattese. Viene usato in orari o da sistemi diversi da quelli previsti dal suo compito.
- Nessuna manutenzione. Le credenziali non vengono rinnovate da anni e l'account non compare in nessuna procedura documentata.
- Sopravvissuto al suo scopo. Il programma per cui era nato è stato dismesso o sostituito, ma l'account è ancora attivo.
Uno di questi segnali, da solo, non dimostra un problema: indica una verifica da fare. L'obiettivo del censimento è proprio trasformare questi indizi in schede con una risposta documentata.
Il censimento iniziale, senza bloccare i sistemi
La regola d'oro del censimento è: prima si osserva, poi si propone, infine si decide. Disattivare un account «sospetto» di impulso è il modo più rapido per fermare un processo aziendale che nessuno sapeva dipendesse da quell'utenza. Un percorso prudente si svolge così:
- Raccogliere l'elenco. Partire dalle fonti già disponibili — sistemi di gestione delle identità, inventari, documentazione dei fornitori — ed estrarre gli account non personali. Non serve partire da zero: serve partire da ciò che esiste.
- Assegnare un proprietario. Per ogni account, indicare una persona responsabile: chi sa dire a cosa serve e chi deciderà il suo destino. Se nessuno lo rivendica, l'account resta in evidenza finché non viene identificato.
- Classificare con tre domande. Serve ancora? Chi ne risponde? I privilegi sono quelli minimi necessari? Le risposte determinano la proposta: conferma, riduzione dei privilegi, rinnovo gestito delle credenziali oppure dismissione.
- Proporre, non spegnere. Ogni modifica passa da una proposta visibile e da un'approvazione. Dopo l'intervento si verifica che i processi che usavano l'account funzionino ancora.
- Tenere il controllo acceso. Il censimento chiude la fotografia iniziale; le variazioni successive — un account che cambia privilegi, uno nuovo che compare — vanno segnalate man mano, con una revisione periodica dei privilegi come appuntamento fisso.
Esempio illustrativo: l'account che nessuno possiede
Esempio illustrativo. Lo scenario seguente è inventato per spiegare il percorso; non descrive un cliente né un intervento realmente eseguito.
Durante il censimento, un'azienda trova un account di servizio creato anni prima per un gestionale nel frattempo dismesso: ha ancora privilegi ampi sulla banca dati e non risulta assegnato a nessun responsabile. Daedalus, l'agente di discovery e inventario, lavora nel perimetro concordato: mappa asset, servizi e dipendenze e mostra quali sistemi risultano ancora collegati a quell'account — compresa un'integrazione con il magazzino che nessuno ricordava. Athena, l'agente che controlla identità, gruppi e privilegi, spiega le autorizzazioni rilevate e mette in evidenza lo scostamento: privilegi ampi, nessun proprietario, scopo originario superato.
La proposta che arriva al responsabile offre opzioni con conseguenze chiare: mantenere l'account osservato assegnandogli un proprietario; ridurne i privilegi al minimo necessario per la sola integrazione attiva; programmare la dismissione dopo aver migrato l'integrazione. Qualunque sia la scelta, viene registrata insieme alla motivazione. Se il responsabile non risponde, nessuna modifica parte: il silenzio non autorizza.
Il contributo di OverZeus
OverZeus tratta gli account di servizio come soggetti da conoscere e tenere sotto controllo, non come dettagli tecnici. Daedalus mappa asset, servizi e dipendenze nel perimetro concordato ed evidenzia le informazioni mancanti: è dentro questo perimetro che la scoperta degli account di servizio avviene, usando le fonti di inventario e il discovery autorizzati per il progetto. Athena controlla identità, gruppi e privilegi, spiega le autorizzazioni rilevate e segnala le variazioni da verificare — per esempio quando un account di servizio viene aggiunto a un gruppo più ampio senza una richiesta approvata nelle fonti collegate.
Le operazioni attivabili dipendono dalle integrazioni e dalle policy concordate sul tuo ambiente: i sistemi da cui leggere identità e autorizzazioni vanno definiti in fase di progetto. Ciò che non cambia è il confine decisionale: gli agenti osservano e propongono, la persona competente approva, e ogni scelta resta documentata. Per un quadro più ampio degli strumenti di controllo, vedi anche l'articolo sullo strumento di controllo dei privilegi.
Porta un caso di modifica ai privilegi o al firewall da discutere in demo: vediamo insieme come OverZeus lo scopre, lo spiega e lo propone.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.