Seudonimización

La seudonimización es una técnica de desidentificación que sustituye los valores de datos sensibles por tokens generados criptográficamente. La seudonimización se usa ampliamente en sectores como el financiero y el sanitario para reducir el riesgo de los datos en uso, acotar el ámbito de cumplimiento y minimizar la exposición de los datos sensibles a los sistemas, al tiempo que se preserva la utilidad y la precisión de los datos.

Protección de Datos Sensibles admite tres técnicas de seudonimización para anonimizar datos y genera tokens aplicando uno de los tres métodos de transformación criptográfica a los valores de datos sensibles originales. A continuación, cada valor sensible original se sustituye por el token correspondiente. La seudonimización a veces se denomina tokenización o sustitución por un elemento ficticio.

Las técnicas de seudonimización permiten usar tokens unidireccionales o bidireccionales. Un token unidireccional se ha transformado de forma irreversible, mientras que un token bidireccional se puede invertir. Como el token se crea mediante cifrado simétrico, la misma clave criptográfica que puede generar tokens nuevos también puede revertir tokens. En los casos en los que no necesites que se pueda revertir, puedes usar tokens unidireccionales que utilicen mecanismos de cifrado con hash seguros.

Es útil saber cómo puede ayudar la seudonimización a proteger los datos sensibles y, al mismo tiempo, permitir que las operaciones empresariales y los flujos de trabajo analíticos accedan fácilmente a los datos que necesitan y los usen. En este tema se explica el concepto de seudonimización y los tres métodos criptográficos para transformar datos que admite Protección de Datos Sensibles.

Para obtener instrucciones sobre cómo implementar estos métodos de seudonimización y ver más ejemplos de uso de Protección de Datos Sensibles, consulta Desidentificar datos sensibles.

Métodos criptográficos admitidos en Protección de Datos Sensibles

Protección de Datos Sensibles admite tres técnicas de seudonimización, todas ellas con claves criptográficas. Estos son los métodos disponibles:

• Cifrado determinista mediante AES-SIV: un valor de entrada se sustituye por un valor que se ha cifrado mediante el algoritmo de cifrado AES-SIV con una clave criptográfica, se ha codificado con base64 y, a continuación, se le ha añadido una anotación de sustituto, si se ha especificado. Este método genera un valor cifrado con hash, por lo que no conserva el conjunto de caracteres ni la longitud del valor de entrada. Los valores cifrados y cifrados con hash se pueden volver a identificar mediante la clave criptográfica original y el valor de salida completo, incluida la anotación de sustituto. Más información sobre el formato de los valores tokenizados mediante el cifrado AES-SIV encryption
• Encriptado con preservación de formato: un valor de entrada se sustituye por un valor que se ha encriptado mediante el algoritmo de encriptado FPE-FFX con una clave criptográfica y, a continuación, se le añade una anotación de sustituto, si se ha especificado. Por diseño, tanto el conjunto de caracteres como la longitud del valor de entrada se conservan en el valor de salida. Los valores cifrados se pueden volver a identificar con la clave criptográfica original y el valor de salida completo, incluida la anotación de sustituto. Para consultar algunas consideraciones importantes sobre el uso de este método de cifrado, consulta la sección Cifrado que conserva el formato, que aparece más adelante en este tema.
• Cifrado con hash: un valor de entrada se sustituye por un valor que se ha cifrado y cifrado con hash mediante código de autenticación de mensajes basado en hash (HMAC) - algoritmo de hash seguro (SHA) - 256 en el valor de entrada con una clave criptográfica. El resultado cifrado de la transformación siempre tiene la misma longitud y no se puede volver a identificar. Más información sobre el formato de los valores tokenizados mediante el cifrado hash

Estos métodos de seudonimización se resumen en la siguiente tabla. Las filas de la tabla se explican después de la tabla.

	Cifrado determinista con AES-SIV	Cifrado que conserva el formato	Funciones hash criptográficas
