Principios de confianza cero y sus componentes

En el modelo de perímetro, llegar a la red interna ya era una credencial: quien estaba dentro alcanzaba casi todo. La arquitectura de confianza cero retira esa confianza implícita. El NIST la resume en siete principios; entre ellos, que todo servicio y fuente de datos es un recurso que se protege, que la comunicación se protege sin importar la red, que el acceso se concede por sesión y que lo decide una política dinámica.

La identidad pasa a ser el centro: antes de abrir un recurso hay que saber quién pide, desde qué equipo y en qué condiciones, y volver a decidirlo en cada sesión.

La arquitectura se reparte en piezas con una función cada una. Una decide (el motor de políticas), otra ordena abrir o cerrar la ruta (el administrador de políticas) y una tercera es la que en la práctica deja pasar o corta el tráfico: el punto de aplicación de políticas. Alrededor hay sistemas que le dan datos: el de gestión de identidades, el de diagnóstico de equipos, el SIEM y la infraestructura de claves.

Abre el laboratorio y lee componentes.txt, el inventario de Cobaltia. Cada fila nombra la pieza y el sistema que la cumple.

Un recurso confía por costumbre cuando exige autenticación solo a quien llega de fuera, y deja pasar sin pedir nada a quien llega desde la red interna. Cada uno de esos recursos es una puerta abierta para quien logre ponerse dentro, por una cuenta robada o un equipo infectado, sin que nadie lo vuelva a comprobar.

En recursos.txt, la columna «auth interna» dice si el recurso pide autenticación a quien viene de dentro. Cuenta los que no la piden.

El tercer principio pide que el acceso se conceda por sesión: cuando la sesión acaba, la decisión se toma otra vez, con los datos de ese momento. Un acceso que nunca vence no se vuelve a evaluar, y si la cuenta se compromete, nadie lo notará por esa vía.

La columna «duración» de recursos.txt dice cuánto dura el acceso una vez concedido. Hay un recurso cuya duración contradice el principio.

Decidir en cada acceso solo es viable si es rápido. El archivo flujo.txt registra una solicitud de principio a fin: el sujeto pide, el punto de aplicación consulta, el motor decide, el administrador ordena y el canal se abre. Cada línea lleva su hora.

Mide cuánto pasó entre que el sujeto pidió el acceso y el canal quedó abierto.