Jak skutecznie zapewnić ciągłość biznesu i dostępność danych wobec obecnych wyzwań

W debacie pod patronatem Hewlett Packard Enterprise (HPE), przedstawiciele: Grupy PZU; Krajowego Depozytu Papierów Wartościowych; mBanku; banku Nordea; Polpharmy oraz HPE rozmawiali o tym: jakie mechanizmy Disaster Recovery muszą posiadać organizacje prowadzące nierzadko działalność o kluczowym znaczeniu dla gospodarki; jaka jest specyfika rozwiązań DR w największych firmach; jak budować architekturę środowiska pozwalającego zapewnić ciągłość biznesu w razie awarii lub cyberataku czy też jak szukać kompromisów z użytkownikami biznesowymi, jeśli chodzi o relację dostępności i kosztów.

JAK ZMIENIA SIĘ OBSZAR DISASTER RECOVERY i BUSINESS CONTINUITY?

Ostatnie lata przyniosły zasadnicze zmiany w wielu obszarach związanych z wykorzystaniem technologii. Jak zmienił się obszar Disaster Recovery i Business Continuity Management?

Maciej Kalisiak, HPE Compute and Data Services Sales Manager, Hewlett Packard Enterprise Polska (M.K.): Wszyscy widzimy, jak dynamicznie zmienia się świat. Przejście na model usługowy – jak w przypadku oferty naszej firmy – oznacza także nowe podejście do procesów Disaster Recovery, w zakresie szeroko rozumianego bezpieczeństwa – w tym tworzenia i przywracania kopii zapasowych.

Najważniejsza zmiana polega jednak na tym, że użytkownicy są coraz bardziej świadomi, iż dane są kluczowym zasobem biznesu. W związku z tym, nie trzeba dbać o szczególnie. Liczba ataków i incydentów, o których wiadomo powszechnie, powoduje, że kwestia ochrony danych przestaje być odległym zagadnieniem, ale dotyczy każdego.

Aleksander Gawroński, dyrektor ds. infrastruktury, mBank (A.G.): Z perspektywy instytucji finansowej zmian w tym obszarze jest kilka. Wzrosło bowiem zagrożenie cyberatakami, a ochrona danych stała się jedną z podstawowych wartości, które dostarcza bank. W naszym przypadku to pieniądze klientów zapisane na dyskach. Ze względu na geopolitykę i wzrost cyberzagrożeń, znaczenie mechanizmów Disaster Recovery, ochrony danych, wdrażania rozwiązań typu anty-ransomware i podnoszenia poziomu cyberbezpieczeństwa wzrosło.

Drugim elementem, który ma znaczenie dla tych zagadnień, jest transformacja chmurowa. Możemy teraz dane przekazywać do chmury i traktować ją jako dodatkowy magazyn, np. kopii. Choć z perspektywy wielu organizacji, takich jak mBank, wykorzystanie potencjału chmury okazało się wyzwaniem. Posiadamy ok. 10 PB danych. Codzienne synchronizowanie ich jest niemożliwe, dlatego potrzebne jest wyselekcjonowanie zbiorów danych które muszą być synchronizowane w czasie rzeczywistym, a także zbiorów, dla których procesy synchronizacji mogą odbywać się rzadziej.

Łukasz Polkowski, dyrektor ds. utrzymania usług IT w PZU (Ł.P.): Ostatnie lata to dla nas czas skierowania uwagi na kwestie związane z zapewnianiem ciągłości działania, również te bezpośrednio związane z Disaster Recovery. W związku z wysokim priorytetem tych tematów w strategii Grupy PZU powołane zostały m.in. odpowiednie struktury do ich koordynowania.

Ciągła współpraca zespołu IT z obszarem bezpieczeństwa jest naturalnym wynikiem działań dotyczących Disaster Recovery. Wspólnie dyskutujemy i analizujemy kwestie związane z zabezpieczeniem danych, np. we wspomnianym już kontekście rozwiązań chmurowych. Z szerszą, międzyobszarową optyką przyglądamy się też nowym rozwiązaniom, które wdrażamy, aby mieć pewność, że spełniają najwyższe standardy w obszarze bezpieczeństwa.

Andrzej Makarewicz, ekspert ds. testów ciągłości działania i Disaster Recovery w PZU (A.M.): Bezpośrednio stykam się zagadnieniem przywracania działalności po różnego rodzaju katastrofach, m.in. z powodu regulacji zewnętrznych, które dotyczą każdej organizacji finansowej. W odniesieniu do zmieniających się uwarunkowań regulacji, które dotyczą każdej organizacji finansowej, opracowuję scenariusze będące odpowiedzią na zagrożenia ogólne. Jednocześnie – przygotowując kolejne edycje, coraz bardziej zaawansowanych testów – jako organizacja odnotowujemy postęp w poziomie bezpieczeństwa.

Widać, że w całej organizacji zmieniło się spojrzenie na rozwiązania wspierające zapewnienie wysokiej dostępności. Wcześniej zagadnienia DR były postrzegane jako gwarancje operacyjnej ciągłości działania. Funkcjonowały jednak przede wszystkim pod kątem potrzeby lokalnego utrzymania usługi albo zwiększenia jej pojemności. W tej chwili ciężar ten coraz bardziej przechodzi na kwestie bezpieczeństwa na wypadek rzeczywistych zagrożeń zewnętrznych. To ważna zmiana.

Sławomir Panasiuk, VP, CIO, Krajowy Depozyt Papierów Wartościowych (S.P.): Od ponad 20 lat jestem zaangażowany w kwestie ciągłości działania i właściwie co roku mogę powiedzieć, że czuję się mniej pewnie i bezpiecznie. Przykładowo, 24 lata temu, kiedy byłem jeszcze programistą stawiano nam za cel uruchomienia centrum zapasowego w ciągu maksymalnie 2 godzin. Dziś również w ciągu 2 godzin musimy przywrócić do działania podstawowe systemy, choć oczywiście to już zupełnie inna architektura i stopień powiązań.

Dwa razy w roku przeprowadzamy testy przywracania kluczowych systemów po awarii, niekiedy wzbogacając scenariusz ćwiczeń o niedostępność wybranych obszarów infrastruktury. To się udaje, ale ja nadal nie mam pewności, czy jesteśmy w pełni odporni np. na ransomware. Problem ten spędza mi sen z powiek, ale dotyczy wszystkich organizacji.

Aby poprawić naszą efektywność, nieustannie poszukujemy rekomendacji i dobrych praktyk. Widzimy jednak, że pod względem zabezpieczenia skutkami ataków hakerskich nawet dużo większe izby rozliczeniowe nie mają zbyt wielu pomysłów. Posiadamy natomiast pewne doświadczenie związane ze współpracą z depozytem centralnym Ukrainy. Zainteresowali nas koncepcją tzw. golden copy, która sprawdziła się u nich, a której obecnie przyglądają się także inne, centralne depozyty w Europie. To dodatkowe, ulokowane poza środowiskiem backupu rozwiązanie przechowywania kopii najważniejszych danych. Dodajmy, kopii wykonywanej regularnie, zapisywanej w najprostszy sposób, ale poza jakimkolwiek środowiskiem chmurowym czy dostępnym z sieci. Pracujemy nad takim rozwiązaniem.

Andrzej Leszczyński, Nordea Global Service Desktop and Support, Nordea (A.L.): W kontekście tego, co się ostatnio dzieje, golden copy to bardzo dobry pomysł, który powinien być wręcz obowiązkowy dla instytucji finansowych.

Robert Pławiak, CIO i CDO, Polpharma (R.P.): Dla nas obszar Disaster Recovery stanowi pewien podzestaw szeroko rozumianej koncepcji ciągłość działania, co w przypadku branży medycznej oznacza po prostu ciągłość dostarczania medykamentów, które ratują życie. Inny, charakterystyczny dla mojej branży aspekt, to bardzo mocna integracja łańcucha dostaw – od badań po produkcję. Musimy zapewnić ciągłość, integralność i sprawdzalność wytwarzania pojedynczych produktów. W celu zapewnienia odporności tych elementów regularnie prowadzimy m.in. testy zakładające np. zniknięcie z sieci wybranego laboratorium.

Od siebie dodam uwagę o prostej zmiennej, którą warto obecnie uwzględnić w planach. To zresztą była pierwsza rzecz, o jaką zapytałem podczas spotkania na temat ciągłości działania z biznesem w firmie farmaceutycznej. Czy wiemy, kto ma w naszej firmie ma książeczkę wojskową z kategorią A? Odebrano to jako małą prowokację, ale w obecnych realiach powszechna mobilizacja nie jest nieprawdopodobnym wydarzeniem. Bez wiedzy o tym kto może być powołany do wojska, nie jesteśmy w stanie odpowiedzialnie planować procesów.

Odrębna kwestia dotyczy też tego, jak szybko można wynieść i uruchomić konkretny ośrodek biznesowy z dala od strefy zagrożenia działaniami wojennymi.

Piotr Drąg, HPE Storage Category & Data Services Business Development Manager w Hewlett Packard Enterprise Polska (P.D.): Od razu zadeklaruję, że mam kategorię A (śmiech). Jako dostawca nie ustajemy w wysiłkach, aby nasze rozwiązania rozwijać pod kątem aktualnych potrzeb rynku. Mamy świetne usługi, a golden copy jest tego doskonałym przykładem. W naszej nomenklaturze jest to „bezpieczna krypta”.

