En este documento, se analiza cómo usar Sensitive Data Protection para crear una canalización de transformación de datos automatizada para 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. Sensitive Data Protection 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, Sensitive Data Protection también puede inspeccionar los datos 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 los datos, sin necesidad de ser un experto.
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.
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 de uso.
Administración de la configuración (plantilla y clave de Sensitive Data Protection): 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, para 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 bucket de Cloud Storage se encripta con una clave que es propiedad de Google y está 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 que son propiedad de Google y están administradas por Google. Los instructivos asociados con este documento utilizan una canalización automatizada que emplea claves predeterminadas de Google y administradas por Google.
Transformaciones de datos de Sensitive Data Protection
Sensitive Data Protection 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. Sensitive Data Protection permite que ambos tipos de transformaciones coexistan en una sola plantilla de desidentificación.
La protección de datos sensibles incluye más de 100 detectores infoTypes integrados.
También puedes crear tipos personalizados o modificar los detectores infoTypes integrados para 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 Sensitive Data Protection con la calculadora de precios de Google Cloud.
Para ver 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 Sensitive Data Protection |
|---|---|---|
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 este ejemplo, 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 seguridad más sólida y se recomiendan para casos de uso 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 Sensitive Data Protection
Para implementaciones a gran escala, usa las plantillas de Sensitive Data Protection para 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.
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 la protección de datos sensibles como una herramienta nativa. En la siguiente arquitectura de referencia, 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.
¿Qué sigue?
- Obtén información sobre cómo usar Sensitive Data Protection para inspeccionar el almacenamiento y las bases de datos en busca de datos sensibles.
- Obtén más información sobre otras soluciones de reconocimiento de patrones.
- Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.