A un fornitore va concesso solo l'accesso necessario al servizio che deve svolgere, con un account nominativo, una scadenza legata al contratto, una traccia delle attività svolte e una revoca automatica quando il rapporto finisce. Ogni accesso esterno deve avere un responsabile interno che ne risponde. Questa checklist riassume le regole minime per concedere, controllare e chiudere gli accessi di terze parti senza affidarti alla memoria di qualcuno.
Perché gli account dei fornitori sono tra i più dimenticati
Gli accessi dei fornitori nascono quasi sempre in fretta: un guasto da risolvere, una migrazione da completare, un'assistenza urgente sul gestionale. L'account viene creato per sbloccare il lavoro, e quando il lavoro finisce nessuno ha il compito esplicito di chiuderlo. La responsabilità si divide tra chi gestisce il contratto (acquisti, amministrazione) e chi gestisce i sistemi (IT, spesso in parte esterno a sua volta): ognuno presume che l'altro abbia revocato.
Il principio di riferimento è quello dell'architettura zero trust descritta dalla pubblicazione NIST SP 800-207: nessuna fiducia implicita per posizione di rete o proprietà del sistema, e autenticazione e autorizzazione verificate prima di ogni sessione verso una risorsa. Tradotto per le terze parti: un account del fornitore è un soggetto da autorizzare come qualsiasi altro, con privilegi minimi e senza fiducia ereditata «perché è un nostro partner» o «perché si collega da una rete privata virtuale (VPN)». Attenzione: SP 800-207 è un modello architetturale, non una certificazione di prodotto.
Anche i Cross-Sector Cybersecurity Performance Goals del CISA — un insieme volontario di pratiche essenziali, nato per le infrastrutture critiche statunitensi e utile come riferimento di buone pratiche, non come obbligo per le aziende italiane — includono tra gli obiettivi i rischi dei fornitori di servizi gestiti e il principio dei privilegi minimi. Il messaggio delle fonti converge: l'accesso esterno non è un dettaglio tecnico, è una decisione di governance.
La checklist delle regole minime
Sette regole coprono la gran parte dei problemi. Per ognuna serve un responsabile nominativo: una regola senza proprietario è una regola che nessuno applica.
| Regola | Cosa significa in pratica | Chi ne risponde |
|---|---|---|
| Perimetro minimo | Il fornitore accede solo ai sistemi e ai dati necessari al servizio contrattuale; niente privilegi amministrativi «per comodità». | Referente IT, con il responsabile del servizio |
| Account nominativo | Ogni tecnico esterno ha un'identità propria; niente account condivisi tra persone o tra fornitori diversi. | Referente IT |
| Scadenza | L'accesso ha una data di fine legata al contratto o al singolo intervento; le proroghe sono nuove decisioni, non rinnovi taciti. | Responsabile del contratto |
| Traccia | Accessi e attività dell'account esterno sono registrati e consultabili dopo, non solo nel momento. | Referente IT / sicurezza |
| Revoca a fine rapporto | La chiusura del contratto innesca la disattivazione degli account, con una verifica di avvenuta esecuzione. | Acquisti segnala, IT esegue, un responsabile verifica |
| Revisione periodica | Gli accessi esterni ancora attivi vengono riletti a intervalli concordati: servono ancora? Il perimetro è ancora quello giusto? | Responsabile sicurezza o titolare |
| Eccezioni controllate | Ogni attività fuori dal perimetro atteso viene segnalata, spiegata e riesaminata: non diventa abitudine silenziosa. | Referente IT / sicurezza |
Quali accessi concedere e per quanto tempo
Parti dal contratto, non dalla richiesta tecnica: che cosa deve fare il fornitore, su quali sistemi, con quale frequenza? Un manutentore che interviene sul gestionale due volte l'anno non ha bisogno di un account sempre attivo; meglio un'abilitazione temporanea con finestra e scopo dichiarati, oppure un account disattivato da riattivare a ogni intervento approvato. Per i fornitori con assistenza continuativa, la scadenza coincide con la durata del contratto e la revisione periodica verifica che perimetro e realtà coincidano ancora.
Come si controlla cosa fa un account esterno
Definisci per ogni accesso esterno un perimetro atteso — sistemi raggiungibili, orari tipici, tipo di operazioni — e registra ciò che avviene. Il controllo non è diffidenza verso il fornitore: è la stessa tracciabilità che dovresti avere sugli account interni con privilegi elevati, come descritto nella guida allo strumento di controllo dei privilegi. Senza registrazione, l'unica risposta possibile a «cosa ha fatto il tecnico martedì scorso?» è una telefonata e una fiducia.
Chi revoca l'accesso quando il contratto finisce
La revoca è un passaggio di consegne tra tre ruoli: chi gestisce il contratto segnala la fine del rapporto, chi gestisce i sistemi disattiva gli account, un responsabile verifica che sia stato fatto. Va scritta nella procedura di chiusura contratto, non lasciata all'iniziativa. Il meccanismo è lo stesso della revoca degli accessi quando esce un dipendente: cambia chi segnala, non la logica.
Esempio illustrativo: l'assistenza sul software di magazzino
Esempio illustrativo. Lo scenario seguente è inventato e mostra un percorso possibile con OverZeus; non racconta un caso reale.
Un'azienda di distribuzione ha un contratto di assistenza con il fornitore del software di magazzino. Tre anni prima, per una migrazione, era stato creato un account esterno con privilegi ampi; la migrazione è finita, l'assistenza continua, e l'account è rimasto com'era. Alla revisione periodica degli accessi, Athena mette in evidenza l'account esterno con privilegi che superano il perimetro atteso e ne spiega le autorizzazioni rilevate. Argus, che osserva gli eventi delle fonti collegate, segnala un accesso avvenuto in un orario insolito rispetto all'attività tipica di quel fornitore.
Il responsabile IT riceve la proposta con il contesto: ridurre i privilegi al necessario, oppure sospendere l'account fino al prossimo intervento pianificato. Decide per la riduzione e la sospensione temporanea, in attesa del riscontro del fornitore. Mnemosyne conserva la segnalazione, la proposta, la decisione e l'esito: mesi dopo, quando il fornitore chiede perché il suo accesso è cambiato, la risposta è nel registro e non nella memoria di qualcuno. Nessuna sospensione sarebbe partita da sola: l'intervento attivo richiede l'approvazione prevista, e il silenzio non autorizza.
Segnalazione automatica delle attività fuori perimetro
La regola più difficile da mantenere a mano è l'ultima: le eccezioni. Un accesso fuori orario, un sistema toccato che non rientra nel servizio, un'attività più ampia del previsto: se il controllo dipende da una persona che ricorda di guardare, prima o poi smette di funzionare. Il perimetro atteso va quindi tradotto in controlli automatici sulle fonti collegate, con segnalazioni che arrivano a un responsabile insieme al contesto necessario per decidere.
Due cautele rendono il meccanismo sostenibile. La prima: l'elenco delle eccezioni attive è esso stesso un oggetto da revisione periodica dei privilegi, altrimenti l'eccezione tollerata diventa la nuova regola non scritta. La seconda: una segnalazione fuori perimetro non è un'accusa; spesso è una manutenzione legittima comunicata male, e il processo deve prevedere il confronto con il fornitore prima di qualunque conclusione.
Il contributo di OverZeus
OverZeus riunisce 16 agenti AI specializzati in sicurezza, gestione IT, audit e dispositivi. Sul controllo degli accessi dei fornitori lavorano in particolare tre agenti:
- Athena — identità e privilegi: controlla identità, gruppi e privilegi, spiega le autorizzazioni rilevate sugli account esterni e mette in evidenza le variazioni da verificare, come un privilegio cresciuto oltre il perimetro concordato.
- Argus — monitoraggio continuo: osserva eventi, servizi e rete tra le fonti collegate ed evidenzia gli scostamenti dalla situazione attesa, per esempio un accesso esterno in orario o su sistemi fuori perimetro.
- Mnemosyne — audit ed evidenze: conserva fonti, timeline, proposte, autorizzazioni ed esiti, così la storia di ogni accesso esterno — concessione, uso, revisione, revoca — resta ricostruibile.
Come nel resto del progetto, gli agenti osservano, spiegano la proposta e attendono l'approvazione prevista prima di un intervento attivo: la decisione su un account di un fornitore resta a una persona. Le operazioni attivabili dipendono dalle integrazioni e dalle policy concordate sul tuo ambiente; con Oracle e la modalità di sola osservazione puoi vedere in prova quali segnalazioni emergerebbero sui tuoi accessi esterni, senza modificare la produzione.
Porta un caso di modifica ai privilegi o al firewall da discutere in demo: vediamo insieme come OverZeus lo osserva, lo spiega e lo prepara per la tua decisione.
Contenuto realizzato con assistenza AI. Gli scenari descritti sono esempi illustrativi.