Atlasingeniería

Fundamentos de cloudSemi-SeniorTema 8Semi-Senior

Cifrado en reposo y en tránsito con servicios de claves

Activar el cifrado en reposo es una casilla y casi nunca es la parte difícil. Lo que importa es quién tiene la clave, quién puede usarla y qué queda registrado cuando alguien la usa: ahí es donde el cifrado protege o no protege de nada.

Datos de proveedores verificados contra la documentación oficial el 19 de sept de 2026.

“¿Los datos están cifrados?” es la pregunta que aparece en toda auditoría, y la respuesta casi siempre es sí, porque hoy los servicios de nube cifran en reposo por defecto.

La pregunta útil es otra: si alguien se lleva una copia de la base, ¿le sirve de algo? Y eso no depende de que haya cifrado, sino de quién puede pedirle a la nube que lo descifre. El cifrado en reposo protege del disco robado, no del permiso de más.

En tránsito y en reposo protegen cosas distintas

En tránsitoEn reposo
Protege deQue alguien lea o altere lo que viaja por la redQue alguien lea el medio donde están guardados
Cómo se haceTLS entre cliente y servicio, y entre servicios internosEl servicio cifra antes de escribir en disco
Quién lo administraCertificados: emisión y renovaciónClaves: rotación y permisos de uso
Qué no cubreNada de lo que ya llegó y se guardóA quien tenga permiso de leer por la API

De ahí sale la aclaración que más falta hace: el cifrado en reposo es transparente. Una consulta autorizada recibe los datos en claro, porque el servicio los descifra al leerlos. No protege contra credenciales robadas, ni contra un permiso mal puesto, ni contra una consulta que exporta todo. Para eso están los permisos, la red y la auditoría.

Una clave que cifra claves

Ningún servicio cifra terabytes con la clave que uno administra. Se usa una jerarquía de dos niveles, y entenderla explica por qué la rotación es barata.

Cómo se cifra un objeto

  1. El servicio genera una clave de datos única para ese objeto o ese volumen.
  2. Cifra los datos con esa clave, que es rápida y local.
  3. Le pide al servicio de claves que cifre la clave de datos con la clave maestra.
  4. Guarda la clave de datos cifrada al lado de los datos, y descarta la versión en claro.
  5. Para leer, pide descifrar la clave de datos —ahí se registra el acceso— y con ella descifra.

Antes de seguir, predecí

Se rota la clave maestra de un bucket con 10 TB. ¿Hay que volver a cifrar los 10 TB?
CapacidadAWSGoogle CloudAzure
Servicio de clavesKMSCloud KMSKey Vault y Managed HSM
Clave del proveedor, transparenteClave gestionada por AWSCifrado por defecto de GoogleClaves gestionadas por Microsoft
Clave propia, con permisos y auditoríaClave gestionada por el clienteClave gestionada por el clienteClave gestionada por el cliente
Secretos de aplicaciónSecrets Manager y Parameter StoreSecret ManagerKey Vault (secretos)
Contrastado con la documentación de cada proveedor en septiembre de 2026.

La clave propia sirve por los permisos, no por el algoritmo

La clave del proveedor y la propia cifran exactamente igual de bien. La diferencia es de control.

Qué se gana con una clave administrada por uno

  1. Permiso separado: usar la clave es un permiso distinto de leer el recurso. Alguien con acceso al bucket pero sin permiso sobre la clave no puede leer nada.
  2. Registro de cada uso: cada operación de descifrado queda en el registro de auditoría, con quién y desde dónde. Es de las señales más útiles que existen.
  3. Botón de apagado: deshabilitar la clave vuelve ilegibles los datos sin borrarlos, que es la respuesta rápida ante un incidente.
  4. Política propia de rotación, y condiciones: por ejemplo, permitir el uso sólo desde un servicio determinado.

Antes de seguir, predecí

Un atacante obtiene credenciales de una aplicación que lee un bucket cifrado con clave propia. ¿El cifrado lo detiene?

Secretos: lo que no es cifrado pero se confunde

Las contraseñas de terceros, los tokens de API y las credenciales que no se pueden reemplazar por un rol viven en un gestor de secretos, que es un servicio distinto del de claves aunque se apoye en él.

Cómo se maneja un secreto que no se puede evitar

  1. No está en el repositorio ni en la imagen: se lee en tiempo de ejecución.
  2. No está en una variable de entorno si se puede evitar: las variables se imprimen en los volcados de error y en los paneles de configuración.
  3. Se lee con un rol, así que quién lo leyó queda registrado.
  4. Se rota, idealmente con la rotación automática que ofrecen los gestores para las bases gestionadas del propio proveedor.
  5. Se cachea en memoria con un vencimiento corto: leerlo en cada request cuesta plata y latencia.

Cierre

Autoevaluación

¿Lo entendiste?

¿De qué protege el cifrado en reposo?
¿Por qué rotar la clave maestra no obliga a volver a cifrar los datos?
¿Qué gana una clave administrada por el cliente frente a la del proveedor?
Se subió una contraseña al repositorio y se borró en el commit siguiente. ¿Qué hay que hacer?