Backup to dopiero początek

Doświadczenia zdobyte przy realizacji projektów dla infrastruktury krytycznej – m.in. dla Polskiej Grupy Energetycznej – pokazują, że skuteczna cyberodporność wymaga dziś nie tylko backupu, ale także sprawnego odtwarzania systemów i wykorzystania chmury. Dodatkowo regulacje NIS2 i UKSC przenoszą odpowiedzialność za ten obszar na poziom zarządów i architekturę IT.

Wywiad Adama Jadczaka z Arturem Kamińskim, CTO w ApexIT.

Jak pozycjonujecie swoje kompetencje w obszarze ochrony danych, backupu, systemów pamięci masowych i odporności infrastruktury? Jak to się wpisuje w szerszą strategię usług cyberbezpieczeństwa dla operatorów infrastruktury krytycznej?

Zacząłbym od krótkiego rysu historycznego, bo on tłumaczy, skąd biorą się nasze dzisiejsze kompetencje. Gdy dołączyłem do ApexIT, była to czteroosobowa firma. Postawiliśmy na to, na czym świetnie się znaliśmy – data center w szerokim tego słowa znaczeniu. To są nasze korzenie i do dziś kluczowa kompetencja. Mamy bardzo mocny zespół i duże doświadczenie w projektowaniu oraz wdrażaniu infrastruktury data center dla sektorów: publicznego, energetycznego, paliwowego i transportowego.

Dla klientów z tych branż jesteśmy przede wszystkim partnerem od projektowania i wdrażania infrastruktury centrum danych. Na bazie tych kompetencji naturalnie rozwijaliśmy kolejne specjalizacje. Następnym logicznym krokiem było zbudowanie zespołu zajmującego się ochroną danych i ciągłością działania. Ten zespół, podobnie jak od rozwiązań data center, tworzą ludzie z wieloletnim doświadczeniem, zdobytym w czasie najbardziej wymagających projektów na rynku.

Kluczową rolę odegrał projekt migracji systemu backupowego dla Polskiej Grupy Energetycznej. Była to migracja z istniejącego systemu do nowego rozwiązania, w bardzo dużym środowisku, obejmującym ok. 4500 obiektów – baz danych, aplikacji, systemów, serwerów, maszyn wirtualnych. Jak na polski rynek jest to liczba naprawdę znacząca.

Celem projektu było stworzenie systemu, który spełnia wymagania operatora infrastruktury krytycznej: z jednej strony narażonego na szeroko rozumiane cyberzagrożenia, z drugiej – mającego absolutnie krytyczny wymóg ciągłości działania dla odbiorców i całego rynku.

Naszym głównym wyzwaniem były konfiguracja i wdrożenie systemu, który spełnia wymagania takiego podmiotu jak PGE, oraz przeprowadzenie migracji w taki sposób, by nie zakłócić bieżącej eksploatacji i ani na moment nie pozostawić klienta bez sprawnego backupu. Ten projekt był dla nas krokiem milowym. Od tamtego czasu minęły już ponad 4 lata, a my zrealizowaliśmy kolejne duże wdrożenia podobnych środowisk.

Dziś nasze DNA to wciąż data center, ochrona danych, pamięci masowe i kopie zapasowe. W obszarze ochrony danych współpracujemy również z liderami rynku backupu i cyberodporności, takimi jak Commvault i Cohesity, dzięki czemu możemy projektować i wdrażać rozwiązania spełniające najwyższe wymagania dotyczące bezpieczeństwa, odtwarzania danych oraz ciągłości działania. Równolegle rozwijamy obszar bardziej klasycznie rozumianego cyberbezpieczeństwa. W tym zakresie realizujemy projekty oparte m.in. na rozwiązaniach Fortinet i Trend Micro. Sprzętowo jesteśmy partnerem HPE (w tym Aruba i Juniper) oraz Della. Ich infrastrukturę wykorzystujemy w projektach data center i systemach ochrony danych.

Pracujemy też z polskimi dostawcami. Dobrym przykładem jest DBPlus, który obok monitorowania wydajności baz danych, ma bardzo mocny silnik replikacyjny używany w scenariuszach Disaster Recovery.

Wydaje mi się, że w kontekście NIS2 i UKSC regulator coraz większy nacisk kładzie nie na sam backup, lecz na możliwość i czas odtworzenia po awarii. Czy to zmienia sposób, w jaki projektujecie rozwiązania dla klientów?

Masz absolutną rację, backup jest wart tyle, ile realna możliwość odtworzenia zapisanych danych. To było prawdą już 20 lat temu i jest dzisiaj. Tylko skala konsekwencji i złożoność środowisk bardzo się zmieniły.

