Observability ai tempi di CRA e NIS2

Dall'11 settembre 2026 diventano operativi gli obblighi di segnalazione del Cyber Resilience Act¹ e la Single Reporting Platform gestita da ENISA². Da quella data, un produttore di software ha 24 ore per inviare l’early warning³ su una vulnerabilità attivamente sfruttata o su un incidente grave. Rispettare queste scadenze richiede un’observability integrata fin dalla progettazione. Le finestre temporali prevedono poi 72 ore per la notifica dettagliata, 14 giorni (vulnerabilità) o un mese (incidenti gravi) per il report finale.

L’ordine di grandezza delle sanzioni chiarisce la posta in gioco: il Regolamento (UE) 2024/2847 prevede fino a 15 milioni di euro o il 2,5% del fatturato globale annuo, la NIS2⁴ fino a 10 milioni o il 2% per le entità essenziali. Il problema, però, non è legale. È di ingegneria.

Ventiquattro ore non sono un problema di modulistica. Sono un requisito di Mean Time To Detect. Se la telemetria è dispersa in silos non correlati, la finestra si consuma nella ricostruzione manuale dell’accaduto: chi ha chiamato cosa, con quale identità, su quale endpoint, in quale finestra temporale.

Qui sta il punto che sfugge alla maggior parte dei contenuti sull’argomento. Il CRA non chiede soltanto di notificare: all’Allegato I, Parte 1, punto (l) chiede che il prodotto registri e monitori l’attività interna rilevante per la sicurezza, cioè accessi e modifiche a dati, servizi e funzioni. L’observability è quindi un requisito di prodotto prima ancora che uno strumento operativo.

Questo articolo mappa i tre pilastri della telemetria sugli obblighi normativi, mostra come progettare la cascata di notifica 24h/72h a partire dalla pipeline di observability e chiude sull’uso dei modelli di anomaly detection per comprimere il tempo di rilevazione.

Cosa chiedono davvero CRA e NIS2 in termini di visibilità sui sistemi?

Il CRA regola i prodotti con elementi digitali, la NIS2 regola le entità che erogano servizi essenziali. Il primo impone la registrazione dell’attività security-relevant come requisito essenziale di sicurezza del prodotto; la seconda impone alle organizzazioni di notificare gli incidenti significativi entro finestre precise. Entrambi presuppongono una capacità di rilevazione che nessuna checklist documentale può sostituire.

La distinzione fra Regolamento (UE) 2024/2847 e Direttiva (UE) 2022/2555 non è accademica: cambia chi è il soggetto obbligato. Se produci e vendi software, il CRA ti riguarda in quanto fabbricante. Se gestisci un servizio in uno dei 18 settori coperti dalla NIS2, sei obbligato in quanto entità. Molte aziende italiane sono entrambe le cose contemporaneamente, e questo è il caso più scomodo da gestire.

L’Allegato I del CRA elenca il logging e il monitoraggio dell’attività rilevante per la sicurezza fra i requisiti essenziali di sicurezza del prodotto, e l’Allegato VII impone che la documentazione tecnica ne dia evidenza esplicita. Non è una buona pratica operativa: è una condizione per la marcatura CE, quindi per l’accesso al mercato europeo.

Perché un solo incidente fa scattare due normative

Immagina una vulnerabilità zero-day in un componente software venduto a un operatore sanitario. Viene sfruttata attivamente in produzione un martedì mattina. Da quel momento partono due catene di obblighi distinte: il produttore notifica ai sensi del CRA perché il difetto è nel prodotto, l’ospedale notifica ai sensi dell’Art. 23 NIS2 perché il servizio essenziale è compromesso. Le finestre a 24 e 72 ore corrono in parallelo, non in sequenza.

La conseguenza operativa è concreta: servono due catene di evidenze separate, alimentate però dalla stessa pipeline di telemetria. Chi le tiene distinte a mano, esportando screenshot da dashboard diverse, brucia ore che non ha.

Il perimetro NIS2 è più ampio di quanto molti team pensino. Nelle proposte di emendamento e semplificazione di gennaio 2026, la Commissione europea stimava in circa 28.700 le organizzazioni coinvolte e facilitate nei loro obiettivi di conformità⁵.

Se i tuoi clienti operano in energia, sanità, trasporti, pubblica amministrazione o servizi digitali, con ogni probabilità rientrano. Le intersezioni fra le due normative e il regolamento DORA⁶ sono trattate in modo sistematico attraverso il nostro compendio su NIS2 e DORA, utile per capire quale disciplina si applica al proprio perimetro. Le implicazioni architetturali di questi obblighi sui cluster e sulle piattaforme le abbiamo analizzate anche dal punto di vista della conformità nelle architetture cloud native.

