Registros de auditoría de agentes: registros de sesión y de llamadas

Los registros de auditoría de agentes fallan cuando intentan responder dos preguntas distintas con un solo registro. Durante un incidente necesitas saber quién tenía autoridad para actuar y qué acción exacta llegó al mundo exterior. El registro de una ejecución no puede sustituir al registro de una llamada, y una lista de solicitudes no explica por qué ese proceso tenía permiso.

Los equipos suelen conservar solo una de estas perspectivas porque durante una demostración parece suficiente. Después el agente abre un ticket, modifica una configuración de producción o ejecuta un comando SSH, y la investigación se reduce a adivinar marcas de tiempo. Se puede evitar. Conserva un diario de sesiones para la autoridad y el ciclo de vida. Conserva un diario de actividad para cada acción externa intentada. Únelos con un identificador que ni las personas ni los agentes puedan inventar libremente.

Un registro de ejecución responde quién tenía autoridad

Un registro de sesión debe indicar si un proceso concreto del agente tenía permiso para actuar, durante qué periodo y bajo qué decisión humana. Es el registro que consultas cuando alguien pregunta: «¿Qué instancia del agente hizo esto y por qué se lo permitimos?»

Un registro de sesión útil comienza cuando un proceso solicita autoridad por primera vez, no cuando un usuario abre un editor ni cuando aparece un directorio de proyecto. Los nombres de los agentes son pruebas débiles. Dos procesos pueden llamarse igual y un binario malicioso puede adoptar un nombre conocido. Registra la identidad del proceso que el sistema anfitrión pueda proporcionar, su autoridad de firma de código cuando el sistema operativo la ofrezca, el proceso padre cuando sea útil, un ID de sesión generado, las horas de inicio y finalización y el resultado de la autorización.

El registro de sesión también necesita eventos del ciclo de vida. La aprobación es un evento. La revocación es un evento. La salida del proceso es un evento. El bloqueo del almacén de credenciales, si impide la actividad, también merece correlacionarse. Sin estos límites, un investigador no puede saber si una llamada ocurrió dentro de un periodo aprobado o después de un supuesto apagado.

No conviertas el registro de sesión en un diario de cada pensamiento del modelo, línea de terminal y edición de archivo. Eso crea una acumulación de material sensible y aun así puede omitir el límite importante: un proceso de agente recibió autoridad para pedir a una puerta de enlace que realizara acciones externas. Conserva de forma clara las pruebas que establecen ese límite.

Considera este registro de sesión simplificado:

{
  "type": "session.authorized",
  "session_id": "ses_7f4c2",
  "observed_at": "2025-04-18T14:03:11Z",
  "process": {
    "pid": 8124,
    "signing_authority": "Example Development Team",
    "parent_pid": 8090
  },
  "decision": "approved",
  "approved_by": "local_operator"
}

El registro no necesita el nombre de un empleado para ser útil. En una estación de trabajo compartida, local_operator puede ser el nivel honesto de atribución. Fingir que sabes más produce una ficción expresada con seguridad. Si tu entorno puede vincular la aprobación a una persona autenticada, registra ese vínculo y cómo se estableció.

Un registro de sesión nunca debe afirmar que una ejecución completa era segura. La aprobación concede autoridad, pero no aprueba de antemano todos los efectos que un proceso pueda producir. Esta distinción parece quisquillosa hasta que un agente de programación mantiene una sesión abierta durante horas y realiza cientos de llamadas con una sola aprobación.

Un registro de llamadas responde qué llegó al mundo exterior

Un registro de llamada debe describir una operación intentada y su resultado. Es la prueba que necesitas cuando alguien pregunta: «¿El agente envió esta solicitud, a qué destino y con qué resultado?»

Registra los intentos, no solo los éxitos. Una solicitud rechazada puede mostrar que el agente estaba buscando una credencial. Una solicitud fallida puede revelar un host mal escrito, un secreto caducado o un comando inseguro que el equipo remoto rechazó. Una solicitud cancelada puede explicar por qué una sesión parece haberse detenido a mitad de un despliegue. Los registros que solo muestran éxitos cuentan una historia favorable, pero incompleta.

Para una acción HTTP, conserva la identidad del destino, el método HTTP, la ruta o una representación controlada de ella, la referencia de la credencial en lugar de su valor, la hora de la solicitud, la hora de finalización, el resultado de estado, el ID de sesión y un ID de llamada. Para SSH, conserva la identidad del host previsto, el comando o una representación segura, el resultado de la conexión, el estado de salida remoto cuando esté disponible, el ID de sesión y el ID de llamada.

