Zero Trust, VPN e inspección TLS fan traballos distintos

Os documentos de compra tratan zero trust, VPN e inspección TLS coma se fose a mesma compra, e cada un responde unha pregunta que os outros non poden. Un túnel constrúe un camiño protexido, unha porta de inspección le o tráfico que pode terminar, e unha política decide se unha identidade nomeada pode executar unha operación nomeada sobre un recurso nomeado. Só a última é unha decisión de autorización. Un produto pode facer perfectamente as dúas primeiras e aínda deixar aberta a pregunta real.

Tres mecanismos, tres preguntas

O túnel responde como chega o tráfico á rede. Unha porta de inspección responde que pode ver e facer un elemento intermedio onde está autorizado a terminar TLS. Un motor de políticas responde quen pode facer que a que recurso, e despois necesita un punto de aplicación capaz de aplicar esa resposta. A arquitectura zero trust de NIST pon o recurso no centro e négase a inferir confianza de onde veu un paquete.

Ese enfoque é máis difícil de satisfacer ca unha etiqueta, e moito máis difícil de falsificar nunha revisión. Tamén move a pregunta desde que produtos están despregados cara a que decisións se aplican e mediante que.

Onde se aplica realmente a decisión

Tome unha solicitude: un enxeñeiro de soporte abre unha consola de servizo, e unha máquina persoal conectada ao mesmo conmutador non debe herdar ese permiso só por estar preto. Anote a operación permitida, as condicións do dispositivo e o compoñente que as aplica. A ubicación decide todo: unha porta de aplicación, un proxy de servizo, un control de host ou outra fronteira que a organización realmente admita. Sexa cal sexa ese compoñente, ten que estar na ruta dos intentos remotos e dos locais.

O tráfico que nunca cruza a entrada da VPN non se rexe por unha comprobación feita alí, por exhaustiva que sexa. Esa única fenda explica a maior parte da distancia entre un diagrama de zero trust e un despregamento que funciona. Debuxe a ruta da solicitude antes de debuxar a arquitectura.

Descifrar non é autorizar

A interceptación serve obxectivos de inspección estreitos e leva a súa propia carga de certificados, raíces de confianza, revisión de privacidade e aplicacións que se rompen baixo ela. Nada diso é o que significa zero trust, e nada diso substitúe unha decisión de política. Autenticar a unha persoa e autorizar un servizo é totalmente posible sen descifrar un só paquete. Un fluxo descifrado non di nada sobre se o usuario tiña dereito á operación que leva dentro.

A política necesita un tipo de proba, e o descifrado non o é. A saúde do dispositivo é unha entrada entre a identidade, a sensibilidade do recurso e o contexto, e pasala unha vez non lle entrega a esa máquina o resto da rede. Mesturar as dúas converte unha pregunta de autorización nun proxecto de certificados.

Cando a porta non está en ningures da ruta

Inventaríe o que viaxa sen tocar a porta remota: ligazóns entre máquinas do segmento local, chamadas dunha carga de traballo a outra e extremos alcanzados directamente dentro dunha conta de nube. Para cada ruta, nomee un método de aplicación que realmente poida despregarse hoxe. O equipo que non pode aloxar un axente segue necesitando outro control admitido de forma explícita, e supoñer que o axente chegará máis tarde non pecha nada agora. O acceso de servizo a servizo adoita encaixar mellor coa identidade de carga de traballo e unha comprobación escrita contra o recurso ca con outra rede superposta.

Acepte o deseño polo comportamento e non polos diagramas: que operacións se permiten, cales se denegan e onde se aplica cada resposta. Asine operacións concretas permitidas e denegadas, e inclúa unha ruta local que nunca chegue á porta. Deixe constancia de quen é o dono da política, como cambia e como funciona a revocación.

Un túnel reetiquetado segue sendo un túnel. Unha política decide, e algo ten que aplicara.