Guardia de IA
Deje que la IA investigue caídas y problemas por sí sola, ejecute diagnósticos en sus servidores y aplique las reparaciones que usted permita, con cada paso registrado y cada paso arriesgado en sus manos.
El técnico de guardia es una IA que investiga problemas por sí sola: examina los datos de monitoreo, ejecuta diagnósticos en el servidor, aplica una reparación cuando conoce la causa y usted lo permite, comprueba el resultado y escribe una conclusión. Cada paso queda registrado.
La guardia está desactivada de forma predeterminada. Primero hay que configurar el análisis de IA.
Activarla
Abra IA → Guardia y active Guardia (o use el interruptor de IA → Resumen).
Elija qué puede hacer la IA en los servidores. La opción predeterminada, Solo diagnósticos, le permite investigar pero le deja a usted cada reparación.
Si quiere que ejecute las reparaciones que usted apruebe, registre una llave de acceso y haga que sus servidores confíen en ella.
Los diagnósticos en sandbox y las reparaciones aprobadas requieren el agente 1.1.0 o posterior en el servidor. Los agentes se actualizan solos a la versión del servidor principal; IA → Guardia muestra los servidores donde la IA puede hacer menos.
Cuándo empieza
| Disparador | Cuándo |
|---|---|
| Caída | Se confirma una caída de un servidor o un monitor |
| Patrulla | Cada 60 minutos de forma predeterminada (IA → Configuración → Patrullar cada). Primero hace las comprobaciones el propio programa, y solo despierta a la IA cuando encuentra algo que revisar, así que una patrulla tranquila no cuesta nada. |
| Vulnerabilidad | Aparece una vulnerabilidad urgente. El técnico de guardia comprueba si el software está en ejecución y es accesible, prepara el comando de actualización y luego decide si le envía un correo. |
| Su tarea | Usted le da una tarea |
| Comprobación tras la aprobación | Se ejecutaron las operaciones que usted aprobó, y la IA comprueba los resultados |
Darle una tarea
En IA → Resumen o en IA → Guardia, describa la tarea en el cuadro, por ejemplo "averiguar por qué la tienda va lenta por la noche", elija Todos los servidores o un servidor y haga clic en Iniciar (o presione Ctrl / ⌘ + Enter; Enter empieza una línea nueva). Lo que esté escribiendo se conserva mientras la página se actualiza sola.
Una tarea puede durar más que una investigación automática: hasta 60 comprobaciones y 30 minutos.
El resultado de una tarea se muestra en el panel; nunca se envía por correo. Cuando la IA termina, puede continuar la conversación.
Revisión de riesgos: una tarea como "revisar qué riesgos tiene este servidor" abarca parches, puertos expuestos, SSH, inicios de sesión fallidos, cuentas y sudo, tareas programadas, procesos y conexiones, el servidor web, certificados y el endurecimiento del sistema. Termina con una conclusión de la revisión de riesgos: cada hallazgo por severidad, con la evidencia, la corrección y quién la hace (hecha por la IA, aprobar en el panel o ejecutarla usted mismo).
Qué puede hacer en un servidor
Todo lo que la IA quiere ejecutar lo comprueba el servidor principal, otra vez antes de enviarlo, y otra vez en el servidor el ayudante root. Los niveles, del más seguro al más peligroso:
| Nivel | Ejemplos | Qué pasa |
|---|---|---|
| Solo lectura | Las comprobaciones fijas (estado y registros de servicios, servicios fallidos, errores del sistema, mensajes del kernel, espacio en disco, tamaño de directorios, archivos grandes, memoria, procesos, puertos en escucha, conexiones, prueba de la configuración del servidor web, un archivo de registro, actualizaciones disponibles, abrir una URL, probar un puerto, configuración de SSH, inicios de sesión fallidos, reglas del firewall, cuentas y sudo, tareas programadas, certificados, AppArmor / SELinux, opciones de seguridad del kernel, actualizaciones automáticas, contenedores y puertos, conexiones abiertas, consulta DNS, ping), y comandos simples de solo lectura como ls, cat, grep -r, tail, ps, ss, journalctl o systemctl status | Se ejecuta de inmediato. Los comandos que leen el contenido de archivos se ejecutan como un usuario sin privilegios, así que los archivos que solo root puede leer quedan ocultos. |
| Sandbox | Cualquier otro diagnóstico: tuberías, bucles, awk, sort, find … -exec grep, un script de diagnóstico | Se ejecuta en el sandbox después de que el revisor de seguridad lo aprueba. Cuando el revisor no está seguro, queda pendiente de usted. |
| Bajo riesgo | Iniciar, reiniciar o recargar un servicio normal; limpiar entradas antiguas del journal o la caché de paquetes; rotar registros; vaciar un archivo de registro enorme | Se ejecuta después de que el revisor lo aprueba, o queda pendiente de usted, según la opción elegida. Un servicio se reinicia como máximo 3 veces por hora, y las reparaciones automáticas se limitan a 20 por día. Cada servidor también las limita por sí mismo: la misma reparación 3 veces por hora y 20 en 24 horas (ai_auto_per_day en su agent.conf). |
| Requiere aprobación | Actualizar un paquete, detener o deshabilitar un servicio normal, terminar un proceso | Siempre espera su Aprobar y ejecutar, firmado con su llave de acceso. Luego el agente ejecuta exactamente esa operación, una vez, dentro de una hora. |
| Alto riesgo | Reiniciar el servidor, instalar todas las actualizaciones, editar la configuración, cualquier cosa sobre SSH, la red, el firewall, la VPN, Docker o el propio 3R Monitor, cualquier otro comando que cambie el sistema | El sistema nunca lo ejecuta. Se le muestra para que lo ejecute usted mismo, con el motivo de la IA y la opinión del revisor. |
| Malicioso | rm -rf, mkfs, dd sobre un disco, curl … | sh, bombas fork, shells inversas, leer o buscar contraseñas y claves, vaciar el firewall, detener SSH o el monitoreo | Se rechaza se escriba como se escriba (con sudo, rutas completas, comillas, opciones separadas): nunca se ejecuta, ni siquiera se sugiere. Ninguna aprobación cambia eso. |
Actualizar un paquete actualiza los paquetes que están realmente instalados: las vulnerabilidades nombran el paquete fuente (por ejemplo perl o brotli), mientras que el servidor tiene perl-base o libbrotli1. Primero se actualizan las listas de paquetes, una actualización que no cambia nada cuenta como fallida, y la lista de software se vuelve a leer justo después, así que una vulnerabilidad corregida desaparece en pocos segundos.
El sandbox
Los diagnósticos del nivel Sandbox se ejecutan:
- como un usuario desechable sin privilegios, con un sistema de archivos de solo lectura y sin privilegios;
- durante 120 segundos como máximo, con 256 MB de memoria como máximo;
- con las contraseñas y las claves eliminadas de su salida.
El sandbox solo puede conectarse al propio servidor y a las redes que usted permita para ese servidor en Servidores → Configuración → Redes a las que puede conectarse el sandbox de IA, dentro del límite local sandbox_networks_max en agent.conf (redes privadas de forma predeterminada). El kernel bloquea todo lo demás; donde el kernel no puede filtrar, el sandbox no tiene red en absoluto.
El revisor por sí solo no basta para todo: los scripts solo pueden usar una lista fija de herramientas de solo lectura. Cualquier otra cosa, y leer directorios personales o el correo, requiere la aprobación de un administrador con su llave de acceso.
El sandbox necesita systemd 236 o posterior y D-Bus en el servidor. Sin ellos, solo se ejecutan las comprobaciones fijas.
Qué puede hacer la IA en los servidores
Elíjalo en IA → Configuración → Qué puede hacer la IA en los servidores:
| Opción | Significado |
|---|---|
| Desactivado: nada en los servidores | La IA solo usa los datos de monitoreo |
| Solo diagnósticos (predeterminado) | Registros, estado, disco, procesos, scripts en sandbox… las reparaciones quedan en sus manos |
| Las reparaciones necesitan mi aprobación | Los diagnósticos se ejecutan solos; cada reparación queda pendiente de usted |
| Las reparaciones de bajo riesgo se ejecutan solas | Después de que el revisor las aprueba, con límites por hora y por día. Las actualizaciones, detener servicios y terminar procesos siempre quedan pendientes de usted. |
Elija lo que elija, la IA nunca ejecuta operaciones de alto riesgo. Reparaciones automáticas por día (20 de forma predeterminada) limita las automáticas; por encima de ese número, esperan su aprobación.
Cada servidor lleva además su propia cuenta, para que ni siquiera un servidor principal del que alguien tomara el control pueda ejecutar más: una reparación aprobada solo por el revisor se ejecuta como máximo 3 veces por hora, y como máximo se ejecutan 20 de esas reparaciones en 24 horas (ai_auto_per_day en agent.conf). Por encima de eso, el servidor la rechaza con «Límite en este servidor: …». Las reparaciones que usted mismo aprueba no tienen este límite.
Para excluir un servidor, marque No permitir que la IA ejecute nada en este servidor (ni siquiera diagnósticos de solo lectura) en Servidores → Configuración → Guardia de IA. En el propio servidor, root puede limitar lo que acepta el ayudante, y el agente no puede cambiarlo:
sudo 3rmonitor ai status # qué puede ejecutar la IA del panel en este servidor
sudo 3rmonitor ai off # nada
sudo 3rmonitor ai read # solo diagnósticos de solo lectura y en sandbox
sudo 3rmonitor ai on # también reparaciones aprobadas (el valor predeterminado)Pendiente de usted
Las operaciones que lo necesitan a usted aparecen en Pendiente de usted, en IA → Resumen, en IA → Guardia y en la propia investigación. Cada una muestra qué ejecutaría, por qué, su nivel y la opinión del revisor.
| Estado | Sus opciones |
|---|---|
| Esperando su aprobación | Aprobar y ejecutar: usted confirma con su llave de acceso (huella, rostro o PIN), y el servidor ejecuta exactamente esta operación, una vez, dentro de una hora. Rechazar. |
| Para ejecutar usted | Copiar comando para ejecutarlo usted mismo si está de acuerdo, y luego Ya lo hice. O Ignorar. |
Un bloqueo que hizo la IA se puede quitar con Deshacer.
Cuando una investigación lo necesita a usted, la IA puede enviarle un correo: el resultado, con las reparaciones realizadas, los problemas que requieren su intervención y las operaciones que esperan su aprobación, va en el correo de alertas combinado. Cuenta para los correos por día de la IA, así que revise también Pendiente de usted en el panel.
Investigaciones
IA → Guardia → Investigaciones muestra cada investigación con su disparador, cuántas operaciones se hicieron, están en espera o se rechazaron, y su resultado:
| Resultado | Significado |
|---|---|
| Trabajando… | Sigue en curso. Detener la termina. |
| En espera: aguarda su aprobación | La conclusión está escrita, y hay operaciones que esperan su aprobación |
| Corregido · Mejoró | El problema está resuelto, o mejor |
| Requiere su intervención | Algo que solo usted puede hacer |
| Nada que hacer | No había nada mal, o no se podía hacer nada |
| Fallido · Detenido | La investigación falló o se detuvo |
Abra una para ver primero la conclusión y luego Qué hizo la IA: cada consulta, comando y rechazo, con su salida.
En espera: cuando la IA terminó pero todavía hay operaciones que esperan su aprobación, escribe la conclusión de inmediato. Después de que usted las aprueba y se ejecutan, vuelve a la misma investigación, comprueba los resultados, continúa si hace falta y actualiza la conclusión (la anterior se queda en la línea de tiempo). Las operaciones rechazadas o vencidas solo se marcan debajo de la conclusión.
La IA recuerda las investigaciones anteriores del mismo servidor o problema de los últimos 30 días.
Continuar una tarea
Debajo de la conclusión de una tarea que usted le dio a la IA hay una Conversación. Haga otra pregunta, o dígale a la IA qué hacer a continuación, y haga clic en Enviar (o presione Ctrl / ⌘ + Enter). Responde con todo lo de esa investigación, las comprobaciones que hizo y sus resultados, en lugar de empezar de nuevo:
- puede consultar datos y revisar servidores como en la tarea; las reparaciones pasan por las mismas comprobaciones y aprobaciones;
- la respuesta aparece en la conversación y la conclusión no cambia;
- si escribe mientras la IA todavía trabaja, responde cuando termina lo que está haciendo; como máximo 5 mensajes pueden esperar respuesta.
Puede continuar durante 24 horas después de la última respuesta de la IA; el texto debajo del cuadro indica hasta cuándo. La conversación se cierra antes, con «Esta conversación está cerrada: …», cuando:
| Motivo que se muestra | |
|---|---|
| se detuvo | Usted hizo clic en Detener, o en Detener todas las operaciones de IA. Detener pregunta antes, porque después la conversación ya no se puede continuar. |
| llegó al límite de tiempo, pasos o tokens | La tarea usó todas sus comprobaciones, su tiempo o sus tokens |
| se rechazaron demasiadas operaciones | El revisor o las reglas rechazaron demasiadas operaciones |
| el modelo falló | El modelo devolvió errores |
| la conversación se hizo demasiado larga para el modelo | Demasiado texto para que el modelo lo vuelva a leer |
| han pasado más de 24 horas desde la última respuesta de la IA | |
| el maestro se reinició mientras la IA trabajaba | |
| se hizo antes de que se pudiera continuar la conversación | La tarea es anterior a la 1.1.1 |
Para seguir después de eso, dele a la IA una tarea nueva. Las investigaciones que la IA inició por sí misma (caídas, patrullas, vulnerabilidades) no se pueden continuar. Los pasos, el tiempo y los tokens son limitados; si el modelo falla, se prueba con el modelo predeterminado.
Bloquear IP
El técnico de guardia puede bloquear por sí solo una IP pública únicamente con evidencia en los registros de acceso y la aprobación del revisor: durante 1 hora de forma predeterminada y 7 días como máximo, como máximo 10 por hora y 50 por día, y el bloqueo vence solo. Cualquier rango de direcciones requiere una aprobación con llave de acceso.
Estas nunca se bloquean, ni siquiera con aprobación: las direcciones de la lista de permitidos y las direcciones protegidas, las IP desde las que iniciaron sesión los administradores, sus servidores y el servidor principal. Cada bloqueo registra su evidencia y quién lo aprobó.
Detenerlo todo
Detener todas las operaciones de IA (en IA → Resumen y en IA → Guardia) cambia qué puede hacer la IA a Desactivado, detiene la investigación en curso, cancela las operaciones en cola y en espera y cierra todas las conversaciones. Desactivar Guardia detiene las investigaciones nuevas.
Servidores donde la IA puede hacer menos
IA → Guardia muestra los servidores donde la IA no puede hacerlo todo:
| Se muestra | Por qué | Qué hacer |
|---|---|---|
| Limitado: "Agente x.y.z: actualícelo a 1.1.0 o posterior…" | Un agente anterior solo ejecuta las comprobaciones de solo lectura antiguas y las reparaciones de bajo riesgo | Actualice el servidor principal; los agentes lo siguen automáticamente |
| Limitado: "Este servidor no tiene sandbox…" | No hay systemd 236 o posterior, o no hay D-Bus | Solo se ejecutan las comprobaciones fijas |
| No se ejecuta nada | El agente todavía se ejecuta como root, o su ayudante no está en ejecución | Ejecute sudo 3rmonitor agent secure en el servidor. Consulte Solución de problemas. |
La fila Agente de la pestaña Sistema, en la página de detalles de un servidor, también muestra cómo se ejecuta su agente. Las reparaciones solo se ejecutan en los servidores que confían en la clave de firma del servidor principal, y las que usted aprueba, solo en los que además confían en sus llaves de acceso: consulte Llaves de acceso.
Cómo está protegida
- El agente no se ejecuta como root. Desde la versión 1.1.0 se ejecuta como el usuario sin privilegios
3rmonitor-agent. Las operaciones de IA pasan por un pequeño ayudante root,3rmonitor-helper, que obtiene cada operación directamente del servidor principal, la vuelve a comprobar con las mismas reglas, comprueba la aprobación y su firma, y solo entonces la ejecuta. - Tres comprobaciones: en el servidor principal, otra vez antes de enviar una operación, y otra vez en el servidor por parte del ayudante, que no confía en el nivel que le asignó el servidor principal.
- Límites en el propio servidor: el ayudante cuenta las reparaciones aprobadas solo por el revisor y rechaza más de 3 de la misma reparación por hora, o más de 20 en 24 horas.
- Un revisor: otra IA, con su propio contexto, revisa cada reparación y cada diagnóstico en sandbox: necesidad, efectos secundarios, archivos leídos o modificados, destinos de red, datos que salen del servidor, recursos e intentos de eludir el sandbox o un rechazo. El texto de los registros, las páginas web y la salida de los comandos se trata como datos, nunca como instrucciones. Los rechazos repetidos detienen una investigación.
- Aprobaciones firmadas: su aprobación se firma con su llave de acceso sobre la operación exacta, y el servidor principal firma cada operación, así que ni siquiera el servidor principal puede aprobar, cambiar ni agregar nada por sí solo. Consulte Llaves de acceso.
- Privacidad: los nombres, las IP y los dominios se envían al modelo como códigos.