Podkast 22T30 VPN – Które Rozwiązanie Wybrać?

Więcej miejsc do posłuchania:

Spotify

WERSJA TEKSTOWA

Cześć, witam Cię w dzisiejszym odcinku mojego podkastu. Dzisiejszy temat to jak skonfigurować dostęp zdalny po VPN-ie w najłatwiejszy sposób. Najkrótsza odpowiedź na to pytanie to najlepiej wybrać rozwiązanie, które jest dla Ciebie najbardziej znane. Jeżeli konfigurowałeś CISCO, skonfiguruj VPN w oparciu o CISCO. Jeżeli znasz Fortineta to konfiguruj w oparciu o Fortineta. Jeżeli Pulse Secure czy Arubę, to konfiguruj jak potrzebujesz.

Są jeszcze, można powiedzieć, dwa typy podejścia do VPN-a, czyli albo płatne albo open source. Open source, czyli najbardziej popularny dzisiaj OpenVPN. Jest to dostęp najczęściej realizowany w oparciu o OpenSSL, dla małych instalacji, nie wymagających dużej wydajności, do skonfigurowania bez jakiegoś większego problemu. Mogę Ci wskazać takie dwa manuale jak to zrobić, jeśli chcesz to zrobić w swoim małym środowisku, bez dodatkowych kosztów.

Druga opcja są to rozwiązania płatne. Kto instaluje rozwiązania płatne i dlaczego? Pierwszy podstawowy powód, dla którego instalujemy rozwiązania płatne to jest przede wszystkim support, czyli możliwość odniesienia się do kogoś, kto zna to rozwiązanie, jeśli nastąpi problem. Drugi typowy powód to jest skalowalność. Jeżeli mamy tych użytkowników dużo, to raczej wybieramy rozwiązanie, które ma odpowiednią wydajność sprzętową.

Większość dzisiejszych rozwiązań tak czy inaczej opiera się o rozwiązania serwerowe. W związku z tym czy to będzie wirtualny appliance czy fizyczny, tam najczęściej pod spodem jest jakaś wersja serwera. W przypadku dostępu zdalnego jest jeszcze tutaj taki element do omówienia jak uwierzytelnianie. Gdy mówimy o VPN-ach to najczęściej mamy na myśli IPsec. To jest najbardziej powszechnie stosowany protokół dostępu. Ale IPsec w swojej wersji podstawowej, czyli IKEv1 nie umożliwia uwierzytelniania użytkowników sam z siebie. Nadaje się dobrze do takich sytuacji, gdzie mamy dwie lokalizacje, dwie serwerownie lub lokalizację zdalną i chcemy administracyjnie spiąć taką infrastrukturę w jeden byt, czyli mamy tunele IPsec pospinane ze sobą. Na to najczęściej jest jeszcze nałożona jakaś adresacja i polityka kierowania ruchem. Jest to podstawa, z której IPsec się wywodzi. Jego cały schemat działania był oparty na takim scenariuszu.

W przypadku dostępu zdalnego pracowników, czyli to co najczęściej się dzisiaj pojawia w kontekście VPN-ów, to mówimy o potrzebie nadania użytkownikowi jakiegoś loginu i hasła. Oczywiście alternatywą do dostępu jest uwierzytelnianie w inny sposób. Mamy tu też całą gamę możliwości: zewnętrzne systemy SSO, MFA, uwierzytelnianie przez certyfikaty, mamy różne możliwości. Ważne jest to, że musimy w jakiś sposób tego użytkownika podłączyć, rozróżnić, powiedzieć, że to jest Kowalski a to jest jakiś inny użytkownik, przypisać mu jakiś poziom dostępu, politykę, do czego ma mieć dostęp, do czego nie ma mieć dostępu i zrobić to wg najlepszych praktyk. Tj. monitorować dane rozwiązanie na bieżąco i szukać ewentualnych anomalii w zachowaniu. Oczywiście jeśli chcemy podwyższać tą poprzeczkę, co my oczekujemy od dostępu zdalnego i od rozwiązań VPN-owych. Idziemy w stronę rozwiązań komercyjnych za które trzeba zapłacić. Jeśli chcemy zainstalować taki bardzo podstawowy zakres funkcjonalny dostępu zdalnego i najczęściej jeszcze manualnie nim zarządzać – tu mam na myśli głównie tego OpenVPN-a, którego najczęściej realizujemy w oparciu o certyfikaty, ale tymi certyfikatami musimy jakoś ręcznie zarządzać – musimy je generować, musimy odświeżać. Jest tam lista CRL-owa, gdy chcemy jej użyć, a powinniśmy, to też trzeba ją odświeżać, więc tutaj trochę takich czynności manualnych, które administrator wtedy bierze na siebie. Musi sam sobie je zaplanować i cyklicznie je wykonywać.

