Trovare i dati personali che il pattern matching non vede

Cosa fa molto bene il pattern matching

Le espressioni regolari sono eccellenti nel trovare dati personali dalla forma prevedibile. Un numero di previdenza sociale ha un raggruppamento di cifre fisso. Una carta di pagamento ha una lunghezza fissa e supera un controllo di checksum. Indirizzi email, numeri di telefono, indirizzi IP, riferimenti di conto e codici postali seguono tutti formati rigidi che un'espressione regolare riconosce in pochi microsecondi.

Per questi dati il pattern matching è veloce, deterministico, verificabile e praticamente gratuito, e il determinismo conta quanto la velocità. Non ha senso spendere una chiamata al modello per stabilire che una stringa con il formato di un numero di previdenza sociale è un numero di previdenza sociale, e ha tutto il senso preferire un controllo di cui puoi prevedere esattamente il comportamento.

Dove fallisce senza avvisare

La maggior parte dei dati personali reali non arriva già formattata. Un nome è solo una parola. Un luogo è solo un luogo. Pensa a due frasi che identificano una persona precisa con assoluta affidabilità e non contengono alcun pattern riconoscibile: “Maria nella stanza 4B” e “il CFO arrivato dall'ufficio di Reno la primavera scorsa”.

Un'espressione regolare non ragiona sul significato, quindi lascia passare tutto ciò che dipende dal contesto: nomi che nessuno le ha fornito, ruoli legati a una singola persona, identificativi indiretti, riferimenti di conto riformulati e identificativi composti nell'arco di una frase invece che contenuti in un solo token. Produce anche falsi positivi nella direzione opposta, segnalando come identificativo qualsiasi numero di nove cifre, e smette di funzionare appena i dati arrivano in un formato che nessuno aveva previsto.

Il fallimento non dà alcun segnale, ed è la caratteristica peggiore che possa avere un controllo sulla privacy. Niente viene segnalato, niente viene registrato e la pipeline riporta un esito positivo.

Cosa aggiunge un passaggio contestuale

Un rilevatore basato su un modello legge il testo come lo legge una persona. Capisce che “la paziente”, “stanza 4B” e un nome di battesimo insieme costituiscono informazioni sanitarie identificabili, anche se nessun singolo token corrisponde a qualcosa. Trova nomi che non ha mai incontrato, si accorge quando una frase descrive un individuo preciso invece di una categoria e si adatta a formulazioni che nessuna regola aveva previsto.

Il prezzo è che è più lento e probabilistico. Ragiona invece di confrontare, quindi non conviene eseguirlo su ogni byte di ogni richiesta se una regola deterministica ed economica ha già risolto la questione. Significa anche che il suo risultato è una valutazione, e va trattato come tale.

La risposta è usarli entrambi, in ordine

I due approcci falliscono in punti opposti, ed è proprio per questo che vanno messi in sequenza e non in competizione. Prima un passaggio deterministico e veloce rimuove gli identificativi strutturati, in modo economico e prevedibile. Poi un passaggio contestuale lavora su quello che resta e trova i nomi, i luoghi e i riferimenti riformulati che i pattern non potevano vedere.

Il pattern matching porta volume e precisione; il passaggio contestuale porta sfumature e capacità di trovare ciò che sfugge. Insieme coprono un vuoto che nessuno dei due copre da solo, ed entrambi agiscono mentre ogni token sensibile è ancora nei tuoi sistemi. È l'unico ordine utile, perché un oscuramento applicato dopo la chiamata al modello è già un fallimento.

Il rilevamento è metà del controllo; l'altra metà è cosa succede dopo

Un rilevatore che trova qualcosa e poi non agisce in modo coerente non è un controllo. La seconda decisione è di policy: in caso di corrispondenza, il valore va mascherato, sostituito con un token stabile perché la frase resti leggibile, eliminato del tutto, oppure va rifiutata l'intera richiesta? Intenti diversi richiedono risposte diverse, ed è per questo che conviene configurarlo per workflow e non a livello globale.

Due controlli vicini contano più di quanto sembri. Il primo è la possibilità di definire che cosa è sensibile nel tuo settore, perché un termine innocuo in un settore è un identificativo in un altro. Il secondo è tenere credenziali e segreti di connessione completamente fuori dal traffico verso il modello, perché se una chiave può arrivare in un prompt, può arrivare in un log, e il log è proprio il documento che consegni a un auditor.

E poiché ogni rilevamento e ogni azione vengono registrati, l'affermazione cambia natura. “Crediamo che i nostri dati siano al sicuro” diventa un registro che mostra cosa è stato rilevato, cosa è stato fatto e quando.