La red interna no es zona de confianza

La arquitectura de confianza cero que describe NIST en su publicación SP 800-207, de agosto de 2020, parte de una idea simple: estar en una red, aunque sea la propia, no da confianza a nadie. Cada acceso a un recurso se autentica y se autoriza antes de hacerse, y la protección se pone alrededor del recurso, no del perímetro.

En microservicios esto tiene una lectura muy concreta. Una política de red que limita quién puede abrir una conexión es útil: reduce lo que un servicio comprometido o mal configurado alcanza. Pero no sustituye que el servicio de destino compruebe quién lo llama y para qué. Son dos capas distintas y hacen falta las dos.

Abre el laboratorio y lee politicas-red.yaml. Fíjate en la primera regla del clúster: lo que no tiene política acepta tráfico de cualquiera. Es un valor por defecto abierto, y por eso basta con olvidar un solo espacio para que quede expuesto entero. Compara la lista de espacios con políticas con la de servicios.txt.

Una política puede existir y aun así ser más ancha de lo que pide la arquitectura. Aquí se aplican por espacio de nombres a todos los servicios de ese espacio, y uno de ellos está abierto a todos. Recorre flujos.log y, para cada flujo que la política permitió, comprueba si el par origen y destino está en matriz-prevista.txt. Cuenta los permitidos que la matriz no prevé.

El servicio de la tarea anterior tiene un puerto de administración sin autenticación «porque solo se llega desde la red interna». Ya sabes que su espacio no tiene política. Lee cuentas-admin.txt y cruza la hora y la dirección con el registro de flujos y con servicios.txt.

El arreglo fácil es agregar una política al espacio que no la tiene y dar el caso por cerrado. Eso reduce quién llega, pero deja intacta la causa: una operación que cambia contraseñas y no pregunta quién la pide. Si mañana un servicio permitido falla, el hueco vuelve a estar ahí.