Cloud DR - jak chmura publiczna może pomóc w zabezpieczaniu ciągłości działania firmy?

Rozwiązanie DR w chmurze, czyli cloud Disaster Recovery

W najprostszym ujęciu cloud Disaster Recovery jest oparciem procesu od strony technologicznej na zasobach chmurowych. Obsługa procesów świadczonych dotychczas przez określone centrum lub centra danych jest przełączana na zdefiniowane środowisko / środowiska chmurowe. Dla użytkownika fizycznego (przykładowo pracownika organizacji, agenta lub klienta korzystającego z systemów) lub dla użytkownika technicznego (takiego jako aplikacja) przełączenie na środowiska chmurowe może być na tyle płynne, by zostać niezauważone. Dane systemowe mogą być synchronizowane na bieżąco, włączając w to dane tymczasowe w pamięci podręcznej maszyn na jakich działają procesy. Infrastruktura i aplikacje mogą być uruchomione i gotowe do przejęcia obciążenia, a przełączenie przekierowań sieciowych z rozwiązania dotkniętego awarią do rozwiązania chmurowego może odbywać się w sposób zautomatyzowany lub pół-zautomatyzowany w oparciu o mechanizm sprawdzania dostępności środowisk.

Wzrost możliwości technologii chmurowej i coraz większa popularyzacja usług chmurowych zapewniają organizacjom dodatkowe sprawdzone narzędzie, które w porównaniu z rozwiązaniami on-premises może być bardziej skuteczne w zakresie ryzyk zidentyfikowanych w Business Continuity Plan. Przewaga chmury publicznej względem rozwiązań on-premises dla rozwiązań Disaster Recovery jest szczególnie widoczna w możliwości prostej i relatywnie szybkiej zmiany geolokalizacji infrastruktury oraz rozpięcia na wielu regionach. Przy czym należy wskazać, że ogólnie dobrą praktyką jest tworzenie regionalnie zamkniętej infrastruktury. W rozwiązaniach funkcjonujących w wielu regionach, system powinien być powielany pomiędzy nimi i działać niezależnie. Niestety, nieważne jak idealny jest sposób synchronizacji danych, w momencie uszkodzenia infrastruktury zawsze trzeba liczyć się z jakąś stratą danych. Dopuszczalna ilość utraty danych (RPO, czyli Recovery Point Objective), jest definiowana przez każdą organizację indywidualnie i może być różnicowana ze względu na system lub aplikację. W efekcie, wpływa na konfigurację oraz stosowane w DR narzędzia czy serwisy.

Backup danych w chmurze

W najprostszym modelu chmura może stanowić miejsce bezpiecznego przechowywania kopii danych, które są zapisywane w dedykowanych magazynach chmurowych. Technicznie chmura może przyjąć niemal dowolne dane - od plików wraz ze strukturą katalogów, bazy danych, obrazy systemów i wirtualnych maszyn, dane aplikacji, obrazy dysków, repozytoria kodu, etc. Backup danych w chmurze może zawierać kompletny obraz wybranych systemów organizacji oraz dane na jakich te systemy działają.

Źródłem danych mogą być fizyczne centra danych, dane przechowywane u innych dostawców chmurowych lub tego samego dostawcy chmurowego, u którego przechowywane będą zreplikowane dane. Replikowanie danych może odbywać się w sposób ciągły, zapewniając oczekiwany tryb spójności danych lub procesowany w określonych odstępach czasu zapewniając niższy koszt. Przy określaniu procesów tworzenia kopii zapasowych danych w chmurze należy uwzględnić zróżnicowaną charakterystykę i potrzeby organizacji wobec obsługiwanych aplikacji, systemów oraz magazynów danych. Dla części danych określonych przez organizację jako krytycznie ważne, np. bazy danych aplikacji zapisującej operacje wpływające na saldo finansowe klientów, organizacja może oczekiwać replikacji danych niemal w czasie rzeczywistym. „Niemal”, gdyż światłowód ogranicza o około 1/3 prędkość światła, które jest fizycznym nośnikiem danych, a dodatkowo należy uwzględnić korektę na niedoskonałości infrastruktury oraz opóźnienia generowane przez elementy krańcowe. W przypadku złożonych rozwiązań i wymagań, przy których oczekuje się przetwarzania w czasie niemal rzeczywistym, powyższe należy uwzględnić przy określaniu wymagań wobec rozwiązania, w szczególności dla usług świadczonych i rozproszonych globalnie.

