Cifrado con preservación de formato (FPE): uso en GCP

El cifrado que preserva el formato (FPE) es una técnica de cifrado que transforma los datos en un texto cifrado con la misma longitud y conjunto de caracteres que la entrada, como por ejemplo, convertir un número de tarjeta de 16 dígitos en otro número de 16 dígitos. Esto es importante porque permite que los esquemas heredados, las reglas de validación y los sistemas posteriores sigan funcionando sin cambios, mientras que el valor subyacente está protegido criptográficamente. En Google Cloud, utilice el algoritmo FF1 dentro de la Protección de datos confidenciales con una clave encapsulada en Cloud KMS en lugar de una clave sin encapsular o una implementación manual.

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

Para obtener una definición independiente del proveedor sobre el cifrado que preserva el formato y compararlo con otras técnicas de anonimización, consulte nuestro artículo del Centro de Educación " ¿Qué es el cifrado que preserva el formato?" . Para saber cómo gestionar la clave de envoltura subyacente al cifrado que preserva el formato, consulte AWS KMS frente a Azure Key Vault frente a GCP KMS.

¿Qué es el cifrado que preserva el formato?

Si una organización almacena números de tarjetas de crédito de 16 dígitos en una base de datos, y cada sistema, índice y regla de validación posterior espera que ese campo conserve exactamente 16 dígitos, el cifrado estándar rompe el esquema, ya que el texto plano cifrado con AES-GCM o similar produce un texto cifrado de diferente longitud y conjunto de caracteres. El cifrado que preserva el formato (FPE) resuelve este problema: cifra el texto plano de una longitud y alfabeto determinados en un texto cifrado de la misma longitud y alfabeto. Cifrar el texto plano 1483920193402918 con FPE podría producir una salida como 1483666666662918 : los mismos 16 dígitos, el mismo alfabeto numérico, pero protegido criptográficamente.

FPE es una de las tres técnicas de seudonimización que Google Cloud admite para anonimizar datos mediante la Protección de Datos Sensibles (anteriormente Cloud DLP): cifrado determinista con AES-SIV, cifrado que conserva el formato y hash criptográfico. Las tres reemplazan los valores sensibles con tokens generados criptográficamente mediante una clave; este artículo se centra específicamente en el método FPE.

¿Cómo funciona el cifrado que conserva el formato en Google Cloud?

Google Cloud implementa FPE mediante una construcción llamada FFX , que define dos métodos candidatos, FF1 y FF3, para convertir texto plano en texto cifrado que conserva el formato. FF1 es el único método FFX aprobado actualmente para el cifrado en Google Cloud. FF2 nunca se finalizó para su publicación cuando se creó FFX, y se descubrió que FF3 era criptoanalíticamente débil en un ataque de 2017, tras lo cual el NIST retiró su recomendación para FF3 a la espera de una revisión más sólida (FF3-1). La implementación de Google Cloud refleja este historial al admitir únicamente FF1.

FFX construye el texto cifrado ejecutando varias rondas de una función Feistel sobre el texto plano, utilizando la clave de cifrado en cada ronda. Una función Feistel divide el texto plano en dos mitades, aplica una permutación con clave a una mitad basándose en la otra, e intercambia las mitades en cada ronda. FF1 utiliza 10 rondas de esta función Feistel (FF3 utilizó 8, en parte por lo que resultó ser más débil). Antes de que pueda comenzar el cifrado, el alfabeto utilizado para anonimizar los datos debe especificarse de una de tres maneras: seleccionando uno de los cuatro conjuntos de caracteres comunes predefinidos de Google, especificando un valor de base (2 para binario, 95 para el rango ASCII imprimible completo con números, letras mayúsculas/minúsculas y símbolos), o proporcionando un alfabeto personalizado que contenga los caracteres exactos que se deben usar.

Cuando FPE-FFX se ejecuta en Sensitive Data Protection, el texto cifrado resultante puede ir precedido de una anotación sustituta para formar un token final con el formato surrogate_infotype(surrogate_length):surrogate_valueEl infotipo lo define el usuario y el valor sustituto es el propio texto cifrado. Para reidentificar datos no estructurados se requiere el token completo, incluida su anotación sustituta; los datos estructurados (una columna conocida en un esquema conocido) solo necesitan el valor sustituto, ya que el infotipo y la longitud ya están implícitos en el esquema.

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

