Moure una aplicació web d'empresa darrere la VPN: guia del tall
Seguiu el canvi des del marcador de l'usuari fins a l'antic receptor públic. Mantingueu HTTPS, els comptes de l'aplicació i tots els cridadors no empleats al pla.
Imagineu el canvi des del costat de l'usuari. Algú clica un marcador, espera la pàgina d'inici familiar i, en canvi, rep un error de connexió perquè el nom d'amfitrió ara només respon dins del túnel. Aquest moment únic conté tot el que el pla de migració ha d'encertar: el nom, el camí, el certificat, el compte i l'operació que hi ha darrere. Seguiu els passos de sota en aquest ordre i la migració deixa de ser un salt.
Pas 1: anoteu què fa avui la gent
Comenceu pel nom d'amfitrió a la barra d'adreces, el port, les operacions que fa la gent i els comptes que utilitzen. Si no podeu anomenar les tres operacions principals, no esteu a punt per tancar l'entrada pública, perquè no reconeixereu una de trencada durant l'acceptació.
Després decidiu qui és el públic privat. Els empleats a la VPN corporativa són un començament, no una resposta. Els contractistes, el personal de suport i l'equip financer poden necessitar tots l'aplicació i potser no tots seuen darrere la mateixa porta d'enllaç.
Pas 2: separeu el túnel de l'inici de sessió
Quan l'usuari arriba a l'aplicació a través de la VPN, el navegador encara obre una connexió TLS al punt final propi de l'aplicació. El certificat ha de coincidir amb aquest nom, i l'aplicació encara autentica el compte. Res del túnel substitueix cap de les dues coses.
Aquí és on les migracions fallen en silenci. Algú decideix que l'adreça privada ja no necessita un certificat vàlid, els usuaris aprenen a clicar a través d'un avís, i l'organització ha canviat una exposició pública per un programa de formació en ignorar avisos de seguretat. Si l'aplicació necessita de debò un certificat intern, emeteu-ne un de l'autoritat interna i distribuïu la confiança correctament. Això és un canvi controlat; una pàgina d'avís no ho és.
Mantingueu l'autorització on ja viu. El resum de l'arquitectura de confiança zero del NIST ho diu directament: la ubicació a la xarxa no és motiu per concedir una operació sensible. Ser dins del túnel no hauria de convertir un compte de només lectura en administrador.
Pas 3: trobeu els cridadors que no són empleats
Obriu la configuració de l'aplicació i llisteu tot el que hi parla: l'URL de retorn del proveïdor d'identitat, el webhook d'un proveïdor de pagaments, una importació programada, una sonda de monitoratge, el client API d'un soci. Cadascun és una dependència amb un propietari, i cadascun es trencarà en un moment diferent.
Decidiu un camí suportat per a cadascun que ha de quedar-se. Un proveïdor de webhook no pot unir-se a la vostra VPN d'empleats, així que o exposeu un punt final d'integració d'abast estret amb la seva pròpia autenticació, o canvieu el model d'integració. Deixar tota l'aplicació pública perquè existeix una devolució de trucada és una elecció, i normalment la incorrecta.
Anoteu cada excepció amb destinació, operació permesa, autenticació i propietari. Un compte VPN genèric lliurat a una integració és com una excepció es torna permanent. Reviseu la llista a la propera revisió d'accés, perquè les integracions sobreviuen als projectes que les van afegir. Una excepció sense data de caducitat és una decisió de disseny permanent que ningú no va prendre.
Pas 4: retireu la ruta pública, no només el registre DNS
Recorreu la cadena de publicació: DNS, receptors del balançador de càrrega, regles del proxy invers, tallafoc de l'amfitrió i qualsevol nom alternatiu que encara apunti a l'adreça antiga. Comproveu les dues famílies d'adreces. Canviar el registre A principal no demostra gairebé res si un CNAME més antic o un receptor IPv6 encara serveix l'aplicació.
En paral·lel, confirmeu que el nom privat es resol dins del túnel i que el certificat cobreix el nom que els usuaris escriuran. Un usuari que ha d'enganxar una adreça numèrica ha trobat un símptoma, no una solució alternativa.
Limiteu el públic de la VPN al camí de l'aplicació. L'accés ampli a la xarxa d'oficina canvia una decisió d'exposició per una de més gran, i les interfícies administratives necessiten les seves pròpies fonts permeses en lloc d'heretar la regla d'usuari.
Pas 5: passeu l'acceptació vosaltres mateixos
Connecteu-vos com a usuari aprovat, obriu el marcador, comproveu el certificat, inicieu sessió i feu una operació real. Després proveu un compte que no hauria de tenir aquesta operació i confirmeu que se li refusa. Després proveu des d'un dispositiu fora de la VPN i confirmeu que l'aplicació és inabastable.
Repetiu-ho per a cada integració retinguda, i llegiu el registre de lliurament del proveïdor en lloc de suposar que un 200 de la vostra pròpia eina de proves és el mateix. Un inici de sessió VPN correcte no és evidència de cap d'aquests resultats.
Pas 6: assageu el mal dia
Decidiu què passa durant una interrupció del túnel: la feina s'atura o un altre mètode d'accés aprovat pren el relleu. Triïu el que triïu, anoteu-ho i proveu-ho una vegada, perquè la reobertura pública d'emergència com a mecanisme de recuperació sense documentar finalment la farà algú sota pressió.
Mantingueu l'accés de recuperació per als administradors que mantenen la porta d'enllaç i l'aplicació, amb un propietari i una data de retirada. Registreu el canvi i les seves condicions de reversió al mateix lloc, perquè una migració fallida no bloquegi les persones que la repararien.
Després de la migració, l'aplicació de pedaços, el cicle de vida dels comptes, l'autorització de l'aplicació i l'auditoria continuen sent vostres. El túnel va estrenyir l'entrada; no va assumir cap d'aquestes feines.