Tipo de cifrado	AES-SIV	FPE-FFX	HMAC-SHA-256
Valores de entrada admitidos	Debe tener al menos 1 carácter y no hay limitaciones en el conjunto de caracteres.	Debe tener al menos 2 caracteres y estar codificado como ASCII.	Debe ser una cadena o un valor entero.
Anotación de sustituto	Opcional.	Opcional.	N/A
Ajuste de contexto	Opcional.	Opcional.	N/A
Se conservan el conjunto de caracteres y la longitud	✗	✓	✗
Reversible	✓	✓	✗
Integridad referencial	✓	✓	✓

• Tipo de cifrado: el tipo de cifrado que se usa en la transformación de anonimización.
• Valores de entrada admitidos: requisitos mínimos de los valores de entrada.
• Anotación de sustitución: anotación especificada por el usuario que se añade al principio de los valores cifrados para proporcionar contexto a los usuarios e información a Protección de Datos Sensibles para que la use en la reidentificación de un valor desidentificado. Se requiere una anotación de sustitución para reidentificar datos no estructurados. Es opcional cuando se transforma una columna de datos estructurados o tabulares con una RecordTransformation.
• Ajuste de contexto: referencia a un campo de datos que "ajusta" el valor de entrada para que los valores de entrada idénticos se desidentifiquen en valores de salida diferentes. El ajuste de contexto es opcional cuando se transforma una columna de datos estructurados o tabulares con un RecordTransformation. Para obtener más información, consulta Usar ajustes de contexto.
• Conjunto de caracteres y longitud conservados: si un valor anonimizado está formado por el mismo conjunto de caracteres que el valor original y si la longitud del valor anonimizado coincide con la del valor original.
• Reversible: se puede volver a identificar mediante la clave criptográfica, la anotación de sustitución y cualquier ajuste de contexto.
• Integridad referencial: integridad referencial permite que los registros mantengan su relación entre sí incluso después de que sus datos se hayan anonimizado individualmente. Con la misma clave criptográfica y el mismo ajuste de contexto, una tabla de datos se sustituirá por la misma forma ofuscada cada vez que se transforme, lo que asegura que se conserven las conexiones entre los valores (y, en el caso de los datos estructurados, los registros), incluso entre tablas.

Cómo funciona la tokenización en Protección de Datos Sensibles

El proceso básico de tokenización es el mismo para los tres métodos que admite Protección de datos sensibles.

Paso 1: Protección de Datos Sensibles selecciona los datos que se van a tokenizar. La forma más habitual de hacerlo es usar un detector de infoType integrado o personalizado para buscar coincidencias con los valores de datos sensibles que quieras. Si analiza datos estructurados (como una tabla de BigQuery), también puede tokenizar columnas de datos completas mediante transformaciones de registros.

Para obtener más información sobre las dos categorías de transformaciones (infoType y registro), consulta Transformaciones de desidentificación.

Paso 2: Con una clave criptográfica, Protección de Datos Sensibles cifra cada valor de entrada. Puede proporcionar esta clave de tres formas:

• Encapsulándola con Cloud Key Management Service (Cloud KMS). (Para disfrutar de la máxima seguridad, Cloud KMS es el método preferido).
• Usando una clave transitoria que Protección de Datos Sensibles genera en el momento de la desidentificación y que, después, descarta. Una clave transitoria solo mantiene la integridad por solicitud de API. Si necesita integridad o tiene previsto volver a identificar estos datos, no utilice este tipo de clave.
• Directamente en formato de texto sin formato. (No recomendado).

Para obtener más información, consulta la sección Usar claves criptográficas, que aparece más adelante en este tema.

Paso 3 (cifrado criptográfico con hash y cifrado determinista solo con AES-SIV): Sensitive Data Protection codifica el valor cifrado con base64. Con el hash criptográfico, este valor codificado y cifrado es el token, y el proceso continúa con el paso 6. Con el cifrado determinista mediante AES-SIV, este valor cifrado y codificado es el valor sustituto, que es solo un componente del token. El proceso continúa con el paso 4.

