Desidentificar y reidentificar la IPI de conjuntos de datos a gran escala con Protección de Datos Sensibles

Last reviewed 2024-06-07 UTC

En este documento se explica cómo usar Protección de Datos Sensibles para crear un flujo de procesamiento de transformación de datos automatizado que permita desidentificar datos sensibles, como la información personal identificable (IPI). Las técnicas de desidentificación, como la tokenización (seudonimización), te permiten seguir usando los datos para uniones o analíticas. Además, para reducir los riesgos inherentes a la gestión de datos, se ofuscan los identificadores sensibles sin procesar. Para minimizar el riesgo de gestionar grandes volúmenes de datos sensibles, puedes usar un flujo de procesamiento de transformación de datos automatizado para crear réplicas desidentificadas. Protección de Datos Sensibles permite realizar transformaciones como la ocultación, el enmascaramiento, la tokenización, el agrupamiento y otros métodos de desidentificación. Si no se ha caracterizado un conjunto de datos, Protección de Datos Sensibles también puede inspeccionar los datos para detectar información sensible mediante más de 100 clasificadores integrados.

Este documento está dirigido a un público técnico cuyas responsabilidades incluyen la seguridad, el tratamiento o el análisis de datos. En esta guía se da por hecho que conoces los conceptos de tratamiento y privacidad de los datos, pero no es necesario que seas un experto.

Arquitectura de referencia

En el siguiente diagrama se muestra una arquitectura de referencia para usar productos deGoogle Cloud con el fin de añadir una capa de seguridad a los conjuntos de datos sensibles mediante técnicas de anonimización.

Arquitectura de la canalización de desidentificación, la gestión de la configuración y la canalización de reidentificación.

La arquitectura consta de lo siguiente:

  • Flujo de procesamiento de desidentificación de datos: desidentifica datos sensibles en texto mediante Dataflow. Puedes reutilizar la canalización para varias transformaciones y casos prácticos.

  • Gestión de la configuración (plantilla y clave de Protección de Datos Sensibles): una configuración de desidentificación gestionada a la que solo puede acceder un pequeño grupo de personas (por ejemplo, administradores de seguridad) para evitar que se expongan los métodos de desidentificación y las claves de cifrado.

  • Proceso de validación de datos y reidentificación: valida copias de los datos desidentificados y usa un proceso de Dataflow para reidentificar datos a gran escala.

Ayudamos a proteger los datos sensibles

Una de las tareas clave de cualquier empresa es ayudar a garantizar la seguridad de los datos de sus usuarios y empleados. Google Cloud proporciona medidas de seguridad integradas para facilitar la seguridad de los datos, incluido el cifrado de los datos almacenados y el cifrado de los datos en tránsito.

Encriptado en reposo: Cloud Storage

Mantener la seguridad de los datos es fundamental para la mayoría de las organizaciones. El acceso no autorizado a datos incluso moderadamente sensibles puede dañar la confianza, las relaciones y la reputación que tienes con tus clientes. Google cifra los datos almacenados en reposo de forma predeterminada. De forma predeterminada, los objetos que se suben a un segmento de Cloud Storage se encriptan con una Google-owned and Google-managed encryption key. Si tu conjunto de datos usa un método de cifrado preexistente y requiere una opción no predeterminada antes de la subida, Cloud Storage ofrece otras opciones de cifrado. Para obtener más información, consulta las opciones de cifrado de datos.

Cifrado en tránsito: Dataflow

Cuando tus datos están en tránsito, el cifrado en reposo no está activado. Los datos en tránsito están protegidos por protocolos de red seguros denominados cifrado en tránsito. De forma predeterminada, Dataflow usa Google-owned and Google-managed encryption keys. Los tutoriales asociados a este documento usan una canalización automatizada que utiliza el valor predeterminado Google-owned and Google-managed encryption keys.

Transformaciones de datos de Protección de Datos Sensibles

Protección de Datos Sensibles realiza dos tipos principales de transformaciones:

Tanto el método recordTransformations como el infoTypeTransformations pueden anonimizar y cifrar la información sensible de tus datos. Por ejemplo, puedes transformar los valores de la columna US_SOCIAL_SECURITY_NUMBER para que no se puedan identificar o usar la tokenización para ocultarlos y, al mismo tiempo, mantener la integridad referencial.

El método infoTypeTransformations te permite inspeccionar datos sensibles y transformar los resultados. Por ejemplo, si tiene datos no estructurados o de texto libre, el método infoTypeTransformations puede ayudarle a identificar un número de la Seguridad Social en una frase y cifrar el valor del número, mientras que el resto del texto permanece intacto. También puedes definir métodos infoTypes personalizados.

