Aktualizacje firmware urządzeń sieciowych przynoszą poprawki błędów i luk bezpieczeństwa, ale każda z nich oznacza restart, czyli przerwę. Ten artykuł opisuje, jak zaplanować okno serwisowe, w jakiej kolejności aktualizować, kiedy świadomie poczekać i dlaczego to jest czynność cykliczna, a nie jednorazowa.
Sprzęt sieciowy to też oprogramowanie
Przełącznik, punkt dostępowy i brama są urządzeniami, ale to, co w nich faktycznie pracuje, jest oprogramowaniem, a więc ma błędy, dostaje poprawki i w pewnym momencie przestaje być wspierane.
Różnica wobec komputerów polega na widoczności. System na laptopie sam przypomina o aktualizacji, natomiast przełącznik zamknięty w szafie nie przypomina o niczym i potrafi pracować na wersji z dnia montażu przez pięć lat, nie wzbudzając niczyjego zainteresowania, ponieważ działa.
Właśnie to „działa” jest tu mylące, bo urządzenie może działać bez zarzutu, mając jednocześnie znaną i opisaną publicznie lukę, dla której poprawka istnieje od dwóch lat.
Co dają aktualizacje firmware urządzeń sieciowych
Warto rozdzielić trzy rzeczy, które różnią się pilnością na tyle, że traktowanie ich łącznie prowadzi do złych decyzji.
Poprawki bezpieczeństwa są najważniejsze, ponieważ podatności w oprogramowaniu urządzeń sieciowych są publikowane, a urządzenia brzegowe pozostają celem skanowania z internetu prowadzonego w sposób ciągły i zautomatyzowany. To jedyna kategoria, która bywa naprawdę pilna.
Poprawki błędów rozwiązują konkretne problemy: zrywanie połączeń w określonych warunkach, wycieki pamięci powodujące restarty co kilka tygodni czy błędne działanie funkcji w rzadkich konfiguracjach. Zdarza się, że problem, którego nikt nie potrafi zdiagnozować, okazuje się znanym błędem z gotową poprawką.
Nowe funkcje są najmniej pilne i w środowisku produkcyjnym nie stanowią powodu do aktualizacji, jeśli nikt ich nie potrzebuje.
Ta hierarchia ma znaczenie praktyczne, ponieważ aktualizacja bezpieczeństwa uzasadnia okno serwisowe wyznaczone poza planem, podczas gdy nowa funkcja nie uzasadnia niczego.
Dlaczego to nie jest czynność „przy okazji”
Aktualizacja urządzenia sieciowego wymaga restartu, a restart oznacza przerwę w działaniu wszystkiego, co przez to urządzenie przechodzi.
Skala tej przerwy zależy od miejsca w topologii: restart pojedynczego punktu dostępowego dotknie jednego pomieszczenia, restart przełącznika szkieletowego wyłączy wszystko, co znajduje się za nim, a restart bramy zatrzyma całą firmę.
Dlatego aktualizacja jest działaniem zaplanowanym, na które składa się pięć elementów.
Okno serwisowe wyznacza się poza godzinami pracy, uwzględniając to, kiedy firma faktycznie nie pracuje. Dla zakładu produkcyjnego pracującego dwuzmianowo „wieczór” nie jest odpowiedzią.
Kolejność prowadzi od urządzeń najmniej krytycznych do najbardziej: najpierw punkty dostępowe w mniej istotnym obszarze, potem przełączniki dostępowe, następnie szkielet, a na końcu brama, przy czym każdy etap weryfikuje się, zanim ruszy następny.
Weryfikacja po każdym kroku sprowadza się do sprawdzenia, czy urządzenie wróciło, czy porty mają link, czy klienci się łączą i czy segmentacja nadal działa. Pytanie „czy internet jest” na to nie odpowiada.
Plan powrotu oznacza możliwość wgrania poprzedniej wersji oraz zapisaną konfigurację, a także, co bywa pomijane, ustaloną godzinę, po której zamiast naprawiać dalej, wracamy do stanu poprzedniego.
Informacja dla ludzi obejmuje termin przerwy, jej zakres oraz wskazanie osoby, do której zgłasza się to, co po aktualizacji nie wróciło.
Kolejność ma znaczenie także technicznie
Istnieje zasada, którą pomija się zaskakująco często: w platformach z centralnym zarządzaniem oprogramowanie kontrolera lub panelu aktualizuje się przed urządzeniami, nie po nich.
Powód jest prosty. Nowsze urządzenie zarządzane przez starszy kontroler bywa nierozpoznawane poprawnie, podczas gdy odwrotna kolejność nie stwarza takiego ryzyka.
Druga zasada mówi, żeby nie aktualizować wszystkiego naraz, i nie wynika z ostrożności, tylko z możliwości diagnozy. Jeżeli po jednoczesnej aktualizacji dwudziestu urządzeń coś przestaje działać, nie sposób ustalić, które z nich jest przyczyną, dlatego etapowanie, choć kosztuje więcej czasu na miejscu, oszczędza go później.
Kiedy świadomie poczekać
Aktualizowanie natychmiast po wydaniu nie jest w środowisku produkcyjnym cnotą, o czym warto pamiętać, gdy pojawia się pokusa „zróbmy to od razu”.
Warto poczekać, jeżeli wersja jest świeża i nie zawiera poprawki bezpieczeństwa dotyczącej Twojego środowiska, jeżeli środowisko jest nietypowe ze względu na konfigurację, integracje lub starsze urządzenia, jeżeli zbliża się okres krytyczny dla firmy, taki jak zamknięcie miesiąca, sezon czy inwentaryzacja, albo jeżeli producent oznaczył wydanie jako wczesne lub testowe. Wiele platform rozdziela kanały wydań na stabilny i wcześniejszy, a w produkcji korzysta się ze stabilnego.
Nie warto czekać, gdy poprawka dotyczy luki w urządzeniu dostępnym z internetu, gdy obecna wersja powoduje problem, który już występuje, albo gdy urządzenie zbliża się do końca wsparcia i jest to jedna z ostatnich aktualizacji, jakie w ogóle dostanie.
Koniec wsparcia to osobna sprawa
Aktualizacje kiedyś się kończą, ponieważ producent wyznacza datę, po której urządzenie nie otrzymuje już poprawek, w tym poprawek bezpieczeństwa.
Kłopot polega na tym, że urządzenie po tej dacie działa dokładnie tak samo jak wcześniej, nie dając żadnego sygnału, że cokolwiek się zmieniło. A zmieniło się zasadniczo: od tego momentu każda nowo odkryta podatność zostaje w nim na stałe.
Dlatego lista urządzeń w sieci powinna zawierać kolumnę „do kiedy wspierane”, bez której wymiana sprzętu zawsze będzie reakcją na awarię zamiast decyzją zaplanowaną wraz z budżetem.
Czego aktualizacje nie załatwią
Warto to powiedzieć wprost, żeby nie traktować ich jako rozwiązania problemów, których nie dotyczą.
Aktualizacje nie naprawią złego projektu sieci, bo źle rozmieszczone punkty dostępowe pozostaną źle rozmieszczone w każdej wersji oprogramowania. Nie zastąpią segmentacji ani kontroli dostępu, które stanowią osobne warstwy, opisane w artykule o podstawach bezpieczeństwa sieci firmowej. Nie usuną problemu z okablowaniem, ponieważ uszkodzony tor pozostanie uszkodzony. Nie ochronią też komputerów, co należy do zupełnie innego obszaru.
Jak to wygląda przy zarządzanej sieci
Bez centralnego zarządzania aktualizacja polega na logowaniu się do każdego urządzenia osobno i ręcznym sprawdzaniu wersji, co przy dziesięciu urządzeniach zajmuje wieczór, a przy trzech lokalizacjach staje się powodem, dla którego nikt tego nie robi.
Platformy zarządzania pokazują wersje na wszystkich urządzeniach jednocześnie i pozwalają zaplanować aktualizację na wybraną godzinę, przy czym zakres tych możliwości bywa powiązany z planem licencyjnym, co warto sprawdzić przed zakupem, a nie po nim.
Na przykład w Zyxel Nebula Control Center zarządzanie firmware w obrębie obiektu jest dostępne w bezpłatnym planie Base, natomiast planowanie aktualizacji per urządzenie w obrębie całej organizacji wymaga planu Plus lub wyższego, a w planie Pro dochodzi dziennik zmian obejmujący organizację, przydatny przy ustalaniu, kto i kiedy co zmienił.
Znaczenie ma również retencja logów, od niej bowiem zależy, czy po aktualizacji da się w ogóle ustalić, co się działo. W planie Base wynosi ona jeden dzień, w Plus siedem dni, a w Pro rok, co przy weekendowym oknie serwisowym oznacza, że w poniedziałek nie ma już czego analizować.
To jest czynność cykliczna
Dochodzimy do zdania, przez które ten temat w ogóle wraca: aktualizacje nie są stanem, który da się osiągnąć, lecz procesem. Sieć zaktualizowana dziś będzie nieaktualna za trzy miesiące i nikt o tym nie przypomni.
W praktyce sprowadza się to do trzech pytań, które firma powinna umieć sobie zadać:
- Kto sprawdza, czy są nowe wersje, i jak często?
- Kto decyduje, czy i kiedy aktualizować?
- Kto to wykonuje i weryfikuje wynik?
Jeżeli na którekolwiek z nich nie ma odpowiedzi, urządzenia pracują na wersji z dnia montażu, co nie jest zaniedbaniem konkretnej osoby, tylko naturalną konsekwencją braku przypisanej odpowiedzialności.
U nas patch management urządzeń sieciowych stanowi część stałej opieki, a nie osobne zlecenie: śledzimy wydania producentów, oceniamy ich pilność, planujemy okna serwisowe, prowadzimy aktualizacje etapami i weryfikujemy wynik. Prowadzimy również listę urządzeń z datami końca wsparcia, dzięki czemu wymiana pozostaje decyzją, a nie reakcją. Zakres i czasy reakcji zapisujemy w umowie.
W sieciach firmowych jesteśmy Partnerem Zyxel Networks i wdrażamy również Ubiquiti UniFi.
Zakres stałej obsługi opisujemy na stronie opieki IT, wdrożenia na stronie sieci firmowych, a mechanizm dostępu, dzięki któremu to wszystko da się prowadzić zdalnie, w artykule o zdalnym zarządzaniu siecią firmową.
Umów bezpłatny przegląd IT i sprawdźmy, na jakich wersjach pracują dziś Twoje urządzenia.