Los registros de auditoría de los agentes deben cerrarse ante la presión del disco

Una puerta de enlace de agentes que sigue actuando cuando ya no puede registrar esas acciones de forma duradera ha roto su propio límite de seguridad. La presión sobre el disco no es una simple molestia de observabilidad. Decide si la siguiente solicitud API o el siguiente comando SSH dejarán pruebas que los operadores puedan inspeccionar y verificar.

La regla segura es clara: deniega las nuevas llamadas con credenciales antes de que el escritor de auditoría se quede sin espacio. Envía la alerta antes. Permite que el trabajo que ya cruzó el límite de admisión termine solo si la puerta de enlace aún puede registrar su finalización o su fallo. Cuando fallen las adiciones, conserva el texto cifrado que ya está en el disco y deja de tratar el registro como un archivo cómodo que se puede limpiar más tarde.

El registro de auditoría debe formar parte de la autorización

Una puerta de enlace no puede considerar el registro de auditoría «un esfuerzo razonable» si su objetivo es establecer un límite controlado por una persona alrededor de las acciones de los agentes. En cuanto un agente puede solicitar una petición HTTP con credenciales o un comando SSH, el registro de esa petición forma parte de la decisión de autorización. Si la puerta de enlace ejecuta la acción pero pierde el registro, un operador no puede distinguir después una ejecución legítima de otra que no dejó cuentas.

Aquí los equipos suelen mezclar dos fallos distintos:

• El panel o la vista de actividad no puede actualizarse porque no está disponible un índice derivado.
• El registro de origen cifrado no puede aceptar una adición duradera de un evento.

El primer fallo resulta incómodo. El segundo cambia la respuesta a la pregunta de si la puerta de enlace puede realizar una nueva acción externa. No les asignes la misma gravedad ni la misma ruta de recuperación.

El modelo de Sallyport da una forma útil a esta distinción: sus diarios de sesiones y actividad se proyectan desde un único registro de auditoría cifrado y encadenado mediante hashes, en lugar de ser cada uno una fuente de verdad independiente. Una proyección puede retrasarse o necesitar una reconstrucción. La cadena cifrada, que no puede escribirse, es el registro que debe permanecer intacto.

Esta organización también facilita expresar la regla de admisión. Antes de enviar una acción, la puerta de enlace debe saber que tiene suficiente capacidad de almacenamiento y que el escritor funciona para registrar al menos el intento. Después de enviarla, debe registrar el resultado. Si la acción tiene un efecto irreversible, como cambiar una configuración remota de producción, la puerta de enlace debería registrar un evento de intención duradero antes de enviarla y un evento de resultado después.

No prometas una cronología exacta que la capa de almacenamiento no pueda ofrecer. Promete algo más sólido y útil: cada acción admitida tiene un registro duradero y ordenado de su identidad, su contexto de autorización y su último resultado conocido. Si la puerta de enlace no puede mantener esa promesa, no debe admitir otra acción.

Las alertas y la denegación son estados distintos

Alertar en el mismo instante en que deniegas las llamadas garantiza una mala decisión operativa. El operador se entera cuando el agente ya está bloqueado y debe decidir bajo presión si borra datos, detiene el trabajo o debilita la regla de auditoría. Una política de almacenamiento necesita estados separados y transiciones explícitas.

Usa cuatro estados:

1. Normal: la capacidad libre supera la reserva operativa y una comprobación reciente de durabilidad ha sido correcta.
2. Advertencia: la capacidad ha caído por debajo del umbral de advertencia, pero la puerta de enlace aún conserva toda su reserva. Las nuevas llamadas continúan y los operadores reciben una alerta.
3. Restringido: la capacidad ha caído por debajo de la reserva o el escritor ha detectado un fallo temporal que todavía no ha cruzado el límite de fallo grave. No admitas acciones que puedan crear registros grandes o con muchos eventos. Permite únicamente el trabajo ya admitido y sigue comprobando el escritor.
4. Denegado: la puerta de enlace no puede añadir de forma duradera un evento de auditoría o la capacidad restante no cubre el presupuesto mínimo de registro. Deniega todas las nuevas llamadas con credenciales.

