Arquitectura de ejemplo para usar un proxy de DLP a fin de consultar una base de datos que contiene datos sensibles

En este documento, se describe cómo usar Cloud Data Loss Prevention (Cloud DLP) para mitigar el riesgo de exponer los datos sensibles que están almacenados en las bases de datos de Google Cloud a los usuarios y, aun así, permitirles consultar datos significativos.

Puede haber datos sensibles en toda la empresa. Los datos que se recopilan, procesan y comparten pueden contener distintos tipos de información, como la información de identificación personal (PII) que está sujeta a políticas o normas internas y externas. Además de emplear controles de seguridad adecuados para restringir el acceso a los datos sensibles, puedes usar estas técnicas con el fin de proteger los datos en uso. La desidentificación ayuda a lograr un equilibrio entre la utilidad y la privacidad de los datos mediante técnicas como el enmascaramiento de datos, el agrupamiento y la asignación de token.

La asignación de token reemplaza los datos sensibles por valores subrogados llamados tokens, que representan el valor sensible original (sin procesar) cuando se consultan o se ven los datos. Este proceso se suele denominar seudonimización o reemplazo subrogado. El concepto de asignación de token se usa en sectores como las finanzas y la atención médica para disminuir el riesgo de los datos en uso, reducir el alcance del cumplimiento y minimizar la exposición de los datos sensibles a personas o sistemas que no los necesitan.

Con Cloud DLP, puedes clasificar y desidentificar datos sensibles por lotes y en tiempo real. La clasificación es un proceso que consiste en identificar la información sensible y decidir de qué tipo es. En este documento, se analiza en qué lugares puedes emplear estas técnicas de desidentificación y cómo usar un proxy para llevar a cabo estas tareas.

En el siguiente diagrama, se ilustra la situación que se describe en este documento.

Arquitectura de los datos almacenados en Cloud Storage, transferidos a través de ETL y consultados por los usuarios

  • Los datos se almacenan en reposo en Cloud Storage. Por ejemplo, los datos que se reciben de un socio.
  • Los datos se transfieren a través de un proceso de extracción, transformación y carga (ETL) a una base de datos SQL.
  • Los usuarios consultan los datos de esta base de datos para realizar análisis.

En esta situación, los resultados que muestra la consulta son datos sin procesar, por lo que se muestran datos sensibles, y es posible que se expongan datos de PII al usuario que ejecuta la consulta. Debes diseñar la aplicación para auditar y evitar consultas no autorizadas de datos sensibles.

Arquitectura del proxy de DLP

Una forma de proteger los datos de PII es pasar todas las consultas y los resultados a través de un servicio que analice, inspeccione y registre los resultados o los desidentifique mediante Cloud DLP antes de mostrar los datos solicitados al usuario. En este documento, este servicio se llama proxy de DLP.

La aplicación de proxy de DLP acepta una consulta de SQL como entrada, la ejecuta en la base de datos y, luego, aplica el servicio de Cloud DLP a los resultados antes de mostrarlos al usuario que solicita los datos.

En el siguiente diagrama, se ilustra la arquitectura de la aplicación de proxy de DLP.

Arquitectura de la app de proxy de DLP con comandos de transformación de datos

Cloud DLP permite la configuración detallada de los tipos de datos que se deben inspeccionar y de cómo transformarlos en función de estos resultados de inspección o de la estructura de los datos (por ejemplo, nombres de campos). Para simplificar la creación y la administración de la configuración, debes usar las plantillas de Cloud DLP. La aplicación de proxy de DLP hace referencia a las plantillas de inspección y desidentificación.

Puedes usar plantillas para crear y conservar la información de configuración mediante Cloud DLP. Las plantillas son útiles para separar la información de configuración (por ejemplo, qué inspeccionas y cómo lo desidentificas) de la implementación de las solicitudes. Para obtener más información sobre las plantillas, consulta las plantillas de Cloud DLP.

Los registros de auditoría de Cloud es un servicio de registro integrado de Google Cloud que se usa en esta arquitectura. En primer lugar, este servicio proporciona un registro de auditoría de las llamadas realizadas a la API de DLP. Las entradas del registro de auditoría incluyen información sobre quién realizó la llamada a la API y con qué proyecto de Cloud se ejecutó, además de detalles sobre la solicitud (también se indica si se usó una plantilla como parte de la solicitud). En segundo lugar, si usas el archivo de configuración de la aplicación para activar la auditoría, los registros de auditoría de Cloud registran un resumen de los resultados de la inspección.

