Disaster Recovery Center a ciągłość działania | All for One Poland

Disaster Recovery Center a ciągłość działania

Plan awaryjny to konieczność

W świecie, w którym cyberataki, awarie infrastruktury i utrata danych zdarzają się coraz częściej, Disaster Recovery Center (DRC) staje się podstawowym elementem strategii ciągłości działania firmy. Nawet najlepiej zabezpieczone środowisko IT może ulec paraliżowi wskutek błędu ludzkiego, utraty zasilania, ataku ransomware czy niedostępności usług chmurowych. Dlatego organizacje muszą myśleć nie tylko o backupie, ale także o skutecznym planie odzyskiwania danych i odtworzenia systemów. Dziś DRC to konieczność, by chronić dane w chmurze publicznej, prywatnej, SaaS i on-premise.

W świecie, w którym cyberataki, awarie infrastruktury i utrata danych zdarzają się coraz częściej, Disaster Recovery Center (DRC) staje się podstawowym elementem strategii ciągłości działania firmy. Nawet najlepiej zabezpieczone środowisko IT może ulec paraliżowi wskutek błędu ludzkiego, utraty zasilania, ataku ransomware czy niedostępności usług chmurowych. Dlatego organizacje muszą myśleć nie tylko o backupie, ale także o skutecznym planie odzyskiwania danych i odtworzenia systemów. Dziś DRC to konieczność, by chronić dane w chmurze publicznej, prywatnej, SaaS i on-premise.

Współczesny biznes działa w środowisku, w którym ryzyko przestojów i utraty danych jest większe niż kiedykolwiek wcześniej. Katastrofy naturalne, awarie infrastruktury, cyberataki, błędy ludzkie czy przerwy w dostępie do energii – każdy z tych czynników może sparaliżować działalność firmy w ciągu zaledwie kilku minut. Coraz częstsze są też zagrożenia będące echem wydarzeń geopolitycznych, jak wojna, zakłócenia w dostawach surowców czy niedostępność usług chmurowych w danym regionie.

Również zawrotne tempo zmian, jakich doświadczamy w sferze informatyzacji, generuje nowe zagrożenia. W wyścigu o uwagę klientów dostawcy systemów i aplikacji wypuszczają na rynek rozwiązania niedopracowane, z błędami w kodzie umożliwiającymi włamania do systemów. Wyspecjalizowane grupy hakerskie, często opłacane przez nieprzyjazne rządy innych krajów czy konkurencję technologiczną, wykorzystują wszelkie podatności – zarówno technologiczne, jak i wynikające z błędów ludzkich. Aż 40% włamań do systemu odbywa się poprzez atak phisingowy lub jest efektem zwykłej nieostrożności.

Jak się bronić przed cyberatakami

Każdy z sukcesem przeprowadzony atak wpływa na ciągłość działania firmy, kruszy jej renomę, a nawet może prowadzić do upadłości. Co w taki razie należy zrobić, aby firma mogła funkcjonować bez ryzyka z strony systemów informatycznych?

Po pierwsze nigdy dość szkoleń pracowników z zakresu przeciwdziałania infiltracji i odporności na stosowane socjotechniki.

Po drugie warto zadbać o zabezpieczenie danych na wypadek uszkodzenia, niedostępności lub zaszyfrowania.

Firmowe dane przechowujemy w różnych lokalizacjach. Część w rozwiązaniach chmurowych własnych lub publicznych (takich jak Amazon Web Services, Google Cloud Platform, Microsoft Azure oraz dedykowanych chmurach jak SAP S/4HANA Cloud). Inne w aplikacjach SaaS u różnych dostawców. Niektóre przedsiębiorstwa wybierają rozwiązania oparte na lokalnych Data Center w danym regionie lub własnych, na terenie centrali lub oddziału firmy.

Dane mogą być kopiowane między regionami, mogą występować w rozwiązaniu wysokiej dostępności oraz być kopiowane do innej lokalizacji w ramach firmy. W przypadku aplikacji SaaS w chmurach dostawców zwykle nie mamy dostępu do informacji, w jaki sposób dane składowane i w jakiej lokalizacji.

Wiedząc to wszystko, trudno uciec od pytania: a co się stanie, jeżeli dane zostaną usunięte, zaszyfrowane lub uszkodzone?

Disaster Recovery Center

Kluczowym elementem strategii bezpieczeństwa biznesu staje się Disaster Recovery Center (DRC) – zapasowe centrum przetwarzania danych, które umożliwia utrzymanie ciągłości działania nawet w przypadku poważnej awarii podstawowego środowiska IT. Podstawą do zabezpieczenia danych są różne rodzaje kopii zapasowych wykonywanych do zdalnej lokalizacji, zabezpieczonej przez nieuprawnionym usunięciem, testowane na wypadek potrzeby odtworzenia oraz stworzenie miejsca do odtworzenia, tak aby firma mogła funkcjonować bez przeszkód. Samo posiadanie kopii zapasowej nie wystarczy: równie ważne jest określenie, jak szybko organizacja jest w stanie przywrócić systemy do działania i gdzie te kopie są fizycznie przechowywane.

