Wdrożenie systemu kontroli dostępu do sieci (NAC) – nie taki diabeł straszny!

Systemy kontroli dostępu do sieci (NAC – Network Access Control) cieszą się w ostatnich latach niesłabnącym zainteresowaniem. Ich stosowanie dla wielu sektorów, zwłaszcza publicznych, bywa wymuszane na drodze prawnej, natomiast zalecane jest ono do wdrożenia i stosowania jako rezultat przeprowadzonych audytów bezpieczeństwa i testów penetracyjnych praktycznie wszędzie tam, gdzie istnieje ogólnodostępna dla pracowników i klientów infrastruktura IT: sieci WiFi czy nienadzorowane gniazda sieciowe. Jak jednak wygląda wdrożenie takiego systemu? Na ile jest ono problematyczne, z jakimi wyzwaniami się wiąże, czy stanowi realne zagrożenie dla zachowania ciągłości działania infrastruktury?Zacznijmy od tego, że nie ma uniwersalnej odpowiedzi na to, jak wygląda takie wdrożenie. Trudno też mówić o modelowym podejściu do tego zagadnienia – tak naprawdę każda infrastruktura jest inna, jest zbyt wiele zmiennych zarówno w konfigurowanym sprzęcie, jak i oczekiwaniach Klientów wobec systemu, jego skalowalności oraz wymagań związanych z przerwami w dostępie do zasobów podczas tego procesu.

Pierwszym, naturalnym etapem jest rozpoznanie infrastruktury sieciowej Klienta pod kątem skali: ilu unikalnych użytkowników korzysta z sieci lokalnej? Ile ma być urządzeń logujących się do sieci samodzielnie z wykorzystaniem protokołu 802.1x lub adresu MAC? Jak wiele urządzeń sieciowych (przełączników, kontrolerów WiFi/access pointów) zapewniających obsługę 802.1x posiada klient? Odpowiedzi na te pytania pozwalają oszacować czasochłonność procesu konfiguracji urządzeń sieciowych oraz wycenić licencję dla rozwiązania klasy NAC. Dla przykładu: oprogramowanie NACVIEW licencjonowane jest na ilość unikatowych autoryzacji (adresów MAC logujących się do sieci) w ciągu doby. Na czas potrzebny do skonfigurowania urządzeń z kolei składa się w oczywisty sposób ich ilość, ale także różnorodność: im większa gama występujących modeli, a co za tym idzie możliwości konfiguracji, tym większa czasochłonność.

Drugą kwestią jest omówienie zakresu wdrożenia: jaka część środowiska sieciowego ma podlegać ochronie systemem NAC? Zwykle pożądana jest ochrona całościowa, ale bywają też takie instancje, które chronią zaledwie określony wycinek sieci, w którym system NAC kontroluje gościnny dostęp do sieci i np. wyłącznie jedną halę produkcyjną, biura pozostawiając bez zabezpieczenia. Obniża to koszty licencji i wdrożenia, niemniej jednak nie stanowi całkowitego zabezpieczenia przed nieautoryzowanym dostępem do sieci, pozostawiając luki w postaci niezabezpieczonych portów. W dalszej części rozważań nad zakresem wdrożenia należy odpowiedzieć na pytanie, czy autoryzowane mają być tylko komputery, czy może także urządzenia peryferyjne (np. drukarki), IoT (telewizory, projektory, etc.), telefony komórkowe, urządzenia sieciowe wykorzystywane na halach produkcyjnych, kamery, telefony VoIP?… Tutaj także działa prosta prawidłowość: im większa ilość, tym większa czasochłonność projektu i jego koszty.

Duże oszczędności poczynić można korzystając z istniejących w infrastrukturze systemów umożliwiających automatyzację: systemy klasy NAC bezproblemowo potrafią komunikować się np. z kontrolerami domeny AD, z których w czasie rzeczywistym pobierają informacje na temat obiektów użytkowników i komputerów i nie trzeba dodawać ich ręcznie do systemu. Zewnętrzne urzędy certyfikacji? To nie problem! Mogą stanowić źródło certyfikatów dla klientów i sprzętu, w oparciu o które system NAC pozwoli (lub nie) na dostęp do pożądanej podsieci. GPO w środowisku Windows Server zadba o propagację ustawień suplikanta na wszystkich komputerach, przy okazji dbając o dystrybucję certyfikatów. Jeżeli urządzenia sieciowe, którymi dysponuje klient umożliwiają skorzystanie z dynamic VLAN, to również automatyczny przydział danego komputera/użytkownika/sprzętu sieciowego po udanej autoryzacji do właściwego VLAN-u nie stanowi żadnego wyzwania.