Il logging come requisito essenziale di prodotto, non come pratica DevOps

Che cosa significa, in pratica, registrare l’attività interna rilevante per la sicurezza? Significa produrre eventi strutturati e correlabili per almeno queste categorie:

• eventi di autenticazione e autorizzazione, inclusi i tentativi falliti e le escalation di privilegio;

• modifiche di configurazione applicativa o infrastrutturale, con l’identità di chi le ha eseguite;

• accessi a dati sensibili o soggetti a vincoli GDPR⁷, con riferimento alla risorsa toccata;

• invocazioni di funzioni privilegiate e di API amministrative;

• eventi di integrità: verifica delle firme, aggiornamenti applicati, rollback eseguiti.

Il requisito implicito che quasi tutti sottovalutano è la documentazione. Se non sai dichiarare quali eventi il tuo prodotto registra, dove li scrive e per quanto tempo li conserva, il fascicolo tecnico previsto dall’Allegato VII semplicemente non esiste.

Nella maggior parte dei progetti che ereditiamo il logging c’è, ma è stato progettato per il debug: messaggi in linguaggio naturale, campi non normalizzati, retention di pochi giorni decisa dal costo dello storage. Per l’audit servono schema stabile, formato strutturato e retention allineata al ciclo di vita del prodotto. Cambia tutto.

Monitoring o observability: quale regge davvero un audit di conformità?

Il monitoring risponde a domande che hai già previsto quando hai configurato le soglie. L’observability ti permette di formulare domande nuove su un sistema in esecuzione, senza rilasciare codice aggiuntivo. Uno zero-day è per definizione una domanda che non avevi previsto: ecco perché in sede di audit e di incident response il monitoring da solo non regge.

Tabella di confronto fra monitoring tradizionale e observability

L’uptime al 99,9% non è una metrica di conformità. Un servizio può essere perfettamente “up”, rispondere 200 a tutte le richieste ed essere contemporaneamente compromesso da settimane: la disponibilità misura la continuità, non l’integrità.

I tre pilastri come catena di evidenze

Log, metriche e tracce: i tre pilastri dell’observability sono gli stessi che ogni team conosce dalla documentazione di OpenTelemetry, ma sotto il CRA cambiano funzione. Non servono più soltanto a capire perché un servizio è lento, vanno letti in chiave probatoria, ciascuno con un ruolo preciso nella ricostruzione di un incidente:

• Metriche: il segnale che qualcosa è fuori norma. Rispondono al “cosa” e sono il trigger della timeline normativa.

• Tracce distribuite: il percorso della richiesta attraverso i servizi. Rispondono al “dove” e definiscono il perimetro dell’impatto.

• Log strutturati e correlati: l’evidenza di ciò che è accaduto. Rispondono al “perché” e alimentano il report finale.

Senza correlazione restano tre silos, e la ricostruzione forense non entra nelle 24 ore.

Gli span attributes sono ciò che trasforma la telemetria in evidenza: route HTTP, status code, client IP, identità del chiamante, tenant. Senza attributi contestuali un log è rumore che nessun auditor accetterà come ricostruzione dell’impatto.

OpenTelemetry⁸ non è solo una scelta tecnica, è una scelta di sovranità sui dati: una strumentazione vendor-agnostic significa poter cambiare backend, da uno strumento di Application Performance Management (APM) commerciale come Dynatrace⁹ a uno stack open source, senza spezzare la continuità dell’evidenza. Quando il ciclo di vita del prodotto dura anni e la retention deve seguirlo, questa portabilità è un requisito, non una preferenza architetturale.

Sul piano del runtime entra in gioco eBPF¹⁰, che consente monitoraggio a livello di kernel e container senza modificare le applicazioni. È qui che si materializza la distinzione del CRA fra vulnerabilità presente e vulnerabilità attivamente sfruttata: l’analisi statica e la SBOM¹¹ dicono che la falla c’è, solo il runtime dice che qualcuno la sta usando. Il lato build di questa catena, con scanning, firma degli artefatti e policy nelle pipeline, lo abbiamo già trattato nell’articolo della serie dedicato all’automazione del monitoraggio nelle pipeline cloud native.

