Cifrado a nivel de campo: garantizar la privacidad y seguridad de los datos

Publicado: mayo de 2025. Actualizado: agosto de 2026. Revisado por el equipo de asesoría en protección de datos de Encryption Consulting.

¿Qué es el cifrado a nivel de campo y por qué es importante?

El cifrado a nivel de campo (FLE, por sus siglas en inglés) consiste en cifrar campos de datos individuales, como un número de tarjeta de pago, un documento nacional de identidad o un código de diagnóstico, dentro de una base de datos o documento, en lugar de cifrar todo el volumen de almacenamiento o una columna completa de una tabla. Cada campo protegido recibe su propio tratamiento de cifrado y, en la mayoría de las implementaciones, su propio material de clave, de modo que una copia de seguridad de la base de datos robada o una consulta con privilegios excesivos sigue devolviendo texto cifrado ilegible precisamente para los campos que conllevan riesgo regulatorio o financiero, mientras que el resto del registro permanece utilizable.

El cifrado de disco completo ( FLE) es importante porque las filtraciones de datos y las normativas de privacidad ahora penalizan a las organizaciones por exponer categorías específicas de datos, no por exponer un disco. PCI DSS se preocupa por el número de cuenta principal (PAN). HIPAA se preocupa por la información de salud protegida (PHI). GDPR se preocupa por la información de identificación personal (PII). El cifrado de disco completo protege todo hasta que el sistema arranca y un usuario se autentica, momento en el que todos los datos, sensibles o no, se convierten en texto plano para esa sesión. El cifrado a nivel de columna limita el objetivo a una columna, pero generalmente comparte una clave y un modo de cifrado en todas las filas. FLE va un paso más allá: permite que un equipo de seguridad cifre solo el PAN, el número de seguro social (SSN) o el campo de diagnóstico, elija la construcción criptográfica adecuada para cómo se usa ese campo específico y deje intactos los números de factura, las marcas de tiempo y las direcciones de envío.

Método de cifrado	<b></b><b></b>	granularidad	Caso de uso	Impacto en el rendimiento
Cifrado de disco completo	Todo el disco o unidad de almacenamiento	Bajo (todo el disco)	Cifrado de portátiles, protección contra pérdida de dispositivos	Mínimo (hecho a nivel de hardware)
Cifrado a nivel de columna	Columnas específicas de la base de datos	Moderado (nivel de columna)	Cifrado de números de seguro social y de tarjetas en una base de datos	Moderado (dependiendo de la complejidad de la consulta)
Cifrado a nivel de campo (FLE)	Campos individuales dentro de una base de datos o documento	Alto (específico del campo)	Control preciso sobre PAN, PII y PHI	Mayor (cifrado/descifrado por campo, por operación)

¿Qué método de cifrado debería elegir: determinista, aleatorio, FPE o tokenización?

La elección depende de si el campo necesita ser buscado o combinado. El cifrado aleatorio ofrece la mayor confidencialidad, pero bloquea las consultas del servidor; el cifrado determinista y el cifrado que preserva el formato (FPE) sacrifican parte de esa confidencialidad a cambio de una búsqueda de igualdad y, en el caso del FPE, un formato de campo sin cambios; la tokenización elimina por completo el valor sensible del sistema y puede reducir el alcance del cumplimiento normativo.

El cifrado determinista siempre produce el mismo texto cifrado para el mismo texto plano y la misma clave. Esto permite realizar búsquedas de igualdad, uniones y agrupaciones directamente sobre los datos cifrados, pero también significa que un atacante que pueda ver el texto cifrado puede descubrir qué filas comparten un valor, incluso sin la clave, mediante análisis de frecuencia. Es una opción razonable para campos de tipo clave externa con alta cardinalidad y una necesidad de consulta real, y una mala opción para campos de baja cardinalidad, como un código de país o un indicador de sí/no.

