Która warstwa kopii zapasowych powinna zarządzać kluczami szyfrowania: klient, repozytorium czy lokalizacja zewnętrzna?

W przypadku większości kopii zapasowych serwerów domowych aplikacja do tworzenia kopii zapasowych lub klient powinien kontrolować szyfrowanie niezbędne do odczytu kopii zapasowej, natomiast szyfrowanie stosowane przez dostawcę pamięci masowej poza siedzibą powinno być traktowane jako dodatkowa warstwa. Dzięki temu przejęcie chmury lub zdalnej pamięci masowej nie ujawni automatycznie zawartości kopii zapasowych, a jednocześnie zostanie zachowany format kopii, który nadal umożliwia wydajną deduplikację, weryfikację i przywracanie danych.

Istotne rozróżnienie nie polega po prostu na „szyfrowaniu po stronie klienta lub serwera”. Trzeba zdecydować, która domena awarii jest właścicielem sekretu deszyfrowania. Jeśli jedyny klucz istnieje na serwerze źródłowym, awaria serwera lub zaszyfrowanie go przez oprogramowanie ransomware może uniemożliwić odzyskanie danych. Jeśli miejsce docelowe poza siedzibą przechowuje jedyny istotny klucz, operator tego miejsca lub przejęte konto docelowe mogą nadal znajdować się wewnątrz granicy zaufania. Najlepszy projekt oddziela dane kopii zapasowych, dane uwierzytelniające repozytorium i klucze odzyskiwania.

Istnieją trzy różne miejsca, w których może znajdować się szyfrowanie

Określenie „zaszyfrowana kopia zapasowa” kryje w sobie kilka architektur. Pliki źródłowe można zaszyfrować, zanim zobaczy je narzędzie do tworzenia kopii zapasowych. Narzędzie do tworzenia kopii zapasowych może zaszyfrować format swojego repozytorium przed wysłaniem obiektów do lokalnej lub zdalnej pamięci masowej. System pamięci masowej w miejscu docelowym może też otrzymać dane i zaszyfrować je w spoczynku, korzystając z własnej warstwy zarządzania kluczami.

Szyfrowanie na poziomie repozytorium jest zazwyczaj najlepszym ustawieniem domyślnym

Nowoczesne narzędzia do tworzenia kopii zapasowych są zaprojektowane tak, aby szyfrować dane jako część formatu repozytorium. Dokumentacja szyfrowania restic traktuje szyfrowanie jako podstawową funkcję repozytorium i obsługuje wiele kluczy dostępu lub haseł. Kopia podobnie opisuje swoje repozytoria jako dodające szyfrowanie i deduplikację do zapleczy pamięci masowej, takich jak systemy plików, S3 i chmurowe magazyny obiektowe.

Borg szczególnie jasno przedstawia model zaufania. Jego dokumentacja bezpieczeństwa zakłada, że środowisko klienta jest zaufane, a repozytorium może być wrogie. Borg szyfruje dane lokalnie, dzięki czemu zdalne repozytorium nie otrzymuje plików w postaci jawnej ani niezaszyfrowanego klucza kopii zapasowej.

Ten model jest atrakcyjny w przypadku domowego serwera NAS, ponieważ aplikacja do tworzenia kopii zapasowych nadal może widzieć oryginalne pliki podczas tworzenia kopii. Może wykonywać dzielenie na fragmenty, deduplikację, kompresję, obsługę metadanych migawek, weryfikację oraz selektywne przywracanie przed szyfrowaniem lub równolegle z nim. Miejsce docelowe otrzymuje zaszyfrowane obiekty repozytorium zamiast zwykłych, czytelnych plików.

Nie myl klucza repozytorium z danymi uwierzytelniającymi pamięci masowej

Klucz dostępu do zasobnika w chmurze, prywatny klucz SFTP, hasło do zdalnego serwera NAS i klucz deszyfrowania kopii zapasowej to różne sekrety, nawet jeśli skrypt automatyzujący potrzebuje ich wszystkich. Dane uwierzytelniające pamięci masowej odpowiadają na pytanie: „czy ten klient może odczytywać obiekty repozytorium lub zapisywać je w nim?”. Klucz repozytorium odpowiada na pytanie: „czy te obiekty można odszyfrować do postaci danych kopii zapasowej?”.