Paso 4 (cifrado determinista y que conserva el formato con AES-SIV únicamente): Protección de Datos Sensibles añade una anotación de sustituto opcional al valor cifrado. La anotación de sustituto ayuda a identificar los valores de sustituto cifrados añadiéndoles una cadena descriptiva que definas. Por ejemplo, sin una anotación, no podrías distinguir entre un número de teléfono anonimizado y un número de la seguridad social u otro número de identificación anonimizado. Además, para volver a identificar los valores de datos no estructurados que se han anonimizado mediante el encriptado con preservación de formato o el encriptado determinista, debe especificar una anotación de sustitución. (No es necesario usar anotaciones de sustitución al transformar una columna de datos estructurados o tabulares con RecordTransformation).

Paso 5 (cifrado determinista y que conserva el formato con AES-SIV de datos estructurados únicamente): Sensitive Data Protection puede usar contexto opcional de otro campo para "ajustar" el token generado. Esto te permite cambiar el ámbito del token. Por ejemplo, supongamos que tiene una base de datos de datos de campañas de marketing que incluye direcciones de correo electrónico y quiere generar tokens únicos para la misma dirección de correo electrónico "modificada" por el ID de campaña. De esta forma, se podría combinar información del mismo usuario en la misma campaña, pero no en diferentes campañas. Si se usa un ajuste de contexto para crear el token, también se requiere este ajuste para que se reviertan las transformaciones de anonimización. Encriptado determinista y con preservación de formato mediante contextos de compatibilidad con AES-SIV. Más información sobre cómo usar los ajustes de contexto

Nota: Para obtener más información sobre el formato de los valores tokenizados, incluidas las anotaciones y los contextos de sustitución, consulta la sección "Comparación de valores tokenizados" que aparece a continuación.

Paso 6: Protección de Datos Sensibles sustituye el valor original por el valor desidentificado.

Comparación de valores tokenizados

En esta sección se muestra el aspecto de los tokens típicos después de anonimizarlos con cada uno de los tres métodos descritos en este tema. El valor de datos sensibles de ejemplo es un número de teléfono de Norteamérica (1-206-555-0123).

Cifrado determinista con AES-SIV

Con la desidentificación mediante cifrado determinista y AES-SIV, se cifra un valor de entrada (y, opcionalmente, cualquier ajuste de contexto especificado) mediante AES-SIV con una clave criptográfica, se codifica con base64 y, opcionalmente, se le añade una anotación de sustituto, si se ha especificado. Este método no conserva el conjunto de caracteres (o "alfabeto") del valor de entrada. Para generar una salida imprimible, el valor resultante se codifica en base64.

El token resultante, suponiendo que se ha especificado un infoType subrogado, tiene el siguiente formato:

SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE

En el siguiente diagrama anotado se muestra un ejemplo de token, que es el resultado de una operación de desidentificación mediante cifrado determinista con AES-SIV en el valor 1-206-555-0123. El infoType subrogado opcional se ha definido como NAM_PHONE_NUMB:

1. Anotación subrogada
2. InfoType subrogado (definido por el usuario)
3. Longitud de caracteres del valor transformado
4. Valor sustituto (transformado)

Si no especificas una anotación de sustituto, el token resultante será igual al valor transformado, o #4 en el diagrama anotado. Para volver a identificar datos no estructurados, se necesita todo este token, incluida la anotación de sustituto. Al transformar datos estructurados, como una tabla, la anotación de sustituto es opcional. Protección de Datos Sensibles puede anonimizar y volver a identificar una columna completa mediante un RecordTransformation sin una anotación de sustituto.

Encriptado con preservación de formato

Con la desidentificación mediante el encriptado con preservación de formato, se encripta un valor de entrada (y, opcionalmente, cualquier ajuste de contexto especificado) mediante el modo FFX del encriptado con preservación de formato ("FPE-FFX") con una clave criptográfica y, a continuación, se le añade opcionalmente un prefijo con una anotación de sustituto, si se ha especificado.

