Strona administracyjna NAS działa w domu i przestaje działać w chwili, gdy administrator wyjeżdża, więc ktoś otwiera port i problem znika razem z prywatnością. Istnieje na to lepsza forma. Zostaw stronę tam, gdzie jest, pozwól tunelowi zapewnić osiągalność, a to, co dokumentujesz, zrób pełnym URL-em z nazwaną ścieżką uprawnień, a nie adresem urządzenia, które przypadkiem odpowiada. Każda decyzja poniżej, od nazwy przez certyfikat po jedyny dozwolony port, wynika z takiego zapisu.

Jednostką projektu jest URL, a nie adres

Zapisz wejście jako pełny URL z jego portem i schematem, a następnie dołącz warunki: kto może go używać, z której sieci i którą ścieżką. Przykładem może być https://nas.corp.example:8443 publikowany tylko dla zatwierdzonych klientów prywatnych, gdzie nazwa i port zastępują to, czego urządzenie faktycznie słucha.

Ta rama wymusza decyzje wcześnie. URL implikuje nazwę, nazwa implikuje certyfikat, a certyfikat implikuje układ zaufania. Adres nie implikuje niczego z tego i właśnie dlatego wersja tylko z adresem przetrwa do pierwszego ostrzeżenia przeglądarki, a potem staje się nawykiem klikania przez nie.

Entry pointWhat it costsWhen it fits
Private name over the tunnelA private DNS zone and a certificate for that nameAdministrators who already hold VPN access
Public reverse proxyAn exposed front end to patch and monitorA documented, reviewed need for public reach
Vendor relay serviceTrust in a third party pathA supported product design, not a workaround

Zachowaj nazwę, dla której wydano certyfikat

Klient potrzebuje dozwolonej trasy do prywatnego adresu NAS, a prywatny układ DNS może rozwiązać zamierzoną nazwę hosta na ten adres, zachowując przy tym nazwę oczekiwaną przez usługę HTTPS. Obie połowy się liczą: trasa dostarcza pakiety na miejsce, nazwa mówi klientowi, którą tożsamość zweryfikować.

Wpisanie zamiast tego adresu numerycznego zmienia wymaganie tożsamości. RFC 9525 oddziela nazwę, z którą klient zamierza się połączyć, od tożsamości przedstawianej przez usługę, więc certyfikat wydany dla nas.corp.example może zasadnie zawieść, gdy przeglądarka została skierowana na 10.20.0.15. Ostrzeżenie jest słuszne, a rozwiązaniem jest nazwa, nie wyjątek.

dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.example

Uruchom oba, zanim obwinisz tunel. Pierwsze pokazuje, czy prywatna nazwa rozwiązuje się tam, gdzie myślisz, a drugie pokazuje, jaki certyfikat i jakie alternatywne nazwy podmiotu usługa faktycznie przedstawia. Prywatny CA może być całkowicie dobrze zarządzanym wyborem; rutyną nie powinno się stawać uczenie ludzi odrzucania ostrzeżeń o tożsamości.

Ogranicz ścieżkę zarządzania

Zezwól dokładnie usłudze zarządzającej z zamierzonego źródła, zarówno na bramie, jak i na NAS. To zdanie ukrywa szczegół, który gryzie: pula klientów trasowanych i brama z tłumaczeniem źródła docierają do NAS z różnymi adresami źródłowymi, więc reguła zezwolenia napisana dla jednej po cichu zawodzi dla drugiej.

NAS potrzebuje też ścieżki powrotnej, a przeglądarka musi użyć skonfigurowanego portu i schematu, a nie domyślnej wartości producenta z postu na forum. Dotarcie do urządzenia nie jest pozwoleniem na dotarcie do każdego jego portu. Różnica między urządzeniem, które odpowiada na ping, a stroną administracyjną, która się ładuje, to różnica między dwiema osobnymi regułami. Zapisz je jako dwie reguły z dwoma komentarzami, żeby następna osoba widziała, dlaczego istnieją obie.

Oddziel wpuszczenie do VPN od uprawnień NAS

Wpuszczenie przez tunel to nie to samo co pozwolenie na zarządzanie urządzeniem. Użytkownik, który legalnie potrzebuje pamięci plików, nie powinien dziedziczyć administracji urządzeniem tylko dlatego, że oba mieszkają za jedną bramą, a model kont NAS jest miejscem, w którym to oddzielenie musi być egzekwowane.

Wspólny lub przetłumaczony adres wyjściowy też nie może zidentyfikować pojedynczego administratora. Jeśli ślad audytu ma wskazać osobę, tożsamość musi pochodzić z uwierzytelnionego konta, a nie z adresu źródłowego tunelu, z którego korzysta wiele osób.

Czego nie publikować przez przypadek

Publiczny odwrotny proxy i przekaźnik producenta to obie prawdziwe architektury i każda niesie własne decyzje o zaufaniu i ekspozycji. Żadna nie staje się konieczna dlatego, że administrator jest poza domem, i żadna nie powinna pojawiać się jako skutek uboczny wystawienia serwera multimediów lub udostępniania plików.

Udokumentuj cztery rzeczy i przestań: prywatną nazwę, listener, na który jest mapowana, grupę uprawnioną do korzystania z niej oraz ścieżkę odzyskiwania, jeśli tunel jest niedostępny. Te cztery odpowiadają też na pytania, które zada przegląd incydentu, czego nie można powiedzieć o zrzucie ekranu strony przekierowania portów. W efekcie masz jeden stabilny administracyjny punkt wejścia, a nie urządzenie, którego każda funkcja patrzy w internet.

Powiązane artykuły