Nie myli się ten, kto nic nie robi. Błędy się zdarzają i często są wynikiem rutyny, pośpiechu lub chęci uproszczenia sobie życia. Najwygodniej jest opisywać grzechy kolegów i koleżanek. Jednak opisywane w tym artykule sytuacje dotyczą nas (pośrednio lub bezpośrednio). Człowiek uczy się całe życie, czyż nie?
Wolisz posłuchać? Sprawdź odcinek naszego podcastu ten temat:
Grzech 1 >> Używanie laptopów służbowych do działań prywatnych.
Wielu administratorów, ze względu na wygodę, łączy swoje prywatne życie z tym zawodowym, korzystając z jednego urządzenia do różnych celów. Choć może wydawać się to niewinne, takie postępowanie niesie ze sobą ogromne ryzyko.
Administratorzy często łączą się z krytycznymi elementami infrastruktury z tych samych laptopów, które później służą do przeglądania Internetu, robienia zakupów online czy korzystania z mediów społecznościowych. Tego typu praktyki mogą prowadzić do poważnych konsekwencji, zwłaszcza gdy nieświadomie ściągniemy na komputer złośliwe oprogramowanie.
Wirusy i Malware: Ściągając pliki z niepewnych źródeł lub klikając na podejrzane linki, administratorzy narażają całą infrastrukturę firmy na atak.
Phishing: Nawet doświadczeni specjaliści mogą paść ofiarą dobrze skonstruowanych ataków phishingowych, co może prowadzić do wykradzenia wrażliwych danych.
Utrata kontroli: W przypadku zainfekowania urządzenia, atakujący może uzyskać dostęp do krytycznych systemów firmy, co może skutkować poważnymi konsekwencjami finansowymi i reputacyjnymi.
Ransomeware: Utrata (szyfrowanie) danych – atakujący szyfruje dane organizacji, żądając okupu za klucze deszyfrujące.
Konsekwencje tego grzechu:
Zostaliśmy poproszeni o pomoc pewnej organizacji. Niestety okazało się, że już nie było to możliwe. Firma ta miała jednego administratora, który używał swojego służbowego laptopa do celów prywatnych. Pewna grupa hackerów zyskała dostęp do sieci firmowej przez jego laptopa. Przez długi czas obserwowali działania administratora, aż w końcu skoordynowali atak, szyfrując wszystkie produkcyjne dane. Co gorsza, backupy były przechowywane na OneDrive, który nie miał włączonego uwierzytelniania dwuskładnikowego (MFA). Efekt? Firma została zmuszona do zapłacenia okupu, aby odzyskać dane.
Jednak nie zawsze zapłata okupu skończy się z odszyfrowaniem!
Jak się zabezpieczyć?
Separacja środowisk. Administratorzy powinni korzystać z dedykowanych urządzeń do pracy.
Kopie bezpieczeństwa – przynajmniej jedna kopia bezpieczeństwa powinna być offline (odseparowana logicznie od infrastruktury produkcyjnej).
Regularne testy odtworzeniowe.
Chcesz obejrzeć rozmowę na ten temat? Sprawdź nagranie na naszym kanale YouTube:
Grzech 2 >> Brak dialogu z IT z Biznesem o SLA i ciągłości działania.
Zderzenie się z rzeczywistością, gdzie kopie zapasowe pochodzą sprzed tygodnia, choć biznes miał niewyrażone oczekiwania przywrócenia po incydencie danych z wczoraj, wywołuje frustrację i poczucie rozczarowania. Jak więc radzić sobie w takich sytuacjach?
Kluczową rolę odgrywa tutaj psychologia i komunikacja. W przypadku współpracy między działem IT a Biznesem niejednokrotnie dochodzi do braku porozumienia wynikającego z różnic w podejściu i niechęci do dialogu. Tymczasem, aby uniknąć nieporozumień i katastrof, niezbędna jest współpraca i wzajemne zrozumienie potrzeb. IT musi zinwentaryzować swoje zasoby, zweryfikować procedury backupowe i przetestować zdolność do odtworzenia poszczególnych systemów. To zadanie wymaga zarówno technicznego przygotowania, jak i współpracy z zewnętrznymi partnerami, jeśli wewnętrzne zasoby są niewystarczające.
Grzechy 3 & 4 >> Brak regularnych testów odtworzeniowych oraz procedur odtwarzania systemów po awarii
Brak regularnych testów może prowadzić do błędów, niepewności oraz obaw podczas faktycznej awarii, szczególnie w małych zespołach, gdzie jedna osoba odpowiada za całą infrastrukturę. Regularne ćwiczenie odtwarzania systemów redukuje stres związany z sytuacją awaryjną, podobnie jak ćwiczenia fizyczne pomagają utrzymać sprawność i tzw. pamięć mięśniową.
Kiedy przeprowadzać testy odtworzeniowe?
Dobre praktyki sugerują kilka sytuacji, kiedy testy odtworzeniowe powinny być wykonywane.
Po każdej znaczącej zmianie w systemie, takiej jak aktualizacja oprogramowania do backupu lub zmiana w infrastrukturze oraz usługach.
Przykład grzechu z życia wzięty
Jedna z organizacji odkryła, że wprowadzone zmiany w sieci uniemożliwiły działanie funkcji szybkiego odzyskiwania maszyn wirtualnych z backupu. Gdyby nie testy, ten problem mógłby wyjść na jaw dopiero podczas faktycznej awarii, co znacząco wydłużyłoby czas przywracania systemów. Testy po każdej zmianie, znacząco minimalizują ryzyko takich niespodzianek.
W większych organizacjach standardem jest przeprowadzanie pełnych testów disaster recovery co kwartał lub co pół roku. Częstotliwość ta pozwala na bieżąco weryfikować skuteczność procedur odtwarzania, a także utrzymanie zespołu w gotowości.
Ważne jest również regularne testowanie systemów krytycznych, w szczególności tych, które wymagają dodatkowych kroków przed lub po odtworzeniu danych.
Jednym z kluczowych powodów regularnego testowania jest rozwijanie tzw. pamięci mięśniowej zespołu. Podobnie jak piloci regularnie ćwiczą różne procedury, aby w sytuacjach kryzysowych działać automatycznie, zespoły IT powinny regularnie przeprowadzać testy odtworzeniowe, aby w sytuacji awarii zachować spokój i pewność siebie.
Ważnym aspektem testów jest także weryfikacja i możliwość aktualizacji dokumentacji technicznej środowiska oraz procedur odtworzeniowych, zarządzania incydentem, itd. Brak wiedzy o niuansach konfiguracji systemów, zwłaszcza tych zmodyfikowanych pod kątem specyficznych potrzeb organizacji, może skutkować wydłużeniem czasu przywracania organizacji do działania. Dobrze przygotowana dokumentacja powinna obejmować nie tylko techniczne kroki odtwarzania, ale również kontakt z dostawcami, SLA na poszczególne usługi oraz inne niezbędne informacje, które pomogą w szybkim rozwiązaniu problemu.
Grzech 5 >> „Szybkie ręce”, czyli jak drobne zmiany mogą wywołać poważną awarię.
Mówiąc 'szybkie ręce’, mamy na myśli kogoś, kto działa bardzo szybko…czasem za szybko. To często młodzi, pewni siebie administratorzy, którzy chcą udowodnić swoje doświadczenie i profesjonalizm. Niestety, taki pośpiech może prowadzić do poważnych problemów, nawet przy prostych zadaniach.
Jednym z częstych błędów jest ignorowanie potencjalnych ryzyk związanych z aktualizacjami systemowymi. Administrator, który setki razy wykonywał daną czynność, w pośpiechu może pominąć istotne kroki, takie jak backup czy weryfikacja stabilności oprogramowania po ewentualnej aktualizacji. Na przykład, wgranie nieprzetestowanej łatki systemowej bez sprawdzenia, potencjalnych problemów, może wywołać awarię serwera produkcyjnego.
Warto zarezerwować czas na przeprowadzenie aktualizacji w środowisku testowym, zamiast działać na żywym organizmie, bez przygotowania. Nawet jeśli dana procedura jest prosta, lepiej przewidzieć potencjalne problemy niż później walczyć z konsekwencjami. Podstawowe przygotowanie, takie jak stworzenie kopii zapasowej lub symulacja awarii, może oszczędzić mnóstwo czasu i stresu.
Grzech 6 >> Odkładanie działań na później, czyli kolejna metoda na awarię.
Aktualizacje oprogramowania, BIOS-ów, firmware’u czy systemów operacyjnych są regularnie wypuszczane przez producentów, a niektóre z nich mają status „critical”, co oznacza, że powinny zostać wdrożone jak najszybciej. Niestety, wiele firm nie podchodzi do tego zadania z odpowiednią systematycznością.
Często zdarza się, że serwery, macierze czy systemy operacyjne przez lata nie widziały aktualizacji. Systemy działają na oprogramowaniu, które nie było aktualizowane od czasu ich instalacji. W efekcie, gdy po kilku latach konieczne staje się wdrożenie nowych wersji, administratorzy muszą mierzyć się z dodatkowymi wyzwaniami. Pojawiają się wątpliwości: czy można bezpiecznie przejść na najnowszą wersję firmware’u, jeśli przez kilka lat nie aktualizowano systemu? Czy konieczne jest wgrywanie pośrednich wersji?
Co najczęściej powoduje takie „nagłe” aktualizacje? Często impulsem jest audyt – wewnętrzny lub zewnętrzny. Zmiana w strukturze firmy, np. nowy szef IT lub przejęcie przez inną firmę, może zmusić do uporządkowania infrastruktury IT. Przygotowanie do audytu ISO czy innych certyfikacji również bywa impulsem do szybkiego „malowania trawy na zielono”. Z tego powodu firmy zaczynają w pośpiechu aktualizować systemy, co często prowadzi do nieprzemyślanych działań i potencjalnych awarii.
Grzech 7 >> Aktualizacja krytycznej infrastruktury — jedni za szybko, drudzy za wolno.
Zbyt pośpieszne aktualizacje to kolejne ryzyko. W momencie, gdy zmiany są wprowadzane bez odpowiedniej analizy zależności, można łatwo popełnić błąd. Na przykład, podniesienie wersji firmware’u w macierzy bez jednoczesnej aktualizacji sterowników kart HBA w serwerach, może skutkować utratą komunikacji z macierzą, co w konsekwencji wywoła poważne problemy z działaniem systemów za sprawą braku dostępu do danych. Tego typu sytuacje wynikają z ignorowania dokumentacji (release notesów) lub pobieżnego przeglądania jej treści.
Wielu administratorów narzeka na brak czasu, aby na bieżąco śledzić zmiany, testować nowe rozwiązania i uczyć się obsługi nowych technologii. Często ich praca obejmuje również zadania dalekie od typowego zarządzania infrastrukturą IT, co powoduje, że aktualizacje stają się zadaniem drugorzędnym. W takiej sytuacji nawet przy najlepszych intencjach, trudno jest utrzymać środowisko w pełnej gotowości.
Rozwiązanie: outsourcing IT.
Jednym z rozwiązań, szczególnie w rozwijających się firmach, jest outsourcing niektórych procesów IT. Firmy specjalizujące się we wdrażaniu rozwiązań IT mogą pomóc administratorom nadążać za nowinkami i wspierać w testach oraz aktualizacjach. Dzięki temu administratorzy mogą skupić się na bieżącej pracy, a specjalistyczne zadania, takie jak krytyczne aktualizacje firmware’u czy zarządzanie złożonymi systemami, mogą być zlecane zewnętrznym partnerom. To pozwala na bezpieczne, rutynowe wdrożenia w odpowiednich momentach, bez ryzyka, że coś zostanie pominięte.
Grzech 8 >> Brak wsparcia (gwarancji) na infrastrukturę lub sprzętu zastępczego.
Pierwszą konsekwencją braku wykupionego wsparcia od producenta jest brak dostępu do aktualizacji, zwłaszcza tych krytycznych dla bezpieczeństwa. W takich przypadkach użytkownicy pozostają narażeni na niezałatane luki, co może być szczególnie ryzykowne w kontekście macierzy dyskowych czy serwerów kluczowych dla funkcjonowania biznesu.
Najważniejszą rzeczą, którą trzeba zrobić w sytuacji, gdy nie mamy wsparcia producenta, jest opracowanie planu awaryjnego. Strategia IT nie powinna opierać się tylko na zakupie nowego sprzętu czy wsparcia, ale także na elastycznych rozwiązaniach, które pozwalają radzić sobie z potencjalnymi problemami.
Jedną z opcji jest wirtualizacja systemów. Zamiast trzymać się przestarzałego sprzętu, warto rozważyć przeniesienie niektórych usług do chmury prywatnej lub publicznej. Możemy również zwirtualizować system na lokalnych platformach, co pozwoli uniezależnić się od fizycznych awarii sprzętu.
Kluczem do efektywnego zarządzania infrastrukturą bez wsparcia producenta jest szacowanie ryzyka. Czy wiemy, jakie części mogą ulec awarii i czy są dostępne na rynku wtórnym? Warto sprawdzić, czy jesteśmy w stanie kupić używane serwery, dyski czy przełączniki. W ten sposób można być przygotowanym na potencjalne problemy w przypadku braku wsparcia producenta.
Grzech 9 >> Używanie jednego konta administratora do wszystkich systemów.
Wielu administratorów IT preferuje wygodę, używając jednego hasła do różnych systemów. To błąd. Kluczowe jest stosowanie różnych haseł, najlepiej generowanych losowo i przechowywanie ich w zaszyfrowanych menedżerach haseł.
Dodatkowo, wdrożenie multifaktorowego uwierzytelniania (MFA) znacznie podnosi poziom bezpieczeństwa. Nawet jeśli hasło zostanie wykradzione, MFA wymaga dodatkowego potwierdzenia, np. na telefonie, co stanowi dodatkową warstwę ochrony.
Wybór pomiędzy wygodą a bezpieczeństwem jest kluczowy. Wdrożenie odpowiednich zasad ochrony, rozdzielenie kont i stosowanie MFA to najlepsze sposoby na minimalizację ryzyka i zabezpieczenie infrastruktury przed potencjalnymi atakami.
Grzech 10 >> Uprawnienia administratora na stacjach użytkowników.
Jeśli administrator loguje się na stacji użytkownika z pełnymi uprawnieniami, istnieje ryzyko, że jego dane logowania mogą zostać przechwycone. Zdarza się, że administratorzy wpisują swoje hasła na komputerach, które mogą być zainfekowane lub narażone na ataki. W ten sposób potencjalny atakujący, uzyskując dostęp do tych danych, może przejąć pełne uprawnienia w całym systemie.
Aby ograniczyć ryzyko, zaleca się stosowanie stacji przesiadkowych (jump stations) lub dedykowanych narzędzi do zdalnego zarządzania, które eliminują konieczność logowania się bezpośrednio na stacji roboczej użytkownika. W ten sposób minimalizuje się możliwość przechwycenia wrażliwych danych. Dodatkowo warto rozważyć nadanie użytkownikom jedynie niezbędnych uprawnień, aby ograniczyć ich wpływ na system w przypadku awarii lub ataku.
Podsumowując
Każdy z nas, niezależnie od roli, jaką pełni w firmie, powinien regularnie robić rachunek sumienia i oceniać swoje działania w kontekście bezpieczeństwa IT. Grzechy, które opisaliśmy w tym artykule, mogą wydawać się trywialne, ale ich konsekwencje są bardzo poważne. Wyeliminowanie ryzykownych praktyk, takich jak korzystanie z jednego konta do wszystkich systemów czy odkładanie aktualizacji na później, to dobry pierwszy krok na drodze do zwiększenia cyberbezpieczeństwa. Świadome podejmowanie decyzji, odpowiednia separacja środowisk, testy odtworzeniowe i współpraca między IT a Biznesem są kluczem do ochrony przed zagrożeniami.
Czy jesteś gotowy zrobić ten krok i zadbać o bezpieczeństwo w swojej organizacji?
W dobie cyfrowej rzeczywistości ataki phishingowe stanowią jedno z największych zagrożeń dla użytkowników internetu. Hakerzy wykorzystują techniki socjotechniczne, by przechwycić dane logowania, hasła czy informacje o kartach płatniczych w celu wyłudzenia poufnych danych. Ataki phishingowe są jednymi z najczęściej stosowanych metod oszustwa...
Wiele małych firm wykorzystuje sieciowe magazyny danych (NAS, ang. Network Attached Storage) jako centralne miejsce przechowywania i udostępniania plików. Dane przechowywane na tych urządzeniach są narażone na różnorodne zagrożenia, dlatego ważne jest, aby dbać o ich bezpieczeństwo. Urządzenia te (SOHO, ang. Small...
Phishing jest popularnym rodzajem cyberataku, wykorzystującym głównie pocztę email jako medium komunikacji z potencjalną ofiarą. Celem atakującego jest wyłudzenie informacji poprzez podszywanie się i stosowanie przeróżnych technik inżynierii społecznej.
Tworzenie polityk backupu i zarządzanie nimi wymaga stałej współpracy pomiędzy Biznesem a działem IT. Dopiero realny incydent i konieczność przywrócenia danych staje się przyczyną bardziej „systemowego” podejścia.
Wielu przedsiębiorców, zwłaszcza w początkowej fazie rozwoju firmy, decyduje się na współpracę z pojedynczym specjalistą IT. Czasami jest to konsultant systemu dziedzinowego, czasami znajomy kogoś w firmie, a czasami polecony usługodawca JDG, który obsługuje od jednego do kilku różnych...
Czy małe i średnie przedsiębiorstwa mogą skorzystać z najlepszych praktyk ITIL? Odpowiedź brzmi: zdecydowanie tak! W tym artykule pokażemy, jak inteligentnie wdrożyć kluczowe elementy ITIL 4 w organizacji liczącej 20-100 pracowników, nie wydając fortuny na skomplikowane systemy. Dlaczego ITIL...