Natomiast sam fakt pojawiania się komputerów kwantowych spowoduje, że niedługo wiele kwestii, o których dziś mówimy, straci znaczenie. Będziemy musieli przebudować nasze myślenie o bezpieczeństwie, dostępności i ciągłości działania.

Ostatnio przeczytałem, że Japończycy byli w stanie już kilka lat temu zmagazynować dane na poziomie DNA wirusa. Pomyślmy, jak już w przewidywalnej przyszłości może to zmienić perspektywę przesyłania ogromnych ilości danych, powiedzmy 10 PB. Dziś przesłanie takiej ilości danych do chmury publicznej jest karkołomnym zadaniem i do tego bardzo kosztownym. Co jeżeli np. będzie możliwe magazynowanie danych na poziomie DNA organizmów, nawet ludzi. Nikt wtedy nie będzie wysyłał do danych do chmury publicznej, bo wszystko będzie jedną wielką chmurą!

Powinniśmy odejść od dotychczasowego podejścia do problematyki DR. Moim zdaniem czeka nas wstrząs i ogromny chaos, którego ułożenie będzie wymagało kilku lat.

A.G.: Dodałbym jeszcze jedno, ważne dla wszystkich czytelników przesłanie: Disaster Recovery w sektorze finansowym obecny jest od dawna. Musimy nieustannie testować, potwierdzać, że wszystko działa właściwie ze względu na własny zdrowy rozsądek i wymogi regulacyjne. Mam wrażenie, że z perspektywy naszego sektora, ten temat był już uporządkowany, ale ostatnie wydarzenia mocno podniosły jego znaczenie. Dziś jest to temat żywy, który stale owocuje nowymi rozwiązaniami i usprawnieniami.

Wdrożyliśmy m.in. gotowe rozwiązanie do ochrony przed ransomware. Dzięki niemu ochrona danych nie odbywa się tylko na poziomie dodatkowych pamięci masowych, ale dodaliśmy kolejną linię obrony. Mam tu na myśli dodatkowe obszary pamięci, cyfrowy bunkier, który wykorzystuje Machine Learning do analizy danych doń trafiających, aby ustalić, czy nie są to przypadkiem dane już zaszyfrowane. Jest to dodatkowa ochrona przed ransomware, która gwarantuje, że w przypadku „nieszczęścia”, zarówno dane, jak i parametry z nimi związane znajdują się w cyfrowym bunkrze.

KTO WSKAŻE KRYTYCZNE PROCESY I SYSTEMY?

Zaczynamy więc rozmawiać o portfelu rozwiązań, mechanizmów, które tworzą klasę Disaster Recovery. Czy dobrze rozumiem, że ulega ona obecnie pewnemu przetasowaniu, uzupełnieniu o nowe pozycje odpowiadające np. na upowszechnienie ransomware?

S.P.: Zmiany kontekstu nie przechodzą niezauważone przez zespoły odpowiedzialne za DR. Zaczęto powszechnie modyfikować plany tak, aby uwzględniały m.in. kwestię dostępu do usług infrastruktury telekomunikacyjnej z domowych „lokalizacji zapasowych”. Równocześnie niezbędne stało się podnoszenie jakości komunikacji i zabezpieczeń.

W przypadku ataków hakerskich, mamy na rynku najczęściej dwa scenariusze. Jeden dotyczy zabezpieczenia przed takimi atakami, a drugi sytuacjami, w których dane zostaną już zaszyfrowane. Warto postawić sobie szereg pytań Dotyczących scenariuszy zaangażowania odpowiednich służb i podjęcia prób odzyskania danych.

Chciałbym zwrócić uwagę na jeszcze jedną kwestię. O ile faktycznie zmienia się portfel używanych rozwiązań, to niezmiennie wyzwaniem jest dobre określenie poziomu krytyczności zasobów – danych i systemów. Jeśli wybieramy priorytety, to właściciele pominiętych w pierwszym rozdaniu linii czują się mniej ważni. Trzeba stale weryfikować krytyczność poszczególnych systemów. Trzeba mieć plan z ustawionymi miarami krytyczności.

