NIS2 per sviluppatori: obblighi tecnici concreti per chi gestisce applicazioni web

La direttiva NIS2 è entrata formalmente in vigore il 18 ottobre 2024 con il recepimento nella legislazione nazionale degli stati membri dell'Unione Europea, e la maggior parte dei titolari di PMI italiane che incontro la conosce come "quella cosa che deve gestire il DPO" o "un problema dell'ufficio legale." È un errore di inquadramento che costa caro: NIS2 non è una normativa sulla privacy come il GDPR - è una normativa sulla sicurezza dei sistemi informativi che impone obblighi tecnici concreti a chi scrive codice, gestisce server e mantiene applicazioni web. Se sei uno sviluppatore PHP che gestisce un'applicazione Laravel in produzione per un'azienda che rientra nel perimetro NIS2 (e il perimetro è molto più ampio di quanto pensi), questa normativa ti riguarda direttamente - e non rispettarla espone l'azienda a sanzioni che possono raggiungere i 10 milioni di euro o il 2% del fatturato globale.

A marzo 2025 ho completato l'adeguamento NIS2 per un'azienda del settore manifatturiero con circa 70 dipendenti - un'azienda che rientrava nel perimetro come "soggetto importante" perché opera nel settore della fabbricazione di prodotti critici con più di 50 dipendenti. Il lavoro ha coinvolto tre aree: la configurazione del logging e del monitoring secondo i requisiti tecnici della direttiva, la strutturazione del processo di incident response con le tempistiche obbligatorie di notifica, e la documentazione delle misure di sicurezza per dimostrare la conformità in caso di audit. In questo articolo mappo gli articoli tecnici di NIS2 su azioni concrete che uno sviluppatore o un responsabile IT può implementare - non teoria legale, ma configurazioni, procedure e codice.

Quali obblighi tecnici impone NIS2 a chi gestisce applicazioni web?

L'articolo 21 della direttiva NIS2 elenca dieci categorie di misure di gestione del rischio cyber che i soggetti essenziali e importanti devono implementare. Per uno sviluppatore che gestisce applicazioni web, le categorie rilevanti sono cinque: gestione degli incidenti (incident handling), sicurezza della catena di approvvigionamento (supply chain security), gestione delle vulnerabilità (vulnerability handling and disclosure), uso della crittografia, e politiche di sicurezza dei sistemi informativi. La guida tecnica di implementazione pubblicata da ENISA nel 2025 traduce questi requisiti generali in misure specifiche con esempi di evidenze per dimostrare la conformità.

In termini pratici, per un'applicazione Laravel su VPS Linux, i requisiti si traducono in queste azioni concrete:

Logging obbligatorio. NIS2 richiede che i soggetti "predispongano procedure e utilizzino strumenti per monitorare e registrare le attività sui propri sistemi di rete e informazione al fine di rilevare eventi che possano essere considerati incidenti." Tradotto in linguaggio tecnico: devi avere log applicativi strutturati che registrino autenticazioni (successo e fallimento), modifiche ai dati sensibili, accessi amministrativi, errori di sicurezza (CSRF, validazione, rate limiting), e operazioni critiche (pagamenti, export dati, cambio permessi). I log devono essere conservati per un periodo sufficiente a supportare l'analisi forense post-incidente - la guida ENISA suggerisce un minimo di 90 giorni, con best practice a 12 mesi per i log di sicurezza.

Incident response con tempistiche vincolanti. L'articolo 23 della direttiva impone tre scadenze non negoziabili: early warning entro 24 ore dalla scoperta di un incidente significativo, notifica completa dell'incidente entro 72 ore, e report finale entro un mese. Per uno sviluppatore, questo significa che il sistema deve essere in grado di rilevare un incidente (monitoring e alerting attivi, non solo log passivi), che esiste una procedura documentata di escalation (chi chiama chi, in quale ordine, con quali informazioni), e che la documentazione dell'incidente viene raccolta automaticamente fin dal primo momento. Ho descritto il framework operativo per le prime 72 ore nel mio articolo dedicato alla gestione degli incidenti di sicurezza NIS2-ready su applicazioni Laravel e Symfony.

