W firmowym Wi-Fi, a mimo to proszą o VPN? Oto dlaczego

Laptop jest w firmowym SSID, monit o certyfikat został zaakceptowany, a aplikacja webowa nadal prosi o VPN. Wygląda to na podwójną pracę i czasami nią jest. Oba logowania zwykle egzekwują różne decyzje, a jedynym sposobem, by sprawdzić, czy drugie zasługuje na swoje miejsce, jest zapytanie, co zmienia.

Dołączenie do sieci to decyzja o dopuszczeniu

Wdrożenie 802.1X odpowiada na jedno pytanie: czy to urządzenie lub użytkownik może podłączyć się do tej sieci? Punkt dostępowy przekazuje dane uwierzytelniające do serwera RADIUS, a odpowiedź może nieść atrybuty, które umieszczają sesję w określonym VLAN albo stosują filtr. To dopuszczenie i segmentacja, a nie autoryzacja dla konkretnej aplikacji.

Gdy sesja zostanie dopuszczona, łącze bezprzewodowe jest szyfrowane między klientem a punktem dostępowym. Ochrona kończy się tam, na skraju sieci przewodowej.

Wszystko poza tym punktem to zwykłe trasowanie wewnątrz budynku, z tą wewnętrzną osiągalnością, na jaką pozwala segment.

Co naprawdę chroni EAP-TTLS

EAP-TTLS buduje tunel TLS podczas uwierzytelniania i uruchamia w nim metodę wewnętrzną. Metodą wewnętrzną jest często PAP, a jej obecność w projekcie nie oznacza, że hasło przechodzi przez powietrze jako czysty tekst, bo to tunel TLS je przenosi. Klient nadal musi zweryfikować tożsamość serwera i zaufać właściwemu CA, a znany SSID nie jest tą weryfikacją. Wybór metody wewnętrznej czytaj jako format danych uwierzytelniających, nie jako twierdzenie o zewnętrznym szyfrowaniu.

To wymiana uwierzytelniająca, a nie tunel danych dla późniejszego ruchu laptopa.

Gdy uwierzytelnianie się kończy, tunel TLS znika, a pakiety klienta wędrują przez dopuszczony segment. Mylenie tych dwóch rzeczy jest korzeniem przekonania, że szyfrowanie Wi-Fi już wykonuje pracę VPN.

VPN to druga, węższa decyzja

VPN odpowiada na inne pytanie: do jakich prywatnych zasobów ta tożsamość może dotrzeć i na jakich warunkach? Kończy się na bramie z własną polityką, własnymi kontrolami tożsamości i często własnymi wymaganiami dotyczącymi stanu urządzenia. Osiągalny zbiór po podniesieniu tunelu jest zwykle mniejszy niż wewnętrzna sieć budynku i właściwy dla roli.

Dlatego rola serwisowa może zostać dopuszczona do Wi-Fi jak wszyscy inni, a mimo to potrzebować tunelu, by dotrzeć do podsieci zarządzania. Decyzja o Wi-Fi została podjęta w punkcie dostępowym; ta jest podejmowana na bramie.

Oba etapy mogą być szyfrowane i nadal egzekwować niepowiązane polityki.

Gdzie załamuje się zaufanie oparte na lokalizacji

Traktowanie sieci biurowej jako domyślnie zaufanej zawodzi z prostego powodu: lokalizacja w sieci jest właściwością połączenia, a nie osoby. Wytyczne NIST dotyczące zerowego zaufania mówią to wprost, i dlatego dostęp do zasobów jest rozstrzygany na żądanie, a nie na budynek. Kto dołącza do tego samego SSID, dziedziczy tę samą lokalizację. Dlatego też przejęty laptop w sieci pracowników zasługuje na taką samą nieufność jak ten w sieci gości.

Praktyczną konsekwencją jest to, że autoryzacja aplikacji nadal musi istnieć. VPN, który daje całą podsieć, plus aplikacja, która ufa każdemu żądaniu z tej podsieci, dzieli jedno poświadczenie od złego dnia.

Żadna z warstw nie zastępuje drugiej, ponieważ odpowiadają na pytania w różnych zakresach.

Jak sprawdzić, czy drugie logowanie zasługuje na swoje miejsce

Zapytaj właściciela sieci o dwie rzeczy: co staje się osiągalne po połączeniu VPN i jakie warunki tożsamości lub urządzenia są sprawdzane, by na to pozwolić? Następnie zweryfikuj odpowiedzi, testując, co rzeczywiście odpowiada. Jeśli tunel nie zmienia ani osiągalności, ani gwarancji, może to być nawyk operacyjny, a nie kontrola, i to decyzja właściciela, a nie coś, co użytkownik powinien obchodzić.

Szukaj też niezamierzonych bezpośrednich ścieżek, bo zasób osiągalny bez tunelu czyni tunel dekoracyjnym.

Udokumentuj każdą granicę i jej cel, a następna osoba nie będzie musiała zgadywać, dlaczego są dwa logowania.