A.G.: W naszym wypadku punktem wyjścia w tej selekcji ze względu na poziom krytyczności – jest kwestia danych, które nazywamy „witalnymi”. Stanowią one 5-10% spośród wszystkich ok. 10 PB, którymi dysponujemy. Te właśnie, witalne dane, trafiają do naszych cyfrowych bunkrów. Ciągle weryfikujemy ten zestaw, aby trafnie je definiować. To decyduje o efektywności ewentualnego przywracania działania. Oczywiście takiej weryfikacji towarzyszy ciągła rozmowa z biznesem. Każda instytucja ma swój zestaw krytycznych systemów, procesów i danych. Reszta, w trudnej, kryzysowej sytuacji nie jest niezbędna.

Kto decyduje, które dane są witalne? Czy jest to w gestii zarządu, czy IT?

A.G.: Wypracowaliśmy metodykę procesów krytycznych w oparciu o wymogi regulatorów. Prawo definiuje procesy krytyczne, to z kolei określa, które systemy są krytyczne, a co za tym idzie dane. Do tego trzeba oczywiście dołożyć zdrowy rozsądek. W sytuacji, gdy system krytyczny wykorzystuje wiele danych z różnych źródeł, określamy krytyczne funkcje, a co za tym idzie i dane. Jest to wówczas praca zespołu IT, wspólnie z właścicielami systemów, a nie zarządu.

S.P.: Na poziom zarządu te kwestie mogą trafić w przypadku konfliktu lub braku uzgodnień. Natomiast w naszym przypadku rozstrzyga je Komitet ds. ryzyka, złożony z osób odpowiedzialnych za analizę ryzyka, bezpieczeństwo, IT i biznes. Tam dochodzi do oceny procesów pod kątem krytyczności.

R.P.: My w podobnej sytuacji uwzględnialiśmy przede wszystkim kwestię kosztu utraty danych oraz ich właścicielstwo. Musielibyśmy poświęcić wiele czasu i energii, aby ustalić czyje są dane, a niekiedy wyjaśnić to nieświadomemu swoich praw właścicielowi. Wiedza o własnej odpowiedzialności robi dużą różnicę w dalszym, wspólnym ustalaniu znaczenia i wagi dostępu do danych. Podobnie, jak wiedza o tym, ile kosztuje zakwalifikowanie wybranej grupy danych do kategorii „dane krytyczne, do natychmiastowego przywrócenia”. Okazało się, że wiele z nich może spokojnie spoczywać w bardziej odległych czasowo „szafach”.

Mnie obszar Disaster Recovery jest bliski, ale nie rozpoczynam dyskusji z biznesem od omawiania założeń DR. Zaczynam od prośby o przedstawienia planu ciągłości działania. Dopiero w kolejnym kroku precyzuję, jakie zastosuję środki, aby go wykonać. I możecie wierzyć lub nie, bywało, że w razie odmowy zagrywałem prowokacyjnie – skoro mam decydować samodzielnie, co odtwarzać w pierwszej kolejności, to proponuję administrację, bo to łatwe i przyjemne. Udawało mi się wówczas lekko wstrząsnąć zainteresowanymi i uzyskać jasne deklaracje dotyczące krytyczności, właścicielstwa i odpowiedzialności. Tu nie chodzi o asertywność, tylko o to, by decyzje podejmować w pełni świadomie.

TESTY I „TESTY”

A.M.: Wskazanie systemów krytycznych to jedna – i to zaledwie wstępna – kwestia z obszaru Disaster Recovery. Należy również wskazać niezbędne otoczenie systemów wspomagających. To także problemy decyzyjne i pytanie czy należy je również traktować jako systemy krytyczne, bo bez nich niczego nie da się uruchomić. Do tej problematyki można podejść bardzo obszernie i wówczas odbudowujemy praktycznie całe centrum danych, ale można też skupiać się na wybranych, punktowych typach danych.

Natomiast uwarunkowania są takie, że usługi powszechne – prąd, Internet, itd. – zaczynają być traktowane przez biznes jak powietrze: niezbędne i zawsze dostępne, a tak naprawdę przywrócenie usługi powszechnej także wymaga czasu i zasobów w scenariuszu odtwarzania. Inny problem dotyczy zlecenia konkretnych testów na żywym organizmie i udowodnienia, że środowisko produkcyjne jest bezpieczne, np. jako skutek utraty części infrastruktury. To oczywiście znakomite doświadczenie, ale bardzo delikatne.

Ł.P.: Mało która firma pozwoli na to, aby obszar kluczowej działalności stanowił zarazem poligon działań przypominających pracę sapera. Mamy tutaj paradoks. Z jednej strony widoczny jest apetyt na to, aby jak najwięcej testować na produkcyjnym organizmie, a z drugiej – przeważa obawa przed utratą zdolności do bieżącej działalności. Wypracowanie kompromisu bywa wyzwaniem, ale jest osiągalne