Kopia statyczna danych najczęściej oznacza zaakceptowanie utraty największego wolumenu danych. 

Szyfrowanie kopii zapasowych danych

Jeżeli potraktujemy chmurę tylko jako repozytorium do zapisywania kopii zapasowych danych (backup danych),do wyboru są dwa wysokopoziomowe podejścia ze względu na sposób w jaki dane będą szyfrowane:

• pierwsze podejście zakłada, że organizacja może zdecydować się na szyfrowanie danych za pomocą algorytmu kluczy generowanych przez tego samego dostawcę usług chmury publicznej, który również zapewnia magazyny danych, gdzie będą zapisane kopie zapasowe danych.
• drugie podejście bazuje na rozdzielności dostawcy, który generuje klucze szyfrujące od dostawcy serwisów do zapisu kopii zapasowych danych. 

Upraszczając analizę w tym zakresie dla scenariusza, gdzie zapewniono zapis danych zaszyfrowanych kluczem zewnętrznym wobec dostawcy magazynów danych. Przy czym, należy zauważyć, że drugie podejście może stworzyć dodatkową złożoność rozwiązania, rzutować na zwiększenie RTO oraz budzić wątpliwości na gruncie czysto technologicznym w zakresie  rzeczywistego zwiększenia bezpieczeństwa wobec pierwszego z opisanych podejść.

Sposoby replikowania danych na chmurę

Przyjmując założenie, że przedsiębiorstwo posiada aktualne plany BCP i sprecyzowane wymagania per system/aplikacja w zakresie RPO i RTO, jednym z pierwszych technicznych kroków jest przegląd stosowanych rozwiązań do backup’u jako analiza as-is procesów oraz narzędzi. Organizacja z dużym prawdopodobieństwem używa już dla swoich fizycznych centrów danych rozwiązań od dostawców z firm trzecich w celu tworzenia kopii zapasowych i zapewnienia technologicznej platformy dla procesów Disaster Recovery. Jednocześnie, raport Gartnera z lipca 2022 r. [1] wskazuje grupę dostawców zapewniających rozwiązania do backup‘u danych oraz wsparcia procesów Disaster Recovery, sklasyfikowanych jako „rynkowi liderzy”, którzy w większości biorą udział w integracjach z głównymi dystrybutorami rozwiązań chmury publicznej. W praktyce, organizacja może kontynuować używanie pakietu aplikacji od tego samego dostawcy rozwiązań do kopii zapasowych i Disaster Recovery rozciągając architekturę rozwiązania do chmury publicznej. Oczywiście, po uprzedniej konfiguracji tych narzędzi oraz zapewnieniu wymaganych zasobów po stronie chmury, które bazują na odpowiednio skonfigurowanym tzw. 'landing zone'.

Dodatkowo, dostawcy rozwiązań chmurowych zapewniają własne, dedykowane serwisy do tworzenia kopii zapasowych oraz synchronizacji danych - zarówno dla danych przechowywanych on-premises, jak i danych zapisanych na chmurach podmiotów trzecich.

Przy czym, to zaledwie jeden ze sposób zapewnienia kopii danych. Niektóre repozytoria posiadają swoje natywne sposoby replikowania danych, np. bazy SQL mogą zapewnić ciągłe utrzymywanie zgodności pomiędzy rozwiązaniem on-premises, a bazą udostępnioną w chmurze. Innym przykładem są katalogi do zarządzania tożsamością użytkowników dbające o replikowanie zmian i spójność pomiędzy różnymi środowiskami.