Debes decidir con cuidado qué datos de la solicitud conservar. Registrar por costumbre las cabeceras y cuerpos completos es una fuente de incidentes. Las cabeceras de autorización, cookies, URL firmadas, tokens de acceso, datos privados de clientes y contraseñas suelen estar ahí. Un buen registro conserva el significado de la operación y elimina el material secreto. Por ejemplo, POST /v1/users/123/disable puede bastar para reconstruir un cambio administrativo; copiar todo el cuerpo JSON podría exponer mucho más de lo que la investigación necesita.

Usa la identidad del destino, no solo una cadena de URL sin procesar. https://api.example.test y https://api.example.test:443 pueden representar el mismo destino, mientras que un host parecido puede diferir en un solo carácter. En SSH, registra la identidad del host utilizada para la verificación cuando tu sistema pueda obtenerla. Un nombre de host por sí solo no demuestra que la conexión llegara al equipo esperado.

Este conjunto emparejado muestra la separación:

{
  "type": "call.completed",
  "call_id": "call_b91d",
  "session_id": "ses_7f4c2",
  "observed_at": "2025-04-18T14:09:27Z",
  "channel": "http",
  "operation": "POST",
  "target": "api.example.test/v1/deployments/42/cancel",
  "credential_ref": "deployment-service",
  "authorization": "session_approved",
  "outcome": "completed",
  "response_status": 202
}

El ID de sesión indica de quién procedía la autoridad utilizada por la llamada. El destino y el resultado indican qué ocurrió. Si los mezclas en un único evento impreciso como agent performed task, no habrás respondido bien a ninguna de las dos preguntas.

La aprobación y la ejecución son hechos distintos

Los equipos suelen confundir un evento de aprobación con una prueba de que una solicitud se ejecutó. Son hechos distintos y una pista de auditoría debe conservar ambos.

Un operador puede aprobar un proceso nuevo del agente y después alejarse. El proceso puede no hacer ninguna llamada porque la tarea termina localmente. Puede realizar una solicitud API fallida o cincuenta solicitudes exitosas. El registro de aprobación es el mismo en todos los casos. Solo los registros de llamadas individuales muestran el efecto.

También ocurre la confusión inversa. Alguien ve una solicitud saliente en un registro de red y supone que la envió un agente aprobado. Un registro de red puede demostrar una conexión o un fragmento de solicitud, según dónde se capturara. Normalmente no puede mostrar la decisión de aprobación, la identidad real del proceso ni si una puerta de enlace inyectó una credencial en nombre del agente. No le exijas responder preguntas para las que nunca fue diseñado.

NIST Special Publication 800-92, Guide to Computer Security Log Management, distingue entre la fuente del evento, la infraestructura de registro y el proceso de análisis. Su lección práctica para los sistemas de agentes es sencilla: recoge cada evento en la capa que conoce el hecho. La capa de autorización sabe si una sesión recibió autoridad. La puerta de enlace de acciones sabe qué operación intentó con una credencial protegida. Un cortafuegos conoce el tráfico que observó. Cada registro tiene un alcance probatorio diferente.

Ayuda incluir un estado de autorización preciso en cada llamada. session_approved significa que la sesión tenía una aprobación vigente. per_call_approved significa que un operador aprobó ese uso concreto. denied_locked significa que el almacén de credenciales rechazó el intento mientras estaba bloqueado. denied_user significa que un operador lo rechazó. No son etiquetas decorativas. Indican al investigador si la operación llegó al ejecutor de acciones y si una intervención humana la detuvo.

No etiquetes cada llamada exitosa como «aprobada». Esa palabra oculta la diferencia entre el permiso concedido al inicio de la sesión y el permiso concedido en el momento de uso. Cuando un revisor de incidentes pregunte si alguien aprobó la eliminación, el registro debería responder de un vistazo.

La aprobación por llamada tiene su lugar, pero úsala como control específico. Aplícala a credenciales cuyo uso tenga consecuencias graves o cuando el destino cambie de estado de una forma que el operador deba ver. Si exiges un clic humano para lecturas rutinarias y llamadas de compilación inocuas, las personas aprenderán a aprobar una sucesión borrosa de avisos. La aprobación seguirá existiendo sobre el papel, pero dejará de significar consentimiento informado.

Una cronología de fallos revela lagunas que ocultan los resúmenes

