¿Qué es el cifrado de datos en reposo y en tránsito?

El cifrado en reposo es un control que vuelve ilegibles los datos almacenados sin las claves; el cifrado en tránsito protege los datos que cruzan la red. Los datos viven en tres estados — en reposo en el almacenamiento, en tránsito por el cable y en uso en la memoria — y los dos primeros son la obligación de base de toda aplicación: AES-256 para lo que está quieto, TLS para lo que se mueve. El tercer estado (protegido por entornos de ejecución confiables y, en la frontera, por cifrado homomórfico) es real, pero, para la mayoría de los equipos de aplicación, es la capa de alguien más.

Puntos clave

Las dos protecciones — y qué frena cada una en realidad

La tabla honesta que las páginas del ranking omiten — incluida la columna que más importa:

              Estándar         Cubre                  Detiene                      NO detiene
En tránsito   TLS 1.2+/HTTPS   cada tramo de red      escuchas, MITM,              endpoints comprometidos —
                                                      espionaje de wifi público    el servidor lo lee sin más
En reposo     AES-256 (GCM)    discos, BDs, backups   drives robados, backups      credenciales robadas,
                                                      filtrados, buckets abiertos  SQL injection, bugs de la app
En uso        TEEs             RAM al procesar        raspado de memoria           — casi siempre asunto de la plataforma

Ninguno detiene a un atacante en quien la propia app confía. La app guarda las claves
y descifra bajo demanda — el cifrado complementa el control de acceso, nunca lo sustituye.

Cómo se ven los valores seguros por defecto desde el código de la aplicación:

// JavaScript / Node.js — Back4app JS SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
const user = new Parse.User();
await user.signUp({ username: 'ada', password: secret });
// On the wire: TLS 1.2+ (the https serverURL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

// Flutter / Dart — Back4app Flutter SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
final user = ParseUser('ada', secret, '[email protected]');
await user.signUp();
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

// iOS / Swift — Back4app Swift SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
var user = User()
user.username = "ada"
user.password = secret
let signedUp = try await user.signup()
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

// Android / Kotlin — Back4app Android SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
val user = ParseUser()
user.username = "ada"
user.setPassword(secret)
user.signUp()
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

Cómo funciona TLS, en un párrafo

El truco elegante: la criptografía asimétrica es lenta pero no necesita un secreto compartido; la simétrica es rápida pero necesita uno. Así que el handshake de TLS usa la primera para establecer la segunda — el cliente verifica el certificado del servidor (la comprobación de identidad que vuelve detectable la interceptación), ambos lados acuerdan una clave de sesión nueva vía intercambio asimétrico de claves, y todo lo que sigue viaja en cifrado simétrico rápido. TLS 1.3 apretó todo eso: una ida y vuelta en lugar de dos, cifrados legados e intercambio de claves RSA eliminados, forward secrecy obligatorio — así el tráfico grabado no puede descifrarse después, incluso si la clave de largo plazo del servidor se filtra. Apunte móvil que las páginas del ranking se saltan: las apps pueden además hacer pinning de los certificados esperados, cambiando resiliencia contra autoridades certificadoras deshonestas por cuidado operativo a la hora de rotar.

Las capas en reposo: disco vs. base de datos vs. campo vs. aplicación

“Cifrado en reposo” abarca cuatro promesas muy distintas — cada una derrota a un atacante diferente:

La regla que atraviesa toda la tabla: las capas más altas protegen contra más, cuestan más. El cifrado a nivel de campo es el intercambio honesto — las columnas cifradas no pueden indexarse ni buscarse con normalidad (el cifrado determinista devuelve las búsquedas por igualdad al costo de cierta fuga) — y por eso se reserva para lo genuinamente sensible: datos de salud, documentos de identidad, secretos. Y la falla clásica de auditoría vive aquí: la base de datos cifrada cuyos backups salen sin cifrar.

El cifrado de extremo a extremo es otra promesa

