Wersjonowanie, MFA Delete i replikacja

Przechowywanie wersji w S3 umożliwia zachowanie, pobieranie i przywracanie każdej wersji każdego obiektu przechowywanego w bucketu. Gdy przechowywanie wersji jest włączone, każda operacja PUT tworzy nową wersję z unikalnym identyfikatorem wersji; stara wersja zostaje zachowana, a nie zastąpiona. Po usunięciu obiektu S3 dodaje znacznik usunięcia jako bieżącą wersję, ale zachowuje wszystkie wcześniejsze wersje. Chroni to przed przypadkowym zastąpieniem, przypadkowym usunięciem i niezamierzoną korupcją danych na poziomie aplikacji — najczęstszymi scenariuszami utraty danych w środowisku produkcyjnym.

Bucket S3 może znajdować się w jednym z trzech stanów przechowywania wersji: Unversioned (domyślny, bez identyfikatorów wersji), Versioning-enabled (wszystkie nowe obiekty otrzymują unikalne identyfikatory wersji, a każde zastąpienie tworzy nową wersję) lub Versioning-suspended (nowe obiekty otrzymują identyfikator wersji null, ale istniejące wersje zostają zachowane). Po włączeniu przechowywania wersji nie można go usunąć — można je tylko zawiesić. Obiekty utworzone przed włączeniem przechowywania wersji mają identyfikator wersji null i nie zostaną zmienione, dopóki nie zostaną zastąpione lub usunięte.

Aby przywrócić starszą wersję obiektu z włączonym przechowywaniem wersji, można skorzystać z dwóch opcji. Opcja 1: należy skopiować identyfikator starszej wersji z powrotem do tego samego klucza — spowoduje to utworzenie nowej wersji będącej kopią starszej zawartości i ustawienie jej jako bieżącej. Opcja 2: należy usunąć bieżącą wersję lub znacznik usunięcia, aby poprzednia wersja stała się bieżącą. Gdy w konsoli „usuwają” Państwo obiekt z bucketu z włączonym przechowywaniem wersji, nie podając identyfikatora wersji, S3 dodaje znacznik usunięcia — obiekt wygląda na usunięty dla żądań nieuwzględniających wersji, ale wszystkie wersje nadal istnieją.

MFA Delete dodaje drugą warstwę ochrony dla bucketów z włączonym przechowywaniem wersji. Po włączeniu tej funkcji trwałe usunięcie określonej wersji lub zmiana stanu przechowywania wersji bucketu (enabled → suspended) wymaga podania prawidłowych danych MFA w żądaniu API. Chroni to przed trwałym usunięciem krytycznych wersji przez osobę atakującą, która przejęła poświadczenia AWS, przypadkowym lub automatycznym usunięciem przypiętych wersji obiektów oraz zagrożeniami wewnętrznymi polegającymi na próbie zniszczenia śladów audytowych. Funkcję MFA Delete może włączać i wyłączać wyłącznie użytkownik root za pośrednictwem interfejsu CLI.

S3 Object Lock wymusza model WORM (write-once-read-many) na potrzeby zgodności z przepisami. Obiektów zablokowanych za pomocą Object Lock nie można usuwać ani zastępować przez określony okres przechowywania — nawet przy użyciu konta root. Dostępne są dwa tryby: Governance mode (użytkownicy ze specjalnymi uprawnieniami mogą zastąpić blokadę lub ją usunąć) oraz Compliance mode (nikt, nawet AWS, nie może usunąć obiektu w okresie przechowywania — jest to najsilniejsza ochrona). Funkcję Object Lock należy włączyć podczas tworzenia bucketu; wymaga ona także włączenia przechowywania wersji.

Cross-Region Replication (CRR) automatycznie replikuje nowe obiekty i aktualizacje z bucketu źródłowego w jednym regionie do bucketu docelowego w innym regionie. Przykładowe zastosowania to: zgodność z przepisami (przechowywanie kopii danych w określonym kraju), odtwarzanie po awarii (zmniejszenie RPO dla krytycznych danych dzięki utrzymywaniu kopii w drugim regionie) oraz redukcja opóźnień (udostępnianie obiektów z regionu znajdującego się najbliżej użytkowników). CRR wymaga włączenia przechowywania wersji zarówno w bucketach źródłowym, jak i docelowym, oraz roli IAM z niezbędnymi uprawnieniami do replikacji.

