Negli ultimi mesi ho lavorato a un plugin WordPress diverso dagli altri che ho scritto. Più tosto, più grande, più impegnativo. Si chiama db-secure-auth ed è arrivato al punto di maturità in cui può essere installato in ambiente reale per la prima volta. Vale la pena fermarsi a raccontare di cosa si tratta, perché esiste, e perché un docente di un istituto tecnico si è messo a scriverlo.

Il momento è particolare. Gli altri plugin che ho pubblicato risolvono problemi specifici: un costruttore di form, un gestore di cookie, un carosello di immagini, un simulatore PLC per la didattica. Sono applicativi, vivono nel proprio dominio, hanno una superficie API piccola. Questo no. Questo è infrastruttura, e tocca un punto sensibile: l’accesso ai sistemi informatici di scuole e Pubbliche Amministrazioni.

Il problema reale

L’autenticazione nelle scuole italiane è, in molti casi, ferma a vent’anni fa. Un docente entra nel portale interno con username e password generata dalla segreteria, magari condivisa via email in chiaro, magari mai cambiata. Il DSGA accede alle informazioni del personale dallo stesso account che usa per scrivere comunicazioni di servizio. Non c’è log di chi ha fatto cosa, non c’è secondo fattore, non c’è notifica se qualcuno entra dalla Russia alle tre di notte.

Le scuole che usano Google Workspace istituzionale — quasi tutte, ormai — avrebbero a portata di mano un’infrastruttura di autenticazione moderna. Account verificati, gestione gruppi, 2FA di dominio. Eppure il portale WordPress della scuola spesso non ne sfrutta nulla, perché collegare WordPress a Workspace via SSO richiede una configurazione tecnica che pochi sanno fare, e ancora meno la documentano.

Il risultato è che molte scuole italiane sono tecnicamente fuori dalle Linee guida AGID sulla sicurezza ICT della Pubblica Amministrazione. Non per cattiva volontà, ma perché manca uno strumento standard, gratuito, documentato e mantenuto, che metta insieme i pezzi.

A cosa risponde il plugin

Le necessità concrete che db-secure-auth affronta sono almeno sei, ognuna delle quali sarebbe abbastanza per giustificare un progetto a sé.

I requisiti di legge

La parte normativa è quella che più di tutto distingue questo plugin dai progetti applicativi. Quando si tratta sicurezza degli accessi, gli obblighi che si incrociano sono diversi, e non sempre tra loro coerenti.

GDPR (Reg. UE 2016/679)

Il plugin tratta dati personali — indirizzi IP, identificativi dispositivo, paesi di provenienza — che la sentenza CGUE Breyer e la giurisprudenza italiana consolidata qualificano come tali. Ogni trattamento richiede una base giuridica chiara: esecuzione di un compito di interesse pubblico per le PA (art. 6.1.e), legittimo interesse del Titolare per le misure di sicurezza (art. 6.1.f), adempimento di obblighi giuridici per il logging AGID (art. 6.1.c). Servono retention configurabile, diritti dell’interessato esercitabili, informativa adeguata, registro dei trattamenti aggiornato.

Linee guida AGID sulla sicurezza ICT delle PA

Le PA italiane sono soggette alle Linee guida AGID che impongono logging strutturato degli accessi, autenticazione forte per ruoli sensibili, gestione delle sessioni, step-up authentication su operazioni di approvazione. Il plugin è stato progettato esplicitamente per soddisfare questi requisiti senza richiedere ai dirigenti scolastici di diventare esperti di sicurezza informatica.

Statuto dei Lavoratori (L. 300/1970, art. 4)

L’art. 4 dello Statuto dei Lavoratori regola gli strumenti dai quali deriva controllo a distanza dell’attività dei lavoratori. Un sistema che logga ogni accesso del personale dipendente potrebbe configurarsi come tale, anche se la finalità è di sicurezza. Il comma 2 dell’art. 4 prevede però una eccezione per gli “strumenti di registrazione degli accessi”, dentro cui plausibilmente rientra questo plugin. La documentazione include un capitolo specifico su questo punto, con template di informativa al personale e indicazioni operative per il coinvolgimento delle RSU.

Trasferimenti extra-UE