W przypadku rozwiązań komercyjnych, są one najczęściej bardziej zautomatyzowane. Są dostępne automatyczne scenariusze onboardowania użytkownika, czyli tego pierwszego kroku jak użytkownik ma się podłączyć. Jeżeli mamy nowego pracownika, mamy nasz system VPN-owy już skonfigurowany, to ten użytkownik powinien tylko dostać odpowiedni adres, najczęściej adres https i tam zalogować się swoim loginem i hasłem domenowym. Jeśli ten proces jest odpowiednio przygotowany to w tym momencie wystarczy, że kliknie odpowiednią ikonę i zacznie mu się instalować klient końcowy razem z profilem podłączenia VPN-owego. Gdy do tego chcemy podwyższyć poziom bezpieczeństwa, to oczywiście możemy dodatkowe rzeczy sprawdzać. Np. Host Checker jest możliwy do włączenia, czyli możemy wtedy sprawdzać, czy mamy aktualne patche na stacji końcowej. Czy spełnia ta stacja końcowa naszą politykę bezpieczeństwa. Tu już mówimy o podnoszeniu poziomu bezpieczeństwa, czyli podnoszeniu tej poprzeczki naszych oczekiwań do parametrów funkcjonalnych rozwiązania VPN-owego.

Jeżeli chodzi o tą automatyzację, to użytkownik, który zainstaluje sobie w tym automatycznym procesie klienta i profil, ma możliwość podłączenia się od razu do naszych zasobów VPN-owych i zgodnie ze swoją funkcją, ze swoim przypisaniem najczęściej w AD, ma dostęp do poszczególnych zasobów. Tak to powinno wyglądać, bo jeśli wyobrazisz sobie, że mamy tych użytkowników 2000 to nie ma możliwości ręcznego zarządzania takim schematem postępu VPN-owego, gdy mamy ograniczone zasoby a zasoby administratora są zawsze ograniczone. Nie ma takiej możliwości, żeby można było wszystko robić ręcznie, raczej się przechodzi w stronę automatycznej implementacji i zarządzania.

Tutaj się oczywiście pojawia jeszcze taki wątek: co się ma wydarzyć, jeżeli dany użytkownik nam zgłasza problem. Czyli nam ten VPN nie działa albo nie działa w takim zakresie w jakim powinien. Jakie mamy narzędzia do troubleshotingu, czyli do szukania różnych źródeł problemu i jeżeli mamy taką skalę, że podłączamy pięciu, dziesięciu użytkowników to prawdopodobnie ten OpenVPN i sprawdzanie logów zupełnie nam wystarczy, bo nam zgłosi ten jeden użytkownik raz na pół roku, raz na rok, raz na dwa lata jakiś problem. Natomiast jak już mamy skalę 2000 użytkowników, 10 000 użytkowników, to już te możliwości różnych problemów się mnożą i możesz oczekiwać, że tych zgłoszeń będzie bez wątpienia więcej. Z doświadczenia powiem, że najwięcej tych problemów wynika z różnych zagadnień stacji końcowej, ewentualnie z różnych zachowań użytkowników końcowych i z różnego poziomu ich wiedzy. W związku z tym, jeśli szukasz rozwiązania typowo takiego małego, np tylko dostępu administracyjnego albo tylko do małej firmy to open source jak najbardziej. Jeżeli szukasz rozwiązania dla większej firmy, dla większej ilości użytkowników, o większej wydajności lub podnosisz tą poprzeczkę funkcjonalną wyżej, to wtedy raczej należy rozpatrzeć rozwiązania komercyjne. Na dzisiaj to tyle. Dziękuje Ci za uwagę i do usłyszenia już za tydzień.


Autor: Darek Koralewski

Od początku swojej kariery, czyli od 2004 roku, zajmuję się sieciami komputerowymi ze szczególnym uwzględnieniem ich bezpieczeństwa oraz sieciami programowalnymi. Mam na swoim koncie całą listę certyfikatów różnych producentów, dwa najważniejsze to te poświadczające najwyższy poziom wiedzy eksperckiej z zakresu rozwiązań Aruba ClearPass ACCX#901 oraz z projektowania sieci opartych o rozwiązania Aruba ACDX#1255. Więcej informacji możesz znaleźć na moich portalach społecznościowych.