Nie da się ukryć, że infrastruktura krytyczna jest systemem złożonym i indywidualnym dla każdego przedsiębiorstwa. Składa się z głównego systemu nadzorowania procesu (jak SCADA) lub systemu sterowania DCS. W skład takich systemów wchodzą rozmaite urządzenia wielu producentów należące do różnych grup – sterowniki przemysłowe, przełączniki sieciowe, routery, konwertery mediów transmisyjnych, routery GSM czy specjalizowane urządzenia pomiarowe oraz podsystemy sterowania wycinkiem procesu dostarczone przez producenta.
Idealną sytuacją byłoby, gdybyśmy posiadali tylko urządzenia jednego producenta, ale nie jest to możliwe. Najczęściej w infrastrukturze krytycznej mamy do czynienia z występowaniem w jednej sieci elementów wielu różnych producentów.
Administratorzy takiej infrastruktury muszą więc wykorzystywać wiele narzędzi odpowiednich dla każdego z wdrażanych rozwiązań, a jednocześnie każdy z dostawców instaluje narzędzia, które w lepszy czy gorszy sposób próbują monitorować stan tych urządzeń. Dla przykładu – w branży energetycznej w ramach jednego procesu przemysłowego można spotkać kilkanaście rozwiązań, gdzie jeden podmiot dostarcza elementy dla systemu sterowania palnikami, a inny elementy monitorujące pracę turbiny.
Rozwiązanie problemów administratorów infrastruktury krytycznej
Jest tylko jedna rzecz, która łączy wszystko – komunikacja sieciowa oraz protokół TCP/IP. Prowadząc wdrożenia w różnych obiektach oraz integrując rozwiązania, obserwujemy problemy w aspekcie zarządzania tak złożonym środowiskiem. W świecie IT znane są rozwiązania, które mają na celu monitorowanie wszystkiego w każdej lokalizacji. Jednym z takich rozwiązań jest system monitorowania infrastruktury Zabbix.
Rozwiązanie to rozwijane jest od ponad 22 lat i posiada ponad 300 000 wdrożeń. Zabbix to oprogramowanie open source posiadają większe możliwości niż większość narzędzi dostarczanych przez innych producentów. Zabbix pozwala na monitorowanie urządzeń sieciowych (takich jak switche, routery czy serwery), innych aplikacji oraz usług sieciowych.
Przykład wizualizacji monitorowanej infrastruktury (źródło: www.zabbix.com)
Jak podejść do tematu?
Chciałbym zwrócić uwagę na delikatne podejście do tematu nadzoru nad infrastrukturą krytyczną. W odróżnieniu od świata IT, w OT nie zawsze będziemy mogli monitorować wszystkie parametry urządzania.
Zabbix posiada wiele mechanizmów monitorowania infrastruktury, np. poprzez SNMP, ICMP, dedykowanego agenta dla konkretnych systemów operacyjnych i wiele innych. Podczas takiego wdrożenia musimy dobrze znać proces, jaki zachodzi w infrastrukturze krytycznej, i rozumieć wszystkie zależności poszczególny elementów. Mam tu na myśli sytuacje, w których awaria jednego urządzenia lub tylko jednej usługi ma wpływ na resztę procesu. Podczas każdego wdrożenia rozmowa z inżynierami odpowiedzialnymi za proces jest najważniejsza, bo to Oni wiedzą, jakie awarie wystąpiły w ostatnim czasie. Staramy się razem przewidzieć i określić, jakie zachowania poprzedzają awarię i konfigurujemy alarmy z tym związane.
Przykłady z życia wzięte
Jeden z naszych klientów posiada rozsiane po swojej infrastrukturze liczniki energii elektrycznej. Liczniki te nie są krytyczne dla procesu, ale raz na tydzień służą za źródło do poboru odczytów. Jeżeli odczyt się nie powiedzie, podmiot nadzorujący wymusza na kliencie tworzenie stosów dokumentów i wyjaśnień, co generuje niepotrzebną pracę. Liczniki są obecnie monitorowane przez system Zabbix na dwa sposoby:
- Sprawdzenie, czy istnieje komunikacja z tym urządzeniem na poziomie sieciowym, test Simply Check ICMP z interwałem 1 minutowym.
- Sprawdzenie, czy usługa na odpowiednim porcie TCP odpowiada i da się z nią połączyć.
Te dwa testy generują alarmy w przypadku wystąpienia następujących zdarzeń:
- Przerwania łącza fizycznego lub braku zasilania licznika. Występuje wtedy brak komunikacji ICMP i awaria wykrywana jest po maksymalnie minucie od jej wystąpienia.
- Błędnej konfiguracji urządzenia – jeżeli urządzenie odpowiada po ICMP, ale test usługi TCP nie pozwala na autoryzację, to otrzymujemy alarm o tym, że ustawienia zostały zmienione.
- Brak odpowiedzi na pakiet TCP SYN – co oznacza, że usługa nie jest dostępna lub urządzenie się zawiesiło.
Drugim przykładem jest lokalizacja awarii urządzenia, które nie jest monitorowane bezpośrednio, ale jego zachowania można odczytać z symptomów, jakie zaistniały na sprzęcie poddanym monitorowaniu.
Klient posiada sieć Ethernet w architekturze pierścienia, gdzie monitorowane są wszystkie parametry pracy każdego przełącznika sieciowego. Między innymi monitorowane są obciążenia procesora w przełączniku i parametry transmisji danych, jak ilość pakietów na sekundę oraz prędkość wysyłanych i odbieranych danych dla każdego portu. U klienta zaobserwowano problemy z działaniem sieci – urządzenia w sieciprzestały być dostępne, a zarządzanie siecią stało się niemożliwe.
Dzięki Zabbixowi wykryto w zebranych danych, że przed awarią sieci jeden z przełączników sieciowych miał zwiększone zapotrzebowanie na czas procesora. Drążąc temat głębiej, okazało się, że urządzenie podłączone do portu numer pięć wysyłało miliony pakietów. Zła konfiguracja urządzenia telemechaniki, które było podpięte do tego portu, spowodowała wystąpienie sztormu w sieci.
Gdyby nie wdrożenie Zabbixa, proces znalezienia usterki potrwałby kilkanaście godzin, ponieważ każdy z przełączników usytuowany jest w innej lokalizacji – niekiedy oddalonej o dziesiątki kilometrów. Dane zebrane w Zabbixie pozwoliły na precyzyjne działanie administratorów oraz szybkie przywrócenie poprawnego działania.
Jakie jeszcze problemy rozwiązujemy przy okazji?
Przede wszystkim w Zabbixie mamy moduł inwentaryzacji, gdzie możemy bardzo skrupulatnie pilnować wszystkich niezbędnych danych o zainstalowanym sprzęcie. Aktualna dokumentacja infrastruktury jest aktualizowana w Zabbixie automatycznie podczas normalnego procesu użytkowania.
Zabbix – wdrożenie
Próg wejścia we wszystkie funkcje Zabbixa jest duży – możliwe jest odbycie szkolenia z systemu Zabbix, rozgryzienie go samemu lub wynajęcie firmy, która posiada w tym zakresie doświadczenie. Proces wdrożenia jest uzależniony od stopnia skomplikowania infrastruktury, jej elementów i tego, jak dobrze proces w infrastrukturze krytycznej jest znany klientowi. Ale to opowiadanie na zupełnie inny wpis.