Wsparcie zdalne przy pełnym rozproszeniu…

Use case #2 – wsparcie użytkownika pracującego zdalnie przez serwisanta również pracującego zdalnie.

Wyzwanie: jak udzielać wsparcia użytkownikom gdy zarówno wspierany, jak i wspierający pracują zdalnie? Jak zadbać o bezpieczeństwo i rozliczalność tego procesu?

Opisywałem dwa dni temu specyficzną sytuację, w której pracownicy oddelegowani do pracy z domów, łączyli się z prywatnych urządzeń, do komputerów pozostawionych w biurze. Rozwiązanie jednego problemu (jak bezpiecznie zestawić takie połączenie) rodzi kolejne. Między innymi, jak świadczyć wsparcie dla takiego pracownika? Ale, żeby nie operować tak szczególnym przypadkiem, zadałem sobie pytanie bardziej ogólne – jak świadczyć support użytkowników, kiedy wszyscy ci użytkownicy są rozproszeni, ale także gdy operatorzy Service Desk pracują zdalnie.

Standardowe rozwiązania tego problemu są najczęściej dwa. Pierwszy zakłada (ponownie) otwarcie tuneli VPN dla wszystkich – zarówno wspieranych, jak również wspierających. A następnie, wykorzystując narzędzia działające w sieci lokalnej (np. pulpit zdalny) rozwiązywać problemy użytkowników, które zgłaszają w systemie ITSM. Alternatywnie – gdy użytkownicy nie mogą zostać przyłączeni do sieci korporacyjnej, konieczne jest użycie narzędzi opartych o chmurę – czyli na przykład popularnego TeamViewera, czy też Skype.

Funkcjonalnie, obydwa rozwiązania spełnią pokładane w nich oczekiwania. Operator Service Desk będzie mógł wykonać swoją pracę, a pracownik zostanie obsłużony i jego problem zostanie rozwiązany. Pytanie, czy z perspektywy bezpieczeństwa procesów supportowych, wykorzystanie takich narzędzi jest zasadne? Wstęp do tego zagadnienia zrobiłem już w pierwszej mojej publikacji. Dziś chciałbym wejść nieco głębiej w mechanizmy świadczenia wsparcia dla użytkowników bardziej „korporacyjnie” niż tylko „doraźnie”.

Swój tekst oprę ponownie o rozwiązanie BeyondTrust, a konkretnie o produkt o nazwie Remote Support (producent uwielbia zawierać w nazwach swoich systemów ich przeznaczenie). Jest to system do wsparcia zdalnego użytkowników klasy enterprise, co oznacza, że został od początku zaprojektowany do pracy w dużych środowiskach (nawet 1000 równoległych sesji i wsparcie dla 25 000 końcówek), przy jednoczesnym skalowaniu rozwiązania dla mniejszej infrastruktury. Produkt podchodzi do zagadnień z obszaru Service Desk nakładając priorytety zarówno na wygodę pracy serwisantów, ale także na kwestie bezpieczeństwa świadczenia tej pracy (zarówno dla samych operatorów, ale także dla organizacji).

Marketingu i zachwalania wystarczy. Ważniejsze niż broszurowe deklaracje są faktyczne możliwości zastosowania systemu i wykorzystania jego funkcji. Co zatem daje Remote Support działom wsparcia i dlaczego lubią to narzędzie również działy bezpieczeństwa? Oto krótki przypadek użycia.

Wróćmy do tych pracowników wykonujących swoje zadania z domu. Bez względu na to, czy korzystają z komputera prywatnego, czy też mają do dyspozycji firmowy laptop. Bez względu na to, czy są spięci z firmową siecią, czy też nie ma takiej konieczności, bo do pracy potrzebują wyłącznie dostępu do poczty. Taki użytkownik, siedząc przy stole w jadalni (dokładnie tak jak ja w tej chwili), może napotkać na techniczny problem. Przeszkodę, która uniemożliwi mu dalsze działania. Co robi? Otwiera system helpdeskowy i zgłasza ów problem. Opisuje go najlepiej jak potrafi i czeka na pomoc.