A diferencia de los otros métodos de tokenización descritos en este tema, el valor de sustituto de salida tiene la misma longitud que el valor de entrada y no se codifica con base64. Defines el conjunto de caracteres (o "alfabeto") del que se compone el valor cifrado. Hay tres formas de especificar el alfabeto que Protección de Datos Sensibles debe usar en el valor de salida:

• Usa uno de los cuatro valores enumerados que representan los cuatro conjuntos de caracteres o alfabetos más comunes.
• Usa un valor de base, que especifica el tamaño del alfabeto. Si se especifica el valor mínimo de base 2, el alfabeto constará únicamente de 0 y 1. Si se especifica el valor máximo de base, 95, se obtiene un alfabeto que incluye todos los caracteres numéricos, los caracteres alfabéticos en mayúsculas, los caracteres alfabéticos en minúsculas y los símbolos.
• Crea un alfabeto enumerando los caracteres exactos que quieras usar. Por ejemplo, si se especifica 1234567890-*, se obtendrá un valor de sustitución formado únicamente por números, guiones y asteriscos.

Importante: Si decides usar el método de anonimización con cifrado que conserva el formato (FPE), asegúrate de que tanto los valores originales que vas a transformar como el tamaño del alfabeto que has especificado para que usen los valores transformados (la base) tengan una longitud suficiente para evitar la ingeniería inversa de la salida segura. En situaciones en las que el número de cadenas de caracteres posibles es pequeño, aumenta la base del alfabeto o usa un ajuste de contexto.

Además, aunque la longitud del valor transformado se conserva, gracias a la falta de autenticación y vector de inicialización, el cifrado preservador de formato ofrece menos garantías de seguridad que otros métodos de cifrado deterministas, como el cifrado determinista con AES-SIV.

En la siguiente tabla se enumeran cuatro conjuntos de caracteres habituales con su valor enumerado (FfxCommonNativeAlphabet), su valor de base y la lista de caracteres del conjunto. En la última fila se muestra el conjunto de caracteres completo, que corresponde al valor máximo de la base.