A.M.: To prawda. Odpowiadam za kreowanie w organizacji apetytu na ciekawe wyzwania i oczywiście jestem w tych działaniach temperowany. Nie jest to jednak wyzwanie tylko w sferze mentalnej, ale też – jak najbardziej fizycznej. Na przykład, standardowy i wystarczający do normalnego funkcjonowania zespół bazodanowy liczący 15-20 osób, gdzie każda osoba jest odpowiedzialna za kilka elementów, podczas realizacji scenariusza DR staje przed niezwykle trudnym zadaniem. Nagle członek tego zespołu na co dzień obsługujący trzy bazy danych, musi zgodnie z obowiązującym SLA w przeciągu 6 czy 12 godzin odtworzyć ich 70.

To nasuwa pytanie, czy ten apetyt dotyczy także innowacji umożliwiających testowanie większych całości np. przez przesuwanie ich do przestrzeni laboratoryjnych, gdzie eksperymentować można bezpiecznie – na zduplikowanym środowisku.

Ł.P.: Z moich doświadczeń wynika, że jest to kolejny etap rozwoju środowisk Disaster Recovery i element większej zmiany w kontekście DR. Choć nie umiemy jeszcze powiedzieć jaki przyjmie ostateczny kształt w takiej firmie jak PZU, ciągle jesteśmy na etapie eksperymentowania i szukania optymalnego dla wszystkich rozwiązania.

A.L.: Niektóre aspekty są pewne. Przykładowo, nie wyobrażam sobie, żebyśmy mieli postawioną równolegle drugą sieć testową. Serwery, nawet klastry, które mają jakieś dane i środowiska testowe tak, ale z siecią jest to niemożliwe do realizacji. Nie da się zatem wszystkiego wytestować, jeśli nie można działać na żywym organizmie.

Niektóre firmy mają poczucie, że system „Recovery” jest równoznaczny z „Disaster Recovery”. Chcę powiedzieć, że w ciągu 2 godzin będziemy w stanie odtworzyć jakąś część, np. 2-3 systemy, ale wąskim gardłem okaże się przepustowość systemu backup albo dostępność ludzi. Systemów krytycznych jest dużo, dlatego tak ważne jest wspominane tu klasyfikowanie i mapowanie ich zależności.

A.M.: W tym kontekście oczywiście bardzo ważnym kierunkiem jest automatyzacja. Staramy się pozyskiwać jak najwięcej nowych rozwiązań tego typu z rynku, ponieważ uniezależniają nas od czynnika ludzkiego. Rolą ludzi będzie wyłącznie podejmowanie decyzji kierunkowych.

R.P.: W kontekście Disaster Recovery, podstawowe znaczenie ma dotarcie z informacją, że w tym czasie, kiedy coś się wydarzy, pewne narzędzia albo ich większość nie będzie działała albo będzie działania inaczej, gorzej. O tym się zapomina, ale działanie w trybie Disaster Recovery to działanie w trybie nadzwyczajnym – nasi czytelnicy powinni mieć tego świadomość, szczególnie kiedy reprezentują tzw. biznes.

Po drugie – chciałbym kupować i gromadzić usługi, nie tylko związane z samymi kopiami zapasowymi, co z odtworzeniem kluczowych systemów. Poprzez portfel takich usług można porządkować zagadnienie Disaster Recovery w firmie. Taki model wpiera przejrzystość całego planu, ale też jasno określa progi – wiemy, że w pierwszej kolejności nie będą odzyskiwane środowiska testowe czy developerskie, tylko najbardziej podstawowe.

A.G.: Zgodzę się, że o wiedzę, świadomość i uwagę biznesu warto zabiegać. Na podstawowym poziomie często funkcjonuje przekonanie, że obsługujemy wszystkie scenariusze, od sytuacji, kiedy spali się RAM w jakimś serwerze, po katastrofę atomową. Podobnie często istnieje przekonanie, że wszystkie te scenariusze znajdują się w jednym pudełku. Aby być uczciwym, stale aktualizujemy informację o scenariuszach, które jesteśmy w stanie obsłużyć – i w jakim zakresie – a na jakie nie jesteśmy przygotowani.

W tym podejściu zawiera się także informacja, że przechowanie danych w bezpiecznym miejscu to jedno, ale do przywrócenia działania potrzebna będzie infrastruktura, działające serwery i integracja pomiędzy systemami. Każdy taki scenariusz trzeba jasno i uczciwie opisać właścicielom biznesowym po to, aby rozumieli związane z tym koszty – od najprostszych działań, po scenariusz zakładający istnienie żywych, dokładnych kopii.