Gestione delle vulnerabilità. NIS2 richiede politiche e procedure per la gestione delle vulnerabilità, inclusa la disclosure responsabile. Per un'applicazione PHP, questo significa: aggiornamenti di sicurezza del framework e delle dipendenze applicati entro un tempo definito dalla disclosure (la best practice è 72 ore per le vulnerabilità critiche, 30 giorni per le medie), scanning automatico delle dipendenze con composer audit integrato nella pipeline CI/CD, e una policy documentata che descriva come l'azienda gestisce le segnalazioni di vulnerabilità ricevute dall'esterno. Nel mio profilo professionale trovi il dettaglio dell'esperienza che porto nell'adeguamento NIS2 di applicazioni web e infrastrutture - un'area dove la competenza tecnica e la comprensione normativa devono procedere insieme.

Il logging strutturato: cosa registrare e come conservarlo

Il requisito di logging di NIS2 non si soddisfa con un tail -f storage/logs/laravel.log. Serve un logging strutturato, centralizzato, tamper-evident e con retention policy definita. In Laravel, la configurazione base che implemento per la conformità NIS2 è:

// config/logging.php - canale dedicato alla sicurezza NIS2
'channels' => [
    'security' => [
        'driver' => 'daily',
        'path' => storage_path('logs/security.log'),
        'level' => 'info',
        'days' => 365,  // Retention 12 mesi per log di sicurezza
        'permission' => 0600,  // Solo root può leggere
    ],
],

// Middleware di audit logging per le operazioni sensibili
// app/Http/Middleware/SecurityAuditLog.php
class SecurityAuditLog
{
    public function handle(Request $request, Closure $next): Response
    {
        $response = $next($request);

        // Registra ogni operazione su route sensibili
        if ($request->routeIs('admin.*', 'api.payments.*', 'users.export')) {
            Log::channel('security')->info('audit', [
                'user_id' => $request->user()?->id,
                'action' => $request->method() . ' ' . $request->path(),
                'ip' => $request->ip(),
                'user_agent' => $request->userAgent(),
                'status' => $response->status(),
                'timestamp' => now()->toIso8601String(),
            ]);
        }

        return $response;
    }
}

Tre aspetti di questa configurazione sono rilevanti per la conformità. Il primo è la retention di 365 giorni: i log di sicurezza devono essere conservati abbastanza a lungo da supportare un'indagine che potrebbe iniziare mesi dopo l'incidente. Il secondo è il permesso 0600 sul file: i log di sicurezza contengono indirizzi IP, user ID e pattern di accesso che sono dati personali sotto GDPR - l'accesso deve essere limitato al personale autorizzato. Il terzo è la struttura JSON del log: un log strutturato è parsabile automaticamente da strumenti di analisi (ELK, Grafana Loki, CloudWatch), un log testuale non lo è - e la capacità di cercare "tutti gli accessi dall'IP X nelle ultime 72 ore" è essenziale durante un incidente.

Il logging degli errori di autenticazione è particolarmente critico. Un pattern di login falliti da un singolo IP (brute force), da IP diversi sullo stesso account (credential stuffing), o da un account che non fallisce mai ma accede in orari anomali (compromissione con credenziali valide) sono tutti segnali di incidente che il logging deve catturare e l'alerting deve notificare. Nel progetto per il cliente manifatturiero, ho configurato un alert che si attiva quando un singolo IP genera più di 10 login falliti in 5 minuti - un segnale di brute force che richiede l'attivazione della procedura di incident response. Ma il logging da solo non basta senza un meccanismo di centralizzazione: se i log risiedono solo sul server dell'applicazione e un attaccante compromette quel server, la prima cosa che farà è cancellare i log per coprire le proprie tracce. La soluzione è il forwarding in tempo reale dei log di sicurezza verso un server separato - un syslog remoto, un'istanza Grafana Loki su un VPS diverso, o un servizio cloud come AWS CloudWatch. Il log originale sul server applicativo è la prima copia; il log remoto è la copia forense che l'attaccante non può raggiungere senza compromettere un secondo sistema. Per il cliente manifatturiero, ho configurato rsyslog per inoltrare i log di sicurezza verso una Hetzner Storage Box dedicata con accesso in sola scrittura - il server applicativo può scrivere nuovi log ma non può cancellare o modificare quelli già inviati, garantendo l'integrità della catena di custodia per un'eventuale analisi forense post-incidente.

La documentazione: cosa devi produrre per dimostrare la conformità

