Tokenización, enmascarado, retención y borrado

Tokenizar es sustituir un dato sensible por un valor sustituto sin relación matemática con él; la correspondencia entre token y valor real vive en una bóveda separada que solo consultan pocos sistemas. Un dato cifrado, en cambio, sigue siendo el dato, solo que ilegible: quien tenga la clave lo recupera con una operación. Quien robe una tabla de tokens no obtiene nada que pueda deshacer, porque no hay clave que lo revierta; solo la bóveda lo relaciona.

Esa propiedad mueve el problema: ya no se protege una clave sino una bóveda, y los sistemas que solo manejan tokens (la conciliación, los informes) quedan fuera del alcance de quien protege el dato real. Por eso la tokenización reduce el alcance de las auditorías en pagos.

Un hash es una función de un solo sentido, y por eso se usa a menudo para «proteger» identificadores que luego hay que comparar. El problema aparece cuando el conjunto de valores posibles es pequeño: una cédula tiene un número finito y modesto de combinaciones para un computador, y quien tenga la tabla de hashes puede calcular el hash de todas y comparar. Sin sal ni clave, la tabla se deshace con un cálculo que cabe en un portátil. El hash sin más no protege identificadores de rango pequeño; los protege uno con clave secreta, o mejor una pseudonimización con bóveda.

El análisis aquí es de diseño: se mira cuántos valores posibles hay detrás del campo, no qué función se aplicó.

La retención dice cuánto tiempo se conserva cada tipo de dato y la destrucción es el cumplimiento de ese plazo. El plazo lo fija la política interna a partir de las obligaciones del negocio y la ley; el arquitecto no lo inventa, lo hace comprobable. Cada tipo de copia tiene el suyo: lo normal es que un respaldo, pensado para recuperarse de un desastre reciente, se conserve mucho menos que un archivo de casos cerrados.

Para encontrar la copia que se pasó se compara la edad de cada una con el plazo de su propio tipo, no con el de otro: una edad que es normal en un archivo puede ser un exceso en un respaldo.

Borrar un dato de una copia exige poder localizarlo y sobrescribirlo, y hay copias que lo impiden: cintas, instantáneas inmutables, almacenamiento de un tercero que solo borra por lotes. Para esos casos existe el borrado criptográfico: si la copia se cifró con una clave que solo sirve para esa copia, destruir la clave la deja ilegible para siempre, con el mismo efecto que borrarla. Hay dos condiciones: que la clave sea exclusiva de esas copias, y que no existan otras copias de la propia clave, incluidas las de respaldo del servicio de claves.

La destrucción de la clave debe quedar documentada con quién, cuándo y qué clave, porque es la evidencia de que el plazo se cumplió.

Un entorno de pruebas con una copia de producción hereda el nivel de producción y no el nivel de control de un entorno de pruebas: más gente accede, con menos registros y con menos vigilancia. La solución de arquitectura es que los datos reales no lleguen al entorno de pruebas. Se usan datos sintéticos, o una copia enmascarada de forma estática: antes de que la copia salga de producción, cada valor sensible se sustituye por otro ficticio y coherente (un diagnóstico que existe, una cédula con formato válido que no es de nadie) y el proceso de enmascarado es el único con acceso a los datos reales.

Cifrar la copia no resuelve nada si el entorno de pruebas tiene la clave, y un hash del diagnóstico deja inservibles las pantallas que lo muestran.