Un porcentaje por sí solo no define ninguno de esos estados. Un 5 % libre en un volumen de 4 TB puede ser suficiente. Un 5 % libre en un volumen pequeño puede desaparecer durante una ejecución de agente, una actualización del sistema o un pico de salida detallada de comandos remotos. Las políticas de almacenamiento fallan cuando toman sus cifras de una plantilla de monitorización en lugar del comportamiento real de escritura de la puerta de enlace.

El umbral de advertencia compra tiempo para el operador. La reserva protege la cadena de pruebas. El estado denegado protege la afirmación de que toda acción admitida queda registrada. Cada elemento cumple una función distinta, por lo que no deberían usar la misma cifra.

Una buena transición de estado también evita los cambios constantes. Entra en Advertencia cuando la capacidad libre cruza por debajo de su umbral. Sal de ese estado solo cuando la capacidad supere un umbral de recuperación más alto y el escritor complete una adición de prueba duradera. Aplica la misma histéresis a Restringido. Sin ella, una ejecución de agente cerca del límite puede alternar entre llamadas permitidas y denegadas por unos pocos bloques del sistema de archivos. Eso confunde y dificulta la investigación.

Una reserva es un presupuesto de registros, no optimismo sobre el espacio libre

Establece la reserva crítica calculando los registros que aún podrían tener que existir después de dejar de admitir trabajo nuevo. El cálculo no necesita una precisión falsa. Necesita datos conservadores que puedas explicar durante un incidente.

Empieza con estas preguntas:

• ¿Cuál es el registro de acción admitida más grande, incluidos el contenido cifrado, los encabezados que conserva tu política, los metadatos del resultado y los campos de la cadena de hashes?
• ¿Cuántas acciones pueden estar en curso cuando la puerta de enlace entra en Restringido?
• ¿Puede una acción producir un registro de finalización, de tiempo de espera o de reintento independiente?
• ¿Qué archivos locales crecen junto al registro de origen, como metadatos de segmentos, índices, archivos temporales o informes de fallos?
• ¿Cuánto espacio necesitan el sistema operativo y la aplicación para informar correctamente de la situación?

Supón que una puerta de enlace permite 12 acciones simultáneas, que cada una puede necesitar un registro de intención y otro de resultado, y que el presupuesto conservador de un registro cifrado es de 128 KiB. Solo los registros de las acciones consumen 3 MiB. Esa cifra no es la reserva. Añade el lote de proyección de diario más grande previsto, la sobrecarga de rotación de archivos, un marcador de fallo y un margen de seguridad importante para el comportamiento de asignación. Después, redondea al alza hasta una cifra fácil de supervisar.

El resultado útil es una política escrita, no una cifra mágica:

umbral de advertencia: 2 GiB libres en el volumen de auditoría
reserva crítica:       512 MiB reservados para registros de finalización y recuperación
presupuesto de admisión: 256 KiB disponibles como mínimo por acción nueva
umbral de recuperación: 3 GiB libres más una adición de prueba duradera

Estos valores son ejemplos, no valores predeterminados para todos los Mac. Un equipo de desarrollador con llamadas API breves puede justificar una reserva menor que un equipo compartido de compilación con agentes autónomos que ejecutan trabajos SSH largos. La política debe reflejar la mayor salida creíble que registra la puerta de enlace, no el tamaño medio de las peticiones durante una semana tranquila.

La documentación actual de APFS de Apple señala algo relacionado que suele pasarse por alto al crear una alerta porcentual: comprueba si está disponible el espacio necesario para una operación concreta, en lugar de intentar obtener un total fiable a partir del espacio libre disponible en una partición. APFS también usa distribución compartida del espacio, clones y archivos dispersos, por lo que el espacio aparente y el espacio utilizable de inmediato no siempre se comportan como en un disco antiguo de particiones fijas.

Para un escritor de auditoría, esto significa que la comprobación de admisión debe preguntar: «¿Puedo permitirme de forma segura este presupuesto de registro ahora?». No debe preguntar: «¿La barra de menús todavía muestra una cantidad distinta de cero como espacio libre?».