Same-Region Replication (SRR) replikuje obiekty w obrębie tego samego regionu. Przykładowe zastosowania to: agregacja logów (replikowanie logów z wielu bucketów źródłowych do jednego centralnego bucketu), synchronizacja środowiska testowego (utrzymywanie kopii danych produkcyjnych w buckecie deweloperskim w tym samym regionie) oraz zgodność z zasadą suwerenności danych w jednym kraju, w którym znajduje się wiele stref dostępności AWS. Podobnie jak CRR, SRR wymaga włączenia przechowywania wersji w obu bucketach oraz roli IAM. Automatycznie replikowane są tylko nowe obiekty utworzone po włączeniu replikacji — do replikowania istniejących obiektów należy użyć S3 Batch Replication.

Replikacja S3 obejmuje: nowe obiekty, metadane, tagi, listy ACL i stan szyfrowania. Domyślnie replikacja nie obejmuje: obiektów istniejących przed jej włączeniem (w ich przypadku należy użyć S3 Batch Replication), znaczników usunięcia (chyba że włączą Państwo Delete Marker Replication), obiektów w Glacier (nie można ich replikować — najpierw należy je przywrócić) ani obiektów już zreplikowanych (replikacja kaskadowa między trzema bucketami nie jest obsługiwana). Zrozumienie tych ograniczeń jest ważne podczas projektowania kompletnych strategii odtwarzania po awarii, w których trzeba również replikować dane historyczne i zdarzenia usunięcia.

Replication Time Control (RTC) to opcjonalny dodatek do CRR, który zapewnia umowę SLA: 99,99% obiektów zostaje zreplikowanych w ciągu 15 minut, a w CloudWatch dostępne są metryki replikacji i powiadomienia. Bez RTC replikacja nie ma gwarantowanego czasu realizacji — większość obiektów jest replikowana szybko, ale w pojedynczych przypadkach może to potrwać kilka godzin. RTC jest niezbędne, gdy wymagania dotyczące odtwarzania po awarii lub zgodności z przepisami określają maksymalny cel punktu odtwarzania (RPO) dla danych w S3. Oprócz standardowego kosztu transferu danych podczas replikacji naliczana jest opłata za replikację za każdy GB.

Włączenie wersjonowania zwiększa koszty przechowywania, ponieważ S3 zachowuje każdą wersję każdego obiektu do momentu jej jawnego usunięcia. Plik o rozmiarze 100 MB, który zostanie nadpisany 10 razy, zajmuje teraz 1000 MB przestrzeni. Można temu zapobiec za pomocą reguł cyklu życia, które automatycznie usuwają nieaktualne wersje po określonej liczbie dni (np. usuwają nieaktualne wersje starsze niż 30 dni) lub przenoszą je do tańszych klas przechowywania, takich jak Glacier. W środowisku produkcyjnym zawsze należy łączyć wersjonowanie z regułami cyklu życia, aby kontrolować koszty przechowywania.

Wersjonowanie S3 w połączeniu z Object Lock (tryb Compliance) zapewnia silną ochronę przed ransomware. Jeśli osoba atakująca zaszyfruje lub usunie obiekty, wersjonowanie gwarantuje zachowanie poprzednich wersji (chyba że osoba atakująca usunie je trwale — dlatego Object Lock uniemożliwia trwałe usunięcie danych w okresie przechowywania). Aby zapewnić maksymalną ochronę: należy włączyć wersjonowanie, włączyć MFA Delete, zastosować Object Lock w trybie Compliance dla danych krytycznych oraz replikować dane do drugiego Region z użyciem oddzielnych danych uwierzytelniających IAM, aby pojedyncze przejęcie konta nie mogło doprowadzić do zniszczenia wszystkich kopii.

Sprawdź swoją wiedzę na temat zagadnień AWS Solutions Architect (SAA-C03) z tej lekcji.

W tej lekcji dowiedziałeś się, że: wersjonowanie zachowuje wszystkie wersje każdego obiektu i chroni przed przypadkowym usunięciem, MFA Delete i Object Lock zapewniają dodatkową niezmienność danych na potrzeby zgodności z wymaganiami i ochrony przed ransomware, a CRR i SRR replikują obiekty do innych bucketów, aby spełnić wymagania dotyczące odzyskiwania po awarii i zgodności. W następnej części omówimy klasy przechowywania S3 i zasady cyklu życia służące optymalizacji kosztów.