Co ciągłość działania właściwie znaczy dla firmy naszej wielkości?

Ciągłość działania kontra disaster recovery, po ludzku

Te dwa terminy są używane zamiennie, a różnica ma znaczenie, bo mówi ci, kto za co odpowiada.

Ciągłość działania to szerokie pytanie: jeśli coś nas zakłóci, jak dalej obsługujemy klientów, płacimy ludziom i wywiązujemy się ze zobowiązań, aż wrócimy do normy? Obejmuje twoich ludzi, dostawców, gotówkę i reputację, nie tylko komputery. To sprawa zarządu, bo większość tych dźwigni jest w rękach zarządu.

Disaster recovery to węższe, techniczne pytanie w środku tego: jak odzyskujemy systemy IT i dane po awarii? Odtwarzanie serwerów, odzyskiwanie plików, przywracanie aplikacji online. Zwykle odpowiada za to IT albo zewnętrzny dostawca, i to jeden składnik ciągłości, nie cały posiłek.

Prosty sposób, żeby utrzymać to rozróżnienie: disaster recovery odzyskuje systemy, ciągłość działania utrzymuje firmę w ruchu, kiedy są niedostępne i po ich powrocie. Jeśli twoim jedynym planem jest techniczny plan odzyskiwania, przygotowałeś się na połowę problemu. Brakująca połowa to, jak biznes działa w tej luce, i to właśnie tę część naprawdę odczuwają klienci i regulatorzy.

ISO 22301, międzynarodowy standard zarządzania ciągłością działania, ujmuje to podobnie. Jest zbudowany wokół identyfikacji twoich najważniejszych działań, zrozumienia, jak długo możesz tolerować ich utratę, i wprowadzenia rozwiązań, które utrzymają je w ruchu albo szybko przywrócą. Nie musisz mieć certyfikacji, żeby pożyczyć tę logikę; dla większości firm mid-market standard jest punktem odniesienia dla dobrej praktyki, nie wymogiem.

Zacznij od garści funkcji, bez których nie działasz

Pierwszy odruch, kiedy ludzie zaczynają myśleć o ciągłości, to chronić wszystko po równo. Właśnie tak wysiłek grzęźnie, a rozmowa o budżecie donikąd nie prowadzi. Dyscyplina jest odwrotna: bądź szczery co do kilku funkcji, które, gdyby stanęły, naprawdę zagroziłyby firmie, i skoncentruj się na nich.

Dla większości firm mid-market ta lista jest krótka. Typowi kandydaci to przyjmowanie zamówień i otrzymywanie płatności, dostarczanie głównego produktu lub usługi, płacenie personelowi i dostawcom, oraz każdy system, który regulator albo umowa z kluczowym klientem wymaga utrzymać dostępnym. Wszystko inne zwykle może poczekać kilka dni bez trwałej szkody.

Praktyczny sposób na znalezienie tej listy to pytanie, funkcja po funkcji: gdyby to stanęło dziś rano, kiedy zaczęłoby to naprawdę boleć, do południa, do końca dnia, czy dopiero po tygodniu? Funkcje, które bolą w ciągu godzin, to twoja garść krytycznych. Zapisz je. Ta krótka lista to fundament, na którym wisi wszystko inne: mówi ci, gdzie wydawać pieniądze, gdzie budować fallbacki, i co twój plan musi chronić w pierwszej kolejności.

Dobry wynik to jednostronicowa lista od trzech do siedmiu krytycznych funkcji, uzgodniona przez zarząd, nie rozrośnięty spis każdego systemu, jaki firma posiada.

Zdecyduj, jak szybko potrzebujesz tego z powrotem i ile danych możesz stracić

Kiedy już znasz swoją garść krytycznych funkcji, dwa proste pytania zamieniają niepokój w cele. Ta dyscyplina ma na nie żargon, i warto się go raz nauczyć, bo pojawia się w umowach z dostawcami, formularzach ubezpieczeniowych i kwestionariuszach od klientów.

Pierwsze to recovery time: jak długo ta funkcja może być niedostępna, zanim szkoda stanie się poważna? W standardach to recovery time objective, czyli RTO. Jeśli twój system zamówień może być offline przez cztery godziny bez trwałej szkody, ale cały dzień kosztowałby cię klientów, twój recovery time mieści się w tym przedziale. To osąd biznesowy, nie techniczny, i to ty jesteś właściwą osobą, żeby go wydać.

