DATA LIFECYCLE / PRACTICAL DESIGN

Del almacenamiento a la eliminación,
administrar dónde van los datos.

¿Qué pasa si una dirección cifrada permanece en registros de texto sin formato o índices de búsqueda? ¿Qué pasa si los datos eliminados regresan de una copia de seguridad? La protección debe extenderse más allá de la bóveda.

Separe los registros comerciales de los datos personales.

Para el comercio minorista, mantenga los ID de proxy, los pedidos, los productos y el estado de entrega en los sistemas comerciales. Almacene nombres, direcciones y números de teléfono en la bóveda. Los flujos de trabajo de entrega autorizados recuperan solo lo que necesitan.

Sistema de pedidos: ID de pedido/ID de proxy/productos/estado de entrega
Bóveda: nombre, dirección y teléfono cifrados asignados a una ID de proxy
Entrega: recupere los campos obligatorios solo durante el período permitido

El almacenamiento separado reduce la exposición directa de la dirección si se roba la base de datos del pedido. Los historiales de pedidos y los ID de proxy aún pueden identificar a las personas cuando se combinan con otra información. Las identificaciones de proxy no garantizan el anonimato.

En la recogida: Definir propósito y retención. No recopile campos innecesarios ni registre cuerpos de solicitud en errores y registros de acceso.
Durante el almacenamiento: Separe el texto cifrado de los permisos de descifrado. Incluya réplicas, cachés y copias analíticas en la gestión de datos.
En uso: Autorizar campos y finalidad. Devuelva solo los datos necesarios y realice un seguimiento de las nuevas copias creadas mediante transferencias a socios.

Los índices de búsqueda, avisos de eliminación a terceros y borrado irreversible de claves de esta sección son ejemplos de diseño. La API actual no ofrece búsqueda, avisos automáticos ni borrado físico inmediato de copias de seguridad. Consulte la guía para el alcance real. Guía de inicio

¿Cómo se pueden buscar datos cifrados?

Los nonces aleatorios producen texto cifrado diferente para la misma dirección de correo electrónico, lo que impide las búsquedas ordinarias de coincidencias exactas. Prefiere ID de proxy o ID de pedido. Si es necesario comparar datos personales, diseñe un índice de búsqueda separado.

Ejemplo de coincidencia exacta: HMAC con clave.

Normalice las direcciones de correo electrónico utilizando reglas definidas y calcule un HMAC con claves de búsqueda específicas de cada campo y organización. Repita para las búsquedas, luego verifique los datos de origen después de la autorización. El valor del índice es para texto cifrado coincidente, no descifrable.

Los hash simples permiten adivinar los correos electrónicos o números de teléfono de los candidatos. HMAC también permite adivinar si le roban la clave. Los valores repetidos y la frecuencia permanecen visibles. Limite las consultas masivas para buscar API.

Las búsquedas de subcadenas, prefijos y rangos pueden exponer información adicional y aumentar los costos de procesamiento. Evalúe la funcionalidad, las fugas y el rendimiento juntos. La rotación de claves de búsqueda también requiere reconstruir índices.

¿Qué significa realmente la eliminación?

Eliminar datos de una pantalla no es suficiente. Bloquee la recuperación y luego aborde los registros de origen, índices, cachés, réplicas y socios. Registre el comportamiento de retención y restauración de copias de seguridad.

Dejar de usar: rechazar nuevas recuperaciones y revocar tokens y autorizaciones.
Eliminar datos activos: eliminar registros de origen, índices y réplicas; invalidar cachés.
Notificar a los socios: solicitar la eliminación y realizar un seguimiento de las acciones completadas y pendientes.
Maneje las copias de seguridad: documente lo que queda hasta que caduque y conserve los registros de eliminación para evitar su reutilización después de la restauración.

Hacer que los datos sean ilegibles mediante la destrucción de claves.

El borrado criptográfico hace que las claves requeridas sean irrecuperables. Esto requiere claves dedicadas y la eliminación de copias de seguridad, claves empaquetadas, cachés y copias de servicios recuperables. La destrucción de una clave compartida también afecta a otros usuarios.

La desactivación de la clave reversible no es un borrado irreversible. No elimina el texto sin formato ya recuperado ni las copias cifradas con otras claves. Realice un seguimiento del bloqueo de acceso, la eliminación de datos activos y la caducidad de la copia de seguridad por separado.

Recupérese de forma segura sin recuperar los datos eliminados.

Restaurar la copia de seguridad de ayer puede recuperar las direcciones eliminadas hoy. Restaure de forma aislada, vuelva a aplicar los registros de eliminación y las revocaciones actuales, luego valide antes de reabrir el acceso. Los registros de eliminación no pueden existir solo en esa misma copia de seguridad anterior.

RPO: ventana de pérdida de datos aceptable: Un objetivo de 15 minutos significa que se pueden perder hasta 15 minutos de actualizaciones recientes. Confirme la replicación real, las copias de seguridad y los resultados de las pruebas.
RTO: hora de restablecer el servicio: Un objetivo de dos horas incluye claves, permisos, reproducción de eliminación y validación, no solo restauración de la base de datos. Estos números son ejemplos, no garantías de servicio.
Comprobaciones de recuperación: Verifique que los datos válidos se descifren, que los datos eliminados no se puedan recuperar, que los tokens antiguos se rechacen y que las fallas de claves dejen de procesarse sin exponer la información.
evidencia de auditoría: Registrar actor, referencia objetivo, tiempo, resultado y versión clave. Evite copiar datos personales o tokens sin procesar en los registros.

Evidencias para evaluar el diseño.

Revise los mapas de ubicación de datos, los permisos de descifrado, las fugas de búsqueda, el estado de eliminación y los resultados de las pruebas de recuperación para evaluar la protección durante el almacenamiento, el uso y la eliminación.

Discutir la integración técnica