Familiarícese con el nuevo concepto de Crypto-Shredding

La destrucción criptográfica es una técnica que consiste en eliminar permanentemente la clave de cifrado que protege un conjunto de datos, en lugar de borrar los datos en sí, lo que hace que estos sean prácticamente irrecuperables. Esto es importante porque permite a las organizaciones cumplir con las solicitudes de "derecho de supresión" (Artículo 17 del RGPD) en copias de seguridad y réplicas sin tener que buscar cada copia individualmente. Acción recomendada: utilice el flujo de trabajo de destrucción de claves nativo de su KMS en la nube con un período de espera deliberado y combínelo con un cifrado robusto para garantizar la eficacia de la técnica.

Publicado: agosto de 2021. Actualizado: agosto de 2026. Revisado por el equipo de gestión de claves en la nube de Encryption Consulting.

Para saber cómo se aplican las obligaciones de cumplimiento más amplias del RGPD en entornos de nube, más allá de la mera destrucción de claves, consulte nuestra publicación « Estándares de cumplimiento de seguridad en la nube: PCI DSS y RGPD» . Para saber cómo difiere el KMS subyacente entre proveedores, consulte « AWS KMS frente a Azure Key Vault frente a GCP KMS».

¿Qué es la destrucción criptográfica?

La destrucción criptográfica es la técnica de descartar la clave de cifrado de un conjunto de datos sin borrar ni eliminar los datos cifrados en sí, lo que hace que dichos datos sean permanentemente indescifrables en la práctica. La protección de datos se ha convertido en un tema prioritario, ya que las filtraciones y una regulación más estricta han convertido el cifrado en la práctica habitual en todos los sectores. Sin embargo, cifrarlo todo genera un segundo problema: gestionar qué sucede con los datos cifrados una vez que deben destruirse.

Los datos cifrados generalmente se dividen en dos categorías. Los datos cifrados activos son aquellos que las aplicaciones utilizan actualmente y que se gestionan dentro del ecosistema de seguridad habitual. Los datos cifrados pasivos no se utilizan activamente y son candidatos a ser destruidos, ya sea porque ha expirado el período de retención o porque el titular de los datos ha ejercido su derecho de supresión. La destrucción criptográfica es la solución práctica para la categoría de datos pasivos.

¿Por qué es tan difícil eliminar datos para cumplir con el derecho de supresión del RGPD?

La destrucción de datos es realmente difícil de ejecutar correctamente cuando se ejerce como un derecho individual, especialmente bajo normativas de protección de datos como el artículo 17 del RGPD. Para respetar literalmente el derecho de supresión, una organización debe localizar cada referencia a los datos de un individuo específico en bases de datos de producción, registros, copias de seguridad, almacenes de datos y cualquier exportación posterior, y luego eliminar cada copia. Esta no es una tarea sencilla: las copias de seguridad suelen ser inmutables por diseño precisamente por su resistencia al ransomware, lo que las hace valiosas; los registros pueden estar sujetos a un requisito de retención independiente; y una exportación de análisis posterior puede haber propagado los datos a algún lugar al que el sistema original no tiene acceso.

¿Cómo resuelve la criptodegradación el problema de la destrucción de datos?

La destrucción criptográfica evita por completo el problema de la búsqueda y eliminación. Dado que los datos se cifraron antes de ser escritos, la destrucción de la clave hace que todas las copias de esos datos (producción, copia de seguridad, registro, exportación) sean indescifrables de inmediato, sin necesidad de localizarlas individualmente. Si se destruye la clave de cifrado y no existe ninguna otra copia, nadie podrá descifrar los datos que protegía , independientemente de dónde se encuentren físicamente.

Para que esto sea realmente efectivo, deben cumplirse dos condiciones. Primero, no puede existir ninguna otra copia de la clave; una clave almacenada en un segundo sistema, en caché en un proceso de aplicación o respaldada por separado invalida toda la técnica. Segundo, el algoritmo de cifrado en sí debe permanecer intacto; si el cifrado que protege los datos fuera vulnerable, ya estaría obsoleto según el NIST u otro organismo de estandarización y no debería haberse utilizado en primer lugar, por lo que esta es una suposición razonable para cualquier algoritmo actualmente aprobado (AES-256, por ejemplo). Dadas ambas condiciones, la destrucción criptográfica es funcionalmente equivalente a eliminar o borrar los datos, aunque los bytes del texto cifrado aún estén físicamente presentes en el disco.

