Desidentificación y reidentificación de PII en conjuntos de datos a gran escala con Cloud DLP

En este documento, se analiza cómo usar Cloud Data Loss Prevention (Cloud DLP) para crear una canalización de transformación de datos automatizada a fin de desidentificar datos sensibles, como la información de identificación personal (PII). Las técnicas de desidentificación, como la asignación de tokens (seudonimización), te permiten conservar la utilidad de tus datos para la unión o las estadísticas y, al mismo tiempo, disminuir el riesgo de la manipulación de datos mediante la ofuscación de los identificadores de confidencialidad sin procesar. A fin de minimizar el riesgo de manipular grandes volúmenes de datos sensibles, puedes usar una canalización de transformación de datos automatizada para crear réplicas desidentificadas. Cloud DLP permite transformaciones como el ocultamiento, el enmascaramiento, la asignación de tokens, el agrupamiento y otros métodos de desidentificación. Cuando un conjunto de datos no está identificado, Cloud DLP también puede inspeccionarlos en busca de información sensible mediante el uso de más de 100 clasificadores integrados.

Este documento está dirigido a un público técnico cuyas responsabilidades incluyen la seguridad, el procesamiento o el análisis de datos. En esta guía, se supone que estás familiarizado con el procesamiento y la privacidad de datos, sin necesidad de ser un experto.

Este documento forma parte de una serie:

Arquitectura de referencia

En el siguiente diagrama, se muestra una arquitectura de referencia para usar productos de Google Cloud a fin de agregar una capa de seguridad a los conjuntos de datos sensibles mediante técnicas de desidentificación.

Arquitectura de la canalización de desidentificación, administración de configuración y canalización de reidentificación

La arquitectura consta de lo siguiente:

  • Canalización de transmisión de desidentificación de datos: desidentifica datos sensibles en texto con Dataflow. Puedes volver a usar la canalización para varias transformaciones y casos prácticos.

  • Administración de la configuración (plantilla y clave de DLP): una configuración de desidentificación administrada a la que solo puede acceder un pequeño grupo de personas, por ejemplo, los administradores de seguridad, a fin de evitar exponer métodos de desidentificación y claves de encriptación.

  • Canalización de reidentificación y validación de datos: valida las copias de los datos desidentificados y usa una canalización de Dataflow para reidentificar datos a gran escala.

Ayuda para proteger datos sensibles

Una de las tareas clave de cualquier empresa es 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, incluida la encriptación de datos almacenados y la encriptación de datos en tránsito.

Encriptación en reposo: Cloud Storage

Mantener la seguridad de los datos es fundamental para la mayoría de las organizaciones. El acceso no autorizado, incluso a datos moderadamente sensibles, puede dañar la confianza, las relaciones y la reputación que tienes con tus clientes. Google encripta los datos almacenados en reposo de forma predeterminada. De forma predeterminada, cualquier objeto subido a un depósito de Cloud Storage se encripta con una clave de encriptación administrada por Google. Si tu conjunto de datos usa un método de encriptación preexistente y requiere una opción no predeterminada antes de subirse, Cloud Storage proporciona otras opciones de encriptación. Para obtener más información, consulta Opciones de encriptación de datos.

Encriptación en tránsito: Dataflow

Cuando tus datos están en tránsito, la encriptación en reposo no está implementada. Los datos en tránsito están protegidos por protocolos de red seguros denominados encriptación en tránsito. De forma predeterminada, Dataflow usa claves de encriptación administradas por Google. Los instructivos asociados con este documento utilizan una canalización automatizada que emplea claves de encriptación predeterminadas administradas por Google.

Transformaciones de datos de Cloud DLP

Cloud DLP realiza dos tipos de transformaciones principales:

Los métodos recordTransformations y infoTypeTransformations pueden desidentificar y encriptar información sensible en tus datos. Por ejemplo, puedes transformar los valores en la columna US_SOCIAL_SECURITY_NUMBER para que no puedan identificarse o usar la asignación de token a fin de ocultarlos manteniendo la integridad referencial.

El método infoTypeTransformations te permite inspeccionar datos sensibles y transformar el resultado. Por ejemplo, si tienes datos no estructurados o de texto libre, el método infoTypeTransformations puede ayudarte a identificar un NSS dentro de una oración, encriptar el valor del NSS y conservar el resto del texto intacto. También puedes definir métodos infoTypes personalizados.