El cifrado aleatorio utiliza un valor aleatorio nuevo (un vector de inicialización o un número aleatorio) en cada operación de cifrado, por lo que el mismo texto plano produce un texto cifrado diferente cada vez. No filtra información sobre patrones y es la opción más segura para campos que se almacenan pero nunca se consultan, como notas médicas en texto libre o un número de la seguridad social almacenado que solo se muestra a un usuario autorizado a la vez.

El cifrado que preserva el formato (FPE) produce texto cifrado con el mismo formato y longitud que el texto plano, por lo que un número de tarjeta de 16 dígitos se cifra en otro número de 16 dígitos y un número de la seguridad social de 9 dígitos se cifra en otro valor de 9 dígitos. NIST SP 800-38G especifica dos construcciones FPE, FF1 y FF3, ambas basadas en AES. En 2017, los investigadores publicaron un ataque práctico contra FF3 cuando el dominio cifrado es pequeño, y NIST respondió con una construcción reforzada, FF3-1, que reduce la longitud de ajuste y requiere un dominio mínimo mayor; FF3-1 se define actualmente en el segundo borrador público de SP 800-38G Revisión 1 , abierto a comentarios a partir de 2025. Las nuevas implementaciones de FLE deben implementar FF1 o FF3-1, y no deben basarse en la construcción original de FF3, aunque la versión de 2016 de SP 800-38G siga siendo la publicación finalizada vigente. La ventaja de FPE radica en la interoperabilidad: evita ampliar las columnas de la base de datos, romper la validación del dígito de control o actualizar cada sistema posterior que espera un valor de formato fijo.

La tokenización reemplaza el valor sensible con un token sustituto que no guarda relación matemática con los datos originales. Un servicio de tokenización con bóveda almacena el valor original en una bóveda de tokens reforzada y emite un token de búsqueda; un esquema sin bóveda (a menudo derivado de HMAC o FPE) calcula el token algorítmicamente sin una bóveda central, intercambiando el riesgo de disponibilidad de la bóveda por una dependencia de la clave de tokenización. Dado que el token en sí no es información personal ni del titular de la tarjeta, la tokenización es el enfoque con mayor probabilidad de eliminar un sistema del alcance del cumplimiento normativo, en lugar de simplemente reducir el riesgo dentro del mismo. Nuestra guía sobre tokenización con y sin bóveda , así como la comparación entre cifrado y tokenización, abordan esta disyuntiva con mayor profundidad.

Nuevo enfoque	¿Se puede buscar en el servidor?	¿Formato conservado?	Ajuste de conformidad
Cifrado aleatorio	No	No	Campos que nunca se consultan directamente: notas de texto libre, un número de seguro social almacenado que solo se muestra a un usuario a la vez.
Cifrado determinista	Igualdad y se une únicamente	No	Campos de búsqueda de alta cardinalidad donde la fuga de valores duplicados es un riesgo aceptable.
FPE (FF1 / FF3-1)	Igualdad solamente	Sí:	Esquemas heredados y lógica de validación que asumen el formato original: PAN, SSN, números de cuenta.
Tokenización (almacenada)	Solo mediante búsqueda de destokenización	Sí (el token coincide con el formato)	Protección PCI PAN y reducción del alcance, procesamiento de pagos
Tokenización (sin bóveda)	No se permite ninguna consulta directa sobre el valor original.	Sí:	Entornos de alto rendimiento donde una bóveda central supondría un cuello de botella.

¿Contra qué amenazas protege realmente el cifrado a nivel de campo?

FLE protege contra tres escenarios de amenazas específicos: un usuario interno con privilegios que consulta la base de datos sin procesar, una copia de seguridad de la base de datos robada o exfiltrada, y un alcance de cumplimiento innecesario. No protege contra una aplicación comprometida que posee legítimamente la clave de descifrado, por lo que la gestión de claves y el control de acceso son tan importantes como la elección del algoritmo de cifrado.

