Flyt en virksomhedswebapp bag VPN'en: en gennemgang af skiftet

Forestil dig ændringen fra brugerens side. Nogen klikker på et bogmærke, forventer den velkendte login-side og får i stedet en forbindelsesfejl, fordi værtsnavnet nu kun svarer inde i tunnelen. Det øjeblik indeholder alt, som migreringsplanen skal gøre rigtigt: navnet, stien, certifikatet, kontoen og handlingen bag den. Gå trinnene nedenfor igennem i den rækkefølge, og overgangen holder op med at være et spring.

Trin 1: skriv ned, hvad brugerne gør i dag

Start med værtsnavnet i adresselinjen, porten, de handlinger, folk udfører, og de konti, de bruger. Hvis du ikke kan navngive de tre vigtigste handlinger, er du ikke klar til at lukke den offentlige indgang, for du vil ikke genkende en ødelagt under accepten.

Beslut derefter, hvem det private publikum er. Ansatte på virksomhedens VPN er en begyndelse, ikke et svar. Leverandører, supportpersonale og økonomiteamet har måske alle brug for applikationen og sidder måske ikke alle bag samme gateway.

Trin 2: adskil tunnelen fra login

Når brugeren når applikationen gennem VPN'en, åbner browseren stadig en TLS-forbindelse til applikationens eget endepunkt. Certifikatet skal matche det navn, og applikationen godkender stadig kontoen. Intet ved tunnelen erstatter nogen af delene.

Det er her, migreringer stille går galt. Nogen beslutter, at den private adresse ikke længere behøver et gyldigt certifikat, brugerne lærer at klikke gennem en advarsel, og organisationen har byttet en offentlig eksponering for et træningsprogram i at ignorere sikkerhedsadvarsler. Hvis applikationen reelt har brug for et internt certifikat, så udsted et fra den interne myndighed og distribuer tilliden korrekt. Det er en kontrolleret ændring; en advarselsside er det ikke.

Behold autorisationen, hvor den allerede ligger. NIST's resumé af zero-trust-arkitekturen siger det direkte: netværksplacering er ikke en grund til at give en følsom handling. At være inde i tunnelen bør ikke gøre en skrivebeskyttet konto til administrator.

Trin 3: find de kaldere, som ikke er ansatte

Åbn applikationens konfiguration, og list alt, der taler med den: identitetsudbyderens callback-URL, en betalingsudbyders webhook, en planlagt import, en overvågningssøgning, en partners API-klient. Hver er en afhængighed med en ejer, og hver vil brække på et forskelligt tidspunkt.

Beslut en understøttet vej for hver enkelt, der skal blive. En webhook-udbyder kan ikke tilslutte sig din medarbejder-VPN, så enten eksponer et snævert integreret endepunkt med egen godkendelse, eller ændr integrationsmodellen. At lade hele applikationen være offentlig, fordi ét callback findes, er et valg, og som regel det forkerte.

Skriv hver undtagelse ned med destination, tilladt handling, godkendelse og ejer. En generisk VPN-konto, der gives til en integration, er hvordan en undtagelse bliver permanent. Gennemgå listen ved næste adgangsgennemgang, for integrationer lever længere end de projekter, der tilføjede dem. En undtagelse uden udløbsdato er en permanent designbeslutning, som ingen har taget.

Trin 4: nedlæg den offentlige rute, ikke blot DNS-posten

Gå gennem udgivelseskæden: DNS, loadbalancer-lyttere, regler for omvendt proxy, værtsfirewall og ethvert alternativt navn, der stadig peger på den gamle adresse. Kontroller begge adressefamilier. Ændring af den primære A-post beviser næsten intet, hvis en ældre CNAME eller en IPv6-lytter stadig betjener appen.

Bekræft samtidig, at det private navn opløses inde i tunnelen, og at certifikatet dækker det navn, brugerne vil skrive. En bruger, der skal indsætte en numerisk adresse, har fundet et symptom, ikke en omvej.

Afgræns VPN-publikummet til applikationens sti. Bred adgang til kontornetværket bytter én eksponeringsbeslutning ud med en større, og administrative grænseflader har brug for deres egne tilladte kilder i stedet for at arve brugerreglen.

Trin 5: gå accepten igennem selv

Forbind som godkendt bruger, åbn bogmærket, kontroller certifikatet, log ind og udfør én rigtig handling. Prøv derefter en konto, som ikke bør have den handling, og bekræft, at den afvises. Prøv derefter fra en enhed uden for VPN'en, og bekræft at applikationen er utilgængelig.

Gentag for hver bibeholdt integration, og læs udbyderens leveringslog i stedet for at antage, at et 200 fra dit eget testværktøj er det samme. Et vellykket VPN-login er ikke bevis for nogen af disse resultater.

Trin 6: øv den dårlige dag

Beslut, hvad der sker under et tunneludfald: arbejdet stopper, eller en anden godkendt adgangsmetode overtager. Uanset hvad du vælger, så skriv det ned og test det én gang, for nødgenåbning som en udokumenteret gendannelsesmekanisme vil før eller siden blive udført af nogen under pres.

Behold gendannelsesadgang for de administratorer, der vedligeholder gatewayen og applikationen, med ejer og fjernelsesdato. Registrer ændringen og dens tilbageførselsbetingelser samme sted, så en mislykket migrering ikke låser de personer ude, som ville rette den.

Efter overgangen er patchning, kontolivscyklus, applikationsautorisation og revision stadig dit. Tunnelen indsnævrede indgangen; den overtog ingen af de opgaver.