Zero Trust, VPN i la inspecció TLS fan feines diferents

Els documents de compra tracten zero trust, VPN i la inspecció TLS com si fos la mateixa compra, i cadascun respon una pregunta que els altres no poden. Un túnel construeix un camí protegit, una passarel·la d’inspecció llegeix el trànsit que pot acabar, i una política decideix si una identitat anomenada pot executar una operació anomenada sobre un recurs anomenat. Només l’última és una decisió d’autorització. Un producte pot fer perfectament les dues primeres i encara deixar oberta la pregunta real.

Tres mecanismes, tres preguntes

El túnel respon com arriba el trànsit a la xarxa. La passarel·la d’inspecció respon què pot veure i fer un element intermedi on té autorització per acabar TLS. El motor de polítiques respon qui pot fer què a quin recurs, i després necessita un punt d’aplicació capaç d’aplicar aquesta resposta. L’arquitectura zero trust de NIST posa el recurs al centre i es nega a inferir confiança d’on ha vingut un paquet.

Aquest plantejament és més difícil de satisfer que una etiqueta, i molt més difícil de falsificar en una revisió. També mou la pregunta de quins productes estan desplegats cap a quines decisions s’apliquen i per mitjà de què.

On s’aplica realment la decisió

Agafeu una sol·licitud: un enginyer de suport obre una consola de servei, i una màquina personal connectada al mateix commutador no ha d’heretar aquest permís només per ser a prop. Anoteu l’operació permesa, les condicions del dispositiu i el component que les aplica. La ubicació ho decideix tot: una passarel·la d’aplicació, un proxy de servei, un control d’amfitrió o una altra frontera que l’organització realment admeti. Sigui el que sigui aquest component, ha de seure al camí tant dels intents remots com dels locals.

El trànsit que mai no creua l’entrada de la VPN no es regeix per una comprovació feta allà, per exhaustiva que sigui. Aquest únic buit explica la major part de la distància entre un diagrama de zero trust i un desplegament que funciona. Dibuixeu el camí de la sol·licitud abans de dibuixar l’arquitectura.

El desxifrat no és autorització

La intercepció serveix objectius d’inspecció estrets i porta la seva pròpia càrrega de certificats, arrels de confiança, revisió de privadesa i aplicacions que es trenquen sota ella. Res d’això no és el que significa zero trust, i res d’això no substitueix una decisió de política. Autenticar una persona i autoritzar un servei és del tot possible sense desxifrar ni un sol paquet. Un flux desxifrat no diu res sobre si l’usuari tenia dret a l’operació que porta a dins.

La política necessita un tipus de prova, i el desxifrat no ho és. La salut del dispositiu és una entrada entre la identitat, la sensibilitat del recurs i el context, i passar-la una vegada no dona a aquesta màquina la resta de la xarxa. Barrejar les dues coses converteix una pregunta d’autorització en un projecte de certificats.

Quan la passarel·la no és enlloc del camí

Inventarieu què viatja sense tocar la passarel·la remota: enllaços entre màquines del segment local, crides d’una càrrega de treball a una altra i punts finals assolits directament dins d’un compte de núvol. Per a cada camí, anomeneu un mètode d’aplicació que es pugui desplegar realment avui. L’equipament que no pot allotjar un agent encara necessita algun altre control explícitament admès, i suposar que l’agent arribarà més tard no tanca res ara. L’accés de servei a servei sol encaixar millor amb la identitat de càrrega de treball i una comprovació escrita contra el recurs que amb una altra xarxa superposada.

Accepteu el disseny pel comportament i no pels diagrames: quines operacions es permeten, quines es deneguen i on s’aplica cada resposta. Aproveu operacions concretes permeses i denegades, i incloeu una ruta local que no arribi mai a la passarel·la. Deixeu constància de qui és el propietari de la política, com canvia i com funciona la revocació.

Un túnel reetiquetat continua sent un túnel. Una política decideix, i alguna cosa l’ha d’aplicar.