Una única cronología de incidente deja clara la utilidad de las dos perspectivas. Supón que un agente autónomo de programación recibe la tarea de limpiar entornos de vista previa antiguos. El operador aprueba su proceso para la sesión. El agente descubre una credencial antigua de la API de despliegue y pide a la puerta de enlace que haga llamadas con ella.

A las 14:03, el diario de sesiones registra un proceso aprobado y asigna ses_7f4c2. A las 14:07, el diario de actividad registra una solicitud GET que enumera los despliegues. A las 14:09 registra la llamada de cancelación mostrada arriba. A las 14:10, un segundo intento de cancelación recibe una respuesta 403. A las 14:12, el operador revoca la sesión al advertir que el agente había seleccionado el grupo de entornos equivocado.

Ahora imagina que solo conservaste registros de sesión. Podrías decir que un proceso fue aprobado y después revocado. No podrías demostrar si canceló un entorno, varios o ninguno. Tampoco podrías distinguir un segundo intento bloqueado de uno exitoso. Tendrías que preguntar al servicio de despliegue, y su retención o nivel de detalle podría no satisfacer tus necesidades.

Ahora imagina que solo conservaste registros de llamadas. Verías dos solicitudes de cancelación. No podrías demostrar qué proceso local las inició, si un operador había aprobado ese proceso, si la aprobación seguía vigente en ese momento ni si el revisor actuó rápidamente después de la revocación.

La cronología debe conservar el orden sin fingir que la hora del reloj es perfecta. Los equipos pueden tener relojes desincronizados. Los servicios remotos informan de sus propias marcas de tiempo. Escribe una marca de tiempo de la puerta de enlace cuando observes la solicitud y, cuando corresponda, conserva por separado la marca de tiempo del resultado remoto. Usa una secuencia de orden dentro del registro de auditoría si dispones de ella. No declares causalidad solo porque dos eventos comparten un segundo en el reloj.

La pregunta incómoda es si una sesión revocada puede tener llamadas que terminen después. Puede ocurrir, según cuándo llegue la revocación al ejecutor y según si la solicitud ya había salido del equipo. Tus registros deben hacerlo visible. Registra la hora de revocación y después cualquier finalización de llamada, con la hora de inicio y de finalización de la llamada. Un sistema que simplemente elimina una sesión hace imposible este análisis.

Los ID de correlación necesitan una propiedad estricta

Un ID de sesión solo funciona cuando la puerta de enlace lo asigna y lo controla. No permitas que el agente proporcione un identificador de sesión y lo trates como una prueba de seguridad.

Los agentes pueden transportar texto arbitrario entre llamadas de herramientas. Pueden reutilizar un ID antiguo tras reiniciarse, escribirlo mal o afirmar deliberadamente que pertenecen a otra sesión si la interfaz lo permite. La puerta de enlace debe derivar la asociación a partir de la conexión local autenticada o de la relación entre procesos y añadir por sí misma el ID de sesión a cada llamada.

Los ID de llamada necesitan un tratamiento parecido. Genéralos en el límite de acción antes de que la solicitud salga. Si una solicitud HTTP se reintenta, registra si el reintento es un intento nuevo vinculado a la llamada original o parte de la misma llamada con varios intentos de transporte. Cualquiera de los dos modelos puede funcionar. Mezclarlos destruye la precisión de los recuentos durante una interrupción.

Usa un modelo de correlación pequeño y coherente:

• Un ID de sesión agrupa los eventos de autoridad y ciclo de vida de un proceso de agente.
• Un ID de llamada identifica una operación externa solicitada.
• Un ID de intento identifica un intento de transporte cuando los reintentos importan.
• Una referencia de credencial identifica el secreto configurado sin exponer su valor.
• Una referencia de destino identifica el host, servicio o destino del comando.

No hagas que cada identificador tenga que ser comprensible para una persona. Su función es unir los registros de forma fiable. Las etiquetas legibles pueden acompañarlos, pero cambian, pueden coincidir y facilitan la edición casual.

Con agentes simultáneos, la correlación evita un fallo conocido. Un ingeniero ve una solicitud destructiva a las 16:21, encuentra una transcripción de terminal de un agente a las 16:21 y supone que ambas cosas coinciden. Mientras tanto, otro proceso de agente se ejecutaba con la misma cuenta. El ID de sesión del registro de acciones elimina la suposición. Si no existe una relación estable, declara esa limitación en el informe del incidente en lugar de rellenar la laguna con seguridad fingida.

El registro de auditoría debe mostrar los rechazos además del uso

Las acciones rechazadas suelen importar más que las completadas porque revelan lo que el agente intentó hacer antes de que un control lo detuviera. Regístralas con contexto suficiente para explicar la decisión, pero evita que el registro de rechazos se convierta en otra fuente de secretos.

Un almacén de credenciales bloqueado debe rechazar toda acción que lo necesite. El registro de llamada resultante debe indicar que la acción fue rechazada antes de ejecutarse externamente, identificar la sesión y el destino solicitados y señalar la categoría del motivo. No debe contener un token falso, una clave privada parcial ni una cabecera de autorización copiada.

El rechazo por llamada merece el mismo cuidado. Si un operador rechaza un comando SSH, registra la representación del comando, el destino, la hora de la decisión y su resultado. La ausencia de un estado de salida remoto tendrá entonces un significado: el ejecutor nunca inició el comando. Es distinto de un comando que se inició y devolvió un estado distinto de cero.

Sallyport utiliza tres controles fijos: una barrera absoluta del almacén, autorización por sesión de forma predeterminada y aprobación opcional por llamada para una credencial individual. Este modelo acotado facilita la interpretación de la auditoría porque cada registro puede identificar qué decisión detuvo o permitió la acción.

Evita la respuesta de moda de usar un lenguaje de políticas gigante para cada acción de cada agente. Es popular porque promete una automatización completa. En la práctica, un motor de políticas añade un segundo programa que los equipos deben revisar, probar, actualizar y explicar durante un incidente. Si necesitas políticas para la gobernanza de redes o servicios, aplícalas en la capa correspondiente. No finjas que un conjunto de reglas ilegible elimina la necesidad de contar con pruebas claras de sesiones y llamadas.

Un registro debe distinguir estos resultados:

• El agente nunca tuvo una sesión autorizada.
• La sesión tenía autoridad, pero el almacén estaba bloqueado.
• La puerta de enlace solicitó una decisión por llamada y el operador la rechazó.
• La puerta de enlace ejecutó la acción y el destino remoto la rechazó o falló.
• La puerta de enlace ejecutó la acción y recibió un resultado exitoso.

Cada caso requiere un seguimiento distinto. Una solicitud de sesión rechazada puede indicar un proceso no confiable. Un 403 remoto puede señalar un problema de alcance de la credencial. Una llamada exitosa pero no deseada puede requerir revisar la instrucción de la tarea, la decisión de aprobación de la sesión y el uso permitido de la credencial de destino.

Las pruebas contra manipulaciones protegen el registro después del incidente

Los registros de aplicaciones habituales son fáciles de editar, truncar o sustituir después de que alguien obtiene el control del host. Eso no los vuelve inútiles, pero limita lo que pueden demostrar. Un registro de auditoría encadenado mediante hashes hace evidente una modificación posterior cuando un verificador comprueba la cadena frente a los registros que recibió.

La diferencia importa. Una cadena de hashes puede mostrar que una entrada cambió o desapareció del centro de una cadena conservada. No puede demostrar que el sistema registró todos los eventos que deberían haber existido. No puede salvar un host que ya estaba comprometido antes de crear el evento. Tampoco puede decirte si un operador entendió una tarjeta de aprobación. Afirmar algo más sería teatro de seguridad.

RFC 5848, Signed Syslog Messages, aborda un problema relacionado: los mensajes de registro pueden perder integridad y garantías de origen al atravesar distintos sistemas. Su lección también se aplica cuando usas un diario local cifrado en lugar de syslog. Protege los registros cerca del punto donde ocurre el evento, conserva pruebas de orden y verifica en lugar de confiar solo en una interfaz atractiva.

Sallyport proyecta sus diarios Sessions y Activity desde un único registro de auditoría cifrado, encadenado mediante hashes y protegido contra escritura. Su comando sp audit verify verifica la cadena sin conexión sobre el texto cifrado y sin necesitar la clave del almacén. Esto resulta útil cuando el revisor debe validar la integridad de los registros sin recibir los secretos utilizados para las acciones.

Ejecuta la verificación antes de filtrar, exportar o anotar registros para un incidente. Conserva primero las pruebas cifradas originales. Después crea una copia de trabajo para analizarlas. Si la verificación falla, registra el fallo y el artefacto exacto examinado. No continúes en silencio con una exportación depurada, porque la cuestión de integridad ya forma parte del incidente.