Cloud Key Management Service (Cloud KMS) es un servicio de administración de claves alojado en la nube de Google Cloud que te permite administrar claves criptográficas para los servicios en la nube.

En los métodos de Cloud DLP para la asignación de token y el cambio de fecha, se usa criptografía para generar los valores de reemplazo. Estos métodos criptográficos usan una clave para encriptar los valores de manera coherente a fin de mantener la integridad referencial o, en el caso de los métodos que son reversibles, quitar la asignación de token. Puedes proporcionar esta clave directamente a Cloud DLP cuando se realiza la llamada o puedes unirla mediante Cloud KMS. La unión de la clave en Cloud KMS proporciona otra capa de control de acceso y auditoría y, por lo tanto, es el método preferido para las implementaciones de producción.

En una configuración de producción, debes usar el principio de privilegio mínimo para asignar permisos. En el siguiente diagrama, se ilustra un ejemplo de este principio.

Configuración de producción con tres personas y sus permisos

En el diagrama anterior, se muestra una configuración de producción típica en la que hay tres personas con diferentes funciones y acceso a los datos sin procesar:

  • Administrador de la infraestructura: Instala y configura el proxy para tener acceso al entorno de procesamiento en el que está instalado el proxy de Cloud DLP.
  • Analista de datos: Accede al cliente que se conecta al proxy de DLP.

  • Administrador de seguridad: Clasifica los datos, crea las plantillas de Cloud DLP y configura Cloud KMS.

Si deseas obtener más información sobre el uso de Cloud KMS para encriptar y desencriptar datos, consulta Encripta y desencripta datos. Para obtener más información sobre cómo usar una clave unida, consulta la muestra de código deindentification.java.

En el caso del proxy de DLP que se usa en este documento, toda esta información se configura en una plantilla de desidentificación de Cloud DLP.

Protección de la PII mediante la auditoría, el enmascaramiento y la asignación de token

Existen dos estrategias que puedes implementar para mitigar el riesgo de exponer la PII en esta situación.

Datos sin procesar almacenados en la base de datos

Si la aplicación almacena datos sin procesar en una base de datos, puedes usar el proxy de DLP a fin de procesar los resultados que se muestran al usuario. Para ello, inspecciona cualquier resultado sensible y genera una auditoría de él, todo de forma automática. También puedes enmascarar los resultados de la consulta en tiempo real, como se ilustra en el siguiente diagrama.

Arquitectura en la que se enmascaran los resultados de las consultas en tiempo real

Esta configuración requiere que uses un cliente de SQL que se conecte al proxy de DLP. Si habilitas la auditoría en la app, se crea un registro en los registros de auditoría de Cloud con un resumen de los resultados de la inspección. En este resumen, se indica qué tipo de información sensible se mostró en la consulta.

Datos almacenados en formato desidentificado

Si no deseas almacenar los datos sin procesar, puedes almacenar los datos para la aplicación en formato desidentificado o enmascarado mediante transformaciones de desidentificación durante el proceso de ETL en la base de datos, como se ilustra en el siguiente diagrama.

Arquitectura en la que se enmascaran los resultados de la consulta durante el proceso de ETL

En el diagrama anterior, se ilustra el flujo básico, en el que los datos se inspeccionan y enmascaran antes de que se transfieran a la base de datos. Cuando un usuario consulta estos datos, aunque tenga acceso sin procesar a la base de datos, solo puede ver la versión enmascarada.

Si permites que el usuario vea los datos sin enmascarar, debes usar un cliente que pueda conectarse a una instancia del proxy de DLP que tenga permiso para desenmascarar los datos, como se ilustra en el siguiente diagrama.

Arquitectura en la que se usa un cliente para conectarse al proxy de DLP a fin de ver los datos sin enmascarar

En el diagrama anterior, se ilustra cómo puedes usar un cliente para conectarte al proxy de DLP a fin de permitir que se le muestren al cliente los datos sin enmascarar.

Próximos pasos