Aegis Backup
Poniżej opisujemy dokładnie, co dzieje się przy każdej kopii, gdzie leży klucz, dlaczego robimy wyłącznie kopie pełne i co dzieje się z danymi po upływie retencji.
Architektura
Aegis Backup to autorskie oprogramowanie, nie odsprzedaż cudzej usługi. Kontrolujemy wszystkie trzy części.
Zarządza przestrzenią, kontami i politykami przechowywania. To tutaj obowiązuje retencja, poza zasięgiem serwera klienta.
Punkt integracji. Wydaje aplikacji klienckiej czasowe, wąsko określone uprawnienia dostępu.
Instalowana na serwerze klienta. Szyfruje dane i wysyła je do przestrzeni backupu.
Przepływ
Skrypt przygotowany przez nas pod konkretne środowisko wykonuje kopię bazy danych, plików albo maszyny wirtualnej.
Skrypt uruchamia agenta Aegis zainstalowanego na serwerze klienta. To jedyny element, który komunikuje się z naszą infrastrukturą.
Agent łączy się z API Aegis i otrzymuje ograniczone czasowo pozwolenie. Zakres jest wąski: jeden, wydzielony katalog utworzony na potrzeby tej konkretnej kopii — i tylko zapis. Nie odczyt, nie usuwanie, nie nadpisywanie.
Dane są szyfrowane kluczem klienta jeszcze na jego serwerze, a następnie przesyłane do przestrzeni backupu w Unii Europejskiej.
Po zakończeniu transferu pozwolenie przestaje obowiązywać, a katalog pozostaje nietykalny. Kolejna kopia trafia do własnego, nowego katalogu.
Klucze
Dane są szyfrowane po stronie klienta, przed opuszczeniem jego serwera. Klucz przechowywany jest na Waszym serwerze i nigdy nie trafia do Aegis. Nie przechowujemy kluczy klientów, więc nie mamy technicznej możliwości odczytania powierzonych danych.
Odtwarzanie
Kopia, której nikt nigdy nie odtworzył, jest tylko rachunkiem za przestrzeń dyskową.
Na życzenie klienta łączymy się zdalnie z jego serwerem i przeprowadzamy odtworzenie na miejscu — tam, gdzie znajduje się klucz. Dane przez cały czas pozostają po stronie klienta i nie przechodzą przez naszą infrastrukturę w postaci odszyfrowanej.
W tym samym modelu wykonujemy regularne testy przywracania kopii. Chodzi o to, żeby wiedzieć, że backup działa, zanim będzie potrzebny — a nie dopiero w dniu awarii. Zakres, czas reakcji i częstotliwość testów ustalamy indywidualnie.
Kopie pełne
Powód jest przede wszystkim architektoniczny. Aplikacja kliencka dostaje jednorazowe, ograniczone czasowo uprawnienie wyłącznie do zapisu, do jednego wydzielonego katalogu — bez prawa odczytu, usuwania i nadpisywania. Kopia przyrostowa wymagałaby odczytu wcześniejszych kopii, bo bez nich nie ma z czego złożyć ani odtworzyć łańcucha.
Doszłoby do tego zarządzanie retencją po stronie Waszego serwera. Kopie są zaszyfrowane kluczem, którego nie posiadamy, więc przestrzeń przechowywania nie wie, który plik jest bazą dla którego przyrostu — usunięcie kopii pełnej unieważniłoby wszystko, co po niej nastąpiło. Decyzję o usuwaniu musiałaby podejmować aplikacja kliencka, czyli serwer, który atakujący może przejąć. To dokładnie te dwa uprawnienia, których brak jest podstawą odporności na ransomware.
Osobno, niezależnie od uprawnień, liczy się kruchość samego modelu: w wariancie przyrostowym i różnicowym odtworzenie danych wymaga kompletnego, nieuszkodzonego łańcucha plików, a utrata, uszkodzenie lub manipulacja jednym ogniwem może unieruchomić cały późniejszy zestaw kopii. Każda kopia pełna jest natomiast samodzielna — do odtworzenia wystarczy jeden plik, niezależny od wszystkich pozostałych.
Ma to swoją cenę i nie zamierzamy jej ukrywać: kopie pełne zajmują więcej miejsca, a rozliczamy się za ilość przechowywanych danych. Mechanizmem kontroli kosztu jest polityka retencji i częstotliwość wykonywania kopii, ustalane indywidualnie na etapie wdrożenia. Przy dużych źródłach — zwłaszcza maszynach wirtualnych — projektujemy to razem z klientem, a nie ustawiamy domyślnie.
Środowiska
Poza tą listą obowiązuje prosta zasada: jeśli dane da się zrzucić skryptem, da się je zabezpieczyć.
Wdrożenie
Wdrożenie nie jest samoobsługowe i uważamy to za zaletę. Klient nie musi rozumieć backupu — dostaje zautomatyzowany proces, który po prostu działa.
Przygotowujemy skrypt, który zrzuca dane z konkretnego systemu i wywołuje aplikację kliencką. Nie dostajecie generycznego narzędzia do samodzielnej konfiguracji.
Instalujemy agenta, ustawiamy harmonogram i retencję, sprawdzamy pierwsze kopie. Przy okazji ustalamy, gdzie poza serwerem produkcyjnym leży kopia klucza.
Wycena
Nie mamy cennika ani darmowego okresu próbnego — i wolimy powiedzieć to od razu niż w ofercie.
Podstawą rozliczenia jest liczba gigabajtów trzymanych w przestrzeni backupu.
Okres przechowywania i częstotliwość kopii projektujemy razem z klientem — to główny mechanizm kontroli kosztu.
Za przygotowanie skryptów i uruchomienie procesu w środowisku klienta. Mówimy o niej od razu, nie w ofercie.
Nie mamy sztywnych pakietów ani cennika na stronie. Wycenę przygotowujemy indywidualnie, po rozmowie o tym, co dokładnie ma być zabezpieczone.
Poproś o wycenęPytania
Standardowe rozwiązania dają serwerowi dostęp z uprawnieniami do kasowania. Jeśli dane uwierzytelniające wyciekną z serwera, atakujący usuwa kopie. U nas serwer takich uprawnień nie posiada — dostaje jednorazowe pozwolenie na zapis do jednego katalogu i nic ponadto.
Wystarczy lista systemów i przybliżona objętość danych. Resztę — harmonogram, retencję i skrypty — przygotujemy my.
