Pregunta abierta sobre cifrado en SQL Server: ¿usa alguien por aquí Always Encrypted o TDE (Transparent Data Encryption) en producción? Me interesa la experiencia real, no solo la teoría de la documentación de Microsoft.
Para quien no esté familiarizado con la diferencia: TDE cifra el fichero de base de datos completo en disco (protege contra que alguien robe el .mdf o una copia de seguridad y la lea directamente), pero los datos viajan sin cifrar entre SQL Server y la aplicación, y cualquiera con permisos de consulta normales ve los datos en claro. Always Encrypted va más allá: cifra columnas concretas de forma que ni siquiera un administrador de base de datos con acceso total al servidor puede leer el valor real, solo la aplicación cliente que tiene la clave de cifrado puede descifrarlo.
Lo que tengo curiosidad por saber de quien lo haya usado de verdad: ¿qué tan doloroso fue implementarlo sobre un sistema ya existente? ¿Tuvisteis que reescribir consultas porque Always Encrypted no soporta ciertas operaciones sobre columnas cifradas (comparaciones, LIKE, ordenar por esa columna)? ¿Y cómo gestionáis la rotación de claves sin tiempo de inactividad?
Cristina
Depende de qué estás protegiendo exactamente, porque TDE y Always Encrypted resuelven amenazas distintas, no son intercambiables:
TDE (Transparent Data Encryption) cifra los ficheros de datos en disco (.mdf/.ldf) y los backups. Protege frente a alguien que roba físicamente el disco o una copia de seguridad y trata de leerla sin pasar por SQL Server. Es completamente transparente para las queries: SQL Server descifra automáticamente al leer, así que ni la aplicación ni las consultas cambian nada. Pero no protege frente a un DBA con acceso legítimo al servidor, ni frente a alguien que consigue ejecutar queries directamente contra la base de datos: para SQL Server los datos están en claro en cuanto los lee de disco.
Always Encrypted va un paso más allá: los datos van cifrados incluso en memoria dentro de SQL Server, y solo se descifran en el cliente (driver), que es quien tiene la clave. Ni un DBA con acceso total al servidor puede ver el valor real de una columna protegida así con una query normal. La contrapartida es que limita mucho lo que puedes hacer con esas columnas en SQL: nada de LIKE, comparaciones de rango, ni funciones sobre el valor cifrado (salvo igualdad exacta con el modo determinístico).
En la práctica, muchos proyectos usan las dos juntas: TDE para todo el disco/backups de forma transparente, y Always Encrypted solo en las columnas realmente sensibles (números de tarjeta, DNI) donde de verdad importa que ni siquiera el propio DBA pueda verlas.
Elena