Zasady grupy NPS nie są egzekwowaniem zasobów VPN

Dwie grupy, dwa profile dostępu, jedna brama VPN, a na końcu obie grupy docierają do tych samych serwerów. Zwykłą przyczyną nie jest zepsuta polityka, lecz brakująca druga połowa projektu: NPS decyduje, kto może ustanowić sesję, a coś innego musi zdecydować, do czego ta sesja może dotrzeć. Gdy istnieje tylko pierwsza połowa, autoryzacja udaje się każdemu, kto się uwierzytelni. Polityka robi swoje, a projekt wciąż jest niekompletny.

Polityka sieciowa pasująca do grupy jest dowodem na dopuszczenie. Nie jest dowodem na pakiety, a luka między tymi dwoma stwierdzeniami to miejsce, w którym dzieje się większość tej pracy.

Znajdź politykę, która faktycznie dopuściła sesję

NPS ocenia uporządkowane polityki sieciowe i wygrywa pierwsza włączona reguła, której warunki pasują. Warunki mogą obejmować członkostwo w grupie użytkownika lub komputera, typ połączenia, czas i stan urządzenia. Dlatego szeroka polityka umieszczona wcześniej na liście dopuszcza połączenie, zanim węższa reguła niżej zostanie w ogóle rozważona. Kolejność nie jest szczegółem interfejsu; kolejność jest polityką.

Przeczytaj listę po kolei i wskaż tę, która pasowała, a następnie zapisz, jakie ustawienia zwróciła. Nazwa grupy w edytorze nie jest wynikiem; wynikiem jest autoryzacja, którą otrzymał serwer. Trzymaj autoryzację użytkownika i autoryzację urządzenia osobno tam, gdzie wdrożenie używa obu, bo konto, które może otworzyć tunel, nie jest automatycznie kontem, które powinno docierać do każdej usługi wewnętrznej.

Odpowiedź RADIUS jest instrukcją, nie filtrem

Atrybut Filter-Id niesie nazwę listy filtrów. Nie dostarcza przenośnego zestawu reguł filtrowania pakietów, który rozumiałby każdy odbiorca, a wysłanie nazwy, której brama nigdy nie zdefiniowała, nie egzekwuje zupełnie niczego. Ta sama ostrożność dotyczy atrybutów VLAN: przypisanie sesji tunelu do VLAN samo w sobie nie jest trasowaną regułą dostępu dla tego użytkownika.

Tu właśnie projekt, który po stronie NPS wygląda kompletnie, po cichu nie robi nic. Potwierdź w dokumentacji dostawcy bramy, które atrybuty autoryzacji są obsługiwane i co odbiorca robi z każdym z nich, zamiast zakładać, że standardowa nazwa atrybutu oznacza standardowe zachowanie.

Umieść egzekwowanie tam, gdzie przechodzi ruch

Brama, która przetwarza pakiety użytkownika, może zastosować filtr na sesję, zmapować grupę na politykę bramy albo dać sesji adres z odseparowanej puli, którą zapora traktuje inaczej. Każda z tych opcji może działać i każda zawodzi inaczej. Ustal, który mechanizm obsługuje twoja brama, zanim napiszesz politykę, która go nazywa. Potem zapisz, co dzieje się z sesją, gdy tego mechanizmu nie ma, bo cisza jest domyślnym stanem.

Opisz zamierzone uprawnienie w czterech częściach: tożsamość źródła lub grupa, cel, protokół i port. Dodaj zależności, których użytkownik naprawdę potrzebuje, na przykład DNS albo usługę uwierzytelniania, inaczej ograniczenie zepsuje przepływy logowania, których nikt nie pomyślał testować. Pisz regułę wobec interfejsu, który faktycznie filtruje, a nie wobec interfejsu, który przypadkiem jest otwarty w edytorze.

Weź pod uwagę także translację adresów. Jeśli zapora poniżej widzi jeden przetłumaczony adres źródłowy dla każdego użytkownika tunelu, nie może odróżnić osób wyłącznie po tym adresie, a reguła napisana tak, jakby mogła, będzie albo bezużyteczna, albo zbyt szeroka.

Profile klienta żyją po stronie niezaufanej

Zarządzany profil VPN może wypychać trasy, reguły tunelu dzielonego lub filtry aplikacji, a one kształtują zachowanie dobrze wychowanego urządzenia. Nie są ochroną usługi, bo klient jest stroną, którą próbujesz ograniczyć. Usunięcie trasy w profilu też nie jest autoryzacją, ponieważ klient może mieć inną drogę do tego samego celu.

Traktuj ustawienia klienta jako wygodę, a ustawienia bramy jako kontrolę. Gdy te dwie rzeczy się nie zgadzają, rację ma brama, bo to ona widzi pakiety.

Przyjmij za pomocą dwóch kont, a potem śledź po kolei

Utwórz dwa zwykłe konta testowe z różnymi zamierzonymi uprawnieniami, ustanów nowe sesje i sprawdź skuteczną politykę bramy dla każdego. Następnie przetestuj jedną nieszkodliwą dozwoloną operację i jeden konkretnie odmówiony zasób. Nieudany ping sam w sobie dowodzi bardzo niewiele, bo ICMP może być filtrowany, podczas gdy usługa TCP za nim chętnie odpowiada.

Gdy oba konta nadal mają szeroki dostęp, śledź w ustalonej kolejności: która polityka pasowała, jaką autoryzację niosła odpowiedź i co brama z nią zrobiła. Dodawanie kolejnych atrybutów NPS przed potwierdzeniem, że odbiorca je implementuje, to droga, na której mały problem z autoryzacją staje się oknem zmian bez rezultatu.