Rozdzielenie tych elementów ma znaczenie podczas incydentu. Osoba atakująca, która wykradnie dane uwierzytelniające do zapisu w zasobniku, nie powinna automatycznie uzyskać sekretu deszyfrowania repozytorium. Z kolei posiadanie hasła do kopii zapasowej nie powinno samo w sobie zapewniać dostępu administracyjnego do zdalnego konta pamięci masowej.

Przewodnik ZimaSpace dotyczący weryfikowania każdego klucza wymaganego do zaszyfrowanego przywracania jest przydatnym uzupełnieniem, ponieważ przedstawia dostęp do repozytorium, szyfrowanie kopii zapasowej, pamięć docelową, sekrety kontenerów i sekrety na poziomie aplikacji jako odrębne zależności procesu odzyskiwania.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Szyfrowanie po stronie klienta najlepiej sprawdza się w przypadku wąskich zakresów danych o wysokiej wrażliwości

Szyfrowanie plików przed ich odczytaniem przez aplikację do tworzenia kopii zapasowych może mieć sens, gdy określony zbiór danych musi pozostać niejawny nawet dla zwykłych narzędzi do tworzenia kopii zapasowych lub administratorów. Przykłady obejmują niewielkie archiwum prawnicze, wyeksportowaną bazę haseł, pakiet kluczy prywatnych lub zaszyfrowany kontener kontrolowany przez klienta.

Kompromis polega na tym, że szyfrowanie wykonane zbyt wcześnie może ukryć strukturę, którą system kopii zapasowych mógłby w innym przypadku wykorzystać. Jeśli każdy zmieniony plik staje się całkowicie innym zaszyfrowanym wynikiem, kompresja i deduplikacja mogą działać mniej skutecznie. Przeglądanie pojedynczych plików może również wymagać dwuetapowego przywracania: najpierw odzyskania zaszyfrowanego obiektu, a następnie odblokowania go za pomocą innego narzędzia.

Z tego powodu pełne szyfrowanie zbioru danych przed wykonaniem kopii jest zwykle słabszą domyślną architekturą domowej kopii zapasowej niż użycie narzędzia do tworzenia kopii zapasowych z natywnym uwierzytelnianym szyfrowaniem repozytorium. Stosuj je wtedy, gdy celowo potrzebujesz dodatkowej granicy zaufania wokół podzbioru danych.

Szyfrowanie po stronie serwera kopii zapasowych poza siedzibą chroni pamięć masową, ale nie cały model zaufania kopii zapasowej

Chmurowe magazyny obiektowe zazwyczaj szyfrują dane w spoczynku. Amazon S3 domyślnie stosuje na przykład szyfrowanie po stronie serwera i obsługuje klucze KMS zarządzane przez AWS lub klienta. W dokumentacji SSE-KMS opisano, jak S3 wykonuje szyfrowanie w miejscu docelowym, podczas gdy AWS KMS kontroluje klucze i uprawnienia.

Backblaze B2 również obsługuje zarządzane przez dostawcę SSE-B2 oraz zarządzane przez klienta SSE-C. W dokumentacji szyfrowania po stronie serwera wyjaśniono, że SSE chroni dane plików w spoczynku oraz że utrata klucza SSE-C zarządzanego przez klienta sprawia, że dane stają się niemożliwe do odzyskania.

Szyfrowanie po stronie serwera jest wartościowe. Pomaga chronić nośniki fizyczne i infrastrukturę pamięci masowej, a zasady KMS zarządzane przez klienta mogą zapewnić silne mechanizmy kontroli organizacyjnej. Jeśli jednak docelowa usługa może odszyfrować dane za każdym razem, gdy otrzyma autoryzowane żądanie dostępu do pamięci masowej, nadal znajduje się wewnątrz granicy poufności. Różni się to od przesłania repozytorium Borg, restic lub Kopia, które zostało zaszyfrowane przed dotarciem do dostawcy.

Używaj szyfrowania poza siedzibą jako dodatkowej warstwy ochrony