Cada operación FPE-FFX necesita una clave AES, y Google Cloud ofrece tres maneras de proporcionarla, cada una con un modelo de custodia diferente.

Modelo de control de llaves	Cómo funciona	Mejor ajuste
Nativo (clave sin procesar en la solicitud)	La clave AES codificada en base64 se incluye directamente en cada llamada a la API de anonimización/reidentificación.	Pruebas únicamente locales. La clave se expone en la carga útil de la solicitud y debe excluirse del registro manualmente.
Clave encapsulada en Cloud KMS (equivalente a BYOK)	La clave AES se cifra mediante una clave de Cloud KMS y solo se almacena/transmite el texto cifrado encapsulado; la protección de datos confidenciales llama a Cloud KMS para descifrarlo en cada operación.	Producción. IAM controla quién puede invocar el desempaquetado, y cada desempaquetado se registra en los registros de auditoría de la nube.
Externo/equivalente a HYOK (ECM en la nube)	La clave Cloud KMS que encapsula la clave AES está alojada por un administrador de claves externo a través de Cloud External Key Manager, por lo que Google nunca almacena material de clave utilizable.	Datos regulados en los que un contrato o un organismo regulador exige que el proveedor de la nube nunca posea la clave, aceptando la latencia adicional que supone una comunicación bidireccional con un gestor de claves externo en cada operación.

El modelo de clave encapsulada debería ser la opción predeterminada para cualquier implementación de FPE que maneje datos reales de clientes. Añade control de acceso gestionado por IAM y un registro de auditoría completo que una clave simple no puede proporcionar, y es el patrón que la propia documentación de Google recomienda para la tokenización en producción y las cargas de trabajo de FPE.

¿Cómo debería IAM regular quién puede tokenizar y reidentificarse?

FPE es reversible por diseño, lo que precisamente lo hace útil (un sistema de pagos necesita recuperar el número real de la tarjeta en algún momento) y es precisamente por eso que el control de acceso es más importante aquí que para el hash unidireccional. Estructure IAM en torno a la operación, no solo a los datos:

1. Otorgar a la capa de aplicación que solo necesita tienda un valor tokenizado permite llamar a la función de desidentificar, pero no a la de volver a identificar.
2. Otorgue permisos de reidentificación únicamente a las cuentas de servicio específicas que legítimamente necesiten recuperar el valor original (un procesador de pagos, un flujo de trabajo de revisión de fraudes), nunca a una función de análisis general.
3. Proporcione la clave de envoltura de Cloud KMS cryptoKeyEncrypterDecrypter Este rol se asigna únicamente a la cuenta de servicio DLP, nunca directamente a una identidad humana.
4. Separe la identidad que gestiona las plantillas de inspección/desidentificación de la identidad que consume la salida tokenizada, de modo que los cambios en las plantillas sean auditables independientemente del acceso a los datos.
5. Revise las concesiones de reidentificación con la misma frecuencia que las revisiones de acceso a la base de datos de producción, ya que una concesión de reidentificación obsoleta es funcionalmente equivalente al acceso permanente al texto sin formato.

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

Al rotar la clave Cloud KMS que encapsula una clave AES de FPE, se crea una nueva versión de la clave. Sin embargo, Google Cloud aclara que la rotación «no vuelve a cifrar los datos ni desactiva ni elimina las versiones anteriores de la clave». En el caso específico de FPE, esto significa que cada valor tokenizado con la versión anterior de la clave de encapsulación aún necesita que esa versión exacta esté disponible para poder ser identificada posteriormente. Si se elimina una versión de la clave antes de que todos los valores de FPE dependientes se hayan vuelto a cifrar con la nueva versión, esos datos se vuelven irrecuperables de forma permanente, según el diseño del sistema.