• Amenaza interna: Un administrador o analista de bases de datos con amplio acceso SELECT ve el texto cifrado de los campos protegidos a menos que también posea la clave de descifrado, que las arquitecturas FLE mantienen deliberadamente fuera del alcance del motor de la base de datos.
• Violación de la base de datos o robo de copias de seguridad: Un atacante que extrae una copia de seguridad completa de la base de datos, o una copia de seguridad mal configurada que se deja en un depósito de almacenamiento abierto, obtiene texto cifrado ilegible para los campos que realmente conllevan un riesgo de notificación de la brecha de seguridad.
• Reducción del alcance del cumplimiento normativo: bajo PCI DSS 4.0.1Hacer que el PAN sea ilegible mediante criptografía robusta, tokenización, truncamiento o hash es un control obligatorio dondequiera que se almacenen datos del titular de la tarjeta; cuando un sistema nunca tiene la capacidad de descifrar o destokenizar, ese sistema puede, con la segmentación de red y acceso adecuada, considerarse fuera del alcance.
• Lo que FLE no detiene: Un atacante que compromete el propio servidor de la aplicación, donde el texto sin cifrar permanece en la memoria durante el procesamiento normal, o que obtiene credenciales válidas de la aplicación con acceso legítimo de descifrado, elude por completo la protección de FLE. FLE reduce el alcance de una brecha de datos; no reemplaza el endurecimiento de los endpoints, el acceso con privilegios mínimos ni la monitorización.

¿Cómo se implementa el cifrado a nivel de campo?

La implementación de FLE es una secuencia de ocho decisiones, no una simple configuración. Omitir el paso de inventario es la razón más común por la que los proyectos de FLE deben rehacerse.

1. Descubre y clasifica los campos sensibles. Identifique todos los campos que contienen datos PAN, PII o PHI en todas las bases de datos, almacenes de documentos y lagos de datos, incluidas las copias que nadie recuerda haber creado. Una herramienta de descubrimiento criptográfico como CBOM Secure está diseñada precisamente para este paso.
2. Seleccione el método de cifrado por campo. en función de si es necesario buscarlo, combinarlo o generar un informe, utilizando la tabla de decisiones anterior en lugar de aplicar un único enfoque a toda la organización.
3. Seleccione el modelo de despliegue: una característica nativa de la base de datos (cifrado a nivel de campo del lado del cliente de MongoDB, cifrado consultable de MongoDB, SQL Server Always Encrypted) donde la plataforma lo admita, o una biblioteca personalizada de la capa de aplicación donde no lo admita.
4. Diseñar el modelo de cifrado de sobres: Generar una clave de cifrado de datos (DEK) por campo o por registro, y encapsular cada DEK con una clave de cifrado de clave (KEK) almacenada en un servicio de gestión de claves respaldado por HSM, de modo que ninguna clave en texto plano salga del hardware.
5. Integrar el cifrado en la capa del cliente o del controlador. De esta forma, el texto sin formato nunca llega al motor de la base de datos, o bien se adopta un modelo de enclave seguro (SQL Server 2019 y versiones posteriores) donde las consultas más complejas se ejecutan dentro de una región de memoria protegida.
6. Defina la rotación de claves y los criptoperíodos. para cada DEK y KEK, siguiendo las directrices del período de uso del originador y del receptor en NIST SP 800-57 Parte 1 Revisión 5y documentar un procedimiento de reenvoltura para cuando un KEK rote.
7. Validar el impacto de la consulta y el índice Se realizan pruebas con cargas de trabajo reales de la aplicación antes de su puesta en marcha, ya que los campos de igualdad o sin consulta suelen requerir cambios en la lógica de la aplicación, no solo un cambio de esquema.
8. Supervisar las operaciones de descifrado y ensayar la recuperación, incluyendo un ejercicio de simulación para una clave KEK perdida o comprometida, ya que ese escenario es el único modo de fallo de FLE que no tiene solución criptográfica.

¿Cuáles son las ventajas y desventajas en cuanto a rendimiento e interoperabilidad?