En la práctica, esto cambia el significado de una solicitud de "eliminación" en la capa de infraestructura. Cuando se crean nuevos datos que se van a almacenar, respaldar o replicar, primero se cifran con una clave específica para esos datos (por inquilino, por usuario o por registro, según los requisitos de granularidad). Cuando es necesario eliminar esos datos, el sistema no busca todas las copias en su infraestructura; simplemente elimina la clave de cifrado.

¿Cómo afecta el control de claves nativo frente al control de claves externo al cifrado de datos?

La ubicación de la clave determina la rapidez, la auditabilidad y la reversibilidad de una operación de destrucción de datos criptográficos.

Modelo de control de llaves	Cómo funciona la destrucción	Mejor ajuste
Gestión nativa en la nube (AWS KMS, Azure Key Vault, Google Cloud KMS)	El proveedor de la nube impone un período de espera obligatorio antes de la destrucción permanente (véase la tabla a continuación), durante el cual se puede cancelar la operación.	La mayoría de las cargas de trabajo. Ofrece un equilibrio entre una auténtica red de seguridad contra la eliminación accidental o maliciosa y una eventual destrucción permanente impuesta por el proveedor.
BYOK (material clave proporcionado por el cliente, alojado en la nube)	El flujo de trabajo de destrucción gestionado por el proveedor es el mismo que para las claves nativas, pero la organización conserva su propia copia del material de clave original fuera de la nube, que también debe destruirse para que la destrucción criptográfica sea completa.	Organizaciones que necesitan demostrar la procedencia o portabilidad de datos clave, pero que se sienten cómodas con la custodia diaria del HSM por parte del proveedor de la nube.
HYOK / administrador de claves externo (Cloud EKM, AWS External Key Store, Azure Managed HSM con una raíz externa)	La clave KMS de la nube es un puntero a una clave que posee un administrador de claves externo; la destrucción de la clave en el sistema externo surte efecto de inmediato y es independiente del período de retención de la propia nube.	Datos altamente regulados en los que una organización necesita demostrar que fue ella, y no el proveedor de la nube, quien tuvo el control último sobre el evento de destrucción, y donde la destrucción inmediata e independiente del proveedor es un requisito explícito.

La mayoría de las organizaciones deberían confiar en la destrucción de claves gestionada por la nube, que incluye un período de espera predefinido; este proceso es auditable, reversible durante dicho período y no requiere infraestructura adicional. Solo se debe recurrir a un modelo externo/HYOK cuando un requisito normativo o contractual específico exija una destrucción que no dependa del proceso del proveedor de la nube.

¿Cómo debería IAM regular quién puede destruir una clave?

Destruir una clave es una de las pocas operaciones criptográficas que no se pueden deshacer una vez que expira su período de espera, por lo que su modelo IAM debería ser más estricto que los permisos de uso de claves ordinarios.

1. Separe los permisos de "usar la clave" (cifrar/descifrar) de los permisos de "programar la destrucción de la clave"; casi ninguna identidad necesita ambos.
2. Se requiere una justificación documentada y registrada (un ID de solicitud de borrado específico, una fecha de vencimiento de la política de retención) antes de programar cualquier destrucción de claves.
3. Utilice un flujo de trabajo con un segundo aprobador o de emergencia para las solicitudes de destrucción de cualquier clave que proteja los registros de más de un interesado, ya que una destrucción masiva errónea de claves es un incidente de pérdida de datos, no solo una victoria en materia de privacidad.
4. Conceda amplios derechos de cancelación de destrucción programada (un administrador de seguridad siempre debería poder detener rápidamente una destrucción en curso), incluso mientras que los derechos de inicio de la destrucción sigan siendo limitados.
5. Registra cada evento de programación, cancelación y destrucción completada en un sistema que la identidad que realiza la destrucción no puede modificar.

¿Cómo interactúa la rotación de claves con la destrucción criptográfica?

La rotación y el cifrado criptográfico son operaciones opuestas que a menudo se confunden. La rotación crea una nueva versión de clave activa, conservando intencionadamente las versiones antiguas para que los datos previamente cifrados sigan siendo descifrables; ninguno de los tres principales sistemas de gestión de claves en la nube destruye automáticamente las versiones antiguas de clave durante la rotación. El cifrado criptográfico es la acción opuesta y deliberada: destruir una versión específica de clave a propósito para que los datos que protege sean permanentemente irrecuperables.