El método recordTransformations te permite aplicar una configuración de transformación por campo cuando usas datos estructurados o tabulares. Con el método recordTransformations, puedes aplicar la misma transformación en todos los valores de ese campo, como la generación de un hash o la asignación de tokens a cada valor de una columna cuyo nombre de campo o encabezado sea SSN.

Con el método recordTransformations también puedes integrar 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 a fin de ocultar cualquier resultado de US_SOCIAL_SECURITY_NUMBER que se encuentre dentro del texto en el campo.

En orden creciente de complejidad, los procesos de desidentificación son los siguientes:

  • Ocultamiento: quita el contenido sensible sin reemplazarlo.
  • Enmascaramiento: reemplaza el contenido sensible con caracteres fijos.
  • Encriptación: reemplaza el contenido sensible con strings encriptadas, posiblemente de manera reversible.

Trabaja con datos delimitados

A menudo, los datos constan de registros delimitados por un carácter seleccionado, con tipos fijos en cada columna, como un archivo CSV. Para esta clase de datos, puedes aplicar transformaciones de desidentificación (recordTransformations) directamente, sin inspeccionar los datos. Por ejemplo, puedes esperar que una columna con la etiqueta SSN solo contenga datos de NSS. No es necesario inspeccionar los datos para saber que el detector infoType es US_SOCIAL_SECURITY_NUMBER. Sin embargo, las columnas de formato libre con la etiqueta Additional Details pueden contener información sensible, pero la clase infoType es desconocida de antemano. En una columna de formato libre, debes inspeccionar el detector infoTypes (infoTypeTransformations) antes de aplicar las transformaciones de desidentificación. Cloud DLP permite que ambos tipos de transformaciones coexistan en una sola plantilla de desidentificación. Cloud DLP incluye más de 100 detectores infoTypes integrados. También puedes crear tipos personalizados o modificar los detectores infoTypes integrados a fin de buscar datos sensibles que sean únicos para tu organización.

Determina el tipo de transformación

Determinar cuándo usar el método recordTransformations o infoTypeTransformations depende de tu caso de uso. Debido a que usar el método infoTypeTransformations requiere más recursos y, por lo tanto, es más costoso, recomendamos usar este método solo para situaciones en las que el tipo de datos se desconozca. Puedes evaluar los costos de ejecutar Cloud DLP con la calculadora de precios de Google Cloud.

Para proporcionar ejemplos de transformación, este documento tiene varios instructivos asociados que usan un conjunto de datos. El conjunto de datos 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 DLP
Card Number No aplicable Encriptación determinista (DE)
Card Holder's Name No aplicable Encriptación determinista (DE)
Card PIN No aplicable Hashing criptográfico
SSN (Social Security Number) No aplicable Enmascaramiento
Age No aplicable Agrupamiento
Job Title No aplicable Agrupamiento
Additional Details Integrado:
IBAN_CODE, EMAIL_ADDRESS, PHONE_NUMBER
Personalizado:
ONLINE_USER_ID
Reemplazo

En esta tabla, se enumeran los nombres de las columnas y se describe qué tipo de transformación es necesaria para cada una. Por ejemplo, la columna Card Number contiene números de tarjetas de crédito que se deben encriptar. Sin embargo, 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 Additional Details. Esta columna es de formato libre y puede contener PII, que, a los fines de esta serie, debe detectarse y desidentificarse.

Los ejemplos en esta tabla presentan cinco transformaciones de desidentificación diferentes:

  • Asignación de tokens bidireccional: reemplaza los datos originales con un token determinista que conserva la integridad referencial. Puedes usar el token para unir datos o usarlo en el análisis agregado. Puedes revertir o quitar el token de los datos con la misma clave que usaste para crearlo. Existen dos métodos para la asignación de tokens bidireccional:

    • Encriptación determinista (DE): reemplaza los datos originales con un valor encriptado codificado en base64 y no conserva el grupo de caracteres ni la longitud originales.
    • Encriptación de preservación de formato con FFX (FPE-FFX): reemplaza los datos originales con un token generado mediante la encriptación de preservación de formato en modo FFX. Por diseño, FPE-FFX conserva la longitud y el grupo de caracteres del texto de entrada. Carece de autenticación y de un vector de inicialización, lo que puede causar una expansión de la longitud del token de salida. Otros métodos, como la DE, proporcionan garantías de seguridad más sólidas y se recomiendan para casos prácticos de asignación de tokens, a menos que la preservación de la longitud y el grupo de caracteres sean requisitos estrictos, como la retrocompatibilidad con sistemas de datos heredados.
  • Asignación de tokens unidireccional con Hashing criptográfico: reemplaza el valor original con un valor de hash y conserva la integridad referencial. Sin embargo, a diferencia de la asignación de tokens bidireccional, un método unidireccional no es reversible. El valor de hash se genera mediante un código de autenticación de mensaje basado en SHA-256 (HMAC-SHA-256) en el valor de entrada.

  • Enmascaramiento: reemplaza los datos originales con un carácter especificado, ya sea de forma parcial o total.

  • Agrupamiento: reemplaza un valor más identificable con un valor menos distintivo.

  • Reemplazo: reemplaza los datos originales con un token o el nombre del infoType, si se detecta.

