---
term: 'Cifrado de Datos en Reposo y en Tránsito'
seoTitle: 'Cifrado en reposo vs. en tránsito: TLS, AES-256, gestión de claves'
headline: '¿Qué es el cifrado de datos en reposo y en tránsito?'
slug: cifrado-de-datos
category: auth-security
shortDefinition: '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.'
relatedTerms:
  - data-layer-vs-application-layer-security
  - row-level-security
  - api-key-security
  - tenant-isolation
contrastsWith:
  - data-layer-vs-application-layer-security
aboutTerms:
  - 'Cifrado en Reposo'
  - 'Cifrado en Tránsito'
  - 'TLS'
  - 'Gestión de Claves'
faq:
  - question: '¿Qué es el cifrado en reposo?'
    answer: 'Cifrar los datos almacenados — discos, bases de datos, backups, object storage — para que quien obtenga el medio de almacenamiento sin las claves se quede solo con ciphertext. El estándar es AES-256; la protección es contra hardware robado, backups filtrados y capas de almacenamiento vulneradas.'
  - question: '¿Qué es el cifrado en tránsito?'
    answer: 'Cifrar los datos mientras cruzan redes, para que el tráfico interceptado sea ilegible — el trabajo de TLS, que es lo que la S de HTTPS entrega. Protege contra escuchas y ataques man-in-the-middle en cualquier tramo entre el cliente y el servidor.'
  - question: '¿Cuál es la diferencia entre cifrado en reposo y en tránsito?'
    answer: 'Estados de datos distintos, amenazas distintas. En reposo defiende las copias almacenadas contra el robo de medios y backups; en tránsito defiende los datos en movimiento contra la intervención de la línea. Son complementos, no alternativas — todo framework de seguridad serio espera ambos, porque cada uno frena ataques que el otro no ve.'
  - question: '¿HTTPS es lo mismo que TLS?'
    answer: 'HTTPS es HTTP transportado sobre TLS, el protocolo criptográfico que protege la conexión. TLS 1.3 es el actual — handshakes más rápidos, cifrados débiles eliminados, forward secrecy obligatorio; las versiones 1.0 y 1.1 están formalmente obsoletas y deben quedar deshabilitadas.'
  - question: '¿Qué es AES-256?'
    answer: 'El Advanced Encryption Standard con clave de 256 bits — un cifrado simétrico por bloques estandarizado por el NIST, efectivamente inmune a la fuerza bruta y la elección de facto para los datos en reposo. En la práctica quieres un modo autenticado como AES-GCM, que detecta la manipulación además de ocultar el contenido.'
  - question: '¿Cuál es la diferencia entre cifrado simétrico y asimétrico?'
    answer: 'El simétrico usa una clave compartida para ambos sentidos — rápido, correcto para datos en volumen (AES). El asimétrico usa un par de claves pública/privada — más lento, correcto para intercambio de claves, certificados y firmas. TLS usa ambos: un handshake asimétrico acuerda una clave de sesión simétrica que cifra el tráfico real.'
  - question: '¿En qué se diferencia el cifrado de extremo a extremo del cifrado en tránsito?'
    answer: 'En el alcance de la confianza. TLS protege cada tramo, pero el servidor descifra y puede leerlo todo. Cifrado de extremo a extremo significa que solo los usuarios que se comunican tienen las claves — el propio operador del servicio no puede leer el contenido. E2EE protege contra el servidor; TLS protege el camino hacia él.'
  - question: '¿El cifrado en reposo protege contra hackers?'
    answer: 'Solo contra un tipo específico: los que obtienen el almacenamiento — drives robados, backups filtrados, buckets mal configurados. Un atacante que compromete la aplicación o roba credenciales lee los datos libremente, porque la app descifra de forma legítima. El cifrado no es control de acceso; complementa a las ACLs, nunca las sustituye.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'NIST FIPS 197 — Advanced Encryption Standard (AES)'
    url: 'https://csrc.nist.gov/pubs/fips/197/final'
  - name: 'RFC 8446 — TLS 1.3'
    url: 'https://datatracker.ietf.org/doc/html/rfc8446'
  - name: 'NIST SP 800-57 — Key Management Recommendations'
    url: 'https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final'
  - name: 'OWASP Cryptographic Storage Cheat Sheet'
    url: 'https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html'
  - name: 'Encryption — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Encryption'
