Transparent Data Encryption (TDE): ‘compliance’ vs. ‘security’

Transparent Data Encryption (TDE) es una tecnología que protege los datos sensibles en bases de datos durante su almacenamiento (data-at-rest). Sin embargo, su uso debe estar restringido a escenarios muy específicos, fuera de los cuales el nivel de protección que ofrece se reduce y puede dar lugar a una falsa sensación de seguridad, sobre todo cuando se emplea en entornos sujetos al cumplimiento de PCI DSS.

El ciclo de vida de los datos y los controles de cifrado

De acuerdo con la RAE, un “dato” puede considerarse información dispuesta de manera adecuada para su tratamiento por una computadora. El dato, como tal, puede ser procesado, almacenado y/o transmitido.

Uno de los principales controles para proteger la integridad y la confidencialidad de estos datos es la cryptography. Mediante este proceso, solamente el receptor y el emisor de los datos pueden acceder a los datos en texto claro, gracias a claves criptográficas compartidas previamente y a un algoritmo de cifrado común.

Cuando se implementan controles criptográficos en estos datos, solo se pueden proteger dos de sus tres estados: durante su almacenamiento y durante su transmisión, ya que, para su procesamiento, es indispensable que la información se encuentre en claro y, por lo general, dicho procesamiento se realiza en memoria volátil. Por esta razón, el estándar PCI DSS excluye de la implementación de controles de cifrado la información almacenada en la memoria RAM.

Applicability of PCI DSS depending on storage medium

Para los otros dos estados del dato (almacenamiento y transmisión), PCI DSS define los controles necesarios en los requerimientos 3 (Protect Stored Account Data) y 4 (Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks), respectivamente.

Cifrado de datos durante el almacenamiento

Entrando en detalles, el requerimiento 3 (3.5.1) de PCI DSS v4.x establece cuatro (4) opciones para la protección de datos durante su almacenamiento (data-at-rest):

1. Uso de funciones de hash con clave (keyed-hashed functions)
2. Truncamiento
3. Tokenización
4. Use of robust cryptography con sus procedimientos asociados de gestión de claves

Precisamente en esta última opción, cuando se emplea cifrado de datos, se puede usar:

1. Cifrado a nivel de dato (data-level encryption), en el que el dato o conjunto de datos específico es cifrado ANTES de ser almacenado o transmitido. Por lo general, este control es implementado en la aplicación que procesa los datos, por lo que también suele denominarse «application-level encryption‘.
2. Cifrado a nivel de archivo (file-level encryption), en el que el contenedor lógico de los datos (archivo) se cifra por completo antes de ser almacenado o transmitido. Ejemplo: Cifrado con PGP/GPG o funcionalidades de cifrado de programas ofimáticos o de compresión.
3. Cifrado a nivel de columna (column-level encryption), aplicable a bases de datos, en el que las columnas de las tablas que contengan datos sensibles se cifran.
4. Cifrado a nivel de disco o de partición (disk/partition-level encryption), en el que el medio de almacenamiento persistente (por lo general, discos duros y/o particiones) se cifra para proteger todos los datos almacenados, incluidas las copias de seguridad. Ejemplo: Microsoft Bitlocker, LUKS, etc.

Para cada una de estas opciones se pueden emplear distintas aplicaciones y/o librerías o, incluso, estas funcionalidades pueden incluirse como parte de una suite operativa completa.

¿Qué es Transparent Data Encryption (TDE)?

Aparte de las opciones de cifrado de datos descritas arriba, existe una tecnología híbrida que combina funcionalidades de cifrado de archivo, cifrado de columna (opcional) y cifrado de disco/partición, llamada Transparent Data Encryption (TDE), generalmente implementada por motores de bases de datos relacionales (RDBMS) como Microsoft SQL Server, IBM DB2, Oracle, etc. La lógica de su funcionamiento es relativamente sencilla:

• Se despliega una capa de cifrado intermedia entre los datos en ejecución y los datos almacenados en el datafile/tablespace de la base de datos. Esta capa se encarga de interceptar todas las llamadas de lectura y escritura de datos y de cifrarlas o descifrarlas de forma transparente para el usuario cuando la base de datos está en uso.
• Para la gestión del cifrado, se emplean algoritmos y longitudes de clave robustos, protegidos por una clave maestra, que suele almacenarse en un lugar seguro, protegido por una palabra de paso (como en Java KeyStore) o en un módulo de seguridad de hardware (HSM).

Transparent data encryption (TDE)

