Detectar es fácil. Cerrar el ciclo es el problema

Encontrar el problema es la parte fácil

Casi toda la industria de herramientas de red se detiene en el diagnóstico. Le dicen que el equipo del sitio norte no tiene el servidor de tiempo secundario, que la lista de acceso de administración permite un rango que ya no debería, que la versión de sistema operativo quedó atrás. Eso es útil, y es donde termina el producto.

Lo que sigue es un ingeniero abriendo una sesión contra cada equipo, escribiendo los comandos a mano, esperando que no se equivoque, y anotando en alguna parte que ya lo hizo. En una red de veinte equipos es tedioso. En una de doscientos, la lista de hallazgos crece más rápido de lo que se cierra, y el informe de cumplimiento se vuelve un documento que nadie lee porque siempre dice lo mismo.

Un hallazgo que no se puede cerrar desde la misma herramienta que lo encontró es una tarea pendiente, no un hallazgo.

Por qué no basta con «que lo aplique solo»

La reacción natural es pedir que la herramienta corrija automáticamente. Y es exactamente donde hay que tener cuidado, porque un cambio automático mal hecho en la red no genera un ticket: genera una salida a sitio.

Los riesgos concretos son tres, y son distintos entre sí:

• El comando puede ser inválido. La sintaxis correcta depende de la plataforma, de la versión y a veces del modelo. Un comando que funciona en una versión se rechaza en otra, y si el cambio se aplicó a medias el equipo queda en un estado intermedio que nadie declaró.
• El comando puede ser válido y estar mal. Aplicar una lista de acceso de administración que no incluye la dirección desde la que usted se conecta es sintácticamente perfecto y lo deja fuera del equipo.
• El cambio puede ser correcto y llegar en mal momento. Corregir la prioridad del árbol de expansión es lo adecuado, y hacerlo a las once de la mañana de un día hábil provoca una reconvergencia que nadie pidió.

Por eso el ciclo cerrado no significa automático. Significa que cada paso —proponer, revisar, aprobar, aplicar y verificar— ocurre dentro de la misma herramienta, con la persona en el punto donde su criterio aporta algo.

El gemelo digital: comparar antes de tocar

El término se usa para muchas cosas. Aquí significa algo concreto y verificable: una representación de cómo debería estar configurado un equipo según la intención declarada, que se puede comparar contra cómo está configurado de verdad.

De esa comparación sale un diferencial: las líneas que hay que agregar, las que hay que quitar y las que cambian. Y ese diferencial es el artefacto que se revisa antes de que nada toque la red. No es una promesa de lo que la herramienta hará; es el texto exacto que va a enviar.

La diferencia con aprobar un cambio descrito en prosa es enorme. «Corregir la configuración de tiempo del equipo» es una intención. Las tres líneas concretas que se van a enviar, en la sintaxis del fabricante, son algo que un ingeniero puede leer en quince segundos y aprobar o rechazar con fundamento.

Aquí también es donde se cae la mayoría de las herramientas multivendor, y por una razón que ya tratamos en el artículo sobre la fuente de verdad: si el modelo interno es una traducción a una sintaxis común, el diferencial que le muestran no es el que se va a aplicar. Se parece. Y «se parece» no es una base para aprobar un cambio en producción.

Cada fabricante tiene su forma segura de aplicar

Aplicar un cambio no es abrir una sesión y pegar texto. Cada plataforma ofrece una primitiva pensada justamente para que un cambio remoto no lo deje fuera del equipo, y usarla es la diferencia entre una operación controlada y una apuesta.

• Junos tiene confirmación diferida: el cambio se aplica y se revierte solo si nadie lo confirma dentro de un plazo. Si el cambio lo dejó fuera, el equipo vuelve al estado anterior por sí mismo.
• IOS e IOS-XE tienen archivo de configuración y reemplazo, que permite volver a un estado conocido sin reconstruirlo a mano.
• FortiGate se opera por interfaz de programación, donde la respuesta del equipo confirma si el objeto quedó como se pidió, en vez de tener que interpretar la salida de una terminal.

Una herramienta que envía texto por terminal a los tres por igual desperdicia las tres protecciones. Respetar la primitiva de cada fabricante cuesta más trabajo de desarrollo y es la única forma de que un cambio remoto sea reversible.

El paso que casi siempre falta: verificar

Aplicar no es cerrar. El equipo puede aceptar el comando y aun así no quedar como se esperaba: una dependencia que no existía, un objeto referenciado que no estaba declarado, una configuración que se acepta pero no surte efecto hasta reiniciar un proceso.

El ciclo sólo cierra cuando se vuelve a auditar el mismo equipo contra la misma regla y el hallazgo desaparece. Eso convierte «se aplicó el cambio» —que es una afirmación sobre lo que hizo la herramienta— en «el hallazgo cerró», que es una afirmación sobre el estado de la red. Son cosas distintas y sólo la segunda sirve para un informe.

Detectar, proponer, aprobar, aplicar, verificar. Sin el último paso, los otros cuatro son una suposición documentada.

Cómo lo resuelve Oktavia

El Gemelo Digital de Oktavia genera la configuración deseada de un equipo a partir de la intención declarada por alcance y la compara contra la activa. El diferencial se revisa en pantalla, se aprueba, y sólo entonces se aplica con la primitiva que corresponde a ese fabricante. Después, una nueva auditoría sobre las mismas reglas confirma si el hallazgo cerró.

Todo el recorrido deja artefactos descargables —la configuración propuesta, el diferencial, el resultado de la aplicación y la auditoría posterior— de modo que la evidencia para una auditoría interna o regulatoria no se arma después: se produjo mientras se trabajaba.

Lo mismo aplica al alta de servicios nuevos, no sólo a la corrección: un túnel entre dos sitios, la publicación de una red en los protocolos de ruteo, la configuración de asignación dinámica de direcciones. Cada uno con su procedimiento de reversión definido desde antes de aplicarse.

Gemelo digital: del hallazgo al cambio aprobado y verificado.

El alta de un servicio nuevo: Argos crea una loopback desde cero y pasa por el mismo ciclo de revisión y aprobación.