Flytte ein bedriftswebapp bak VPN-en: ein gjennomgang av overgangen
Følg endringa frå bokmerket til brukaren til den gamle offentlege lyttaren. Hald HTTPS, applikasjonskontoane og kvar ikkje-tilsett som kallar i planen.
Sjå føre deg endringa frå sida til brukaren. Nokon klikkar på eit bokmerke, ventar den kjende påloggingssida og får i staden ein tilkoplingsfeil fordi vertsnamnet no berre svarar inne i tunnelen. Det eine augneblinken inneheld alt migrasjonsplanen må gjere rett: namnet, banen, sertifikatet, kontoen og operasjonen bak han. Gå gjennom trinna nedanfor i den rekkjefølgja, og overgangen sluttar å vere eit sprang.
Trinn 1: skriv ned kva brukarane gjer i dag
Start med vertsnamnet i adressefeltet, porten, operasjonane folk utfører og kontoane dei brukar. Viss du ikkje kan namngje dei tre viktigaste operasjonane, er du ikkje klar til å lukke den offentlege inngangen, fordi du ikkje vil kjenne att ein øydelagd under aksepten.
Deretter avgjer du kven det private publikumet er. Tilsette på bedrifts-VPN-en er ein byrjan, ikkje eit svar. Kontraktørar, støttepersonale og økonomiteamet kan alle trenge applikasjonen og sit kanskje ikkje alle bak same gateway.
Trinn 2: skil tunnelen frå pålogginga
Når brukaren når applikasjonen gjennom VPN-en, opnar nettlesaren framleis ei TLS-tilkopling til applikasjonens eige endepunkt. Sertifikatet må samsvare med namnet, og applikasjonen autentiserer framleis kontoen. Ingenting i tunnelen erstattar nokon av delane.
Det er her migreringar stille går gale. Nokon avgjer at den private adressa ikkje lenger treng eit gyldig sertifikat, brukarane lærer å klikke gjennom ei åtvaring, og organisasjonen har bytt ein offentleg eksponering mot eit opplæringsprogram i å ignorere tryggingsvarsel. Viss applikasjonen verkeleg treng eit internt sertifikat, utsted eitt frå den interne styresmakta og fordel tilliten ordentleg. Det er ei kontrollert endring; ei åtvaringsside er det ikkje.
Hald autorisasjonen der han allereie er. Samandraget av nulltillitsarkitekturen til NIST seier det direkte: nettverksplassering er ikkje grunn til å gje ein følsam operasjon. Å vere inne i tunnelen bør ikkje gjere ein skriveverna konto til administrator.
Trinn 3: finn dei som kallar og som ikkje er tilsette
Opne konfigurasjonen til applikasjonen og list opp alt som snakkar med han: callback-URL-en til identitetsleverandøren, ein webhook frå ein betalingsleverandør, ein planlagd import, ein overvakingssonde, ein API-klient hjå ein partnar. Kvar er ein avhengnad med ein eigar, og kvar vil bryte på eit ulikt tidspunkt.
Avgjer ein støtta veg for kvar som må bli verande. Ein webhook-leverandør kan ikkje bli med i tilsett-VPN-en din, så anten eksponer eit smalt integrert endepunkt med eigen autentisering, eller endre integrasjonsmodellen. Å la heile applikasjonen vere offentleg fordi det finst éin callback er eit val, og vanlegvis det gale.
Skriv ned kvart unntak med destinasjon, tillaten operasjon, autentisering og eigar. Ein generisk VPN-konto gjeven til ein integrasjon er korleis eit unntak blir permanent. Gå gjennom lista ved neste tilgangsrevisjon, fordi integrasjonar lever lenger enn prosjekta som la dei til. Eit unntak utan utløpsdato er ei permanent designavgjerd som ingen har teke.
Trinn 4: avvikle den offentlege ruta, ikkje berre DNS-posten
Gå gjennom publiseringskjeda: DNS, lyttarar til lastbalanseraren, reglar for omvend proxy, vertsbrannmur og eitkvart alternativt namn som framleis peikar på den gamle adressa. Kontroller båe adressefamiliane. Å endre hovud-A-posten beviser nesten ingenting viss ein eldre CNAME eller ein IPv6-lyttar framleis tener appen.
Stadfest samstundes at det private namnet blir løyst inne i tunnelen, og at sertifikatet dekkjer namnet brukarane vil skrive. Ein brukar som må lime inn ei numerisk adresse, har funne eit symptom, ikkje ein omveg.
Afgrens VPN-publikumet til banen til applikasjonen. Brei tilgang til kontornettverket byter éi eksponeringsavgjerd mot ei større, og administrative grensesnitt treng eigne tillatne kjelder i staden for å arve brukarregelen.
Trinn 5: gå gjennom aksepten sjølv
Kopla til som godkjend brukar, opne bokmerket, kontroller sertifikatet, logg inn og utfør éin ekte operasjon. Prøv deretter ein konto som ikkje skal ha den operasjonen, og stadfest at han blir avvist. Prøv deretter frå ein eining utanfor VPN-en og stadfest at applikasjonen er utilgjengeleg.
Gjenta for kvar behalden integrasjon, og les leveringsloggen til leverandøren i staden for å gå ut frå at ein 200 frå ditt eige testverktøy er det same. Ei vellukka VPN-pålogging er ikkje bevis for noko av desse resultata.
Trinn 6: øv på den dårlege dagen
Avgjer kva som skjer under eit tunnelutfall: arbeidet stoppar, eller ein annan godkjend tilgangsmetode tek over. Uansett kva du vel, skriv det ned og test det éin gong, fordi naudopning for publikum som ein udokumentert gjenopprettingsmekanisme til slutt vil bli utført av nokon under press.
Hald gjenopprettingstilgang for administratorane som vedlikeheld gatewayen og applikasjonen, med eigar og fjerningsdato. Registrer endringa og vilkåra for å snu ho på same stad, slik at ein mislukka migrasjon ikkje låser ute dei som ville rette han.
Etter overgangen er lapping, kontolivssyklus, applikasjonsautorisasjon og revisjon framleis ditt. Tunnelen innsnevra inngangen; han tok ikkje over nokon av desse oppgåvene.