El método recordTransformations le permite aplicar una configuración de transformación por campo cuando utiliza datos estructurados o tabulares. Con el método recordTransformations, puede aplicar la misma transformación a todos los valores de ese campo, como cifrar o tokenizar todos los valores de una columna con SSN column como nombre de campo o de encabezado.

Con el método recordTransformations, también puedes combinar el método infoTypeTransformations, que solo se aplica a los valores de los campos especificados. Por ejemplo, puedes usar un método infoTypeTransformations dentro de un método recordTransformations para el campo llamado comments con el fin de redactar cualquier resultado de US_SOCIAL_SECURITY_NUMBER que se encuentre en el texto del campo.

Los procesos de desidentificación, ordenados de menor a mayor complejidad, son los siguientes:

  • Ocultación: elimina el contenido sensible sin sustituirlo.
  • Máscara: sustituye el contenido sensible por caracteres fijos.
  • Cifrado: sustituye el contenido sensible por cadenas cifradas, posiblemente de forma reversible.

Trabajar con datos delimitados

A menudo, los datos se componen de registros delimitados por un carácter seleccionado, con tipos fijos en cada columna, como en un archivo CSV. En el caso de este tipo de datos, puede aplicar transformaciones de desidentificación (recordTransformations) directamente, sin inspeccionar los datos. Por ejemplo, puedes esperar que una columna etiquetada como SSN contenga solo datos de números de la Seguridad Social. No es necesario inspeccionar los datos para saber que el detector infoTypeUS_SOCIAL_SECURITY_NUMBER. Sin embargo, las columnas de formato libre etiquetadas como Additional Details pueden contener información sensible, pero la clase infoType se desconoce de antemano. En el caso de las columnas de texto libre, debe inspeccionar el detector infoTypes (infoTypeTransformations) antes de aplicar transformaciones de anonimización. Protección de Datos Sensibles permite que ambos tipos de transformación coexistan en una misma plantilla de desidentificación. Protección de Datos Sensibles incluye más de 100 detectores infoTypes integrados. También puedes crear tipos personalizados o modificar detectores infoTypes integrados para encontrar datos sensibles que sean únicos en tu organización.

Determinar el tipo de transformación

Determinar cuándo usar el método recordTransformations o infoTypeTransformations depende de tu caso práctico. Como el método infoTypeTransformations requiere más recursos y, por lo tanto, es más costoso, te recomendamos que lo uses solo en situaciones en las que se desconozca el tipo de datos. Puedes evaluar los costes de ejecutar Protección de Datos Sensibles con la Google Cloud calculadora de precios.

En los ejemplos de transformación, este documento hace referencia a un conjunto de datos que contiene archivos CSV con columnas fijas, como se muestra en la siguiente tabla.

Nombre de la columna Inspección infoType (personalizada o integrada) Tipo de transformación de Protección de Datos Sensibles
Card Number No aplicable Cifrado determinista (DE)
Card Holder's Name No aplicable Cifrado determinista (DE)
Card PIN No aplicable Cifrado con hash criptográfico
SSN (Social Security Number) No aplicable Enmascaramiento
Age No aplicable Agrupación
Job Title No aplicable Agrupación
Additional Details Integradas:
IBAN_CODE, EMAIL_ADDRESS, PHONE_NUMBER
Personalizadas:
ONLINE_USER_ID
Sustitución

En esta tabla se enumeran los nombres de las columnas y se describe el tipo de transformación que se necesita para cada columna. Por ejemplo, la columna Card Number contiene números de tarjetas de crédito que deben cifrarse, pero no es necesario inspeccionarlos porque se conoce el tipo de datos (infoType).

La única columna en la que se recomienda una transformación de inspección es la columna Additional Details. Esta columna es de formato libre y puede contener IPI, que, a efectos de este ejemplo, debe detectarse y anonimizarse.