Un patrón seguro: rotar la clave de encapsulación de Cloud KMS según un cronograma definido (no existe un intervalo mínimo o máximo fijo para la rotación en Cloud KMS, pero un valor base común es de 90 días para las claves simétricas), descifrar y volver a tokenizar los valores FPE existentes con la nueva versión de la clave en un proceso por lotes en segundo plano, y programar la destrucción de la versión de clave obsoleta solo cuando dicho proceso por lotes confirme que no quedan dependencias. El período de destrucción programada predeterminado de Cloud KMS es de 30 días, lo que proporciona un margen razonable para detectar cualquier valor que un proceso por lotes haya pasado por alto.

¿Qué información se debe registrar para una implementación de FPE?

• Cada llamada de reidentificación, con la identidad de la persona que llama y el campo/registro específico al que se hace referencia, ya que la reidentificación es la operación que realmente expone el texto plano.
• Operaciones de desempaquetado de Cloud KMS contra la clave de envoltura, capturada automáticamente a través de los registros de auditoría de la nube.
• Cambios en la plantilla a la configuración de inspección/desidentificación que define a qué campos se les aplica FPE y con qué alfabeto.
• Eventos del ciclo de vida de la versión clave (rotación, destrucción programada, cancelación), de modo que un administrador de seguridad pueda correlacionar un incidente de "el valor ya no se puede volver a identificar" con un evento clave específico.

¿Cuánto cuesta FPE en Google Cloud?

FPE se presenta como una operación de transformación de protección de datos confidenciales, bajo el mismo modelo de precios (método de contenido o trabajo de almacenamiento) que cubre la tokenización en general: en términos generales, la transformación mediante método de contenido tiene un costo aproximado de $2.00/GB después de un nivel gratuito de 1 GB/mes, hasta 1 TB, con una tarifa por GB menor por encima de ese límite (consulte las tarifas actuales en la página de precios de Google, ya que los precios de protección de datos confidenciales son escalonados y pueden variar). La clave de encapsulado de Cloud KMS agrega un cargo independiente basado en el uso para cada operación de encapsulado/desencapsulado, que se escala según la cantidad de operaciones de FPE que se ejecuten, no según el volumen de datos escaneados.

El detalle de costos que la mayoría de los equipos pasan por alto: debido a que FPE es reversible, una carga de trabajo que tokeniza al escribir y reidentifica al leer (un sistema de pagos, por ejemplo) paga el costo de operación de Cloud KMS dos veces por ciclo de vida del registro, no una sola vez. Modele que duplique el número de operaciones antes de comparar el costo total de FPE con un enfoque de hash o enmascaramiento unidireccional que nunca requiere reidentificación.

¿Cómo es la arquitectura FPE multi-nube?

La compatibilidad con FPE no es uniforme en las principales nubes. Google Cloud tiene FF1 integrado directamente en Sensitive Data Protection; AWS no tiene una primitiva FPE nativa en AWS KMS y normalmente requiere una biblioteca de terceros o una implementación FPE de un proveedor de módulos de seguridad de hardware que se ejecute sobre AWS CloudHSM; Azure, de manera similar, no tiene un servicio FPE nativo y depende de soluciones de socios o del cifrado determinista de Always Encrypted (que no es la misma construcción que FPE) para la protección que preserva el esquema. Una plataforma de datos multi-nube que necesita una tokenización consistente que preserve el formato en las tres nubes generalmente tiene que estandarizar una biblioteca FPE de terceros o autohospedada en lugar de las herramientas nativas de cada nube, y encapsular el material de clave de esa biblioteca en el KMS nativo de cada nube (Cloud KMS, AWS KMS, Azure Key Vault) para un control de acceso y una auditoría consistentes.

Consulte nuestra comparación de AWS KMS, Azure Key Vault y GCP KMS para ver cómo difiere la capa nativa de administración de claves subyacente a cualquier implementación de FPE entre los tres proveedores.

¿Cuáles son las limitaciones del cifrado que preserva el formato?