La disyuntiva es clara: cuanto mayor sea la garantía de confidencialidad, menos podrá hacer la base de datos con el campo por sí sola. El cifrado aleatorio ofrece la mejor confidencialidad, pero la peor capacidad de búsqueda; el cifrado de campo completo (FPE) y la tokenización sacrifican cierta confidencialidad a cambio de mantener el campo utilizable.

• Capacidad de búsqueda: El cifrado aleatorio bloquea todo filtrado, ordenación e informe del lado del servidor sobre el campo protegido; la aplicación debe descifrar y filtrar en memoria, lo que no es escalable a grandes conjuntos de resultados.
• Indexación: Los índices de rango B-tree estándar generalmente no funcionan con valores cifrados. El cifrado determinista admite un índice de igualdad, pero revela qué filas comparten un valor; las consultas de rango en datos cifrados requieren una función específica como MongoDB Queryable Encryption (igualdad y rango, generalmente disponible, con consultas de prefijo, sufijo y subcadena en vista previa pública a partir de MongoDB 8.2) o SQL Server Always Encrypted con enclaves seguros.
• Latencia de la consulta: El cifrado y descifrado del lado del cliente añade un viaje de ida y vuelta por cada operación, y un diseño de clave por registro añade una búsqueda de clave adicional, lo que se manifiesta más en cargas transaccionales de alto rendimiento que en cargas de trabajo de generación de informes.
• Interoperabilidad: La tokenización con preservación de formato y FPE mantiene intactas las reglas de validación heredadas, las columnas de ancho fijo y las integraciones posteriores. El texto cifrado aleatorio es más largo que el valor original y, por lo general, obliga a modificar el ancho de la columna y a actualizar todos los sistemas que utilizan ese campo.

¿Qué dependencias de gestión de claves requiere el cifrado a nivel de campo?

La seguridad de FLE depende enteramente de la correcta gestión de las claves que la respaldan; la elección del algoritmo de cifrado es casi secundaria. Tres dependencias aparecen en toda implementación seria de FLE.

1. Cifrado del sobre: Cada campo o registro tiene su propia clave de cifrado de datos (DEK), y cada DEK está protegida por una clave de cifrado de claves (KEK) almacenada de forma centralizada. Esto significa que una DEK comprometida expone un solo campo o registro, no todo el conjunto de datos, y la rotación de claves solo requiere volver a proteger las DEK en lugar de volver a cifrar todos los datos subyacentes.
2. Gestión de claves respaldada por HSM: La clave maestra de clave (KEK) debe residir en un módulo de seguridad de hardware (HSM) validado por FIPS o en un sistema de gestión de claves (KMS) en la nube respaldado por HSM, de modo que nunca pueda extraerse como texto plano, incluso si la infraestructura circundante se ve comprometida. SQL Server Always Encrypted garantiza esto directamente: la clave maestra de columna se almacena fuera del motor de la base de datos, en un almacén de certificados, Azure Key Vault o HSM, y el propio motor nunca la ve.
3. Rotación de claves por campo: Se deben seguir los siguientes períodos de rotación y criptoperíodos NIST SP 800-57 Parte 1 Revisión 5 Se trata de una guía en lugar de un cronograma interno arbitrario, y es necesario probar el procedimiento de rotación, ya que volver a empaquetar millones de DEK bajo un nuevo KEK es un proyecto operativo, no una simple llamada a la API.

La pérdida de una clave de cifrado de claves (KEK) o de una clave de cifrado de claves (DEK) sin posibilidad de recuperación es irreversible: no existe una vía de recuperación criptográfica para los datos cifrados con una clave destruida. Por lo tanto, los procedimientos de copia de seguridad y custodia de las claves de cifrado de claves no son opcionales en una arquitectura FLE de producción.

¿Cómo son las implementaciones de cifrado sobre el terreno en el mundo real?

La mayoría de los casos de uso de FLE en producción hoy en día se cubren con tres patrones de despliegue concretos.

