Prevención de pérdida de datos en la computación en la nube: API DLP de GCP

La Protección de Datos Sensibles (anteriormente Cloud DLP) es el servicio administrado de Google Cloud para descubrir, clasificar y anonimizar información personal identificable (PII) en texto, imágenes y almacenes de datos estructurados como BigQuery y Cloud Storage. Es importante porque una sola exportación sin censurar puede activar una notificación de incumplimiento del RGPD o PCI DSS. Acción recomendada: redirigir los campos sensibles a través de un proxy DLP con claves de tokenización encapsuladas en Cloud KMS y IAM con privilegios mínimos antes de que los datos salgan del almacenamiento.

Puntos Clave

Google cambió el nombre de Cloud DLP a Protección de datos sensiblesLa interfaz REST/gRPC subyacente sigue siendo la API DLP, cuyas tres capacidades principales son el descubrimiento, la inspección y la anonimización.
La tokenización y el cifrado que preserva el formato dentro de la API de DLP pueden ejecutarse en una clave encapsulada en Cloud KMS (custodia nativa) o en una clave AES sin procesar proporcionada por el cliente (custodia externa, equivalente a HYOK); la mayoría de las implementaciones de producción deberían usar el modelo de clave encapsulada.
Un proxy DLP de producción debe separar las funciones de administrador de infraestructura, analista de datos y administrador de seguridad para que ninguna identidad pueda clasificar datos y leer el código fuente sin censurar al mismo tiempo.
La rotación de claves de Cloud KMS crea nuevas versiones de clave, pero nunca elimina automáticamente las antiguas; los equipos aún deben programar la destrucción de las claves de tokenización obsoletas.
La protección de datos sensibles factura por separado la inspección, la transformación y el descubrimiento, por lo que el modelo de costes debe tener en cuenta los tres antes de una migración de gran envergadura.

Publicado: enero de 2021. Actualizado: agosto de 2026. Revisado por el equipo de protección de datos en la nube de Encryption Consulting.

Esta publicación se centra en cómo diseñar la protección de datos confidenciales para su uso en producción en Google Cloud. Para obtener una definición independiente del proveedor sobre la prevención de pérdida de datos y una comparación de las herramientas de DLP entre las distintas categorías, consulte nuestra explicación del Centro de Educación sobre qué es la prevención de pérdida de datos (DLP) y las soluciones de DLP . Para saber cómo gestionar la clave de cifrado en las distintas nubes, consulte AWS KMS frente a Azure Key Vault frente a GCP KMS.

¿Qué es la protección de datos confidenciales (anteriormente conocida como DLP en la nube)?

La protección de datos confidenciales es el nombre que Google Cloud le da a lo que antes se comercializaba como Cloud DLP; el punto final de la API aún se llama API de prevención de pérdida de datos en la nube (API DLP). Permite a las organizaciones detectar la presencia de información de identificación personal (PII) y otros datos confidenciales en flujos de datos no estructurados proporcionados por el usuario, como un párrafo de texto, una imagen o una grabación de audio convertida a texto mediante la API de conversión de voz a texto. El servicio también se ejecuta directamente sobre los datos que ya se encuentran en Google Cloud Storage, BigQuery y Cloud SQL.

La protección de datos confidenciales cuenta con tres capacidades distintas que a menudo se confunden en conversaciones informales: el análisis de descubrimiento crea perfiles de toda una organización, carpeta o proyecto para mostrar dónde es probable que residan los datos confidenciales y de alto riesgo; la inspección realiza un escaneo profundo de un recurso para devolver la ubicación exacta de cada instancia coincidente; y la anonimización oculta las instancias coincidentes mediante enmascaramiento, censura, agrupación, cambio de fecha o tokenización. Una cuarta capacidad, el análisis de riesgos, evalúa el riesgo de reidentificación en los datos estructurados de BigQuery antes y después de la anonimización.

Diagrama de arquitectura de protección de datos confidenciales (Cloud DLP) que muestra los flujos de inspección, anonimización y descubrimiento en Google Cloud.

¿Cómo detecta y clasifica la protección de datos sensibles los datos sensibles?