Il flusso SSO Google comporta un trasferimento di dati personali verso Google LLC, USA. La base giuridica è il Data Privacy Framework ratificato nel 2023 (decisione di adeguatezza UE 2023/1795). La geolocalizzazione IP avviene tramite un servizio europeo (ip-api.com, Germania); è prevista una migrazione a database locale MaxMind GeoLite2 in v1.1 per eliminare ogni trasferimento esterno.

Le sfide tecniche

La sicurezza informatica è uno di quei campi in cui le scorciatoie si pagano sempre. Ogni decisione tecnica che ho preso durante lo sviluppo ha avuto una sua trafila di ragionamento. Riassumo le più significative.

Cifratura legata al contesto

I secret TOTP degli utenti sono cifrati con AES-256-GCM. Niente di nuovo. Quello che è meno banale è il binding al contesto: ogni ciphertext è legato al user_id e allo scopo ("user:42:totp") tramite Additional Authenticated Data. Se un attaccante ruba un secret cifrato dal database e prova a iniettarlo sul record di un altro utente, la decifratura fallisce. È una piccola precauzione che mitiga interi vettori di attacco.

La chiave di cifratura vive in wp-config.php, non nel database. Questa scelta architetturale, banale per chi conosce le best practice, è in realtà uno dei punti più sensibili: se la chiave viene persa o sovrascritta da un deploy automatico, tutti i secret TOTP diventano illeggibili. La documentazione dedica un capitolo intero alle procedure di key rotation e ai backup necessari.

Fingerprint dispositivo non invasivo

Per riconoscere un dispositivo già visto rispetto a uno nuovo non serve usare le tecniche di fingerprinting che tracciano l’utente attraverso i siti — canvas, WebGL, audio context, enumerazione font. Un hash SHA-256 di User-Agent + Accept-Language è sufficiente per la finalità dichiarata (riconoscere un dispositivo noto), proporzionato ai sensi GDPR, e non utilizzabile per profilazione cross-site. Le scelte di proporzionalità contano: anche quando una tecnica più aggressiva sarebbe legale, sceglierne una più mite è ciò che distingue un sistema progettato per servire l’utente da uno progettato per sorvegliarlo.

Fail-soft ovunque

Un plugin di sicurezza che genera un’eccezione PHP e lascia il sito con il white screen è peggio del problema che dovrebbe risolvere. Tutto il codice è scritto in modalità fail-soft: gli errori sono propagati come WP_Error o silenziati con action di notifica, mai sollevati come exception in produzione. Se un modulo si rompe, gli altri continuano a funzionare. Se la libreria Google non è installata, il modulo SSO si auto-disabilita invece di crashare. Se il geofencing non riesce a localizzare un IP, applica una policy conservativa (richiede secondo fattore) invece di permettere accesso libero o bloccare.

Step-up legato alla sessione

Lo step-up authentication apre una finestra di fiducia: una volta verificato il secondo fattore, l’utente può eseguire altre operazioni sensibili per 15 minuti senza nuovo prompt. La cosa interessante è che la finestra è legata al session token specifico: se l’utente si disconnette e si riconnette, la fiducia non si trasferisce. Questo previene scenari in cui un attaccante che ottiene una sessione separata erediterebbe lo step-up dell’utente legittimo.

Recovery senza scorciatoie

Cosa succede quando un utente perde il telefono e non ha i codici di backup? Cosa succede quando la chiave di cifratura viene compromessa? Quando un account amministratore è preso da terzi? La documentazione include una sezione dedicata a queste procedure operative, con i comandi WP-CLI esatti da eseguire e l’ordine in cui farlo. Non sono note a margine: sono parte integrante del prodotto. Un sistema di sicurezza è valido tanto quanto le sue procedure di recovery.

Le scelte progettuali

Oltre alla parte tecnica e normativa, ci sono state scelte di impostazione che hanno orientato l’intero sviluppo.

Infrastruttura, non applicazione

Il plugin non implementa logica di dominio. Non c’è codice specifico per la scuola, per la PA, per il museo. db-secure-auth risponde alla domanda “chi sei, da dove?”. Il plugin applicativo che lo userà (nel mio caso, db-area-personale per il portale CBG) risponde alla domanda “cosa puoi fare?”. I due comunicano tramite hook standard WordPress. Questa separazione permette di:

• Riutilizzare il blocco auth in progetti diversi senza copia-incolla.
• Auditare indipendentemente la superficie di sicurezza, che ha dipendenze chiare e logiche dedicate.
• Pubblicare il plugin come open source senza esporre la logica applicativa specifica di un’organizzazione.

Zero dipendenze esterne obbligatorie

L’unica dipendenza non opzionale è la libreria standard di PHP. Google API Client è installata di default ma il modulo SSO si auto-disabilita se manca. Action Scheduler gestisce i job periodici ma il plugin funziona anche senza (perdendo solo il cleanup automatico del log). Questa scelta protegge il progetto dalla dependency hell tipica di molti plugin WordPress: meno dipendenze esterne significa meno breakage, meno aggiornamenti obbligati, meno superficie di attacco.

La documentazione è parte del prodotto

Il plugin è accompagnato da sette documenti markdown, per un totale di circa cinquemilacinquecento righe e ventiseimila parole. Architettura, riferimento API, schema database, deployment, configurazione SSO, privacy e GDPR, procedure di recovery. Non sono note tecniche scarne: ogni documento copre il proprio ambito in profondità, con esempi di codice, diagrammi, template di informativa, query SQL utili. Per un plugin di sicurezza che vuole essere installato in contesti istituzionali questa è una scelta non negoziabile: chi installa deve sapere esattamente cosa sta facendo, e chi prende decisioni di compliance deve avere il materiale per farlo.

Trecentocinquantasette test

La suite di test è scritta in PHP nativo, senza dipendenze da framework esterni. Gira in meno di un secondo, sul mio Mac. Copre i 12 moduli con asserzioni mirate alla logica di sicurezza (cifratura, validazione token, anti-replay, capability check, sanitizzazione). Non testo il rendering HTML perché è cosmetico, ma testo ogni singolo path decisionale rilevante per la sicurezza. Quando dovrò pubblicare un fix o una nuova feature, avere la regression suite a posto fa la differenza tra un release pulito e una crisi.

Cosa succede ora

Il plugin è arrivato al punto di maturità in cui i 12 moduli sono tutti funzionali, la documentazione è completa, il tooling di sviluppo (composer, phpcs, gitignore, gitattributes) è in posto, e i README sono allineati ai numeri reali. Quello che ancora non c’è è il collaudo in produzione su un sito reale. Il prossimo passaggio è esattamente questo: installarlo sul portale CBG, in ambiente di staging prima e di produzione poi, e tenerlo sotto osservazione per alcune settimane.

Da lì in poi vedremo. Una scuola di Torino mi ha chiesto una consulenza qualche tempo fa, e potrebbe diventare il secondo caso pilota. Se la diffusione cresce, si apre la possibilità — non garantita, ma legittima — di proporlo come plugin companion alla community AGID che mantiene il tema WordPress per le scuole. Sarebbe una strada lunga e non scontata, ma il percorso è chiaro: prima far girare il plugin in produzione, poi documentare i casi d’uso, poi presentare il lavoro sul Forum Italia e nei canali della community.

Una nota personale

Quando ho iniziato a scrivere plugin WordPress qualche anno fa, l’obiettivo era risolvere problemi concreti che incontravo nel mio lavoro quotidiano di docente e referente ICT. Form, cookie, gallerie, simulatori didattici. Strumenti utili, mantenuti con cura, ma circoscritti. Questo plugin è diverso. È il primo che si confronta con un dominio in cui le scelte tecniche hanno conseguenze immediate sulla sicurezza di persone reali — colleghi, studenti, segreteria, dirigenti — e in cui la complessità normativa richiede la stessa attenzione di quella tecnica.

Non sono un consulente di sicurezza informatica e non pretendo di esserlo. Sono un ingegnere elettronico che insegna in un istituto tecnico, che ha studiato a fondo il problema, che ha scritto codice testabile e documentazione seria, e che ora si appresta a metterlo in produzione e vedere cosa succede. Se altri vorranno usarlo, criticarlo, migliorarlo, segnalarne i difetti — bene, è esattamente per questo che sarà open source. Se servirà a una sola altra scuola, oltre alla mia, avrà già giustificato il tempo che ci ho messo.

Le cose si fanno serie, appunto.