NIS2 non richiede solo di implementare misure di sicurezza - richiede di dimostrare di averle implementate. In caso di audit o di incidente, devi essere in grado di produrre evidenze documentali delle misure adottate. Per un'applicazione web, i documenti minimi che preparo per ogni cliente sono:

• Policy di sicurezza dei sistemi informativi: descrive l'architettura dell'applicazione, i componenti di sicurezza (TLS, autenticazione, autorizzazione, crittografia), e le responsabilità del personale tecnico
• Procedura di incident response: chi fa cosa, con quali tempistiche, usando quali strumenti, e come vengono conservate le prove forensi. Include i template di notifica per CSIRT e Garante Privacy
• Registro delle vulnerabilità: log di tutte le vulnerabilità identificate, valutate e remediate, con timestamp e responsabile. Include l'output di composer audit archiviato ad ogni deploy
• Piano di backup e disaster recovery: documentazione delle procedure di backup, test di ripristino periodici (almeno trimestrali), e RTO/RPO definiti per ogni sistema critico
• Registro degli incidenti: log cronologico di ogni incidente di sicurezza gestito, con analisi delle cause e azioni correttive implementate. Anche se l'incidente è stato minore e non ha richiesto notifica, la registrazione è obbligatoria

Questa documentazione non deve essere un progetto da 200 pagine. Per il cliente manifatturiero, l'intero set documentale è composto da 5 documenti per un totale di 35 pagine - scritti in italiano comprensibile, non in legalese, con riferimenti agli articoli della direttiva per ogni sezione. La chiave è che i documenti riflettano ciò che l'azienda fa davvero, non ciò che "dovrebbe" fare: un documento che descrive procedure mai testate è peggio che inutile, perché crea un falso senso di conformità che crolla al primo audit.

Supply chain security: le dipendenze del tuo composer.json sono nel perimetro

Un aspetto di NIS2 che colpisce particolarmente gli sviluppatori è il requisito sulla sicurezza della catena di approvvigionamento (supply chain). L'articolo 21 comma 2 lettera d richiede misure sulla "sicurezza della catena di approvvigionamento, compresi gli aspetti relativi alla sicurezza riguardanti i rapporti tra ciascun soggetto e i suoi diretti fornitori." Per un'applicazione PHP, i "fornitori" includono: i pacchetti Composer (le dipendenze nel tuo composer.json), le immagini Docker che usi per il deployment, le librerie JavaScript nel frontend, e i servizi esterni (API di pagamento, provider email, CDN).

La misura minima che implemento è l'integrazione di composer audit nella pipeline CI/CD con blocco del deploy se vengono trovate vulnerabilità con severity alta o critica, il pinning delle versioni dei pacchetti (niente ^ o ~ per le dipendenze critiche - versione esatta), e la verifica dell'integrità dei pacchetti con composer.lock versionato nel repository. Ho descritto le misure più avanzate per la supply chain PHP nel mio articolo sulla sicurezza della supply chain con Composer per Laravel e Symfony, dove copro anche il typosquatting, la dependency confusion e la protezione contro gli script malevoli nel post-install-cmd.

La guida tecnica di ENISA per l'implementazione NIS2 fornisce esempi di evidenze accettabili per dimostrare la conformità sulla supply chain: inventario dei fornitori con valutazione del rischio, policy di gestione delle dipendenze software, e procedure di verifica dell'integrità dei componenti. Per una PMI con un'applicazione Laravel e 80 pacchetti Composer, questo si traduce in un file SBOM.json (Software Bill of Materials) generato automaticamente ad ogni release, archiviato nel repository, e consultabile in caso di audit.

La conformità NIS2 non è un progetto con una data di fine - è un processo continuo che richiede disciplina operativa quotidiana. La checklist di hardening NIS2-ready per applicazioni Laravel e Symfony che ho pubblicato è il punto di partenza per un'implementazione in 10-14 giorni, ma il mantenimento della conformità richiede review periodici delle misure, test degli incidenti simulati, aggiornamento della documentazione e formazione del personale. Se gestisci applicazioni web per un'azienda che rientra nel perimetro NIS2 e non sai da dove cominciare con l'adeguamento tecnico, contattami per un assessment di conformità: in due giornate di lavoro analizziamo la tua infrastruttura, identifichiamo le lacune rispetto ai requisiti della direttiva, e produciamo un piano di adeguamento con priorità, tempi e costi definiti.