# ¿Puede la verificación de copias de auditoría cifradas demostrar la recuperación? Una copia de seguridad que no puede restaurarse en un equipo limpio y comprobarse sin secretos del almacén no está preparada para un incidente. Puede seguir siendo una copia de algunos archivos, pero nadie ha demostrado que conservará la evidencia necesaria cuando ya no existan el Mac original, la cuenta de usuario o el estado de la aplicación. Los registros de auditoría cifrados cambian el simulacro de recuperación de una forma útil. Deberías poder verificar su continuidad mientras siguen cifrados. Si el procedimiento necesita un almacén desbloqueado, una estación de trabajo habitual o a un desarrollador que recuerde qué carpeta copiar, tiene dependencias ocultas. Las dependencias ocultas convierten una recuperación rutinaria en una discusión durante una caída del servicio. ## Una restauración correcta y una cadena de auditoría válida responden preguntas distintas Un directorio restaurado responde a una pregunta de almacenamiento: ¿puede esta máquina leer los bytes guardados? Una cadena hash verificada responde a una pregunta sobre evidencia: ¿siguen describiendo esos bytes una secuencia continua de registros de auditoría sin alteraciones? Necesitas ambas respuestas y ninguna sustituye a la otra. Los equipos suelen mezclar tres comprobaciones bajo una sola palabra tranquilizadora: «restauración». Mantenlas diferenciadas en el registro del simulacro. - **Integridad de transporte** pregunta si la copia de recuperación coincide con el artefacto de copia que querías transferir. Un manifiesto SHA-256 independiente puede responder a esto. - **Integridad de la cadena** pregunta si cada registro de auditoría conservado conecta correctamente con el anterior según las reglas de verificación del formato de registro. - **Completitud de la recuperación** pregunta si el conjunto restaurado cubre el período, las sesiones y los registros de llamadas que tu plan de retención establece que debe cubrir. Una suma de comprobación de archivo no puede detectar un trabajo de copia que omitió sistemáticamente el segmento de auditoría de ayer. Confirmará fielmente que recibiste el conjunto incompleto. La verificación de cadena no puede indicar si el trabajo se ejecutó tarde o si una regla de retención eliminó registros que debías conservar. Confirma el historial interno del material que recibe. Esta distinción importa cuando alguien pregunta: «¿Podemos confiar en esto?». La respuesta honesta debe nombrar la afirmación: «Confirmamos que esta copia se transfirió sin cambios, que los registros cifrados se verifican como una cadena continua y que llegan hasta esta marca de tiempo». Eso es mucho más sólido que decir que una copia se restauró correctamente. NIST SP 800-34, Contingency Planning Guide for Federal Information Systems, considera las pruebas y ejercicios de recuperación parte del mantenimiento de una capacidad de contingencia funcional, no documentación que se completa al configurar las copias de seguridad. La lección útil para un equipo pequeño de ingeniería es sencilla: una ejecución de copia demuestra que se ejecutó un trabajo; un ejercicio demuestra que las personas y las herramientas pueden recuperar un resultado definido. Un rastro de auditoría cifrado te da un resultado que puede comprobarse sin abrir antes el almacén de secretos. ## El equipo limpio no debe tener tus comodidades habituales Un equipo de recuperación limpio no tiene relación previa con el entorno que se está probando. Crea una cuenta local nueva, instala solo el verificador y sus requisitos documentados, y usa un directorio de trabajo nuevo. No inicies sesión en sincronización en la nube, no copies un directorio personal, no restaures una caché de paquetes ni conectes una carpeta antigua de datos de la aplicación. Estos detalles parecen quisquillosos hasta que ocultan justo la dependencia que fallará después. Una configuración sincronizada puede aportar una ruta que el procedimiento olvidó documentar. Una credencial recordada puede permitir que una herramienta obtenga algo que debía encontrar en la copia. Un directorio de aplicación copiado puede hacer que la prueba dependa del estado local, en vez del artefacto de recuperación. Deja la recuperación del almacén fuera de este simulacro. No importes un almacén cifrado, no lo desbloquees ni apruebes ninguna acción para intentar que funcione la verificación de auditoría. El verificador debe inspeccionar el texto cifrado y la cadena criptográfica, no repetir acciones externas. Si alguien dice que necesita secretos para comprobar si la copia de auditoría está intacta, detente e identifica qué componente se ha confundido con el verificador de auditoría. Prepara el equipo para un propósito limitado: 1. Instala la versión documentada del verificador de línea de comandos, o la misma familia de versiones usada para producir la copia. 2. Crea un directorio de simulacro vacío en almacenamiento local, con espacio suficiente para la copia cifrada y un pequeño registro de evidencia. 3. Transfiere la copia y su inventario o manifiesto de sumas de comprobación por la ruta de recuperación documentada. 4. Mantén el medio de origen y la copia restaurada en modo de solo lectura durante la verificación, cuando el sistema operativo y el medio lo permitan. Las palabras «misma familia de versiones» merecen atención. Los formatos de auditoría pueden cambiar. Un simulacro debe registrar la versión de la aplicación y la del verificador usadas, y conservar el instalador o artefacto de versión disponible según tu práctica de retención de software. No resuelvas una incompatibilidad de formato instalando lo más reciente que encuentres en un portátil conectado a internet. Puede corregir la compatibilidad en ese momento, pero deja sin definir el procedimiento real de recuperación. ## Comprueba la copia antes de pedirle que hable a la cadena Ejecuta una comprobación a nivel de archivo antes de verificar la cadena. Así separas una transferencia defectuosa de un historial de auditoría estructuralmente defectuoso y ahorras tiempo cuando el problema entero es un cable dañado, una descarga parcial o un directorio equivocado. En un Mac u otro sistema con `shasum`, un inventario generado al crear la copia puede verse así: ``` shasum -a 256 audit-export/* | sort > audit-export.sha256 ``` En el sitio de recuperación, copia tanto la exportación cifrada como `audit-export.sha256` en el directorio del simulacro y ejecuta: ``` shasum -a 256 -c audit-export.sha256 ``` Cada archivo listado debe mostrar `OK`. Un archivo ausente, un nombre que no coincide o una suma de comprobación distinta indican un fallo de transporte o de inventario. Regístralo como tal antes de ejecutar el verificador de auditoría. No regeneres el manifiesto a partir de los archivos recuperados, porque solo estarías dando un recibo nuevo a bytes alterados. Este pequeño artefacto evita un mal hábito sorprendentemente común: una persona operadora ve que falla el verificador, vuelve a copiar los archivos e informa de éxito en el segundo intento sin conservar lo que falló. La segunda copia puede ser la correcta. También puede ocultar un destino de copia defectuoso, una ruta de transferencia intermitente o que se eligió la instantánea equivocada. Conserva la primera copia fallida, el manifiesto y la salida del comando en una ubicación de incidentes con acceso restringido. Si tu sistema de copias ya ofrece versiones inmutables de objetos o sus propias sumas de comprobación, úsalas como un control adicional de transporte. No sustituyen a un manifiesto que viaja con el artefacto de recuperación, porque el simulacro aún debe mostrar qué contenía esta copia restaurada en el momento en que llegó. ## Verifica el texto cifrado sin desbloquear el almacén Cuando pase la comprobación a nivel de archivo, ejecuta el verificador de cadena de auditoría sobre los datos de auditoría copiados. La propiedad relevante es que la verificación funciona sobre texto cifrado y no necesita un secreto del almacén. Con la herramienta de línea de comandos Sallyport, el comando de verificación es: ``` sp audit verify ``` Ejecuta el comando desde el contexto de recuperación documentado para los datos de auditoría copiados, no desde la cuenta de producción. El comando comprueba sin conexión el registro de auditoría cifrado y encadenado por hash. No debe activar una tarjeta de aprobación, solicitar Touch ID, llamar a una API, abrir una conexión SSH ni exigir que desbloquees el almacén. Cualquiera de esos eventos indica que el simulacro ha cruzado a un límite de sistema diferente. No reduzcas el resultado a una captura de pantalla que diga «aprobado». Registra el comando, la versión del verificador, el identificador de exportación de auditoría o la marca de tiempo de la copia, la ruta local usada para la copia, la fecha del simulacro y el nombre de la persona operadora. Este registro permite que otra persona que responda distinga una verificación limpia de un comando ejecutado semanas después sobre el directorio equivocado. Un criterio de aprobación útil tiene tres partes: el manifiesto de sumas de comprobación pasa, el verificador de cadena informa de éxito y el material restaurado alcanza el límite del último registro esperado para esa ejecución de copia. Formula la tercera parte con una marca de tiempo real o un límite de secuencia de tu propio inventario. «Lo bastante reciente» es una opinión; «cubre hasta la copia programada de las 18:00 UTC» es una afirmación comprobable. Sallyport mantiene el registro fuente cifrado con escritura ciega y proyecta desde él un diario Sessions y un diario Activity. Este diseño hace de la verificación de cadena sin conexión la comprobación de evidencia; los diarios legibles por personas son vistas operativas útiles, pero no justifican desbloquear el almacén durante la recuperación. ## Una cadena rota debe conservarse antes de repararla Un fallo de cadena no es una señal para improvisar. Primero conserva la copia exacta que produjo el fallo, incluidos sus metadatos de archivo cuando tu proceso de recuperación pueda retenerlos, el manifiesto de sumas de comprobación, la versión del verificador y la salida completa del comando. Después crea una copia de trabajo independiente si necesitas comparar fuentes. Varias causas pueden producir el mismo síntoma de fallo. Un trabajo de copia puede haber capturado un segmento de registro omitiendo su predecesor. La retención puede haber eliminado un segmento anterior sin conservar los datos de límite que permiten continuar la verificación. Una persona operadora puede haber combinado dos exportaciones de momentos distintos. También son posibles daños en el almacenamiento y modificaciones deliberadas. El verificador puede decirte que no se mantiene la continuidad; la investigación de recuperación determina por qué. Recorre un fallo común antes de enfrentarte a él bajo presión. Un trabajo nocturno copia el archivo de registro cifrado más reciente a un volumen de copia. Omite un pequeño registro complementario porque el trabajo usa un patrón de nombres de archivo mantenido hace meses. A la mañana siguiente, un simple recuento de archivos parece razonable y el registro más reciente parece estar presente. Durante el simulacro, el manifiesto SHA-256 pasa porque se generó a partir de esa exportación ya incompleta. El verificador de cadena falla porque el registro más reciente no puede conectarse con el predecesor omitido. Ese fallo es una buena noticia durante un simulacro. Detectó un error en la definición de la copia mientras los datos originales y la persona que configuró el trabajo siguen disponibles. La solución no consiste en suprimir la comprobación ni en redefinir el éxito según los archivos que se copiaron. Corrige la selección de exportación, conserva suficientes datos de continuidad, crea una copia nueva y vuelve a ejecutar el ejercicio con un equipo limpio. No «repares» una copia fallida en el directorio de evidencia. Puede que necesites recuperar una copia anterior conservada o un segundo destino para restaurar el servicio, pero etiquétalo como una fuente distinta. En una investigación, las personas necesitan saber qué artefacto falló y cuál se verificó después. ## El alcance de la restauración debe escribirse antes de empezar el simulacro Decide qué debe recuperar la copia de auditoría antes de tocar el equipo de recuperación. La respuesta suele incluir un intervalo de tiempo, los registros generados por las sesiones de agente y llamadas externas relevantes, y suficiente procedencia para identificar la versión que los produjo. También puede incluir el inventario de copia de apoyo y el manifiesto de sumas de comprobación independiente. No incluye automáticamente todos los archivos asociados a la aplicación. El almacén contiene credenciales y el rastro de auditoría registra el relato de la puerta de enlace sobre las ejecuciones y acciones individuales de los agentes. Son objetivos de recuperación diferentes, con reglas de acceso distintas. Llevar el almacén al simulacro de auditoría amplía la exposición de secretos sin mejorar el resultado de la cadena. Escribe una breve declaración de alcance que una persona operadora pueda comprobar. Por ejemplo: ``` Objetivo de recuperación: datos de auditoría cifrados de la copia programada con fecha [marca de tiempo de la organización] Límite esperado: la última entrada de auditoría registrada es igual o posterior a [marca de tiempo de la organización] Comprobaciones necesarias: el manifiesto de transferencia pasa; la verificación de cadena sin conexión pasa Excluido de este simulacro: importación del almacén, desbloqueo del almacén, llamadas API activas, acciones SSH Evidencia conservada: identificador de origen, versión del verificador, salida del comando, registro de la persona operadora ``` Los campos entre corchetes son intencionados. Rellénalos a partir del inventario de copias antes del simulacro. No hagas que el ejercicio apruebe eligiendo un límite después de inspeccionar lo que llegó. Aquí también se encuentran la política de retención y la realidad. Si un equipo promete que puede reconstruir una ventana concreta de un incidente, su declaración de alcance debe cubrir esa ventana después de eliminaciones normales, trabajos fallidos y rotación de almacenamiento. Una copia verificada de la semana pasada no cumple un requisito de investigar un evento de ayer. ## El modelo de aprobación debe estar ausente de la verificación La aprobación de acciones y la verificación de auditoría tienen tareas opuestas. La aprobación controla si un proceso de agente activo puede usar una credencial para causar un efecto externo. La verificación pregunta si el texto cifrado de auditoría almacenado aún conserva un historial intacto. Un simulacro de recuperación no debe necesitar ejercer la primera tarea para realizar la segunda. Esta separación detecta un error de diseño sutil pero grave. Algunos equipos crean un script de recuperación que obtiene un token, inicia la pila habitual de la aplicación y después consulta un servicio en línea para decidir si la copia es válida. El script puede funcionar en la oficina y fallar durante una interrupción de red. Peor aún, puede crear actividad nueva mientras quienes investigan intentan establecer qué ocurrió antes de la caída. Mantén el entorno de verificación desconectado de credenciales activas y sistemas externos. Si tu proceso necesita descargar un paquete, obténlo antes del ejercicio formal y registra la versión exacta. Si el verificador intenta acceder a la red, considéralo un defecto del procedimiento. Un artefacto de auditoría debe seguir siendo inspeccionable cuando DNS, los proveedores de identidad y el equipo original no estén disponibles. El mismo principio se aplica a las personas. Quien puede ejecutar el verificador no tiene por qué ser quien esté autorizado a recuperar secretos del almacén. Separar estas funciones reduce el acceso innecesario a secretos y permite que un equipo de incidentes establezca pronto el estado de su evidencia. ## Un registro de simulacro debe hacer que la siguiente persona operadora sea eficaz sin esfuerzo Un simulacro de recuperación ante desastres cumple su función cuando otra persona ingeniera puede repetirlo sin adivinar. Guarda un registro breve de ejecución junto al procedimiento, pero conserva el texto cifrado restaurado y la salida de comandos bajo los controles de acceso apropiados para los datos de auditoría. Registra estos hechos en lenguaje sencillo: - Qué fuente de copia y marca de tiempo seleccionó la persona operadora. - Qué manifiesto, versión de herramienta y cuenta de equipo limpio se usaron. - Si pasaron la comprobación de suma de comprobación, la verificación de cadena y el límite esperado de registros. - Cualquier dependencia que apareciera, incluida una ruta sin documentar, una solicitud de red, un instalador ausente o una petición de permisos. - Qué cambió después del simulacro y quién se encarga de repetir la prueba. Evita calificar un simulacro como exitoso porque el equipo encontró una solución temporal. Una solución temporal puede ser necesaria para restaurar evidencia durante un incidente real, pero revela una carencia en el proceso documentado. Marca la prueba original como fallida hasta que el procedimiento habitual funcione en un equipo nuevo. Ejecuta este ejercicio después de cambios importantes en los scripts de copia, el almacenamiento de auditoría, la retención o la versión de la aplicación que produce registros. Ejecútalo con una frecuencia acorde con la rapidez con la que necesitarías evidencia fiable después de un incidente. El intervalo exacto depende de tus obligaciones y la frecuencia de tus copias, así que escríbelo en vez de tomar un número prestado de otro equipo. El primer simulacro de recuperación debe terminar con una copia de texto cifrado conservada, una cadena verificada, un límite de cobertura declarado y una lista de defectos que realmente puedas corregir. Si termina con un almacén desbloqueado y un suspiro de alivio, repítelo.