A.L.: Ja z kolei zwróciłbym się do tych, którzy reprezentują instytucje nadzorujące nas i wymagające pewnych scenariuszy, z wnioskiem, aby ich oczekiwania były bardziej specyficzne. Dzięki bardziej złożonym scenariuszom można lepiej poznać i zrozumieć co jest zdarzeniem z kategorii „bomba atomowa”, a co bardziej powszechnym wypadkiem.

Ł.P.: Jest to porównywalne do zagadnienia, które właśnie mamy w PZU. Dotychczas realizowane scenariusze switch-over maja ustąpić miejsca scenariuszom failover, czyli sytuacjom nieprzewidzianym, odnoszącym się do zespołu lub infrastruktury.

S.P.: Oznacza to odejście od projektów rutynowych i testów. My mieliśmy podobny problem dwa lata temu. IT naciskało, żeby realizować testy ciągłości działania w środowisku produkcji. Argument był oczywisty – środowiska testowe są sztuczne. Scenariusze, które się dla nich tworzy także. W efekcie poświęca się masę czasu na działanie rozwiązań w środowisku testowym, nierealnym. Przeprowadziliśmy burzliwą dyskusję i uruchomiliśmy testy w środowisku produkcyjnym. Na dłuższą metę takiemu podejściu przeciwni byli jednak nasi kontrahenci.

Ważniejsze są dziś dla mnie te testy, które wykonujemy już samodzielnie, bez udziału kontrahentów, we własnym środowisku produkcyjnym. Co ważne, tzw. biznes naszych testów w zasadzie nie widzi – nie wie, że właśnie robimy przełączanie czy wyłączanie pewnych elementów. I o to właśnie nam chodzi. Tego rodzaju testy dowodzą, że nie mamy problemów, ale też mamy świadomość, że rzeczywiste zdarzenia są trudne do przewidzenia. Natomiast dzieje się to w mocno ograniczonym zakresie, nasze systemy są bowiem zależne od: banków, domów markierskich, banków centralnych, giełdy, systemu SWIFT.

R.P.: Mam kapitalne doświadczenia z ćwiczeń zrywających ze schematem testów realizowanych według konkretnego scenariusza. Dobrym pretekstem stało się połączenie testów rozwiązań zapewniających ciągłość biznesu z obowiązkowymi ćwiczeniami ze strażą pożarną. Umówiliśmy się wówczas ze strażakami, że ktoś będzie krzyczał, że ma pociętą rękę, ktoś zacznie panikować. Chodziło o przetestowanie emocji. Było to ważne doświadczenie.

Okazało się np., że namaszczony i certyfikowany menedżer BCP przepadł w tym ćwiczeniu. W sytuacji kryzysowej nie był w stanie działać, dostał ataku paniki. Jego rolę przejął płynnie ktoś inny. W podobnej sytuacji takich ćwiczeń dodatkowo wyrywaliśmy kable pomiędzy losowymi urządzeniami, żeby sprawdzić jak wówczas uda nam się przywrócić całość. Te dwa przypadki realistycznych i niezapowiedzianych ćwiczeń dały świetny materiał i zaowocowały zmianami.

CAŁOŚCIOWE PODEJŚCIE DO DISASTER RECOVERY

Chciałbym rozwinąć wątek uzyskania stałej gotowości do reagowania. Wydaje mi się, że może być ona dodatkowo wspierana informacją o charakterze predykcji – z rozmaitych źródeł monitorujących otoczenie cyfrowe i fizyczne.

P.D.: Warto pamiętać, że nie wszystko da się przewidzieć. Kluczem do budowy lepszego środowiska Disaster Recovery jest wyjście z dyskusjami o możliwych scenariuszach poza samo IT. Szersze spojrzenie pozwala dostrzegać więcej: od fizycznych urządzeń, po systemy inteligentne czy analizy ruchu w sieci użytkowników.

R.P.: Mówimy, wobec tego o podejściu sięgającym wskroś organizacji, a nawet poza firmę – w jej bliższe i dalsze otoczenie. Jakiś czas temu też rozpoczęliśmy działania w tym duchu – na razie niestety odzew nie jest wielki – a mianowicie zbierania informacji o incydentach i działaniach u kolegów z branży. Chcielibyśmy zbudować taki interdyscyplinarny, sektorowy zestaw wiedzy, która posłużyłaby jako podstawa dla realizujących DR. Jestem przekonany, że takie podejście ma wielkie perspektywy w kontekście całej branży life science, health care i farmacji. Doświadczenia, wnioski, interpretacje z wydarzeń, z praktyki mogłyby służyć szerzej niż tylko jednej firmie. Na razie to nie funkcjonuje z wielką szkodą dla wszystkich.