Una adición fallida debe cambiar de inmediato el comportamiento de la puerta de enlace

Trata un fallo de adición como una transición de estado, no como una línea en un registro de depuración seguida de otro intento. Un reintento puede tener sentido ante una interrupción temporal. No puede convertirse en permiso para seguir enviando llamadas sin registrar.

Imagina una secuencia de fallo plausible. El volumen de auditoría ha caído por debajo de su reserva porque una herramienta local de desarrollo creó una caché grande. Un agente solicita a la puerta de enlace una acción de despliegue HTTP. La puerta de enlace escribe el evento de intención, envía la petición, recibe una respuesta correcta y luego no puede añadir el evento de finalización porque el sistema de archivos devuelve un error de falta de espacio.

En ese momento la puerta de enlace sabe tres cosas: admitió la acción, el sistema externo puede haber cambiado y falta su registro normal de finalización. La respuesta correcta es conservar el evento de intención duradero, registrar un marcador de fallo si queda algún canal seguro, detener las nuevas llamadas y mostrar al operador el identificador de la acción junto con el fallo de almacenamiento. No debe volver a ejecutar la petición en silencio. Un reintento podría duplicar el efecto remoto.

Considera ahora una secuencia peor. La propia adición de intención falla antes del envío. La puerta de enlace debe denegar la acción. No tiene una base duradera para afirmar que la acción fue solicitada, aprobada o ejecutada. Esto puede frustrar a quien espera una compilación, pero la alternativa es una brecha de auditoría que nadie puede reconstruir con confianza.

La misma regla se aplica a los fallos detectados durante la sincronización. El manual de fsync de Apple indica que fsync mueve los datos y atributos modificados hacia el almacenamiento permanente y que una operación de E/S en cola puede hacer que falle con errores relacionados con la lectura o la escritura. El manual también advierte que una descarga normal no garantiza por sí sola el orden físico del soporte después de una pérdida de alimentación. Por eso el software debe definir su propio límite de durabilidad y no equiparar una adición en memoria con un evento confirmado.

Usa un clasificador de fallos pequeño:

la adición o sincronización funciona       -> la acción puede continuar o terminar normalmente
la adición falla antes del envío           -> denegar la acción
la adición falla después del envío         -> denegar nuevas acciones, conservar la intención, elevar un incidente
la sincronización informa de un fallo de E/S -> denegar nuevas acciones, conservar los archivos, investigar el almacenamiento
la comprobación de espacio queda por debajo del presupuesto -> denegar esta acción nueva antes del envío

No borres segmentos antiguos para que funcione la escritura actual. Eso convierte un incidente de capacidad en destrucción de pruebas.

El escritor necesita un límite de confirmación duradero

Un escritor que se limita a añadir bytes a un archivo abierto no ha resuelto el problema de auditoría. Necesita un límite que indique al resto de la puerta de enlace cuándo un evento pasó a formar parte de la cadena duradera.

Mantén ese límite pequeño y explícito. Un patrón viable usa archivos de segmentos de solo adición, cada evento con el hash del evento anterior y un pequeño manifiesto de segmentos. La codificación exacta puede variar. El orden de las operaciones no debería variar.

1. Serializa el siguiente evento cifrado con el número de secuencia N y el hash anterior H(N-1).
2. Añade el marco completo del evento al segmento activo.
3. Sincroniza el archivo del segmento y comprueba el resultado.
4. Actualiza el manifiesto con la nueva secuencia máxima y el hash del segmento.
5. Sincroniza el manifiesto y comprueba el resultado.
6. Solo ahora marca el evento N como confirmado para el distribuidor.

El manifiesto importa porque la recuperación necesita responder a «¿qué marcos completos de eventos cuentan?». Un marco parcial al final después de un fallo o de un disco lleno no es un evento confirmado solo porque algunos de sus bytes hayan llegado al segmento. La longitud del marco, los datos de autenticación, el número de secuencia y la marca de agua máxima confirmada del manifiesto permiten que la recuperación rechace la ambigüedad en lugar de adivinar.

No resuelvas esto reescribiendo un archivo JSON en el mismo lugar. Parece fácil hasta que el sistema de archivos tiene espacio para el archivo nuevo pero no para el cambio de nombre, o hasta que un fallo deja un índice antiguo junto a un segmento más reciente. Los segmentos de solo adición y un manifiesto pequeño hacen que el comportamiento ante fallos sea más fácil de razonar y de verificar sin conexión.

Aquí importa otra distinción: el cifrado protege el contenido de los eventos, mientras que una cadena de hashes protege la continuidad ordenada. Ninguna de las dos propiedades significa que una adición sea duradera. El escritor debe establecer primero la durabilidad y después el verificador puede comprobar que la secuencia conservada no se ha alterado.

El comando sp audit verify de Sallyport puede verificar sin conexión su cadena de hashes cifrada sobre texto cifrado, sin una clave de bóveda. Esa verificación resulta útil después de un incidente de almacenamiento porque el operador puede comprobar las pruebas conservadas antes de desbloquear la bóveda o reanudar el trabajo de los agentes.

Ejecuta la prueba en un volumen de auditoría desechable

Una prueba de presión de disco debe demostrar el comportamiento en cada transición de estado, no solo que una escritura acaba fallando. Usa una imagen de disco o un volumen de prueba aislado, configura únicamente una instancia de puerta de enlace que no sea de producción para guardar allí sus datos de auditoría y elimínalo después del ejercicio. No llenes el volumen normal de tu Mac. La prueba debe incomodar a un entorno desechable, no poner en riesgo el equipo que contiene tu código fuente y tus credenciales.

En macOS, crea y monta una imagen de disco APFS pequeña para la prueba:

hdiutil create -size 2g -fs APFS -volname AuditDrill /tmp/audit-drill.dmg
hdiutil attach /tmp/audit-drill.dmg
df -h /Volumes/AuditDrill

La ruta exacta de montaje puede cambiar si ya existe un volumen con ese nombre. Confírmala con df antes de modificar la configuración de prueba. El formato esperado de la salida debe identificar un sistema de archivos montado y mostrar una capacidad aproximada de 2 GiB:

Filesystem        Size   Used  Avail Capacity  Mounted on
/dev/diskXsY      2.0G   ...   ...     ...%    /Volumes/AuditDrill

Dirige el almacenamiento de auditoría de la instancia de prueba a esa ruta montada. Genera primero algunas acciones conocidas que funcionen. Anota sus identificadores y ejecuta el verificador de la cadena. Esta línea base importa porque un fallo de verificación posterior podría deberse a la configuración y no a la presión del disco.

Después, consume espacio únicamente dentro de la imagen montada:

dd if=/dev/zero of=/Volumes/AuditDrill/fill.bin bs=1048576

dd se detiene cuando el volumen ya no puede asignar más bloques. Es deliberadamente tosco. No uses un comando para crear un archivo disperso en esta prueba, porque un archivo disperso puede parecer grande sin consumir los bloques que activan la condición que necesitas probar.

Ejecuta la prueba por etapas en lugar de correr directamente hasta dejar el espacio a cero:

1. Llena el volumen hasta activar el umbral de advertencia. Confirma que las nuevas acciones pequeñas todavía funcionan y que la alerta del operador aparece una sola vez.
2. Llénalo hasta activar la reserva crítica. Confirma que la puerta de enlace deniega las nuevas acciones según su presupuesto de admisión.
3. Si el diseño de la prueba lo permite, admite una acción controlada justo antes de entrar en Restringido y observa si su evento final se registra correctamente.
4. Llena el volumen hasta que falle realmente una adición o una sincronización. Confirma que la puerta de enlace entra en Denegado y muestra el motivo del fallo.
5. Detén el proceso, vuelve a montar la imagen si es necesario y verifica la cadena cifrada antes de borrar el archivo de relleno.

El objetivo no es admirar un error ENOSPC. El objetivo es responder si la puerta de enlace falla en el momento correcto, si sus diarios cuentan la verdad después y si el operador tiene pruebas suficientes para actuar sin adivinar.

Prueba las ventanas de tiempo problemáticas, no solo un volumen lleno

