Cifrado en reposo (Encryption at rest)

Los datos se cifran antes de escribirse y se descifran al leerse, mediante algo que está entre quien pide y el almacenamiento. Dónde se sitúa ese algo decide qué protege el control de verdad.

En la capa de disco o de volumen se cifra el dispositivo entero y cualquier cosa que lo monte ve texto en claro. Eso defiende de que se saque una unidad, de que roben un portátil o de que se dé de baja mal un equipo, y de nada más. En la capa del servicio de almacenamiento, que es lo que aplican por defecto los proveedores cloud, los objetos y los volúmenes se cifran con claves que gestiona la plataforma, y cualquiera a quien la plataforma autorice recibe texto en claro. En la capa de la base de datos se cifran los ficheros y toda consulta autorizada devuelve filas legibles. En la capa de aplicación se cifran campos concretos antes de que lleguen a la base de datos, así que el administrador de la base ve texto cifrado y solo la aplicación puede leer los valores.

Casi todos los despliegues reales usan cifrado de sobre. Una clave de cifrado de datos cifra los datos, y una clave de cifrado de claves custodiada en un servicio de gestión de claves cifra esa clave. Rotar la clave exterior sale entonces barato, porque solo hay que volver a cifrar la clave pequeña, y el acceso al servicio de gestión de claves se convierte en el control de verdad.

Ese último punto lo es todo. Una vez los datos están cifrados con solvencia, la seguridad de los datos es la seguridad de las claves y de quién puede pedirle al servicio de claves que las use.

El malentendido más frecuente, y aparece sin parar en las respuestas de auditoría, es que el cifrado en reposo protege de una brecha. No protege de la brecha que con más probabilidad vas a tener. Un atacante que compromete la aplicación, o que roba una credencial con acceso de lectura, pregunta por la vía autorizada y obtiene texto en claro. En nuestros proyectos no nos ha parado nunca el cifrado en reposo, porque no llegamos al disco, llegamos a una identidad.

El segundo es la custodia de claves sin separación. La clave está en la misma cuenta, con los mismos administradores y protegida por las mismas credenciales que los datos. Compromete la cuenta y tienes las dos cosas. Donde la política de la clave permite que el mismo rol que lee el almacenamiento use la clave, los dos controles son un solo control.

El tercero es la cobertura. La base de datos principal está cifrada y las réplicas, las exportaciones, la copia de analítica, los ficheros temporales, la cola de mensajes y la copia de seguridad que hace otro equipo no lo están. Los datos no se quedan donde se diseñó que estuvieran, y es en las copias donde los encontramos.

El cuarto es confundir el valor por defecto de la plataforma con una decisión. Un almacenamiento cloud cifrado con claves gestionadas por el proveedor satisface la frase «los datos están cifrados en reposo» y no te da ninguna separación de funciones ni ninguna capacidad de revocar el acceso destruyendo una clave. Puede ser perfectamente adecuado. Debería ser una elección documentada y no una casilla que se marcó sola y que después se le cita a un auditor como si lo fuera.

Los tres estados se comparan constantemente, casi siempre para establecer cuál cubre un control. Defienden de adversarios distintos.

La fila que importa para planificar es la última. Ni el cifrado en reposo ni el cifrado en tránsito hacen nada contra una aplicación comprometida o una credencial robada, que es como ocurre casi cualquier brecha real. Son necesarios, baratos y resuelven amenazas concretas y estrechas. Presentarlos como respuesta general de protección de datos es donde se tuercen las respuestas de auditoría.

Presentar el cifrado en reposo como control frente a brechas. Responde a una amenaza de la capa de almacenamiento. Dilo con precisión, sobre todo en una respuesta regulatoria donde el texto se va a leer con lupa.

Guardar la clave donde están los datos. Cuentas separadas, administradores separados, y políticas de clave que nombren los roles autorizados a usar cada clave.

Cifrar la base de datos y no sus copias. Las copias de seguridad, las réplicas, las exportaciones y las copias de analítica son las que se van.

No rotar nunca, o rotar sin probarlo. Una rotación de claves que no se ha ejercitado es un riesgo de recuperación, y una clave que no se puede rotar es un riesgo permanente.

