Przeniesienie firmowej aplikacji webowej za VPN: przewodnik po przełączeniu

Wyobraź sobie zmianę z perspektywy użytkownika. Ktoś klika zakładkę, oczekuje znanej strony logowania, a zamiast tego dostaje błąd połączenia, ponieważ nazwa hosta odpowiada teraz tylko wewnątrz tunelu. Ten jeden moment zawiera wszystko, co plan migracji musi zrobić dobrze: nazwę, ścieżkę, certyfikat, konto i operację za nimi. Przejdź poniższe kroki w tej kolejności, a przełączenie przestanie być skokiem.

Krok 1: zapisz, co użytkownicy robią dziś

Zacznij od nazwy hosta w pasku adresu, portu, operacji wykonywanych przez ludzi i kont, których używają. Jeśli nie potrafisz wymienić trzech głównych operacji, nie jesteś gotowy do zamknięcia publicznego wejścia, ponieważ nie rozpoznasz zepsutej podczas odbioru.

Następnie zdecyduj, kim jest publiczność prywatna. Pracownicy w firmowym VPN to początek, nie odpowiedź. Wykonawcy, personel wsparcia i zespół finansowy mogą wszyscy potrzebować aplikacji i niekoniecznie siedzieć za tą samą bramą.

Krok 2: oddziel tunel od logowania

Gdy użytkownik dociera do aplikacji przez VPN, przeglądarka nadal otwiera połączenie TLS do własnego punktu końcowego aplikacji. Certyfikat musi pasować do tej nazwy, a aplikacja nadal uwierzytelnia konto. Nic w tunelu nie zastępuje żadnego z nich.

Tu migracje po cichu idą źle. Ktoś decyduje, że prywatny adres nie potrzebuje już ważnego certyfikatu, użytkownicy uczą się klikać przez ostrzeżenie, a organizacja zamieniła publiczne wystawienie na szkolenie w ignorowaniu ostrzeżeń bezpieczeństwa. Jeśli aplikacja naprawdę potrzebuje wewnętrznego certyfikatu, wydaj go z wewnętrznego urzędu i właściwie rozpowszechnij zaufanie. To kontrolowana zmiana; strona ostrzeżenia nią nie jest.

Zostaw autoryzację tam, gdzie już jest. Streszczenie architektury zero zaufania NIST mówi to wprost: lokalizacja w sieci nie jest powodem do przyznania wrażliwej operacji. Przebywanie w tunelu nie powinno zamieniać konta tylko do odczytu w administratora.

Krok 3: znajdź wywołujących, którzy nie są pracownikami

Otwórz konfigurację aplikacji i wypisz wszystko, co z nią rozmawia: URL wywołania zwrotnego dostawcy tożsamości, webhook dostawcy płatności, zaplanowany import, sonda monitorująca, klient API partnera. Każde jest zależnością z właścicielem, a każde zepsuje się w innym momencie.

Ustal obsługiwaną ścieżkę dla każdego, które musi zostać. Dostawca webhooka nie może dołączyć do Twojego VPN pracowniczego, więc albo wystaw wąsko ograniczony punkt końcowy integracji z własnym uwierzytelnianiem, albo zmień model integracji. Pozostawienie całej aplikacji publicznej z powodu jednego wywołania zwrotnego to wybór, i zwykle niewłaściwy.

Zapisz każdy wyjątek z celem, dozwoloną operacją, uwierzytelnianiem i właścicielem. Ogólne konto VPN przekazane integracji to sposób, w jaki wyjątek staje się trwały. Przejrzyj listę przy następnym przeglądzie dostępu, ponieważ integracje żyją dłużej niż projekty, które je dodały. Wyjątek bez daty wygaśnięcia to trwała decyzja projektowa, której nikt nie podjął.

Krok 4: wycofaj publiczną trasę, nie tylko rekord DNS

Przejdź przez łańcuch publikacji: DNS, odbiorniki modułu równoważenia obciążenia, reguły odwrotnego proxy, firewall hosta i każdą alternatywną nazwę, która nadal wskazuje stary adres. Sprawdź obie rodziny adresów. Zmiana głównego rekordu A prawie nic nie dowodzi, jeśli starszy CNAME lub odbiornik IPv6 nadal obsługuje aplikację.

Równolegle potwierdź, że prywatna nazwa rozwiązuje się wewnątrz tunelu i że certyfikat obejmuje nazwę, którą wpiszą użytkownicy. Użytkownik, który musi wkleić adres liczbowy, znalazł objaw, a nie obejście.

Ogranicz publiczność VPN do ścieżki aplikacji. Szeroki dostęp do sieci biurowej zamienia jedną decyzję o ekspozycji na większą, a interfejsy administracyjne potrzebują własnych dozwolonych źródeł zamiast dziedziczyć regułę użytkownika.

Krok 5: sam przejdź odbiór

Połącz się jako zatwierdzony użytkownik, otwórz zakładkę, sprawdź certyfikat, zaloguj się i wykonaj jedną rzeczywistą operację. Następnie spróbuj kontem, które nie powinno mieć tej operacji, i potwierdź odmowę. Potem spróbuj z urządzenia poza VPN i potwierdź, że aplikacja jest nieosiągalna.

Powtórz dla każdej zachowanej integracji i przeczytaj dziennik dostarczania dostawcy, zamiast zakładać, że 200 z własnego narzędzia testowego to to samo. Udane logowanie do VPN nie jest dowodem żadnego z tych wyników.

Krok 6: przećwicz zły dzień

Zdecyduj, co się dzieje podczas awarii tunelu: praca się zatrzymuje albo przejmuje ją inna zatwierdzona metoda dostępu. Cokolwiek wybierzesz, zapisz to i przetestuj raz, ponieważ awaryjne publiczne otwarcie jako nieudokumentowany mechanizm odzyskiwania w końcu wykona ktoś pod presją.

Zachowaj dostęp odzyskiwania dla administratorów utrzymujących bramę i aplikację, z właścicielem i datą usunięcia. Zarejestruj zmianę i warunki jej odwrócenia w tym samym miejscu, aby nieudana migracja nie zablokowała ludzi, którzy by ją naprawili.

Po przełączeniu łatanie, cykl życia kont, autoryzacja aplikacji i audyt nadal są Twoje. Tunel zawęził wejście; nie przejął żadnego z tych zadań.