• Protección PCI PAN en un procesador de pagos: El número de tarjeta (PAN) se cifra in situ con FF1 o FF3-1 para que conserve su formato de 16 dígitos para la lógica de validación existente, o bien se tokeniza a través de una bóveda compatible con PCI para que los sistemas de aplicación y análisis del procesador nunca manejen el número real de la tarjeta. PCI DSS 4.0.1 requiere que el PAN se vuelva ilegible dondequiera que esté almacenado, y solo la arquitectura tokenizada generalmente admite la eliminación de los sistemas circundantes del alcance de la evaluación.
• Información de identificación personal (PII) e información de salud protegida (PHI) en MongoDB: una plataforma de tecnología sanitaria que almacena códigos de diagnóstico de pacientes y números de la Seguridad Social utiliza Cifrado a nivel de campo del lado del cliente or Cifrado consultable Con claves de cifrado de datos por paciente gestionadas mediante un KMS externo (AWS KMS, Azure Key Vault o Google Cloud KMS). El cifrado y descifrado se realizan en el controlador antes de que los datos lleguen al servidor, por lo que MongoDB nunca procesa información de salud protegida en texto plano. Además, el cifrado consultable admite consultas de igualdad y de rango en los campos protegidos sin exponerlos a la base de datos.
• Datos de cuentas financieras en SQL Server: un banco cifra las columnas de número de cuenta y SSN con Siempre encriptado, utilizando cifrado determinista en el número de cuenta para que las búsquedas de igualdad y las uniones sigan funcionando, y cifrado aleatorio en el SSN, que solo se muestra, no se busca. La clave maestra de la columna se encuentra en un almacén respaldado por HSM fuera del motor de la base de datos, y donde el banco necesita consultas de rango o patrón en columnas protegidas, Siempre encriptado con enclaves seguros Ejecuta esa lógica de comparación dentro de un enclave protegido en lugar de exponer el texto plano al motor de consultas.

Extracción de dominios (FLE) nativa de la base de datos frente a FLE en la capa de aplicación: ¿Cuál se adapta mejor a su pila tecnológica?

Utilice una función nativa de la base de datos siempre que su plataforma ya la admita; reserve una compilación personalizada de la capa de aplicación para plataformas que no cuenten con una función FLE nativa o para requisitos de coherencia entre bases de datos que una función nativa no pueda cumplir.

Nuevo enfoque	Esfuerzo de configuración	Capacidad de consulta	Mejor ajuste
FLE de capa de aplicación personalizada	Alto: desarrollas lógica de cifrado, manejo de claves y rotación.	Control total, pero sin consulta nativa sobre el texto cifrado.	Plataformas sin FLE nativo o necesidades de consistencia entre bases de datos
Cifrado a nivel de campo del lado del cliente de MongoDB	Medio: biblioteca de cliente más un KMS externo	Consultas de igualdad en campos cifrados de forma determinista	Aplicaciones multiusuario que necesitan claves diferentes para el mismo campo.
Cifrado consultable de MongoDB	Medio: cifrado estructurado nativo, una sola clave por campo.	Igualdad y rango (GA); prefijo, sufijo, subcadena en vista previa	Nuevas aplicaciones que requieren tipos de consulta más amplios con mayor privacidad
SQL Server / Azure SQL Always Encrypted	De bajo a medio: jerarquía de clave maestra/cifrado de columna nativa	Igualdad en columnas deterministas; los enclaves seguros añaden coincidencia de rango y patrón.	Entornos SQL Server o Azure SQL existentes con un almacén CMK respaldado por HSM
Servicio de tokenización de Vaulted	De bajo a medio: integrar con una API de bóveda de tokens	Solo destokenizar y luego consultar	Reducción del alcance de la protección y el cumplimiento de PCI PAN

Limitaciones

