Audyt infrastruktury IT — zdegradowana macierz i kopia zapasowa na tym samym serwerze

Wyzwanie

Cała firma pracowała na kilku urządzeniach: serwerze Windows Server 2019 z Hyper-V, na którym działały SQL Server, system księgowy i usługi pomocnicze, serwerze plików FreeNAS na ZFS i firewallu pfSense. Serwer ma za sobą 7–10 lat eksploatacji, storage jeszcze więcej. Wszystko działało, więc od dawna nikt nie sprawdzał, w jakim stanie są dyski, aktualizacje i kopie zapasowe.

Pytanie klienta brzmiało: co realnie grozi ciągłości działania firmy i w jakiej kolejności to naprawiać.

Jak pracowaliśmy

Audyt wykonaliśmy zdalnie, w trybie diagnostycznym. Jedyną zmianą w środowisku produkcyjnym było uporządkowanie konfiguracji VSS (opis niżej).

Serwer Windows — konfiguracja systemu, dziennik zdarzeń, usługi i procesy, zużycie pamięci i pliku stronicowania, konfiguracja VSS / Shadow Copies, wolumeny i macierz, stan aktualizacji, środowisko Hyper-V, usługi SQL Server i aplikacyjne, kopie zapasowe — co jest kopiowane, dokąd i czy da się z tego odtworzyć system.
Storage (FreeNAS) — konfiguracja i stan puli ZFS (zpool status, wynik scrubu, błędy checksum), odczyty SMART każdego dysku (ocena ogólna, godziny pracy), zajętość, redundancja, wersja systemu.
Sieć — platforma firewalla i wersja pfSense.

Każde ustalenie dostało ocenę ryzyka i opis tego, co z niego wynika dla działania firmy.

Ustalenia — storage

Pula ZFS w stanie DEGRADED. Macierz RAIDZ2 straciła jeden dysk i pracowała z ograniczoną redundancją. Dobra wiadomość: ZFS zachował integralność danych, scrub zakończył się bez błędów, nie było błędów checksum. Dane były całe, ale zapas na kolejne awarie się skurczył.
Dysk w stanie krytycznym. Jeden z dysków puli zwracał w SMART wynik FAILED z komunikatem, że awaria jest spodziewana w ciągu 24 godzin. Kwalifikował się do wymiany od ręki.
Wyeksploatowane dyski. Odczyty SMART pokazały 88–135 tys. godzin pracy, czyli 10–15 lat ciągłej eksploatacji. Storage dawno przekroczył zalecany cykl życia, więc po wymianie jednego dysku łatwo o awarię kolejnego. Ryzyko: wysokie.
Za mało miejsca. Ok. 231 GB pojemności, z czego wolne ok. 40 GB. Pełny obraz serwera Windows się tam nie zmieści, więc storage nie może pełnić roli repozytorium kopii zapasowych.
System bez wsparcia. FreeNAS na FreeBSD 11.3, build z 2020 roku: zaległe poprawki bezpieczeństwa, przestarzałe komponenty SMB i OpenSSL, coraz gorsza zgodność z nowszym oprogramowaniem, a to utrudnia odtwarzanie danych w razie problemów.

Ustalenia — serwer Windows

Wieloletnie zaległości w aktualizacjach bezpieczeństwa. Otwarte podatności w RDP, SMB i Hyper-V to realne ryzyko przejęcia serwera, na którym działa baza danych i księgowość. Ryzyko: wysokie.
Źle skonfigurowane VSS. Brak limitu miejsca dla kopii migawkowych (UNBOUNDED), nadmiar shadow copies i błędy Volsnap / FilterManager w dzienniku zdarzeń. Skutki: kopie migawkowe zjadały miejsce na dysku, a migawki i oparte na nich kopie zapasowe mogły działać niestabilnie. To naprawiliśmy już w trakcie audytu: ustawiliśmy limit 95 GB i kontrolowany harmonogram migawek. Po zmianie VSS działa stabilnie, a miejsce na dysku przestało ubywać.
Kopia zapasowa tylko lokalnie. Na osobnym dysku serwera był systemowy obraz Windows Server (Windows Server Backup). To duży plus, bo pozwala odtworzyć system po awarii logicznej albo przenieść go na nowy sprzęt. Kopia leży jednak w tej samej obudowie co system, który zabezpiecza. Nie ma kopii offline ani na zewnętrznym nośniku czy storage. Awaria całego hosta, uszkodzenie storage albo ransomware zabierają produkcję i kopię naraz. Ryzyko: wysokie.
16 GB RAM na wszystko. Na tej pamięci działały jednocześnie SQL Server, Hyper-V, kontroler sieci Wi-Fi z własną bazą MongoDB i środowiskiem Java oraz Windows Defender. Zużycie pamięci było wysokie, plik stronicowania intensywnie używany, zapas wydajności niewielki. Ryzyko: średnie.
Za dużo ról na jednym serwerze. Usługi sieciowe działały obok bazy danych i systemu księgowego. To dodatkowe obciążenie, większa powierzchnia ataku i trudniejsza przyszła migracja. Zaleciliśmy stopniowe oddzielenie usług infrastrukturalnych od środowiska SQL i księgowego.
Brak Active Directory. Serwer działa w grupie roboczej, bez centralnego zarządzania kontami. Odnotowaliśmy to jako punkt wyjścia do przyszłej modernizacji, nie jako pilną zmianę.

