Audit Logging degli Accessi

La piattaforma Mirox mantiene un audit trail continuo e a prova di manomissione di ogni accesso remoto ai dispositivi di rete di un impianto — ogni sessione di tunnel VPN (Layer 3/4) e ogni richiesta Proxy (Layer 7, HTTP). Questa pagina descrive esattamente cosa viene registrato, quanto è granulare il dettaglio, chi è autorizzato ad accedervi e per quanto tempo i dati vengono conservati.

L'audit trail è ciò che rende l'accesso ai dispositivi dell'impianto conforme alle regole tedesche KRITIS e alla direttiva EU NIS2. Tali normative impongono la finestra minima di conservazione e le categorie di evidenze che l'operatore deve essere in grado di produrre — ma il log di audit è, prima di tutto, uno strumento di tracciamento degli accessi per l'operatore dell'impianto.

Perché Esiste Questo Audit Logging

KRITIS e NIS2 obbligano gli operatori di infrastrutture critiche (nel nostro caso le reti degli impianti di parchi solari, parchi eolici e siti di accumulo a batteria) a poter rispondere alle seguenti domande per ogni accesso remoto, in modo completo e anche mesi dopo:

Chi ha raggiunto la rete interna di questo impianto?
Quando è stata stabilita la connessione — e per ogni connessione: quando è stata toccata per la prima e l'ultima volta una determinata sottorete / un determinato dispositivo?
Quanto traffico è stato trasferito durante la connessione?
Quale dispositivo specifico e quale servizio è stato toccato?
Cosa è stato fatto lì (a livello HTTP: quali URL, quali metodi)?

L'audit trail Mirox copre tutte queste domande ed è progettato per l'operatore dell'impianto in quanto parte soggetta all'obbligo di rendicontazione — non per l'utente che accede.

Due Percorsi di Accesso, Un Audit Condiviso

Entrambi i meccanismi di accesso alla piattaforma confluiscono in una panoramica unificata degli accessi per ogni impianto:

Percorso	Layer registrato	A quale domanda risponde?
VPN	Layer 3/4 (traffico IP)	"Chi ha raggiunto quale sottorete e quale dispositivo specifico, da dove — quando per la prima volta, quando per l'ultima, con quale volume?"
Proxy	Layer 7 (HTTP)	"Cosa ha fatto specificamente l'utente sul dispositivo — quali URL, quali richieste, quante richieste, per quale durata?"

Entrambi i percorsi condividono la stessa base di identità (l'account Mirox dell'utente) e la stessa logica legale di conservazione e accesso. Dal punto di vista dell'operatore dell'impianto esiste un'unica lista cronologica degli accessi per impianto, in cui entrambi i canali compaiono affiancati e possono essere filtrati secondo necessità.

Profondità di Registrazione

L'audit trail è organizzato in diversi livelli di dettaglio. Più si scende nella gerarchia, più le informazioni diventano granulari:

Layer 1: Certificato / Identità

Il livello superiore registra, per ogni certificato VPN, uno snapshot dell'identità utente al momento dell'emissione e della rotazione:

Nome account anonimizzato
Indirizzo email
Identificatore univoco del certificato

Anche se l'utente viene successivamente rinominato, eliminato o il certificato viene revocato, questa identità viene preservata.

Layer 2: Sessione

Ogni connessione viene tracciata come una sessione. Una sessione è un periodo continuo di attività dallo stesso certificato dalla stessa origine. Brevi interruzioni inferiori a dieci minuti contano ancora come la stessa sessione; pause più lunghe creano una nuova sessione.

Per ogni sessione registriamo:

Chi è connesso (snapshot di account ed email al momento della connessione — preservato anche se l'account viene eliminato in seguito)
Orario di connessione
Indirizzo IP di origine e attribuzione geografica (città, paese)
Regione e nodo che hanno terminato la connessione (per l'analisi della latenza)
Volume totale di dati (in entrata e in uscita)

Layer 3: Volume per Sottorete (Solo VPN)

All'interno di una sessione registriamo, per ogni sottorete dell'impianto toccata:

Quale parco e quale sottorete è stata toccata
Volume di dati trasferiti e conteggio dei pacchetti per sessione e sottorete
Orario del primo e dell'ultimo contatto
Snapshot del nome del parco e dell'organizzazione, nel caso l'impianto venga successivamente rinominato o eliminato

Il rumore come query DNS, multicast mDNS, ping ICMP e comportamenti simili a port-scan viene filtrato e/o limitato in frequenza, in modo che l'audit trail riporti solo eventi di utilizzo effettivi.

Layer 4: Contatti con i Dispositivi (Solo VPN)

Il livello VPN più granulare registra, per ogni dispositivo di destinazione specifico:

IP del dispositivo, protocollo (TCP, UDP, ICMP, ICMPv6, SCTP) e porta
Il dispositivo corrispondente nell'inventario dell'impianto (nome, tipo) — se registrato
Orario del primo contatto all'interno della sessione
Numero di eventi di connessione in questa sessione
Snapshot di tutti gli identificatori al momento del primo contatto

Le interazioni sotto soglia (ad es. singoli reset TCP da clic errati) vengono registrate in modo conservativo, ma sono riconoscibili come tali.

Layer 4': Sessioni HTTP (Solo Proxy)

In parallelo, il Proxy registra, per ogni sessione a livello HTTP:

Account ed email dell'utente che accede
Quale destinazione web o accesso predefinito al dispositivo è stato utilizzato
Dispositivo di destinazione (nome, IP) — con snapshot per i casi di successiva eliminazione o rinomina
Browser, sistema operativo, indirizzo IP pubblico, posizione geografica
Inizio e fine della sessione (fine sessione: 10 minuti di inattività)
Numero di richieste e relativi metodi HTTP (ad es. {"GET": 42, "POST": 3, "PUT": 1})
Volume di dati in entrata e in uscita
Una traccia delle attività della sessione basata sugli URL (le query string vengono redatte, limitate alle attività più recenti entro una soglia fissa)
Una breve descrizione generata dall'AI dell'attività della sessione, per un triage rapido. Se l'AI non è disponibile alla chiusura della sessione, la descrizione viene compilata successivamente — non è opzionale, ma una parte fissa di ogni sessione proxy chiusa.

Massima Profondità di Dettaglio Possibile

La massima profondità di dettaglio è quindi:

Esempio di accesso VPN:

"L'utente X si è connesso tramite VPN il 2026-05-13 alle 13:44 dall'IP pubblico 198.51.100.7 (regione eu-central, Monaco, DE), ha indirizzato la sottorete 10.90.69.0/24 del parco 'Solar Park Annaburg' durante questa sessione (12 MB trasferiti, primo contatto 13:45, ultimo 13:54), toccando specificamente il dispositivo 'Inverter Block 3' (10.90.69.12, TCP/443) (primo contatto 13:45, 41 connessioni)."

Esempio di accesso Proxy:

"L'utente Y ha acceduto alla destinazione web 'Inverter Block 3 – Service UI' tramite il Proxy il 2026-05-13 tra le 13:46 e le 13:55 dall'IP pubblico 203.0.113.42 (regione eu-central, Francoforte, DE) su Mobile Safari 26.4 / iOS 18.7 (87 richieste, di cui 84 GET, 3 POST; 2.3 MB di volume di risposta, riepilogo AI: 'Modifica della configurazione delle impostazioni dell'MPP tracker')."

Sia VPN che Proxy registrano l'IP pubblico di origine, la regione di terminazione e l'attribuzione geografica (città, paese) della connessione. Per il Proxy, le informazioni su browser e sistema operativo entrano inoltre nell'audit trail (tramite lo User-Agent inviato dal browser), poiché viaggiano comunque a livello HTTP. Per l'accesso puramente basato su VPN (Layer 3/4) queste informazioni sul client applicativo non sono intrinsecamente disponibili — lì la piattaforma vede solo il flusso di pacchetti IP, non il client a livello applicativo.

Un livello di dettaglio più profondo (contenuti dei pacchetti, body HTTP completi) non viene deliberatamente registrato, poiché sarebbe sia problematico per la privacy sia operativamente inutile.

Chi È Autorizzato a Vedere l'Audit?

L'accesso all'audit trail è limitato in base al ruolo lavorativo che un utente ricopre sull'impianto:

Un Technical Manager o superiore sull'impianto può visualizzare l'audit trail di quell'impianto. In pratica ciò significa un Operatore, un Technical Manager o un Asset Manager sull'impianto. Admin e Moderatori si qualificano automaticamente, poiché il loro ruolo organizzativo si mappa a un ruolo lavorativo idoneo su ogni impianto della loro organizzazione (vedi il Sistema di Permessi per la mappatura completa ruolo-mansione).
I cooperatori sono inclusi: un tecnico che raggiunge un impianto attraverso una cooperazione con il ruolo lavorativo richiesto può anch'esso vedere l'audit trail di quell'impianto. La visibilità sull'audit segue lo stesso vincolo di ruolo lavorativo del resto dei controlli dell'impianto.
I Visualizzatori sono esclusi. Un Visualizzatore (e chiunque sia al di sotto del livello di Technical Manager) non vede alcun audit trail. Il frontend nasconde completamente la scheda del log degli accessi per gli utenti al di sotto della soglia.

La piattaforma espone la vista di audit attraverso un endpoint API dedicato per il log degli accessi e una corrispondente vista UI. La modifica o l'eliminazione dei record di audit non è supportata.

Periodo di Conservazione e Resistenza alla Manomissione

Almeno 730 giorni di conservazione per tutti i livelli di audit (certificato, sessione, volume per sottorete, contatti con i dispositivi, sessioni HTTP). Il periodo di conservazione è allineato tra i livelli, in modo che i riferimenti incrociati tra di essi si risolvano sempre all'interno dell'intera finestra di audit.
I campi snapshot su ogni record di audit (ad es. nome del parco, nome del dispositivo, nome dell'organizzazione, account, email) sono write-once: vengono impressi al primo inserimento e mai aggiornati. Questo garantisce l'identità forense anche se il record originale (utente, impianto, dispositivo) viene successivamente eliminato o rinominato.
Risoluzione live con fallback: finché le entità di riferimento (utente, parco, organizzazione, dispositivo) esistono ancora, la vista di audit mostra il loro nome attuale (ad es. dopo che l'impianto è stato rinominato). Una volta eliminata l'entità, la vista esegue automaticamente il fallback allo snapshot impresso. L'audit trail rimane così leggibile — anche mesi o anni dopo, dopo cambi di personale o vendite di impianti.
Nessun percorso di eliminazione o modifica rivolto all'utente: le tabelle di audit non possono essere modificate tramite normali operazioni UI o API. Vengono toccate solo da eventi di audit automatizzati e dal processo notturno di pulizia per la conservazione, dopo la scadenza dei 730 giorni.

Comportamento in Caso di Eliminazioni

Evento	Effetto sull'audit trail
L'utente viene eliminato	I record di audit vengono preservati. La vista mostra lo snapshot di account ed email dal certificato o dalla sessione.
Il certificato viene revocato	I record di audit vengono preservati. Il certificato viene soft-revocato e rimane disponibile come fonte di risoluzione per 730 giorni.
L'impianto viene eliminato	I record di audit vengono preservati. La vista mostra lo snapshot del nome del parco dal record di audit.
Il dispositivo viene eliminato / rinominato / l'IP cambiato	I record di audit vengono preservati. La vista mostra lo snapshot del nome del dispositivo; l'IP nel record è l'identificatore forense persistente.
L'organizzazione viene eliminata	I record di audit vengono preservati. La vista mostra lo snapshot del nome dell'organizzazione.

Protezione Contro la Manomissione dei Dati di Audit

Le sessioni che non possono essere attribuite (ad es. perché un header è stato rimosso) vengono comunque registrate con identità vuota, anziché essere scartate. Un'analisi successiva può quindi indagare specificamente questi casi.
Le sessioni HTTP non vengono chiuse dai soli componenti SaaS, ma vengono chiuse e segnalate dall'agente dell'impianto stesso, così che la piattaforma SaaS non possa sottostimare silenziosamente il conteggio delle richieste o il volume.
Le race condition di durata inferiore al millisecondo durante la lettura delle catene di contatori sono accettate come "lossy by design" e documentate per essere conformi a KRITIS; al massimo possono interessare un singolo ciclo di contatore, mai intere sessioni o contatti con i dispositivi.

Filtraggio e Ricerca nella Vista di Audit

La vista di audit consente a un utente autorizzato di restringere l'insieme dei risultati:

Per account utente
Per sottorete o IP del dispositivo
Per protocollo o porta (percorso VPN)
Per destinazione web o dispositivo specifico (percorso proxy)
Per intervallo temporale (da … a …)
Ordinamento predefinito per "ultimo visto"

L'ordinamento predefinito raggruppa naturalmente per sessione, così che la domanda "L'utente X ha toccato i dispositivi A e B in questa sessione 18:43–19:00, e il dispositivo C in una seconda sessione 13:44–14:30" sia direttamente visibile senza ulteriore raggruppamento lato client.

Privacy e Divulgazione

Cosa l'audit trail contiene:

Campi identità derivati dal normale account Mirox (account, email)
Indirizzi IP di origine della connessione (richiesti legalmente per KRITIS)
Attribuzione geografica dell'origine (città, paese)
Volume di dati, conteggio delle richieste, distribuzione dei metodi, timestamp

Cosa l'audit trail non contiene:

Contenuti dei singoli body HTTP
Contenuti dei pacchetti VPN
Sequenze di tasti o registrazioni dello schermo
Dati non necessari per la rendicontazione KRITIS / NIS2

Cosa Fare in Caso di Richiesta Normativa

Per richieste di informazioni dovute a incidenti rivolte all'autorità competente (ad es. il BSI ai sensi di KRITIS), tutti i dati necessari sono disponibili entro la finestra di 730 giorni tramite la vista di audit. Una funzione di esportazione (ad es. CSV) è prevista come azione separata e singolarmente sottoposta ad audit, e viene fornita su richiesta — tale esportazione è essa stessa un'operazione degna di audit, in modo da documentare chi ha esportato quali dati di audit e quando ("audit dell'audit").

Funzionalità Correlate

VPN — tunnel personale con registrazione completa dell'audit a Layer 3/4
Proxy — accesso basato su browser con registrazione completa dell'audit a Layer 7
Sistema di Permessi — la mappatura ruolo-mansione che decide chi può aprire la vista di audit
Cooperazioni — come a un tecnico cooperante viene concesso (e sottoposto ad audit) l'accesso all'impianto
Restrizioni di Cooperazione — i limiti che mantengono l'accesso condiviso entro l'ambito scelto dal proprietario