• FLE no protege los datos una vez que se descifran en la memoria de la aplicación; un servidor de aplicaciones comprometido o un proceso malicioso que se ejecute con acceso legítimo de descifrado aún puede leer el texto sin cifrar en el punto de uso.
• El cifrado aleatorio bloquea prácticamente todas las consultas, el filtrado y la generación de informes del lado del servidor sobre los campos protegidos, lo que traslada esa lógica a la capa de aplicación y añade trabajo de ingeniería.
• La pérdida de claves es catastrófica e irreversible: si una clave de cifrado de datos o su clave de envoltura se destruye sin una copia de seguridad recuperable, los datos subyacentes no se pueden recuperar por ningún medio.
• El cifrado FPE y el cifrado determinista sacrifican cierta confidencialidad en aras de la usabilidad; los campos con un dominio de valores pequeño siguen siendo vulnerables al análisis de frecuencia o a la enumeración por fuerza bruta, independientemente del cifrado.
• Adaptar FLE a un esquema heredado es un verdadero proyecto de migración que implica la reconstrucción de índices, cambios en el ancho de las columnas y actualizaciones para todos los usuarios posteriores de ese campo, no un simple interruptor de configuración.
• La tokenización con bóveda introduce la propia bóveda de tokens como un nuevo objetivo de alto valor y un posible punto único de fallo de disponibilidad si no está diseñada para ser resiliente.

¿Qué recomendaría Encryption Consulting?

Comience con el descubrimiento, no con el cifrado. Las organizaciones que eligen un algoritmo de cifrado antes de confirmar la ubicación exacta de los campos PAN, PII y PHI terminan volviendo a cifrar los campos que omitieron en la primera revisión. CBOM Secure está diseñado para ese primer paso, revelando la ubicación real de los campos confidenciales, las claves y los activos criptográficos en el código, la nube y los sistemas locales, antes de tomar cualquier decisión sobre la arquitectura FLE.

Una vez inventariados los campos, asigne cada uno a un patrón de consulta antes de elegir determinista, aleatorio, FPE o tokenización, utilizando la tabla de decisiones anterior en lugar de una configuración predeterminada única para toda la organización. Cualquiera que sea el enfoque que elija, la clave de cifrado de claves debe estar en el hardware, no en la configuración de la aplicación ni en una bóveda solo de software; nuestro HSM como servicio proporciona protección de claves validada por FIPS sin la carga de ejecutar hardware HSM físico, que es la brecha más común que encontramos en las implementaciones de FLE durante la evaluación. Para las organizaciones que ejecutan FLE en AWS, Azure o GCP, nuestra Evaluación de protección de datos en la nube valida que los controles de cifrado y administración de claves realmente cumplen con las expectativas de NIST, CIS, ISO 27001 y PCI DSS antes de una implementación en producción, en lugar de después de un hallazgo de auditoría.

Una advertencia importante a tener en cuenta: el cifrado de disco completo (FLE) no sustituye universalmente el cifrado de disco completo ni el cifrado a nivel de columna. Para lagos de datos completos o almacenes de archivo sin requisitos de cumplimiento específicos para cada campo, el cifrado en reposo más general sigue siendo el control más práctico. La complejidad del FLE radica en los campos regulados específicos que realmente conllevan riesgos de vulneración y cumplimiento, y no en una política general aplicable en todas partes.

Conclusión

El cifrado a nivel de campo (FLE) ofrece a las organizaciones una forma de proteger específicamente los datos que conllevan riesgos regulatorios y financieros (PAN, PII, PHI), sin cifrar ni bloquear el resto de la información. La implementación adecuada nunca se reduce a la elección de un único algoritmo de cifrado: implica un inventario de la ubicación de los campos sensibles, una decisión para cada campo entre cifrado determinista, aleatorio, FPE y tokenización, según las necesidades reales de las consultas, un modelo de implementación adaptado a la plataforma de base de datos en uso y un programa de gestión de claves respaldado por un HSM que pueda soportar la rotación, las auditorías y el peor escenario posible de pérdida de claves. Si se implementa correctamente, el FLE reduce el alcance de PCI DSS, limita el daño de una brecha de seguridad en la base de datos y mantiene las aplicaciones funcionando como siempre. Si se implementa sin un plan de gestión de claves adecuado, se convierte en una nueva fuente de pérdida de datos irrecuperable.