Niemniej istotne są chęci i czas zamawiających: często bywa tak, że klienci życzą sobie przygotowania w toku wdrożenia wzorcowych konfiguracji np. sprzętu sieciowego (przełączników, kontrolerów WiFi, etc.), na podstawie których będą oni mogli samodzielnie dokonać wdrożenia w pozostałym obszarze infrastruktury, stosując się do procedur step-by-step przygotowanych „na miarę” przez inżyniera prowadzącego projekt. Z praktyki wynika, że to właśnie takie podejście gwarantuje najniższe koszty wdrożenia, ponieważ wszystkie powtarzalne czynności przejmują administratorzy sieci, działając na podstawie przygotowanych wcześniej przez inżyniera wzorców, co pozwala zredukować koszty o czas, który musiałaby na to normalnie poświęcić osoba ze strony wykonawcy. Podobnie sprawa się ma z dostosowaniem istniejącego środowiska AD (o ile pożądana jest integracja systemu NAC z tą usługą) czy urzędu certyfikacji.

Jak natomiast wygląda oddziaływanie systemu na aktualne środowisko sieciowe? Czy możemy spodziewać się przerw w dostępie do sieci? I tak i nie – ponownie, wszystko zależy od tego, na jakim środowisku pracujemy. Sama instalacja systemu i zasilenie go informacjami dotyczącymi kształtu sieci (VLAN-y, podsieci), jak i obiektami (komputery, użytkownicy, inny sprzęt, polityki dostępowe, etc.) dzieje się zupełnie poza infrastrukturą produkcyjną. W ramach dobrych praktyk, dobrze jest udostępnić do testów niewielki wycinek infrastruktury inżynierowi wdrażającemu rozwiązanie, np. jakąś dedykowaną stację roboczą, testowe konto w AD, nieużywany przełącznik bądź nieużywany port na produkcyjnym przełączniku, etc., by mógł on dokonać skutecznego uruchomienia systemu w kontrolowanych warunkach i mógł z powodzeniem przenieść konfigurację na środowisko produkcyjne. Urządzenia podłączone do sieci przy pomocy przewodu sieciowego można przełączyć na uwierzytelnianie z użyciem protokołu 802.1x zmieniając ustawienia portów na przełączniku, co można czynić pojedynczo lub grupami, w zależności od preferencji administratorów. Następuje wówczas krótka (kilku-kilkunastosekundowa) przerwa w dostępie do sieci dla urządzenia końcowego, ponieważ przełącznik dokonuje zapisania zmian na porcie i uwierzytelnia w sieci podłączony do portu sprzęt. W przypadku sieci bezprzewodowych wystarczy dokonać przełączenia komputera/drukarki/telefonu, etc. na sieć WiFi z włączonym uwierzytelnianiem 802.1x – tutaj przerwa w dostępie do sieci jest tak mała, jak szybko jest w stanie sobie z takim przełączeniem poradzić urządzenie końcowe. Jak widać zatem, nie ma tutaj mowy o tym, że wdrożenie takie może sparaliżować działanie sieci na długo i w wielkiej skali. Jest to proces, który można od początku do końca kontrolować i z łatwością przywrócić poprzednie ustawienia, gdyby coś z jakiegoś powodu się nie udało.

Podsumowując: to, jak będzie wyglądało wdrożenie systemu klasy NAC w ogromnej mierze zależy od samego klienta: jego elastyczności w podejściu do tematu w zakresie gotowości do samodzielnego działania, udostępniania do pracy wycinka infrastruktury na potrzeby przygotowania konfiguracji wzorcowych i przeprowadzania testów, sprzętu na jakim przyjdzie działać inżynierom w procesie konfiguracji oraz od płynności komunikacji w relacji inżynier-klient. Ja osobiście na tym polu mam praktycznie same pozytywne doświadczenia na przestrzeni kilkunastu takich projektów i mogę z czystym sumieniem powiedzieć: nie taki diabeł straszny!

KG