Backup selektywny w erze RODO i konkretnego użytkownika

Kopia zapasowa a archiwizacja – po co to robimy? Zagadnienie, które w zasadzie powinno być już oczywiste, a jego poruszanie może budzić kontrowersje wśród specjalistów, często pozostaje poza zainteresowaniem właścicieli biznesowych aplikacji. Wszak obie metody zabezpieczania danych kojarzone są przez biznes wyłącznie z kosztem i działają jak każde ubezpieczenie, które trzeba opłaci i jak najszybciej zapomnieć. Do czasu, kiedy trzeba z takiej polisy skorzystać. Wtedy – i najczęściej tylko wtedy – następuje brutalna weryfikacja jak dobrą polisę sobie przygotowaliśmy i na jakie okazje jesteśmy ubezpieczeni.

Taką podstawową polisą jest kopia zapasowa, nazywana wprost po angielsku: backup. I choć słowo to na stałe zagościło w naszych słownikach w oryginalnym, angielskim brzmieniu, to kopia zapasowa chyba lepiej oddaję istotę tego zagadnienia. Wykonujemy ją, aby przywrócić system do działania po awarii lub by wycofać zmianę. Interesują nas wówczas parametry takie jak RPO (Recovery Point Objective) czyli punkt w czasie, do którego przywracamy system oraz RTO (Recovery Time Objective) czyli całkowity czas przywrócenia jego funkcjonalności.

Archiwizacja powinna nam się kojarzyć z danymi i to tymi, które są na co dzień nieużywane, ale jednocześnie są ważne in powinny być długo przechowywane. Wspaniałym przykładem, szczególnie w wiosennym okresie są nasze rozliczenia PIT. Jesteśmy zobowiązani przechowywać dokumentacje podatkową, gdyż urzędnik skarbowy w każdej chwili może o nią zarządzać, ale na co dzień nie jest ona nam potrzeba i istnieje relatywnie małe prawdopodobieństwo, że kiedykolwiek będzie. Nie będziemy zatem poświęcać jej najbardziej eksponowanego miejsca w naszym domu trzeba ją mieć! Podobnie jest z danymi archiwalnymi, które w organizacji nie muszą zajmować miejsca na najszybszych modułach SSD czy NVMe, ale są składowane na dużo tańsze magazyny obiektowe czy ciągle jeszcze taśmy.

Perspektywa silosu kontra perspektywa tożsamości

Warto jednak zauważyć, że oba wcześniej wspomniane pojęcia, przynajmniej na dziś, związane są z konkretnym systemem, który zabezpieczamy. Zespoły dbające o nasze kopie zapasowe i archiwa dedykują zasoby dla konkretnych rozwiązań, np. CRM, poczta elektroniczna czy ERP. Mamy więc perspektywę funkcjonalną. Co byłoby, gdyby to całkowicie zmienić, stawiając człowieka w centrum uwagi? Wyobraźmy sobie sytuację, że tworzymy politykę kopii zapasowej dla konkretnych osób i grup zamiast dla systemów IT?

Dzisiaj w narzędziach takich producentów jak Veritas, Veeam, Commvault i wielu innych tworzy się politykę, w której określone zostaje jakie komponent infrastruktury są zabezpieczane, na jaki czas i jak często wykonujemy kopię zapasową. Jeśli dla przykładu wyobrazimy sobie serwer plików, to w takiej polityce wskazujemy, które foldery mają być zabezpieczone, względnie jakie dane mają być przesunięte do archiwum do długoterminowego przechowywania. Nie operujemy tu tożsamością właścicieli tych danych – jedynie miejscem ich przechowywania. Ponadto każdy z systemów traktujemy w pewnym sensie rozłącznie i zarządzamy przez zupełnie osobne polityki.

Jeśli zatem zaistnieje potrzeba odtworzenia wszystkich danych konkretnej osoby, np. z powodu toczącego się procesu sądowego, musimy najpierw zinwentaryzować wszystkie systemy, w do których dany użytkownik miał dostęp a następnie przeglądać kopie zapasowe i archiwa jedno po drugim odtwarzając dane jeden po drugim. Oczywiście przez ostatnie lata producenci rozwiązań zabezpieczania danych pracują nad ich rozwojem i oferują coraz to szersze możliwości w selektywnym odtwarzaniu. Od dawna już nie musimy odtwarzać całego serwera Microsoft Exchange, aby odzyskać pojedyncza skrzynkę czy wiadomość danego użytkownika. Jeśli jednak potrzebujemy wszystkie dane konkretnej osoby ze wszystkich systemów, na dzisiaj żadna konsola nam takiej możliwości nie daje. Ciągle zabezpieczamy systemy z perspektywy funkcjonalnej, z perspektywy silosów technologicznych.

