// Indice
1 Premessa e ambito di applicazione
La Direttiva (UE) 2022/2555, nota come NIS2 (Network and Information Security 2), e il relativo recepimento italiano con il D.Lgs. 4 settembre 2024, n. 138, stabiliscono un quadro normativo rafforzato per garantire un livello elevato di cybersecurity in tutta l'Unione Europea.
La Direttiva NIS2 si applica ai soggetti essenziali e importanti operanti in settori critici quali energia, trasporti, sanita, infrastrutture digitali, pubblica amministrazione, servizi ICT gestiti (managed services) e altri ambiti elencati negli Allegati I e II della Direttiva.
reCoding e una piattaforma didattica e ambiente di sviluppo web cloud destinata prevalentemente all'uso educativo. Pur non rientrando necessariamente tra i soggetti direttamente obbligati dalla NIS2, reCoding adotta volontariamente misure di sicurezza allineate ai principi e alle best practice della Direttiva, a dimostrazione dell'impegno concreto verso la protezione dei dati e delle infrastrutture a servizio dei propri utenti.
La presente informativa descrive le misure organizzative e tecniche implementate da reCoding, con riferimento in particolare all'Art. 21 della Direttiva NIS2 (Misure di gestione dei rischi di cybersecurity) e agli articoli corrispondenti del D.Lgs. 138/2024.
2 Governance della sicurezza
La governance della sicurezza informatica di reCoding si basa su un modello strutturato che prevede:
# Responsabile della sicurezza
E stato designato un responsabile della sicurezza informatica che supervisiona l'implementazione delle policy, coordina la risposta agli incidenti e mantiene aggiornata la documentazione di sicurezza. Il responsabile riferisce direttamente alla direzione della piattaforma.
# Valutazione periodica dei rischi
Viene condotta una valutazione periodica dei rischi informatici che considera le minacce emergenti, le vulnerabilita dell'infrastruttura, l'impatto potenziale sugli utenti e la probabilita di occorrenza. I risultati della valutazione informano le priorita di intervento e gli investimenti in sicurezza.
# Piano di risposta agli incidenti
E stato predisposto un Incident Response Plan (IRP) che definisce ruoli, responsabilita, procedure di escalation, canali di comunicazione e tempistiche per la gestione degli incidenti di sicurezza, in conformita con le indicazioni dell'Art. 23 NIS2.
3 Misure tecniche di sicurezza
In conformita con l'Art. 21 della Direttiva NIS2, reCoding implementa le seguenti misure tecniche proporzionate al rischio e allo stato dell'arte tecnologico.
Isolamento e sandboxing
Ogni utente opera in un ambiente isolato per prevenire interferenze e accessi non autorizzati alle risorse di altri utenti.
Bubblewrap (bwrap)
Sandbox Linux con namespace PID e IPC isolati, filesystem root read-only, home utente come unico spazio scrivibile. Massimo livello di isolamento per i terminali.
Art. 21(2)(a) NIS2Jail fallback
Su sistemi senza bubblewrap, una shell jail con override dei comandi di navigazione impedisce la fuga dalla home directory dell'utente.
Art. 21(2)(a) NIS2Nessun accesso privilegiato
Gli utenti normali non dispongono di privilegi amministrativi. Il principio del minimo privilegio e applicato a tutti i livelli dell'architettura.
Art. 21(2)(i) NIS2Crittografia
Le comunicazioni e i dati sensibili sono protetti con algoritmi crittografici allo stato dell'arte.
Crittografia E2E nella chat
Il sistema di messaggistica implementa crittografia end-to-end con chiavi per utente e salt dedicato, garantendo che solo mittente e destinatario possano leggere i messaggi.
AES-256-CBC e scrypt
I PIN di blocco desktop sono cifrati con AES-256-CBC. Le password degli utenti sono sottoposte a hashing con crypto.scrypt, resistente ad attacchi brute-force e rainbow table.
HTTPS/TLS e WSS
Tutte le comunicazioni client-server transitano su HTTPS con certificato TLS gestito da Nginx. Le connessioni WebSocket utilizzano il protocollo WSS (WebSocket Secure).
Controllo degli accessi
L'accesso alla piattaforma e regolato da un sistema multilivello che previene accessi non autorizzati.
Autenticazione multi-fattore
Login con password seguita da verifica OTP via email. Doppio fattore di autenticazione per garantire l'identita dell'utente.
Sessioni con scadenza
Le sessioni hanno una durata massima di 24 ore, persistite su MySQL per sopravvivere ai restart del server senza compromettere la sicurezza.
Tre ruoli separati
Sistema RBAC con ruoli user, docente e admin, ciascuno con permessi specifici e accesso limitato alle funzionalita pertinenti.
Approvazione manuale
Ogni nuova registrazione richiede l'approvazione esplicita dell'amministratore prima che l'utente possa accedere alla piattaforma, prevenendo accessi non controllati.
Protezione applicativa
Misure di sicurezza a livello applicativo per contrastare le principali minacce OWASP e proteggere l'integrita dei dati.
Protezione CSRF
Validazione dell'header Origin e Referer su tutte le richieste mutative, con whitelist degli origin autorizzati (ALLOWED_ORIGINS).
Rate limiting
Limitazione della frequenza delle richieste sugli endpoint sensibili: login, verifica OTP, upload file e upload chat, con key generator personalizzati per IP.
Sanitizzazione input
Nomi file sanitizzati con sanitizeFileName(). Tutte le query SQL utilizzano prepared statements per prevenire SQL injection.
Anti path-traversal
Ogni percorso file e validato con resolveUserPath() e fs.promises.realpath(), con controlli anti-symlink via lstat.
Isolamento delle risorse per utente
Ogni utente dispone di risorse dedicate e completamente isolate dagli altri utenti della piattaforma.
Database MySQL dedicato
Ogni utente approvato riceve un database MySQL proprio con credenziali univoche, accessibile tramite Adminer. Nessun utente puo accedere ai dati di un altro.
Pool PHP-FPM per utente
Ogni utente ha un pool PHP-FPM dedicato con UID/GID Linux reale e open_basedir limitato alla propria home directory, con funzioni pericolose disabilitate.
code-server isolato
Le istanze VS Code nel browser (code-server) vengono eseguite con UID/GID separati per utente, su porte TCP dedicate, con idle timeout automatico.
Monitoraggio e logging
Un sistema di logging completo consente la tracciabilita di tutte le operazioni e facilita l'analisi forense in caso di incidenti.
📊 Logging completo con severity
Tutte le operazioni utente vengono registrate nel database con livello di severity (info, warn, error). I tipi di evento tracciati includono: registrazione, login, logout, comandi terminale, operazioni file (upload, download, creazione, eliminazione, rinomina), join e consegna verifiche, messaggi chat, operazioni portfolio, quiz, condivisioni file e utilizzo app. I comandi eseguiti nel terminale sono registrati per consentire audit post-incidente.
Protezione dell'infrastruttura
Nginx reverse proxy con SSL
Nginx gestisce la terminazione SSL, il reverse proxy verso Express e gli upgrade WebSocket, fornendo un ulteriore livello di sicurezza perimetrale.
WebSocket autenticato
L'upgrade WebSocket verifica la sessione utente prima di stabilire la connessione, prevenendo accessi non autorizzati al terminale e alla chat.
Funzioni PHP pericolose disabilitate
I pool PHP-FPM disabilitano le funzioni di sistema potenzialmente pericolose, limitando la superficie di attacco anche in caso di vulnerabilita nel codice utente.
4 Gestione delle vulnerabilita
In conformita con l'Art. 21(2)(e) della Direttiva NIS2, reCoding adotta un approccio proattivo alla gestione delle vulnerabilita:
- Aggiornamento periodico delle dipendenze — Le 18 dipendenze npm del progetto vengono aggiornate regolarmente. Le advisory di sicurezza vengono monitorate tramite
npm audite i bollettini CVE dei singoli pacchetti. - Monitoraggio CVE — I componenti critici dell'infrastruttura (Node.js, MySQL, Nginx, PHP-FPM, bubblewrap) sono monitorati per la pubblicazione di nuove CVE, con aggiornamento tempestivo in caso di vulnerabilita critiche.
- Principio di minima superficie — L'architettura utilizza solo le dipendenze strettamente necessarie, riducendo la superficie di attacco. Non vengono inclusi pacchetti non essenziali.
- Revisione del codice — Le modifiche al codice sorgente sono sottoposte a revisione prima del deployment in produzione, con particolare attenzione alle implicazioni di sicurezza.
5 Gestione degli incidenti
In conformita con l'Art. 23 della Direttiva NIS2 e gli articoli corrispondenti del D.Lgs. 138/2024, reCoding ha definito procedure di gestione degli incidenti di sicurezza:
🚨 Procedura di notifica
- Rilevamento e classificazione — Ogni anomalia viene valutata per determinare se costituisce un incidente significativo ai sensi della NIS2.
- Notifica iniziale entro 24 ore — In caso di incidente significativo, viene inviata una notifica preliminare all'ACN (Agenzia per la Cybersicurezza Nazionale) entro 24 ore dal rilevamento, ove applicabile.
- Notifica completa entro 72 ore — Una notifica dettagliata con valutazione iniziale dell'incidente, della sua gravita e del suo impatto viene trasmessa entro 72 ore.
- Relazione finale entro 1 mese — Una relazione conclusiva con descrizione dettagliata dell'incidente, le cause, le misure di mitigazione adottate e l'impatto transfrontaliero eventuale.
📢 Comunicazione agli utenti
In caso di incidente che comporti un rischio per i dati o la sicurezza degli utenti, reCoding si impegna a comunicare tempestivamente agli utenti interessati la natura dell'incidente, i potenziali impatti e le azioni consigliate per mitigare i rischi, attraverso email e notifiche sulla piattaforma.
6 Continuita operativa
In conformita con l'Art. 21(2)(c) della Direttiva NIS2, reCoding implementa misure per garantire la continuita dei servizi:
Strategia di backup
Backup periodici del database MySQL e delle home directory degli utenti, con retention policy definita e test di ripristino regolari.
Graceful shutdown
Il server gestisce i segnali SIGTERM e SIGINT con shutdown ordinato: chiusura delle istanze code-server, terminazione delle connessioni WebSocket e salvataggio dello stato.
Persistenza delle sessioni
Le sessioni utente sono persistite su MySQL tramite express-mysql-session, garantendo che un restart del server non comporti la disconnessione degli utenti attivi.
7 Sicurezza della supply chain
In conformita con l'Art. 21(2)(d) della Direttiva NIS2, reCoding presta particolare attenzione alla sicurezza della catena di fornitura software:
La piattaforma utilizza 18 dipendenze npm note, documentate e attivamente mantenute. Ogni dipendenza e stata selezionata per necessita specifica e viene monitorata per vulnerabilita note.
- Dipendenze minime — Il principio di necessita guida la selezione: solo pacchetti indispensabili vengono inclusi. Non sono presenti dipendenze orfane o non mantenute.
- Pacchetti noti e affidabili — Le dipendenze core (
express,mysql2,ws,node-pty,sharp, ecc.) sono progetti open source con ampia adozione e community attiva. - Lock file — Il file
package-lock.jsongarantisce la riproducibilita delle build e previene l'introduzione di versioni non verificate. - Audit periodico — Esecuzione regolare di
npm auditper identificare e risolvere vulnerabilita nelle dipendenze dirette e transitive.
8 Formazione e sensibilizzazione
In conformita con l'Art. 21(2)(g) della Direttiva NIS2, reCoding promuove la consapevolezza sulla sicurezza informatica:
- Sensibilizzazione utenti — Gli utenti sono informati sulle best practice di sicurezza attraverso la documentazione della piattaforma, incluse le presenti informative.
- Convenzioni scolastiche — Il sistema di convenzioni scolastiche integrato definisce regolamenti e norme comportamentali per l'uso responsabile della piattaforma in ambito educativo.
- Ambiente didattico sicuro — Il sistema di verifiche scritte con lockdown desktop, monitoraggio heartbeat e logging completo insegna agli studenti l'importanza dell'integrita e della sicurezza negli ambienti digitali.
- Separazione dei ruoli — La struttura a tre ruoli (user, docente, admin) familiarizza gli utenti con il concetto di controllo degli accessi basato sui ruoli (RBAC), principio fondamentale della cybersecurity.
9 Diritti degli utenti
reCoding garantisce trasparenza sulle misure di sicurezza adottate e riconosce i seguenti diritti agli utenti:
- Diritto di informazione — Gli utenti hanno diritto a conoscere le misure di sicurezza implementate a protezione dei loro dati e delle loro risorse. La presente informativa assolve a questo scopo.
- Segnalazione vulnerabilita — Gli utenti sono invitati a segnalare eventuali vulnerabilita o anomalie riscontrate nella piattaforma tramite i contatti indicati nella sezione successiva. Ogni segnalazione viene valutata e, se confermata, risolta nel piu breve tempo possibile.
- Accesso ai log — Gli utenti possono richiedere informazioni sulle attivita registrate a loro carico nel sistema di logging.
- Notifica in caso di incidente — Come descritto nella sezione 5, gli utenti vengono notificati tempestivamente in caso di incidenti che possano coinvolgere i loro dati.
Per l'esercizio dei diritti relativi alla protezione dei dati personali (accesso, rettifica, cancellazione, portabilita), si rimanda all'Informativa Privacy della piattaforma.
10 Contatti sicurezza
Per segnalazioni di vulnerabilita, domande sulle misure di sicurezza o richieste di informazioni relative alla presente informativa:
Responsabile Sicurezza Informatica
Piattaforma reCoding
Le segnalazioni di vulnerabilita vengono gestite con la massima priorita e riservatezza.
11 Data di aggiornamento
La presente informativa viene riesaminata e aggiornata periodicamente per riflettere l'evoluzione delle misure di sicurezza, delle normative applicabili e delle minacce emergenti.
Riferimenti normativi: Direttiva (UE) 2022/2555 (NIS2) · D.Lgs. 4 settembre 2024, n. 138 · Regolamento (UE) 2016/679 (GDPR) · D.Lgs. 196/2003 (Codice Privacy)