Selección de métodos

Elegir el mejor método de desidentificación dependerá de tu caso práctico. Por ejemplo, si una aplicación heredada está procesando los registros desidentificados, la preservación del formato podría ser importante. Si se trata de números con un formato estricto de 10 dígitos, la encriptación de preservación de formato (FPE) conserva la longitud (10 dígitos) y el grupo de caracteres (numérico) de una entrada para la compatibilidad con sistemas heredados.

Sin embargo, si no se requiere un formato estricto para la compatibilidad heredada, como es el caso de los valores en la columna Card Holder's Name, la DE es la opción preferida porque tiene un método de autenticación más sólido. Tanto la FPE como la DE permiten que los tokens se reviertan o se desasignen. Si la desasignación de tokens no es necesaria, el hashing criptográfico proporciona integridad, pero los tokens no se pueden revertir.

Otros métodos, como el enmascaramiento, el agrupamiento, el cambio de fechas y el reemplazo, son buenos para los valores que no necesitan mantener una integridad completa. Por ejemplo, el agrupamiento de un valor de edad (por ejemplo, 27) a un rango de edad (de 20 a 30) aún puede analizarse mientras se reduce la unicidad que podría conducir a la identificación de un individuo.

Claves de encriptación de token

Para las transformaciones de desidentificación criptográfica, se requiere una clave criptográfica, también conocida como clave de encriptación de token. La clave de encriptación de token que se usa para la encriptación de desidentificación también se usa con el objetivo de reidentificar el valor original. La creación y administración segura de claves de encriptación de token no se incluyen en este documento. Sin embargo, hay algunos principios importantes para tener en cuenta que se usarán más adelante en los instructivos asociados:

  • Evita usar claves de texto simple en la plantilla. En su lugar, usa Cloud KMS para crear una clave unida.
  • Usa claves de encriptación de token diferentes para cada elemento de datos a fin de reducir el riesgo de comprometer las claves.
  • Rota las claves de encriptación de token. Aunque puedes rotar la clave unida, rotar la clave de encriptación de token interrumpe la integridad de la asignación de tokens. Cuando se rota la clave, debes volver a asignar un token para todo el conjunto de datos.

Plantillas de Cloud DLP

Para implementaciones a gran escala, usa las plantillas de Cloud DLP a fin de lograr lo siguiente:

  • Habilita el control de seguridad con la administración de identidades y accesos (IAM).
  • Desacoplar la información de configuración, y el modo de desidentificar esa información, de la implementación de tus solicitudes.
  • Reutilizar un conjunto de transformaciones. Puedes usar las plantillas de desidentificación y reidentificación en varios conjuntos de datos.

Los instructivos asociados te guiarán en el proceso de crear y administrar plantillas de Cloud DLP.

BigQuery

El componente final de la arquitectura de referencia es ver y trabajar con los datos desidentificados en BigQuery. BigQuery es la herramienta de almacén de datos de Google que incluye infraestructura sin servidores, BigQuery ML y la capacidad de ejecutar Cloud DLP como una herramienta nativa. En los siguientes instructivos, BigQuery funciona como almacén de datos para datos desidentificados y como backend para una canalización de datos de reidentificación automatizada que puede compartir datos a través de Pub/Sub.

A fin de obtener más información sobre las aplicaciones avanzadas de BigQuery ML y los datos sensibles, consulta Consideraciones para datos sensibles dentro de los conjuntos de datos de aprendizaje automático.

¿Qué sigue?