cta:
  title: 'Cifrado por defecto, de punta a punta de tu stack'
  text: 'Back4app sirve cada API, archivo y Live Query sobre TLS y almacena datos y backups cifrados — lo que te queda es política: contraseñas solo con hash (integrado), cifrado a nivel de campo para lo genuinamente sensible y ACLs para el acceso.'
  linkText: 'Empieza gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-04'
translationKey: data-encryption-at-rest-transit
---

**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](https://csrc.nist.gov/pubs/fips/197/final) 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

| Pregunta | Respuesta |
| --- | --- |
| En reposo | AES-256 en discos, bases, backups — contra medios robados |
| En tránsito | TLS 1.2+ en toda conexión — contra escuchas y MITM |
| El punto ciego | Ninguno frena una app comprometida — el cifrado no es control de acceso |
| El problema real | La gestión de claves — claves guardadas junto a los datos son teatro |
| La confusión a jubilar | Las contraseñas reciben *hash* (bcrypt/argon2), nunca cifrado |

## 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:

```text
              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:**

```javascript
// 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
// Flutter / Dart — Back4app Flutter SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
final user = ParseUser('ada', secret, 'ada@example.com');
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
```

**Swift:**

```swift
// 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
```

**Kotlin:**

```kotlin
// 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](https://datatracker.ietf.org/doc/html/rfc8446) 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:

| Capa | Cómo | Derrota | No toca |
| --- | --- | --- | --- |
| Disco completo (LUKS/dm-crypt) | El SO cifra el volumen | Hardware robado/desechado | A cualquiera dentro del sistema en ejecución |
| Transparente (TDE) | La base cifra los archivos al escribirlos | Archivos de datos y backups robados | A cualquiera con credenciales de la base |
| Campo/columna | Columnas específicas cifradas, la app guarda las claves | DBAs curiosos, brechas más amplias de la base | El compromiso de la propia app |
| Nivel de aplicación | Cifrado *antes* de llegar al almacenamiento | Todo lo que está debajo de la app | La app y su almacén de claves |

```mermaid
flowchart LR
  accTitle: Envelope encryption manteniendo las claves separadas de los datos
  accDescr: Los datos de la aplicación se cifran con una clave de datos. La clave de datos se cifra a su vez con una clave de cifrado de claves guardada en un servicio de gestión de claves o en un módulo de seguridad de hardware, de modo que una base de datos robada contiene ciphertext y claves envueltas, pero nada que descifre sin el servicio de claves custodiado por separado.
  D["Datos"] -->|"AES-256-GCM"| C["Ciphertext<br/>en la base de datos"]
  DEK["Clave de datos (DEK)"] -->|"cifra"| D
  KEK["Clave de cifrado de claves (KEK)"] -->|"envuelve"| DEK
  KMS["Servicio de claves / HSM<br/>sistema separado, auditado"] -->|"custodia"| KEK
  T["Ladrón con la base de datos"] -.->|"obtiene ciphertext +<br/>claves envueltas — nada se abre"| C
```

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

| | Cifrado | Hashing |
| --- | --- | --- |
| Reversible | Sí — con la clave | No — por diseño |
| Correcto para | Datos que necesitas leer de vuelta | Contraseñas, comprobaciones de integridad |
| Estándares | AES-256-GCM | bcrypt, scrypt, argon2 (lentos + salt) |
| La falla | Perder o filtrar claves | Hashes rápidos sin salt (MD5, SHA-256 puro) |

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

| Situación | Usa |
| --- | --- |
| Cualquier dato, cualquier app | TLS en todas partes + cifrado en reposo de la plataforma — el piso |
| La pesadilla del backup robado | Backups cifrados + claves guardadas en otro lugar |
| Columnas sensibles (salud, documentos) | Cifrado de campo/aplicación, claves en env o KMS |
| "Ni nosotros deberíamos leerlo" | Cifrado de extremo a extremo — acepta los costos de producto |
| Contraseñas | Hashing (bcrypt/argon2) — nunca cifrado |
| Preocupación por el acceso, no por el robo | [ACLs y seguridad a nivel de fila](/glossary/es/seguridad-a-nivel-de-fila/) — el cifrado no va a ayudar |

## Limitaciones y trade-offs

- **El cifrado no es control de acceso.** El argumento de la [seguridad por capas](/glossary/es/seguridad-capa-de-datos-vs-aplicacion/) 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](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) 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](/glossary/es/seguridad-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](/glossary/es/listas-de-control-de-acceso-acl/) 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.