Drugie to recovery point: jeśli musisz cofnąć się do backupu, ile najnowszej pracy możesz sobie pozwolić stracić? W standardach to recovery point objective, czyli RPO. Jeśli twój backup działa raz dziennie w nocy, odtworzenie z niego może stracić do dnia pracy wprowadzonej od czasu jego uruchomienia. Jeśli utrata dnia zamówień albo zapisów jest nie do przyjęcia, musisz robić backup częściej. Recovery point to tak naprawdę pytanie o to, jak często zapisujesz chronioną kopię.

Ustaw obie wartości dla każdej krytycznej funkcji osobno, bo się różnią. Możesz zaakceptować dzień przestoju dla wewnętrznego systemu dokumentów, ale tylko minuty utraconych danych w zapisach finansowych. Spisanie tych celów mówi twojemu zespołowi IT albo dostawcy, do czego dążyć, i ujawnia luki, w których to, co masz dziś, nie spełnia tego, czego potrzebuje biznes. Ta luka, znaleziona w spokojne popołudnie, nie w trakcie kryzysu, to cały sens tego ćwiczenia.

Dobry wynik to niewielka tabela: każda krytyczna funkcja, jej cel recovery time, cel recovery point, i uczciwa notatka, czy twoja obecna konfiguracja jest w stanie je spełnić.

Upewnij się, że backupy istnieją i że przetestowałeś ich odtwarzanie

Backupy to miejsce, w którym pewność siebie i rzeczywistość najczęściej się rozjeżdżają. Wiele firm wierzy, że ma dobre backupy, aż do dnia, w którym próbują z nich skorzystać i odkrywają, że były niekompletne, nieaktualne, albo zaszyfrowane razem z całą resztą.

Powszechnie rekomendowanym standardem jest zasada 3-2-1, którą CISA popiera jako praktyczną obronę zarówno przed ransomware, jak i zwykłą awarią sprzętu. Trzymaj trzy kopie ważnych danych, na dwóch różnych rodzajach nośników albo w dwóch lokalizacjach, z jedną kopią poza siedzibą. Pojedynczy backup leżący obok oryginału niewiele chroni, jeśli pożar, kradzież albo atak dosięgnie obu naraz.

Jedna współczesna komplikacja, o której lider powinien wiedzieć: operatorzy ransomware teraz celowo atakują backupy, usuwając je albo szyfrując, żebyś nie miał czystej kopii, do której mógłbyś się cofnąć, czasem używając skradzionych danych uwierzytelniających administratora, żeby dosięgnąć backupów w chmurze. Dlatego aktualne wytyczne dodają co najmniej jedną kopię offline albo niezmienialną, czyli kopię, której nie da się po cichu zmienić ani usunąć, nawet mając dostęp do twoich systemów. Zadaj swojemu zespołowi proste pytanie: gdyby atakujący dziś w nocy przejął pełną kontrolę nad naszą siecią, czy wciąż istniałby backup, którego nie mógłby dotknąć?

Pojedynczy najważniejszy nawyk, i ten najczęściej pomijany, to testowanie odtwarzania. Backup, który nigdy nie był odtworzony, to założenie, nie zabezpieczenie. Wytyczne CISA wprost mówią, że powinieneś testować procedury backupu, żeby zespół faktycznie potrafił odtworzyć dane, w pełni i częściowo, w czasie, jakiego oczekujesz. Test odtwarzania dwa razy w roku, na prawdziwych danych, jest wart więcej niż jakiekolwiek zapewnienie, że backupy „działają".

Dobry wynik to backupy zgodne ze standardem 3-2-1, obejmujące co najmniej jedną kopię, do której atakujący nie ma dostępu, i odtworzone w teście w ciągu ostatnich sześciu miesięcy, z zapisanym wynikiem.

Jeśli duża część danych twojej firmy żyje w aplikacjach chmurowych takich jak Microsoft 365 czy Google Workspace, a nie na twoich własnych serwerach, kwestia backupu ma własną komplikację. Powiązany przewodnik „Czy musisz robić backup danych SaaS" opisuje to szczegółowo.

Miej fallback dla rzeczy krytycznych