Przydałby się zatem tak zbudowany system, aby jego operator mógł w polityce kopii zapasowych określić jej parametry dla konkretnych osób, grup, zespołów czy departamentów. Kolejnym parametrem byłyby systemy docelowe, do których dany użytkownik ma dostęp. Narzędzia kopii zapasowych integrowałyby się z nimi – podobnie jak dzisiaj za pomocą wtyczek – jednak zachowując w archiwach metadane, szczegółowo opisujące właścicielstwo danych. Fantazjując nieco można tu sobie wyobrazić, że w konsoli konfigurujemy kopię zapasową dla konkretnego człowieka, określając, gdzie i jak długo przechowujemy jego dane i z jakich systemów powinniśmy je pozyskać.

Gdy nadchodzi potrzeba ich odtworzenia mamy pełny przegląd z perspektywy konkretnej osoby lub grupy. Jeśli więc użytkownik zgłasza zaginięcie wiadomości e-mail, w systemie backup odszukujemy jego tożsamość i przywracamy jego skrzynkę. Wygląda na niewielką zmianę, ale jeśli jeszcze trochę rozwiniemy wyobraźnię, można uzyskać swego rodzaju wehikuł czasu. Otóż przyjmijmy, że użytkownik pracuje nad projektem w wielu systemach i popełnia błąd, który się rozpropagował. W takiej sytuacji zbawienne byłoby proste wydanie polecenia „przywróć moją tożsamość i w wszystkie moje dane w systemach A, B, C i D z wczoraj z godziny 16:00”. System kopii zapasowych posiadający perspektywę użytkownika przywróciłby pożądany stan w wielu miejscach na raz na dodatek spójnie. Idąc dalej w tych rozważaniach, można wyobrazić sobie sprawę sądową czy audyt – bo przecież kopia zapasowa jest na czasy złe, na wypadek awarii. Mając w narzędziach technologicznych perspektywę tożsamości, nie silosu technologicznego odnalezienie danych konkretnej osoby czy historii jej poczynań, mogłoby trwać znacznie krócej i być wielokrotnie łatwiejsze.

Czy to dalej ta sama kopia zapasowa i archiwum?

Takie właśnie pytanie można byłoby sobie zadać mając do dyspozycji system backup, umożliwiający zarządzanie danymi z perspektywy tożsamości. Skoro kopią zapasową jest taki zestaw danych, który pozwala nam – w dużym uproszczeniu – na powrót do stanu np. z przed awarii to czy mając zarchiwizowane dane wszystkich użytkowników z wielu systemów warto jest jeszcze przechowywać je w kopii zapasowej? Może wystarczyłoby przechować jedynie binarna poszczególnych aplikacji, obrazy systemów operacyjnych, skrypty instalacyjne i konfigurację poszczególnych komponentów. Po ich odtworzeniu wybrać zaś zakres tożsamości do odtworzenia i „wstrzyknąć” te dane do pracującego już systemu? Na tym etapie pomijam oczywiście czas potrzebny na tę operacje.

Być może dzisiaj łatwiej przywrócić cały system z danymi. Chcę jednak podkreślić, że zmieniając perspektywę możemy nieco zmienić procesy. Być może na cele wprowadzania zmian technologicznych wystarczyłby jedynie kopie migawkowe komponentów? W ten sposób można nieco przenieść nacisk z typowej kopii zapasowej na archiwizację danych użytkowników optymalizując w ten sposób zasoby potrzebne na zapewnienie RPO i RTO poszczególnych systemów. Otwiera to szereg nowych możliwości w zakresie przeszukiwania danych, wykrywania przyczyn błędów, budowania mechanizmów zapewniania zgodności prawnej, kontroli jakości, nadużyć i wielu, wielu innych.

Automatyzacja, integracja i metadane