La detección se basa en los detectores infoType, término que utiliza Google para referirse a los clasificadores de aprendizaje automático y coincidencia de patrones que reconocen una categoría específica de datos confidenciales (un número de la Seguridad Social estadounidense, un número de tarjeta de crédito, una dirección de correo electrónico). La propia referencia infoType de Google ahora incluye más de 200 detectores integrados que abarcan documentos de identidad, datos financieros, identificadores de salud y credenciales en docenas de países. Además, las organizaciones pueden definir detectores personalizados con expresiones regulares, diccionarios o reglas de contexto para cualquier dato propietario, como un formato interno de número de cuenta.

La protección de datos sensibles incluye más de 200 configuraciones predefinidas. Detectores de infoTypey las organizaciones pueden agregar detectores personalizados para formatos internos.
Después de detectar datos confidenciales, la API puede censurarlos, máscaratokenizar o transformar texto e imágenes para preservar la privacidad.
Se trata de un servicio totalmente gestionado; Google adapta las tareas de inspección y transformación al volumen de datos enviados sin necesidad de que el cliente gestione la infraestructura.
Los resultados de la clasificación se pueden escribir directamente en BigQuery para su análisis o exportar a otro entorno para su posterior procesamiento.
La protección de datos confidenciales/DLP en la nube se somete a auditorías independientes de terceros que abarcan el manejo de datos, la privacidad y los controles de seguridad.

¿Cómo funciona el control de claves nativo frente al control de claves externo para la tokenización y FPE?

Las transformaciones de tokenización y cambio de fecha de Sensitive Data Protection utilizan criptografía para generar valores de reemplazo, y dicha criptografía requiere una clave. Puede proporcionar esa clave de tres maneras diferentes, y la elección determinará quién puede reidentificar técnicamente los datos posteriormente.

Modelo de control de llaves	Cómo funciona	Mejor ajuste
Nativo (clave sin procesar)	La clave AES se pasa directamente en el cuerpo de la solicitud a la API en cada llamada.	Solo para prototipos y datos de prueba efímeros; nunca para producción, ya que la clave se expone en cada solicitud y en Cloud Logging a menos que se excluya explícitamente.
Clave encapsulada en Cloud KMS (equivalente a BYOK)	La clave AES se cifra ("encapsula") mediante una clave de Cloud KMS, y solo el texto cifrado encapsulado se envía a la API de DLP; la API llama a Cloud KMS para desencapsularlo en cada operación.	Implementaciones en producción. Agrega control de acceso gobernado por IAM y un registro completo de auditoría en la nube para cada operación de desempaquetado.
Externo/equivalente a HYOK (ECM en la nube)	La clave Cloud KMS a la que se hace referencia anteriormente está respaldada por un administrador de claves externo a través de Cloud External Key Manager (EKM), por lo que Google nunca almacena el material de la clave sin cifrar.	Cargas de trabajo reguladas (servicios financieros, gobierno) donde un requisito contractual o reglamentario exige que el proveedor de la nube nunca posea material clave utilizable.

La mayoría de las organizaciones deberían optar por el modelo con Cloud KMS como método predeterminado. Envolver la clave en Cloud KMS añade una capa de control de acceso y auditoría que va más allá de lo que ofrece una clave sin encapsular, y la propia documentación de Google lo considera el método preferido para implementaciones en producción. Reserve Cloud EKM/HYOK para el reducido grupo de cargas de trabajo en las que lo exija un organismo regulador o un contrato con el cliente, ya que añade latencia y una dependencia externa a cada llamada de tokenización/reidentificación.

¿Cómo controla IAM el acceso en una arquitectura de proxy DLP?

Una forma fiable de eliminar la información de identificación personal (PII) antes de que llegue al consumidor es redirigir las consultas y los resultados a través de un módulo que analiza, inspecciona y registra los hallazgos, y luego anonimiza los resultados mediante la protección de datos sensibles antes de devolver o reenviar los datos. Este módulo se conoce comúnmente como proxy DLP : acepta una consulta SQL como entrada, la ejecuta en la base de datos y aplica la API DLP a los resultados antes de devolverlos al solicitante.

