La mappatura dei sistemi informativi descrive applicazioni, infrastrutture, persone e flussi che rendono possibile un servizio. Il suo valore emerge davanti a una decisione: cosa si interrompe se un componente si guasta, dove passa un dato personale e chi può confermare il funzionamento di un’interfaccia. Un diagramma gradevole ma privo di proprietari, versioni e collegamenti verificati diventa rapidamente poco affidabile.
Il metodo ANSSI per la cartografia dei sistemi propone una costruzione progressiva. Questa guida ne riprende l’approccio operativo, collegando inventario, viste, flussi e manutenzione. Il risultato è una mappa utilizzabile per sicurezza, continuità e protezione dei dati, senza confonderla con un elenco di prodotti o con il solo registro dei trattamenti.
Scegliere la domanda cui la mappa deve rispondere
Prima di raccogliere informazioni, identificate il destinatario e la decisione. La direzione può aver bisogno di capire quali servizi dipendono da un fornitore; gli amministratori devono conoscere collegamenti e punti di gestione; chi prepara il registro deve ricostruire categorie di dati e destinatari. Una vista unica raramente serve bene a tutte queste persone.
Definite un perimetro iniziale significativo, per esempio il percorso di una richiesta cliente dalla ricezione alla fatturazione. Indicate società, sedi e ambienti inclusi. Esplicitate anche ciò che non è ancora verificato: una linea tratteggiata con un referente da intervistare è più utile di un collegamento presentato come certo senza evidenza.
Stabilite il livello di dettaglio. Per una vista direzionale può bastare il servizio di identità; per un piano di ripristino servono componenti, configurazioni e dipendenze. Tenete separati i dati di gestione riservati, come indirizzi amministrativi o dettagli di rete sensibili, dalle mappe distribuite a un pubblico più ampio.
Costruire un inventario con identificativi stabili
Assegnate a ciascuna applicazione e componente un identificativo che non dipenda soltanto dal nome commerciale. Un prodotto può cambiare denominazione, un’istanza può essere sostituita e un’organizzazione può avere più ambienti dello stesso servizio. L’identificativo permette di collegare mappa, contratto, rischio e azione correttiva senza perdere la continuità storica.
Raccogliete proprietario del servizio, referente tecnico, funzione, utenti, fornitore, ambiente e criticità. Aggiungete fonte dell’informazione e data di verifica. Una risposta del reparto acquisti conferma il contratto, mentre un amministratore può confermare l’uso effettivo; quando le due fonti divergono, la mappa deve conservare l’anomalia fino alla risoluzione.
| Oggetto | Campi iniziali | Fonte di conferma |
|---|---|---|
| Applicazione | Identificativo, funzione, proprietario e ambiente | Referente del servizio |
| Infrastruttura | Componente, ubicazione logica e dipendenze | Amministrazione tecnica |
| Fornitore | Entità contrattuale, servizio e referente | Contratto e acquisti |
| Flusso | Origine, destinazione, dati e frequenza | Configurazione e referente applicativo |
| Accesso | Identità, ruolo e percorso | Sistema delle autorizzazioni |
Non rinviate la mappatura perché l’inventario non è perfetto. Avviate il lavoro con le informazioni disponibili e un elenco delle lacune. Il controllo più utile consiste nel verificare che ogni oggetto abbia un referente e che nessun collegamento importante dipenda soltanto da una conoscenza informale.
Separare le viste senza perdere i collegamenti
La vista dei servizi mostra ciò che l’organizzazione eroga. Quella applicativa mostra i sistemi che sostengono quei servizi. La vista tecnica descrive infrastrutture, collegamenti e zone di fiducia. La vista dei dati segue invece categorie di informazioni, destinatari e luoghi di trattamento. Gli stessi identificativi devono permettere di passare da una vista all’altra.
Per esempio, un servizio di assistenza può utilizzare un portale, una casella di posta e un sistema di ticket. La vista applicativa evidenzia le tre componenti; quella dei dati mostra gli allegati personali e le esportazioni; quella tecnica identifica il fornitore e il servizio di identità. Ognuna risponde a una domanda diversa sul medesimo processo.
La politica di sicurezza informatica può richiedere queste viste per le nuove applicazioni. Il requisito deve essere proporzionato: un piccolo servizio non necessita dello stesso dettaglio di un’infrastruttura complessa, ma deve comunque rendere comprensibili responsabilità, dati e dipendenze essenziali.
Descrivere i flussi come operazioni reali
Una freccia deve avere un significato. Indicate quali informazioni passano, attraverso quale meccanismo, con quale frequenza e sotto la responsabilità di chi. Distinguete un’integrazione automatica da un’esportazione manuale e da un accesso remoto. Questi percorsi hanno controlli, rischi e possibilità di interruzione differenti.
Verificate anche i flussi meno visibili: allegati inviati all’assistenza, esportazioni per l’analisi, copie in ambienti di prova e file caricati in strumenti personali. Interviste e osservazione del processo aiutano a scoprire queste pratiche. L’obiettivo è rappresentare l’attività reale, non soltanto l’architettura prevista dal progetto iniziale.
Per i servizi internazionali, distinguete ubicazione dichiarata dei dati, accessi del personale e catena dei subfornitori. Il percorso sui trasferimenti internazionali utilizza proprio queste informazioni. Una regione di hosting europea non descrive da sola tutti i destinatari o tutti i possibili accessi.
Collegare mappa e registro dei trattamenti
Il registro dei trattamenti descrive attività, finalità e altri elementi richiesti dall’articolo 30; la mappa descrive come sistemi e flussi le sostengono. Non esiste necessariamente una corrispondenza uno a uno. Una stessa applicazione può servire più trattamenti e un trattamento può attraversare diversi strumenti.
Create quindi relazioni esplicite tra identificativo del trattamento e componenti coinvolte. Questo permette di trovare i sistemi da interrogare per una richiesta di accesso, quelli da aggiornare per una rettifica e le copie da considerare nella conservazione. Evitate di duplicare interi testi in ogni scheda: riferimenti stabili riducono il rischio di versioni contraddittorie.
L’articolo 30 GDPR rimane il riferimento per i contenuti obbligatori del registro. Una mappa tecnica può alimentarlo e renderlo più attendibile, ma non sostituisce automaticamente le informazioni giuridiche richieste, come finalità e categorie di interessati.
Usare un esempio completo per verificare la mappa
Prendete un ordine ipotetico dal portale alla fatturazione. Seguite identificativo cliente, recapiti, dettagli della richiesta e documento finale. Identificate dove vengono inseriti, modificati ed esportati, chi può consultarli e quali sistemi mantengono una copia. Chiedete al referente di dimostrare ogni passaggio con dati di esercitazione.
Introducete poi una variazione: l’indirizzo deve essere corretto oppure l’ordine arriva durante un’interruzione. La mappa deve permettere di capire quali sistemi aggiornare e come evitare una reimportazione del dato precedente. Se non lo consente, aggiungete il collegamento o l’informazione mancante, senza aumentare indiscriminatamente il dettaglio di tutte le viste.
La stessa prova alimenta il piano di continuità operativa. Individuate quali componenti devono tornare disponibili prima delle altre e quali attività possono proseguire temporaneamente. Una dipendenza dal sistema di identità o dal fornitore di posta può emergere soltanto seguendo l’operazione dall’inizio alla fine.
Scegliere strumenti e organizzare gli aggiornamenti
Un foglio strutturato e diagrammi collegati possono essere sufficienti per un perimetro limitato. Un catalogo più complesso può richiedere relazioni, controllo delle versioni e permessi differenziati. Valutate la facilità di esportazione e aggiornamento prima dell’estetica: uno strumento che soltanto una persona sa usare crea una nuova dipendenza.
Definite eventi che richiedono manutenzione: acquisto di un servizio, nuova integrazione, modifica del fornitore, cessazione di un’applicazione o variazione rilevante dei dati. Il responsabile della modifica deve sapere quale scheda aggiornare e chi conferma la nuova vista. Una revisione periodica resta utile per intercettare cambiamenti non segnalati.
Infine collegate le anomalie della mappa al piano dei controlli di igiene informatica. Applicazioni senza proprietario, collegamenti non documentati e ambienti dimenticati devono diventare azioni assegnate. Conservate le versioni necessarie a interpretare incidenti e decisioni passate, limitando accessi e durata in base all’utilità. La mappa diventa così una base di lavoro che accompagna il cambiamento, anziché un’immagine aggiornata soltanto prima di un audit.