Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Niezmienna pamięć dla Azure Blob Storage pozwala przechowywać dane krytyczne dla biznesu w stanie WORM (Write Once, Read Many). W stanie WORM nie można modyfikować ani usuwać danych dla interwału określonego przez użytkownika. Konfigurując zasady niezmienności dla danych obiektów blob, można chronić dane przed zastępowaniem i usuwaniem.
Niezmienny magazyn dla usługi Azure Blob Storage obsługuje dwa typy zasad niezmienności:
Zasady przechowywania na podstawie czasu: w przypadku zasad przechowywania na podstawie czasu użytkownicy mogą ustawiać zasady przechowywania danych dla określonego interwału. Po ustawieniu zasad przechowywania na podstawie czasu można tworzyć i odczytywać obiekty, ale nie modyfikować ani usuwać. Po wygaśnięciu okresu przechowywania można usunąć obiekty, ale nie zostaną zastąpione.
Zasady blokady prawnej: Blokada prawna przechowuje niezmienne dane do momentu jawnego cofnięcia blokady. Po ustawieniu blokady prawnej można tworzyć i odczytywać obiekty, ale nie modyfikować ani usuwać.
Możesz ustawić te zasady jednocześnie. Na przykład możesz mieć zarówno politykę zatrzymania opartą na czasie, jak i legalną blokadę ustawioną na tym samym poziomie i w tym samym czasie. Aby operacja zapisu się powiodła, musisz mieć włączone wersjonowanie albo nie mieć ani blokady prawnej, ani określonych czasowo zasad przechowywania danych. Aby usunięcie się powiodło, nie może istnieć prawna zasada przechowywania danych ani polityka przechowywania oparta na czasie.
Poniższy diagram pokazuje, jak polityki retencji oparte na czasie oraz zasady prawne uniemożliwiają operacje zapisu i usuwania podczas ich obowiązywania.
Istnieją dwie funkcje w ramach niezmiennego parasola magazynu: WORM na poziomie kontenera i WORM na poziomie wersji. WORM na poziomie kontenera pozwala ustawiać polityki tylko na poziomie kontenera, natomiast WORM na poziomie wersji pozwala ustawiać polityki na poziomie konta, kontenera lub wersji.
Informacje o niemodyfikowalnym przechowywaniu dla obiektów blob
Niezmienne przechowywanie pomaga organizacjom opieki zdrowotnej, instytucjom finansowym oraz powiązanym branżom (szczególnie brokersko-dealerskim) bezpiecznie przechowywać dane. Magazyn niezmienny może być używany w dowolnym scenariuszu w celu ochrony krytycznych danych przed modyfikacją lub usunięciem.
Typowe zastosowania tej funkcji to:
Zgodność z przepisami: Niezmienny magazyn dla usługi Azure Blob Storage pomaga organizacjom spełnić wymagania SEC 17a-4(f), CFTC 1.31(d), FINRA oraz innych przepisów.
Bezpieczne przechowywanie dokumentów: niezmienny magazyn obiektów blob gwarantuje, że dane nie mogą być modyfikowane ani usuwane przez żadnego użytkownika, nawet przez użytkowników z uprawnieniami administracyjnymi konta.
Blokada prawna: Niezmienne przechowywanie dla blobów pozwala przechowywać wrażliwe informacje kluczowe dla postępowania sądowego lub użytku biznesowego w stanie odpornym na manipulacje przez pożądany czas do czasu usunięcia blokady. Ta funkcja nie jest ograniczona tylko do przypadków użycia ze względów prawnych, ale może być również uważana za blokadę opartą na zdarzeniach lub blokadę przedsiębiorstwa, gdzie wymagana jest ochrona danych na podstawie wyzwalaczy zdarzeń lub zasad firmowych.
Zgodność z przepisami
Firma Microsoft zatrudniła wiodącą niezależną firmę oceniającą, która specjalizuje się w zarządzaniu dokumentami i nadzorze informacji, Cohasset Associates, aby ocenić niezmienny magazyn obiektów blob i jego zgodność z wymaganiami specyficznymi dla branży usług finansowych. Cohasset zweryfikował, że niezmienna pamięć masowa, gdy jest używana do przechowywania obiektów blob w stanie WORM, spełnia odpowiednie wymagania dotyczące przechowywania zgodnie z regułą CFTC 1.31(c)-(d), regułą FINRA 4511 oraz regułą SEC 17a-4(f). Microsoft skierował zestaw tych reguł, ponieważ stanowią one najbardziej szczegółowe wytyczne na świecie dotyczące przechowywania danych dla instytucji finansowych na całym świecie.
Raport Cohasset jest dostępny w Centrum zaufania usług firmy Microsoft. Centrum zaufania Azure zawiera szczegółowe informacje o certyfikatach zgodności firmy Microsoft. Aby zażądać listu zaświadczania od firmy Microsoft w sprawie zgodności niezmienności WORM, skontaktuj się z pomocą techniczną platformy Azure.
Zasady przechowywania na podstawie czasu
Zasady przechowywania na podstawie czasu przechowują dane obiektów blob w formacie WORM dla określonego interwału. Gdy ustawiasz politykę retencji opartą na czasie, klienci mogą tworzyć i odczytywać bloby, ale nie mogą ich modyfikować ani usuwać. Po upływie interwału retencyjnego plamy mogą być usuwane, ale nie nadpisane.
Scope
Możesz skonfigurować politykę retencji opartą na czasie w następujących zakresach:
- Polityka WORM na poziomie wersji: Konfiguruj politykę retencji na poziomie konta, kontenera lub wersji (wersjonowanie musi być włączone na koncie). Jeśli skonfigurujesz ją na poziomie konta lub kontenera, wszystkie bloby w danym kontu lub kontenerze dziedziczą politykę. Jeśli na kontenerze istnieje blokada prawna, nie można utworzyć mechanizmu WORM na poziomie wersji dla tego samego kontenera. To ograniczenie istnieje, ponieważ prawo nie pozwala generować tych wersji.
- Zasady WORM na poziomie kontenera: zasady przechowywania oparte na czasie skonfigurowane na poziomie kontenera dotyczą wszystkich obiektów blob w tym kontenerze. Nie możesz skonfigurować pojedynczych blobów z ich własnymi politykami niezmienności.
Interwał przechowywania zasad opartych na czasie
Minimalny interwał przechowywania dla zasad przechowywania na podstawie czasu wynosi jeden dzień, a maksymalna wartość to 146 000 dni (400 lat). Podczas konfigurowania zasad przechowywania na podstawie czasu obiekty, których dotyczy problem, pozostają w stanie niezmiennym w okresie efektywnego przechowywania. Obowiązujący okres przechowywania obiektów jest równy różnicy między czasem tworzenia obiektu blob a interwałem przechowywania określonym przez użytkownika. Ponieważ okres przechowywania w ramach polityki może być wydłużony, niezmienne magazynowanie używa najnowszej wartości okresu przechowywania określonego przez użytkownika, aby obliczyć efektywny okres przetrzymywania.
Załóżmy na przykład, że użytkownik tworzy zasady przechowywania na podstawie czasu z interwałem przechowywania wynoszącym pięć lat. Istniejący obiekt blob w tym kontenerze, testblob1, został utworzony rok temu, więc jego efektywny okres przechowywania wynosi cztery lata. Gdy nowy obiekt blob, testblob2, zostanie przekazany do kontenera, obowiązujący okres przechowywania dla obiektu testblob2 wynosi pięć lat od momentu jego utworzenia.
Polityki zablokowane i odblokowane
Podczas pierwszego konfigurowania polityki zasad przechowywania na podstawie czasu, polityka jest odblokowywana do celów testowych. Po zakończeniu testowania można zablokować politykę, tak aby była w pełni zgodna z SEC 17a-4(f) i innymi przepisami regulacyjnymi.
Zarówno zablokowane, jak i odblokowane zasady chronią przed usunięciem i zastąpieniem. Można jednak zmodyfikować odblokowane zasady, skracając lub przedłużając okres przechowywania. Możesz również usunąć odblokowaną politykę. Nie można usunąć zablokowanych zasad przechowywania na podstawie czasu. Okres przechowywania można przedłużyć, ale nie można go zmniejszyć. Dozwolone jest maksymalnie pięć zwiększeń efektywnego okresu przechowywania w czasie trwania zablokowanej polityki zdefiniowanej na poziomie kontenera. W przypadku zasad skonfigurowanych dla wersji obiektu blob nie ma limitu liczby wydłużeń okresu obowiązywania.
Ważne
Zasady retencji oparte na czasie muszą być zablokowane, aby obiekt blob był w stanie niezmiennym (chronionym przed zapisem i usunięciem) dla SEC 17a-4(f) i innych przepisów dotyczących zgodności. Firma Microsoft zaleca blokowanie polityki w rozsądnym czasie, zazwyczaj krótszym niż 24 godziny. Chociaż stan odblokowany zapewnia ochronę przed niezmiennością, nie zalecamy używania go do niczego poza krótkoterminowymi testami.
Rejestrowanie audytów zasad retencji
Każdy kontener z włączoną czasową polityką przechowywania zapewnia dziennik inspekcji polityki. Dziennik inspekcji zawiera maksymalnie siedem poleceń zatrzymywania opartych na czasie dla ustalonych zasad przechowywania na określony czas. Rejestrowanie zazwyczaj rozpoczyna się po zablokowaniu polityki. Wpisy dziennika obejmują identyfikator użytkownika, typ polecenia, sygnatury czasowe i interwał przechowywania. Dziennik inspekcji jest zachowywany dla okresu istnienia zasad zgodnie z wytycznymi prawnymi SEC 17a-4(f).
Dziennik aktywności platformy Azure zawiera bardziej kompleksowy dziennik wszystkich działań usługi zarządzania. Dzienniki zasobów platformy Azure zachowują informacje o operacjach danych. Jesteś odpowiedzialny za trwałe przechowywanie tych logów, co może być wymagane w celach regulacyjnych lub innych.
Zmiany zasad przechowywania na podstawie czasu na poziomie wersji nie są poddawane inspekcji.
Blokady prawne
Tymczasowy nakaz prawny to polityka tymczasowej niezmienności, którą można zastosować do celów dochodzenia prawnego lub ogólnych polityk ochronnych. Blokada prawna przechowuje dane obiektu blob w formacie Write Once, Read Many (WORM), dopóki blokada nie zostanie jawnie zdjęta. Gdy blokada prawna jest w mocy, można tworzyć i odczytywać obiekty blob, ale nie modyfikować ani usuwać. Użyj blokady prawnej, gdy okres, przez który dane muszą być przechowywane w stanie WORM, jest nieznany.
Scope
Zasady blokady prawnej można skonfigurować w jednym z następujących zakresów:
Zasady WORM na poziomie wersji: Dla poszczególnych wersji obiektu blob można skonfigurować blokadę prawną w celu precyzyjnego zarządzania danymi wrażliwymi (na koncie musi być włączone wersjonowanie).
Polityka WORM na poziomie kontenera: Blokada prawna skonfigurowana na poziomie kontenera dotyczy wszystkich obiektów blob w tym kontenerze. Nie można skonfigurować poszczególnych obiektów blob przy użyciu własnych zasad niezmienności.
Tagi
Musisz powiązać blokadę prawną na poziomie kontenera z co najmniej jednym alfanumerycznym znacznikiem zdefiniowanym przez użytkownika, który pełni funkcję ciągu identyfikacyjnego. Na przykład tag może zawierać identyfikator sprawy lub nazwę zdarzenia.
Rejestrowanie inspekcji
Każdy kontener z zabezpieczeniem prawnym zapewnia rejestr audytu zasad. Dziennik zawiera identyfikator użytkownika, typ polecenia, sygnatury czasowe i tagi archiwizacji ze względów prawnych. Dziennik inspekcji jest zachowywany dla okresu istnienia zasad zgodnie z wytycznymi prawnymi SEC 17a-4(f).
Dziennik aktywności platformy Azure zawiera bardziej kompleksowy dziennik wszystkich działań usługi zarządzania. Dzienniki zasobów platformy Azure zachowują informacje o operacjach danych. Jesteś odpowiedzialny za trwałe przechowywanie tych logów, co może być wymagane w celach regulacyjnych lub innych.
Zmiany w zabezpieczeniach prawnych na poziomie wersji nie są audytowane.
Opcje funkcjonalności niezmiennego przechowywania
W poniższej tabeli przedstawiono podział różnic między WORM na poziomie kontenera i WORM na poziomie wersji:
| Kategoria | WORM na poziomie kontenera | WORM na poziomie wersji |
|---|---|---|
| Poziom szczegółowości zasad | Konfiguruj polityki tylko na poziomie kontenera. Każdy obiekt, który przesyłasz do kontenera, dziedziczy niezmienny zestaw polityk. | Konfiguruj polityki na poziomie konta, kontenera lub bloba. Jeśli ustawisz politykę na poziomie konta, wszystkie bloby, które wgrasz na to konto, dziedziczą tę politykę. Ta sama logika jest zgodna z kontenerami. Jeśli ustawisz politykę na wielu poziomach, kolejność precedencji to zawsze Blob -> Kontener -> Konto. |
| Dostępne typy zasad | Ustaw dwa różne typy polityk na poziomie kontenera: polityki przechowywania oparte na czasie oraz blokady prawne. | Na poziomie konta i kontenera ustaw tylko czasowe zasady retencji. Na poziomie blobów ustal zarówno politykę zatrzymania opartą na czasie, jak i legalne blokady. |
| Zależności funkcji | Żadne inne funkcje nie są wymaganiem wstępnym ani wymaganiem, aby ta funkcja działała. | Przechowywanie wersji jest wymaganiem wstępnym do użycia tej funkcji. |
| Obsługa istniejących kont i kontenerów | Włącz tę funkcję w dowolnym momencie dla istniejących kontenerów. | W zależności od poziomu szczegółowości, ta funkcja może nie być włączona dla wszystkich istniejących kont i kontenerów. |
| Usuwanie konta/kontenera | Po zablokowaniu polityki zatrzymania czasu na kontenerze, możesz usuwać kontenery tylko wtedy, gdy są puste. | Po włączeniu wersji WORM na poziomie konta lub kontenera możesz je usunąć tylko wtedy, gdy są puste. |
| Obsługa usługi Azure Data Lake Storage (konta magazynu z włączoną hierarchiczną przestrzenią nazw) | Wspieraj polityki WORM na poziomie kontenera w kontach posiadających hierarchiczną przestrzeń nazw. | Zasady WORM na poziomie wersji nie są jeszcze obsługiwane na kontach z hierarchiczną przestrzenią nazw. |
Aby dowiedzieć się więcej o WORM na poziomie kontenera, zobacz polityki WORM na poziomie kontenera. Aby dowiedzieć się więcej o WORM na poziomie wersji, zobacz polityki WORM na poziomie wersji.
WORM na poziomie kontenera a WORM na poziomie wersji
Poniższa tabela ułatwia podjęcie decyzji o typie zasad WORM do użycia.
| Kryterium | Użycie WORM na poziomie kontenera | Użycie WORM na poziomie wersji |
|---|---|---|
| Organizacja danych | Chcesz ustawić polityki dla konkretnych zbiorów danych, które możesz kategoryzować według kontenerów. Wszystkie dane w tym kontenerze muszą być przechowywane w stanie WORM przez ten sam czas. | Nie można grupować obiektów według okresów przechowywania. Wszystkie bloby muszą być przechowywane z indywidualnie określonym okresem retencji, zależnym od scenariuszy dotyczących danego bloba, lub występuje mieszane obciążenie, w którym niektóre grupy danych można grupować w kontenerach, podczas gdy innych blobów nie można w ten sposób grupować. Możesz również ustawić zasady na poziomie kontenera i zasady na poziomie obiektów blob w ramach tego samego konta. |
| Ilość danych, które wymagają niezmiennych zasad | Nie musisz ustawiać zasad dla ponad 10 000 kontenerów na konto. | Chcesz ustawić polityki dotyczące wszystkich danych lub dużych ilości danych, które możesz określić według kont. Wiesz, że jeśli używasz WORM na poziomie kontenera, musisz przekroczyć limit 10 000 kontenerów. |
| Zainteresowanie włączaniem przechowywania wersji | Nie chcesz zajmować się aktywowaniem wersjonowania z powodu kosztów lub dlatego, że proces roboczy utworzy wiele dodatkowych wersji do obsłużenia. | Chcesz użyć przechowywania wersji lub nie masz nic przeciwko jego użyciu. Wiesz, że jeśli nie włączysz wersjonowania, nie możesz zachować edycji lub nadpisów niezmiennych blobów jako oddzielnych wersji. |
| Lokalizacja magazynu (Blob Storage a Data Lake Storage) | Twoje obciążenie jest całkowicie skoncentrowane na usłudze Azure Data Lake Storage. Nie masz bezpośredniego zainteresowania ani nie planujesz przełączyć się na korzystanie z konta, które nie ma włączonej funkcji hierarchicznej przestrzeni nazw. | Twoje obciążenie znajduje się w usłudze Blob Storage na koncie, które nie ma włączonej funkcji hierarchicznej przestrzeni nazw i może teraz używać funkcji WORM na poziomie wersji lub chcesz poczekać na udostępnienie wersji dla kont z włączoną hierarchiczną przestrzenią nazw (Azure Data Lake Storage). |
Poziomy dostępu
Wszystkie warstwy dostępu do obiektów blob obsługują niezmienialną pamięć masową. Możesz zmienić tier dostępu do bloba za pomocą operacji Set Blob Tier . Aby uzyskać więcej informacji, zobacz Warstwy dostępu dla danych blob.
Konfiguracje nadmiarowości
Wszystkie konfiguracje nadmiarowości obsługują niezmienny magazyn. Aby uzyskać więcej informacji na temat konfiguracji nadmiarowości, zobacz Nadmiarowość usługi Azure Storage.
Zalecane typy obiektów blob
Microsoft zaleca konfigurowanie zasad niezmienności głównie dla blokowych blobów i dołączalnych blobów. Nie zaleca się konfigurowania zasad niezmienności dla obiektu blob typu stronicowego przechowującego dysk VHD aktywnej maszyny wirtualnej, ponieważ zapisy na dysku są blokowane, a jeśli włączone jest wersjonowanie, każdy zapis jest zapisywany jako nowa wersja. Firma Microsoft zaleca dokładne przejrzenie dokumentacji i przetestowanie scenariuszy przed zablokowaniem zasad opartych na czasie.
Niezmienny magazyn danych z funkcją łagodnego usuwania obiektów blob
Gdy konfigurujesz miękkie usuwanie blobow dla konta magazynowego, dotyczy to wszystkich blobow w obrębie konta, niezależnie od tego, czy obowiązuje legalna zasada rezerwacji czy retencji na podstawie czasu. Microsoft zaleca włączenie miękkiego usuwania, aby zapewnić dodatkową ochronę przed zastosowaniem jakichkolwiek zasad niezmienności.
Jeśli włączysz nietrwałe usuwanie obiektów blob, a następnie skonfigurujesz zasadę niezmienności, wszystkie obiekty blob, które zostały już nietrwale usunięte, zostaną trwale usunięte po upływie okresu przechowywania określonego przez zasady nietrwałego usuwania. Możesz przywrócić miękkie usunięte bloby podczas okresu przechowywania miękkiego usuwania. Blob lub wersja, której jeszcze nie usunąłeś miękko, jest chroniona przez politykę niezmienności i nie może zostać miękko usunięta, dopóki nie wygaśnie polityka zatrzymania opartego na czasie lub nie zostanie usunięta prawna blokada.
Śledzenie zasad niezmienności za pomocą spisu obiektów blob
Przegląd obiektów blob usługi Azure Storage zapewnia wgląd w kontenery w twoich kontach magazynu oraz w obiekty blob, migawki i wersje obiektów blob. Raport spisu obiektów blob umożliwia zrozumienie atrybutów obiektów blob i kontenerów, w tym tego, czy zasób ma skonfigurowane zasady niezmienności.
Po włączeniu spisu obiektów blob usługa Azure Storage generuje codziennie raport spisu. Raport zawiera omówienie danych dotyczących wymagań biznesowych i zgodności.
Aby uzyskać więcej informacji na temat spisu obiektów blob, zobacz Spis obiektów blob usługi Azure Storage.
Uwaga
Nie możesz skonfigurować polityki inwentarza na koncie, jeśli na tym koncie jest włączona obsługa niezmienności na poziomie wersji lub jeśli w docelowym kontenerze zdefiniowanym w polityce inwentarza jest włączona niezmienność na poziomie wersji.
Konfigurowanie zasad na dużą skalę
Możesz użyć zadania przechowywania danych do konfigurowania polityk niezmienności na dużą skalę na wielu kontach pamięci masowej, w oparciu o zestaw warunków, które zdefiniujesz. Zadanie przechowywania to zasób dostępny w usłudze Azure Storage Actions; platforma bezserwerowa umożliwiająca wykonywanie typowych operacji na danych na milionach obiektów w wielu kontach magazynowych. Aby dowiedzieć się więcej, zobacz Co to jest usługa Azure Storage Actions?
Cennik
Za korzystanie z magazynu niezmiennego nie są naliczane dodatkowe opłaty za pojemność. Niezmienne dane są wyceniane w taki sam sposób, jak dane modyfikowalne. Jeśli używasz WORM na poziomie wersji, opłata może być wyższa, ponieważ włączyłeś wersjonowanie, a przechowywanie dodatkowych wersji wiąże się z dodatkowymi kosztami. Aby uzyskać więcej informacji, zapoznaj się z zasadami cen przechowywania wersji. Aby uzyskać szczegółowe informacje o cenach usługi Azure Blob Storage, zobacz stronę cennika usługi Azure Storage.
Tworzenie lub usuwanie polityki przechowywania na podstawie czasu lub blokady prawnej dla wersji obiektu blob powoduje naliczanie opłaty za transakcję zapisu. Zmiana polityki retencji opartej na czasie (jej zablokowanie lub przedłużenie) powoduje naliczenie opłaty za inne operacje. Więcej informacji o opłatach transakcyjnych można znaleźć w sekcji Operacje i Transfer Danych.
Jeśli nie zapłacisz rachunku, a Twoje konto ma aktywne zasady przechowywania na podstawie czasu, obowiązują normalne zasady przechowywania danych zgodnie z postanowieniami umowy z firmą Microsoft. Aby uzyskać ogólne informacje, zobacz Zarządzanie danymi w firmie Microsoft.
Obsługa funkcji
Ważne
Ta funkcja jest niekompatybilna z przywracaniem danych do punktu w czasie i śledzeniem ostatniego dostępu.
Ta funkcja jest kompatybilna z nieplanowanym przełączaniem awaryjnym zarządzanym przez klienta. Jednak wszelkie zmiany wprowadzone w polityce niezmiennej po ostatnim czasie synchronizacji (takie jak zablokowanie polityki retencji opartej na czasie lub jej przedłużenie) nie synchronizują się z regionem drugorzędnym. Po zakończeniu przełączenia awaryjnego możesz ponownie zastosować zmiany w regionie pomocniczym, aby upewnić się, że jest on aktualny pod względem wymagań dotyczących niezmienności. Zasady niezmienności nie są obsługiwane na kontach z włączonym protokołem sieciowego systemu plików (NFS) 3.0 ani protokołem SSH File Transfer Protocol (SFTP).
Niektóre obciążenia, takie jak kopia zapasowa SQL do URL, tworzą obiekt blob, a następnie dodają do niego dane. Jeśli dla kontenera są aktywne zasady przechowywania oparte na czasie lub nałożono na niego blokadę prawną, to działanie nie powiedzie się. Aby uzyskać więcej informacji, zobacz Zezwalaj na zapisywanie chronionych uzupełnialnych obiektów blob.
Aby uzyskać więcej informacji, zobacz Obsługa funkcji usługi Blob Storage na kontach usługi Azure Storage.