Diagrama de arquitectura de una aplicación proxy de DLP en la nube que inspecciona y anonimiza los resultados de las consultas SQL.

Cloud Audit Logs es el servicio de registro integrado de Google Cloud para esta arquitectura, y registra quién realizó cada llamada a la API de DLP, en qué proyecto se ejecutó y si se utilizó una plantilla. Si la auditoría está habilitada en la configuración del proxy, Cloud Audit Logs también registra un resumen de los resultados de la inspección.

La protección de datos sensibles también admite plantillas reutilizables. inspect y de-identify Configuraciones que definen qué buscar y cómo transformar las coincidencias, referenciadas por nombre en lugar de repetirse en línea. Un proxy DLP de producción debe referenciar tanto una plantilla de inspección como una plantilla de anonimización, en lugar de definir reglas de detección ad hoc para cada llamada.

Arquitectura IAM de privilegios mínimos para un proxy DLP que muestra los roles de administrador de infraestructura, analista de datos y administrador de seguridad.

Para la producción, aplique el principio de mínimo privilegio a tres perfiles de usuario distintos, de modo que ninguna identidad individual pueda acceder a los datos sin procesar y, al mismo tiempo, reconfigurar las reglas de detección:

Administración de infraestructura Instala y configura el entorno informático del proxy, pero no tiene permisos de IAM para la propia API de protección de datos confidenciales.
Analista de datos Solo accede a la aplicación cliente que se conecta al proxy DLP, nunca a la base de datos subyacente ni a la clave Cloud KMS.
Administrador de seguridad clasifica los datos, crea y mantiene las plantillas de inspección/desidentificación y es la única identidad con cloudkms.cryptoKeyEncrypterDecrypter en la clave de envoltura.

¿Cómo se debe gestionar la rotación de claves envueltas para la tokenización?

Al rotar la clave de Cloud KMS que encapsula una clave de tokenización, se crea una nueva versión activa de la clave, pero Google Cloud aclara que la rotación "no vuelve a cifrar los datos ni desactiva ni elimina las versiones anteriores de la clave". Esta distinción es importante específicamente para la tokenización: si se rota la clave de encapsulación sin un plan para volver a encapsular y tokenizar, los tokens existentes generados con la versión anterior de la clave se vuelven irrecuperables una vez que dicha versión se destruye, ya que la tokenización determinista vincula la reidentificación a la versión exacta de la clave utilizada para crear el token.

Un procedimiento seguro de rotación consta de tres pasos: rotar la clave de encapsulación de Cloud KMS según un cronograma (la recomendación general de Google es aproximadamente cada 90 días para las claves simétricas, aunque Cloud KMS no impone un intervalo de rotación mínimo o máximo fijo); volver a encapsular la clave de tokenización AES con la nueva versión de la clave de Cloud KMS; y solo entonces programar la destrucción de la versión anterior de la clave de Cloud KMS, con un retraso deliberado (Cloud KMS establece por defecto una ventana de destrucción programada de 30 días, configurable según la política de la organización) lo suficientemente largo como para confirmar que ningún token pendiente aún dependa de ella.

¿Qué información debe registrar al utilizar la protección de datos confidenciales?

Registros de llamadas a la API de DLP: Identidad de la persona que llama, proyecto y si se hizo referencia a una plantilla de inspección/desidentificación, a través de los registros de auditoría de la nube.
Resumen de los hallazgos de la inspección: Se muestran los recuentos y las categorías de infoType coincidentes, habilitados a través de la configuración de auditoría de la propia aplicación proxy en lugar de registrar las coincidencias sin procesar.
Desempaquetado de eventos de Cloud KMS: todas Decrypt/AsymmetricDecrypt Se realiza una llamada contra la clave de envoltura, de modo que un administrador de seguridad pueda detectar actividad de reidentificación anómala.
Registros de exportación de BigQuery: Cuando los resultados de un descubrimiento o una inspección se escriben en BigQuery para su análisis, el registro de auditoría estándar de BigQuery cubre quién consultó posteriormente los resultados analizados.

Nunca registre el valor de coincidencia sin censurar; registre la categoría InfoType, la ubicación y la identidad que activó el análisis. Registrar la información personal identificable (PII) anula el propósito de ejecutar DLP.

