Privacy e sicurezza by design, in pratica: le scelte (e i compromessi) dietro un sito reale

I principi si raccontano facilmente: minimizzare, conservare poco, chiudere gli accessi, prevenire le iniezioni. È nella traduzione tecnica che si vede se erano parole o scelte. Questo articolo prende un sito reale, questo, e mostra come ogni principio è diventato una decisione concreta. Con un'avvertenza che separa una guida da una referenza seria: niente è "perfetto e immobile". Ci sono compromessi, e ci sono difese che vanno verificate, non dichiarate. Quindi accanto a ogni scelta c'è anche cosa si perde, cosa si rifiuta senza appello, e cosa dipende dal contesto.

Raccogliere meno, e dirlo

Il punto di partenza non è "come proteggere i dati raccolti", ma "di quali dati c'è davvero bisogno". Il form di contatto chiede due cose obbligatorie: un'email per rispondere e il messaggio. Niente telefono, nessuna profilazione, nome e azienda facoltativi. Un campo che non si raccoglie non va protetto, non si perde in una violazione, non si conserva. La conservazione è decisa all'inizio: non oltre dodici mesi, poi cancellazione.

Minimizzare non esime dalla trasparenza. Sotto il form c'è il consenso e il link inequivocabile all'informativa, che dichiara finalità, base giuridica e tempi. L'obbligo di informativa previsto dall'art. 13 del GDPR (Regolamento UE 2016/679) resta, anche quando i dati sono pochi.

Poi c'è lo spam, e qui una distinzione netta. La reazione istintiva è il reCAPTCHA di Google: va rifiutato senza appello, perché inietta cookie e traccia l'utente, cioè distrugge esattamente la privacy che si sta costruendo. Una difesa che vanifica lo scopo non è una difesa. L'alternativa, privacy-preserving, è una combinazione: un campo honeypot (una casella invisibile che gli umani non vedono e i bot riempiono: se è valorizzata, è un bot e si scarta), un rate-limit per IP, e il filtro al bordo del reverse proxy.

Per un form a basso traffico questa combinazione è sufficiente. Se un domani lo spam diventasse un problema serio, c'è un gradino in più, comunque rispettoso della privacy: i sistemi a Proof of Work, come Altcha, che fanno eseguire al browser un piccolo calcolo prima dell'invio. In questo modo l'invio automatico di massa diventa costoso per il bot, senza terze parti e senza tracciare nessuno. La differenza con il reCAPTCHA è netta: il reCAPTCHA si rifiuta per principio, perché viola la privacy in ogni caso; il Proof of Work non si rifiuta affatto, semplicemente oggi non serve. È una scelta che dipende dal contesto, non un rifiuto di principio.

Statistiche senza cookie, e la verità sull'indirizzo IP

La maggior parte dei siti misura il traffico con uno strumento che installa cookie e carica script di terze parti. Quei due ingredienti obbligano al banner e mandano i dati dei visitatori a un fornitore esterno. Qui le statistiche si ricavano dai log d'accesso del reverse proxy, analizzati con uno strumento open source. Nessuno script nel browser, nessun cookie, nessuna terza parte: niente da consentire, quindi niente banner.

Servono però due ammissioni oneste, perché un lettore tecnico le conosce.

Primo, il compromesso. Senza un identificativo di sessione, il conteggio dei "visitatori unici" è una stima, non una misura chirurgica. E i log di un proxy sono pieni di bot e scanner. Si accetta una metrica meno precisa in cambio di privacy e leggerezza totali. È una scelta dichiarata, non un limite nascosto.

Secondo, l'obiezione più importante, da anticipare: "l'indirizzo IP è un dato personale; chiamarlo 'anonimizzato' mentre lo si scrive in chiaro sul disco non torna". È corretta a metà, ed è il punto da chiarire bene.

