En este documento, se describe el uso de la Protección de datos sensibles para mitigar el riesgo de exponer los datos sensibles almacenados en las bases de datos de Google Cloud a los usuarios y permitirles consultar datos significativos de todos modos.
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 la Protección de datos sensibles, 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.
- 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 la Protección de datos sensibles 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 Protección de datos sensibles 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.
La Protección de datos sensibles 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 Protección de datos sensibles. 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 la Protección de datos sensibles. 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 Protección de datos sensibles.
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, los Registros de auditoría de Cloud proporcionan un registro de auditoría de las llamadas realizadas a la API de Cloud Data Loss Prevention (parte de la Protección de datos sensibles). Las entradas del registro de auditoría incluyen información sobre quién realizó la llamada a la API y con qué proyecto de Google 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 la Protección de datos sensibles 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 la Protección de datos sensibles 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.
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 Protección de datos sensibles.
Analista de datos: Accede al cliente que se conecta al proxy de DLP.
Administrador de seguridad: Clasifica los datos, crea las plantillas de Protección de datos sensibles 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.
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 la Protección de datos sensibles.
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.
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.
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.
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.
¿Qué sigue?
- Controla los datos: cómo la asignación de token permite que los datos se puedan usar sin sacrificar la privacidad.
Explora la siguiente documentación técnica de la Protección de datos sensibles:
Explora arquitecturas de referencia, diagramas y prácticas recomendadas sobre Google Cloud. Consulta nuestro Cloud Architecture Center.