Salida controlada a nivel de red

El arreglo en la aplicación decide qué destinos tienen sentido para cada funcionalidad. La salida controlada decide qué puede alcanzar la máquina, pase lo que pase en el código. La primera es precisa y frágil, porque la escribe quien escribe la funcionalidad; la segunda es tosca y estable, porque vive en otro equipo y cubre también lo que todavía no existe.

Una salida controlada bien montada tiene tres piezas: reglas que solo permiten lo que cada subred necesita, un proxy de salida con lista de dominios permitidos por el que pasa todo lo que va a internet, y un registro que anota las denegaciones con el servicio que las pidió. Ese registro es, además, la mejor señal temprana de que algo nuevo está pidiendo lo que no debe.

Abre el laboratorio. matriz-servicios.txt cruza cada servicio con las redes que alcanza y dice si su salida pasa por el proxy; reglas-salida.txt tiene las reglas que lo explican, y registro-proxy.log muestra lo que el proxy vio en la ventana. Uno de los servicios sale a internet por su cuenta, sin pasar por ninguna lista de dominios.

La red de bases de datos y servicios internos es la que no debería alcanzar casi nadie. Cuenta los servicios de la matriz que hoy la alcanzan. Ese número, con la nota de la matriz al lado, es el argumento para que plataforma recorte una regla que se copió en 2023 y nadie volvió a mirar.

Las reglas del conversor son tres líneas abiertas de 2023 y una salida directa a internet sin proxy. El equipo de plataforma puede cerrarlas sin esperar a que desarrollo arregle el código, y conviene decirlo así en el informe: hay un arreglo que depende de un despliegue y otro que depende de una regla.