Flytte en bedriftswebapp bak VPN-en: en gjennomgang av overgangen

Se for deg endringen fra brukerens side. Noen klikker på et bokmerke, forventer den kjente påloggingssiden og får i stedet en tilkoblingsfeil fordi vertsnavnet nå bare svarer inne i tunnelen. Det ene øyeblikket inneholder alt migrasjonsplanen må gjøre riktig: navnet, banen, sertifikatet, kontoen og operasjonen bak den. Gå gjennom trinnene nedenfor i den rekkefølgen, og overgangen slutter å være et sprang.

Trinn 1: skriv ned hva brukerne gjør i dag

Start med vertsnavnet i adressefeltet, porten, operasjonene folk utfører og kontoene de bruker. Hvis du ikke kan navngi de tre viktigste operasjonene, er du ikke klar til å lukke den offentlige inngangen, fordi du ikke vil gjenkjenne en ødelagt under aksepten.

Deretter bestemmer du hvem det private publikummet er. Ansatte på bedrifts-VPN-en er en begynnelse, ikke et svar. Kontraktører, støttepersonale og økonomiteamet kan alle trenge applikasjonen og sitter kanskje ikke alle bak samme gateway.

Trinn 2: skill tunnelen fra påloggingen

Når brukeren når applikasjonen gjennom VPN-en, åpner nettleseren fortsatt en TLS-tilkobling til applikasjonens eget endepunkt. Sertifikatet må samsvare med navnet, og applikasjonen autentiserer fortsatt kontoen. Ingenting i tunnelen erstatter noen av delene.

Det er her migreringer stille går galt. Noen bestemmer at den private adressen ikke lenger trenger et gyldig sertifikat, brukerne lærer å klikke gjennom en advarsel, og organisasjonen har byttet en offentlig eksponering mot et opplæringsprogram i å ignorere sikkerhetsvarsler. Hvis applikasjonen virkelig trenger et internt sertifikat, utsted ett fra den interne myndigheten og distribuer tilliten ordentlig. Det er en kontrollert endring; en advarselsside er det ikke.

Behold autorisasjonen der den allerede er. NISTs sammendrag av nulltillitsarkitekturen sier det direkte: nettverksplassering er ikke grunn til å gi en følsom operasjon. Å være inne i tunnelen bør ikke gjøre en skrivebeskyttet konto til administrator.

Trinn 3: finn dem som kaller og som ikke er ansatte

Åpne konfigurasjonen til applikasjonen og list opp alt som snakker med den: identitetsleverandørens callback-URL, en betalingsleverandørs webhook, en planlagt import, en overvåkingssonde, en partners API-klient. Hver er en avhengighet med en eier, og hver vil bryte på et ulikt tidspunkt.

Bestem en støttet vei for hver som må bli. En webhook-leverandør kan ikke bli med i ansatt-VPN-en din, så enten eksponer et smalt integrert endepunkt med egen autentisering, eller endre integrasjonsmodellen. Å la hele applikasjonen være offentlig fordi det finnes én callback er et valg, og vanligvis det gale.

Skriv ned hvert unntak med destinasjon, tillatt operasjon, autentisering og eier. En generisk VPN-konto gitt til en integrasjon er hvordan et unntak blir permanent. Gå gjennom listen ved neste tilgangsrevisjon, fordi integrasjoner lever lenger enn prosjektene som la dem til. Et unntak uten utløpsdato er en permanent designbeslutning som ingen har tatt.

Trinn 4: avvikle den offentlige ruten, ikke bare DNS-posten

Gå gjennom publiseringskjeden: DNS, lastbalansererens lyttere, regler for omvendt proxy, vertsbrannmur og ethvert alternativt navn som fortsatt peker på den gamle adressen. Kontroller begge adressefamiliene. Å endre hoved-A-posten beviser nesten ingenting hvis en eldre CNAME eller en IPv6-lytter fortsatt betjener appen.

Bekreft samtidig at det private navnet løses inne i tunnelen, og at sertifikatet dekker navnet brukerne vil skrive. En bruker som må lime inn en numerisk adresse, har funnet et symptom, ikke en omvei.

Begrens VPN-publikummet til applikasjonens bane. Bred tilgang til kontornettverket bytter én eksponeringsbeslutning mot en større, og administrative grensesnitt trenger egne tillatte kilder i stedet for å arve brukerregelen.

Trinn 5: gå gjennom aksepten selv

Koble til som godkjent bruker, åpne bokmerket, kontroller sertifikatet, logg inn og utfør én ekte operasjon. Prøv deretter en konto som ikke skal ha den operasjonen, og bekreft at den avvises. Prøv deretter fra en enhet utenfor VPN-en og bekreft at applikasjonen er utilgjengelig.

Gjenta for hver beholdt integrasjon, og les leverandørens leveringslogg i stedet for å anta at en 200 fra ditt eget testverktøy er det samme. En vellykket VPN-pålogging er ikke bevis for noen av disse resultatene.

Trinn 6: øv på den dårlige dagen

Bestem hva som skjer under et tunnelutfall: arbeidet stopper, eller en annen godkjent tilgangsmetode tar over. Uansett hva du velger, skriv det ned og test det én gang, fordi nødåpning for publikum som en udokumentert gjenopprettingsmekanisme til slutt vil bli utført av noen under press.

Behold gjenopprettingstilgang for administratorene som vedlikeholder gatewayen og applikasjonen, med eier og fjerningsdato. Registrer endringen og dens tilbakeføringsvilkår samme sted, slik at en mislykket migrering ikke låser ute dem som ville rettet den.

Etter overgangen er lapping, kontolivssyklus, applikasjonsautorisasjon og revisjon fortsatt ditt. Tunnelen innsnevret inngangen; den overtok ingen av disse oppgavene.