To pojęcia jakie pierwsze przychodzą mi na myśl, gdy rozważam, czy zaproponowana wcześniej wizja jest możliwa do realizacji. Dzisiaj oczywiście nie są jeszcze gotowe kompleksowe narzędzia zapewniające opisane wcześniej możliwości wyselekcjonowania danych przypisanych do tożsamości. Wszystko jednak wskazuje, że świat zmierzą w tym właśnie, lub co najmniej zbliżonym kierunku. Automatyzacja posunęła się dzisiaj bardzo daleko. Najbardziej nowoczesne aplikacje – najczęściej serwowane z platform chmurowych lub kontenerowych – samodzielnie się skalują i naprawiają. Mechanizmy AI i ML powodują, że są to komponenty coraz bardziej autonomiczne. Jednocześnie systemy te korzystają częściej niż z typowych systemów plików – z baz danych nierelacyjnych, zasobów obiektowych i metadanych. Warstwa danych jest tym samym jeszcze bardziej oddzielona od samej infrastruktury.

Warto zauważyć, że jeśli aplikacja przechowuje dane jako obiekt, czyli plik z metadanymi, inna aplikacja będzie mogła łatwo z nich skorzystać. Wystarczy bowiem sięgnąć do silnika indeksującego metadane otrzymać odpowiedzi na zadane pytania. Co więcej, można te metadane wzbogacić z różnych perspektyw w żaden sposób nie komunikując aplikacji między sobą. Jedyną platformą wymiany informacji między nimi będzie silnik metadanych dostępny przez API. Co ważne, w ten właśnie sposób uwalniamy się od konkretnego dostawcy. Bardzo dobrze widać to na przykładzie systemów przechowywania dokumentacji elektronicznej – ECM (Enterprise Content Management). Jeśli wszystkie dokumenty i ich metadane przechowywane są w postaci obiektu w magazynie obiektowym, zamiast w bazie danych konkretnego rozwiązania, jak wiele prościej jest te same obiekty podłączyć do innego rozwiązania i wykorzystać zapisane tam metadane?

Ponadto w modelu Infrastructure-as-a-Code konfiguracja i integracja realizowana są w momencie powoływania komponentów na podstawie opisu w formacie YAML lub innych. Generalnym założeniem DevOps jest szybka budowa i modyfikacja platform. Czy musimy je zatem zabezpieczać kopią zapasową? W pewnym zakresie być może tak. Jednak lwią część będą stanowiły dane, które możemy już łatwo wyobrazić sobie w modelu zarządzania z perspektywy tożsamości. Do tego oczywiście potrzebne są konektory i ich dzisiaj najbardziej brakuje. Jak już wspominałem – producenci systemów archiwizacji i kopii zapasowych robią co mogą, aby jeszcze bardziej precyzyjnie móc odtwarzać dane w poszczególnych systemach. Jednak jeszcze wiele brakuje, żeby można było takim podejście obsłużyć 100% komponentów w każdej organizacji. Różne wtyczki mają różny zakres funkcjonalności dla różnych systemów. Tu jeszcze jest wiele do zrobienia. Być może odpowiedzią byłoby wspólne, standardowe API, np. IdentityBackupAPI? Wtedy nawet wewnętrzne zespoły deweloperskie mogłyby tak pisać systemy dla swojej organizacji, żeby umożliwić procesy zarządzania kopiami z perspektywy tożsamości.

ETL i narzędzia indeksujące

Czy opisane powyżej, całkiem obiecujące możliwości są dzisiaj w zasięgu ręki? W tak idealnym, w pełni zintegrowanym wydaniu chyba nie. Jednak trwają prace, które tak mogą nam wkrótce pomóc. Wszak choćby potrzeba realizacji prawa do zapomnienia zdefiniowanego w dyrektywie RODO wymaga od nas często niełatwych zabiegów. Nikt wprawdzie dzisiaj nie odtwarza wszystkich systemów składowanych na taśmach, aby usunąć dane konkretnej osoby i zapisać całość kopii zapasowej ponownie. Udało się wypracować pewne proceduralne podejście do tego zagadnienia, ale możemy się spodziewać, że granularność na poziomie konkretnej tożsamości będzie coraz bardziej potrzebna.

W tym nieco pomagają narzędzia indeksujące, mechanizmy ETL, które na dzisiaj pomagają nam opisywać i inwentaryzować posiadane dane. Już dzisiaj dostępne są narzędzia, które mogą przeszukać wiele źródeł danych i zbudować indeksy. Oferują je w postaci pudełkowych rozwiązań producenci, którzy od lat zajmują się cyklem życia danych w organizacji – jak Veritas czy Hitachi. Nie mniej wymagane są elementy wykonawcze, które realnie będą potrafiły zabezpieczyć i przywrócić dane w dowolnym systemie z dokładnością do pojedynczych osób. Na dzisiaj wydaje się, że wiele już nie brakuje do osiągnięcia tego efektu.