Una prueba superficial llena un volumen, observa una denegación, libera espacio y declara el éxito. Eso deja fuera las ventanas de tiempo que crean brechas de auditoría.

Prueba una acción cuyo efecto externo termine rápidamente mientras su registro de finalización de auditoría se retrasa. El destino controlado puede ser un endpoint HTTP de prueba que devuelva un identificador de petición único. Inicia la acción mientras aún queda espacio para el evento de intención y consume después el espacio restante del volumen de prueba antes de que la puerta de enlace confirme el evento de resultado. El resultado esperado no tiene por qué ser un estado limpio de éxito o fallo. Puede que la puerta de enlace tenga que informar de que el estado final de la acción externa necesita conciliación.

Ese es un resultado honesto. La puerta de enlace debe mostrar el registro de intención duradero, el identificador de la petición remota si recibió uno y el fallo de almacenamiento local. Debe denegar las llamadas posteriores. Un operador puede inspeccionar el destino de prueba y decidir si la acción remota tuvo éxito. Lo que no debe hacer es convertir la incertidumbre en una segunda petición.

Prueba también un fallo mientras la puerta de enlace rota un segmento de auditoría. La rotación consume metadatos y puede implicar un archivo nuevo, una actualización del directorio y una actualización del manifiesto. Un diseño que sobrevive a una adición normal pero falla durante la rotación no ha resuelto la presión de almacenamiento.

Prueba también el comportamiento al reiniciar. Después de un fallo de adición, cierra por la fuerza únicamente la instancia de prueba desechable y vuelve a iniciarla con el volumen todavía lleno. Debe permanecer en una condición segura de denegación, en lugar de asumir que un proceso nuevo implica un almacenamiento saludable. Libera una cantidad medida de espacio, vuelve a iniciarla y confirma que verifica la última secuencia confirmada antes de abrir un segmento nuevo.

Por último, inyecta un fallo de permisos o de E/S si tu entorno de pruebas puede hacerlo. El agotamiento de capacidad y un error de E/S requieren la misma respuesta inmediata de admisión cuando bloquean las escrituras de auditoría duraderas, pero la investigación es distinta. Liberar espacio puede curar ENOSPC. No cura un volumen que falla, un error del sistema de archivos ni un dispositivo de almacenamiento interrumpido.

Conserva el texto cifrado antes de intentar reparar nada

Cuando falla una escritura de auditoría, la gente suele buscar una limpieza porque quiere desbloquear al agente. Ese impulso convierte un incidente recuperable en uno discutido. Conserva primero, repara después.

Congela el directorio de auditoría afectado. No compactes segmentos, regeneres el manifiesto, trunques el último archivo, rotes el material criptográfico ni vuelvas a ejecutar una acción solo para que la vista de actividad parezca completa. Si el dispositivo de almacenamiento parece dañado, copia el directorio con un método que informe de los errores de lectura y trabaja después con la copia. El original puede ser la única prueba de qué registros llegaron al almacenamiento.

Tu lista de conservación debe responder a cinco preguntas:

• ¿Qué segmento de auditoría y qué manifiesto estaban activos cuando falló la primera escritura?
• ¿Cuál es la última secuencia que acepta el verificador?
• ¿Qué acciones admitidas tienen un registro de intención sin registro de resultado?
• ¿Qué sistemas externos pueden confirmar esas acciones de forma independiente?
• ¿Algún proceso modificó el directorio de auditoría después del fallo?

El resultado de una verificación de la cadena de hashes es una prueba, no una instrucción de reparación. Si la verificación se detiene en la secuencia 8.412, conserva ese hecho. No trunques automáticamente un marco parcial posterior salvo que tu procedimiento de recuperación documentado lo defina y hayas conservado el artefacto original. Un marco cifrado parcial puede ser normal después de un fallo, pero también puede revelar un error del escritor. Necesitas los bytes originales para distinguir una situación de la otra.

Esta es otra razón para mantener el registro de origen separado del diario visible para el usuario. Un diario puede mostrar filas incompletas hasta que se reanude la proyección. Es aceptable si indica al operador que se está poniendo al día. Reconstruir u ocultar vistas derivadas nunca debe reescribir las pruebas de origen para que una pantalla parezca ordenada.

