Audyt infrastruktury IT po poprzednim zespole: od czego zaczynam

Audyt infrastruktury IT po poprzednim zespole zaczynam zawsze od tego samego: najpierw spisuję, co jest i kto ma do tego dostęp, potem sprawdzam kopie i monitoring, a dopiero na końcu cokolwiek wyłączam lub poprawiam. Jeśli przejmujesz serwery po odchodzącym informatyku albo firmie, z którą skończyła się współpraca, ta kolejność chroni Cię przed najgorszym scenariuszem: wyłączeniem maszyny, od której zależała usługa, o której nikt nie wiedział.

Niedawno prowadziłem taki audyt dla firmy usługowej z Niemiec, która miała kilkanaście serwerów po poprzednim dziale IT. Poniżej opisuję kolejność kroków, typowe znaleziska i decyzje, które na koniec trafiają do właściciela.

Dlaczego kolejność kroków ma znaczenie

W odziedziczonej infrastrukturze nie ma dokumentacji, której można w pełni ufać. Opis sprzed lat mówi, jak miało być, a nie jak jest. Dlatego każdy krok audytu ma zmniejszać niewiadome, zanim zrobisz coś nieodwracalnego.

Pokusa jest odwrotna. Widać stare systemy, nieużywane maszyny i bałagan, więc chce się od razu sprzątać. To błąd, bo bez inwentaryzacji i kopii nie wiesz, co psujesz, i nie masz do czego wrócić.

Druga rzecz to źródła informacji. Do inwentaryzacji nie wystarcza lista od poprzedniego zespołu. Porównuję ją z fakturami od dostawców, kontami w panelach chmurowych, rekordami DNS i tym, co widać w samej sieci. Każda rozbieżność między tymi źródłami to pozycja do wyjaśnienia, zanim przejdę dalej.

Krok po kroku: jak prowadzę audyt infrastruktury IT

Pracuję w stałej kolejności. Każdy etap kończy się zapisem, z którego korzysta następny.

1. Inwentaryzacja: lista wszystkich serwerów, maszyn wirtualnych, usług w chmurze, domen i kont u dostawców. Przy każdej pozycji: do czego służy, kto z niej korzysta, na jakim systemie działa i do kiedy ten system ma wsparcie producenta.
2. Dostępy: kto ma konta administracyjne, gdzie są hasła i klucze, które konta należą do osób, które już nie pracują z firmą. Zmieniam hasła tam, gdzie znał je poprzedni zespół, ale robię to po sprawdzeniu, czy żadna usługa nie loguje się tym samym kontem.
3. Kopie zapasowe: czy istnieją, gdzie leżą, kiedy powstała ostatnia udana i czy ktoś kiedykolwiek z nich coś odtworzył.
4. Monitoring: czy ktoś dostaje powiadomienie, gdy serwer padnie, zabraknie miejsca na dysku albo wygaśnie certyfikat.
5. Sprzątanie: dopiero teraz, z listą, dostępami, kopiami i monitoringiem w ręku, przechodzę do wyłączania, migracji i porządkowania.

Ten porządek przydaje się także przy mniejszej skali, choćby przy przeprowadzce hostingu małej firmy. Lista składników i dostępów jest punktem wyjścia w obu przypadkach.

Typowe znaleziska w odziedziczonej infrastrukturze

Znaleziska powtarzają się niezależnie od branży i kraju. Najczęściej trafiam na trzy grupy problemów.

• Systemy bez wsparcia: serwery na wersjach systemu operacyjnego, dla których producent nie wydaje już poprawek bezpieczeństwa. Działają, ale każda nowa luka zostaje otwarta na stałe.
• Usługi wystawione do internetu: panele administracyjne, bazy danych i pulpity zdalne dostępne z zewnątrz, choć powinny być widoczne tylko z sieci firmy albo przez VPN.
• Kopie, których nie ma: zadanie kopii jest skonfigurowane, ale od dawna kończy się błędem, zapisuje na ten sam dysk co dane albo nikt nie wie, jak z niego odtworzyć system.

Do tego dochodzą maszyny, których nikt nie umie przypisać do żadnej usługi, oraz usługi uruchomione w kilku miejscach naraz, bo kiedyś ktoś postawił nową wersję obok starej. Szerszy kontekst ochrony danych opisałem w tekście o strategiach zabezpieczania danych firmowych.

Utrzymać, zmigrować, wyłączyć: decyzje dla właściciela

Audyt kończy się listą decyzji, a nie listą usterek. Właściciel firmy nie musi rozumieć konfiguracji serwera, ale musi wiedzieć, co z każdą pozycją zrobić i dlaczego.

Decyzja	Kiedy ją proponuję	Co trzeba przygotować
Utrzymać	usługa jest potrzebna, system ma wsparcie, działa stabilnie	kopie, monitoring, opis w dokumentacji
Zmigrować	usługa jest potrzebna, ale system jest bez wsparcia albo serwer jest przewymiarowany	plan migracji, test na kopii, plan wycofania
Wyłączyć	nikt nie korzysta z usługi albo dubluje inną	okres obserwacji, kopia przed wyłączeniem, potwierdzenie właściciela

Przy wyłączaniu stosuję prostą zasadę: najpierw odcinam maszynę od sieci na jakiś czas i obserwuję, czy ktoś zgłosi problem. Dopiero potem ją kasuję, mając kopię. Migracje planuję tak samo jak każdą inną, z testami i drogą powrotu, o czym pisałem przy migracji aplikacji z planem wycofania.

Co daje audyt infrastruktury IT

W przypadku firmy z Niemiec efekt był taki, jakiego oczekuje się po dobrze przeprowadzonym porządku: mniej maszyn, niższe koszty utrzymania i jasny obraz tego, co działa, gdzie i po co. Właściciel dostał listę usług z przypisaną odpowiedzialnością zamiast zbioru serwerów, o których wiedział tylko poprzedni zespół.

Ten ostatni punkt jest moim zdaniem najważniejszy. Infrastruktura opisana na papierze daje się przekazać kolejnej osobie lub firmie bez powtarzania całego śledztwa. Warto od razu zapisać, kto odpowiada za kopie, aktualizacje i reakcję na awarię, na przykład w umowie SLA na utrzymanie.

Lista kontrolna na pierwszy tydzień po przejęciu

• Spisz wszystkie serwery, usługi chmurowe, domeny i konta u dostawców.
• Ustal, kto ma dostępy administracyjne, i zmień hasła znane poprzedniemu zespołowi.
• Sprawdź, kiedy powstała ostatnia udana kopia każdego ważnego systemu.
• Uruchom podstawowy monitoring dostępności, miejsca na dysku i certyfikatów.
• Niczego nie kasuj, dopóki nie masz kopii i potwierdzenia, że nikt z tego nie korzysta.

Jeśli właśnie przejmujesz serwery po poprzednim IT, zacznij od inwentaryzacji, nawet w arkuszu, zanim ktokolwiek zacznie sprzątać. Audyt infrastruktury IT w tej kolejności jest wolniejszy na starcie, ale nie zostawia niespodzianek. Gdy potrzebujesz kogoś, kto przeprowadzi go z Tobą, sprawdź, jak wygląda współpraca ze mną.