Desde 2004: Sin concesiones

Gestión fuera de banda en cada máquina

Cada servidor que operamos es un servidor enterprise de verdad con un controlador lights-out de verdad: iDRAC Enterprise con licencia Datacenter en Dell, iLO Advanced en HPE, ambos gobernados mediante Redfish, y cada chasis de blades a través de su Onboard Administrator. No una placa base de marca blanca cuya idea de gestión remota es un botón de encendido y ninguna consola.

En los chasis de blades, el Onboard Administrator alcanza cada controlador del chasis a través del backplane, y es a su vez un par redundante con failover automático.

En la práctica. Cuando un rack de chasis de blades necesitó licenciar iLO Advanced, y crear una cuenta de gestión en cada blade, no iniciamos sesión en un solo blade. Lo aplicamos a través del Onboard Administrator de cada chasis y el rack quedó listo en minutos, incluidos blades montados esa misma semana que aún no tenían credenciales propias. Es un runbook.

La red de gestión no es la red de producción

El controlador tiene su propio puerto físico y su propio cable hacia su propio switching. No particionamos una tarjeta de red de producción para que el controlador tome prestada una porción, que es el atajo habitual y la razón habitual por la que la gestión acaba a un error de distancia de internet. La gestión vive en sus propios switches, o en sus propias VLAN sobre fabrics que no transportan nada más, en espacio de direcciones privado que no se enruta hacia ni desde ninguna red de cliente y que nunca se anuncia a internet.

Lo llamamos air gap porque así se comporta. Una máquina virtual de cliente, incluso una totalmente comprometida, escaneando a velocidad de línea durante una semana, no puede ver un iLO ni un iDRAC en absoluto. Ni rechazado, ni filtrado: ausente. No hay ningún sitio al que puedan ir los paquetes. Se cumple también en el otro sentido, y eso importa igual: ningún tráfico de gestión viaja por una VLAN de cliente, así que nuestras sesiones de consola, la monitorización y los backups nunca entran en el dominio de broadcast de un cliente ni compiten por su ancho de banda. El aislamiento es lo bastante real como para resultarnos incómodo, y esa es la prueba de que es real: un controlador en una VLAN de gestión no puede alcanzar sin más un servidor web interno para descargar una imagen de firmware, porque no se permite nada que no se haya pedido y dejado por escrito. El ingeniero da el paso adicional.

Los backups viajan por el mismo camino. Se realizan a través de la red fuera de banda, nunca por un segmento de producción.

En la práctica. Una única lista de acceso de gestión canónica está aplicada en cada plataforma que operamos, en las líneas de inicio de sesión de Cisco Nexus, por instancia de enrutamiento en los routers, por interfaz para SSH y HTTPS en los firewalls, permitiendo solo las subredes de gestión designadas, con control plane policing limitando en hardware lo que quede.

El plano de gestión en sí

El plano de gestión es una red por derecho propio y la construimos como tal. Corre sobre nuestro propio backbone cifrado multisede: Cisco DMVPN, IPsec con AES-256, BGP transportado por los túneles, uniendo Atenas, Ámsterdam y Toronto con nuestra sede central en Chipre, que deliberadamente no está en ninguno de los edificios que gestiona. Los hubs son redundantes, con caminos de igual coste entre ellos y a través de circuitos diversos, y una detección de fallos que advierte un camino muerto en bastante menos de un segundo.

El personal llega a él de una sola manera: a través de puertas de enlace VPN y firewalls que poseemos y operamos nosotros mismos, sobre OPNsense y Cisco Firepower, y luego a través de jump hosts dentro del plano, nunca directamente desde el portátil de un ingeniero. Los distintos niveles de confianza nunca comparten un objeto de firewall, así que ampliar el acceso de un grupo no puede ampliar silenciosamente el de otro.

Hacia los planos de backup y disaster recovery la política es denegar por defecto y los datos fluyen en un solo sentido. Producción nunca empuja hacia backup. El lado de backup extrae. Eso se aplica con reglas de denegación explícitas en los appliances de firewall, no con un firewall de host que un host comprometido podría editar, y los segmentos de backup no tienen ninguna ruta a internet. Solo el rango de gestión los alcanza. Si una máquina de producción es tomada por completo, el atacante no obtiene ningún conocimiento de la infraestructura de backup ni ningún camino hacia ella. Desde donde está, no existe.