Wariantów budowy DRC jest tyle, ile organizacji. Każde rozwiązanie jest budowane indywidualnie, z uwzględnieniem przede wszystkim wielkości i specyfiki środowiska IT, klasyfikacji ważności systemów IT, czasów RPO (Recovery Point Objective, akceptowalna utrata danych) i RTO (Recovery Time Objective, maksymalny dopuszczalny czas przerwy), a także stosowanych technologii IT i dostępnych łączy transmisyjnych.

W kolejnych częściach artykułu przyjrzymy się, jak skutecznie planować i wdrażać mechanizmy Disaster Recovery dla systemów utrzymywanych w różnych modelach chmurowych, a także on-premise i SaaS.

 

Kopie zapasowe w chmurach publicznych

W chmurach publicznych replikacja danych w ramach regionu między strefami nie jest wystarczającym zabezpieczeniem. Wymagane są środki zapobiegawcze takie jak kopia zapasowa do innego regionu. Optymalnym rozwiązaniem, by w drugim regionie zabezpieczyć w dane na szyfrowanej przestrzeni, bez możliwości usunięcia.

W celu zachowania ciągłości działania należy rozważyć replikację danych do innego dostawcy, np. z Azure do AWS, tak aby w przypadku niedostępności całości infrastruktury jednej chmury publicznej można było uruchomić dane w innej chmurze publicznej lub wycofać dane i uruchomić we wskazanym centrum danych poza lokalizacją chmurową.

Należy przy tym pamiętać, aby Disaster Recovery Center (DRC) posiadało możliwość pełnego uruchomienia bez dostępu do zasobów chmurowych (przykładowo wraz z replikacją aplikacji i baz danych) należy zabezpieczyć miejsce dla poświadczenia tożsamości, np. EntraID w trybie hybrydowym.

Kopie dla dedykowanych chmur prywatnych lub publicznych

Przykładowo po migracji danych do systemu SAP w modelu chmury prywatnej istnieje ograniczona możliwość replikacji danych z poziomu wirtualizacji czy systemów operacyjnych. Pozostaje tylko możliwość replikacji danych aplikacyjnie, co stanowi dodatkowy koszt dla organizacji.

Wybierając SAP S/4HANA Cloud, mamy bardzo ograniczone możliwości zorganizowania własnego DRC dla systemów SAP, ponieważ w całości systemami administruje SAP. Inaczej sytuacja wygląda w przypadku SAP RISE Private – możemy zastosować SAP HANA System Replication (HSR), czyli replikacji synchronicznej dla replikacji „krótkodystansowych”, lub replikacji asynchronicznej przy „dłuższych” dystansach. Wymaga to jednak zaprojektowania odpowiedniej topologii i zakupu dodatkowych licencji. Istnieją także inne możliwości wzmacniania bezpieczeństwa – poprzez backup do blob storage albo wykorzystanie narzędzi hiperscalerów jak Azure Site Recovery czy AWS DR pattern.

Kopie zapasowe dla rozwiązań on-premise

W przypadku własnych zasobów istnieje szereg możliwości replikacji danych między innymi ośrodkami, zarówno danych transakcyjnych, jak i kopii zapasowych. Istnieją rozwiązania replikujące dane również do chmur publicznych, a także innych data centers.

Dla rozwiązań SaaS

Dla rozwiązań typu Microsoft 365 lub Google Workspace, dostępnych w modelu Software as a Service, również wskazane jest stworzenie strategii odtwarzania danych (poczta, zasoby plikowe, informacje ze spotkań) na wypadek awarii. Dla tych narzędzi istnieją możliwości wykonywania replikacji danych we wskazanym DRC.

Od koncepcji po testy odtworzeniowe

All for One ma wieloletnie doświadczenia w zakresie utrzymania zapasowego centrum przetwarzania danych (Disaster Recovery Center) zarówno dla systemów SAP, jak i innych narzędzi IT. Zapewniamy kompleksową realizację DRC – od koncepcji i projektu, przez realizację po cykliczne testy odtworzeniowe. Zapasowe centrum może być fizycznie zlokalizowane w jednym z obiektów Data Center All for One, w chmurze publicznej bądź w innej wskazanej lokalizacji. Dysponujemy doświadczeniem i narzędziami, które umożliwiają osiągnięcie czasów near-zero przy synchronizacji danych oraz uruchomieniu zapasowego centrum.

Najczęstsze metody ataków hakerskich

