El servicio de metadatos de la nube como activo

En la nube, una instancia no guarda una contraseña para hablar con el resto de los servicios: lleva un rol adjunto, y pide credenciales temporales a un servicio de metadatos que responde en una dirección de enlace local, igual en todas las instancias. La frontera de ese servicio es la instancia misma: quien pregunta desde dentro, recibe.

Eso convierte cualquier salida controlada por un tercero en un camino hacia los permisos del rol. No hace falta que la aplicación muestre la respuesta en pantalla: el conversor incrusta lo que descarga en un documento que después se entrega. Por eso la defensa no es una sola: se endurece el servicio de metadatos, se bajan los permisos del rol y se bloquea la dirección en la salida de red.

Abre el laboratorio. arquitectura.txt dice qué rol lleva cada servicio; respuesta-guardada.txt es la captura que hizo el equipo de nube dentro de su ventana de trabajo, con los valores de credencial reemplazados por marcadores antes de entregarla. El nombre del rol no se sustituyó, y es lo que permite medir el alcance: con él se mira qué permisos quedaron expuestos.

salida-conversor.log solo trae las conexiones cuyo destino es la dirección de enlace local del servicio de metadatos. Cuenta las de la ventana: ese número es el que va al informe, porque separa un fallo posible de un fallo que ya pasó, y fija la ventana de rotación que el equipo de nube tiene que ejecutar.

Lee opciones-instancia.txt y compara la instancia del conversor con las dos del portal. Dos opciones están en un valor distinto: una acepta consultas sin sesión previa y la otra deja que la respuesta salga de la propia máquina. Las instancias nuevas vienen con los valores estrictos; la del conversor se creó en 2023 a partir de una plantilla vieja.