¿Cuánto cuesta la protección de datos confidenciales?

La protección de datos sensibles factura por separado la inspección, la transformación (anonimización) y el descubrimiento, y la tarifa depende de si el trabajo se ejecuta en el almacenamiento (BigQuery, Cloud Storage, Cloud SQL) o en el contenido enviado directamente a través de la API. Precios orientativos a la fecha de este documento (confirme las tarifas actuales en la página de precios de Google antes de elaborar su presupuesto):

Tipo de empleo	Inspección
Tareas de almacenamiento (BigQuery, Cloud Storage, Cloud SQL)	El primer GB al mes es gratis, luego aproximadamente 1.00 $/GB hasta 50 TB, disminuyendo a medida que aumenta el volumen.	Misma estructura por niveles que la inspección
Llamadas a la API de contenido (en tiempo real)	El primer GB al mes es gratis, luego ~$3.00/GB hasta 1 TB.	El primer GB al mes es gratis, luego ~$2.00/GB hasta 1 TB.
Descubrimiento (perfilado de datos)	Modo de consumo: ~$0.03/GB (según perfil), o modo de suscripción con tarifa plana por unidad de suscripción para grandes extensiones de terreno.

Cloud KMS cobra por separado las operaciones de cifrado/descifrado de la clave de envoltura, y estos cargos aumentan según la frecuencia con la que se crean o reidentifican los tokens, no según el volumen de datos analizados. Los equipos que migren una gran infraestructura de BigQuery a la tokenización deben modelar el volumen de operaciones de Cloud KMS junto con el precio por GB de Sensitive Data Protection, ya que una carga de trabajo de reidentificación de alto tráfico puede hacer que el costo de la operación de KMS sea el rubro más grande.

¿Cómo es una arquitectura de prevención de pérdida de datos en la nube múltiple?

Las organizaciones que ejecutan cargas de trabajo en GCP, AWS y Azure rara vez logran estandarizar un único producto DLP, ya que las capacidades de prevención de pérdida de datos de Amazon Macie y Microsoft Purview están limitadas a su propio almacenamiento y a las plataformas de Microsoft 365, respectivamente, del mismo modo que Sensitive Data Protection está limitada a Google Cloud. El modelo práctico para entornos multinube no consiste en una única herramienta DLP que abarque las tres nubes; se trata de una política coherente (las mismas categorías de infoType, las mismas transformaciones de anonimización, el mismo estándar de cifrado de claves) implementada de forma nativa en cada nube, con los resultados de la clasificación centralizados en un SIEM o catálogo de datos para una visibilidad entre nubes.

La capa de gestión de claves es donde la estandarización es realmente factible: independientemente de la nube que almacene los datos, se debe integrar la clave de tokenización/FPE en el sistema de gestión de claves (KMS) nativo de esa nube (Cloud KMS, AWS KMS o Azure Key Vault) con una rotación y un ciclo de revisión de acceso comunes, de modo que un auditor vea un único control, independientemente de la nube que haya generado el hallazgo. Consulte nuestra comparación de AWS KMS, Azure Key Vault y GCP KMS para ver cómo difiere esta capa de gestión de claves nativa entre los distintos proveedores.

¿Cuáles son las limitaciones de la protección de datos sensibles?

La detección es probabilística. Los detectores InfoType reducen los falsos negativos en formatos de información personal identificable comunes, pero no detectarán todos los identificadores propietarios o con formatos inusuales sin un detector personalizado.
No sustituye una estrategia de cifrado o control de acceso. La protección de datos sensibles reduce la exposición de la información que ya se está leyendo o exportando; no impide que una identidad con privilegios excesivos consulte directamente la tabla de origen sin procesar.
La gestión de versiones de claves de tokenización es responsabilidad del cliente. Google no volverá a encapsular ni retirará automáticamente las claves de tokenización; ese ciclo de vida debe integrarse en el manual de operaciones del proxy DLP.
El coste varía en función del volumen de datos en tres dimensiones de facturación distintas (inspección, transformación y descubrimiento), lo que resulta fácil de subestimar en una gran operación de relleno de datos históricos de BigQuery.