Cifrar un campo por el que además necesitas buscar. El cifrado determinista para conservar la búsqueda filtra la igualdad, que en campos de cardinalidad baja se parece mucho a filtrar el valor. Cuando el requisito es que sea buscable y esté protegido, la tokenización suele ser la mejor respuesta.

Decide la capa a partir de la amenaza y no a partir del valor por defecto. Si lo que preocupa es el hardware y las bajas de equipos, el cifrado de volumen basta y sale gratis. Si lo que preocupa es un administrador de bases de datos o un empleado del proveedor cloud, solo el cifrado a nivel de campo o de aplicación cambia algo. Son proyectos distintos y solo uno de ellos es barato.

Separa la custodia de las claves de la custodia de los datos. Usa un servicio de gestión de claves, guarda las claves en una cuenta con administradores distintos, escribe políticas de clave que nombren los roles autorizados a usar cada una, y registra cada uso. Donde el requisito sea de verdad exigente, un módulo de seguridad hardware te da una clave que no se puede exportar, que es una garantía sustancialmente distinta de una clave gestionada.

Cubre las copias. Inventaría todos los sitios donde aterrizan los datos, incluidas las copias de seguridad, las réplicas, las exportaciones, las colas y los almacenes de analítica, y aplica el mismo estándar. Ese inventario es la clasificación de datos haciendo trabajo de verdad en vez de producir etiquetas.

Y después, ya que el control no aborda el ataque probable, gasta el resto del esfuerzo donde está el ataque: en quién puede recorrer la vía autorizada. Acota las identidades que pueden leer los datos, exígeles autenticación fuerte y registra las lecturas. Eso es lo que cambia algo en el incidente que de verdad vas a tener.

Los reguladores y los esquemas de certificación preguntan por el cifrado en reposo expresamente, y la respuesta honesta nombra la capa, el modelo de custodia de claves, la práctica de rotación y la cobertura de las copias. Una respuesta que solo diga «los datos están cifrados en reposo» invita a una repregunta más difícil de contestar, y contestarla con precisión a la primera sale más rápido.

En nuestros informes el hallazgo rara vez es la ausencia de cifrado. Es la custodia de claves dentro de la misma frontera que los datos, o una copia que se quedó fuera, o una vía autorizada con controles flojos que deja la pregunta entera sin sentido. Decimos claramente cuándo el cifrado está presente y es irrelevante para el camino que usamos, porque un cliente que crea que el control nos paró no va a arreglar lo que sí lo habría hecho.

La severidad va con lo que expone la vía autorizada, no con el estado del cifrado. Cuando leemos los datos a través de una identidad, informamos de la identidad y del camino, y anotamos el cifrado como presente y no aplicable al hallazgo.

Revisar la custodia de claves, la política de claves y la cobertura de las copias forma parte de evaluar un entorno cloud, donde el servicio de claves suele ser el objetivo de más valor de la cuenta.

¿El cifrado en reposo nos protege de una brecha de datos? Protege de las brechas que ocurren en la capa de almacenamiento: discos robados, copias de seguridad copiadas, hardware dado de baja mal. No protege de una aplicación comprometida, de una credencial robada ni de una identidad con permisos de más, que es como ocurren la mayoría de las brechas.

¿Usamos claves gestionadas por el proveedor o por el cliente? Las claves gestionadas por el cliente te dan separación de funciones, una política de clave auditable y la capacidad de revocar el acceso destruyendo una clave. Cuestan esfuerzo de operación y traen un riesgo real de perder datos si la gestión de claves es mala. Elige a propósito y deja escrito el motivo.

¿Basta con el cifrado por defecto del cloud? Para las amenazas de hardware y de baja de equipos, sí. No da ninguna separación entre quien administra los datos y quien controla las claves, así que si tu modelo de amenazas incluye a alguien de dentro o una cuenta comprometida, ahí no cambia nada.

¿Y el cifrado en uso? La computación confidencial y las tecnologías de enclave protegen los datos mientras se procesan, que es el hueco que dejan los otros dos. Son reales y hoy de aplicabilidad estrecha, y conviene acotarlas a cargas de trabajo concretas de alto valor en vez de adoptarlas de forma general.