Ratuj dane, kto może
- Krzysztof Jakubik,
- 01.12.2004
W naturę człowieka wpisane jest dążenie do sukcesu, a nie analityczne myślenie o skutkach katastrof. Dlatego większość planów Disaster Recovery, opisujących konieczne do wykonania czynności po wystąpieniu katastrofy w firmie, ma luki, często dość poważne. Nie pomaga też fakt, że w tworzeniu planów Disaster Recovery rzadko angażują się zarządy firm.
W naturę człowieka wpisane jest dążenie do sukcesu, a nie analityczne myślenie o skutkach katastrof. Dlatego większość planów Disaster Recovery, opisujących konieczne do wykonania czynności po wystąpieniu katastrofy w firmie, ma luki, często dość poważne. Nie pomaga też fakt, że w tworzeniu planów Disaster Recovery rzadko angażują się zarządy firm.
O konieczności dbałości o dane przypominają nam takie zdarzenia, jak chociażby awaria twardego dysku. Oczywiście utrata danych dla każdego będzie miała inny wymiar - dla jednych emocjonalny, dla innych finansowy. Ten pierwszy, chociaż mniej groźny dla podmiotu, który stracił dane, będzie występował coraz częściej - fotografia cyfrowa (czy też inne formy cyfrowej rejestracji wspomnień) rozwija się i popularyzuje zdecydowanie szybciej niż technologie zabezpieczające cyfrowe zdjęcia (a fotografie tradycyjne o wiele trudniej utracić, niż fotografie cyfrowe).
W przypadku utraty danych w firmie skala konsekwencji często trudna jest do określenia. Jedne firmy staną na nogi po kilku dniach, zaś dla innych może oznaczać to natychmiastowe bankructwo. Zresztą całkowita utrata danych to jeden z najgorszych możliwych przypadków, który można sobie wyobrazić. Dla wielu katastrofą finansową jest kilkugodzinny przestój systemu informatycznego, a coraz więcej firm twierdzi, że ogromny wpływ na ich finanse ma nawet spadek wydajności systemu o kilkadziesiąt procent. Stąd firmy kładą coraz większy nacisk na rozwój systemów utrzymania ciągłości biznesowej (Business Continuity) oraz tworzenie planów szybkiego przywrócenia firmy do stanu sprzed awarii (Disaster Recovery), które z założenia powinny być częścią strategii Business Continuity.
Mało optymistyczne są jednak informacje dotyczące zaangażowania w tworzenie planów Disaster Recovery. Według wyników badań w Polsce w proces ten zarząd firmy angażuje się tylko w 14% instytucji (co jest i tak lepszym wynikiem niż w całej Europie czy USA). 17% firm nie ma w ogóle planu Disaster Recovery, 57% plan taki ma, ale kontroluje jego aktualność tylko raz w roku lub rzadziej, zaś 6% firm nie robiło tego w ogóle. Co czwarta firma nigdy nie testowała swojego planu Disaster Recovery.
70% firm przechowuje plan Disaster Recovery jako dokument w swojej głównej siedzibie, tam gdzie znajduje się centrum obliczeniowe (62% przechowuje go tylko tam, w przypadku zawalenia się budynku wiedza o tym, jak odzyskać dane, zostanie pogrzebana wraz z tymi danymi). Tylko co piąta firma przechowuje ten dokument w swoim centrum zapasowym (z reguły oddalonym o 16 km), a 15% przedsiębiorstw - w siedzibie innej firmy. 5% dyrektorów IT przyznało, że w ogóle nie wie, gdzie jest przechowywany ich plan Disaster Recovery!
Jak długo i czemu tak krótko?
Przy tworzeniu naszej strategii Business Continuity staniemy przed koniecznością wyliczenia łącznego czasu w ciągu całego roku, gdy nasz system nie funkcjonuje zgodnie z naszymi oczekiwaniami. Znajomość tej wartości pomoże nam dobrać zarówno metodę zabezpieczania danych, jak i odpowiedni sprzęt. Czynność ta czasem jest określana "wyliczaniem dziewiątek" - sens tego określenia widać na zamieszczonym obok wykresie.
Gdy możemy pozwolić sobie codziennie na kilka godzin niedostępności systemu (np. w nocy), sytuacja jest dość prosta. Wówczas spokojnie możemy zrobić tzw. zimny backup danych, którego wykonanie praktycznie uniemożliwi pracę na serwerach.
Z gorących backupów korzystamy, gdy naszego systemu nie możemy wyłączyć całkowicie, a w ciągu doby są ogromne różnice w obciążeniu serwerów. Wówczas wykonywanie backupu pochłania dość znaczną część mocy obliczeniowej wykorzystywanych do tego serwerów, ale praca wciąż jest możliwa.
Rozwiązania gwarantujące dostępność na poziomie 99,9% (przestój krótszy niż 9 godz. w skali roku) są już bardziej skomplikowane i wymagają dodatkowych nakładów finansowych na sprzęt i oprogramowanie. Umożliwiają m.in. wykonanie tzw. kopii migawkowych (snapshot) - zamrożenia "obrazu" danych o pewnej, określonej godzinie i zarejestrowanie go np. na taśmie. Oczywiście macierz dyskowa rejestruje wszystkie zmiany w plikach powstałe od momentu wykonania snapshotu - dostępne są one dla wszystkich uprawnionych użytkowników.
Kolejną metodą, dość często stosowaną w systemach, w których przetwarzanych jest wiele danych finansowych, jest replikacja - wykonywanie kopii danych w geograficznie wydzielonym centrum obliczeniowym (własnym bądź wynajętym). Są trzy metody replikacji: periodyczna, asynchroniczna i synchroniczna. Przy zastosowaniu replikacji periodycznej określone porcje danych są kopiowane do ośrodka zapasowego co pewien czas. W replikacji asynchronicznej dane kopiowane są ciągle, ale wolniej, niż przetwarzane są w centrum podstawowym. Szybkość kopiowania danych zależy od szerokości pasma, zaś podczas awarii w centrum podstawowym dane znajdujące się w centrum zapasowym nie są w pełni aktualne. Najbardziej zaawansowaną formą jest replikacja synchroniczna, w której (podobnie jak w macierzy RAID 1) dane od razu są kopiowane do ośrodka zapasowego, równolegle podczas zapisywania ich w ośrodku podstawowym. Jest to więc wierna kopia danych, ale rozwiązanie to obniża wydajność systemu informatycznego i wymaga dość szerokiego pasma transmisji danych.
Gdy przed awarią chcemy zabezpieczyć nie tylko dane, ale całe środowisko informatyczne, możemy skorzystać z technologii klastrowej - lokalnej (LAN) lub rozległej (WAN).
Ogólne zasady bezpieczeństwa
- Skuteczność zabezpieczeń zależy od ludzi. Żaden system bezpieczeństwa nie obroni systemu informatycznego, jeżeli człowiek, któremu zaufano, zawiedzie.
- Nie ma bezwzględnej miary bezpieczeństwa. Poziom bezpieczeństwa można mierzyć tylko w odniesieniu do precyzyjnie określonych w tym zakresie wymagań stawianych systemowi.
- Nie istnieje algorytm, który dla dowolnego systemu ochrony mógłby określić, czy dana konfiguracja systemu ochrony jest bezpieczna.
- System bezpieczeństwa musi być systemem spójnym, tzn. muszą być stosowane łącznie różne metody ochrony. Inaczej powstaną w nim luki.
- stosowanie określonych procedur wytwarzania oprogramowania i sprzętu,
- stosowanie odpowiedniego oprogramowania systemowego i dodatkowego,
- stosowanie odpowiednich konfiguracji sprzętowych (UPS, nadmiarowość konfiguracji),
- stosowanie mechanizmów składowania danych,
- szyfrowanie informacji.
- kontrola dostępu do obiektów i pomieszczeń,
- zabezpieczenie przeciw włamaniom,
- systemy zasilania awaryjnego,
- systemy przeciwpożarowe.
- regulaminy dla osób korzystających z systemów informatycznych,
- polityka bezpieczeństwa,
- polityka zakupu sprzętu i oprogramowania.
- kontrola praw dostępu pracowników do danych o szczególnym znaczeniu,
- przestrzeganie odpowiednich procedur zwalniania i zatrudniania pracowników,
- motywowanie pracowników,
- szkolenia.
- Zasada wiedzy koniecznej - prawa muszą wynikać z obowiązków.
- Zasada minimalnego środowiska pracy - prawo dostępu tylko do pomieszczeń związanych z obowiązkami.
- Zasada dwóch osób - funkcje, które mogą być wykorzystane do złamania zabezpieczeń, należy podzielić, a ich wykonanie powierzyć różnym osobom.
- Zasada rotacji obowiązków - za szczególnie ważne funkcje nie powinna być odpowiedzialna cały czas ta sama osoba.