En DB2, column masks se utilizan para lograr el efecto que está describiendo, pero son vulnerables a los ataques de enumeración. Provocarán una máscara (por ejemplo, puede definirla como "CHAR ('XXX-XX-') || SUBSTR (SSN, 8,4)" en lugar del SSN completo) que se devolverá en lugar de los datos para SELECT, pero Todavía se puede utilizar normalmente para DONDE. Se pueden configurar por usuario / grupo / rol.
El ataque de enumeración es el siguiente: si puedo "DÓNDE" el campo "ssn" pero no lo "SELECCIONO", todavía puedo averiguar quién tiene qué 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';
Y para algunas de esas adivinanzas afortunadas, el nombre será devuelto y me dirá qué SSN tienen.
Dependiendo de los datos involucrados, la "fuerza bruta" puede ser algo inteligente. Por ejemplo, con los números de tarjetas de crédito, el número completo puede estar protegido, pero el BIN (primeros 6) y los últimos 4 dígitos pueden almacenarse sin cifrar a su lado. Eso permitiría a un atacante enumerar 5 o 6 dígitos en lugar de 15 o 16, y el espacio puede reducirse aún más si el atacante calcula mod 10 antes de intentar números potenciales.
Ese no es un gran ejemplo porque los límites de campo que estamos discutiendo probablemente no satisfacen PCI DSS 3.4 requisitos para proteger los datos PAN. Pero es un ejemplo, y puede traducirse a otras áreas. Por ejemplo, algún subconjunto de la población tiene un SSN asignado según su lugar de nacimiento. Algún subconjunto de ese subconjunto aún vive en la misma área en la que nacieron. En consecuencia, el prefijo SSN de ese sub-subconjunto puede ser adivinado dada su dirección, que puede almacenarse sin cifrar junto con su SSN, reduciendo así el espacio de ataque.