Lista de verificación para la toma de decisiones: Implementación de la protección de datos confidenciales en producción.

Antes de definir el alcance de una inspección, identifique qué almacenes de datos (BigQuery, Cloud Storage, Cloud SQL) contienen información personal identificable (PII) regulada.
Seleccione las claves encapsuladas en Cloud KMS como modelo de clave de tokenización/FPE predeterminado; reserve Cloud EKM/HYOK para los casos estipulados por contrato.
Configure un proxy DLP con el modelo de privilegios mínimos de tres perfiles (administrador de infraestructura, analista de datos, administrador de seguridad) en lugar de una cuenta de servicio compartida.
Defina un manual de procedimientos para la rotación de claves de envoltura y la re-tokenización antes de que se emita el primer token de producción, no después.
Antes de comprometerse con una implementación completa del sistema, compare por separado los costos de inspección, transformación y descubrimiento del modelo con el volumen de datos previsto.

¿Qué recomendaría Encryption Consulting?

Observamos constantemente la misma deficiencia en las implementaciones de protección de datos sensibles: los equipos implementan rápidamente la inspección y la anonimización, pero luego no crean el manual de procedimientos de rotación de claves y revisión de acceso para la clave de envoltura de Cloud KMS subyacente, que es precisamente lo primero que pregunta un auditor. El servicio de asesoramiento de protección de datos en la nube de Encryption Consulting diseña la arquitectura del proxy DLP, el modelo IAM de privilegios mínimos y el ciclo de vida de la clave de envoltura de forma conjunta, y nuestra oferta de HSM como servicio proporciona custodia con respaldo de hardware para la clave subyacente de Cloud KMS cuando así lo exige un requisito de cumplimiento.

Preguntas frecuentes

¿Es Cloud DLP el mismo producto que Sensitive Data Protection?

Sí. Google integró Cloud DLP en el nombre más amplio del producto Sensitive Data Protection; el punto final de la API al que llaman los clientes sigue siendo la API de Cloud Data Loss Prevention (API de DLP), y las integraciones existentes no necesitan cambiar.

¿Debo usar Cloud KMS con protección de datos confidenciales?

No, puedes pasar una clave AES sin procesar directamente a las llamadas de tokenización y cambio de fecha. Google recomienda encapsular la clave en Cloud KMS para entornos de producción, ya que esto añade control de acceso gestionado por IAM y un registro de auditoría de Cloud que una clave sin procesar no puede proporcionar.

¿Puede la función de Protección de Datos Sensibles analizar datos fuera de Google Cloud?

Puede inspeccionar el contenido enviado directamente a través de la API, independientemente de su origen, pero su escaneo de trabajos de almacenamiento (el modo de menor coste) se limita a BigQuery, Cloud Storage y Cloud SQL dentro de Google Cloud.

¿Qué sucede si cambio la clave de encapsulación de Cloud KMS sin volver a tokenizar los datos existentes?

Los tokens existentes siguen siendo identificables mientras exista la versión anterior de la clave de Cloud KMS de la que dependen, ya que la rotación por sí sola no elimina las versiones anteriores. El riesgo surge únicamente si esa versión anterior de la clave se destruye posteriormente antes de que se ejecute un proceso de re-tokenización sobre los datos que protege.

¿Qué precio tiene Sensitive Data Protection en comparación con Amazon Macie?

Ambos cobran por volumen de datos procesados en lugar de una tarifa plana, pero las dimensiones de facturación difieren (Sensitive Data Protection separa la inspección, la transformación y el descubrimiento; Macie factura principalmente por los datos evaluados para su clasificación y monitorización). Es recomendable comparar ambos servicios con su volumen de datos real en lugar de comparar directamente los precios de lista, ya que los niveles gratuitos y los puntos de ruptura por GB tienen estructuras diferentes.

¿Listo para cerrar la brecha entre la implementación de la protección de datos confidenciales y la gestión efectiva de las claves que la respaldan? Hable con el equipo de protección de datos en la nube de Encryption Consulting para una revisión del proxy DLP y la gestión de claves.