# ¿Las copias de seguridad de evidencias de auditoría deben incluir credenciales? Un archivo de incidentes debe ayudarte a responder quién hizo qué, cuándo, a través de qué ruta aprobada y si alguien modificó el registro después. No debe entregar a la persona que lo abre un token de API operativo, una clave privada SSH ni la capacidad de crear cualquiera de los dos. Los equipos se equivocan con frecuencia porque el software de copias de seguridad hace que todo parezca igual. Un volcado de base de datos, una exportación de la bóveda y un diario de auditoría pueden ser archivos cifrados en reposo. Sus funciones de seguridad son distintas. Una copia de la bóveda restaura autoridad. Una copia de evidencias conserva la responsabilidad. Si los colocas en el mismo archivo, este hereda la propiedad más peligrosa de la bóveda. La diferencia importa aún más con los agentes de programación autónomos. En una sola ejecución, un agente puede crear muchas acciones externas en poco tiempo: cambios en repositorios, llamadas de despliegue, actualizaciones de tickets, administración de la nube y comandos remotos. Después de un incidente, las personas necesitan un registro duradero de esas acciones. No necesitan un paquete portátil con las credenciales que las hicieron posibles. ## Una copia de evidencias no debe restaurar autoridad Un archivo sin credenciales es un paquete de evidencias que no puede autenticarse como usuario, servicio o máquina después de restaurarse. Su contenido puede ser confidencial, pero ninguno de sus elementos puede provocar por sí solo una acción externa. Esto significa que el paquete puede contener un registro como este: ```text 2026-07-22T02:14:09Z session=ses_8f0d... process_authority=Developer ID Application: Example Engineering LLC channel=http method=POST host=api.internal.example path=/deployments credential_ref=prod-deploy-token authorization=approved result=201 Created entry_hash=2ebc6f... previous_hash=78dd91... ``` No debe contener el token bearer representado por `credential_ref`. Tampoco debe contener una clave privada SSH, una cookie de sesión, un token de actualización OAuth, un código de recuperación, una base de datos de la bóveda descifrada ni una contraseña de exportación almacenada junto al archivo. Si aparece cualquiera de esos elementos, ya no tienes una copia de evidencias pura. A veces se objeta que una copia de la bóveda es necesaria para reconstruir el incidente por completo. Solo es necesaria cuando el objetivo es recuperar la autoridad después de un desastre. Esa es otra operación, con otro modelo de amenazas. Tratarla como evidencia habitual crea un archivo que debe protegerse como el acceso de producción, a menudo durante más tiempo del que la credencial original debería seguir siendo válida. Usa dos clasificaciones explícitas en el inventario de copias: - **Material de recuperación de autoridad**: puede restaurar la capacidad de actuar. Pertenece a procedimientos de recuperación de la bóveda con controles estrictos. - **Material de conservación de evidencias**: puede explicar y verificar acciones completadas. Pertenece a un flujo de archivo diseñado para la conservación y la revisión. No suavices la frontera con etiquetas como «exportación saneada de la bóveda». Una exportación de la bóveda que incluya blobs de secretos cifrados, claves de datos envueltas o los medios para desenvolverlas sigue siendo material de la bóveda. Puede que un revisor no pueda usarla hoy, pero has conservado otro objetivo que podría volverse utilizable después de una intrusión independiente. La prueba práctica es sencilla: restaura el archivo en una máquina limpia sin acceso a tu sistema de credenciales. Si un usuario puede convertir cualquier elemento de ese archivo en una solicitud autenticada activa, corrige el diseño. ## El cifrado y la integridad de las evidencias responden preguntas distintas El cifrado responde a «¿quién puede leer este archivo?». La evidencia de integridad responde a «¿se modificó, reordenó o truncó este registro?». Necesitas ambas respuestas y ninguna sustituye a la otra. Un archivo ZIP protegido con contraseña puede mantener privada una línea de tiempo de un incidente y, aun así, ofrecer muy pocas pruebas de que su contenido permaneció intacto. Un atacante que pueda descifrarlo, editarlo y volver a cifrarlo puede dejarte un archivo ordenado, sin una forma confiable de distinguir el original de la versión reescrita. Una cadena de hashes adopta otro enfoque. Cada evento incluye el resumen del evento anterior y el resumen de su propio contenido canónico. Si cambias una entrada anterior, los hashes posteriores dejan de coincidir. Si eliminas una entrada intermedia, la siguiente ya no apunta al predecesor esperado. El archivo puede demostrar que la secuencia exportada es internamente coherente o mostrar exactamente dónde se rompe la coherencia. Esto no convierte una cadena de hashes en magia. Si un atacante controla al escritor antes de que emita un registro, la cadena no puede demostrar que ocurrió el evento omitido. Si controla todas las copias del registro y puede sustituir la cadena completa, una cadena por sí sola no puede identificar cuál es la auténtica. Sigues necesitando puntos de control protegidos, exportación controlada y almacenamiento independiente. RFC 5848, «Signed Syslog Messages», es útil porque separa afirmaciones que a menudo se mezclan sin cuidado. Describe la autenticación del origen, la integridad de los mensajes, la resistencia a repeticiones, la secuenciación y la detección de mensajes ausentes. También deja claro que un registro autenticado no demuestra que el host de origen fuera honesto. Ese límite es saludable. Los registros son evidencias de lo que un sistema de registro observó y emitió, no una visión sobrenatural de la realidad. Para un archivo de incidentes, escribe la afirmación de integridad que realmente puedes respaldar: - Los bytes del archivo coinciden con el manifiesto creado en el momento de la exportación. - La secuencia del diario está completa hasta un punto de control firmado o conservado externamente. - Si una entrada cambia después de capturarse, la verificación falla. - El archivo no demuestra que nunca ocurriera una acción no registrada. La última frase evita investigaciones defectuosas. Un resultado de auditoría limpio respalda una afirmación sobre el diario. No exculpa a un administrador que usó una ruta de credenciales independiente fuera de la puerta de enlace registrada. ## Mantén los diarios y la recuperación de la bóveda en dominios de protección separados Los archivos separados son un comienzo. Los dominios de protección separados son el requisito real. Grupos de acceso, procedimientos de recuperación, plazos de conservación y reglas de eliminación diferentes impiden que una copia conveniente se convierta en una ruta lateral hacia producción. Una distribución razonable tiene tres almacenes: 1. La bóveda activa contiene las credenciales y el material necesario para usarlas. Su recuperación es poco frecuente, requiere una autorización estricta y queda registrada. 2. El diario activo contiene los registros recientes de actividad y el estado de integridad. Los operadores lo necesitan para investigar y revisar la actividad en curso. 3. El archivo de evidencias contiene segmentos exportados del diario, manifiestos, instrucciones del verificador y puntos de control conservados. Los investigadores pueden acceder a él mediante otra ruta de aprobación, sin recibir autoridad sobre credenciales activas. No uses la misma contraseña de cifrado para la copia de recuperación de la bóveda y la copia de evidencias. No coloques ambas copias en el mismo bucket de la nube porque «el bucket ya tiene cifrado». Tampoco pongas por defecto sus contactos de recuperación en el mismo grupo reducido. Esos atajos eliminan la separación cuando se compromete una sola cuenta de administrador, un rol de copias de seguridad o una integración de almacenamiento. La conservación también debe ser distinta. Las credenciales deben rotarse, caducar o revocarse cuando termina su finalidad operativa. Las evidencias pueden tener que sobrevivir mucho más tiempo porque el incidente se descubre después, un cliente solicita una explicación o una revisión interna dura meses. Cuando un archivo antiguo contiene un secreto antiguo, ese periodo de conservación más largo prolonga silenciosamente la vida útil del secreto. Hay otro fallo que aparece durante la salida de un empleado. Un ingeniero pierde el acceso a la bóveda actual, pero conserva una copia cifrada antigua en una unidad personal de recuperación. Si esa copia contiene credenciales que aún son válidas, el proceso de baja tiene un agujero. Si la unidad solo contiene un archivo de diario sin credenciales, puede seguir guardando evidencias sensibles, pero no puede reactivar una identidad de producción. La separación también facilita la destrucción. Puedes destruir evidencias según un calendario de conservación sin preguntarte si acabas de borrar la única copia de recuperación utilizable. Puedes rotar o retirar credenciales sin ejecutar una purga masiva del archivo. Esas tareas nunca deben estar acopladas. ## Exporta un paquete de verificación, no un informe atractivo Una línea de tiempo en PDF resulta útil para una reunión. Es una evidencia primaria deficiente. Pierde la estructura de los registros, normalmente oculta la representación exacta de los campos que se sometieron a hash y deja al revisor sin forma de comprobar si la secuencia de origen estaba completa. Exporta un paquete con contenido verificable por máquina y un índice legible para las personas. Una estructura concreta podría ser esta: ```text agent-evidence-2026-07-22/ manifest.json entries.ndjson checkpoints.ndjson activity-summary.txt VERIFYING.md hashes.sha256 ``` `entries.ndjson` contiene un objeto de evento canónico por línea. Mantén estables los campos. Si debes redactar el cuerpo de una solicitud, indícalo en la entrada y conserva un resumen del campo protegido original cuando sea seguro hacerlo. No sustituyas silenciosamente un valor por `[REDACTED]` y dejes al revisor adivinando si estaba ausente, suprimido o alterado después. `checkpoints.ndjson` contiene la información que fija los segmentos del diario. Según tu diseño, puede incluir un resumen firmado, un valor raíz almacenado externamente, un recibo de testigo o un registro de una transferencia de archivo completada. Una cadena sin un punto de control conservado solo demuestra que sus enlaces internos coinciden. `manifest.json` debe describir el archivo como objeto, en lugar de depender del nombre del directorio. Incluye el identificador de exportación, el intervalo temporal, los identificadores de secuencia inicial y final, el número de registros, la versión del esquema, la versión de canonicalización, el algoritmo de hash, el identificador de la política de redacción y el valor final esperado de la cadena. Añade la versión del exportador y la identidad del host cuando esa información sea útil para la investigación. El resumen de actividad es deliberadamente secundario. Puede indicar que una ejecución realizó siete llamadas HTTP y dos llamadas SSH, recibió una aprobación de sesión e incluyó un comando fallido. Una persona puede leerlo rápidamente. Las entradas detalladas siguen siendo el registro autorizado. La estructura de un manifiesto puede ser así de pequeña: ```json { "archive_id": "evd_2026_07_22_001", "window_start": "2026-07-22T00:00:00Z", "window_end": "2026-07-22T23:59:59Z", "entry_count": 184, "canonicalization": "journal-json-v1", "hash_algorithm": "SHA-256", "first_sequence": 9012, "last_sequence": 9195, "final_entry_hash": "2ebc6f...", "redaction_policy": "evidence-redaction-v3" } ``` A partir de este paquete se puede regenerar un informe. Lo contrario rara vez es posible. Conserva las evidencias estructuradas y crea los informes cuando hagan falta. ## Las copias fallan cuando las exportaciones se hacen después del incidente La secuencia habitual parece inofensiva hasta que alguien necesita el registro. Un agente realiza un despliegue inusual a la 1:40 de la madrugada. Un responsable detecta el impacto en los clientes más tarde. El equipo empieza a examinar el host, reinicia la aplicación, rota las credenciales y copia los registros que encuentra cerca. Al mediodía, el diario local ya se ha sobrescrito, el estado del proceso original ha desaparecido y el archivo copiado no tiene manifiesto ni punto de control. No es necesario que nadie haya actuado con mala intención. El equipo sigue sin poder establecer un historial defendible. Tiene un extracto incompleto, no un archivo de evidencias. NIST SP 800-92 describe la gestión de registros como algo más que su recopilación. Incluye generar, transmitir, almacenar, acceder a y eliminar los datos de registro. Esa visión más amplia es acertada. Si tu plan termina en «la aplicación escribe registros», has planificado la generación, no la conservación. NIST también advierte que registrar indiscriminadamente puede crear problemas operativos e incluso provocar la pérdida de datos. Registra lo suficiente para reconstruir las acciones del agente, pero no disperses secretos sin procesar, cuerpos de respuesta completos y contenidos arbitrarios de archivos en cada evento. Integra las exportaciones en las operaciones normales antes de que ocurra un incidente. El calendario depende del volumen de acciones y de la pérdida máxima que toleres, pero debe tener un responsable y una prueba. Activa una exportación después de una ejecución del agente de gran impacto, antes de un mantenimiento del sistema que pueda afectar al estado local y con una periodicidad habitual para la actividad ordinaria. Prueba el caso complicado. Empieza con un archivo restaurado en otra máquina. No des acceso a la bóveda a quien haga la prueba. Pídele que responda estas preguntas usando solo el paquete: - ¿Qué proceso del agente inició la acción? - ¿Qué decisión de autorización la permitió o rechazó? - ¿A qué destino y operación apuntaba? - ¿La secuencia del diario se verificó hasta el punto de control archivado? - ¿Qué entradas se redactaron y según qué regla declarada? Si la prueba requiere volver a abrir la aplicación original, localizar a un compañero, recordar una contraseña o copiar un secreto del sistema activo, el archivo está incompleto para su uso en incidentes. ## La redacción debe conservar la forma de la acción Los equipos suelen elegir entre dos extremos defectuosos: volcar cada solicitud y respuesta en el diario o eliminar tanto contenido que el registro ya no pueda explicar el evento. El primer enfoque convierte el diario en otro almacén de secretos. El segundo lo convierte en un elemento decorativo de cumplimiento. Conserva los hechos necesarios para identificar y evaluar la acción. En una llamada HTTP, normalmente son la identidad de la sesión, la autoridad de firma de código o identidad equivalente del proceso, el host de destino, el método, la ruta, la referencia de la credencial, el resultado de la aprobación, la marca de tiempo y una representación adecuada de la solicitud y la respuesta. En SSH, registra el destino, la identidad de la cuenta o la referencia de la credencial, el comando o una representación del comando cuidadosamente diseñada, el resultado de la aprobación, el código de salida y la clasificación de salida pertinente. La expresión «representación adecuada» exige criterio. Una solicitud `POST /deployments` con un identificador de versión y un nombre de entorno puede conservarse en texto claro. Un cuerpo que contenga un token de acceso, datos de clientes o una clave privada no. Puedes almacenar una marca de redacción fija más un resumen del campo original si la comparación posterior es importante. El resumen permite al investigador saber si dos valores protegidos eran idénticos sin revelarlos. Ten cuidado con los identificadores. Un encabezado de autorización es claramente secreto. Un parámetro de consulta de una URL puede ser igual de peligroso. Una línea de comandos puede contener una contraseña, un token de acceso a la nube o una ruta de datos de clientes. Los cuerpos de respuesta suelen contener URL temporales de descarga, datos personales o configuración de servicios. Las herramientas de registro no conocen suficientemente bien la semántica de tu negocio como para decidir por sí solas todas las redacciones. Escribe la regla en el archivo. Por ejemplo: ```text redaction_policy=evidence-redaction-v3 request_body=retained only for allowlisted JSON fields authorization_header=omitted query_parameters=names retained, values digested response_body=classified and omitted unless allowlisted ssh_command=stored after secret argument filtering ``` Esta declaración permite al revisor entender por qué falta información. También proporciona a los ingenieros algo concreto que probar cuando cambie una API. No redactes los resultados de autorización, las identidades de destino ni los detalles de los fallos simplemente porque resulten incómodos. Una solicitud rechazada, un intento fallido de autenticación y un host inesperado suelen ser las partes que explican el incidente. ## Una cadena limpia aún necesita conservación independiente La cadena de hashes evita modificaciones silenciosas dentro de una secuencia conservada. No impide que alguien que controle el sistema de origen elimine toda la secuencia y empiece otra. Un plan de archivo serio da a la cadena un punto de referencia externo. El método más sencillo es exportar puntos de control periódicamente. En un intervalo definido, escribe el resumen final del diario, el número de secuencia y la marca de tiempo en un archivo controlado por separado. Conserva varias copias con autoridad de escritura independiente. Si un atacante modifica después el diario local, también tendrá que modificar cada punto de control conservado sin dejar una discrepancia. Puedes reforzarlo con puntos de control firmados, un proceso de sellado de tiempo confiable o un diseño de almacenamiento de solo adición. La opción correcta depende de tu entorno, pero no saltes directamente a una infraestructura compleja si no puedes ejecutar pruebas de restauración y verificación. Un punto de control modesto y repetido que alguien comprueba de verdad es mejor que un diseño impresionante que nadie ha probado. Mantén el proceso de verificación operativo sin conexión. Aquí resulta útil el diseño de auditoría de Sallyport: su registro cifrado, encadenado por hashes y con escritura ciega puede comprobarse sobre el texto cifrado con `sp audit verify`, sin una clave de la bóveda. Un verificador sin credenciales evita la situación absurda en la que la persona que comprueba si un agente abusó de un secreto tiene que obtener primero acceso a ese secreto. Tu procedimiento de evidencias debe conservar el verificador o una forma documentada de obtener la versión exacta utilizada para el formato del archivo. Registra en el manifiesto un resumen criptográfico del binario del verificador o de la revisión del código fuente. Un revisor futuro no necesita un portátil antiguo, pero sí suficiente información para no verificar silenciosamente datos antiguos con reglas modificadas. El resultado esperado de la verificación debe ser inequívoco: ```text $ sp audit verify evidence/journal.enc verified: 184 entries chain: intact range: sequence 9012 through 9195 checkpoint: matched ``` Cuando la verificación falle, conserva la salida del fallo y deja de tratar el archivo como una secuencia limpia. Un fallo no demuestra automáticamente una acción maliciosa. Puede revelar daños durante la transferencia, un exportador defectuoso, una incompatibilidad de formato o una modificación deliberada. El objetivo es que el archivo haga visible el desacuerdo en lugar de aceptar silenciosamente una historia revisada. ## El acceso a las evidencias debe ser suficiente para investigar y limitado para proteger a las personas Las evidencias son más seguras de compartir que las credenciales, pero no son públicas por defecto. Los registros de auditoría pueden revelar nombres de repositorios, topología de servicios internos, acciones de empleados, identificadores de clientes y errores operativos. Elimina la autoridad del archivo y controla el acceso a las evidencias según la sensibilidad de lo que permanezca. Da a los investigadores acceso de lectura al paquete y al verificador, no acceso de escritura a la ubicación autorizada del archivo. Da a los operadores del sistema un rol de exportación documentado, pero haz visible cada exportación en el mismo registro de auditoría cuando sea posible. Entrega a asesores externos, clientes o evaluadores un paquete derivado y redactado cuando no necesiten los detalles internos sin procesar. Evita un único grupo de «archivo de seguridad» que pueda leer material de recuperación de la bóveda, modificar los ajustes de conservación y descargar evidencias. Ese grupo acumulará acceso porque facilita las emergencias. También hará que una sola cuenta comprometida pueda borrar tanto tu capacidad de recuperar el sistema como tu capacidad de explicar lo ocurrido. Define un registro de custodia del archivo. No necesita teatralidad de sala judicial. Necesita datos básicos: identificador del archivo, creador, hora de exportación, intervalo de origen, clase de ubicación de almacenamiento, concesiones de acceso, eventos de transferencia, resultados de verificación y aprobación de destrucción. Si entregas un paquete a un investigador mediante un sistema para compartir archivos, registra el hash del paquete antes y después de la transferencia. La ventaja aparece cuando el incidente se complica. Un ingeniero puede comprobar si un agente llamó a un endpoint de producción sin recibir el token de producción. Un revisor de seguridad puede verificar la cadena sin acceso mediante Touch ID a la bóveda. Un responsable puede recibir un relato legible de los hechos sin recibir los cuerpos de las solicitudes sin procesar. Cada persona obtiene la menor cantidad de información y autoridad necesaria para su trabajo. ## Haz que el archivo sea aburrido antes de necesitarlo La mejor copia de evidencias es la que tu equipo puede crear y verificar cuando no hay nada urgente. Tiene una estructura de paquete fija, una regla explícita de redacción, un punto de control independiente y una prueba de restauración que no depende de la bóveda activa. Realiza un simulacro con una copia dañada deliberadamente. Cambia un byte de una entrada, elimina un registro intermedio y modifica el número del manifiesto. El verificador debe fallar en cada caso de una forma que un responsable agotado pueda entender. Después, ejecuta la copia limpia mediante el mismo proceso y confirma que el paquete de evidencias responde quién autorizó la acción, qué ocurrió y si la secuencia permaneció intacta. Mantén la recuperación de credenciales en otro lugar. Cuando un incidente te obligue a conservar el historial, el archivo debe facilitar la investigación sin crear silenciosamente otro lugar desde el que se pueda acceder a producción.