La “magia” de TDE radica en que, cuando la base de datos está fuera de línea (offline), si su datafile/tablespace se copia a medios externos (por ejemplo, plataformas de backups) o se remueve alguno de los discos duros donde se almacenan los datos de la base de datos, los datos almacenados (data-at-rest) se encontrarán cifrados y será imposible acceder a ellos salvo que se cuente con la clave maestra de cifrado.

Oracle TDE Tablespace Encryption – Fuente: https://docs.oracle.com/

Hasta aquí, una solución de TDE cumple con lo que exige el estándar PCI DSS:

• Usa criptografía robusta y sus claves criptográficas se gestionan de forma segura cuando se siguen las recomendaciones del fabricante y se alinea con los requierimientos del estándar,
• El acceso lógico es gestionado de forma separada e independiente de los mecanismos de control de acceso y de autenticación del sistema operativo nativo,
• Las claves de cifrado no están asociadas con ninguna cuenta de usuario, y
• Los factores de autenticación (contraseñas, palabras de paso (passphrases) o claves criptográficas que permiten el acceso a los datos sin cifrar) se almacenan de forma segura.

De hecho, la gran mayoría de proveedores de soluciones de bases de datos en la nube (AWS RDS, Azure SQL, y GCP) emplean TDE para garantizar a sus clientes que ellos, como proveedores de servicio, no tendrán acceso a sus datos cuando los motores de bases de datos estén fuera de línea, se hagan copias de seguridad o cuando los medios de almacenamiento sean removidos.

El “punto ciego” de TDE

A pesar de que TDE ofrece mecanismos de cifrado aceptables desde el punto de vista del cumplimiento normativo de PCI DSS, tiene un GRAN problema en su arquitectura: solamente se protegen los datos cuando la base de datos está fuera de línea (offline). Sin embargo, cuando la base de datos está en ejecución (data-in-use), cualquier cuenta, interactiva o no, con los privilegios necesarios, puede acceder a los datos en texto claro mediante una simple consulta SQL.

En este escenario, cualquier administrador de bases de datos (DBA) podría ejecutar un select de la base de datos con datos sensibles, ver toda la información en claro, copiarla a cualquier fichero y exfiltrarla, como si la base de datos no tuviera ningún control de seguridad, salvo sus controles de acceso nativos.

Como se puede observar, TDE protege los datos de una base de datos empleando dos controles diferentes:

1. Cifrado para los datos en reposo (data-at-rest) cuando la base de datos (o sus componentes) están fuera de línea, y
2. Control de acceso a los datos mientras la base de datos está en ejecución (data-in-use).

Esto, obviamente, crea un “punto ciego” (blind spot) en la seguridad de la base de datos que muchas entidades desconocen y que crea un sentimiento de “falsa seguridad” que, al no ser un problema de cumplimiento normativo (ya que PCI DSS y otros estándares aceptan TDE como un control «aceptable»), nadie se preocupa en gestionarlo.

Opinión personal del asesor QSA

El problema de TDE descrito anteriormente ha sido objeto de discusión entre los asesores QSA y el PCI SSC desde hace muchos años. Al día de hoy, de forma oficial, el PCI SSC no ofrece ninguna recomendación ni ha formalizado su posición respecto al uso de TDE en PCI DSS o en cualquier otro estándar gestionado por ellos.

Durante el proceso de Request For Comments (RFC) de PCI DSS versión 4.0, específicamente en el RFC 2, se hizo una mención específica a TDE, en donde se afirmaba que TDE no ofrecía un nivel de seguridad satisfactorio para los datos sensibles cuando la base de datos se encontraba en ejecución, necesitando complementar su seguridad con otra capa adicional de cifrado, tal y como se obliga actualmente cuando se realiza cifrado de medios no removibles, descrito en el control 3.5.1.2. Lamentablemente, y a la sorpresa de todos los QSAs con los que estuvimos involucrados en ese proceso de RFC, esta mención fue eliminada de la versión final de PCI DSS 4.0, devolviéndonos al punto de partida.

Desde mi punto de vista personal, considero que TDE, cuando se emplea de forma exclusiva para la protección de datos en bases de datos, es un control insuficiente y que, aunque el estándar PCI DSS no lo excluye como control válido, expone a la entidad a un riesgo innecesario si no se analiza el riesgo de forma global (data-in-use + data-at-rest).

Como explicaba arriba, TDE usa dos enfoques complementarios para proteger los datos en una base de datos: cifrado de datos en reposo (que, como tal, cumple con lo que exige el estándar) y controles de acceso a los datos cuando la base de datos está en ejecución. Y es precisamente en esta última parte en donde vienen las zonas grises:

• TDE remueve controles criptográficos (de alto nivel de seguridad) y los reemplaza por controles de acceso basados en la asignación de privilegios para los datos en ejecución (data-in-use), lo que pone TODO el contenido de la base de datos al mismo nivel de seguridad. Desde el punto de vista del cumplimiento de PCI DSS, se pasa de emplear los controles del requerimiento 3 para los datos en línea a los controles de los requerimientos 7 y 8 (autenticación y control de acceso), que se aplican a cualquier sistema del alcance.
• El riesgo gestionado por TDE está orientado a proteger los datos sensibles almacenados en medios persistentes cuando estos están fuera de línea (offline) por si un atacante potencial remueve ese medio físico del servidor. Estas amenazas, en servidores ubicados en centros de datos con seguridad física, se han vuelto cada vez menos frecuentes. Adicionalmente, muchos sistemas de almacenamiento masivo (discos en RAID, cabinas SAN/NAS, etc.) y plataformas de copias de seguridad (backup) ya incorporan de forma nativa controles criptográficos, a menudo ejecutados en hardware, que optimizan los tiempos de respuesta al acceso a datos, haciendo que tecnologías como TDE sean menos rentables desde el punto de vista de desempeño.
• Finalmente, TDE suele emplearse como parte de los controles de proveedores de servicios en la nube (Cloud Service Providers – CSP) para proteger los datos en reposo. La responsabilidad de emplear TDE muchas veces recae en el CSP. Sin embargo, en las matrices de responsabilidad de estos proveedores se indica que el usuario debe implementar controles de cifrado sobre los datos de tarjetas de pago almacenados en las bases de datos del CSP, al margen de que éstas tengan implementados controles de cifrado en el almacenamiento (data-at-rest) como TDE. Si seguimos la misma lógica que se aplica a un entorno TDE “on-premises”, dicho cifrado de datos adicional sería “opcional” y podría reemplazarse únicamente por controles de acceso… y esto, en la realidad, no es así.

Por esta razón, si una entidad emplea TDE como control exclusivo de seguridad de sus datos en una base de datos, debería replantearse su posición para prevenir riesgos innecesarios a sus datos cuando la base de datos se encuentra en ejecución.

QSA recommendations

A pesar de que, como se ha explicado, TDE continúa siendo un control aceptable desde el punto de vista del estándar PCI DSS, muchas veces nuestra responsabilidad como QSAs es ver más allá del cumplimiento normativo y analizar los riesgos reales que enfrenta una entidad en particular.

Por ello, si una empresa usa TDE, mis recomendaciones son las siguientes:

• Analizar si existen soluciones alternativas al cifrado de datos en reposo  (data-at-rest) proporcionado por TDE en la infraestructura existente. Este cifrado puede implementarse a nivel de disco mediante hardware o mediante controles nativos de plataformas de backup o de sistemas operativos, sin recurrir a la delegación de este proceso a la base de datos.
• Complementar la protección provista por el cifrado de datos en reposo con cifrado a nivel de dato (data-level/application-level encryption). Empleando este enfoque, se protegen estos datos al almacenarlos en la base de datos (tanto online como offline) y se evita que cuentas con privilegios puedan visualizar y/o extraer esta información de forma masiva, complementando de forma integral los controles nativos de acceso a la base de datos.
• Implementados los controles a nivel de cifrado de datos, activar alarmas a nivel de aplicación y de base de datos para identificar cualquier invocación no autorizada de rutinas de cifrado o descifrado que pueda estar vinculada con intentos de acceso masivo a datos sensibles.
• Hasta donde sea posible, emplear módulos de seguridad de hardware (Hardware Security Modules – HSMs) como dispositivos de seguridad para la gestión del ciclo de vida de las claves criptográficas y de los procesos de cifrado y descifrado.

La conclusión final de este artículo radica en el uso del concepto de seguridad en profundidad, que exige implementar controles de seguridad en distintos puntos de la infraestructura y evitar delegar toda la seguridad en un único elemento (en este caso, a la base de datos). El uso de TDE fue válido en un momento en que no existían controles de protección para los medios de almacenamiento persistentes asociados a bases de datos, pero esto ya no es una restricción, considerando la evolución actual de la seguridad. Igualmente, es indispensable que las entidades comprendan que el cumplimiento no siempre implica seguridad. Se trata de dos conceptos diferentes y complementarios, pero que deben ser analizados conjuntamente para evitar una falsa sensación de seguridad.

Modelo de defensa en profundidad. Fuente: www.deacosta.com