Los servicios de asesoramiento en cifrado de Encryption Consulting ayudan a las organizaciones a inventariar campos sensibles, seleccionar el enfoque FLE adecuado para cada campo y diseñar una gestión de claves respaldada por HSM que resista las auditorías. Para analizar una evaluación de cifrado a nivel de campo para su entorno, póngase en contacto con nuestro equipo o explore nuestros servicios de asesoramiento en cifrado.

Preguntas frecuentes

¿El cifrado a nivel de campo es lo mismo que el cifrado a nivel de columna? No. El cifrado a nivel de columna generalmente aplica una clave y un modo a toda una columna de la base de datos, mientras que el cifrado a nivel de campo protege los valores de campos o registros individuales, a menudo con claves independientes, lo que convierte al cifrado a nivel de campo en el enfoque más preciso de los dos.

¿Puedo seguir buscando o generando informes sobre datos cifrados a nivel de campo? Depende del método. El cifrado aleatorio bloquea por completo la búsqueda en el servidor. El cifrado determinista y el cifrado que conserva el formato admiten la búsqueda por igualdad. MongoDB Queryable Encryption y SQL Server Always Encrypted con enclaves seguros extienden esta funcionalidad a las consultas de rango y patrón sin exponer el texto sin cifrar al servidor.

¿El cifrado a nivel de campo excluye mis sistemas del alcance de PCI DSS? Solo ciertas arquitecturas de tokenización pueden hacerlo, y únicamente cuando el sistema nunca almacena, procesa ni transmite el PAN real. El cifrado del PAN in situ, según PCI DSS 4.0.1, reduce el riesgo y cumple con el requisito de "hacer ilegible", pero no reduce automáticamente el alcance de la evaluación a menos que la capacidad de descifrado esté completamente separada del sistema en cuestión.

¿Qué sucede si pierdo la clave de cifrado de un campo? Los datos se vuelven irrecuperables de forma permanente. Precisamente por eso, el cifrado de sobres con un KMS respaldado por HSM, junto con un proceso documentado de copia de seguridad y custodia de las claves de cifrado, es un requisito indispensable y no una medida de seguridad opcional.

¿Debo implementar yo mismo el cifrado a nivel de campo o usar una función nativa de la base de datos? Utilice una función nativa de la base de datos, como el cifrado a nivel de campo del lado del cliente de MongoDB, el cifrado consultable o Always Encrypted de SQL Server, siempre que su plataforma lo admita, ya que elimina la mayor parte del código personalizado de gestión de claves. Implemente una solución personalizada a nivel de aplicación solo si su plataforma carece de soporte nativo o si necesita un comportamiento coherente en varios motores de base de datos.

Referencias

• NIST SP 800-38G, Recomendación para modos de operación de cifrado por bloques: Métodos para cifrado que preserva el formato: https://csrc.nist.gov/pubs/sp/800/38/g/upd1/final
• NIST SP 800-38G Revisión 1, segundo borrador público (FF3-1): https://csrc.nist.gov/pubs/sp/800/38/g/r1/2pd
• NIST SP 800-57 Parte 1 Revisión 5, Recomendación para la gestión de claves: Parte 1 – General: https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
• Biblioteca de documentos PCI DSS v4.0.1 del Consejo de Estándares de Seguridad PCI: https://www.pcisecuritystandards.org/document_library/
• MongoDB, Cifrado a nivel de campo del lado del cliente: https://www.mongodb.com/docs/manual/core/csfle/
• MongoDB, Elección de un enfoque de cifrado en uso (CSFLE frente a cifrado consultable): https://www.mongodb.com/docs/manual/core/queryable-encryption/about-qe-csfle/
• Microsoft Learn, Always Encrypted (Motor de base de datos): https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/always-encrypted-database-engine?view=sql-server-ver17
• Microsoft Learn, siempre cifrado con enclaves seguros: https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/always-encrypted-enclaves?view=sql-server-ver17