Las pruebas contra manipulaciones también cambian la disciplina operativa. Si el equipo sabe que una modificación posterior será visible, dejará de tratar el diario de auditoría como un lugar cómodo para reescribir la historia después de un despliegue fallido. Eso por sí solo no evita los errores. Sí conserva las pruebas necesarias para aprender de ellos.

La retención necesita límites, no una captura indiscriminada

Conserva los registros de sesión y de llamadas durante el tiempo suficiente para investigar descubrimientos tardíos, uso indebido de credenciales y revisiones de acceso. No conserves cada carga útil para siempre solo porque el almacenamiento sea barato. Los registros más peligrosos suelen ser los que nadie ha clasificado.

Empieza por las preguntas de incidente que tu equipo debe poder responder. ¿Cuánto tiempo después de una ejecución del agente podría el responsable de un servicio detectar un cambio no deseado? ¿Cuánto tiempo necesitas para rastrear el uso de una credencial después de la salida de un empleado? ¿Qué normativas o contratos imponen requisitos de retención? Esas respuestas fijan el periodo. No justifican recopilar instrucciones sin procesar, respuestas completas o secretos que no necesitas.

Separa la visibilidad operativa de la conservación forense. Los operadores pueden necesitar una vista actual y concisa de las sesiones activas y las llamadas recientes. Los investigadores pueden necesitar la secuencia inmutable completa, incluidos los rechazos y los detalles temporales. Dar a cada desarrollador acceso sin restricciones a la segunda vista convierte la pista de auditoría en otro conjunto de datos sensibles.

Establece límites de acceso por función, pero no uses el control de acceso como motivo para ocultar información a las personas responsables de los incidentes. El propietario de un servicio puede necesitar saber que una llamada modificó su servicio. No necesita un token portador ni una carga útil de cliente no relacionada para saberlo.

Cuando un registro apunte a contenido sensible almacenado en otro lugar, conserva una referencia controlada y un procedimiento de recuperación. Por ejemplo, guarda un ID de solicitud que el servicio de destino pueda utilizar para localizar una carga útil protegida según sus propias reglas de acceso. Así el diario de acciones sigue siendo útil sin duplicar datos empresariales sensibles en todos los sistemas de auditoría.

La eliminación necesita su propio registro. Si la retención caduca un lote de entradas, registra el evento de retención, el alcance y la autoridad que provocó la eliminación antes de borrar los datos. Sin esto, un verificador posterior no puede distinguir una caducidad autorizada de una ausencia inexplicada. Mantén la política de retención lo bastante clara para que un revisor de incidentes pueda aplicarla sin consultar a quien escribió el sistema original.

Construye la vista del incidente partiendo de la llamada

Durante una investigación activa, empieza por la llamada sospechosa y avanza hacia fuera. Normalmente es la prueba más concreta: un destino, una operación, una hora y un resultado. Usa su ID de sesión para recuperar el registro de autoridad. Después revisa las llamadas cercanas de esa sesión y el evento de revocación o salida.

Sigue esta secuencia:

1. Conserva y verifica los registros de auditoría originales antes de editarlos o exportarlos.
2. Localiza el registro de llamada por destino, ID de llamada, operación o intervalo temporal del incidente.
3. Recupera el registro de sesión vinculado y confirma la identidad del proceso, la hora de aprobación y el estado del ciclo de vida.
4. Revisa todas las llamadas de esa sesión alrededor del evento, incluidos los rechazos y reintentos.
5. Compara la cronología de acciones con los registros del propio servicio de destino y documenta las lagunas en lugar de adivinarlas.

Este método detecta tanto el error evidente como el más silencioso. El error evidente es una llamada que nunca debería haber ocurrido. El silencioso es una sesión que siguió autorizada después de terminar la tarea prevista o un reintento que repitió una acción tras el tiempo de espera de un servicio.

No rotes primero todas las credenciales solo porque parezca una medida contundente. Si el almacén mantuvo las credenciales lejos del agente y el registro muestra una llamada emitida por la puerta de enlace hacia un destino conocido, una rotación general puede causar interrupciones innecesarias. Revoca de inmediato las sesiones activas cuando sea posible que el uso indebido continúe. Después usa los registros de llamadas para decidir qué credencial, destino o alcance de acceso requiere una medida.

Dos perspectivas generan más registros. También eliminan la frase más costosa de un informe de incidente: «No podemos determinar si el agente aprobado realizó realmente este cambio». Haz visible la autoridad en el límite de la sesión y los efectos en el límite de la llamada. Cualquier cosa menor deja al equipo reconstruyendo un evento de seguridad a partir de fragmentos.