Kontraktorzy to bardzo szczególne wyzwanie dla bezpieczeństwa. W przeciwieństwie do zwykłych gości, który przebywają w firmie krótko i jedyne czego potrzebują to dostęp do Internetu, kontraktorzy - zwłaszcza ci, z którymi współpracuje się od dawna - są niemalże pracownikami. Niemalże... Regulacje oraz zdrowy rozsądek podpowiadają, że nie można im dać pełnego dostępu do całej sieci korporacyjnej, choć w prawie każdym przypadku, aby prawidłowo wykonywać swoją pracę muszą mieć dostęp do LAN-u.

Dobrym przykładem są audytorzy - muszą mieć dostęp do kilku systemów finansowych i przebywają na terenie firmy dość długo, np. miesiąc. Podobnie w szpitalach, gdzie technicy obsługujący sprzęt medyczny również często pochodzą "z zewnątrz". Podobnie, wiele przedsiębiorstw zdecydowało się na outsourcing części zadań działu IT, jak np. wspomniane zarządzanie serwerami blade. W dużej mierze ludzi ci przychodzą do firmy przez lata, posługują się firmowym mailem czy telefonem, nierzadko mają także swoje własne miejsce przy biurku.

Kontraktorzy nie powinni mieć dostępu do zasobów chronionych w firmie, jak np. do kodów źródłowych, serwerów finansowych, planów rozwoju itp. Zwłaszcza, że w ramach tej samej branży poruszają się pomiędzy kilkoma firmami. Co za tym idzie, mogą przekazać poufne informacje firmie konkurencyjnej.

W celu ograniczenia dostępu do sieci kontraktorom można stosować mechanizmy segmentacji sieci opierające się o sieci wirtualne (VLAN-y) oraz listy kontroli dostępu (ACL-e). Problem jednak staje się coraz poważniejszy i należy szukać rozwiązać w większym stopniu zautomatyzowanych. Po pierwsze, administracja VLAN-ami i ACL-ami zabiera dużo czasu. Trzeba cały czas "śledzić" kontraktora i pilnować aby konfiguracja tych mechanizmów była zawsze aktualna. Dodatkowo, taka separacja ma charakter logiczny, co w powiązaniu z - jakby nie było fizyczną - postacią sieci rodzi nowe komplikacje. Po drugie, w niektórych środowiskach VLAN-y oraz ACL-e nie mogą być wykorzystywane. Przykładem mogą być linie lotnicze, gdzie wiele osób pracuje na tych samych komputerach. Wszyscy oni potrzebują dostępu do różnych aplikacji i zasobów, a skoro uzyskują do nich dostęp z tego samego peceta nie ma mowy o segmentacji bazującej na portach. Wreszcie po trzecie, najbardziej niepokojącym powodem szukania innych mechanizmów ochrony, jest pomysłowość samych użytkowników, którzy cały czas szukają sposobów na ominięcie barier. Nawet, jeżeli nie ukradną danych logowania swojego kolegi wiedzą, że jeżeli zalogują się z komputera tegoż kolegi uzyskają dostęp do komunikatora, Internetu czy innych zasobów, które nie są dostępne z własnego peceta.

Co może być bardziej bezpiecznym i zautomatyzowanym mechanizmem? Bardzo przydatnym orężem jest kontrola dostępu opierająca się na rolach. Wymaga to odrobiny elastyczności, ale warte jest zachodu. W przypadku pracowników zakontraktowanych na długi okres czasu należy poszukać systemu, za pomocą którego można będzie ich przyporządkować do np. Active Directory lub innego "składu" tożsamości użytkowników. Urządzenia sieciowe powinny współpracować z tym systemem i wymuszać polityki dostępowe w oparciu o przynależność kontraktora do określonej grupy. Jeżeli urządzenie bezpieczeństwa potrafi uczyć się ról automatycznie i bezpośrednio kontrolować ruch (bez pośrednictwa innego urządzenia np. switch-a) całość procesu będzie odbywała się dynamicznie. Jeżeli kontraktor odejdzie, a jego nazwisko zostanie usunięte z AD, nie będzie mógł się więcej dostać do sieci. Podobnie, jeżeli osoba ta będzie musiała zmienić miejsce "urzędowania" nie będzie potrzeby ręcznego przekonfigurownia urządzeń i zmiany VLAN-u czy aktualizacji ACL-a.

Z kolei w przypadku pracowników zakontraktowanych na krótki okres czasu dobrym pomysłem może być uruchomienie tzw. captive portalu, czyli miejsca, w którym użytkownik musi zostać uwierzytelniony zanim będzie mógł dostać się do zasobów. Dla użytkownika skorzystanie z captive portalu to uruchomienie przeglądarki, która automatycznie powinna wystawić odpowiedni portal uwierzytelniający. Dzięki temu narzędziu, korzystając z określonego profilu wspólnego dla grupy kontraktorów, administrator będzie mógł zapewnić dostęp do określonych zasobów bez konieczności modyfikowania AD czy innego katalogu użytkowników. Wspólny login w dalszym ciągu będzie dawał kontrolę nad tym, jakie aplikacje mogą być uruchamianie, czy do jakich serwerów będzie można się dostać. Niestety nie ma roży bez kolców. Takie podejście to brak granularnej kontroli per kontraktor czy śledzenia, które zapewnia scenariusz z wykorzystaniem AD.

Dzięki podejściu zautomatyzowanemu wszelkie zmiany są dla kontraktora w zasadzie niewidoczne. Gorączkowa aktualizacja ACL-i za każdym razem, kiedy pracownik zmienia biurko nie będzie już miała miejsca. Dzięki temu nie powinien on odczuć tych "niewidocznych" zmian jako braku zaufania.

Wybierając system kontroli dostępu pracowników kontraktowych należy upewnić się, że dana platforma bezpieczeństwa oferuje funkcjonalność automatycznego uczenia się roli użytkowników, posiada opcję captive portalu oraz nie wymaga dodatkowych komponentów koniecznych do egzekwowania polityki. Jeżeli te założenia zostaną spełnione administrator będzie mógł zdjąć ze swoich barków zadanie żmudnej rekonfiguracja VLAN-ów i list dostępowych.

***

Artykuł powstał na podstawie informacji zamieszczonych w NetworkWorld