# Revisión semanal de seguridad de agentes: una rutina práctica de 35 minutos Una **revisión semanal de seguridad de agentes** debería durar menos de una hora, producir pocas decisiones y dejar pruebas que alguien pueda consultar más adelante. Si se convierte en una búsqueda entre miles de entradas sin una pregunta clara, el diseño ya ha fallado. He visto a equipos cometer el mismo error con el trabajo automatizado: recopilan registros de actividad porque saben que deberían hacerlo y solo los abren después de una sorpresa incómoda. Para entonces, el contexto útil se ha enfriado. La persona que inició la ejecución ya está con otra tarea, la credencial temporal ha desaparecido y nadie puede decir si aquel comando extraño era una reparación legítima o la primera señal de un límite de permisos mal definido. Una revisión semanal resuelve un problema más concreto. Detecta los cambios graduales en los accesos mientras las personas y las tareas todavía se pueden identificar. También obliga a distinguir algo que se confunde con demasiada frecuencia: que un agente tuviera permiso para actuar no demuestra que sus acciones tuvieran sentido. ## Una revisión semanal detecta los cambios antes de que se vuelvan normales La revisión semanal funciona porque el acceso de los agentes tiende a cambiar en pequeños incrementos fáciles de olvidar. Alguien añade un token para desbloquear una prueba. Una tarea de programación se amplía hasta convertirse en un cambio de despliegue. Un agente reintenta una llamada a una API hasta que funciona una ruta alternativa. Ninguno de estos eventos exige necesariamente una respuesta ante incidentes. Juntos, a lo largo de varias semanas, pueden crear un patrón de acceso que nadie aprobó de forma deliberada. Revisar cada evento en tiempo real parece más seguro, pero la mayoría de los equipos no puede mantener la atención que requiere. Las personas revisoras empiezan a aprobar o descartar registros por simple patrón. Dejan de preguntarse por qué un agente que editaba documentación se conectó a un host de producción. Eso es fatiga de aprobación con una insignia de seguridad. Esperar a una revisión trimestral falla por el motivo contrario. Un trimestre contiene demasiadas ejecuciones, demasiados repositorios modificados y demasiados recuerdos que se han desvanecido. Al final cuentas eventos en lugar de entenderlos. Fija una ventana semanal y revisa los siete días anteriores siempre a la misma hora. Elige un momento en el que la persona revisora pueda contactar con quienes ejecutaron trabajos inusuales. A algunos equipos les funciona el viernes por la tarde; a otros, el lunes por la mañana, sobre todo si la automatización del fin de semana necesita atención. La elección del día importa menos que mantenerla estable. La revisión debería responder a cinco preguntas: - ¿Qué procesos de agente nuevos recibieron autoridad? - ¿Qué acciones se desviaron de la tarea o del destino habitual? - ¿Qué fallos indican una integración rota o un comportamiento de sondeo? - ¿Qué sesiones revocó una persona y la revocación detuvo realmente el uso? - ¿Qué credenciales necesitan una decisión de su propietario antes de volver a utilizarse? No añadas una sexta pregunta solo porque un panel pueda mostrarla. Una rutina semanal sobrevive cuando tiene un objetivo concreto. Muere cuando se convierte en una reunión genérica de seguridad con registros en una pantalla. NIST SP 800-92, *Guide to Computer Security Log Management*, plantea algo que sigue siendo útil aquí: las organizaciones necesitan procesos definidos para analizar los registros, no solo un lugar donde almacenarlos. Los registros de los agentes hacen que la idea sea aún más clara, porque un agente puede actuar con rapidez y repetidamente. El almacenamiento te da pruebas. Una rutina les da a esas pruebas la oportunidad de cambiar una decisión. ## Empieza por las sesiones nuevas, no por las llamadas individuales Empieza revisando las sesiones nuevas porque una sesión es la unidad en la que comienza la autoridad. Necesitas saber qué proceso obtuvo el permiso, qué identidad presentó, cuándo comenzó la ejecución y si tenía un propósito razonable. Una revisión de sesiones no es un ejercicio de inventario. No leas una lista, reconozcas el nombre de un desarrollador conocido y sigas adelante. La identidad firmada de un proceso te ofrece información útil sobre su origen, pero no te dice que se iniciara para una tarea sensata. Trata la identidad del proceso como una prueba de origen, no como una prueba de intención. Para cada sesión nueva, responde a estas preguntas en una nota de revisión: 1. ¿Quién inició o es responsable de la ejecución? 2. ¿Qué repositorio, incidencia, tarea de mantenimiento o investigación la justificaba? 3. ¿Qué clases de credenciales podía utilizar la ejecución? 4. ¿Terminó la sesión cuando terminó la tarea? 5. ¿Apareció otra sesión que repite el mismo trabajo con una identidad diferente? La última pregunta detecta un fallo que los equipos suelen pasar por alto. Una persona ve que una herramienta falla con una cuenta restringida, la vuelve a ejecutar a través de otro proceso de agente y obtiene el resultado. El registro de actividad puede mostrar dos sesiones normales. El significado de seguridad es diferente: el primer límite funcionó, mientras que la segunda ejecución pudo eludir el motivo de ese límite. Marca una sesión para seguimiento si no tiene un propietario reconocible, una referencia de tarea, una duración inusual o una autoridad relacionada con algo distinto de su trabajo declarado. «Duración inusual» no significa que toda ejecución larga sea sospechosa. Las refactorizaciones grandes y las suites de pruebas lentas pueden durar mucho. Una sesión que sigue activa mucho después de que haya desaparecido su contexto humano merece atención, porque es fácil olvidar una autoridad obsoleta. Mantén una lista de permitidos pequeña para las automatizaciones recurrentes, organizada por propósito y no por una etiqueta vaga como «confiable». Por ejemplo, una actualización programada de dependencias puede contactar legítimamente con un registro de paquetes y abrir solicitudes de cambios. Esa descripción le ofrece a la persona revisora algo que puede comprobar. «Bot de programación confiable» no le ofrece nada. ## Un comando inusual necesita contexto antes que culpables Un comando SSH o una solicitud HTTP inusual son pruebas que deben investigarse, no un veredicto. Las personas revisoras se equivocan en ambas direcciones. Algunas descartan los comandos extraños porque el agente tenía autorización. Otras tratan cualquier comando desconocido como hostil. Ambas reacciones hacen que el registro sea menos útil. Construye el contexto esperado a partir de la tarea. Una solicitud para consultar el estado de un despliegue de staging puede encajar en una investigación de una versión. La misma solicitud durante una tarea para ajustar un README no encaja sin una explicación. Un comando que archiva resultados de compilación puede ser normal. Un comando que archiva un directorio personal, lee el historial del shell o cambia archivos de inicio remotos requiere una mirada más atenta. Para la actividad SSH, compara el comando con cuatro límites: - El host que la tarea debería tocar. - La cuenta y el directorio que la tarea debería necesitar. - El tipo de cambio que la tarea permite. - La consecuencia esperada si el comando tiene éxito. El cuarto límite importa. `git status` en un host de compilación tiene pocas consecuencias. Un comando que edita la definición de un servicio, cambia la propiedad de archivos o crea una tarea programada modifica el comportamiento futuro. Esas llamadas deberían tener una referencia de tarea concreta y una persona responsable. Los registros HTTP necesitan el mismo tratamiento, aunque las pistas sean distintas. Observa el destino, el método de solicitud, la ruta, la clase de respuesta y el volumen de solicitudes. Un `GET` nuevo contra un servicio esperado puede ser rutinario. Una ráfaga de respuestas de autorización fallida, intentos contra rutas administrativas o una solicitud de escritura a un servicio que no está relacionado con la tarea requieren una explicación. No crees una lista enorme de cadenas prohibidas y la llames revisión. Los agentes pueden llamar a herramientas legítimas en contextos inadecuados, y un comando inocente puede parecer alarmante sin sus argumentos. La persona revisora necesita suficientes pruebas cercanas para saber qué intentaba hacer el agente. Una observación útil se redacta así: «La sesión S-184 ejecutó una tarea de mantenimiento de un repositorio. Usó SSH en el host de despliegue y cambió la configuración de un servicio. El registro de la tarea no incluía trabajo de despliegue. El propietario de la sesión confirmó que había seleccionado el comando equivocado por accidente. Revocamos la sesión y restauramos la configuración anterior». Esto ofrece a la siguiente persona revisora los hechos, una explicación y una acción completada. Una observación débil se limita a decir: «Se observó un comando sospechoso». Esa frase crea ansiedad y deja que la siguiente persona revisora reconstruya todo el evento. ## Las llamadas fallidas muestran tanto fallos como pruebas de límites Las llamadas fallidas merecen una revisión propia porque transmiten una señal diferente de la de las acciones correctas. Una escritura correcta puede cambiar un sistema. Un fallo puede revelar que un agente intentó llegar a algo que nunca debería haber considerado. Primero separa los fallos normales de integración de las repeticiones sospechosas. Un token caducado, una ruta de API modificada, un tiempo de espera de red o un límite de solicitudes del proveedor producen fallos durante el trabajo normal. La solución puede ser operativa y no estar relacionada con la seguridad. Registra la tendencia de los fallos, identifica a la persona responsable y corrígela antes de que el agente aprenda a esquivar una ruta rota. Después busca patrones que cambien la interpretación: - La misma llamada rechazada se repite muchas veces sin una espera progresiva útil ni un cambio de tarea. - El agente prueba rutas cercanas después de un rechazo de autorización. - Una ejecución cambia de destino después de una denegación en lugar de informar de ella. - Una llamada fallida apunta a un host, servicio o cuenta fuera de los límites de la tarea. - Un fallo aparece justo antes de una acción correcta realizada con una credencial más amplia. Ese último patrón es donde se esconden los diseños de credenciales débiles. Supón que un agente intenta actualizar un despliegue con un token limitado y recibe un error de autorización. Después usa un token general de operaciones y tiene éxito. Los registros pueden mostrar una tarea «recuperada». La revisión debería llamarlo un fallo de alcance. El token limitado rechazó correctamente la solicitud; el token amplio ocultó un desajuste entre la tarea y el acceso permitido. No les digas a los equipos que roten una credencial cada vez que una solicitud a una API devuelva 401 o 403. Ese consejo es popular porque parece decisivo. También es un desperdicio. La rotación no corrige la falta de permisos, un endpoint incorrecto ni la selección repetida de una acción equivocada por parte del agente. Puede dificultar la siguiente revisión al sustituir el rastro de pruebas por una credencial nueva con los mismos permisos inadecuados. En su lugar, clasifica una llamada fallida en uno de cuatro resultados: fallo operativo esperado, defecto de configuración, incumplimiento de los límites de la tarea o posible uso indebido de una credencial. La persona revisora debería explicar por qué eligió la categoría. Si las pruebas no permiten sostener ninguna categoría, pregunta al propietario de la sesión mientras la ejecución aún está reciente. ## La revocación debe cerrar la ruta que provocó la preocupación Una sesión revocada debería impedir que un proceso activo utilice la autoridad que se le concedió, pero no repara automáticamente todos los riesgos relacionados. La revisión semanal debe comprobar el propio evento de revocación y las rutas de acceso cercanas. Para cada sesión revocada, registra el motivo. Una persona puede revocar porque la tarea terminó, porque una aprobación fue accidental, porque la identidad del proceso parecía incorrecta o porque la ejecución se comportó de forma inesperada. Cada motivo lleva a reparaciones diferentes. Una revocación normal al terminar la tarea quizá no requiera ninguna acción adicional. Una identidad de proceso inesperada puede exigir investigar la estación de trabajo y la ruta de inicio. Después comprueba la actividad posterior a la revocación. Toda llamada posterior necesita una explicación. Puede deberse a una confusión con las marcas de tiempo, a un proceso autorizado de forma independiente o a un defecto en la manera en que la persona revisora vinculó los registros. No supongas lo peor, pero tampoco lo descartes sin más. El objetivo de la revocación es hacer observable el límite de autoridad. Comprueba también la autoridad paralela. Un agente puede perder una sesión y seguir actuando mediante otro proceso activo, una credencial diferente, una conexión SSH abierta o una cuenta de automatización independiente. La revisión no necesita demostrar que no existe ninguna ruta alternativa en toda la empresa. Debe determinar si la misma tarea podía continuar por una ruta evidente que se dejó abierta. Escribe el registro de revocación en un lenguaje sencillo: ```text Review date: 2025-03-07 Session: [session reference] Reason: SSH command exceeded the approved maintenance task Action: session revoked Post-revocation calls: none observed Related credential: reviewed, no rotation required Owner follow-up: update maintenance run instructions ``` Usa la fecha y las referencias reales. La plantilla importa porque obliga a la persona revisora a indicar si comprobó qué ocurrió después de la revocación. «Revocada» por sí sola describe una acción, no el resultado. Evita convertir cada revocación en un asunto disciplinario. Si los ingenieros esperan un castigo por detener una ejecución, dudarán hasta poder demostrar la intención. La revocación existe para detener rápidamente una acción incierta. La revisión posterior decide si la causa fue una instrucción incorrecta, una aprobación equivocada, un problema de diseño de credenciales o una conducta indebida. ## La rotación empieza por la propiedad y el alcance Las credenciales que deben rotarse deberían aparecer en la revisión semanal como decisiones pendientes de un propietario, no como una lista de pánico. Un token tiene una fecha de rotación, un propietario del sistema, un propósito declarado y un alcance. Si falta alguno de esos elementos, la credencial ya es más difícil de gestionar de lo necesario. Crea una pequeña cola de rotación a partir de las credenciales utilizadas durante el periodo revisado. Para cada una, registra el propietario, el servicio, el uso previsto, la próxima fecha de rotación y si la actividad de la semana todavía coincide con ese propósito. No necesitas una base de datos elaborada para empezar. Un registro duradero con propietarios identificados vale más que un inventario impresionante que nadie actualiza. Da prioridad a la rotación cuando se cumpla alguna de estas condiciones: - La credencial ha superado la fecha de rotación requerida. - El propietario no puede explicar un uso reciente. - La credencial tiene más permisos de los que necesita la tarea. - La credencial se utilizó después de un problema de acceso o de un evento con un proceso desconocido. - El equipo no puede identificar la cuenta de servicio o la persona responsable. Rotar sin un plan de cambio provoca interrupciones evitables. Antes de sustituir una credencial, identifica las ejecuciones de agentes, scripts e integraciones que la utilizan. Emite la sustituta con el alcance mínimo que necesita la tarea actual. Prueba la acción prevista. Pasa a ella los consumidores conocidos. Después retira la credencial anterior y verifica que ninguna actividad nueva la utilice. No tomes «no la hemos visto últimamente» como prueba de que una credencial no se usa. Algunas tareas de mantenimiento se ejecutan mensualmente o solo durante un incidente. Comprueba el propietario y el propósito documentado antes de eliminarla. Si no existe ninguno, desactívala en una ventana controlada y observa el fallo resultante. A menudo es la respuesta honesta más rápida. Conviene conservar otra distinción: la rotación reduce la vida útil de un secreto, mientras que el alcance limita lo que ese secreto puede hacer. Los equipos suelen usar rotaciones frecuentes para compensar permisos demasiado amplios. No sirve de compensación. Una credencial recién emitida con acceso excesivo sigue teniendo acceso excesivo. ## Verifica las pruebas antes de interpretarlas Una conclusión semanal solo es tan fiable como el registro que la respalda. Las capturas de pantalla exportadas y las filas copiadas manualmente resultan cómodas, pero son pruebas débiles si alguien necesita determinar si se editaron después. Sallyport registra las ejecuciones de los agentes y las llamadas individuales en un único registro de auditoría cifrado y encadenado mediante hashes, mientras las muestra en registros separados de sesiones y actividades. Esa separación es útil porque permite pasar de una aprobación de proceso a las llamadas concretas realizadas durante esa ejecución sin confundir ambos registros. Ejecuta la comprobación de integridad sin conexión disponible antes de comenzar una revisión formal o cuando conserves pruebas después de un evento preocupante: ```sh sp audit verify ``` El comando verifica la cadena sobre el texto cifrado y no necesita la clave del almacén. Una verificación correcta indica que la cadena está intacta según los hashes registrados. No demuestra que una persona autorizada haya aprobado algo sensato, que el destino fuera apropiado o que el alcance de la credencial fuera razonable. La integridad y el criterio son tareas distintas. Si la verificación informa de un problema, deja de tratar la exportación afectada como una prueba definitiva. Conserva los archivos y registra el resultado exacto del comando. Después investiga el estado del almacenamiento y de la aplicación. No «limpies» los registros para que el informe parezca normal. Antes de extraer conclusiones del registro, necesitas saber si el problema se debe a corrupción, a una copia incompleta o a una interferencia. Para las revisiones semanales habituales, conserva el resultado de la verificación junto a la nota de revisión cuando tu equipo necesite un rastro defendible. Para experimentos locales de bajo riesgo, puedes elegir una práctica más ligera. La decisión debe ser explícita. Lo que quieres evitar es saltarte la verificación en silencio justo durante la semana que contiene una observación grave. ## La revisión necesita un ritmo operativo fijo de 35 minutos Una revisión breve funciona cuando reservas tiempo para tomar decisiones, no cuando prometes «mirar los registros» después de terminar el resto del trabajo. La siguiente rutina basta para un equipo con un número manejable de ejecuciones de agentes. Aumenta el tiempo solo cuando el volumen o el riesgo lo exijan de verdad. 1. Dedica cinco minutos a verificar el registro de auditoría y establecer el intervalo de fechas. Abre la nota de la revisión anterior para que los asuntos pendientes estén visibles. 2. Dedica diez minutos a las sesiones nuevas. Relaciona cada proceso desconocido o ejecución inusualmente larga con un propietario y una tarea. 3. Dedica diez minutos a las acciones correctas inusuales y a las llamadas fallidas. Reúne el contexto cercano antes de clasificar cualquier evento. 4. Dedica cinco minutos a las sesiones revocadas. Comprueba el motivo, la actividad posterior a la revocación y la autoridad paralela evidente. 5. Dedica cinco minutos a la rotación de credenciales. Asigna un propietario y una fecha límite a cada elemento que requiera acción. Limita el resultado a un único registro de revisión con tres encabezados: observaciones, decisiones y responsables pendientes. Una observación es un hecho observado. Una decisión indica qué harás. Un responsable pendiente identifica a la persona que debe terminar algo. Mezclar esas categorías produce notas llenas de verbos vagos como «supervisar» y «revisar». Este formato breve funciona bien: ```text Period: [start time] to [end time] Reviewer: [name] Audit verification: pass or follow-up required Findings - [record reference] [observed event and context] Decisions - [action taken and reason] Open owners - [person] will [specific action] by [date] ``` Una revisión semanal sin observaciones puede seguir siendo un buen trabajo, pero escribe qué comprobaste. «Sin problemas» no indica si examinaste el origen de las sesiones, las revocaciones, los fallos o la rotación. Unas pocas líneas concretas ofrecen una referencia a la persona revisora de la semana siguiente. No supedites la revisión a una asistencia perfecta. Una sola persona informada puede completar la revisión de las pruebas y asignar después las preguntas a los propietarios. Esperar a que haya una sala llena de gente es la forma en que una rutina de siete días se convierte en un vacío de seis semanas. ## El registro debería cambiar las decisiones de acceso La revisión ha fracasado si solo crea un informe. Cada observación recurrente debería cambiar una de cuatro cosas: las instrucciones de la tarea, el límite de aprobación, el alcance de la credencial o la propia automatización. Las llamadas fallidas repetidas a un endpoint esperado pueden requerir reparar la integración. Un agente que sigue seleccionando trabajo de despliegue durante una revisión de código puede necesitar instrucciones de tarea más limitadas y ninguna credencial de despliegue. Una sesión desconocida que aparece repetidamente puede exigir cambios en la forma en que los desarrolladores inician el agente. El uso repetido de una credencial amplia puede justificar dividirla por propósito. Sallyport puede exigir aprobación para un proceso de agente nuevo y también para cada uso de una credencial seleccionada. Usa el segundo control en las acciones en las que una persona debería examinar cada intento, en lugar de tratar de expresar ese criterio mediante un conjunto interminable de reglas. No respondas añadiendo aprobaciones en todas partes. Si una persona revisora ve la misma llamada inofensiva cada semana y no puede distinguirla de una llamada arriesgada, el diseño de aprobación es deficiente. Pasa el trabajo recurrente de bajo riesgo a una credencial limitada y conserva la aprobación por uso para las acciones con consecuencias que requieren una decisión humana. Mantén una lista breve de las observaciones recurrentes y su estado de reparación. Cuando aparezca la misma categoría en tres revisiones consecutivas, deja de tratarla como una observación aislada. Alguien debe cambiar el diseño operativo. El registro ya te ha dicho que el límite actual no coincide con el trabajo. Una primera revisión puede resultar un poco incómoda porque deja al descubierto referencias de tareas ausentes, credenciales sin nombre y responsabilidades poco claras. Esa incomodidad es útil. Anota las preguntas sin respuesta, asigna responsables y repite la misma rutina la semana siguiente. El objetivo no es tener un registro impecable. Es contar con un entorno de agentes en el que una persona todavía pueda explicar quién actuó, por qué lo hizo, qué ocurrió y qué accesos permanecen.