Nombre del alfabeto o del conjunto de caracteres	Radix	Lista de caracteres
NUMERIC	10	0123456789
HEXADECIMAL	16	0123456789ABCDEF
UPPER_CASE_ALPHA_NUMERIC	36	0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ
ALPHA_NUMERIC	62	0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
-	95	0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz~`!@#$%^&*()_-+={[}]|\:;"'<,>.?/

El token resultante, suponiendo que se ha especificado un infoType subrogado, tiene el siguiente formato:

SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE

El siguiente diagrama anotado muestra el resultado de una operación de desidentificación de Protección de Datos Sensibles que usa el encriptado con preservación de formato en el valor 1-206-555-0123 con una base de 95. El infoType subrogado opcional se ha definido como NAM_PHONE_NUMB:

1. Anotación subrogada
2. InfoType subrogado (definido por el usuario)
3. Longitud de caracteres del valor transformado
4. Valor sustituto (transformado): tiene la misma longitud que el valor de entrada.

Si no especificas una anotación de sustituto, el token resultante será igual al valor transformado, o #4 en el diagrama anotado. Para volver a identificar datos no estructurados, se necesita todo este token, incluida la anotación de sustituto. Cuando se transforman datos estructurados, como una tabla, la anotación de sustituto es opcional. Protección de Datos Sensibles puede anonimizar y volver a identificar una columna completa mediante un RecordTransformation sin necesidad de usar un sustituto.

Nota: Por diseño, FPE-FFX conserva la longitud y el conjunto de caracteres del texto de entrada. Esto significa que no tiene autenticación ni vector de inicialización, lo que provocaría una expansión de longitud en el token de salida. Otros métodos, como el cifrado determinista con AES-SIV, ofrecen estas garantías de seguridad más sólidas y se recomiendan para los casos prácticos de tokenización, a menos que la conservación de la longitud y del conjunto de caracteres sean requisitos estrictos (por ejemplo, para la compatibilidad con versiones anteriores de un sistema de datos antiguo).

Cifrado con hash criptográfico

Con la desidentificación mediante el cifrado hash, se cifra un valor de entrada mediante HMAC-SHA-256 con una clave criptográfica y, a continuación, se codifica con base64. El valor anonimizado siempre tiene una longitud uniforme, en función del tamaño de la clave.

A diferencia de los otros métodos de tokenización que se describen en este tema, el cifrado criptográfico crea un token unidireccional. Es decir, la desidentificación mediante cifrado hash no se puede revertir.

A continuación, se muestra el resultado de una operación de desidentificación mediante el cifrado hash del valor 1-206-555-0123. Esta salida es una representación codificada en base64 del valor cifrado:

XlTCv8h0GwrCZK+sS0T3Z8txByqnLLkkF4+TviXfeZY=

Usar claves criptográficas

Hay tres opciones de claves criptográficas que puedes usar con los métodos de desidentificación criptográfica de Protección de Datos Sensibles:

• Clave criptográfica encapsulada por Cloud KMS: es el tipo de clave criptográfica más seguro que se puede usar con los métodos de desidentificación de Protección de Datos Sensibles. Una clave encapsulada de Cloud KMS es una clave criptográfica de 128, 192 o 256 bits que se ha encriptado con otra clave. Tú proporcionas la primera clave criptográfica, que se encapsula con una clave criptográfica almacenada en Cloud Key Management Service. Este tipo de claves se almacena en Cloud KMS para volver a identificar al usuario más adelante. Para obtener más información sobre cómo crear y envolver una clave con el fin de desidentificar y reidentificar datos, consulta Guía de inicio rápido: Desidentificar y reidentificar texto sensible.

  Nota: Cuando usas Cloud KMS para realizar operaciones criptográficas, se aplican cargos. Además, cuando usas una clave de Cloud HSM o una clave de Cloud EKM, consumes cuota de Cloud KMS en el proyecto que contiene la clave. Por el contrario, si usas una clave de software de Cloud KMS con Protección de Datos Sensibles, no se aplican valores de cuota. Para obtener más información, consulta Cuotas en la documentación de Cloud KMS.

• Clave criptográfica transitoria: Sensitive Data Protection genera una clave criptográfica transitoria en el momento de la anonimización y, después, la descarta. Por este motivo, no utilices una clave criptográfica transitoria con ningún método de desidentificación criptográfico que quieras revertir. Las claves criptográficas transitorias solo mantienen la integridad por solicitud de API. Si necesitas integridad en más de una solicitud de API o tienes previsto volver a identificar tus datos, no uses este tipo de clave.

• Clave criptográfica desencapsulada: una clave desencapsulada es una clave criptográfica sin formato de 128, 192 o 256 bits codificada en base64 que proporcionas en la solicitud de desidentificación a la API DLP. Usted es responsable de mantener protegidas estas claves criptográficas para su posterior reidentificación. Debido al riesgo de que se filtre la clave por error, no se recomienda usar este tipo de claves. Estas claves pueden ser útiles para las pruebas, pero para las cargas de trabajo de producción, se recomienda usar una clave criptográfica encapsulada de Cloud KMS.

Para obtener más información sobre las opciones disponibles al usar claves criptográficas, consulta CryptoKey en la referencia de la API DLP.

Usar ajustes de contexto

De forma predeterminada, todos los métodos de transformación criptográfica de la desidentificación tienen integridad referencial, tanto si los tokens de salida son unidireccionales como bidireccionales. Es decir, con la misma clave criptográfica, un valor de entrada siempre se transforma en el mismo valor cifrado. En situaciones en las que se pueden producir datos o patrones de datos repetitivos, aumenta el riesgo de reidentificación. Para que el mismo valor de entrada se transforme siempre en un valor cifrado diferente, puedes especificar un ajuste de contexto único.

Cuando transformas datos tabulares, especificas un ajuste de contexto (denominado simplemente context en la API DLP), ya que el ajuste es, en realidad, un puntero a una columna de datos, como un identificador. Protección de Datos Sensibles usa el valor del campo especificado por contextTweak al cifrar el valor de entrada. Para asegurarte de que el valor cifrado sea siempre único, especifica una columna para el ajuste que contenga identificadores únicos.

Veamos un ejemplo sencillo. En la siguiente tabla se muestran varios registros médicos, algunos de los cuales incluyen IDs de pacientes duplicados.

Nota: Este ejemplo se usa para ilustrar cómo funcionan los ajustes de contexto y no debe considerarse una práctica recomendada para usar Protección de Datos Sensibles.

record_id	patient_id	icd10_code
5437	43789	E11.9
5438	43671	M25.531
5439	43789	N39.0, I25.710
5440	43766	I10
5441	43766	I10
5442	42989	R07.81
5443	43098	I50.1, R55
...	...	...

Si le indica a Protección de Datos Sensibles que anonimice los IDs de pacientes de la tabla, de forma predeterminada, anonimizará los IDs de pacientes repetidos con los mismos valores, tal como se muestra en la siguiente tabla. Por ejemplo, las dos instancias del ID del paciente "43789" se anonimizan como "47222". La columna patient_id muestra los valores de token después de la seudonimización mediante FPE-FFX y no incluye anotaciones de sustitución. Consulta Encriptado que mantiene el formato para obtener más información.

record_id	patient_id	icd10_codes
5437	47222	E11.9
5438	82160	M25.531
5439	47222	N39.0, I25.710
5440	04452	I10
5441	04452	I10
5442	47826	R07.81
5443	52428	I50.1, R55
...	...	...

Esto significa que el ámbito de la integridad referencial abarca todo el conjunto de datos.

Para acotar el ámbito y evitar este comportamiento, especifica un ajuste de contexto. Puede especificar cualquier columna como ajuste de contexto, pero para garantizar que cada valor anonimizado sea único, especifique una columna en la que todos los valores sean únicos.

Supongamos que quiere ver si el mismo paciente aparece en un valor de icd10_codes, pero no si aparece en valores de icd10_codes diferentes. Para ello, especifica la columna icd10_codes como ajuste de contexto.

Esta es la tabla después de desidentificar la columna patient_id usando la columna icd10_codes como ajuste de contexto:

record_id	patient_id	icd10_codes
5437	18954	E11.9
5438	33068	M25.531
5439	76368	N39.0, I25.710
5440	29460	I10
5441	29460	I10
5442	23877	R07.81
5443	96129	I50.1, R55
...	...	...

Ten en cuenta que el cuarto y el quinto valor de patient_id anonimizado (29460) son iguales porque no solo los valores de patient_id originales eran idénticos, sino que también lo eran los valores de icd10_codes de ambas filas. Como necesitabas realizar un análisis con IDs de paciente coherentes en el ámbito del valor icd10_codes, este es el comportamiento que buscas.

Para romper por completo la integridad referencial entre los valores de patient_id y los de icd10_codes, puedes usar la columna record_id como ajuste de contexto:

record_id	patient_id	icd10_code
5437	15826	E11.9
5438	61722	M25.531
5439	34424	N39.0, I25.710
5440	02875	I10
5441	52549	I10
5442	17945	R07.81
5443	19030	I50.1, R55
...	...	...

Ten en cuenta que cada valor de patient_id anonimizado de la tabla ahora es único.

Para saber cómo usar los ajustes de contexto en la API DLP, consulta el uso de context en los siguientes temas de referencia sobre métodos de transformación:

• Encriptado con preservación de formato: CryptoReplaceFfxFpeConfig
• Cifrado determinista con AES-SIV: CryptoDeterministicConfig
• Cambios de fecha: DateShiftConfig

Siguientes pasos

• Consulta un ejemplo de principio a fin que muestra cómo crear una clave envuelta, tokenizar contenido y volver a identificar contenido tokenizado.

• Consulta los ejemplos de código que muestran cómo tokenizar datos sensibles.

• Consulta cómo desidentificar datos con la API DLP.