Los cambios en el backbone se verifican en vivo contra el sistema en marcha, una mitad de un par redundante cada vez, y por eso podemos trabajar en el backbone en mitad de una jornada laboral.

En la práctica. Trasladamos toda la instalación de VPN sitio a sitio de un cliente de un país a otro en una sola sesión, antes de una fecha límite fija. El hub se clonó, se llevó al otro lado y se levantó en paralelo con el original, de modo que ambos estuvieron activos a la vez y siempre hubo un lugar donde los túneles pudieran estar. Los routers de las sucursales se movieron uno a uno, cada uno verificado en marcha antes de tocar el siguiente, cada uno conmutando limpiamente sobre la marcha. Nadie viajó a una sucursal.

La línea base de hardening en cada host

Cada máquina que construimos parte de la misma línea base, y la línea base no está sujeta a negociación. SELinux está en modo enforcing, y no lo desactivamos para que una aplicación coopere: escribimos la política. Los sistemas de ficheros son XFS.

El parcheo no depende de nadie más. Mantenemos nuestro propio espejo de paquetes en nuestro propio datacenter, con los repositorios desde los que instala nuestra flota, con las firmas upstream intactas, accesible solo desde nuestros propios rangos de direcciones. Que un espejo público tenga un mal día no es un evento aquí, y un servidor deliberadamente incapaz de hablar con internet sigue siendo un servidor que podemos parchear por completo.

En la práctica. Cuando se publicó una vulnerabilidad crítica en un runtime de uso generalizado, los paquetes corregidos estaban en producción en cada servidor afectado el mismo día, antes de que acabara esa misma noche. Ni a mano ni con prisas: el despliegue hace un backup, actualiza un host cada vez, muestrea sitios reales de ese host para comprobar una respuesta sana antes y después, y detiene todo el barrido automáticamente si uno no vuelve correctamente. Rápido y cuidadoso no son opuestos si se construye la herramienta que lo hace por uno.

Los registros de las máquinas entran, y nada puede quedarse en silencio

Las severidades serias van directamente al chat de operaciones donde ya está el ingeniero de guardia, y llegan a una persona en segundos; sabemos que son segundos porque lo hemos cronometrado con una alarma real. En el edge, sensores dedicados leen tráfico espejado de los routers de borde y vigilan de forma continua patrones volumétricos y de denegación de servicio.

Un dispositivo puede parecer perfectamente sano desde su propia línea de comandos mientras, en silencio, no envía nada al colector, así que «el logging está configurado» aquí no es una evidencia. Confirmamos que el registro llega, en el extremo remoto, al flujo al que pertenece, después de cada cambio que pudiera haberlo alterado. Los sistemas de monitorización tienen sus propios watchdogs en máquinas separadas, así que «lo que vigilaba ha dejado de vigilar» es en sí mismo una alarma. El silencio nunca es una buena noticia.

En la práctica. Nuestra revisión rutinaria de estado comprueba también dos cosas que la mayoría de las revisiones omiten: si cada dispositivo sigue enviando de verdad sus registros, y si su configuración sigue respaldándose de verdad. Esos dos son los fallos que esconden a los demás.

Análisis en tiempo real en nuestras propias NVIDIA A100

La mayoría de los proveedores recogen los registros en un cubo y lo buscan después de que algo ya se haya roto. Nosotros ponemos el flujo a trabajar. Unas reglas básicas eliminan primero el ruido conocido, y luego todo lo que queda, de routers, switches, firewalls, cabinas de storage y servidores, se analiza a medida que llega mediante modelos de IA que se ejecutan en un conjunto de GPU NVIDIA A100 de nuestra propiedad, dentro de nuestro propio datacenter.

Los modelos leen a través de los dispositivos, no línea a línea: un error en un camino de storage, una interfaz que oscila y una temperatura en aumento en el mismo rack se convierten en una sola historia en lugar de tres mensajes inconexos. Captan los patrones que una regla estática nunca captará, la deriva lenta y la combinación inusual que precede a un fallo, y cada alarma llega al ingeniero con una segunda opinión ya adjunta. Los datos de las máquinas dejan de ser un montón de texto que rastrear con grep y se convierten en una alerta temprana.

Nada de esto sale de nuestra red. Los modelos, las GPU y los datos son todos nuestros, y ninguna línea de registro se envía jamás a un servicio de IA externo.

Un CTO que nos esté evaluando puede pedirnos la lista de acceso, el runbook y el enrutamiento de alarmas. Le mostraremos los tres.