Ambos interactúan en arquitecturas de cifrado por inquilino o por registro: si un sistema rota una clave compartida entre los datos de varios inquilinos, la solicitud de eliminación criptográfica de un inquilino individual no puede destruir esa clave compartida sin destruir también el acceso de todos los demás inquilinos. La eliminación criptográfica granular requiere una arquitectura de clave granular (una clave, o una versión de clave, por unidad de datos apta para el borrado) definida en la fase de diseño, no una adaptación posterior a la llegada de la primera solicitud de borrado.

¿Qué información debería registrar para que la destrucción segura de criptomonedas sea válida en una auditoría?

• La solicitud de borrado que desencadenó la destrucción: el ticket específico de derecho de borrado, la norma de política de retención o el incidente que justificó la acción.
• Calendario y eventos cancelados: Quién programó la destrucción, cuándo y si se canceló antes de que expirara el período de espera.
• Confirmación de destrucción completada: la marca de tiempo en la que la clave se volvió permanentemente irrecuperable, que es el registro probatorio de una solicitud de borrado completada.
• Mapeo de clave a ámbito de datos: qué registros, inquilinos o interesados ​​protegía esa clave específica, para que un auditor pueda verificar que la destrucción cubrió realmente el alcance de la solicitud de borrado.

¿Cuánto cuesta la destrucción de criptomonedas?

La destrucción criptográfica en sí misma no tiene un precio aparte en ningún KMS en la nube importante; la programación y la finalización de la destrucción de claves están incluidas en las operaciones estándar del KMS. El verdadero factor determinante del costo es arquitectónico: admitir la destrucción criptográfica granular (una clave por inquilino o por registro, en lugar de una clave compartida para todo un conjunto de datos) multiplica la cantidad de claves activas que un KMS debe administrar, y el precio por clave o por partición HSM (especialmente para claves respaldadas por HSM) aumenta en función de esa cantidad. Un diseño que necesite destruir criptográficamente registros de clientes individuales, no solo conjuntos de datos completos, debería presupuestar un inventario de claves considerablemente mayor que un diseño de una sola clave por conjunto de datos.

Los datos cifrados no se eliminan mediante el cifrado criptográfico, por lo que los costos de almacenamiento de ese texto cifrado, ahora permanentemente inaccesible, continúan hasta que una política de ciclo de vida de almacenamiento independiente lo elimine. Considere este costo de almacenamiento continuo en una política de retención en lugar de asumir que el cifrado criptográfico por sí solo elimina el costo de conservar los datos.

¿Cómo es la arquitectura de criptodestrucción en la nube múltiple?

Cada una de las principales plataformas en la nube implementa la destrucción de claves nativa con una estructura similar pero con especificaciones diferentes, lo cual es importante para una organización que intenta ejecutar un proceso de borrado coherente en las tres.

Cloud	Período de espera predeterminado	Rango configurable
AWS KMS	30 días	7-30 días
Azure Key Vault (eliminación lógica)	90 días	De 7 a 90 días, se configura solo al crear la bóveda.
Sistema de gestión de claves de Google Cloud	30 días	Personalizable por clave en el momento de su creación; las organizaciones pueden imponer un mínimo mediante una restricción de política de la organización.

Un flujo de trabajo de borrado en múltiples nubes (datos de un mismo cliente distribuidos entre AWS, Azure y GCP) debe tener en cuenta que el período de retención predeterminado de Azure es tres veces mayor que el de AWS o GCP, lo cual es importante al informar la fecha de finalización de una solicitud de borrado conforme al RGPD que abarca varias nubes. Estandarice el período de cumplimiento más corto que permita su tolerancia al riesgo en las tres plataformas, en lugar de informar tres fechas de finalización diferentes al mismo interesado.

¿Cuáles son las limitaciones de la destrucción criptográfica de datos?

• Solo funciona si el cifrado era robusto y no existe una copia de seguridad o un depósito de claves; un cifrado débil o una copia de seguridad de la clave que se haya pasado por alto hacen que la "destrucción" sea meramente superficial.
• Los datos cifrados en sí mismos siguen ocupando espacio de almacenamiento y siguen requiriendo su propia decisión sobre el ciclo de vida y la retención de datos.
• Actualmente, ningún organismo de normalización importante (incluido el NIST) prescribe la destrucción criptográfica como un método certificado de borrado seguro de datos; la norma NIST SP 800-88 Rev. 1 sigue siendo el estándar de referencia para el borrado seguro de medios, y las organizaciones que necesiten una certificación de borrado seguro deben evaluar directamente dicha norma en lugar de basarse únicamente en la destrucción criptográfica.
• El cifrado criptográfico granular (por registro) requiere que la arquitectura de claves se diseñe para ello desde el principio; no se puede adaptar fácilmente a un sistema construido en torno a una clave compartida.