Dla każdej krytycznej funkcji następne pytanie jest proste: jeśli normalny sposób jej wykonywania jest niedostępny, jaki jest zapasowy sposób? Fallback nie musi być elegancki. Musi utrzymać funkcję przy życiu wystarczająco długo, żeby dało się ją odzyskać.

Fallbacki przybierają znajome formy. Ręczne obejście, na przykład zapisywanie zamówień w arkuszu, kiedy główny system nie działa, żeby nic nie zginęło i praca ruszyła dalej później. Opcja zapasowa, na przykład drugi dostawca, drugi dostawca płatności albo drugie łącze internetowe, żeby pojedyncza awaria cię nie zatrzymała. I znany, dobry punkt przywracania, żeby po powrocie systemów wrócić do czystego, aktualnego stanu, zamiast odbudowywać wszystko od zera.

Sens ustalania fallbacków z wyprzedzeniem jest taki, że dzień, w którym go potrzebujesz, to najgorszy możliwy dzień, żeby go wymyślać. Zespół, który już wie, że „jeśli system zamówień nie działa, zapisujemy zamówienia w tym wspólnym arkuszu i uzgadniamy je później", traci minuty. Zespół improwizujący pod presją traci godziny i popełnia błędy. Fallbacki potrzebujesz tylko dla tej garści krytycznych funkcji, które zidentyfikowałeś wcześniej.

Dobry wynik to nazwany, prosty fallback dla każdej krytycznej funkcji, zrozumiały dla ludzi, którzy faktycznie mieliby go użyć, a nie zakopany w dokumencie, którego nigdy nie widzieli.

Napisz krótki plan, który ludzie faktycznie potrafią wykonać

Plan ciągłości istnieje po to, żeby używali go zestresowani ludzie w zły dzień, co oznacza, że krótki i jasny bije dokładny i nieprzeczytany. Plan, który przetrwa prawdziwy incydent, mieści się na kilku stronach i odpowiada na praktyczne pytania, jakie zada osoba będąca w jego środku.

Minimum, jakie musi obejmować użyteczny plan: kto jest za to odpowiedzialny i kto go zastępuje, jeśli ta osoba jest nieosiągalna, jak zespół się komunikuje, jeśli normalne systemy i e-mail nie działają, krytyczne funkcje i ich fallbacki, do kogo dzwonić poza firmą (dostawca IT, ubezpieczyciel, kluczowi dostawcy, wsparcie prawne), i prosta sekwencja pierwszych kroków. Trzymaj dane kontaktowe aktualne i miej kopię dostępną nawet wtedy, kiedy twoje systemy nie działają, bo plan przechowywany wyłącznie w sieci, która właśnie padła, to żaden plan.

Powstrzymaj chęć, żeby zrobić go wyczerpującym. Szczegółowe techniczne kroki odzyskiwania należą do zespołu IT albo dostawcy, który je wykona. Plan zarządu to stabilna, czytelna warstwa na wierzchu: kto decyduje, kto co robi, i jak utrzymujesz biznes w ruchu, podczas gdy pod spodem trwa odzyskiwanie.

Dobry wynik to plan, który nowy manager mógłby wziąć do ręki i wykonać, z jasnymi rolami, aktualnymi kontaktami i kopią dostępną, kiedy systemy nie działają.

Przećwicz go, zanim będzie potrzebny

Plan, który nigdy nie był przećwiczony, to dokument, nie umiejętność. Lukę między tymi dwoma wypełnia praktyka, a ta praktyka nie musi być rozbudowana ani kosztowna.

Najprostszą i najbardziej wartościową formą jest ćwiczenie tabletop: zbierz na godzinę osoby wymienione w planie, opisz na głos realistyczny scenariusz i przejdź przez to, co każda osoba faktycznie by zrobiła. Żaden system nie jest dotykany i nic nie jest zagrożone. To, co odkryjesz, zawsze jest przydatne: nieaktualny numer telefonu, fallback zależny od systemu, który też by nie działał, kluczowa osoba, która okazuje się jedyną wiedzącą, jak coś zrobić, decyzja, za którą wyraźnie nikt nie odpowiada. Każdą z tych rzeczy dużo taniej znaleźć w sali konferencyjnej niż w żywym kryzysie.

