„Mamy backup” to za mało, żeby mówić o cyberodporności.
W sytuacji awarii, incydentu lub ataku ransomware liczy się nie sam fakt posiadania kopii zapasowych, ale realna zdolność odtworzenia danych, systemów i kluczowych usług.
Co może łączyć szpital, który musi utrzymać dostęp do dokumentacji medycznej i ciągłość pracy oddziałów, z prywatną uczelnią, która odpowiada za dane studentów, pracowników, systemy dydaktyczne i administracyjne? Na pierwszy rzut oka niewiele. W praktyce jednak obie organizacje w sytuacji cyberataku bardzo szybko stają przed tym samym pytaniem: czy jesteśmy w stanie bezpiecznie odtworzyć dane i przywrócić działanie kluczowych usług?
To pytanie jest znacznie ważniejsze niż klasyczne: „czy mamy backup?”. W wielu organizacjach odpowiedź na nie brzmi: tak, backup jest. Zadania wykonują się cyklicznie, system generuje raporty, konsola pokazuje poprawne statusy, a procedura kopii zapasowych istnieje w dokumentacji. Problem polega na tym, że samo posiadanie backupu nie oznacza jeszcze odporności. Odporność zaczyna się dopiero tam, gdzie organizacja potrafi wykazać, że dane można skutecznie, bezpiecznie i w wymaganym czasie odtworzyć.
Ransomware bardzo brutalnie weryfikuje tę różnicę. Atakujący od dawna nie ograniczają się do szyfrowania środowiska produkcyjnego. Coraz częściej próbują odnaleźć i unieszkodliwić kopie zapasowe, przejąć konta administracyjne, dostać się do repozytoriów backupowych, skasować retencję, zaszyfrować backup serwer albo wykorzystać fakt, że środowisko backupowe jest zbyt blisko połączone z infrastrukturą produkcyjną. Jeżeli backup jest dostępny z tych samych kont, tych samych sieci i tych samych ścieżek administracyjnych co systemy produkcyjne, to w praktyce może stać się kolejnym elementem powierzchni ataku.
Dlatego dojrzałe podejście do backupu nie polega wyłącznie na ustawieniu harmonogramu zadań. Wymaga zrozumienia, które dane i systemy są naprawdę krytyczne, jaki jest oczekiwany czas ich odtworzenia, jaka utrata danych jest akceptowalna, gdzie przechowywane są kopie, kto ma do nich dostęp, jak są chronione oraz czy procedury odtworzeniowe były kiedykolwiek przetestowane w warunkach zbliżonych do rzeczywistego kryzysu.
Największym ryzykiem w backupie jest fałszywe poczucie bezpieczeństwa. Organizacja może przez lata wykonywać kopie, a mimo to dopiero podczas incydentu odkryć, że krytyczna baza danych nie była objęta backupem, retencja nie pozwala wrócić do właściwego punktu w czasie, kopie były przechowywane w tej samej domenie bezpieczeństwa co produkcja, procedura odtworzeniowa jest nieaktualna, a deklarowane RTO i RPO nigdy nie zostały skonfrontowane z realnymi wymaganiami biznesu. Wtedy backup przestaje być mechanizmem ochronnym, a staje się źródłem kolejnego kryzysu decyzyjnego.
Odporne środowisko backupowe powinno być projektowane z założeniem, że incydent kiedyś nastąpi. Dlatego coraz częściej punktem odniesienia nie jest już sama zasada 3-2-1, ale jej rozszerzona wersja: 3-2-1-1-0. Oznacza ona utrzymywanie co najmniej trzech kopii danych, przechowywanych na dwóch różnych typach nośników, z jedną kopią poza główną lokalizacją organizacji, jedną kopią offline, odseparowaną lub niezmienialną oraz z zerową liczbą błędów potwierdzoną regularnymi testami odtworzeniowymi. W praktyce chodzi o to, aby backup nie był dostępny dla atakującego z tego samego środowiska, które zostało przejęte, oraz aby organizacja miała dowód, że kopia jest kompletna, integralna i możliwa do odtworzenia w wymaganym czasie.
Z tego powodu audyt systemu backupu powinien być traktowany jako jeden z kluczowych elementów budowania cyberodporności. Jego celem nie jest formalne potwierdzenie, że organizacja posiada kopie zapasowe. Celem jest ustalenie, czy środowisko backupowe realnie wspiera ciągłość działania, czy obejmuje krytyczne zasoby, czy jest odporne na typowe scenariusze ataku oraz czy organizacja potrafi odtworzyć dane i usługi w czasie zgodnym z wymaganiami biznesu.
Taki audyt powinien zaczynać się od weryfikacji dokumentacji, polityk i procedur backupu, ale nie może się na tym kończyć. Konieczna jest inwentaryzacja systemów i danych, porównanie stanu rzeczywistego z dokumentacją, analiza konfiguracji oprogramowania backupowego, harmonogramów, typów kopii, retencji i lokalizacji przechowywania danych. Trzeba sprawdzić, czy zasada 3-2-1 jest rzeczywiście spełniona, czy kopie są chronione przed nieautoryzowanym dostępem, czy stosowane są mechanizmy niezmienialności i separacji oraz czy środowisko backupowe nie jest zbyt łatwe do przejęcia po kompromitacji infrastruktury produkcyjnej.
Kluczowym elementem audytu pozostaje test odtworzeniowy. To on oddziela deklaracje od faktów. Może polegać na analizie procedur i raportów z wykonanych odtworzeń albo na praktycznym przywróceniu wybranych danych, systemów lub usług zgodnie z uzgodnionym scenariuszem. Dopiero taki test pozwala ocenić, czy organizacja ma nie tylko kopie, ale także realną zdolność powrotu do działania.
Efektem dobrze przeprowadzonego audytu powinien być nie tylko raport techniczny, lecz także mapa dojścia do odporności. Organizacja powinna wiedzieć, które luki są krytyczne, które można usunąć szybko, które wymagają projektu architektonicznego, a które wynikają z braku procedur, właścicieli lub decyzji biznesowych. Taki raport powinien być użyteczny zarówno dla zespołu IT, jak i dla osób odpowiedzialnych za bezpieczeństwo, ciągłość działania, zgodność regulacyjną oraz decyzje zarządcze.
Cyberodporność nie oznacza, że organizacja nigdy nie zostanie zaatakowana. Oznacza, że potrafi ograniczyć skutki incydentu, podejmować decyzje na podstawie faktów, odtworzyć dane, przywrócić usługi i wrócić do działania bez chaosu oraz bez uzależnienia od scenariusza narzuconego przez atakujących.
Backup jest jednym z fundamentów tej odporności. Ale tylko wtedy, gdy został właściwie zaprojektowany, zabezpieczony, udokumentowany i przetestowany.
Dlatego nie warto czekać na ransomware, awarię, kontrolę, audyt klienta albo pytania ubezpieczyciela cyber. Warto sprawdzić backup wcześniej, w kontrolowanych warunkach, zanim stanie się ostatnią linią obrony organizacji.
Bo w dniu incydentu pytanie nie będzie brzmiało: „czy mamy backup?”.
Pytanie będzie znacznie trudniejsze: czy potrafimy z niego wrócić?
Wprowadź dane swojej firmy: