Crypto‑shredding no protege los datos en copias de seguridad antiguas
Eliminar la clave de cifrado en la base de datos no basta para borrar la información guardada en backups previos.
Una solicitud de borrado llega a tu servicio. Los datos del usuario están en la base de datos principal, replicados en tres nodos y almacenados en backups nocturnos que conservas durante cinco años por exigencia regulatoria. No puedes sobrescribir un backup, así que la práctica más extendida es el crypto‑shredding: cada registro se cifra con una clave de datos (DEK) única, la DEK se envuelve con una clave maestra (KEK) y se guarda junto al ciphertext. Cuando se debe eliminar el registro, simplemente se elimina la referencia a la DEK (wrapped_dek = NULL). En teoría, sin la DEK el ciphertext es ruido y los backups quedarían inutilizables.
En la práctica, el envoltorio de la DEK sigue presente en todas las copias realizadas antes del borrado. La KEK sigue existiendo y sigue usándose para desenrollar esas DEK en cualquier restauración. Por tanto, si restauras un backup anterior al borrado y lo apuntas a la KEK actual, el registro “borrado” vuelve a aparecer. El problema no está en el algoritmo de cifrado, sino en la ubicación de la clave.
Cómo cerrar la brecha
La solución consiste en rotar y destruir también la KEK. El proceso típico es:
- Generar una nueva KEK.
- Cargar ambas claves (nueva como activa, antigua solo para lectura).
- Re‑envolver todas las DEK vivas bajo la nueva KEK (solo cambia unos pocos bytes por fila, sin re‑cifrar el ciphertext).
- Eliminar la KEK antigua de todos los lugares donde se almacena: variables de entorno, archivos, secret stores, KMS y, crucialmente, de cualquier backup de material de clave.
Una vez destruida la KEK antigua, cualquier backup anterior a la rotación contiene DEK envueltas con una clave inexistente y, por lo tanto, se vuelve ruido. Los registros que estaban vivos al momento de la rotación se re‑envuelven y siguen accesibles.
Detalles operativos
- En KMS, “destruir” suele ser una eliminación programada con periodo de espera; el borrado real ocurre al final de ese plazo.
- Si se hacen backups de las claves maestras, esas copias también deben eliminarse, o se traslada el riesgo a otro nivel.
- El mismo problema aparece en WALs, snapshots de volúmenes, replicaciones lógicas, dumps y versiones de servicios de gestión de claves (por ejemplo, Vault mantiene versiones antiguas hasta que se ajusta
min_decryption_version).
Riesgos durante la rotación
Re‑envolver DEK parece trivial, pero al ejecutarse contra un sistema en producción pueden surgir colisiones: si un registro se marca como borrado entre la lectura y la escritura del nuevo envoltorio, se podría volver a insertar una clave válida. La solución es usar una condición de actualización que verifique que el registro sigue sin estar marcado como eliminado y que la clave no haya cambiado. Además, la rotación debe procesarse en lotes pequeños (páginas de cientos de filas) para evitar bloqueos prolongados y permitir registrar filas problemáticas sin abortar toda la operación.
En resumen, la garantía de borrado inmediato solo es válida para la base de datos activa; la protección contra copias de seguridad depende de la frecuencia con la que se roten y destruyan las KEK. Si tu política de retención declara que los datos desaparecen en treinta días, deberás rotar y eliminar la KEK al menos mensualmente y conservar pruebas de esa destrucción.