S.P.: Wróciłbym jeszcze do wspomnianej wcześniej kwestii predykcji w oparciu o narzędzia i o schematy sieciowe łączące ludzi o określonej wiedzy i kompetencjach. W naszym przypadku z przyczyn regulacyjnych i świadomych, własnych decyzji powstał dosyć otwarty model zarządzania ryzykiem operacyjnym. Gromadzi on wszelkie zdarzenia, twarde fakty oraz ich interpretacje – analizy i materiał tworzony przez ekspertów. Na tej podstawie wskazuje się różnego rodzaju możliwe zagrożenia, jak awarie u naszych klientów czy kontrahentów banków.

CZY DISASTER RECOVERY TO BIZNESOWE IP?

A.L.: Ja do tej dyskusji dołożę jeszcze jeden nieodzowny aspekt. Pandemia uświadomiła wielu branżom i firmom, co znaczy zależność od zewnętrznego dostawcy w sytuacji zerwania łańcuchów dostaw. Przypomnijmy sobie jakim wyzwaniem okazało się zdobycie w szybkim czasie urządzeń do zdalnego dostępu w określonym standardzie.

Kiedy wydarzy się awaria o szerokim zasięgu, kiedy uderzy w posiadającego wielu klientów dostawcę dowolnego zasobu, to nieuchronnie występuje wąskie gardło. Takim wąskim gardłem w kontekście procesów Disaster Recovery będzie np. architektura chmurowa dla kopii zapasowych. Jeśli w jakimś momencie, w wyniku szerszej awarii np. energetycznej po kopie zapasowe będzie chciało sięgnąć więcej firm jednocześnie, to nieuchronnie wytworzy się kolejka…

S.P.: Temat wymogu drogi wyjścia jest szczególnie ważny w kontekście chmury. Sytuacja, którą opisał Andrzej czy po prostu rynkowe zjawisko, kiedy w innym regionie pojawią się bardziej marżowi klienci sprawi, że możemy znaleźć się – niezbyt komfortowo – w takiej kolejce. Należy zatem zawczasu pomyśleć w jakim stopniu warto bezpośrednio wiązać się z dostawcą, który ma wiele usług masowych, żywotnych dla działania wielu organizacji.

A.G.: Temu właśnie służą analizy ryzyka. Chmura jest w tym kontekście wyjątkowo wdzięcznym obiektem do oceny, bo podlega uwarunkowaniom geopolitycznym, podlega monopolizacji i zjawiskom typu vedorlock.

Chciałbym poprosić, aby w podsumowaniu zawarli Panowie ocenę dwóch zagadnień z perspektywy Disaster Recovery. Pierwsza kwestia to zagadnienie dzielenia się doświadczeniem na różnych poziomach. Czy to ma szansę zaistnieć, czy jest to pewnego rodzaju IP, tajemnica konkurencyjności? Druga kwestia: transformacja chmurowa z perspektywy Disaster Recovery. Podnosi czy obniża poziom odporności?

M.K.: W przypadku rozwiązań Disaster Recovery doskonale widzimy, że nie działamy w próżni. Wokół nas żyje cały ekosystem, którego jesteśmy częścią. Świadomie stawiamy więc na dzielenie się dobrymi praktykami, także z konkurentami. Z niektórymi z nich wypracowujemy wręcz wspólnie standardy. Natomiast w kwestii chmurowej stoję na stanowisku potrzeby zdrowej, racjonalnej dywersyfikacji. Chmura jest dobra do różnych zastosowań, także w kontekście DR, kiedy nie można sobie pozwolić np. na cyfrowy bunkier.

A.G.: Wymiana wiedzy i współpraca w sektorze się pogłębia i jest to z pewnością zjawisko pozytywne. Niestety nie wierzę do końca w pełną transparentność i powszechną skłonność do dzielenia się wiedzą, jest to obecnie dużym stopniu własność intelektualna przedsiębiorstwa i źródło przewagi konkurencyjnej. Cyberprzestępcy zawsze szukają najłatwiejszych celów, więc im bardziej zabezpieczona organizacja, tym mniejsze prawdopodobieństwo ataku na nią. Z perspektywy DR chmura jest dodatkową opcją, bardzo dobrą do użycia w pewnych scenariuszach. To wykorzystanie chmury na potrzeby takich zastosowań będzie stale rosło, w różnych konfiguracjach z chmurą hybrydową, publiczną, specjalizowanymi, gotowymi usługami.