PrzyczynaOpisUdział procentowy
Błąd ludzki (np. phishing, nieostrożność pracownika)Kliknięcie w złośliwy link, otwarcie załącznika, podanie danych logowania~40%
Wykorzystanie skradzionych danych uwierzytelniających (credentials)Hasła pozyskane przez phishing, wycieki, brute-force~25%
Luka w oprogramowaniu (unpatched vulnerability)Włamanie przez niezałataną podatność w systemie, aplikacji, firmware~15%
Złośliwe oprogramowanie (malware, ransomware)Wdrożenie złośliwego kodu, często przez phishing lub zewnętrzne nośniki~10%
Błąd konfiguracji (np. otwarty dostęp, złe uprawnienia)Publiczne wystawienie zasobów (np. S3, RDP, serwery), brak segmentacji~5%
Sabotaż wewnętrzny (insider threat)Działania obecnych lub byłych pracowników~3–5%
Ataki typu supply chainAtak przez dostawcę IT, aktualizację oprogramowania, partnera~1–3%

Wymagania wprowadzone przez dyrektywę NIS2 w zakresie ciągłości działania powodują, że grono organizacji, które powinny przynajmniej przeanalizować zasadność realizacji DRC, obejmuje znaczną część gospodarki

Rafał Grześkowiak, Manager ds. Projektów IT, All for One Poland

Ciągłość działania w NIS2

Rafał Grześkowiak, Manager ds. Projektów IT, All for One Poland, o ciągłości działania w kontekście NIS2: "Dostępność IT przestała być wewnętrzną sprawą firm. Stała się wspólnym celem całej gospodarki. Audyty kontrahentów uwzględniające w szerokim zakresie zagadnienia IT, takie jak cyberbezpieczeństwo, wysoka dostępność i plany awaryjne, są obecnie powszechną praktyką.

Niektóre sektory gospodarki – jak automotive czy audio-video – wypracowały standardy bezpieczeństwa informacji (odpowiednio VDA ISA/TISAX oraz TPN – Trusted Partner Network), których wdrożenie i certyfikacja de facto warunkują możliwość kooperacji w ramach tych branż. Jednym z filarów merytorycznych tych standardów jest ciągłość działania.

Przykładowo dla organizacji zobowiązanych do posiadania etykiety TISAX kontrolki 5.2.8 (IT service continuity planning) i 5.2.9 (Backup and recovery) wskazują wprost na konieczność przeanalizowania wpływu niedostępności usług IT na biznes i wymagają opracowania planów na wypadek awarii oraz określenia czasów i zasobów pozwalających na przywrócenie działania usług IT w założonym czasie.

Analogiczne wymagania narzuca norma ISO 27001 w swoim najnowszym wydaniu (odpowiednio w kontrolkach A.5.30 oraz A.8.13).

Norma ISO 22301 jest w całości poświęcona systemowemu zarządzaniu ciągłością działania, koncentruje się na zapewnieniu, że organizacja potrafi utrzymać kluczowe operacje biznesowe w sytuacjach kryzysowych oraz szybko je przywrócić po zakłóceniach. Biznesowo oznacza to minimalizację strat operacyjnych i reputacyjnych oraz zwiększenie odporności organizacji na ryzyka takie jak awarie IT czy cyberataki.

Dobre praktyki zarządzania usługami IT opisane w normach i standardach z czasem zostały odzwierciedlone w przepisach prawa. Dyrektywa NIS z 2016 r. oraz polska Ustawa o Krajowym Systemie Cyberbezpieczeństwa (KSC) akcentowały konieczność zastosowania odpowiednich rozwiązań organizacyjnych i technicznych. Dopiero jednak dyrektywa NIS2 z 2022 r. w art. 21 konkretyzuje wymagania, narzucając obowiązek przygotowania m.in. analizy ryzyka i procedur przywracania normalnego działania po wystąpieniu sytuacji nadzwyczajnej.

Disaster Recovery Center jest jednym ze środków wspierających ciągłość działania IT. Pozwala organizacjom uwzględnić w planach ciągłości niezależną, zewnętrzną lokalizację, w której – w razie potrzeby – zostaną bezzwłocznie uruchomione kluczowe systemy IT.

Wymagania wprowadzone przez dyrektywy NIS i NIS2 w zakresie ciągłości działania powodują, że grono organizacji, które powinny przynajmniej przeanalizować zasadność realizacji DRC, obejmuje znaczną część gospodarki, m.in. energetykę, transport, bankowość, opiekę zdrowotną, wodociągi, producentów leków i żywności, przemysł chemiczny i kosmetyczny".

Napisz do nas Zadzwoń Wyślij email






    Informacje na temat przetwarzania danych osobowych znajdują się w Polityce Prywatności. Wysłanie wiadomości jest równoznaczne z zapoznaniem się z polityką prywatności All for One Poland Sp. z o. o.

    61 827 70 00

    Biuro jest czynne
    od poniedziałku do piątku
    w godz. 8:00 – 16:00 (CET)

    Kontakt ogólny do firmy
    office.pl@all-for-one.com

    Pytania o produkty i usługi
    info.pl@all-for-one.com

    Pytania na temat pracy i staży
    kariera@all-for-one.com

    This site is registered on wpml.org as a development site. Switch to a production site key to remove this banner.