Backup wykonuje się po to, aby się z niego odtworzyć, a z tego wynikają konkretne wymagania – konieczność regularnego testowania backupów i posiadania procedur odtworzeniowych dla poszczególnych systemów. Trzeba też myśleć o bezpieczeństwie danych, a nie o „samej kopii”.

Odtworzenie złożonej aplikacji rzadko jest prostą operacją, którą może wykonać wyłącznie administrator backupu. Często wymaga to zaangażowania zespołu znającego architekturę danej aplikacji, jej zależności i sposób działania.

Pierwszy, kluczowy punkt to właśnie odtwarzalność: potwierdzona technicznie – da się odczytać dane z nośnika – i proceduralnie – organizacja ma zespół i procesy, które wiedzą, jak to zrobić. Drugi punkt to czas odtworzenia, który dziś staje się jednym z głównych parametrów biznesowych.

Organizacje są w trakcie lub po transformacjach cyfrowych, biznes jest mocno uzależniony od danych i systemów, więc każdy przestój oznacza realne straty. Albo cierpi klient, albo my, jako obywatele, gdy niedostępne stają się krytyczne usługi państwa. Z tego wynika presja na minimalizację czasu odtworzenia. To z kolei przekłada się na dobór technologii. Stąd rosnąca popularność szybkich, flashowych systemów pamięci masowych jako celów backupowych.

Trzeci obszar to zmiana charakteru zagrożeń. Przez wiele lat backup projektowało się głównie pod kątem awarii sprzętu, błędów ludzkich czy błędów aplikacji – krótko mówiąc, zdarzeń wewnętrznych, po których cofaliśmy się do ostatniej dobrej kopii. Ransomware tę optykę zmienił. Dziś realnym scenariuszem jest utrata danych we wszystkich kluczowych systemach jednocześnie albo utrata zaufania do naszych danych, bo wiemy, że środowisko jest zainfekowane.

To niesie dwie konsekwencje. Po pierwsze, możemy mieć potrzebę masowego odtworzenia praktycznie całej infrastruktury IT, a nie pojedynczej bazy danych czy aplikacji. Radykalnie podnosi to wymagania wydajnościowe wobec systemu backupowego. Po drugie, w praktyce zdarza się, że po pierwszym odtworzeniu, odtwarzamy również malware, który ponownie szyfruje środowisko. Dlatego dziś mówimy nie tylko o odtworzeniu danych, ale o odtworzeniu ich do środowiska, któremu znowu możemy zaufać.

W efekcie coraz częściej najszybszy storage w data center jest tym, który obsługuje systemy backupowe. Wymagania wydajnościowe na potrzeby masowego odtwarzania są wyższe niż dla części produkcyjnych systemów biznesowych.

Jak w związku z tym zmienia się sposób projektowania samych systemów backupu? Robi się więcej kopii, stosuje się inne mechanizmy, aby mieć pewność, że któraś z nich będzie wolna od ransomware?

Projekty systemów ochrony danych są obecnie znacznie bardziej złożone i wielowarstwowe. Po pierwsze, budujemy kilka kopii służących różnym celom – szybkiemu odtwarzaniu, długoterminowej archiwizacji, czy właśnie byciu „ostatnią deską ratunku”. Stąd rozwiązania typu „złota kopia”, trzymana w innej lokalizacji lub na nośnikach, do których – ze względu na zastosowane protokoły – atakujący nie ma łatwego dostępu.

W tym kontekście coraz bardziej istotną rolę odgrywa chmura obliczeniowa. Często staje się miejscem przechowywania tej ostatniej, odizolowanej kopii. Z jednej strony wykorzystujemy fizyczne i logiczne odseparowanie od środowiska klienta, z drugiej – regulacje, zwłaszcza nowelizacja Ustawy o Krajowym Systemie Cyberbezpieczeństwa, wręcz zalecają uwzględnianie chmury w planach ciągłości działania.

W projekcie instrukcji dla operatorów infrastruktury krytycznej pojawia się wprost zapis o konieczności posiadania i aktualizowania planu ewakuacji danych do chmury obliczeniowej na wypadek utraty własnych obiektów przetwarzania. Powodem może być np. ryzyko ataku kinetycznego za pomocą dronów.

W praktyce dla części klientów wdrażamy scenariusze, w których połączenie z chmurą otwierane jest tylko na czas wykonywania kopii, a dane w chmurze szyfrowane są kluczami zarządzanymi przez klienta, zgodnie z jego procedurami. Ze względu na model kosztowy chmury publicznej zakładamy, że dane stamtąd odczytujemy tylko w sytuacji utraty wszystkich kopii lokalnych lub utraty zaufania do nich.

Z takich rozwiązań korzystają zarówno instytucje finansowe, jak i operatorzy infrastruktury krytycznej, którzy na co dzień mają większość systemów „on premise”, a chmurę traktują jako trzecią, odizolowaną lokalizację.