Ustalenia — firewall

Sprzęt firewalla nadal wystarcza na potrzeby małej firmy, ale pfSense CE 2.6.0 ma zaległe aktualizacje. Zaleciliśmy przejście na aktualną, wspieraną wersję. Ryzyko: średnie.

Plan naprawczy

Kolejność wynika z prostej zasady: najpierw zabezpieczyć dane, które już są zagrożone, potem usunąć przyczyny, a na końcu poprawić wydajność.

Priorytet krytyczny — natychmiast

Rozszerzyć kopie zapasowe. Zostawić lokalny obraz systemu i dodać kopię zewnętrzną lub offline, odseparowaną od serwera produkcyjnego, z większą pojemnością i regularnymi testami odtwarzania. To pierwszy punkt, bo dopiero z kopią poza hostem każda kolejna operacja (wymiana dysku, aktualizacje) przestaje być ryzykowna.
Wymienić uszkodzony dysk w puli ZFS i odbudować redundancję.
Nie restartować storage do czasu wykonania kopii, wymiany dysku i przygotowania planu migracji. Stare dyski po zatrzymaniu i ponownym rozruchu mogą już nie wstać.

Priorytet wysoki — najbliższe miesiące

Nowy NAS na kopie zapasowe — z pojemnością na pełny obraz serwera i nową strategią kopii.
Aktualizacja Windows Server — etapami, po pełnym backupie, w zaplanowanym oknie serwisowym. Nie jednym ruchem, bo wieloletnia zaległość to duża paczka zmian na serwerze z bazą danych.
Migracja storage na nową platformę z aktualnym, wspieranym TrueNAS.

Priorytet średni

Rozbudowa RAM do co najmniej 32 GB ECC.
Aktualizacja BIOS i firmware serwera.
Aktualizacja pfSense — na miejscu, po wykonaniu kopii konfiguracji. Jeśli aktualizacja firewalla pójdzie źle, zdalny dostęp do sieci zniknie.

Przy wymianie sprzętu — 12–24 miesiące. Środowisko działa, ale jest u kresu cyklu życia. Zaleciliśmy przygotowanie planu migracji na nowy serwer i nowy storage na kopie zapasowe, z uporządkowaną strategią backupu i odtwarzania po awarii (DR). Modernizację rozłożyliśmy w czasie, tak żeby nie trzeba było wymieniać wszystkiego naraz.

Efekt

Zagrożenie danych wykryte przed awarią. Zdegradowaną macierz i dysk z prognozą awarii znaleźliśmy, zanim kolejny dysk odmówił posłuszeństwa. Dane były wtedy jeszcze całe (czysty scrub, zero błędów checksum), więc dało się je zabezpieczyć, zamiast odzyskiwać.
Realna ocena kopii zapasowych. Klient wie, przed czym chroni go obecny backup (awaria logiczna systemu, migracja), a przed czym nie (awaria hosta, ransomware, uszkodzenie storage).
Jeden problem rozwiązany od razu — VSS z limitem i harmonogramem zamiast nieograniczonego przyrostu migawek.
Plan zamiast listy problemów — 9 zaleceń w trzech priorytetach i perspektywa modernizacji na 12–24 miesiące, z uzasadnieniem kolejności.