Las alertas deben indicar qué decisión tomó la puerta de enlace

«Disco casi lleno» es una alerta débil para una puerta de enlace de acciones. Informa al operador de una condición del equipo, pero no de si la actividad de los agentes sigue permitida, si las pruebas de auditoría están en riesgo o qué cambió desde la notificación anterior.

Envía una alerta cuando la puerta de enlace entre en Advertencia, Restringido, Denegado y recuperación verificada. Incluye los campos que permiten actuar a un operador:

estado: denegado
motivo: la adición de auditoría falló con ENOSPC
ruta de auditoría: /configured/audit/path
bytes libres observados: 41,943,040
reserva crítica: 536,870,912
última secuencia confirmada: 8412
acciones admitidas sin resolver: 1
nuevas llamadas con credenciales: denegadas
tratamiento de la acción existente: no se pudo confirmar el registro de finalización
hora del primer fallo: 2026-07-22T14:37:18Z

No pongas secretos, cuerpos de peticiones ni credenciales en esta alerta. La alerta necesita identificadores que permitan relacionarla con las pruebas cifradas, no una segunda copia de datos sensibles repartida por los sistemas de notificación.

Evita generar una página por cada muestra de poco espacio. Genera una página al entrar en Restringido o Denegado y envía un recordatorio solo si la condición persiste o el estado empeora. Una advertencia ruidosa en la transición de Normal a Advertencia puede ser un ticket o una notificación local visible. La transición a Denegado es un incidente operativo porque la puerta de enlace ha detenido deliberadamente las nuevas acciones externas.

La alerta también debe indicar si la puerta de enlace está protegiendo los registros ya admitidos. Ese detalle cambia la respuesta. Si tiene espacio para terminar los registros en curso, los operadores pueden dejar que esas ejecuciones terminen mientras liberan espacio. Si ya falló una adición después del envío, los operadores deben investigar las acciones sin resolver antes de reanudar la automatización.

La recuperación debe demostrar que el escritor vuelve a estar sano

Liberar espacio es necesario, pero no demuestra que el escritor de auditoría pueda volver con seguridad al estado Normal. El procedimiento de recuperación debe hacer que la puerta de enlace se gane esa transición.

Primero, conserva los artefactos del incidente y registra qué liberó el espacio. Borrar una caché de compilación no relacionada es distinto de borrar archivos de auditoría, y el registro del incidente debe indicar cuál de las dos cosas ocurrió. Después, verifica la cadena conservada sin conexión. Si la verificación falla, mantén la puerta de enlace en Denegado e investiga las pruebas antes de permitir nuevas acciones.

A continuación, ejecuta una adición de recuperación limitada. La puerta de enlace debe escribir un evento de recuperación que identifique el estado denegado anterior, añadirlo a un segmento de recuperación nuevo o documentado, sincronizarlo, actualizar su manifiesto y verificar la secuencia resultante. No debe reanudar el trabajo en silencio en mitad del segmento que falló.

Solo después de que esa adición funcione debe la puerta de enlace reconstruir o poner al día sus diarios derivados. El trabajo del diario puede fallar de forma independiente. Si falla, conserva las pruebas de origen e informa de que la vista está incompleta. No niegues que una acción ocurrió solo porque su fila aún no haya aparecido en la vista de actividad.

Después aplica el umbral de recuperación. Si configuraste la Advertencia en 2 GiB, la reserva crítica en 512 MiB y la recuperación en 3 GiB, no reabras las llamadas con 600 MiB solo porque el escritor haya conseguido una adición. El umbral superior evita una recaída inmediata y da tiempo al operador para encontrar la fuente de la presión.

Una prueba de presión de almacenamiento demuestra su valor cuando cambia una decisión concreta: el punto exacto en que tu puerta de enlace deja de autorizar trabajo nuevo. Escríbelo, pruébalo contra un volumen desechable y trata cada adición fallida como una prueba que debe conservarse, no como basura que hay que eliminar.