Bezpieczny dostęp przez VPN cz. 2

Hard czy soft?

Bez względu na technologię, producenci dostarczają swoje rozwiązania w dwojakiej formie: appliance albo samego oprogramowania. Te pierwsze to często zwykły serwer Dell, HP czy IBM z innym logo, np. Secure Computing. Czasami zdarza się, że dostawcy przygotowują własne rozwiązania sprzętowe, np. SonicWall, Juniper, Nortel. Niektórzy zawierają również porozumienia z producentami specjalistycznych urządzeń, jednocześnie dając możliwość instalacji oprogramowania na standardowych maszynach - tak na przykład postępuje Check Point, podpisując partnerskie umowy z Crossbeam i Nokią. Przy wyborze rozwiązania warto brać pod uwagę wiele kryteriów - nie tylko tryb połączenia, ale także skalę. Coraz rzadziej - szczególnie w średnich lub małych firmach - stosuje się dedykowane rozwiązania VPN. Tutaj królują wszelkiego rodzaju UTM-y, które w zależności od producenta umożliwiają zestawianie zarówno kanałów IPSec, jak i SSL/TLS. Nie mogą się one równać ani wydajnością, ani bogactwem funkcji z bramami, ale pozwalają dosłownie w 5 minut zapewnić zdalny dostęp pracownikom czy połączenie z partnerem handlowym.

Czy zmienić IPSec na SSL?

Bezpieczny dostęp przez VPN cz. 2

Zestawianie sesji w SSL/TLS

Odpowiedź na to pytanie nie jest prosta. Można śmiało powiedzieć, że IPSec zdecydowanie lepiej sprawdzi się w przypadku połączeń site-to-site i kropka. Przez lata ten zestaw protokołów wykorzystywany był również w połączeniach client-to-site. Zgodnie ze starą zasadą administratorów - "jeżeli coś działa, to po co to zmieniać", można w dalszym ciągu używać IPSeca do tego typu łączności, ale raczej przy niewielkiej liczbie użytkowników. Jeżeli jedynymi użytkownikami zdalnymi są osoby odpowiedzialne za utrzymanie dostępności usług, to IPSec sprawdzi się nieźle. Problemy pojawiają się, gdy o dostęp zaczynają dopominać się zwykli użytkownicy. Wówczas nakład administracyjny potrzebny, po pierwsze, na konfigurację, po drugie, na bieżące utrzymanie infrastruktury sprawia, że przejście na SSL zaczyna mieć sens. Na przykład handlowcy muszą czasami dostać się do zasobów korporacji nie mając ze sobą komputera, a trudno sobie wyobrazić instalację agenta IPSec na komputerze w kawiarni internetowej. Z łączeniem się z rozmaitych lokalizacji wiążą się jeszcze inne problemy, np. pokrywanie się adresacji, blokada portów niezbędnych do zestawienia tunelu, NAT…

Trzy scenariusze realizacji klasycznego SSL VPN

1. Użytkownik łączy się z określoną stroną webową wystawiającą portal dostępowy, uwierzytelnia się i na tej podstawie uzyskuje autoryzację do poszczególnych zasobów. Są one więc dostępne bezpośrednio z poziomu przeglądarki. Najczęściej w ten sposób udostępniane są aplikacje webowe (np. CRM), poczta web mailowa czy baza dokumentów. Jest to najmniej wymagający scenariusz - choć dużo zależy od samych aplikacji. Użytkownik nie musi mieć na stacji żadnych rozszerzonych uprawnień. Jedyne, czego potrzebuje to przeglądarka internetowa. Jednak nie wszystkie zasoby dostępne są za pomocą mechanizmów webowych, np. udziały sieciowe. Wówczas SSL VPN działa jako translator (tzw. application translator), przekształcając natywny protokół aplikacji na taki, który może być przeczytany przez przeglądarkę. SSL VPN pracujący w tym trybie to możliwość zabezpieczenia ruchu HTTP przez dodanie ochrony w postaci protokołu SSL lub TLS w warstwie transportowej. To z kolei pozwala na zaszycie informacji, które spływają z warstw wyższych - także z warstwy 7. Problemów związanych z tym trybem jest kilka. Najpoważniejszym jest jednak to, że brama VPN musi "przepisać" aplikacje - działa jak proxy między nimi a klientem. To sprawia, że aplikacje webowe o bardziej złożonej budowie, zawierające np. JavaScript, dodatkowe kontrolki czy inną zawartość aktywną - mogą nie dać się łatwo przepisać. Niektóre rozwiązania w ogóle sobie z nimi nie radzą.

2. Użytkownik łączy się ze stroną webową tak, jak w pierwszym przypadku, ale tylko po to, żeby się uwierzytelnić. Następnie ze strony zostaje pobrany dodatek (w zależności od możliwości przeglądarki) lub aplet Javy albo kontrolka ActiveX. Dodatek ten umożliwia nawiązanie połączenia z koncentratorem VPN i uzyskanie łączności IP (klient otrzymuje własny adres IP). Dzięki temu możliwe jest połączenie z aplikacjami czy zasobami, które nie mogą być udostępnione przez przeglądarkę. Ochrona jest tutaj realizowana w warstwie sieci. Ten tryb jest zatem bardzo zbliżony do tradycyjnych VPN-ów, wymagających po stronie klienta instalacji odpowiedniego oprogramowania. Istnieją jednak pewne różnice. Po pierwsze, w przypadku SSL VPN instalacja jest prosta, a rozwiązanie z punktu widzenia użytkownika bezobsługowe. Po drugie, budowa samego tunelu jest jednak inna. Podobnie jak rozwiązania IPSec, także te oparte na SSL-u potrafią rozpoznawać ruch i kierować ten, który odnosi się do zasobów korporacyjnych przez tunel, a pozostały (np. przeglądanie stron) - wypuszczać standardowym łączem (tzw. Split tunneling). Tryb ten stawia pewne wymogi wobec stacji roboczej, z której nawiązywane jest połączenie, np. przeglądarka musi zezwalać na uruchamianie apletów czy kontrolek. Po zakończeniu połączenia klient może zostać automatycznie zdeinstalowany.

3. I wreszcie hybryda, będąca połączeniem scenariuszy nr 1 i 2. W tym przypadku użytkownik znowu łączy się z portalem, który oferuje jednak nieco większe możliwości w stosunku do wariantu nr 1. W zależności od zasobów, z którymi chciałby się połączyć, dostaje się do nich albo bezpośrednio (przez portal), albo instalowany jest dodatek realizujący łączność na poziomie sieci w przypadku aplikacji niewebowych, a nawet wystawiana sama aplikacja, którą użytkownik może sobie uruchomić niemal bezpośrednio z koncentratora. Wariacji na temat tych trzech scenariuszy jest jeszcze kilka, ale te wymienione są najpopularniejsze.


TOP 200