Een bedrijfswebapp achter de VPN plaatsen: een handleiding voor de overstap

Stel je de wijziging voor vanuit de gebruiker. Iemand klikt op een bladwijzer, verwacht de vertrouwde inlogpagina en krijgt in plaats daarvan een verbindingsfout, omdat de hostnaam nu alleen nog binnen de tunnel antwoordt. Dat ene moment bevat alles wat het migratieplan goed moet doen: de naam, het pad, het certificaat, het account en de bewerking erachter. Werk de stappen hieronder in die volgorde af en de overstap is geen sprong meer.

Stap 1: schrijf op wat gebruikers vandaag doen

Begin met de hostnaam in de adresbalk, de poort, de bewerkingen die mensen uitvoeren en de accounts die ze gebruiken. Als je de drie belangrijkste bewerkingen niet kunt benoemen, ben je niet klaar om de openbare ingang te sluiten, want je herkent tijdens de acceptatie geen kapotte.

Bepaal daarna wie het privépubliek is. Medewerkers op de bedrijfs-VPN zijn een begin, geen antwoord. Opdrachtnemers, supportmedewerkers en het financiële team hebben de applicatie misschien allemaal nodig en zitten misschien niet allemaal achter dezelfde gateway.

Stap 2: scheid de tunnel van de login

Wanneer de gebruiker de applicatie via de VPN bereikt, opent de browser nog steeds een TLS-verbinding naar het eigen eindpunt van de applicatie. Het certificaat moet bij die naam passen, en de applicatie authenticeert nog steeds het account. Niets aan de tunnel vervangt een van beide.

Hier gaan migraties stilletjes mis. Iemand besluit dat het privéadres geen geldig certificaat meer nodig heeft, gebruikers leren door een waarschuwing heen te klikken, en de organisatie heeft een openbare blootstelling ingeruild voor een training in het negeren van beveiligingswaarschuwingen. Als de applicatie echt een intern certificaat nodig heeft, geef er dan een uit bij de interne autoriteit en verspreid het vertrouwen correct. Dat is een gecontroleerde wijziging; een waarschuwingspagina is dat niet.

Laat de autorisatie waar die al zit. De samenvatting van de zero-trustarchitectuur van NIST zegt het direct: netwerklocatie is geen reden om een gevoelige bewerking toe te kennen. Binnen de tunnel zijn mag een alleen-lezenaccount geen beheerder maken.

Stap 3: vind de aanroepers die geen medewerkers zijn

Open de configuratie van de applicatie en noem alles op dat ermee praat: de callback-URL van de identiteitsprovider, de webhook van een betaalprovider, een geplande import, een monitoringsprobe, de API-client van een partner. Elk is een afhankelijkheid met een eigenaar, en elk breekt op een ander moment.

Bepaal een ondersteund pad voor elk dat moet blijven. Een webhookprovider kan niet meedoen aan jullie medewerkers-VPN, dus of je stelt een nauw begrensd integratie-eindpunt met eigen authenticatie beschikbaar, of je wijzigt het integratiemodel. De hele applicatie openbaar laten omdat er één callback bestaat is een keuze, en meestal de verkeerde.

Schrijf elke uitzondering op met bestemming, toegestane bewerking, authenticatie en eigenaar. Een generiek VPN-account dat aan een integratie wordt gegeven, is hoe een uitzondering permanent wordt. Bekijk de lijst bij de volgende toegangsreview, want integraties leven langer dan de projecten die ze hebben toegevoegd. Een uitzondering zonder einddatum is een permanent ontwerpbesluit dat niemand heeft genomen.

Stap 4: trek de openbare route in, niet alleen het DNS-record

Loop de publicatieketen door: DNS, listeners van de loadbalancer, regels van de reverse proxy, hostfirewall en elke alternatieve naam die nog naar het oude adres wijst. Controleer beide adresfamilies. Het hoofd-A-record wijzigen bewijst bijna niets als een oudere CNAME of een IPv6-listener de app nog steeds bedient.

Bevestig tegelijk dat de privénaam binnen de tunnel wordt opgelost en dat het certificaat de naam dekt die gebruikers gaan typen. Een gebruiker die een numeriek adres moet plakken, heeft een symptoom gevonden, geen oplossing.

Beperk het VPN-publiek tot het pad van de applicatie. Brede toegang tot het kantoornetwerk ruilt één blootstellingsbeslissing voor een grotere, en beheersinterfaces hebben eigen toegestane bronnen nodig in plaats van de gebruikersregel te erven.

Stap 5: doorloop de acceptatie zelf

Verbind als goedgekeurde gebruiker, open de bladwijzer, controleer het certificaat, log in en voer één echte bewerking uit. Probeer daarna een account dat die bewerking niet zou moeten hebben en bevestig dat het wordt geweigerd. Probeer daarna vanaf een apparaat buiten de VPN en bevestig dat de applicatie onbereikbaar is.

Herhaal dit voor elke behouden integratie, en lees het leveringslog van de provider in plaats van aan te nemen dat een 200 van je eigen testtool hetzelfde is. Een geslaagde VPN-login is geen bewijs voor een van deze resultaten.

Stap 6: oefen de slechte dag

Bepaal wat er gebeurt bij een tunnelstoring: het werk stopt, of een andere goedgekeurde toegangsmethode neemt het over. Wat je ook kiest, schrijf het op en test het één keer, want noodmatig publiek heropenen als ongedocumenteerd herstelmechanisme wordt uiteindelijk uitgevoerd door iemand onder druk.

Behoud hersteltoegang voor de beheerders die de gateway en de applicatie onderhouden, met een eigenaar en een verwijderdatum. Registreer de wijziging en de terugdraaivoorwaarden op dezelfde plek, zodat een mislukte migratie de mensen die het zouden repareren niet buitensluit.

Na de overstap blijven patchen, de levenscyclus van accounts, applicatieautorisatie en auditing van jou. De tunnel heeft de ingang versmald; hij heeft geen van die taken overgenomen.