Potrzeba zdalnego korzystania z zasobów sieci LAN bez narażania ich na niebezpieczeństwo to obecnie priorytet wielu działów IT. Paleta dostępnych architektur i rozwiązań jest całkiem spora.

U podstaw rozwiązań umożliwiających zdalny dostęp do firmowych sieci zwykle leżą dwie potrzeby: zdalne wykorzystanie aplikacji oraz wsparcie techniczne. Z punktu widzenia doboru rozwiązania różnica między nimi jest taka, że wsparcie techniczne zakłada połączenia sporadyczne, zdalne wykorzystywanie aplikacji zaś wymaga połączeń częstych, a niekiedy wręcz stałej łączności. Oprócz funkcjonalności, wybór systemu zdalnego dostępu wiąże się z rozważeniem kilku innych kwestii, m.in. bezpieczeństwa, wymagań co do pasma sieciowego, sposobu nawiązywania połączeń i wielu innych.

Halo, tu użytkownik

Jeszcze do niedawna najbardziej rozpowszechnioną metodą dostępu było wdzwanianie się do zdalnej sieci LAN za pośrednictwem modemu, a dokładnie prostego programu wykorzystującego modem zainstalowany bezpośrednio na serwerze. Połączenie jest łatwe do wykonania, a jednocześnie trudne do przełamania przez potencjalnego włamywacza - włamanie wymaga więcej wysiłku niż proste skanowanie sieci z Internetu, ponieważ konieczne jest przechwycenie numeru telefonu i hasła. Tak działały niemal wszystkie terminale znakowe łączące się z systemami Unix, a do tej pory można w ten sposób skonfigurować także np. pakiet Symantec PCAnywhere.

Obecnie model ten zastąpiono wdzwanianiem się do działającego na brzegu sieci LAN serwera dial-up. Użytkownik dzwoni pod pewien numer, a serwer wymaga od niego podania nazwy użytkownika i hasła. Dostęp do sieci jest przyznawany po prawidłowym uwierzytelnieniu, przy czym z reguły serwer dial-up lub współpracujący z nim serwer DHCP dynamicznie przydziela dzwoniącemu adres IP. Takie połączenie jest bardziej funkcjonalne, po jego ustanowieniu komputer pracuje tak, jakby był wpięty w sieć lokalną.

Z punktu widzenia bezpieczeństwa to, co jest największą zaletą dostępu dial-up, jest jednak jego największą wadą - podsłuchanie hasła lub posłużenie się programem-exploitem może otworzyć przed atakującym całą sieć lokalną. Wystarczy znaleźć choćby jeden niezabezpieczony komputer, by włamywacz mógł swobodnie buszować po całej domenie. Sieci, w których systemy stacji roboczych są systematycznie aktualizowane, to wciąż rzadkość ze względu na koszty i wysiłek, jaki się z tym wiąże.

W związku z powyższym najlepszym zabezpieczeniem dostępu dial-up wydaje się dwustopniowy mechanizm uwierzytelniania. Tokeny, hasła jednorazowe, np. popularne w środowisku systemów typu Unix programy otpw, opie czy nawet stary, dobry S/Key oparty na schemacie Lamport, znacznie podnoszą poziom bezpieczeństwa. Dodatkową formę zabezpieczenia zdalnego dostępu może stanowić konieczność ustanowienia połączenia zwrotnego (callback) na uprzednio ustalony numer. Utrudni to włamywaczom ustanowienie połączenia i ułatwi wykrycie ewentualnych prób włamania.

W poszukiwaniu architektury

Obie przedstawione techniki mają wspólną wadę - wymagają bezpośredniego połączenia modemowego klient-serwer, a to w przypadku dłuższych połączeń jest kosztowne. Alternatywą jest metoda polegająca na nawiązaniu w ten czy inny sposób połączenia z serwerem udostępnionym w publicznej sieci TCP/IP, a następnie za jego pośrednictwem łączeniu się z serwerami docelowymi bądź też uruchamianiu aplikacji wprost w jego środowisku. W praktyce takie rozwiązania przyjmują formę serwerów terminalowych, bramek terminujących kanały VPN lub innych rozwiązań, np. specjalnie skonfigurowanych serwerów aplikacyjnych. Również i tu w większości przypadków można (i raczej trzeba) stosować dodatkowe środki zabezpieczeń w postaci tokenów itp.

Kolejny przypadek to taki, w którym klient mający publiczny adres IP uruchamia oprogramowanie klienckie, a połączenie jest inicjowane wewnątrz firmy na adres IP zdalnego klienta. Wbrew pozorom to bardzo dobry pomysł na połączenie na potrzeby wsparcia technicznego. Takie połączenia można zastosować zwłaszcza w sieciach, które cechują się bardzo restrykcyjnymi regułami filtrowania połączeń przychodzących.

Trzeba jednak mieć na względzie, że korzystanie z publicznego adresu IP po stronie klienta samo w sobie stanowi zagrożenie - zawsze istnieje możliwość, że ktoś podszyje się pod uprawniony komputer. Występuje tu także podwyższone ryzyko ataków socjotechnicznych, co z kolei wymaga zabezpieczeń proceduralnych. Przede wszystkim jednak wymagane jest działanie osoby po stronie komputera docelowego potrzebne do nawiązania połączenia. To doskonałe rozwiązanie dla niskobudżetowego, okazjonalnego wsparcia technicznego w firmach z małymi oddziałami, w której nie ma stałych kanałów VPN. W dużej firmie, przy większej liczbie użytkowników i połączeń można to rozwiązać inaczej, ale o tym za chwilę.

Ze względu na to, że każda metoda połączenia ma pewne wady, wyjściem może być zastosowanie kilku metod łącznie. W najprostszym scenariuszu zestawia się połączenie TCP/IP poprzez bezpieczny kanał VPN - IPsec lub SSH. Bardziej skomplikowane podejście może polegać na zestawieniu wstępnego połączenia przez serwer terminalowy z uwierzytelnieniem przez token, a następnie uruchomieniu na nim klienta w trybie nasłuchiwania połączeń inicjowanych zdalnie w sieci LAN, np. przez docelową aplikację.

To ostatnie rozwiązanie sprawdza się szczególnie przy prowadzeniu scentralizowanego wsparcia technicznego dla wielu zdalnych lokalizacji. Często korzystam właśnie z niego, ponieważ łączy ono prostotę dla użytkownika (konieczną do wsparcia technicznego) z wydajnością transmisji w sieci WAN i bezpieczeństwem.

Jest jeszcze jedna możliwość. Klienta aplikacji uruchamia się w jednej sieci lokalnej, serwer - w innej. Połączenie jest nawiązywane za pośrednictwem brokera działającego w sieci publicznej. Obie strony odpowiedzialne za połączenie nie przyjmują połączeń zewnętrznych, zaś same inicjują połączenia tylko do brokera. Dokładnie na takiej zasadzie działa serwis GoToMyPC przejęty niedawno przez Citrix Systems. To rozwiązanie jest zarówno bezpieczne (uwierzytelnianie oparte na kluczach), jak i elastyczne z punktu widzenia użytkowników.