Przy tworzeniu backup-u, w szczególności inicjalnego obrazu, możliwe jest, że organizacja zidentyfikuje obszerne zbiory danych. Przesyłanie terabajtów, a nawet petabajtów danych przez sieć internetową lub prywatną do dostawcy chmury może być zadaniem kosztownym i angażującym czas.  W odpowiedzi na powyższe problemy, część dostawców wprowadziło do oferty usługę dostarczania fizycznych nośników, które zapewniają kopiowanie szyfrowanych danych na dyski w fizycznym centrum danych organizacji będącej klientem, a następnie odesłanie dysków do serwerowni dostawcy i utworzenie kopii w chmurze.  Dodatkowym, istotnym punktem decyzyjnym jest wybór geograficznej lokalizacji serwerowni, z której lub z których będą świadczone usługi - bez względu na to czy organizacja dokonuje tylko backup-u danych, czy również pokrywa szersze procesy Disaster Recovery. Dostawcy usług publicznych udostępniają informacje nt. dostępnych fizycznych centrów danych, co umożliwia wybór takich lokalizacji geograficznych, które spełniają stawiane im wymagania, w tym np. regulacyjne w zakresie przetwarzania danych tylko w obszarze EOG, dostępność konkretnych usług lub opóźnienia generowane przy transferze danych przez odległości połączenia. Rozwiązanie może opierać się na pojedynczym centrum danych w chmurze lub  udostępnianiu w wielu regionach, co zapewni wyższą dostępność, a w efekcie – wyższe standardy SLA.

W przypadku backup-u danych w chmurze, można zautomatyzować sposób tworzenia obrazów aplikacji i systemów wraz z danymi na jakich pracują. Powyższe obrazy pełnią funkcję instrukcji budowy i umożliwiają odtworzenie systemów w środowiskach chmurowych lub w fizycznych serwerowniach. Backup w chmurze jest relatywnie niedrogim rozwiązaniem w porównaniu do pełnego Disaster Recovery cloud. Należy jednak uwzględnić, że proces będzie czasochłonny - do odtworzenia operacyjnej gotowości działania wybranych w planach Business Continuity Plan systemów czy aplikacji, konieczne jest zbudowanie zasobów z obrazów.

Należy jednak uwzględnić, że proces będzie czasochłonny - do odtworzenia operacyjnej gotowości działania wybranych w planach Business Continuity Plan systemów czy aplikacji, konieczne jest zbudowanie zasobów z obrazów.

Rozwiązanie DR w chmurze a backup danych

W przeciwieństwie do samej kopii zapasowej danych, rozwiązania Disaster Recovery oferują możliwość niemal natychmiastowego przejęcia co najmniej części obciążenia w przypadku zdarzenia uwzględnionego w Business Continuity Plan. Przy czym, rozwiązanie DR w chmurze wiąże się z poniesieniem wyższego kosztu – poza samą kopią zapasową danych wymaga dodatkowych, ciągle uruchomionych zasobów w chmurze, które są gotowe przejąć zaplanowane obciążenie w ramach procesu Disaster Recovery. Jednocześnie, im większa jest skala ciągle uruchomionych zasobów rozwiązania DR, względem zaplanowanej docelowej wielkości środowiska DR, tym wyższy jest standard RTO - szybkość odtworzenia technicznej gotowości do kontynuacji procesów systemowych i biznesowych.

Dla rozwiązań DR w chmurze funkcjonują różne strategie w dużym uproszczeniu bazujące na określeniu pozycji poziomu kosztu oraz zamierzonego poziomu standardu RTO/RPO. Przy czym, zależność pomiędzy tymi dwoma poziomami jest odwrotnie proporcjonalna. Bazując na planach BCP/DR można określić, które ze strategii DR powinny mieć zastosowanie do wybranych systemów organizacji. Takie mapowanie zakłada analizę procesów i serwisów IT w zakresie ich krytyczności dla utrzymania ciągłości działania, a także zapewnienia bezpieczeństwa. W konsekwencji, można stosować różne strategie Distaster Recovery wobec różnych systemów.

Rodzaje strategii DR cloud

Najdroższą strategią Disaster Recovery, ale jednocześnie zapewniającą możliwość niemal natychmiastowego przejęcia procesów w pełnej skali jest strategia 'Multi-site'. Bazuje na podejściu active/active, w którym środowisko chmurowe działa w skali odpowiadającej zaplanowanemu dla rozwiązania DR docelowemu obciążeniu i przy blisko zerowej utracie danych w przypadku wystąpienia zdarzenia.
Po drugiej, skrajnej stronie, jest strategia DR cechująca się najniższym kosztem utrzymania - strategia 'Backup & Restore'. Jest to konfiguracja typu 'active/passive'- w której funkcjonuje aktywne centrum danych jako główna serwerownia, oraz tworzone jest drugie centrum danych stanowiące ośrodek Disaster Recovery, gdzie wymagane są określone działania do jego przygotowania przed przejęciem docelowego obciążenia w ramach procesu DR.