• Che l'IP sia un dato personale è pacifico: lo ha stabilito la Corte di Giustizia dell'Unione Europea con la sentenza Breyer (causa C-582/14, 19 ottobre 2016). La pronuncia fu resa sotto la precedente Direttiva 95/46/CE, ma il principio è rimasto valido sotto il GDPR.
• L'obiezione successiva, "allora va troncato alla sorgente, nel reverse proxy, prima di scriverlo su disco", qui non si può accogliere, e non per pigrizia. La difesa anti-abuso di questo sito banna gli IP malevoli (scanner, tentativi di forzatura): per bannare un IP, serve conoscere l'IP reale. Troncandolo alla sorgente la sicurezza diventa cieca, o finisce per bannare interi blocchi colpendo utenti innocenti. Su un sito senza una difesa basata sull'IP, e con sola finalità statistica, troncare alla sorgente sarebbe invece la scelta giusta: è una questione di contesto.
• E tenere l'IP per questo scopo non è un abuso, è una finalità che la legge riconosce espressamente. Il Considerando 49 del GDPR (Regolamento UE 2016/679), una premessa interpretativa del regolamento e non un articolo, stabilisce che trattare dati personali, nella misura strettamente necessaria e proporzionata, per garantire la sicurezza delle reti e dei sistemi informativi, prevenendo accessi non autorizzati e bloccando attacchi come i "denial of service", costituisce un legittimo interesse del titolare. È esattamente ciò che fa il ban di un IP che sta scansionando o forzando il sito. La base giuridica operativa è l'art. 6, paragrafo 1, lettera f), dello stesso regolamento; il Considerando 49 ne è la conferma interpretativa.
• La soluzione corretta, quindi, non è il troncamento cieco, è la separazione delle finalità. L'IP pieno vive nel log di sicurezza, per il tempo strettamente necessario (qui trenta giorni). Il report statistico, che è una finalità diversa, non mostra mai l'IP del singolo: lo maschera (ultimo ottetto azzerato) e aggrega.

Quindi l'IP non sparisce del tutto, perché la sicurezza lo richiede; ma è confinato (log di sicurezza), limitato nel tempo (trenta giorni), giustificato (art. 6, par. 1, lett. f), del GDPR, letto alla luce del Considerando 49 dello stesso regolamento) e mai esposto come dato individuale nelle statistiche. Questa è privacy by design fatta sul serio: non "zero dati a ogni costo", ma il minimo dato necessario, per il minimo tempo, con la base giuridica giusta.

La porta blindata, e l'allarme

Una delle vie più comuni per attaccare un sito è iniettare uno script che non dovrebbe esserci. La Content Security Policy è la porta blindata: dice al browser quali script può eseguire e blocca gli altri. Qui la CSP usa un nonce per richiesta (un valore casuale che il browser pretende su ogni script) con strict-dynamic, la regola più stretta: vale solo il nonce, non l'origine. Il 'self' resta come ripiego per i browser più vecchi che non capiscono la CSP di terza generazione; quelli moderni lo ignorano e si fidano solo del nonce.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-<casuale-per-richiesta>' 'strict-dynamic';
  object-src 'none'; base-uri 'none'; frame-ancestors 'none';
  report-to csp-endpoint

Ma una porta blindata "cieca" è metà lavoro. Se qualcuno tenta un'iniezione, o se uno script legittimo si rompe dopo un aggiornamento, come lo si scopre? Per questo la CSP qui non solo previene, ma segnala: le direttive report-to e report-uri dicono al browser di inviare un report ogni volta che blocca qualcosa, a un endpoint che lo registra. Da "porta chiusa al buio" a "porta chiusa con allarme".

Qui va prevenuto un equivoco frequente: questi report non servono a bannare l'attaccante. Arrivano dal browser della vittima (è il suo browser a bloccare e a segnalare), non dell'attaccante, e sono rumorosi (estensioni, antivirus) e falsificabili. Sono uno strumento di diagnosi, non di cattura: il ban avviene altrove, dove si vede l'IP reale di chi attacca. E poiché l'endpoint che raccoglie i report è pubblico e senza autenticazione, è stato indurito di conseguenza (limite di dimensione del corpo, rate-limit, sanificazione dei valori contro il log-injection). Come si verifica tutto questo è il punto più avanti.

Log senza dati personali, e come si fa debugging lo stesso