Proces, przy zastosowaniu Remote Support, wygląda już na tym etapie nieco inaczej. Operator Service Desk może nawiązać sesję zdalną bezpośrednio z poziomu systemu ITSM. Po zintegrowaniu tych dwóch systemów, operator może uruchomić sesję zdalną z poziomu zgłoszonego ticketu, klikając odpowiedni przycisk. Konsola Remote Support zostanie uruchomiona, a sesja automatycznie nawiązana. Co istotne – operator wcale nie musi uruchamiać pulpitu komputera zdalnego. Jeżeli problem, nad którym pracuje jest mu znany i możliwy do rozwiązania z poziomu linii komend – może uruchomić tylko ten element. Bez angażowania wspieranego użytkownika i bez odrywania go od pracy. Jeżeli do rozwiązania tego problemu konieczne jest uruchomienie skryptu – operator może go wyzwolić z listy swoich „ulubionych”. Jeżeli trzeba wykonać pracę w rejestrze systemu operacyjnego – odpowiedni moduł da dostęp do tego obszaru (ponownie, bez angażowania użytkownika).

Tych narzędzi, które usprawniają pracę serwisantów jest całe mnóstwo, ale to nie one stanowią o sile tego systemu. Istotne jest to, co dzieje się po zakończeniu takiej sesji. Otóż cała aktywność jest rejestrowana, co oznacza, że w przypadku zastrzeżeń co do jakości pracy serwisantów, można wrócić do nagrania sesji i odtworzyć moment przeprowadzenia określonej operacji. Dotyczy to aktywności pulpitu, linii komend, edytora rejestru i transferowanych plików („z” i „do” komputera wspieranego). Co więcej – link do sesji oraz wszystkich innych logów zebranych w ramach tego połączenia przez Remote Support, zostanie odłożony pod ticketem supportowym, który został utworzony w ITSM. Tym sposobem, każde zgłoszenie, które zostało obsłużone sesją zdalną, będzie wzbogacone o pełną historię wykonanych aktywności. Z perspektywy rozliczalności pracy, a także bezpieczeństwa użytkowników i operatorów – jest to nie do przecenienia. Szczególnie dla kierowników zespołów Service Desk.

A skoro już jestem przy bezpieczeństwie. Remote Support, oprócz rejestracji sesji, która zawsze jest dobrze widziana z perspektywy działów IT Security, posiada kilka innych cech, które bardzo dobrze wpisują się w procedury i polityki mające na celu redukcję ryzyka w organizacjach. O architekturze wspomniałem opisując przypadek użycia w poprzedniej publikacji, ale skoro jest to odrębny tekst, to pokrótce pozwolę sobie przypomnieć, jak to wygląda tutaj.

Podstawowym elementem rozwiązania jest sprzętowy lub wirtualny appliance, który agreguje cały ruch pomiędzy osobą wspieraną i wspierającą. Appliance jest przygotowany, żeby umieścić go w DMZ, co oznacza, że będzie dostępny również dla użytkowników, którzy nie mogą zestawić tunelu VPN. Co również bardzo istotne – ruch odbywa się zawsze w kierunku do appliance (zarówno ze strony serwisanta, jak również pracownika), zatem połączenie pomiędzy komputerami nigdy nie jest bezpośrednie i zawsze następuje przez dostarczany appliance.

Sam appliance to nie wszystko w kontekście bezpieczeństwa. System umożliwia także wprowadzenie mechanizmów charakterystycznych dla systemów PAM – gdzie operator jest odseparowany od hasła konta o podwyższonych uprawnieniach. Niezależnie od tego, czy chce się na to konto zalogować, czy obsłużyć UAC. Poświadczenia konta, przechowywane w zewnętrznym lub wbudowanym sejfie, mogą zostać podstawione do odpowiednich pól, dzięki czemu serwisant może wykonać konieczne działania, przy jednoczesnym podniesieniu poziomu bezpieczeństwa.

Funkcji systemu jest oczywiście znacznie więcej i trudno je wszystkie spisać we względnie krótkiej publikacji. Nie napisałem o możliwości współpracy pomiędzy wieloma serwisantami. Nie wspomniałem też o możliwości wykorzystania systemu do wsparcia innych platform, m.in. OSX, Linux i Unix. Jednak te elementy nie mają większego znaczenia w tej chwili. W tej chwili ważne jest to, żeby móc wspierać użytkowników bez względu na to, gdzie się znajdują. I dotyczy to zarówno wspieranych, jak i wspierających. Szybko, wydajnie i bezpiecznie.