Robienie tego raz albo dwa razy w roku, i po każdej istotnej zmianie w systemach albo zespole, utrzymuje plan w zgodzie z rzeczywistością, a ludzi w nim pewnych siebie. Pierwsze ćwiczenie prawie zawsze ujawnia problemy, i właśnie dlatego robi się je, zanim przyjdzie prawdziwe wydarzenie.

Dobry wynik to co najmniej jedno ćwiczenie tabletop rocznie, z zapisanymi i naprawionymi lukami, które ujawnia, tak żeby plan się poprawiał, zamiast stać w miejscu.

Trzy realistyczne scenariusze, na które warto się przygotować

Abstrakcyjne planowanie trudno przełożyć na działanie, więc warto zakotwiczyć tę pracę w zakłóceniach, które faktycznie zdarzają się firmom mid-market. Trzy pokrywają większość terenu.

Atak ransomware

Atakujący szyfruje twoje pliki i systemy i żąda zapłaty, często najpierw usuwając albo szyfrując twoje backupy, żebyś nie miał czystej kopii, do której mógłbyś się cofnąć. To tu twój recovery point i twoje przetestowane, izolowane backupy zarabiają na swoje utrzymanie. Pytanie o ciągłość nie brzmi tylko „czy IT może odtworzyć systemy", ale „jak dalej obsługujemy klientów i zapisujemy pracę przez dni, które to może zająć", i tu mają znaczenie fallbacki i komunikacja. Powiązany przewodnik „Pierwsze 24 godziny po naruszeniu" opisuje natychmiastową reakcję szczegółowo.

Kluczowy dostawca oprogramowania pada

Możesz prowadzić krytyczną funkcję całkowicie przez jedną aplikację chmurową: platformę księgową, system zamówień albo narzędzie komunikacji. Jeśli ten dostawca ma poważną awarię trwającą dzień, twoje własne techniczne odzyskiwanie nic nie pomoże, bo to nie twoje systemy, żeby je odtworzyć. Odpowiedzią jest fallback, który nie zależy od tego dostawcy (ręczne obejście, drugie narzędzie albo uzgodniony sposób na bezpieczne wstrzymanie i nadrobienie pracy) oraz jasność z wyprzedzeniem co do tego, od jakich dostawców jesteś aż tak zależny.

Utrata dostępu do głównych systemów

Czasem nie tracisz danych, tracisz dostęp: konto zostaje zablokowane, dane uwierzytelniające zresetowane, system logowania pada, albo spór o rozliczenie zawiesza usługę. Praca wciąż istnieje, ale nie możesz się do niej dostać. Warto to zaplanować właśnie dlatego, że nie wygląda to jak katastrofa, dopóki się w niej nie znajdziesz. Zdecyduj z wyprzedzeniem, kto może przywrócić dostęp, jak szybko, i co robi biznes w międzyczasie.

Każdy scenariusz obciąża inną część planu: ransomware testuje twoje backupy, awaria dostawcy testuje twoje fallbacki, a utrata dostępu testuje twoje założenia co do kontroli.

Źródła

• ISO 22301:2019, Security and resilience, Business continuity management systems, International Organization for Standardization (międzynarodowy standard ujmujący ciągłość wokół krytycznych działań i celów odzyskiwania) · https://www.iso.org/standard/75106.html
• Key Definitions Used in ISO 22301 and ISO 22313, PECB (definicje recovery time objective i recovery point objective) · https://pecb.com/en/article/key-definitions-used-in-iso-22301-and-iso-22313
• RTO vs. RPO: Key Differences Explained, Advisera (rozróżnienie recovery time i recovery point objective prostym językiem) · https://advisera.com/27001academy/knowledgebase/what-is-the-difference-between-recovery-time-objective-rto-and-recovery-point-objective-rpo/
• Back Up Business Data, CISA (standard backupu 3-2-1, kopie poza siedzibą i offline, testowanie odtwarzania) · https://www.cisa.gov/audiences/small-and-medium-businesses/secure-your-business/back-up-business-data
• Back Up Government Data, CISA (testowanie backupów pod kątem pełnego i częściowego odtworzenia, cofnięcie o co najmniej siedem dni, kopie offline i szyfrowane) · https://www.cisa.gov/audiences/state-local-tribal-and-territorial-government/secure-us-sltt/back-government-data