Ł.P.: Dzisiejsze spotkanie i dyskusja utwierdzają mnie w przekonaniu, że wymiana wiedzy jest bardzo potrzebna. Wynoszę dziś co najmniej dwa cenne pomysły przedstawione przez kolegów do dalszych przemyśleń. Jestem przekonany, że z częścią problemów z zakresu Disaster Recovery dużo szybciej uporalibyśmy się współpracując z innymi organizacjami. Niezależnie od tego pozostaną bowiem obszary indywidualne, specyficzne dla każdej firmy. Dwie wspomniane kwestie stanowią także wyzwanie od strony kompetencji, co z kolei będzie wymagało czasu i nakładów finansowych.

A.M.: Ja także oba zagadnienia postaram się sprowadzić do wspólnego wątku – ograniczeń prawnych. Z jednej strony, to dobrze, że regulator nakazuje pewne rzeczy i dąży do wprowadzenia standardu. Moje zastrzeżenia budzi jednak szereg zaleceń w kontekście Disaster Recovery, np. wymaganie konkretnych ćwiczeń, które nie zawsze da się osadzić w rzeczywistości danej organizacji. Druga sprawa dotyczy stereotypowego podejścia do kontroli jakości procesu Disaster Recovery. Gdziekolwiek i kiedykolwiek pada hasło „audyt”, to w domyśle rozumiane jest ono wyłącznie jako synonim wytykania błędów, a nie jako szansa na identyfikację słabych punktów w celu ich udoskonalenia.

S.P.: Ze względu na praktyczny wymiar, obszar DR staje się dziś bardzo bliski biznesowi. Przez 30 lat działania w tym obszarze cierpiały na swoisty uwiąd teoretyczny: plany i procedury miały więcej wspólnego z abstrakcją i formalizmem niż rzeczywistością. Teraz pojawia się zdecydowanie więcej praktyki, pragmatyzmu, dlatego też w naturalny sposób będzie rozwijać się wymiana doświadczeń i wiedzy. Podobną ewolucję do pragmatyzmu przeżył około 10 lat temu obszar cyberbezpieczeństwa, stąd także moja prognoza.

W przypadku rozwiązań chmurowych zgadzam się z tym, że należy dywersyfikować i nie wiązać się z jednym dostawcą. To powinna być zasada ogólna i zarazem szczególna dla obszaru Disaster Recovery. Sądzę, że nasze dzisiejsze obawy i dylematy nieuchronnie zostaną rozstrzygnięte przez prawo, konieczne do ograniczenia monopoli i ryzyka nadmiernego przywiązania do jednego dostawcy, a także do tego, aby otworzyć chmury na pełną konkurencję jakości i ceny usług.

A.L.: Według mnie chmura jest jednym z zestawów narzędzi, których należy używać. Oczywiście główni dostawcy chmury zaczynają budować bariery i mury, ale w odpowiedzi pojawiają się rozwiązania umożliwiające swobodne migrowanie pomiędzy platformami.

W kwestii współpracy jestem pełen nadziej, bo przecież porównując Polskę z krajami nordyckimi często widzę, że jesteśmy lepsi technicznie, szybciej znajdujemy rozwiązania, fajnie zachowujemy się w awariach, ale dużo bardziej konkurujemy ze sobą. Jesteśmy zamknięci, a mimo to osiągamy dobre wyniki. Natomiast organizacje z krajów nordyckich nadrabiają praktyką dzielenia się doświadczeniem, porażkami i informacjami. Zastanówmy się jak wiele moglibyśmy w Polsce osiągnąć przełamując tę nieufność?

R.P.: Chmura staje się dominującym standardem, z którego w tej chwili, jako farmacja, nie wyjdziemy. Mamy dziś układ zbudowany z dwóch platform chmurowych, który doskonalimy i rozwijamy. W kwestii wymiany doświadczeń to moim zdaniem – o ile uważam, że kwestie własności intelektualnej są bardzo ważne – informacje z zakresu DR i bezpieczeństwa nie są z kategorii dzieła sztuki, tylko rzetelnego rzemiosła. Co więcej, taka wymiana wiedzy musi nastąpić, ponieważ leży w interesie wszystkich. Oczywiście pozostanie kategoria tych, którzy z satysfakcją obserwujących cudze upadki, ale większość będzie pomagać i liczyć na pomoc.

P.D.: Sądzę, że wartością akceptowaną stanie się wspólne budowanie np. sektorowego bezpieczeństwa. Miejsca wymiany wiedzy będą wówczas czymś naturalnym, zaś sama wymiana będzie także pewnie dotyczyć sposobu wykorzystania chmury publicznej. To powinno pomóc w zdroworozsądkowym jej adaptowaniu, z uwzględnieniem potrzeb, regulacji oraz ograniczeń. Dywersyfikacja i uwzględnianie lokalnych dostawców z rynku europejskiego, powinny pomóc zbudować mocniejszą pozycję względem dostawcy, pewniejszą także pod względem zarzadzania ryzykiem.