Quién pide y quién responde

Cliente es quien pide. Servidor es quien responde. Eso es todo.

Y lo primero que hay que quitarse de la cabeza: no son dos clases de computador. Son dos papeles en una conversación. Tu portátil es cliente cuando abres una página, y es servidor si compartes una carpeta con un compañero. La misma máquina, los dos papeles, a veces a la vez.

En la primera sala tú eras el cliente y clinica-meridiano.local el servidor. En la sala de defensa seguías siendo cliente del panel de monitoreo, que era otro servidor.

Y de ese reparto sale la asimetría que sostiene toda la seguridad web:

El servidor controla su propio código. Del cliente no controla nada.

El código que corre en el servidor lo escribió la clínica y vive en su máquina. El que corre en tu navegador se lo mandaron a tu máquina, donde tú puedes leerlo, cambiarlo o ignorarlo.

Esta idea es de las más importantes de toda la ruta, y explica una cantidad enorme de fallos reales.

Imagina que la clínica pone una validación en el navegador: si el usuario no es de coordinación, no le muestres el botón de la agenda. Se siente razonable. Y no protege nada.

Porque el botón no era la puerta. La puerta es la dirección /agenda-interna, y tú la escribiste a mano en la barra sin pasar por ningún botón. Exactamente eso hiciste en la primera sala.

La regla, escrita como se dice en el oficio:

Todo lo que pasa en el cliente es una sugerencia. La decisión se toma en el servidor, siempre, sin excepciones.

Y cuidado con la trampa, porque es la que atrapa a todo el mundo: validar en el cliente no está mal, está incompleto. Sirve para que el usuario vea el error al instante sin esperar al servidor. Es buena experiencia. Simplemente no es seguridad, y confundir las dos cosas es lo que deja puertas abiertas.

Cuando alguien dice que algo «está en la nube», lo que dice es que el servidor no es suyo. Es de otra empresa, en un centro de datos que no ha visto, y le paga por usarlo.

Técnicamente no cambia nada de lo que has visto: sigue siendo una máquina con Linux, con procesos, con permisos y con registros. Cambia quién responde de qué, y eso sí importa.

La forma más útil de recordarlo:

• El proveedor responde de la nube. Que la máquina exista, que tenga corriente, que el disco no se rompa, que nadie entre físicamente al edificio.
• Tú respondes de lo que pones EN la nube. Tus permisos, tus contraseñas, quién puede ver qué.

Y casi todas las filtraciones que salen en las noticias con la palabra «nube» son de la segunda clase. No entraron al centro de datos: alguien dejó un almacenamiento abierto a internet, o una contraseña en un archivo de configuración.

El fallo de la clínica habría sido idéntico en la nube. /agenda-interna sin comprobar quién llega no se arregla cambiando de proveedor.