Sto costruendo Miraviso, un SaaS per saloni di parrucchieri. La maggior parte dei suoi dati è noiosa: appuntamenti, preferenze sui prodotti, storico delle visite. Ma una parte non è noiosa per niente: le note sui clienti possono contenere allergie e patologie del cuoio capelluto. Sono dati al confine col sanitario, su persone che non si sono mai registrate al mio servizio — sono i clienti dei miei clienti.
L'approccio standard è cifratura at rest più TLS e una privacy policy. Ho deciso che per questo campo specifico non bastava, e il motivo è l'onestà sul modello di minaccia: la cifratura at rest protegge da chi ruba il disco. Non fa niente contro i rischi più realistici — un application server compromesso, un pannello di amministrazione che perde dati, una richiesta dell'autorità, o una mia query sbagliata. In tutti quegli scenari l'applicazione può decifrare tutto, quindi anche l'attaccante (o l'errore) può.
Il design a buste
Per le note sensibili, quindi, Miraviso fa una cosa diversa: la chiave di cifratura è derivata sul dispositivo del salone e non raggiunge mai il server. Il client cifra la nota in locale e spedisce un blob opaco — una busta sigillata. Il server conserva buste che non può aprire. Non "non vuole aprire": non può.
Non è end-to-end encryption dell'intero prodotto, e voglio essere preciso su questo. Appuntamenti, agenda, fatturazione — tutto quello viene elaborato lato server come in qualunque SaaS normale, perché è ciò che fa funzionare il prodotto. Il trattamento a busta si applica specificamente ai campi in cui il server non ha alcun bisogno legittimo di vedere il testo in chiaro, mai. Per quei campi il lavoro del server è conservare e sincronizzare, nient'altro.
Cosa ti costa
Questo design ha costi reali e permanenti, e chiunque lo stia valutando dovrebbe guardarli bene prima di impegnarsi.
Niente ricerca lato server. Non posso offrire "trova tutti i clienti con l'allergia X" come funzione del server, perché il server non sa cosa c'è nelle buste. Qualunque filtro sulle note sensibili deve avvenire lato client, dopo la decifratura sul dispositivo. Per la clientela di un salone va bene; a una scala diversa potrebbe non andare.
La gestione delle chiavi diventa un problema di prodotto, non solo di sicurezza. Se la chiave è derivata sul dispositivo, devi rispondere a una domanda: cosa succede quando il salone cambia tablet? I flussi di smarrimento del dispositivo e recupero della chiave vanno progettati come UX di prima classe, non come ripensamento — sbaglia questo e "il server non può leggerle" diventa "non può leggerle nessuno".
Niente scorciatoie operative lato server. Il supporto non può sbirciare in una nota per aiutare un utente confuso. Le migrazioni che toccano campi cifrati richiedono la partecipazione del client. Stai rinunciando alle scorciatoie operative di proposito.
Perché per questo campo ne vale la pena
Tre ragioni. Primo, l'impatto di un breach: se il mio database finisce in giro, i dati più dannosi che contiene sono illeggibili. Il titolo di giornale peggiore diventa strutturalmente più piccolo. Secondo, la postura GDPR: per dati al confine con le categorie particolari, poter dire "architetturalmente non possiamo accedervi" è una posizione molto più forte di "abbiamo delle policy". Terzo — ed è quella che avevo sottovalutato — è un argomento di vendita. Il titolare di un salone capisce al volo "nemmeno noi possiamo leggere le note sanitarie dei tuoi clienti". È una delle poche proprietà di sicurezza che puoi spiegare a un acquirente non tecnico in una frase.
Il pattern generale
La lezione non è "cifra tutto lato client" — quello ammazza gran parte di ciò che rende utile un SaaS. La lezione è segmentare il modello dati in base a chi ha davvero bisogno del testo in chiaro. La maggior parte dei campi: il server ne ha bisogno, elabora normalmente, proteggi in modo convenzionale. Un piccolo insieme di campi: il server non ne ha mai bisogno, quindi rendilo incapace di leggerli, e accetta il costo in funzionalità esattamente su quei campi.
In Miraviso la stessa segmentazione si ripresenta altrove: la prova colore AI gira interamente sul dispositivo, mentre l'anteprima del taglio gira su server in UE previo consenso e non viene mai scritta su disco. Dati diversi, trattamenti diversi, ognuno dichiarato per quello che è. Di quello che costruisco trovi di più in home page.
Se stai costruendo un SaaS verticale che tocca dati sensibili — sanità, legale, finanza — questa onestà campo per campo è, nella mia esperienza, sia la scelta ingegneristica giusta sia un vantaggio competitivo sottovalutato.