Trasformare questi tre segnali in indicatori auditabili richiede la disciplina del Site Reliability Engineering, che nella nostra guida operativa traduciamo in SLI, SLO e affidabilità misurabile invece che in dashboard da guardare a occhio.

Come progettare la cascata 24h/72h con una pipeline di observability

Le 24 ore vanno trattate come un budget temporale, non come una scadenza amministrativa. Vanno spacchettate in quattro fasi: detection automatica, triage e qualificazione dell’evento, raccolta delle evidenze minime, invio dell’early warning. Se la detection ne consuma 18, alle restanti tre fasi resta un margine che nessun team riesce a rispettare.

Ecco le quattro fasi della cascata con il rispettivo deliverable:

1. Detection (obiettivo: minuti, non ore). Deliverable: alert qualificato con snapshot della telemetria della finestra temporale.
2. Triage e qualificazione (poche ore). Deliverable: decisione documentata su “incidente grave” o “vulnerabilità attivamente sfruttata”, con il razionale.
3. Early warning entro 24 ore. Deliverable: natura dell’evento, sospetta origine, servizi impattati.
4. Notifica dettagliata entro 72 ore. Deliverable: perimetro dell’impatto, indicatori di compromissione, misure di mitigazione già applicate. Segue il report finale entro 14 giorni per le vulnerabilità sfruttate o un mese per gli incidenti gravi, con root cause analysis documentata e misura correttiva.

Né il Regolamento (UE) 2024/2847 né le FAQ ENISA sulla Single Reporting Platform² specificano il formato degli allegati: l’output della pipeline va progettato per essere esportabile. Un dump di dashboard non è un allegato di notifica: servono estratti strutturati, con timestamp coerenti e riferimenti agli identificativi di traccia.

Dalla detection all’early warning: cosa automatizzare nelle prime 24 ore

L’alerting va costruito su indicatori di sicurezza, non solo su soglie infrastrutturali. Definire SLI e SLO che riflettano il comportamento atteso del servizio, come il rapporto fra autenticazioni riuscite e fallite per client, o la distribuzione attesa delle chiamate a endpoint privilegiati, permette di far scattare un segnale prima che l’anomalia diventi un disservizio visibile all’utente.

Il secondo elemento è il routing. L’alert di sicurezza deve finire in un canale di incident response distinto da quello operativo ordinario, con un timer normativo esplicito nel messaggio. Dalla nostra esperienza, il fallimento più frequente non è la mancata rilevazione: è il mancato riconoscimento che quell’alert ha una scadenza di legge. Un ticket di sicurezza parcheggiato in backlog per 30 ore è un problema di processo, non di strumenti.

Il terzo è lo snapshot automatico del contesto al momento del trigger: tracce correlate all’identificativo della richiesta sospetta, metriche della finestra temporale, log degli eventi security-relevant. Congelarli all’istante evita di doverli ricostruire quando la retention li ha già ruotati.

Conservare le evidenze in modo auditabile

La retention va allineata alla vita attesa del prodotto, non alla convenienza di costo del backend di log. Se dichiari un supporto di cinque anni, sette giorni di log non reggono la prima verifica.

C’è poi la questione dell’integrità: chi può modificare o cancellare i log? Un’evidenza alterabile da chiunque abbia accesso al cluster non è un’evidenza. Servono write-once storage, controlli di accesso separati e tracciamento delle operazioni sul log stesso.

Infine la correlazione fra l’identificativo dell’incidente interno e il riferimento della notifica inviata tramite la Single Reporting Platform di ENISA², che smista poi ai CSIRT¹² territoriali competenti, in Italia il CSIRT operante presso l’Agenzia per la Cybersicurezza Nazionale (ACN)¹³. Le pratiche di qualificazione e risposta che rendono sostenibile questo processo le abbiamo raccolte nella nostra guida alla sicurezza applicativa lungo il ciclo di vita del software.

AI applicata all’observability: anomaly detection e compliance proattiva

I modelli di anomaly detection applicati a log, metriche e tracce comprimono il tempo di rilevazione sostituendo le soglie statiche con baseline dinamiche apprese dal comportamento reale del sistema. In un contesto AIOps questo significa correlare eventi apparentemente scorrelati su servizi diversi e far emergere segnali che nessuna regola preconfigurata avrebbe intercettato.

Il paradosso operativo del compliance-driven monitoring è che più requisiti di registrazione produci, più eventi generi, più rumore accumuli. L’alert fatigue non è un fastidio da service desk: è un rischio normativo diretto. Un segnale autentico sepolto fra migliaia di falsi positivi consuma la finestra delle 24 ore mentre nessuno se ne accorge.

