In DB2, maschere di colonna vengono utilizzate per ottenere l'effetto che stai descrivendo, ma sono vulnerabili agli attacchi di enumerazione. Causeranno una maschera (ad esempio puoi definirla come "CHAR ('XXX-XX-') || SUBSTR (SSN, 8,4)" invece del SSN completo) da restituire invece dei dati per SELECT, ma può ancora essere usato normalmente per DOVE. Possono essere configurati in base a utente / gruppo / ruolo.
L'attacco di enumerazione è il seguente: se posso 'DOVE' il campo 'ssn' ma non 'SELEZIONA', posso ancora capire chi ha cosa SSN:
SELECT name FROM table WHERE ssn = '000-00-0000';
SELECT name FROM table WHERE ssn = '000-00-0001';
SELECT name FROM table WHERE ssn = '000-00-0002';
...
SELECT name FROM table WHERE ssn = '999-99-9999';
E per alcune di quelle fortunate ipotesi, il nome verrà restituito, dicendomi quale SSN hanno.
A seconda dei dati coinvolti, la "forza bruta" può essere alquanto intelligente. Ad esempio, con i numeri delle carte di credito, il numero intero può essere protetto, ma il BIN (primo 6) e le ultime 4 cifre possono essere memorizzati in modo non criptato accanto a esso. Ciò consentirebbe a un utente malintenzionato di enumerare 5 o 6 cifre anziché 15 o 16 e lo spazio può essere abbassato ulteriormente se l'utente malintenzionato calcola mod 10 prima di tentare i numeri potenziali.
Questo non è un ottimo esempio perché i limiti di campo di cui stiamo discutendo probabilmente non soddisfano PCI DSS 3.4 requisiti per proteggere i dati PAN. Ma è un esempio e può tradursi in altre aree. Ad esempio, alcuni sottoinsiemi della popolazione hanno un SSN assegnato in base al luogo di nascita. Alcuni sottoinsiemi di quel sottogruppo vivono ancora nella stessa area in cui sono nati. Di conseguenza, il prefisso SSN di quel sottoinsieme può essere ipotizzabile dato il loro indirizzo, che può essere memorizzato non criptato insieme al loro SSN, riducendo così lo spazio di attacco.