En los ejemplos de esta tabla se muestran cinco transformaciones de desidentificación diferentes:

  • Tokenización bidireccional: sustituye los datos originales por un token determinista que conserva la integridad referencial. Puede usar el token para combinar datos o usarlo en análisis agregados. Puedes revertir o des-tokenizar los datos con la misma clave que usaste para crear el token. Hay dos métodos para la tokenización bidireccional:

    • Cifrado determinista (DE): sustituye los datos originales por un valor cifrado codificado en Base64 y no conserva el conjunto de caracteres ni la longitud originales.
    • Encriptado con preservación de formato con FFX (FPE-FFX): sustituye los datos originales por un token generado mediante el encriptado con preservación de formato en modo FFX. Por diseño, FPE-FFX conserva la longitud y el conjunto de caracteres del texto de entrada. No tiene autenticación ni vector de inicialización, lo que puede provocar una expansión de longitud en el token de salida. Otros métodos, como el cifrado de datos, ofrecen una seguridad más sólida 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, como la retrocompatibilidad con sistemas de datos antiguos.
  • Tokenización unidireccional mediante cifrado con hash: sustituye el valor original por un valor cifrado con hash, lo que permite mantener la integridad referencial. Sin embargo, a diferencia de la tokenización bidireccional, un método unidireccional no es reversible. El valor de hash se genera mediante un código de autenticación de mensajes basado en SHA-256 (HMAC-SHA-256) en el valor de entrada.

  • Anonimización: sustituye los datos originales por un carácter especificado, ya sea de forma parcial o completa.

  • Asignación a segmentos: sustituye un valor más identificable por otro menos distinguible.

  • Sustitución: sustituye los datos originales por un token o el nombre del infoType si se detecta.

Selección de método

La elección del mejor método de anonimización puede variar en función del caso práctico. Por ejemplo, si una aplicación antigua está procesando los registros anonimizados, puede que sea importante conservar el formato. Si trabajas con números de 10 dígitos con un formato estricto, FPE conserva la longitud (10 dígitos) y el conjunto de caracteres (numérico) de una entrada para que sea compatible con sistemas antiguos.

Sin embargo, si no se requiere un formato estricto por motivos de compatibilidad con versiones anteriores, como ocurre con los valores de la columna Card Holder's Name, DE es la opción preferida porque tiene un método de autenticación más seguro. Tanto FPE como DE permiten que los tokens se inviertan o se des-tokenicen. Si no necesitas destokenización, el cifrado criptográfico proporciona integridad, pero los tokens no se pueden revertir.

Otros métodos, como el enmascaramiento, la agrupación en contenedores, el desplazamiento de fechas y la sustitución, son adecuados para valores que no necesitan mantener la integridad completa. Por ejemplo, si se asigna un valor de edad (por ejemplo, 27) a un intervalo de edad (20-30), se puede seguir analizando y, al mismo tiempo, se reduce la singularidad que podría llevar a la identificación de una persona.

Claves de cifrado de tokens

Para las transformaciones de desidentificación criptográficas, se necesita una clave criptográfica, también conocida como clave de cifrado de token. La clave de cifrado de tokens que se usa para el cifrado de desidentificación también se usa para volver a identificar el valor original. La creación y gestión seguras de las claves de cifrado de tokens no se tratan en este documento. Sin embargo, hay algunos principios importantes que se deben tener en cuenta y que se usan más adelante en los tutoriales asociados:

  • No uses claves de texto sin formato en la plantilla. En su lugar, usa Cloud KMS para crear una clave encapsulada.
  • Usa claves de cifrado de token independientes para cada elemento de datos con el fin de reducir el riesgo de que se vulneren las claves.
  • Rotar las claves de cifrado de tokens. Aunque puedes rotar la clave envuelta, si rotas la clave de cifrado del token, se romperá la integridad de la tokenización. Cuando se rota la clave, debes volver a tokenizar todo el conjunto de datos.

Plantillas de Protección de Datos Sensibles

En el caso de los despliegues a gran escala, utilice las plantillas de Protección de Datos Sensibles para hacer lo siguiente:

  • Habilita el control de seguridad con Gestión de Identidades y Accesos (IAM).
  • Desacopla la información de configuración y cómo anonimizas esa información de la implementación de tus solicitudes.
  • Reutilizar un conjunto de transformaciones. Puede usar las plantillas de desidentificación y reidentificación en varios conjuntos de datos.

BigQuery

El último componente de la arquitectura de referencia es la visualización y el trabajo con los datos anonimizados en BigQuery. BigQuery es la herramienta de almacén de datos de Google que incluye infraestructura sin servidor, BigQuery ML y la posibilidad de ejecutar Protección de Datos Sensibles como herramienta nativa. En la arquitectura de referencia de ejemplo, BigQuery actúa como almacén de datos de los datos anonimizados y como backend de una canalización de datos de reidentificación automatizada que puede compartir datos a través de Pub/Sub.

Siguientes pasos