Dostęp z VPN do VLAN: najpierw matryca, potem reguły
Role po jednej stronie, usługi po drugiej. Pięć kontroli zamienia mglisty projekt dostępu z VPN do VLAN w tabelę, którą właściciel firewalla może wdrożyć.
Zacznij od matrycy, a nie od składni firewalla. Tabelę z rolami po jednej stronie i usługami po drugiej może przejrzeć właściciel aplikacji, przedyskutować właściciel bezpieczeństwa i wdrożyć ten, kto trzyma bramę. Ten przegląd jest tańszy niż debugowanie reguł, co do których nikt się nie dogadał.
Godzina pisania oszczędza później tydzień archeologii reguł. Projekt mówi o tym, kto dociera do jakiej usługi, i właśnie ta część przeżywa przenumerowanie.
Krok 1: nazwij role przed sieciami
Zacznij od ludzi, a nie od przełącznika. Zapisz każdą grupę, która łączy się zdalnie, oraz jedno zdanie opisujące, co ta grupa robi, na przykład pracownicy magazynu czytający stany magazynowe albo wykonawca utrzymujący jedną integrację. Jeśli dwie grupy dostałyby identyczny dostęp, dla tego celu są jedną rolą.
Zatrzymaj się tutaj, jeśli rola istnieje tylko z powodu schematu organizacyjnego. Rola bez własnej potrzeby usługowej staje się wierszem identycznych komórek, a identyczne wiersze zachęcają kogoś, by później dla wygody przydzielił całą podsieć. Dziel według tego, co ludzie robią, a nie według tego, kto podpisuje ich wydatki. Sześć ról to zwykle za dużo dla małego biura, a trzy często są właściwe.
Krok 2: zamień każdą komórkę w deklarację usługi
Komórka z napisem „Aplikacje” nie jest weryfikowalna. Komórka z napisem „HTTPS do hosta ERP na 443, z puli pracowników” jest. Zastąp każdą nazwę sieci miejscem docelowym, protokołem i portem, a następnie dodaj zależność, bez której usługa nie działa, na przykład wewnętrzny resolver lub dostawcę tożsamości.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
Kolumna kierunku łapie najdroższe błędy. Zezwolenie pracownikom na otwarcie aplikacji nie oznacza zezwolenia serwerom aplikacji na otwieranie połączeń z powrotem do laptopów pracowników, a reguła stanowa zezwalająca na pierwszy kierunek bywa czytana tak, jakby zezwalała na drugi.
Krok 3: zdecyduj, gdzie tożsamość staje się polityką
Ktoś musi zamienić uwierzytelnioną sesję w rolę, którą brama może wyegzekwować. Obsługiwane opcje obejmują politykę grupową dostarczaną przez backend uwierzytelniania, zaufane atrybuty sesji lub osobne pule adresów dla każdej roli. Wszystkie trzy działają; etykieta wysyłana przez klienta nie. Wybierz mechanizm, który dokumentuje twoja brama, a nie ten, który opisuje wpis na forum.
Przydzielenie adresu, który tylko wygląda, jakby należał do VLAN, to ta sama nie-odpowiedź w innym kostiumie. Przewodnik Netgate po regułach firewalla OpenVPN jasno pokazuje rozdzielenie: pozwolenie, by tunel się podniósł, to inna decyzja niż pozwolenie, by ruch przez niego przeszedł.
Zapisz, który mechanizm wybrałeś i gdzie jest skonfigurowany. Gdy rola się zmienia, ta notatka to różnica między jedną edycją a polowaniem przez trzy interfejsy. Mówi też audytorowi, gdzie patrzeć najpierw.
Krok 4: obserwuj adres źródłowy, który widzi cel
Polityka przekazywania musi odpowiadać rzeczywistemu źródłu na granicy. Jeśli brama tłumaczy klientów VPN na własny adres, każdy firewall poniżej widzi jedno źródło i traci możliwość decydowania według roli. Jeśli zachowuje adres klienta, ścieżka powrotna musi istnieć dla tej puli.
Przetestuj oba kierunki, zanim napiszesz ostateczne reguły, a potem zapisz zaobserwowane źródło przy każdej komórce. Uruchom tę samą kontrolę z dwóch różnych ról i porównaj wynik. Jeśli obie pokazują adres bramy, rozróżnienie ról już przepadło. Matryca, która zakłada zachowane adresy, gdy brama wykonuje translację źródła, zawodzi na pierwszej niższej ACL.
Krok 5: przetestuj każdą komórkę przed wydaniem
Zamień każdą dozwoloną komórkę w jedną reprezentatywną operację, a każdą odrzuconą komórkę w przypadek negatywny. Uruchom oba z klienta w rzeczywistej roli, a nie z konsoli bramy, bo konsola omija ścieżkę, którą testujesz.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'Przypadek negatywny, który się łączy, jest ustaleniem, a nie przypadkiem, i jego miejsce jest w matrycy jako komórka, która zawiodła, dopóki reguła nie zostanie poprawiona. Trzymaj polecenia testowe obok tabeli, żeby następny recenzent uruchomił je ponownie zamiast odbudowywać rozumowanie.
Gotowa tabela żyje dłużej niż brama, dla której została napisana. Reguły zmieniają się wraz z firmware i dostawcą, a wiersz mówiący, że wykonawca dociera do jednej usługi projektowej, pozostaje prawdziwy, dopóki ta praca się nie zmieni.