Lista de verificación para la toma de decisiones: Implementación de la destrucción criptográfica de datos

1. Confirme que cada conjunto de datos que pueda necesitar un borrado individual esté cifrado con su propia clave o versión de clave, y no con una clave compartida para todo el conjunto de datos.
2. Seleccione la destrucción de claves gestionada en la nube nativa como opción predeterminada; reserve la destrucción externa/HYOK para casos con un requisito específico de independencia del proveedor.
3. Se requiere un segundo aprobador y una justificación documentada para cada solicitud de destrucción de claves.
4. Registre la solicitud de borrado, los eventos de programación/cancelación y la confirmación de destrucción completada como registro de auditoría del borrado.
5. Combine la destrucción de claves con una política de ciclo de vida de almacenamiento independiente para que el texto cifrado, ahora indescifrable, no permanezca indefinidamente.

¿Qué recomendaría Encryption Consulting?

Las organizaciones que sufren las consecuencias de la destrucción criptográfica de datos son casi siempre aquellas que diseñaron su arquitectura de cifrado en torno a una clave compartida por conjunto de datos, y que luego descubrieron, ante la primera solicitud de borrado individual, que no podían destruir un registro sin dañar todos los demás registros que utilizaban la misma clave. Los servicios de gestión de claves en la nube de Encryption Consulting diseñan la arquitectura de claves por inquilino o por registro, el flujo de trabajo de aprobación de destrucción y el registro de auditoría necesarios para que un proceso de borrado basado en la destrucción criptográfica sea defendible. Además, nuestra oferta de HSM como servicio proporciona a ese inventario de claves una custodia respaldada por hardware sin la sobrecarga operativa de gestionar directamente los HSM.

Preguntas frecuentes

¿Es la destrucción criptográfica un estándar de saneamiento de datos reconocido oficialmente?

No. No existe ninguna norma del NIST, del RGPD ni de ninguna otra autoridad que prescriba formalmente la destrucción criptográfica como método de saneamiento certificado. La publicación especial 800-88, revisión 1, del NIST sigue siendo el documento de referencia para el saneamiento de medios en general, y las organizaciones que necesiten una certificación deben evaluar directamente dicha norma.

¿Cumple la destrucción segura de datos mediante criptografía el derecho de supresión del RGPD?

Se utiliza ampliamente como mecanismo práctico para cumplir con los requisitos del Artículo 17, especialmente en lo que respecta a copias de seguridad y réplicas que, de otro modo, requerirían localizar y eliminar cada copia individualmente. Se trata de un control técnico, no de una garantía legal; su cumplimiento con las expectativas de un regulador específico depende de la solidez del cifrado y de la ausencia de copias de clave supervivientes.

¿Puedo cifrar los datos de un solo cliente si comparte una clave con otros clientes?

Esto no es posible sin destruir el acceso de todos los demás clientes a los datos que utilizan esa misma clave. El cifrado granular preciso requiere una arquitectura de claves por inquilino o por registro, diseñada desde el principio.

¿Cuánto tiempo tarda en destruirse permanentemente una clave en AWS, Azure o GCP?

AWS KMS tiene por defecto un período de espera de 30 días (configurable de 7 a 30 días), la eliminación temporal de Azure Key Vault tiene por defecto un período de 90 días (configurable de 7 a 90 días, establecido al crear el almacén) y Google Cloud KMS tiene por defecto un período de 30 días, ajustable por clave y sujeto a cualquier mínimo establecido por la política de la organización.

¿Qué ocurre con los datos cifrados una vez destruida la clave?

Permanece exactamente donde estaba, ocupando espacio de almacenamiento, pero es permanentemente ilegible. El cifrado no elimina ni mueve el texto cifrado; se necesita una política de ciclo de vida de almacenamiento independiente para eliminarlo finalmente.

¿Necesita ayuda para diseñar una arquitectura de claves que realmente admita el cifrado de registros individuales? Hable con el equipo de Gestión de Claves en la Nube de Encryption Consulting.

Recursos

NIST SP 800-88 Rev. 1: Directrices para la desinfección de medios de almacenamiento