• FPE conserva la longitud y el alfabeto, pero no la validez semántica. Un sistema posterior que aplique una suma de verificación de Luhn a los números de tarjeta, o una verificación de rango de fechas, puede rechazar el texto cifrado FPE a menos que la transformación esté diseñada para preservar esa propiedad específica.
• Dado que FPE es reversible, no cumple con los requisitos que exigen la desidentificación o anonimización irreversible; utilice funciones hash o generalización cuando la reversibilidad en sí misma sea el problema de cumplimiento.
• Actualmente, solo FF1 está aprobado; los equipos no deberían implementar ni depender de FF3 para nuevos trabajos debido a su conocida vulnerabilidad criptoanalítica.
• El ciclo de vida de las versiones de clave es responsabilidad exclusiva del cliente; Google no vuelve a cifrar automáticamente los valores FPE cuando una clave de envoltura rota.

Lista de verificación para la toma de decisiones: Implementación de FPE en Google Cloud

1. Confirme que el campo realmente necesita preservar el formato (una dependencia de validación o esquema posterior), y no solo anonimizarlo en general.
2. Utilice exclusivamente FF1; no cree nuevos flujos de trabajo en FF3.
3. Envuelva la clave AES en Cloud KMS y otorgue el permiso. cryptoKeyEncrypterDecrypter únicamente a la cuenta de servicio que llama a la Protección de Datos Sensibles.
4. Separe las concesiones de IAM para la anonimización y la reidentificación, y revise el acceso a la reidentificación con la misma periodicidad que el acceso a los datos de producción.
5. Redacte el manual de procedimientos para la rotación de claves y la re-tokenización antes de que se tokenice el primer valor de producción.

¿Qué recomendaría Encryption Consulting?

Las implementaciones de FPE suelen funcionar correctamente el primer día, pero se convierten en un problema en la primera rotación de claves, ya que nunca se creó el manual de procedimientos de re-tokenización. El servicio de asesoramiento de Cloud Data Protection de Encryption Consulting diseña conjuntamente el ciclo de vida de la clave FPE, la división de IAM de anonimización/reidentificación y el manual de procedimientos de rotación. Además, nuestra oferta de HSM como servicio proporciona al KMS en la nube una custodia de claves respaldada por hardware donde se requiere la garantía FIPS 140-3.

Preguntas frecuentes

¿Cuál es la diferencia entre FPE y tokenización?

La tokenización es el concepto general de reemplazar un valor sensible con un token sustituto; FPE es una técnica criptográfica específica para generar dicho sustituto, que garantiza que la salida tenga la misma longitud y conjunto de caracteres que la entrada. La protección de datos sensibles de Google Cloud ofrece FPE junto con otros dos métodos de tokenización (cifrado determinista AES-SIV y hash criptográfico).

¿Por qué Google Cloud solo es compatible con Firefox 1 y no con Firefox 3?

En un ataque realizado en 2017, se demostró que FF3 era criptoanalíticamente débil, tras lo cual su margen de seguridad se consideró insuficiente para su uso en entornos de producción. FF1 utiliza más rondas de Feistel (10 frente a las 8 de FF3) y sigue siendo el método aprobado.

¿Se puede utilizar el texto cifrado FPE en un índice de base de datos o en una restricción de unicidad?

Sí, para FPE determinista, ya que el mismo texto plano con la misma clave y alfabeto siempre produce el mismo texto cifrado, que es precisamente lo que lo hace utilizable como índice o clave de unión sin descifrar primero, a diferencia del cifrado aleatorio.

¿El cambio de la clave de cifrado de Cloud KMS daña los datos FPE existentes?

No de inmediato. La rotación crea una nueva versión de clave sin eliminar las antiguas, por lo que el texto cifrado FPE existente sigue siendo identificable mientras su versión de clave original siga existiendo. El riesgo solo surge si esa versión antigua se destruye antes de que se ejecute una nueva tokenización.

¿Está FPE disponible de forma nativa en AWS o Azure, al igual que en Google Cloud?

No. Ni AWS KMS ni Azure Key Vault incluyen una primitiva FPE nativa comparable a la implementación FF1 de Google Cloud dentro de la Protección de datos sensibles; la mayoría de las implementaciones de AWS y Azure dependen de una biblioteca de terceros o de la implementación FPE de un proveedor de módulos de seguridad de hardware.

¿Necesita ayuda para diseñar el ciclo de vida clave detrás de una implementación de FPE, y no solo la llamada de cifrado en sí? Hable con el equipo de Protección de Datos en la Nube de Encryption Consulting.