Uwaga
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.
Funkcja magazynu niezmienialnego w usłudze Azure Blob Storage umożliwia użytkownikom przechowywanie danych krytycznych dla działania firmy w stanie WORM („Write Once Read Many” — jednorazowy zapis i wielokrotny odczyt). 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ć.
Te zasady można ustawić jednocześnie. Na przykład użytkownik może mieć zarówno politykę przechowywania opartą na czasie, jak i blokadę prawną ustawioną na tym samym poziomie i w tym samym czasie. Aby zapis zakończył się pomyślnie, musisz mieć włączoną obsługę wersji lub nie mieć żadnej blokady prawnej ani polityki przechowywania opartej na czasie na danych. Aby usunięcie zakończyło się powodzeniem, nie może istnieć również blokada prawna ani polityka przechowywania danych określona czasowo.
Na poniższym diagramie pokazano, jak zasady przechowywania oparte na czasie i zasady prawne uniemożliwiają operacje zapisu i usuwania, gdy są one w mocy.
Istnieją dwie funkcje w ramach niezmiennego parasola magazynu: WORM na poziomie kontenera i WORM na poziomie wersji. Funkcja WORM na poziomie kontenera umożliwia ustawianie zasad tylko na poziomie kontenera, natomiast funkcja WORM na poziomie wersji umożliwia ustawianie zasad na poziomie konta, kontenera lub wersji.
Informacje o niemodyfikowalnym przechowywaniu dla obiektów blob
Niezmienna pamięć masowa pomaga bezpiecznie przechowywać dane organizacjom opieki zdrowotnej, instytucjom finansowym i powiązanym branżom — szczególnie organizacjom brokersko-dealerskim. 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.
Archiwizacja ze względów prawnych: Niezmienny magazyn dla obiektów blob umożliwia użytkownikom przechowywanie poufnych informacji, które mają kluczowe znaczenie dla postępowania sądowego lub użytku biznesowego w stanie zabezpieczonym przed modyfikacją przez żądany czas trwania do czasu usunięcia blokady prawnej. 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 poprosić o pismo zaświadczania od firmy Microsoft dotyczące 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. Po ustawieniu zasad przechowywania na podstawie czasu klienci mogą tworzyć i odczytywać obiekty blob, ale nie mogą ich modyfikować ani usuwać. Po wygaśnięciu interwału przechowywania można usunąć obiekty blob, ale nie można ich nadpisać.
Zakres
Zasady przechowywania na podstawie czasu można skonfigurować w następujących zakresach:
- Zasady WORM na poziomie wersji: zasady przechowywania na podstawie czasu można skonfigurować na poziomie konta, kontenera lub wersji. Jeśli jest skonfigurowany na poziomie konta lub kontenera, zostanie odziedziczony przez wszystkie bloby w odpowiednim koncie lub kontenerze. Jeśli na kontener nałożona jest blokada prawna, nie można utworzyć WORM na poziomie wersji dla tego samego kontenera. Dzieje się tak, ponieważ nie można generować wersji z powodu blokady prawnej.
- Zasady WORM na poziomie kontenera: zasady przechowywania oparte na czasie skonfigurowane na poziomie kontenera dotyczą wszystkich obiektów blob w tym kontenerze. Nie można skonfigurować poszczególnych obiektów blob przy użyciu własnych zasad 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. Mimo że stan odblokowany zapewnia ochronę niezmienności, używanie stanu odblokowanego do dowolnego celu innego niż testowanie krótkoterminowe nie jest zalecane.
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. Użytkownik ponosi odpowiedzialność za trwałe przechowywanie tych dzienników, co może być wymagane do celów 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 obiektów blob w formacie Write-Once, Read-Many (WORM - zapisz raz, czytaj wielokrotnie), dopóki blokada nie zostanie jawnie wyczyszczona." 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.
Zakres
Zasady blokady prawnej można skonfigurować w jednym z następujących zakresów:
Polityka WORM na poziomie wersji: można skonfigurować blokadę prawną na poziomie poszczególnych wersji obiektów blob w celu precyzyjnego zarządzania poufnymi danymi.
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
Blokada prawna na poziomie kontenera musi być skojarzona z co najmniej jednym tagiem alfanumerycznym zdefiniowanym przez użytkownika, które służą jako ciągi identyfikatorów. Na przykład tag może zawierać identyfikator przypadku 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. Użytkownik ponosi odpowiedzialność za trwałe przechowywanie tych dzienników, co może być wymagane do celów 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 | Zasady można skonfigurować tylko na poziomie kontenera. Każdy obiekt przekazany do kontenera dziedziczy niezmienny zestaw zasad. | Zasady można skonfigurować na poziomie konta, kontenera lub blob. Jeśli polityka jest ustawiona na poziomie konta, wszystkie bloby przesyłane do tego konta dziedziczą politykę. Ta sama logika jest zgodna z kontenerami. Jeśli polityka jest ustawiona na kilku poziomach, kolejność pierwszeństwa to zawsze Blob —> kontener —> konto. |
| Dostępne typy zasad | Na poziomie kontenera można ustawić dwa różne typy zasad: zasady przechowywania na podstawie czasu i blokady prawne. | Na poziomie konta i kontenera można ustawić tylko zasady przechowywania na podstawie czasu. Na poziomie obiektu blob można ustawić zarówno czasowe zasady przechowywania, jak i blokady prawne. |
| 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. |
| Umożliwienie dla istniejących kont/kontenerów | Tę funkcję można włączyć 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/kontenerów. |
| Usuwanie konta/kontenera | Gdy zasady przechowywania na podstawie czasu zostaną zablokowane w kontenerze, kontenery mogą zostać usunięte tylko wtedy, gdy są puste. | Po włączeniu funkcji WORM na poziomie wersji dla konta lub kontenera, można je usunąć tylko wtedy, gdy są puste. |
| Obsługa usługi Azure Data Lake Storage (konta magazynu z włączoną hierarchiczną przestrzenią nazw) | Zasady WORM na poziomie kontenera są obsługiwane na kontach, które mają hierarchiczną strukturę przestrzeni nazw. | Zasady WORM na poziomie wersji nie są jeszcze obsługiwane na kontach, które mają hierarchiczną przestrzeń nazw. |
Aby dowiedzieć się więcej o WORM na poziomie kontenera, zobacz Container-Level zasady WORM. Aby dowiedzieć się więcej na temat WORM na poziomie wersji, odwiedź stronę zasady WORM na poziomie wersji.
Kontener-level vs version-level WORM
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ć zasady dla określonych zestawów danych, które można podzielić na kategorie według kontenera. 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 obiekty blob muszą być przechowywane z indywidualnym czasem przechowywania na podstawie scenariuszy tego obiektu blob lub użytkownik ma mieszane obciążenie, aby niektóre grupy danych mogły być klastrowane w kontenery, podczas gdy inne obiekty blob nie mogą. 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ć zasady dotyczące wszystkich danych lub dużych ilości danych, które mogą być podzielone według konta. 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łączą wersjonowania, nie możesz zachować zmian ani nadpisać niezmiennych obiektów blob w postaci 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ć warstwę dostępu obiektu blob za pomocą operacji Ustawiania warstwy obiektu blob. 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. Skonfigurowanie zasad niezmienności dla obiektu blob typu stronicowego, który przechowuje dysk VHD dla aktywnej maszyny wirtualnej, jest odradzane, ponieważ zapisy na dysku będą zablokowane lub, jeśli włączono wersjonowanie, każdy zapis zostanie przechowany 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
Kiedy dla konta magazynu skonfigurowane jest miękkie usuwanie obiektu blob, ma ono zastosowanie do wszystkich obiektów blob w obrębie konta, niezależnie od tego, czy obowiązuje blokowanie prawne, czy zasady przechowywania oparte na czasie. Microsoft zaleca włączenie miękkiego usuwania, aby zapewnić dodatkową ochronę przed zastosowaniem jakichkolwiek zasad niezmienności.
Jeśli włączysz miękkie usuwanie obiektu blob, a następnie skonfigurujesz zasady niezmienności, wszystkie obiekty blob, które zostały już usunięte miękko, zostaną trwale usunięte po wygaśnięciu zasad przechowywania miękkiego usuwania. Obiekty blob usunięte nietrwale można przywrócić w okresie przechowywania usuwania nietrwałego. Obiekt blob lub wersja, która nie została jeszcze usunięta nietrwało, jest chroniona przez zasady niezmienności i nie może zostać usunięta nietrwale, dopóki zasady przechowywania na podstawie czasu nie wygasły lub archiwizacja prawna zostanie usunięta.
Ś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żna skonfigurować zasad spisu na koncie, jeśli obsługa niezmienności na poziomie wersji jest włączona na tym koncie lub jeśli obsługa niezmienności na poziomie wersji jest włączona w kontenerze docelowym zdefiniowanym w zasadach spisu.
Konfigurowanie zasad na dużą skalę
Za pomocą zadania magazynu można skonfigurować zasady niezmienności na dużą skalę na wielu kontach magazynu na podstawie zestawu zdefiniowanych warunków. 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, rachunek może być wyższy, ponieważ włączono przechowywanie wersji i istnieje koszt związany z przechowywaniem dodatkowych wersji. 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, modyfikowanie lub usuwanie polityki retencji opartej na czasie lub zastosowanie blokady prawnej na wersji obiektu blob skutkuje naliczaniem opłaty za transakcję zapisu.
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 zgodna z nieplanowanym trybem failover zarządzanym przez klienta, jednak wszelkie zmiany wprowadzone w zasadach niezmiennych po ostatniej synchronizacji (takie jak blokowanie zasad przechowywania na podstawie czasu, rozszerzanie go itp.) nie zostaną zsynchronizowane z regionem pomocniczym. Po zakończeniu pracy w trybie *failover*, można ponownie zastosować zmiany w regionie pomocniczym, aby upewnić się, że jest on zgodny z wymaganiami dotyczącymi 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 kontener ma aktywne zasady przechowywania na podstawie czasu lub blokadę prawną, ta procedura 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.