Jest też grupa klientów, którzy z powodów regulacyjnych lub organizacyjnych wolą przenieść cechy chmury – głównie obiektowe systemy pamięci masowych, dostępne za pośrednictwem protokołu S3 (Simple Storage Service – przyp. red.) – do środowisk własnych. Wtedy budujemy obiektowe zasoby on-premise, np. w dodatkowej lokalizacji firmy, służące jako cel długoterminowego przechowywania backupów.

Wspomniałeś o storage’u obiektowym i protokole S3. Dlaczego to tak ważny trend w kontekście bezpieczeństwa danych i ransomware?

Storage obiektowy stał się jednym z kluczowych elementów nowoczesnych systemów ochrony danych z kilku powodów. Po pierwsze, pozwala w racjonalny ekonomicznie sposób przechowywać bardzo duże wolumeny danych. Mówimy o zbiorach wielkości rzędu PB. W energetyce czy sektorze utilities takie ilości danych przestają być wyjątkiem.

Po drugie, dostęp do danych po protokole S3, czyli przez REST API, tworzy bardzo silną barierę dla typowych ataków ransomware. Te skupiają się na szyfrowaniu dysków lokalnych i zasobów dostępnych po protokołach plikowych typu NFS czy SMB.

Na dziś nie ma publicznych doniesień o skutecznych atakach ransomware, które doprowadziłyby do zaszyfrowania lub usunięcia danych składowanych w pamięci obiektowej. Oczywiście to nie znaczy, że takie zagrożenie nigdy się nie pojawi. W praktyce stanowi to realną barierę, którą trudno jest przekroczyć złośliwemu oprogramowaniu.

Storage obiektowy oferuje też możliwość zablokowania usuwania lub modyfikacji zapisanych danych na określony czas lub na stałe. Dzięki temu można budować wielowarstwowe zabezpieczenia. Nawet gdyby ktoś uzyskał dostęp do systemu, nie będzie w stanie manipulować danymi w wybranym przedziale czasu ich retencji.

To wszystko składa się na nowoczesną interpretację zasady 3-2-1, która dziś coraz częściej rozszerza się do 3-2-1-1-0: 3 kopie danych, na 2 różnych typach nośników, 1 poza lokalizacją chronioną, 1 kopia niemutowalna, offline oraz 0 błędów w backupie dzięki regularnej weryfikacji i testom ich odtwarzania.

Rozumiem, że energetyka i inne sektory infrastruktury krytycznej już dziś korzystają z takich rozwiązań?

Tak, to już się dzieje. Część klientów buduje storage obiektowy we własnych lokalizacjach lub w kolokacjach, szczególnie tam, gdzie regulacje ograniczają możliwość wykorzystania chmury publicznej do przetwarzania określonych kategorii danych. Inni – tam gdzie jest to możliwe – wykorzystują chmurę publiczną wprost jako trzecią lokalizację, trzymając tam złote kopie backupów.

Mówimy o organizacjach, które na co dzień nie są Cloud Native. Większość ich systemów działa on-premise. Ale chmura jest wpisana w ich plany ciągłości działania. Ten trend został dodatkowo wzmocniony doświadczeniami ukraińskimi. Tam ciągłość działania państwa była w dużej mierze zabezpieczona dzięki możliwości odtworzenia systemów w chmurze.

To przełożyło się na konkretne zalecenia w polskich dokumentach. Chmura publiczna ma być rozważana zarówno jako środowisko awaryjnego uruchomienia usług, jak i odizolowane repozytorium danych. Realizowaliśmy już takie projekty zarówno w sektorze finansowym, jak i u firm zarządzających infrastrukturą krytyczną.

Jakiego rodzaju scenariusze awarii, ataków i błędów ludzkich bierzecie pod uwagę, projektując systemy pamięci masowych i backupu dla dostawców infrastruktury krytycznej?

Zaczynaliśmy od bardzo „klasycznych” scenariuszy: awarii sprzętu, błędów ludzkich, błędów na poziomie oprogramowania, które prowadziły do uszkodzenia danych. Długo to te przypadki – stosunkowo łatwe do zrozumienia – były głównym uzasadnieniem inwestycji w backup. Co ciekawe, dziś awarie sprzętu klasy Enterprise zdarzają się niezwykle rzadko.

Natomiast mamy przykłady, gdzie przyczyną utraty danych był malware, a odtwarzanie było reakcją na incydent bezpieczeństwa. Te scenariusze są bardziej złożone organizacyjnie i jednocześnie dużo bardziej prawdopodobne niż klasyczne awarie sprzętu. Ransomware wymusza znacznie szersze podejście. Obejmuje nie tylko dział IT, lecz także cyberbezpieczeństwo, użytkowników końcowych czy procesy decyzyjne w organizacji.