Kompromisem strategii 'Backup & Restore' jest zaakceptowanie długiego czasu potrzebnego do odtworzenia pełnej operacyjności rozwiązania. Zaledwie minimalna część serwisów jest uruchomiona w chmurze i w przypadku zdarzenia DR konieczne jest prawie całkowite odtworzenie w chmurze zasobów wymaganych dla rozwiązania DR, co pomimo automatyzacji procesu, przekłada się na pogorszenie wskaźnika RTO. Czas odtworzenia jest zależny od rozmiaru skalowania, wybranych serwisów, złożoności odtwarzanej i skalowanej infrastruktury, dostępności zasobów chmurowych, zapisów umowy z dostawcą chmurowym, etc. Można również przyjąć, że wraz z niższym kosztem rozwiązania Disaster Recovery również wskaźnik RPO może ulec pogorszeniu, co wymusi  na organizacji akceptację większej utraty danych lub presję na zmianę strategii lub sposobu konfiguracji replikowania danych.

Pomiędzy wskazanymi strategiami funkcjonują rozwiązania pośrednie, które są uznawane jako konfiguracja 'active/passive'. Powyższe, pośrednie scenariusze są zazwyczaj implementowane by zapewnić równowagę pomiędzy kosztem, szybkością przywrócenia pracy po awarii lub innego incydentu oraz akceptowalnym poziomem utraconych danych:

•  'Pilot Light': w sposób ciągły w chmurze są uruchomione jedynie krytyczne zasoby systemu. W przypadku zdarzenia Disaster Recovery inicjowane zostaje skalowanie zasobów do docelowo zaplanowanego poziomu. Zakłada się, że skalowanie dla 'Pilot Light' trwa kilkadziesiąt minut.
• 'Warm Standby': uruchomione jest w pełni funkcjonalne środowisko mogące przejąć część procesów. Wciąż jednak wymagane jest skalowanie w górę do zaplanowanego poziomu. W tej strategii można założyć, że skalowanie będzie liczone w minutach.

Wsparcie procesów Disaster Recovery przez rozwiązania chmurowe

Zarówno w wariancie bezpiecznego backup-u danych w chmurze jak i pełnego rozwiązania Disaster Recovery Cloud, konieczne jest:

1. oszacowanie ryzyka rozwiązań,
2. stworzenie całościowej architektury z uwzględnieniem  płaszczyzn integracji, danych, aplikacji lub serwisów, infrastruktury i aktualizacji architektury korporacyjnej organizacji,
3. opracowanie procesów operacyjnych niezbędnych do utrzymania rozwiązania.

Jako uzupełnienie dla rozwiązania Disaster Recovery organizacja może również rozważyć udostępnienie pracownikom usług wirtualizacji systemów operacyjnych wraz z wirtualnymi pulpitami i aplikacjami w chmurze. Powyższe zapewni  bezpieczne środowisko pracy uniezależnione od fizycznych maszyn służbowych.

Tematyka Disaster Recovery w chmurze może przybrać zróżnicowaną skalę i katalog wykorzystanych usług w zależności od potrzeb organizacji. Poruszając tematykę DR w chmurze otwiera się dyskusję i działania na temat wielu aspektów rozwiązań cloud w tym m.in.

• budowy i konfiguracji podstawowego środowiska chmurowego (w tym m.in. podstawowej architektury wraz z niezbędnymi serwisami, ustawieniami sieciowymi, ustawień dla zarządzania tożsamością, etc.),
• kanału komunikacji pomiędzy centrami danych organizacji i platformą chmurową,
•  zapewnieniem zgodności regulacyjnej dla wykorzystania przez organizację rozwiązania chmurowego,
• testowania rozwiązania Disaster Recovery, np. przełączania na rozwiązanie DR, weryfikacja poprawności backup-u danych, etc.