TLS en todas partes sigue significando que el servidor lo lee todo — descifra cada conexión por diseño. El cifrado de extremo a extremo mueve las claves a los usuarios: solo el remitente y el destinatario pueden descifrar, y el operador sirve un ciphertext que no puede abrir. Eso es una decisión de producto distinta, no una configuración más fuerte: E2EE significa nada de búsqueda en el servidor, nada de moderación de contenido, nada de recuperación si los usuarios pierden las claves. Los modelos de amenaza encajan con limpieza — TLS defiende el camino, en reposo defiende el almacenamiento, E2EE defiende contra el propio servicio — y la mayoría de las aplicaciones se detiene, con razón, en los dos primeros, mientras que los mensajeros y los productos de bóveda justifican el tercero.

Hashing vs. cifrado

Un destacado jubila una confusión extendida: las contraseñas reciben hash, nunca cifrado. Nadie — incluido el servidor — debería poder recuperar una contraseña; el login compara hashes. Cifrar contraseñas significa que existe una clave que las descifra todas — exactamente la catástrofe que el hashing existe para impedir.

Casos de uso comunes

• Toda app web y móvil — TLS en todas las conexiones y almacenamiento cifrado son el piso, no features.
• Datos regulados — el GDPR nombra el cifrado como medida técnica apropiada (con alivio en la notificación de brechas), las reglas de salud lo exigen para datos de pacientes, y los estándares de pago exigen números de tarjeta ilegibles en reposo y criptografía fuerte en tránsito.
• Backups y desmantelamiento — backups cifrados y crypto-shredding (destruye la clave y el dato muere en todas partes) cierran el capítulo de la copia robada.
• Protección de campos con PII — cifrado a nivel de aplicación para las columnas cuya fuga es titular de prensa, no incidente.
• Clientes móviles en redes hostiles — TLS más validación de certificados como la defensa que viaja con el usuario.

¿Qué capa necesitas? Matriz de decisión

Limitaciones y trade-offs

• El cifrado no es control de acceso. El argumento de la seguridad por capas en una línea: el cifrado en reposo es transparente para la app en ejecución, así que los permisos — ACLs, CLPs, políticas de fila — siguen siendo la defensa contra todo atacante con credenciales.
• La gestión de claves es el proyecto de verdad. La guía del NIST existe porque la generación, la separación, la rotación y la revocación — no la elección del algoritmo — son donde fallan los despliegues.
• El cifrado a nivel de campo pelea con la base de datos. Sin índices, sin consultas LIKE, migraciones cuidadosas; cifra los campos que lo necesitan, no el esquema.
• TLS termina en el terminador. Los proxies y load balancers que descifran a mitad de camino recrean tramos en texto claro; el tráfico interno necesita la misma disciplina que el borde.
• Compliance ≠ seguridad. El cifrado de checkbox con las claves junto a los datos satisface a los auditores y a nadie más; la columna del modelo de amenaza es contra la que se diseña.

Cifrado en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. El piso lo pone la plataforma: cada conexión REST, GraphQL y Live Query viaja sobre TLS, y los datos y backups se cifran en reposo — las dos capas de base llegan como valores por defecto, no como proyectos. La parte que le queda al desarrollador es exactamente lo que las pestañas de código esbozan: las contraseñas reciben hash bcrypt de Back4app de fábrica (nunca almacenadas, nunca recuperables — la regla del hashing impuesta estructuralmente); los campos genuinamente sensibles reciben cifrado a nivel de aplicación en un beforeSave de Cloud Code, con la clave en la configuración del servidor y no en el código, para que el texto claro nunca llegue al almacenamiento; y los secretos se quedan fuera de logs, URLs y bundles de cliente — la disciplina de claves de API aplicada a los datos. Y luego la pieza que el cifrado no puede hacer: las ACLs y los permisos a nivel de clase gobiernan quién lee qué, porque el control que frena a un atacante con credenciales nunca fue la criptografía — siempre fue la autorización.