Po pierwsze bowiem, trzeba zdiagnozować, które systemy zostały zaszyfrowane lub skompromitowane, które wymagają „wyleczenia”, aby nie doprowadzić do ponownego szyfrowania po odtworzeniu. Po drugie, należy pogodzić się z tym, że odtwarzanie może obejmować wiele systemów równocześnie. Wymaga to innej architektury i mocy systemu backupowego niż, gdy – typowym scenariuszem – była awaria jednego serwera.

W konsekwencji projektujemy systemy zabezpieczenia danych z myślą o dwóch klasach zagrożeń: rzadkich, ale wciąż możliwych awariach technicznych oraz znacznie częstszych incydentach bezpieczeństwa wynikających z działalności cyberprzestępców.

NIS2 i KSC wprowadzają większą odpowiedzialność zarządów za cyberbezpieczeństwo. Czy to zmienia perspektywę realizacji projektów backupu i ciągłości działania? Czy też w sektorach infrastruktury krytycznej i tak był już to temat „na agendzie zarządów”?

Tak i nie. Z jednej strony regulacje zdecydowanie pomagają osobom odpowiedzialnym za cyberbezpieczeństwo wynieść temat na poziom zarządu. Łatwiej uzasadnić budżety na projekty związane z ochroną danych, backupem czy Disaster Recovery. Z drugiej strony w organizacjach, których zależność od cyfrowego świata była i tak wysoka, odpowiedzialność zarządu za ciągłość działania była faktem, nawet jeśli nie wynikała z przepisów.

Trzeba pamiętać, że systemy zabezpieczenia danych generują istotne koszty. Mówimy o dużych wolumenach danych, wielokrotnych kopiach i długich okresach ich przechowywania.

Regulacje powodują także, że audyty się zmieniają. Obok wątków finansowo-księgowych pojawiają się pytania o plany ciągłości działania, sposoby zabezpieczenia danych i możliwości odtworzenia ich po incydencie. Regulacje utrudniają też praktyki, które jeszcze niedawno były dość powszechne, jak np. „zdegradowanie” starej macierzy produkcyjnej do roli systemu backupowego po zakończeniu okresu wsparcia.

Wspominałeś o eksplozji wolumenów danych. Czy macie konkretne rozwiązania adresujące gwałtowny wzrost danych w energetyce – pomiarowych, pogodowych, predykcyjnych – również z perspektywy kosztów backupu i przechowywania?

Od rosnącej ilości danych nie uciekniemy. Jesteśmy cywilizacją danych, a energetyka, sektor utilities i przemysł są tego doskonałym przykładem. Z jednej strony rośnie liczba systemów i czujników, z drugiej zaś regulacje wymagają wieloletniego przechowywania różnych kategorii danych. Na to musimy nałożyć perspektywę AI i Big Data. Dziś powszechne jest przekonanie, że kasowanie danych to utrata potencjalnej wartości.

W efekcie bardzo często przechowujemy znacznie więcej, niż tylko to, co służy bieżącemu przetwarzaniu. Dane z czujników wykorzystywane są dziś do reagowania na zdarzenia w instalacji. W dłuższej perspektywie mogą pozwolić analizować trendy, budować modele predykcyjne, szukać korelacji. Trudno jest więc podjąć decyzję, że czegoś „już nie potrzebujemy”.

Technologia odpowiada na to na kilku poziomach. Po pierwsze, pojemność urządzeń rośnie. Macierze flashowe NVMe o pojemnościach rzędu PB nie są egzotyką. Po drugie, do świata Enterprise weszły rozwiązania, takie jak storage obiektowy, które pierwotnie były domeną dużych operatorów chmurowych. Dziś to on umożliwia ekonomiczne przechowywanie ogromnych zbiorów danych w wielu organizacjach.

Kluczową rolę odgrywają więc mechanizmy kompresji i deduplikacji. Deduplikacja danych jest standardem zarówno w macierzach produkcyjnych, jak i w systemach backupowych. Może odbywać się na dedykowanych urządzeniach typu Dell PowerProtect Data Domain czy HPE StoreOnce Systems. Jest dostępna też na poziomie oprogramowania backupowego, które deduplikuje dane przed ich zapisaniem na nośnik lub wysłaniem do chmury. Znacząco ogranicza to nie tylko zajętość przestrzeni, lecz także koszty transmisji danych.

W praktyce większość projektów, które realizujemy w sektorach przetwarzających ogromne wolumeny danych – jak energetyka – łączy wszystkie wymienione wcześniej podejścia. Są to wydajne macierze flashowe dla danych „gorących”, storage obiektowy dla długoterminowego przechowywania oraz mechanizmy kompresji i deduplikacji na wszystkich poziomach.