I log servono a far funzionare e difendere un sito, ma sono il punto dove i dati personali si accumulano in silenzio. Qui non si scrive mai nei log il contenuto di un messaggio o un dato personale; e i log tecnici si conservano trenta giorni, poi vengono ruotati via.

La domanda giusta di chi ha gestito sistemi è: come si isola la richiesta di un utente che segnala un errore, se nei log la sua email non c'è? La risposta è un correlation id: a ogni errore si genera un codice breve, non segreto, mostrato all'utente e scritto nel log accanto al motivo tecnico. L'utente cita il codice, lo sviluppatore ritrova la richiesta. Diagnosi completa, zero dati personali nei log. È la quintessenza della privacy by design applicata all'osservabilità.

Difesa al bordo e segreti: dove fermarsi

Prima ancora dell'applicazione, il reverse proxy filtra: i percorsi-trappola che gli scanner cercano a tappeto ricevono un blocco secco, i metodi HTTP non necessari sono rifiutati, e c'è un limite alla dimensione del corpo richiesta per tagliare i payload enormi. Meno superficie, meno rumore.

I segreti non vivono mai nel codice né nell'immagine del container: esistono solo come variabili d'ambiente iniettate all'avvio. Qui un lettore esperto obietta, giustamente, che le variabili d'ambiente non sono il massimo: possono finire in un crash dump o essere lette da chi ha accesso al container. Vero, e la risposta è la proporzionalità, non il cargo-cult. Montare un Secret Manager su un singolo server è una complessità, e una nuova superficie d'attacco, sproporzionata rispetto al guadagno: ha senso a scala multi-servizio, in team, con orchestrazione e audit. Il passo intermedio, quando si aggiungono servizi, è montare i segreti come file effimeri invece che nell'environment del processo. Dire "ecco dove è giusto fermarsi, ed ecco dove si andrebbe oltre" è più maturo che applicare lo strumento più grande a prescindere.

Due note che spesso mancano. Il form usa i Server Action del framework, che fanno il controllo CSRF nativamente (confronto dell'origine): non serve reinventarlo. E non serve la Subresource Integrity, perché non si caricano risorse di terze parti: i font e tutto il resto sono ospitati sul dominio. Il problema migliore è quello che si elimina alla radice.

Le difese si verificano, non si dichiarano

C'è una differenza tra scrivere "l'endpoint è sicuro" e dimostrarlo. Il raccoglitore dei report CSP, essendo pubblico, è stato attaccato di proposito: una richiesta col metodo sbagliato riceve un secco rifiuto, un corpo enorme viene scartato prima ancora di leggerlo, un tentativo di iniettare righe di log finte viene neutralizzato (gli a-capo diventano spazi, niente voci di log forgiate), un flusso di richieste ravvicinate viene limitato. Ogni difesa è stata messa alla prova, non solo scritta. È questo che distingue un sistema robusto da uno che sembra robusto.

La checklist, in breve

• Raccogliere solo i dati indispensabili; ogni campo in più è un rischio in più.
• Decidere la scadenza all'inizio e automatizzare la cancellazione.
• Misurare senza cookie e senza terze parti, ammettendo il compromesso sulla precisione.
• Tenere l'IP solo dove serve (sicurezza), per il minimo tempo, con la base giuridica giusta; mascherarlo nelle statistiche.
• CSP a nonce per prevenire, report per accorgersi; mai bannare sui report.
• Niente dati personali nei log; un correlation id per il debug.
• Filtrare al bordo, segreti fuori dal codice; strumento proporzionato alla scala.
• Verificare le difese, non dichiararle.

Non è un costo, è un sistema migliore (e onesto)

Costruire così non rallenta: un sito che raccoglie meno ha meno da proteggere, uno senza tracciamento è più veloce, una CSP stretta con allarme resiste e avvisa. La privacy e la sicurezza by design non sono un vincolo da subire alla fine, ma il punto di partenza che rende tutto il resto più semplice. E la versione matura non è quella che si dichiara perfetta: è quella che dichiara cosa accetta come compromesso, cosa rifiuta e perché, e dove andrebbe oltre. Questo sito è quella versione.

Per i principi generali da cui questo articolo parte:

Privacy by design: cos'è e come si applica davvero