Che cosa fanno concretamente questi modelli sulla telemetria di produzione:

• costruiscono baseline dinamiche per servizio, endpoint e fascia oraria, invece di soglie fisse che vanno bene solo per il traffico medio;

• correlano eventi su servizi diversi che nessun operatore metterebbe in relazione, ad esempio un picco di errori di autorizzazione su un servizio e un cambio di latenza su un altro;

• rilevano configuration drift rispetto allo stato desiderato prima che la deviazione diventi una vulnerabilità sfruttabile.

Il limite va dichiarato con onestà: un modello che segnala un’anomalia non produce una notifica conforme. La qualificazione dell’evento come incidente grave resta una decisione umana, motivata e documentata. L’AI comprime il MTTD (Mean Time To Detect), non trasferisce la responsabilità del fabbricante.

Un discorso a parte, che qui resta fuori scope, riguarda l’osservabilità dei sistemi AI stessi: come tracciare workload probabilistici e agenti in produzione lo abbiamo affrontato parlando di AgentOps.

Dall’allarme all’azione automatizzata

L’anomalia rilevata non deve limitarsi ad accendere un pannello. In un’architettura event-driven innesca un workflow: isolamento del workload sospetto, rollback della configurazione deviata, apertura automatica del fascicolo incidente con lo snapshot delle evidenze già allegato.

L’automazione event-driven non è un concetto sperimentale: piattaforme mature come Event-Driven Ansible¹⁴, Datadog¹⁵ e Dynatrace⁹ collegano un segnale rilevato a un workflow di risposta automatica, dall’isolamento del workload al rollback di una configurazione, senza intervento umano. Questi sistemi permettono di gestire una quantità di dati automatizzati enorme. Il valore non dipende però solo dal volume, quanto dall’affidabilità dei segnali in ingresso: un’automazione innescata da alert rumorosi amplifica gli errori invece di ridurli.

Errori ricorrenti che vanificano l’investimento

Quattro pitfall che vediamo ripetersi sul campo:

• telemetria raccolta in abbondanza ma non correlata, quindi inutilizzabile come catena di evidenze;

• retention decisa dal budget del backend e non dal ciclo di vita dichiarato del prodotto;

• alert privi di ownership nominale e privi di scadenza normativa esplicita;

• strumentazione aggiunta a posteriori invece che progettata insieme all’applicazione, cioè l’assenza di observability by design, gemello operativo del security by design richiesto dal CRA.

La regola pratica per verificarlo in dieci minuti: se per un dato servizio non sai dire quale evento genera quale segnale e chi lo riceve entro quanti minuti, la conformità che hai messo a fascicolo è teorica.

Da obbligo normativo a capacità operativa

L’observability ha due ruoli sotto il CRA, non uno: è requisito essenziale di prodotto secondo l’Allegato I, Parte 1, punto (l), ed è l’abilitatore della cascata di notifica a 24 e 72 ore, tanto lato fabbricante quanto lato entità essenziale ai sensi dell’Art. 23 NIS2. Chi la tratta solo come strumento di troubleshooting sta costruendo metà della conformità.

Il salto da compiere non è tecnologico ma culturale: trattare la telemetria come evidenza fin dalla progettazione, non come strumento da consultare quando qualcosa si rompe. Chi adotta questa prospettiva arriva alle scadenze del CRA e della NIS2 con le prove già pronte all’export, invece di rincorrerle mentre il cronometro delle 24 ore scorre.

In SparkFabrik siamo Kubernetes Certified Service Provider, membri CNCF¹⁶ e OpenSSF¹⁷, e progettiamo stack di observability open source basati su Prometheus¹⁸, Grafana¹⁹, Jaeger²⁰ e OpenTelemetry su Kubernetes²¹ in ambienti multi-cloud. La scelta dell’open source qui è più che ideologica: è l’unica che garantisce la portabilità dei dati di telemetria lungo un ciclo di vita del prodotto che può durare più a lungo del contratto con il vendor.

Dalla mappatura delle dipendenze con la SBOM all’automazione della compliance a runtime, l’adeguamento al CRA passa per capacità tecniche che si costruiscono insieme, non in sequenza. Il quadro completo degli obblighi e delle scadenze è raccolto nella pagina dedicata al Cyber Resilience Act e ai percorsi di adeguamento, mentre per un assessment di sicurezza e conformità puoi confrontarti con il nostro team di supply chain security.

Note e fonti