Flytta en företagswebbapp bakom VPN: en guide för övergången

Föreställ dig ändringen ur användarens perspektiv. Någon klickar på ett bokmärke, förväntar sig den vanliga inloggningssidan och får i stället ett anslutningsfel eftersom värdnamnet nu bara svarar inne i tunneln. Det enda ögonblicket innehåller allt som migreringsplanen måste göra rätt: namnet, sökvägen, certifikatet, kontot och operationen bakom det. Gå igenom stegen nedan i den ordningen och övergången är inte längre ett språng.

Steg 1: skriv ned vad användarna gör i dag

Börja med värdnamnet i adressfältet, porten, operationerna som människor utför och kontona de använder. Om du inte kan namnge de tre viktigaste operationerna är du inte redo att stänga den offentliga ingången, för du kommer inte att känna igen en trasig vid mottagningen.

Bestäm sedan vilka som är den privata publiken. Anställda på företagets VPN är en början, inte ett svar. Entreprenörer, supportpersonal och ekonomiteamet kan alla behöva applikationen och sitter kanske inte alla bakom samma gateway.

Steg 2: skilj tunneln från inloggningen

När användaren når applikationen via VPN öppnar webbläsaren fortfarande en TLS-anslutning till applikationens egen slutpunkt. Certifikatet måste matcha det namnet, och applikationen autentiserar fortfarande kontot. Ingenting i tunneln ersätter något av dem.

Här går migreringar tyst fel. Någon bestämmer att den privata adressen inte längre behöver ett giltigt certifikat, användarna lär sig klicka igenom en varning, och organisationen har bytt en offentlig exponering mot en utbildning i att ignorera säkerhetsvarningar. Om applikationen verkligen behöver ett internt certifikat, utfärda ett från den interna myndigheten och distribuera förtroendet ordentligt. Det är en kontrollerad ändring; en varningssida är det inte.

Behåll auktoriseringen där den redan finns. NIST:s sammanfattning av nollförtroendearkitekturen säger det direkt: nätverksplats är inte skäl att bevilja en känslig operation. Att vara inne i tunneln bör inte göra ett skrivskyddat konto till administratör.

Steg 3: hitta anroparna som inte är anställda

Öppna applikationens konfiguration och lista allt som talar med den: identitetsleverantörens callback-URL, en betalningsleverantörs webhook, en schemalagd import, en övervakningssond, en partners API-klient. Var och en är ett beroende med en ägare, och var och en kommer att gå sönder vid olika tidpunkter.

Bestäm en stödd väg för var och en som måste finnas kvar. En webhook-leverantör kan inte ansluta till er anställdas VPN, så antingen exponerar ni en snävt avgränsad integrationsslutpunkt med egen autentisering, eller ändrar integrationsmodellen. Att lämna hela applikationen offentlig för att det finns en callback är ett val, och oftast det felaktiga.

Skriv ned varje undantag med destination, tillåten operation, autentisering och ägare. Ett generiskt VPN-konto som ges till en integration är hur ett undantag blir permanent. Granska listan vid nästa åtkomstgranskning, eftersom integrationer lever längre än projekten som lade till dem. Ett undantag utan utgångsdatum är ett permanent designbeslut som ingen fattat.

Steg 4: avveckla den offentliga rutten, inte bara DNS-posten

Gå igenom publiceringskedjan: DNS, lastbalanserarens lyssnare, regler för omvänd proxy, värdens brandvägg och varje alternativt namn som fortfarande pekar på den gamla adressen. Kontrollera båda adressfamiljerna. Att ändra huvud-A-posten bevisar nästan ingenting om en äldre CNAME eller en IPv6-lyssnare fortfarande betjänar appen.

Bekräfta samtidigt att det privata namnet löses ut inne i tunneln och att certifikatet täcker namnet användarna kommer att skriva. En användare som måste klistra in en numerisk adress har hittat ett symptom, inte en lösning.

Begränsa VPN-publiken till applikationens sökväg. Bred åtkomst till kontorsnätet byter ett exponeringsbeslut mot ett större, och administrativa gränssnitt behöver egna tillåtna källor i stället för att ärva användarregeln.

Steg 5: gör mottagningen själv

Anslut som godkänd användare, öppna bokmärket, kontrollera certifikatet, logga in och utför en verklig operation. Prova sedan ett konto som inte borde ha den operationen och bekräfta att det nekas. Prova sedan från en enhet utanför VPN:en och bekräfta att applikationen är oåtkomlig.

Upprepa för varje bevarad integration, och läs leverantörens leveranslogg i stället för att anta att en 200 från ditt eget testverktyg är samma sak. En lyckad VPN-inloggning är inte bevis för något av dessa resultat.

Steg 6: öva den dåliga dagen

Bestäm vad som händer vid ett tunnelavbrott: arbetet stoppas, eller så tar en annan godkänd åtkomstmetod över. Vad du än väljer, skriv ned det och testa det en gång, för akut offentlig återöppning som en odokumenterad återställningsmekanism kommer till slut att utföras av någon under press.

Behåll återställningsåtkomst för administratörerna som underhåller gatewayen och applikationen, med ägare och borttagningsdatum. Registrera ändringen och dess återställningsvillkor på samma ställe, så att en misslyckad migrering inte låser ute dem som skulle åtgärda den.

Efter övergången är patchning, kontolivscykel, applikationsauktorisering och revision fortfarande ditt. Tunneln smalnade av ingången; den tog inte över något av dessa jobb.