Awaria dużego dostawcy usług internetowych zazwyczaj wiąże się z niedostępnością wielu innych miejsc w sieci. Dla wielu przedsiębiorców takie zdarzenie jak pożar w OVH może oznaczać niewyobrażalne straty. Nieoficjalne informacje na temat awarii wskazują na fakt, iż niektórzy klienci mogą nie odzyskać utraconych w wyniku incydentu danych.
W trakcie przygotowywania materiału, poprosiliśmy o komentarz Pana Rafała Jaworskiego, COO ProtectHut. O informacje dotyczące awarii poprosiliśmy również OVH, a poniższy materiał to owoc doświadczeń wielu specjalistów z branży IT zajmujących się tematyką serwerową / cloud. Gdy tylko OVH ustosunkuje się do naszych pytań, dodamy komentarz i przekażemy Wam informacje o aktualizacji.
Czytaj więcej: Zakaz dzielenia kont będzie testem dla Netflixa i… może go oblać
10 marca, późną nocą doszło do katastrofalnego w skutkach pożaru w infrastrukturze OVH. O godzinie 00:47 w jednym z 4 centrów danych OVH w Strasburgu (SBG2) pojawił się ogień, który trwał do wczesnych godzin porannych. Niemal doszczętnie spłonęło centrum danych SGB2, a SGB1 zostało częściowo uszkodzone (4 zniszczone pomieszczenia na 12). W momencie tworzenia tego materiału, serwery SGB3 oraz SGB4 są wyłączone, jednak nie są uszkodzone. Obecnie nieznane są przyczyny tego zdarzenia - służby porządkowe oraz oddelegowani specjalnie do tego zadania pracownicy OVH sprawdzają, jakie okoliczności doprowadziły do pożaru.
(dane: serwis dla prasy OVH)
AW: Czy pożar w OVH oraz jego skutki to zdarzenie bezprecedensowe? Trudno wskazać podobne wydarzenie pod względem okoliczności i jego konsekwencji - czy w OVH na pierwszy rzut oka cokolwiek zawiodło? Czy problemem były zabezpieczenia przed skutkami działania ognia, a może dostawca prawdopodobnie nie zadbał wystarczająco o kopie zapasowe danych zgromadzonych na serwerach?
Rafał Jaworski: Zdecydowanie to niecodzienna sytuacja, jednak nie jest to pierwsza poważna awaria, która przydarzyła się tej firmie. W 2017 roku po zaniku zasilania nie zastartowały generatory prądu, co wiązało się ze sporymi utrudnieniami w dostępie do usług na terenie Europy. Pożary w centrach danych zdarzały się także na terenie Polski u innych operatorów. Jest jeszcze za wcześnie aby mówić o tym, czy jakieś dane zostały utracone bezpowrotnie, z pewnością będziemy się o tym dowiadywać w najbliższych dniach. Jednak część serwisów obsługiwanych przez OVH nadal nie funkcjonuje co świadczy o skali problemu.
Mimo tego, że firma OVH świadczyła usługi chmurowe, to jednak dane te, były fizycznie przechowywane. W tym wypadku na serwerach, które uległy zniszczeniu. Dlatego każda firma powinna zastanowić się, jakie elementy są krytyczne z punktu widzenia zachowania swojej ciągłości biznesowej i stworzyć plan, który umożliwi odpowiednie reagowanie na ewentualny kryzys w postaci utraty danych.
Jesteśmy świeżo po katastrofalnym wydarzeniu w Strasburgu: OVH pracuje nad przywróceniem dostępności usług oraz ratowaniem danych klientów. Obecnie nie ma żadnej wiążącej informacji po stronie dostawcy usług chmurowych, czy nastąpi trwała utrata jakichkolwiek informacji należących do osób, które trzymały tam swoje dane. Nieoficjalnie - jak wskazaliśmy wyżej - mówi się jednak o tym, że niektórzy klienci będą musieli liczyć się z tym, że ich dane zwyczajnie są nie do odzyskania. Trzeba sobie w tym miejscu zadać pytanie: czy można zabezpieczyć się przed takimi wypadkami? Oczywiście, że można. Spójrzmy na to, jak wygląda to po stronie biznesu korzystającego z usług chmurowych innego podmiotu oraz przedsiębiorstwa, które samo w sobie oferuje rozwiązania w chmurze / hosting.
W przypadku takich miejsc jak serwerownie (bo przecież usługi chmurowe w dalszym ciągu wymagają korzystania z serwerów, ale to raczej oczywiste), istnieje wiele możliwości wystąpienia katastrofalnych w skutkach incydentów. Przede wszystkim, standardem w tej branży jest bardzo dokładna ocena ryzyka pożarowego w pomieszczeniach, gdzie staną nie tylko same serwery, ale również w kontekście innych pomieszczeń. Generalnie, cały budynek, w którym ma stanąć serwerownia powinien zostać pod tym kątem prześwietlony: po pierwsze oszacowuje się ryzyko wystąpienia konkretnych scenariuszy pożarowych, a następnie określa się możliwe skutki zagrożenia w wyniku zrealizowania danego scenariusza. To rzecz jasna bardzo uproszczone rozważanie na temat oceny ryzyka pożarowego: jednak w mniej więcej takim właśnie trybie rozpatruje się możliwość wystąpienia takiego wypadku i w oparciu o znalezione "wadliwe punkty" konstruuje się metody przeciwdziałania wystąpieniu pożaru.
W przypadku centrów danych stosuje się standard NFPA 75 i NFPA 76, które określają jasno dobre praktyki dotyczące zapobieganiu pożarom oraz ich skutkom w miejscach, gdzie znajdują się urządzenia teleinformatyczne. Standard obejmuje nie tylko zasady, wedle których należy postępować, by nie zwiększać ryzyka zaprószenia ognia, ale również m. in., w jaki sposób walczy się z już powstałymi incydentami - jakie urządzenia instaluje się, by szybko zagasić ogień jak powinno się budować centra danych, by pożar nie spowodował ogromnych szkód, w jaki sposób powinni zachowywać się pracownicy i tak dalej. O standardzie NFPA można napisać mnóstwo. Pewne jest jednak to, że kierowanie się jego wytycznymi pozwala na istotne zmniejszenie ryzyka wystąpienia awarii spowodowanej ogniem w centrum danych. Wiadomo więc, że już na etapie projektowania, budowy takiego obiektu - można zrobić mnóstwo.
Nie bez znaczenia jest również wentylacja pomieszczeń serwerowych: przegrzewanie się urządzeń to jedna z przyczyn ich awarii, a konsekwencją bardzo mocnego przegrzania się może być pożar. Systemy odpowiedzialne za chłodzenie sprzętów, czujniki temperatury to niezwykle istotne części mechanizmów prewencji. Dobrze jest, gdy osoba odpowiedzialna za bezpieczeństwo pomieszczeń serwerowych wie zawczasu, że w pewnym miejscu dochodzi do niepożądanych wzrostów temperatury. Rzecz jasna bardzo ważne są również regularne inspekcje, ćwiczenia oraz szkolenia dla personelu IT, który powinien wiedzieć, jak zachować się w sytuacji kryzysowej.
Dla infrastruktury dostawcy usług internetowych zabójczy może być brak prądu lub... niespodziewany wzrost jego parametrów. Stosuje się liczne systemy zabezpieczające serwerownie przed takimi wypadkami. W przypadku niespodziewanego braku prądu, serwerownie dysponują przemysłowymi UPS-ami do zadań specjalnych o odpowiedniej pojemności baterii dopasowanej do zużycia generowanego przez instalację oraz maksymalnego czasu pracy na zasilaniu awaryjnym.
W przypadku niektórych lokalizacji, warto określić szczególne rodzaje ryzyka wystąpienia zdarzeń losowych: na przykład trzęsień ziemi lub powodzi. W przypadku incydentalnych zalań (o ile do nich dojdzie), w serwerowniach istnieją procedury postępowania w takich sytuacjach i personel jest zazwyczaj co do nich przeszkolony. Budynki, w których znajdują się serwery są dodatkowo zabezpieczone w taki sposób, aby zminimalizować ryzyko zniszczenia nośników, na których znajdują się dane. W przypadku katastrofalnych trzęsień ziemi nie dba się o to, by zapewnić ciągłą dostępność usług: raczej próbuje się uratować przynajmniej informacje zgromadzone na serwerach. Zasadniczo, wybierając miejsce dla serwerowni, próbuje się wybrać taką lokalizację, w której ryzyko incydentów sejsmicznych jest możliwie jak najniższe. Dba się także o to, by nie każdy mógł wchodzić do serwerowni: by dostęp do niej był ograniczony do osób, które odpowiednio przeszkolone do obchodzenia się z tymi urządzeniami. W wielu przypadkach zawodzi czynnik ludzki - tego typu incydenty warto ograniczyć do minimum.
Dajmy na to, że wszystko zawiodło - urządzenia i tak się zniszczyły, nośniki wyparowały, stało się cokolwiek, co spowodowało ich utratę / fizyczne uszkodzenie. W takiej sytuacji mogą przydać się kopie zapasowe. Tanim, choć nie doskonałym sposobem na stworzenie "zapasu" jest backup onsite. Każdy z Was kiedyś pewnie przeprowadził taki typ backupu: być może robiliście kopię swoich informacji na dysk zewnętrzny, który potem trzymaliście w szafie w tym samym domu, gdzie znajduje się "maszyna macierzysta"? A może zapisywaliście kopie ulubionych utworów na płycie CD lub pendrive'ie?
Podobnie robi się w przypadku serwerowni. W tym samym budynku wydziela się urządzenie lub nośniki, gdzie przechowuje się kopie zapasowe tworzone z określoną częstotliwością. Może być również tak (i najczęściej tak jest), że taka kopia zapasowa tworzona jest automatycznie poprzez połączenie między serwerem, a maszyną z nośnikiem na backupy. Nawet, gdy maszyna macierzysta zostanie uszkodzona i dane będą nie do odratowania - sprzęt wykorzystany w ramach onsite backupu będzie je mieć.
Można wykorzystać również backup offsite - wtedy kopia zapasowa znajduje się w innej lokalizacji, niż macierzysta. I znowu Was zaskoczę - jeżeli robiliście kiedyś backup w formie obrazu Waszego systemu i wysłaliście go do chmury, przeprowadziliście backup offsite. Tego typu kopia zapasowa to bardzo często element szerszego planu zarządzania kryzysowego (technicznie: disaster recovery plan). W przypadku takiego backupu mamy pewność, że nawet jak serwerownia zostanie zdmuchnięta z powierzchni ziemi, mamy drugą lokalizację, która pozwoli nam odtworzyć utracone informacje.
Generalnie każdy z tych sposobów tworzenia kopii zapasowej ma swoje wady i zalety. Backup onsite pozwala na niemal natychmiastowy dostęp do informacji, jest on tańszy, ale w przypadku, gdy zniszczony zostanie cały budynek - tracimy wszystko. Offsite backup natomiast jest droższy, bardziej problematyczny, ale znacznie pewniejszy. Trudno sobie wyobrazić, by dwie lokalizacje z tymi samymi danymi zostały uszkodzone z powodu np. pożaru. No, chyba że mówimy o skoordynowanym ataku na centra danych. Niemniej, oceniając ryzyko takiego wypadku można uznać, że jest to bardzo rzadka ewentualność.
Jak widać, dostawcy usług internetowych mają spory wachlarz metod obrony przed wypadkami losowymi w zakresie zapobiegania im oraz minimalizacji skutków tychże. Co można zauważyć na podstawie przypadku OVH, nawet wysokie standardy co do bezpieczeństwa fizycznego zgromadzonych informacji / usług mogą nie wystarczyć.
Zacznijmy od tego, że mnóstwo firm, podmiotów ucierpiało z powodu wypadku w OVH. Między innymi Katolicka Agencja Informacyjna, witryna TOPR, Świat Gry, MMARocks, Bonito.pl bardzo mocno odczuły skutki tego incydentu. Ci sprzedawcy, którzy korzystali na Allegro z Baselinkera, mieli spore problemy z jego działaniem, co skutecznie utrudniało im zarządzanie przedmiotami wystawionymi w serwisie. W momencie pisania tego wpisu, portal eKAI.pl w dalszym ciągu jest niedostępny. MMARocks również zgłasza problem techniczny.
Z usług OVH korzystał również największy polski serwis erotyczny: zbiornik.com. Witryna bardzo mocno ucierpiała: obecnie wyświetlany jest monit o awarii w OVH oraz aktualizacje bazujące na komunikatach ze strony usługodawcy:
Aktualizacja 2021-03-12 07:31
Ze wstępnych ustaleń wynika, iż czeka nas dosyć mozolny proces łączenia ocalałych danych z lokalnymi kopiami zapasowymi. Niemniej finalny efekt powinien być zadowalający biorąc pod uwagę skalę zniszczeń.
W segmencie SBG2 do chmury odeszło ponad 20 serwerów ['][']['] Więcej informacji wkrótce.
Najnowsza aktualizacja w witrynie Zbiornik.com
Wygląda więc na to, że wiele biznesów będzie musiała polegać na lokalnych kopiach zapasowych - czyli takich, które były gromadzone np. w siedzibie przedsiębiorstwa. Co jednak w sytuacji, gdy nikt kopii zapasowych nie robił w ogóle? To osobny problem - najprawdopodobniej wiele osób, podmiotów będzie musiała nauczyć się tego, że backupy mieć należy zawsze - niezależnie od tego, co robimy i o jakie dane chodzi.
Rafał Jaworski: Każda firma powinna mieć wdrożoną strategię zachowania ciągłości biznesowej zwaną BCP (ang. Business Continuity Plan), wspartej procedurami z zakresu zarządzania kryzysowego, czyli DR (ang. Disaster Recovery).
W wielu przypadkach poza wdrożeniem chmury, co z założenia powinno zapewnić nam bezpieczeństwo, warto też pochylić się nad odpowiednim podejściem do kwestii tworzenia kopii zapasowych (ang. Backup Management). Jak pokazują doświadczenia wzięte z życia, nie wystarczy tylko takie kopie posiadać. Należy bowiem je regularnie testować i tworzyć w sposób, który będzie kompatybilny z całą strategią wspierania naszego biznesu, aby nagle nie przestał on działać. Niejednokrotnie spotykałem się z sytuacją, w której klienci posiadali kopie zapasowe, ale nikt nie potrafił z nich skorzystać i w dodatku były one sporadycznie aktualizowane.
Ochrona przed utratą danych nie musi wiązać się z dużymi kosztami. Często koszt dla klienta chcącego podejść odpowiednio do tematu, w znacznej mierze ograniczony jest do czasu potrzebnego na dokonanie audytu bezpieczeństwa, by sprawdzić jakie w danym przypadku występują elementy ryzyka i czy są one przez nas w odpowiedni sposób adresowane.
Zarządzający organizacjami na całym świecie często błędnie rozpoczynają od ostatniego kroku, jakim jest analiza rozwiązań technologicznych. Oczywiście zdarza się, że rekomendowane jest wdrożenie dodatkowych elementów infrastruktury informatycznej, ale nie zawsze musi to oznaczać dodatkowy koszt. Czasem jest to usprawnienie w ramach posiadanych już elementów.
Przedsiębiorca musi zadać sobie pytanie – co mi się bardziej opłaca? Jakie będą koszty związane z brakiem możliwości prowadzenia biznesu przez dzień, trzy, a może miesiąc? A jeżeli dane klientów lub projektu zostaną bezpowrotnie utracone?
Zasadniczo, idealną sytuacją byłaby ta, w której każde przedsiębiorstwo ma swoje procedury dotyczące Disaster Recovery. W przypadku przedsiębiorstw, stosuje się takie rozwiązania jak chociażby outsourcing backupów, gdzie podmioty otrzymują pomoc w zakresie konfiguracji miejsca kopii zapasowej zgodnie z wytycznymi, instalacji oprogramowania, które będzie konieczne do wykonywania kopii zapasowej, testowania procesu odtwarzania informacji, odtwarzania danych i wdrażanie ich na nowej infrastrukturze (łącząc je np. z pozostałościami na serwerze, gdzie doszło do awarii) oraz składowania backupów. Istnieje mnóstwo podmiotów, które udostępniają usługę outsourcingu backupów w kompleksowej formie.
Inną rzeczą jest Business Continuity Plan, którego częścią jest Disaster Recovery: w momencie, gdy ogromna część newralgicznych procesów w przedsiębiorstwie przetwarzana jest w sieci, na zewnętrznych serwerach, należy sobie zadać pytanie: "co w momencie, gdy infrastruktura utrzymująca moje dane niespodziewanie padnie?". A także: "co w sytuacji, gdy po takiej awarii dane będą nie do odzyskania?". Właśnie po to tworzy się tego typu procedury, scenariusze i dopasowuje do nich rozwiązania pozwalające spać spokojnie w sytuacji, gdy stanie się coś naprawdę niedobrego.
Czytaj więcej: OnePlus 9 – wszystko co o nim wiemy przed premierą
Wychodzi więc na to, że zarówno klienci usług hostingowych / cloud, a także sami dostawcy tego typu rozwiązań mają narzędzia, które pozwalają na zabezpieczenie się przed zdarzeniami losowymi, które mogą doprowadzić do utraty cennych danych. Niestety, jak wynika z doświadczeń moich, osób, które pytałem o biznes hostingowy / cloudowy, a także mojego eksperta - w relatywnie niewielu przedsiębiorstwach bierze się pod uwagę przygotowanie planu naprawczego odnoszącego się do sytuacji takich, jak ta, do której doszło w infrastrukturze OVH.
AW: Jak wiele biznesów działających w internecie (mowa o klientach dostawców usług cloud / hosting) aktywnie zabezpiecza się przed podobnymi zdarzeniami jak w OVH? Czy są znane jakiekolwiek dane na ten temat?
Rafał Jaworski: Nie ma oficjalnych danych w tym zakresie jednak z czasem pewnie poznamy skalę zniszczeń. Pierwszymi wskaźnikami będzie to, ile firm korzystających z usług wróciło do normalnego funkcjonowania. Jeżeli zrobiły to szybko – oznacza to, że ich procedury zadziałały. Jednak wiele firm funkcjonuje w przekonaniu, że skoro korzystają z zewnętrznego dostawy danego rozwiązania, to na jego barkach spoczywa potrzeba zabezpieczenia przed zdarzeniami losowymi czy atakami hakerów.
Prawda jest jednak taka, że jeśli sami nie pomyślimy o naszym bezpieczeństwie to nikt za nas tego nie zrobi. Na koniec dnia bowiem w przypadku kryzysu może się okazać, że nasz biznes przestał działać, a dostawca poinformuje nas w oficjalnym komunikacie, że nie może pomóc i powinniśmy wdrożyć swoje własne procedury bezpieczeństwa.
Paradoks całej sytuacji polega jednak na tym, że będą to te same procedury, których nie wdrożyliśmy, gdyż pierwotnie założyliśmy, że w razie czego uzyskamy wsparcie od partnera, który okazał się być akurat źródłem problemu.
Podobnie jak w przypadku dodatkowego ubezpieczenia zdrowotnego, ubezpieczenia na życie, dodatkowych poduszek powietrznych, systemów bezpieczeństwa w aucie, tak samo w świecie IT: rozwiązania zmierzające do minimalizowania skutków takich awarii jak ta, która wydarzyła się w OVH mogą się nigdy nam nie przydać. Może okazać się bowiem, że będziemy mieć szczęście i nic strasznego naszym danym się nie przydarzy. Jednak czy wtedy uznamy, że wyrzuciliśmy nasze pieniądze, czas, zaangażowanie w błoto? Nie. Nigdy nie wiemy, czy jutro nie stanie się coś, co zagrozi informacjom istotnym dla naszego biznesu. Nie wiemy też, czy jutro nie okaże się, że dodatkowe ubezpieczenie zdrowotne lub multum poduszek powietrznych uratują nasze życie.
Gdybyśmy mieli zdolność przewidywania tego typu zdarzeń z dokładnością do dni, momentów - pewnie nie potrzebowalibyśmy takich zabezpieczeń. Najlepsze co możemy zrobić dla biznesu osadzonego w internecie, to procedury dotyczące zarządzania kryzysowego. Usługodawcy hostingowi po swojej stronie mogą zrobić wiele, ale i to może nie wystarczyć. Warto o tym pamiętać.
Hej, jesteśmy na Google News - Obserwuj to, co ważne w techu
