Una chiave surrogata dovrebbe mai essere esposta a un utente?

Devi essere pronto per qualsiasi identificatore esposto a utenti / clienti che necessitano di essere modificati, e cambiare l'identità di una riga in un database e propagare quella modifica a tutte le chiavi esterne è solo chiedere di rompere i dati.

Se i dati non hanno una chiave aziendale naturale, è possibile aggiungere un campo aggiuntivo per un "identificatore aziendale". Questo dovrebbe essere ottimizzato per i processi per cui è usato. L'immissione della tastiera telefonica indica solo valori numerici. Per telefono / mezzo verbale evitare simboli simili (B / D, M / N, ecc.). Puoi anche generare automaticamente alcune frasi facilmente memorizzabili ("green jelly").

L'effetto di questo è che l'azienda può in seguito cambiare il modo in cui desidera fare riferimento ai record e l'unica modifica dello schema dati è l'aggiunta di una nuova colonna per quello stile di id o la trasformazione degli ID già presenti. La modifica non si diffonde attraverso l'intero database e hai ancora un ID (il surrogato) che è valido nel tempo.

In breve, eviterei di esporre le chiavi surrogate agli utenti. Come i commenti sottolineano, le chiavi surrogate non dovrebbero quasi mai cambiare. Al contrario, le aziende vogliono cambiare tutto. Se la chiave surrogata viene esposta, è solo una questione di tempo prima che l'azienda voglia cambiarla.

Come nota a margine, quando dico "esporre" qui, intendo dare la chiave all'utente con l'aspettativa che la usi direttamente (come chiamare per supportare con il loro numero d'ordine ).

In alcuni casi, le chiavi surrogate sono previste e hanno un senso per gli utenti. Il mio esempio preferito è "numero ordine". Il numero dell'ordine non è in realtà una chiave naturale: una chiave naturale potrebbe essere data / ora più utente o forse più di quella se ti aspetti che gli utenti generino più di un ordine nella granularità della data / ora.

Tuttavia, gli utenti comprendono e si aspettano la convenienza di un numero di ordine. Non c'è niente di male, e molto valore, se ne fai sapere agli utenti.

D'altra parte, alcune chiavi sostitutive non hanno senso per un utente. Certo, la mia compagnia di assicurazione sanitaria ha qualche chiave surrogata che mi identifica in base al mio id membro, data di nascita, corriere, ecc., Ma non mi interessa, mi interessa le informazioni sulla mia carta (che spesso include gli ID basati sul mio datore di lavoro e non sono unici in tutto l'universo ... Da qui la chiave surrogata presso la compagnia di assicurazioni).

Dovresti esporre una chiave surrogata solo se è un GUID / UUID generato correttamente *. L'esposizione delle chiavi surrogate sequenziali è numero 4 sui primi 10 problemi di sicurezza di OWASP.

* In pratica, è meglio presumere che non sia stato generato correttamente per questi scopi a meno che non si sappia che è stato creato da un generatore di numeri casuali o pseudo casuali crittograficamente sicuro.

In parole semplici:

• I surrogati devono essere nascosti all'utente.
• Dovresti esporre un po 'di altra chiave business candidate all'utente.
• Se non esistono altre chiavi candidate, è necessario mostrare il PK. Ma in questo caso il PK non è considerato un surrogato poiché non è un sostituto per l'altra colonna.

devi esporre SOLO un campo per un utente che fornisce informazioni utili all'utente, direttamente o per segnalare difetti all'utente.

Al contrario, dovresti SEMPRE esporre "chiavi primarie surrogate" quando sono il mezzo principale per identificare un record (semplice o complesso) per un'interazione che l'utente compie.

Non dovrebbe importare se esponi le chiavi o meno all'utente finale. La tua applicazione dovrebbe eseguire l'autorizzazione necessaria in modo tale che semplicemente conoscere un ID ordine, ad esempio, non possa consentire loro l'accesso a qualcosa a cui normalmente non avrebbero accesso.

avvertenza: presuppone un'applicazione web o di livello n dove l'autorizzazione lato server sia possibile / fattibile. Se hai un'app VB che esegue direttamente SQL, questo è un bel problema.