Czy nadal potrzebujesz VPN lokacyjnego, gdy aplikacja używa mTLS i SSO?
Przejdź kanały, których logowanie do aplikacji nigdy nie obejmuje, a potem zdecyduj, czy dostęp do sieci prywatnej jest zbędny, czy wciąż jest jedyną drogą do hosta.
Logujesz się przez mTLS, pulpit się wczytuje, a twierdzenie, że VPN lokacyjny jest teraz zbędny, brzmi rozsądnie mniej więcej do chwili, gdy o drugiej w nocy trzeba odtworzyć bazę danych. Granica TLS aplikacji opisuje tylko jeden kanał. Host, baza danych, cel kopii zapasowych i konto w chmurze mają każdy własną ścieżkę wejścia, własną tożsamość i własnego zatwierdzającego, i żaden z nich nie jest sprawdzany przez udane logowanie.
Idź na zewnątrz od ekranu logowania
Zaloguj się jak zwykły użytkownik i zapisz każdy krok, którego dotyka żądanie: przeglądarka, brzeg, nasłuch aplikacji, magazyn sesji, API backendu. Każdy krok ma właściciela i decyzję uwierzytelniającą. Teraz powtórz wędrówkę dla osoby, która łata hosta, i dla zadania, które zapisuje nocną kopię. Te wędrówki zwykle rozchodzą się już na pierwszym kroku.
To rozstanie jest pytaniem wartym odpowiedzi. VPN lokacyjny jest zbędny tylko wtedy, gdy każdy kanał tej drugiej wędrówki ma samodzielną politykę wejścia i autoryzacji.
Pięć kanałów, których logowanie do aplikacji nigdy nie obejmuje
Poniższa tabela to szablon inwentaryzacji, a nie lista kontrolna wdrożenia. Wypełnij drugą kolumnę tym, co twoje środowisko naprawdę egzekwuje dzisiaj.
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
Wspólny dostawca tożsamości nie łączy tych autoryzacji. Użytkownik, który może wysłać żądanie API, nie jest przez to uprawniony do wymiany dysku maszyny wirtualnej ani do odtworzenia bazy danych danymi aplikacji. NIST w podsumowaniu architektury zerowego zaufania właśnie z tego powodu trzyma uwierzytelnianie i autoryzację zasobów osobno od położenia w sieci.
Inżynier wsparcia, który potrafi przeczytać zgłoszenie, nie jest przez to uprawniony do otwarcia konsoli na hoście za nim.
Ścieżka jest prawdziwa tylko wtedy, gdy alternatywa pozostaje zamknięta
Ograniczenie osiągalności do prywatnych nasłuchów administracyjnych jest legalnym zamiennikiem VPN lokacyjnego, pod warunkiem że ograniczenie jest egzekwowane, a nie tylko narysowane. Typową porażką jest alternatywny nasłuch, o którym nikt nie pamiętał: usługa wciąż przypisana do wszystkich interfejsów, reguła grupy bezpieczeństwa otwarta dla wykonawcy, port zarządzania osiągalny z internetu.
Sprawdzaj nasłuchy, a nie diagramy. Na hoście wylistuj, co jest naprawdę przypisane, za pomocą ss -ltnp, i potwierdź, że porty administracyjne siedzą na prywatnym adresie. W konsoli chmury przeczytaj reguły przychodzące dla podsieci obciążenia i poszukaj 0.0.0.0/0 na czymkolwiek administracyjnym. Potem spróbuj połączenia spoza prywatnej ścieżki, bo właśnie ten test odpowiada na pytanie.
Jedna jedyna reguła otwarta na świat na SSH niweczy każdy argument projektu tunelu.
Napisz mapę, zanim porównasz projekty
Dla każdego wiersza inwentaryzacji zapisz, kto zatwierdza tożsamości, kto aktualizuje reguły dostępu, kto usuwa dane uwierzytelniające, gdy ktoś odchodzi, i kto zajmuje się odtworzeniem, gdy sama ścieżka się psuje. Cztery nazwiska na wiersz wystarczą, by ujawnić wiersze, w których odpowiedzią jest wspólne konto i strona wiki sprzed trzech lat.
Następnie zweryfikuj jedno zezwolenie i jedno odmowę na każdy kanał. Zezwolenie dowodzi, że zamierzona tożsamość może dotrzeć do zasobu zamierzoną ścieżką. Odmowa dowodzi, że podobna tożsamość nie może, i właśnie ten test ludzie pomijają, dlatego alternatywne nasłuchy przeżywają audyty. Porównaj proponowany projekt z tymi wynikami, a nie z konfiguracją TLS aplikacji, która nigdy nie sprawdziła żadnego z nich.
Gdzie VPN lokacyjny nadal zarabia na swoje miejsce
Tunel lub wąska brama to właściwa odpowiedź, gdy zasób nie ma własnego uwierzytelniania na żądanie: porty konserwacji baz danych, cele kopii zapasowych, konsole hiperwizora, zarządzanie poza pasmem. Te nasłuchy ufają sieci, więc to sieć musi uwierzytelniać wywołującego.
To nie jedyna odpowiedź. Brama, która kończy autoryzację dla każdego zasobu, może być węższa niż tunel na całą podsieć i zostawia lepszy ślad audytowy niż wspólny host przeskoku.
Kolejność pracy: ukończ inwentaryzację, zamknij alternatywy, zweryfikuj jedną odmowę na wiersz i dopiero potem wycofaj tunel. Jeśli wiersz nie potrafi wytworzyć odmowy, utrzymuj prywatną ścieżkę, aż będzie potrafił.