Praktyczna odpowiedź często brzmi: „oba”. Pozwól aplikacji do tworzenia kopii zapasowych zaszyfrować zawartość repozytorium przed przesłaniem, a następnie pozostaw włączone standardowe szyfrowanie celu w spoczynku jako dodatkowy mechanizm ochrony. Obie warstwy chronią przed różnymi zdarzeniami.

Klucz musi przetrwać maszynę, którą chroni

Najważniejsza zasada rozmieszczenia kluczy jest prosta: nie przechowuj jedynej kopii odzyskiwania sekretu szyfrującego na serwerze, którego kopia zapasowa jest tworzona. Aktualny przewodnik inicjalizacji repozytorium Borg wyraźnie zaleca przechowywanie kopii zapasowej klucza Borg poza repozytorium i systemem tworzącym kopie zapasowe.

Ta sama zasada dotyczy haseł restic, haseł repozytoriów Kopia, kluczy age, materiału odzyskiwania LUKS, administracji chmurowym KMS oraz głównych kluczy aplikacji. Doskonale zaszyfrowane repozytorium jest bezużyteczne, jeśli jedyny sekret deszyfrujący zniknie wraz z uszkodzonym dyskiem rozruchowym.

W gospodarstwie domowym lub małym laboratorium przechowuj co najmniej jedną kopię odzyskiwania offline albo w oddzielnym systemie poświadczeń, który nie zależy od działania NAS-a. Następnie przetestuj przywracanie na czystej maszynie. Zapisane hasło, którego nigdy nie użyto do otwarcia repozytorium, jest dowodem udokumentowania, a nie dowodem możliwości odzyskania danych.

Która warstwa powinna przechowywać klucz w typowych konfiguracjach domowych serwerów?

Domowy NAS wykonujący kopie zapasowe w pamięci obiektowej

Przed opuszczeniem NAS-a używaj natywnego szyfrowania repozytorium w restic, Borg, Kopia lub porównywalnym narzędziu do tworzenia kopii zapasowych. Przechowuj klucz lub hasło do repozytorium poza NAS-em. Pozostaw włączone szyfrowanie zasobnika jako dodatkową warstwę ochrony. Dzięki temu cel w chmurze nie będzie jedynym mechanizmem zapewniającym poufność.

Domowy NAS wykonujący kopie zapasowe na zdalnym serwerze znajomego

Preferuj szyfrowanie po stronie klienta lub repozytorium, którego klucz danych w postaci jawnej nie znajduje się na serwerze znajomego. Zdalny host może przechowywać nieczytelne obiekty repozytorium i egzekwować ograniczone uprawnienia zapisu. Jest to szczególnie cenne, ponieważ fizyczna i administracyjna kontrola nad zdalnym komputerem należy do innej domeny awarii.

Lokalny dysk kopii zapasowej przechowywany w tym samym domu

Szyfrowanie repozytorium nadal chroni poufność, jeśli dysk zostanie utracony lub skradziony. Szyfrowanie całego dysku kopii zapasowej może stanowić przydatną drugą warstwę, ale nie dopuść do tego, by klucz odblokowujący dysk stał się jedyną drogą dostępu do repozytorium kopii zapasowej.

Zarządzana chmurowa kopia zapasowa z funkcjami odzyskiwania danych przez dostawcę

Szyfrowanie zarządzane przez dostawcę może być rozsądnym rozwiązaniem, gdy prostota i odzyskiwanie danych z pomocą dostawcy są ważniejsze niż wykluczenie dostawcy z granicy zaufania danych w postaci jawnej. Należy pamiętać, że jest to inna decyzja dotycząca bezpieczeństwa niż szyfrowanie po stronie klienta w modelu wiedzy zerowej.

Nie umieszczaj wszystkich sekretów kopii zapasowych w jednym pliku automatyzacji

Zautomatyzowane zadanie tworzenia kopii zapasowej wymaga poświadczeń, ale wygoda może zniwelować granice bezpieczeństwa. Wskazówki restic dotyczące automatyzacji ostrzegają, że sposób przekazywania haseł może ujawnić poświadczenia, i zalecają staranną ochronę plików z hasłami.

W przypadku serwera domowego, jeśli to możliwe, rozdziel co najmniej następujące role:

• Poświadczenie o ściśle ograniczonym zakresie, umożliwiające dostęp do miejsca docelowego kopii zapasowej.
• Hasło lub klucz deszyfrujący repozytorium.
• Przechowywana offline kopia zapasowa tego hasła/klucza.
• Poświadczenia administratora umożliwiające usuwanie zasad przechowywania, zasobników lub kont zdalnych.

To rozdzielenie jest ważniejsze niż decyzja, czy konkretny sekret powinien być przechowywany w pliku, zmiennej środowiskowej, menedżerze haseł, tokenie sprzętowym czy systemie KMS. Architektura powinna uniemożliwiać, aby jedna skradziona poświadczenie automatyzacji jednocześnie odczytywało dane w postaci jawnej, usuwało repozytorium i niszczyło jedyny klucz odzyskiwania.

Szyfrowanie nie zastępuje niezmienności ani testowania przywracania

Poufność, integralność, odporność na usunięcie i możliwość odzyskania to odrębne cele. Zaszyfrowane repozytorium nadal można usunąć. Niezmienny zasobnik może nadal zawierać kopie zapasowe, do których utracono klucz deszyfrujący. Pomyślnie zakończone zadanie tworzenia kopii zapasowej może nadal zakończyć się niepowodzeniem podczas przywracania.

Porównanie usług ZimaSpace: zdalnego serwera kopii zapasowych i obiektowej pamięci masowej w chmurze na potrzeby kopii zapasowych maszyn wirtualnych prowadzi do tego samego wniosku operacyjnego: etykieta celu ma mniejsze znaczenie niż to, czy przeprowadzono rzeczywisty test odzyskiwania.

Macierz decyzyjna

Ostateczny werdykt

W większości samodzielnie hostowanych systemów kopii zapasowych pozwól, aby klient kopii zapasowej lub format repozytorium odpowiadał za granicę szyfrowania treści, a cel zdalny szyfrował dane dodatkowo w spoczynku. Dzięki temu zachowasz funkcje kopii zapasowych, takie jak deduplikacja i weryfikacja, a jednocześnie ograniczysz zakres zaufania do zdalnego systemu przechowywania w odniesieniu do danych w postaci jawnej.

Plan zarządzania kluczami jest kompletny dopiero wtedy, gdy sekret deszyfrujący przetrwa utratę serwera źródłowego, celu przechowywania i zwykłej stacji roboczej administratora. Przetestuj to założenie z czystej maszyny, zanim uznasz kopię zapasową za możliwą do odzyskania.

Najczęściej zadawane pytania

Czy szyfrowanie po stronie serwera w chmurze wystarcza w przypadku domowych kopii zapasowych?

Chroni dane w spoczynku, ale zwykle pozostawia usługę przechowywania w granicach zaufania odszyfrowywania. Używaj również szyfrowania natywnego dla kopii zapasowej, gdy nie chcesz, aby dostawca lub skradzione dane uwierzytelniające do pamięci masowej wystarczyły do uzyskania dostępu do danych w postaci jawnej.

Czy klucz repozytorium powinien być przechowywany w repozytorium?

Niektóre formaty kopii zapasowych przechowują w repozytorium zaszyfrowany obiekt klucza, ale odzyskanie danych nadal zależy od innego sekretu, takiego jak silne hasło. Niezależne materiały odzyskiwania przechowuj poza repozytorium i systemem źródłowym.

Czy szyfrowanie plików przed utworzeniem kopii zapasowej poprawia bezpieczeństwo?

Może utworzyć dodatkową granicę zaufania dla wrażliwych podzbiorów danych, ale zaszyfrowanie wszystkiego, zanim dane zobaczy narzędzie do tworzenia kopii zapasowych, może ograniczyć deduplikację, kompresję, widoczność metadanych i wygodę przywracania.

Jaki jest najważniejszy test zarządzania kluczami?

Przywracanie z czystej maszyny po założeniu, że oryginalny serwer NAS jest całkowicie niedostępny. Jeśli nie możesz znaleźć wszystkich danych uwierzytelniających i odszyfrować reprezentatywnych danych, plan zarządzania kluczami jest niekompletny.