Lagra affärskritiska blobdata med oföränderlig lagring i ett skrivläge en gång, läs många (WORM) tillstånd
Med oföränderlig lagring i Azure Blob Storage kan användare lagra affärskritiska data i ett WORM-tillstånd (Write Once Read Many). I ett WORM-tillstånd kan data inte ändras eller tas bort för ett användardefinierat intervall. Genom att konfigurera oföränderlighetsprinciper för blobdata kan du skydda dina data från överskrivningar och borttagningar.
Oföränderlig lagring för Azure Blob Storage stöder två typer av oföränderlighetsprinciper:
Tidsbaserade kvarhållningsprinciper: Med en tidsbaserad kvarhållningsprincip kan användarna ange principer för att lagra data under ett angivet intervall. När en tidsbaserad kvarhållningsprincip har angetts kan objekt skapas och läsas, men inte ändras eller tas bort. När kvarhållningsperioden har upphört att gälla kan objekt tas bort men inte skrivas över.
Principer för bevarande av juridiska skäl: Ett bevarande av juridiska skäl lagrar oföränderliga data tills det juridiska undantaget uttryckligen har rensats. När ett bevarande av juridiska skäl har angetts kan objekt skapas och läsas, men inte ändras eller tas bort.
Dessa principer kan anges samtidigt som varandra. En användare kan till exempel ha både en tidsbaserad kvarhållningsprincip och ett bevarande av juridiska skäl på samma nivå och samtidigt. För att en skrivning ska lyckas måste du antingen ha versionshantering aktiverat eller ha varken ett lagligt undantag eller en tidsbaserad kvarhållningsprincip för data. För att en borttagning ska lyckas får det inte finnas någon princip för kvarhållning av juridiska skäl eller en tidsbaserad kvarhållningsprincip för data.
Följande diagram visar hur tidsbaserade kvarhållningsprinciper och juridiska undantag förhindrar skriv- och borttagningsåtgärder när de tillämpas.
Det finns två funktioner under det oföränderliga lagringsparaplyet: WORM på containernivå och WORM på versionsnivå. Worm på containernivå tillåter endast att principer anges på containernivå, medan WORM på versionsnivå tillåter att principer anges på konto-, container- eller versionsnivå.
Om oföränderlig lagring för blobar
Oföränderlig lagring hjälper sjukvårdsorganisationer, finansiella institutioner och relaterade branscher – särskilt mäklarorganisationer – att lagra data på ett säkert sätt. Oföränderlig lagring kan användas i alla scenarier för att skydda kritiska data mot ändring eller borttagning.
Vanliga program innehåller:
Regelefterlevnad: Oföränderlig lagring för Azure Blob Storage hjälper organisationer att hantera SEC 17a-4(f), CFTC 1.31(d), FINRA och andra föreskrifter.
Säker dokumentkvarhållning: Oföränderlig lagring för blobar säkerställer att data inte kan ändras eller tas bort av någon användare, inte ens av användare med administratörsbehörighet för konton.
Bevarande av juridiska skäl: Oföränderlig lagring för blobar gör det möjligt för användare att lagra känslig information som är viktig för rättstvister eller affärsanvändning i ett manipuleringssäkert tillstånd under önskad tid tills undantaget tas bort. Den här funktionen är inte bara begränsad till juridiska användningsfall, utan kan även betraktas som ett händelsebaserat undantag eller ett företagslås, där behovet av att skydda data baserat på händelseutlösare eller företagsprincip krävs.
Regelefterlevnad
Microsoft behöll ett ledande oberoende utvärderingsföretag som specialiserat sig på hantering av arkivhandlingar och informationsstyrning, Cohasset Associates, för att utvärdera oföränderlig lagring för blobbar och dess efterlevnad av krav som är specifika för branschen för finansiella tjänster. Cohasset verifierade att oföränderlig lagring, när den används för att behålla blobar i ett WORM-tillstånd, uppfyller relevanta lagringskrav för CFTC-regel 1.31(c)-(d), FINRA-regel 4511 och SEC-regel 17a-4(f). Microsoft riktade in sig på den här uppsättningen regler eftersom de representerar den mest normativa vägledningen globalt för kvarhållning av arkivhandlingar för finansinstitut.
Cohasset-rapporten är tillgänglig i Microsoft Service Trust Center. Azure Trust Center innehåller detaljerad information om Microsofts efterlevnadscertifieringar. Kontakta Azure-supporten om du vill begära ett intyg från Microsoft om kompatibilitet med WORM-oföränderlighet.
Tidsbaserade kvarhållningsprinciper
En tidsbaserad kvarhållningsprincip lagrar blobdata i WORM-format för ett angivet intervall. När en tidsbaserad kvarhållningsprincip har angetts kan klienter skapa och läsa blobar, men de kan inte ändra eller ta bort dem. När kvarhållningsintervallet har upphört att gälla kan blobar tas bort men inte skrivas över.
Omfattning
En tidsbaserad kvarhållningsprincip kan konfigureras med följande omfång:
- Worm-princip på versionsnivå: En tidsbaserad kvarhållningsprincip kan konfigureras på konto-, container- eller versionsnivå. Om den konfigureras på konto- eller containernivå ärvs den av alla blobar i respektive konto eller container. Om det finns ett lagligt undantag för en container kan inte WORM på versionsnivå skapas för samma container. Det beror på att versionerna inte kan genereras på grund av det juridiska undantaget.
- WORM-princip på containernivå: En tidsbaserad kvarhållningsprincip som konfigurerats på containernivå gäller för alla blobar i containern. Enskilda blobar kan inte konfigureras med sina egna oföränderlighetsprinciper.
Kvarhållningsintervall för en tidsbaserad princip
Det minsta kvarhållningsintervallet för en tidsbaserad kvarhållningsprincip är en dag och det maximala är 146 000 dagar (400 år). När du konfigurerar en tidsbaserad kvarhållningsprincip förblir de berörda objekten i oföränderligt tillstånd under den effektiva kvarhållningsperioden. Den effektiva kvarhållningsperioden för objekt är lika med skillnaden mellan blobens skapandetid och det användardefinierade kvarhållningsintervallet. Eftersom en princips kvarhållningsintervall kan utökas använder oföränderlig lagring det senaste värdet för det användardefinierade kvarhållningsintervallet för att beräkna den effektiva kvarhållningsperioden.
Anta till exempel att en användare skapar en tidsbaserad kvarhållningsprincip med ett kvarhållningsintervall på fem år. En befintlig blob i containern, testblob1, skapades för ett år sedan, så den effektiva kvarhållningsperioden för testblob1 är fyra år. När en ny blob, testblob2, laddas upp till containern är den effektiva kvarhållningsperioden för testblob2 fem år från det att den skapades.
Låsta eller olåst principer
När du först konfigurerar en tidsbaserad kvarhållningsprincip låss principen upp i testsyfte. När du är klar med testningen kan du låsa principen så att den är helt kompatibel med SEC 17a-4(f) och annan regelefterlevnad.
Både låsta och olåst principer skyddar mot borttagningar och överskrivningar. Du kan dock ändra en olåst princip genom att förkorta eller förlänga kvarhållningsperioden. Du kan också ta bort en olåst princip. Du kan inte ta bort en låst tidsbaserad kvarhållningsprincip. Du kan förlänga kvarhållningsperioden, men du kan inte minska den. Högst fem ökningar av den effektiva kvarhållningsperioden tillåts under livslängden för en låst princip som definieras på containernivå. För en princip som konfigurerats för en blobversion finns det ingen gräns för antalet ökningar till den effektiva perioden.
Viktigt!
En tidsbaserad kvarhållningsprincip måste låsas för att blobben ska vara i ett kompatibelt oföränderligt tillstånd (skriv- och borttagningsskyddat) för SEC 17a-4(f) och annan regelefterlevnad. Microsoft rekommenderar att du låser principen inom rimlig tid, vanligtvis mindre än 24 timmar. Även om det olåsta tillståndet ger oföränderligt skydd rekommenderar vi inte att du använder det olåsta tillståndet för något annat syfte än kortsiktig testning.
Granskningsloggning för kvarhållningsprincip
Varje container med en tidsbaserad kvarhållningsprincip aktiverad tillhandahåller en principgranskningslogg. Granskningsloggen innehåller upp till sju tidsbaserade kvarhållningskommandon för låsta tidsbaserade kvarhållningsprinciper. Loggningen startar vanligtvis när du har låst principen. Loggposter inkluderar användar-ID, kommandotyp, tidsstämplar och kvarhållningsintervall. Granskningsloggen behålls för principens livslängd i enlighet med sec 17a-4(f) regelriktlinjer.
Azure-aktivitetsloggen innehåller en mer omfattande logg över alla hanteringstjänstaktiviteter. Azure-resursloggar behåller information om dataåtgärder. Det är användarens ansvar att lagra loggarna beständigt, vilket kan krävas för regelmässiga eller andra ändamål.
Ändringar i tidsbaserade kvarhållningsprinciper på versionsnivå granskas inte.
Kvarhållning av juridiska skäl
Ett bevarande av juridiska skäl är en tillfällig oföränderlighetsprincip som kan tillämpas för juridiska undersökningsändamål eller allmänna skyddsprinciper. Ett bevarande av juridiska skäl lagrar blobdata i formatet Write-Once, Read-Many (WORM) tills undantaget uttryckligen har rensats. När ett juridiskt undantag gäller kan blobar skapas och läsas, men inte ändras eller tas bort. Använd ett bevarande av juridiska skäl när den tidsperiod då data måste hållas i ett WORM-tillstånd är okänt.
Omfattning
En princip för bevarande av juridiska skäl kan konfigureras i något av följande omfång:
Worm-princip på versionsnivå: Ett juridiskt undantag kan konfigureras på en enskild blobversionsnivå för detaljerad hantering av känsliga data.
Worm-princip på containernivå: Ett juridiskt undantag som har konfigurerats på containernivå gäller för alla blobar i containern. Enskilda blobar kan inte konfigureras med sina egna oföränderlighetsprinciper.
Taggar
Ett bevarande av juridiska skäl på containernivå måste associeras med en eller flera användardefinierade alfanumeriska taggar som fungerar som identifierarsträngar. En tagg kan till exempel innehålla ett ärende-ID eller händelsenamn.
Granskningsloggning
Varje container med ett gällande juridiskt undantag tillhandahåller en principgranskningslogg. Loggen innehåller användar-ID, kommandotyp, tidsstämplar och taggar för juridiska undantag. Granskningsloggen behålls för principens livslängd i enlighet med sec 17a-4(f) regelriktlinjer.
Azure-aktivitetsloggen innehåller en mer omfattande logg över alla hanteringstjänstaktiviteter. Azure-resursloggar behåller information om dataåtgärder. Det är användarens ansvar att lagra loggarna beständigt, vilket kan krävas för regelmässiga eller andra ändamål.
Ändringar av juridiska undantag på versionsnivå granskas inte.
Alternativ för oföränderlig lagringsfunktion
I följande tabell visas en uppdelning av skillnaderna mellan WORM på containernivå och versionsnivå WORM:
| Kategori | WORM på containernivå | MASK på versionsnivå |
|---|---|---|
| Principkornighetsnivå | Principer kan endast konfigureras på containernivå. Varje objekt som laddas upp till containern ärver den oföränderliga principuppsättningen. | Principer kan konfigureras på konto-, container- eller blobnivå. Om en princip anges på kontonivå ärver alla blobar som laddas upp till kontot principen. Samma logik följer med containrar. Om en princip anges på flera nivåer är prioritetsordningen alltid Blob –> Container –> Konto. |
| Tillgängliga typer av principer | Två olika typer av principer kan anges på containernivå: Tidsbaserade kvarhållningsprinciper och juridiska undantag. | På konto- och containernivå kan endast tidsbaserade kvarhållningsprinciper anges. På blobnivå kan både tidsbaserade kvarhållningsprinciper och juridiska undantag anges. |
| Funktionsberoenden | Inga andra funktioner är en förutsättning eller krav för att den här funktionen ska fungera. | Versionshantering är en förutsättning för att den här funktionen ska kunna användas. |
| Aktivering för befintliga konton/container | Den här funktionen kan aktiveras när som helst för befintliga containrar. | Beroende på detaljnivån kanske den här funktionen inte är aktiverad för alla befintliga konton/containrar. |
| Borttagning av konto/container | När en tidsbaserad kvarhållningsprincip har låsts på en container kan containrar bara tas bort om de är tomma. | När versionsnivån WORM har aktiverats på konto- eller containernivå kan de bara tas bort om de är tomma. |
| Stöd för Azure Data Lake Storage (lagringskonton som har ett hierarkiskt namnområde aktiverat) | WORM-principer på containernivå stöds i konton som har ett hierarkiskt namnområde. | Worm-principer på versionsnivå stöds ännu inte i konton som har ett hierarkiskt namnområde. |
Mer information om WORM på containernivå finns i Worm-principer på containernivå. Mer information om WORM på versionsnivå finns i WORM-principer på versionsnivå.
Containernivå jämfört med versionsnivå WORM
I följande tabell kan du bestämma vilken typ av WORM-princip som ska användas.
| Villkor | Worm-användning på containernivå | Användning av WORM på versionsnivå |
|---|---|---|
| Organisation av data | Du vill ange principer för specifika datauppsättningar, som kan kategoriseras efter container. Alla data i containern måste hållas i ett WORM-tillstånd under samma tid. | Du kan inte gruppera objekt efter kvarhållningsperioder. Alla blobar måste lagras med en enskild kvarhållningstid baserat på blobens scenarier, eller så har användaren en blandad arbetsbelastning så att vissa grupper av data kan grupperas i containrar medan andra blobbar inte kan göra det. Du kanske också vill ange principer på containernivå och principer på blobnivå inom samma konto. |
| Mängden data som kräver en oföränderlig princip | Du behöver inte ange principer för fler än 10 000 containrar per konto. | Du vill ange principer för alla data eller stora mängder data som kan avgränsas med konto. Du vet att om du använder WORM på containernivå måste du överskrida gränsen på 10 000 containrar. |
| Intresse av att aktivera versionshantering | Du vill inte hantera aktivering av versionshantering på grund av kostnaden eller på grund av att arbetsbelastningen skulle skapa flera extra versioner att hantera. | Du vill antingen använda versionshantering eller inte ha något emot att använda den. Du vet att om de inte aktiverar versionshantering kan du inte behålla redigeringar eller överskrivningar till oföränderliga blobar som separata versioner. |
| Lagringsplats (Blob Storage jämfört med Data Lake Storage) | Din arbetsbelastning är helt fokuserad på Azure Data Lake Storage. Du har inget omedelbart intresse eller planerar att växla till med ett konto som inte har funktionen hierarkisk namnrymd aktiverad. | Din arbetsbelastning finns antingen på Blob Storage i ett konto som inte har funktionen hierarkisk namnrymd aktiverad och kan använda WORM på versionsnivå nu, eller så är du villig att vänta tills versionshantering är tillgänglig för konton som har ett hierarkiskt namnområde aktiverat (Azure Data Lake Storage). |
Åtkomstnivåer
Alla blobåtkomstnivåer stöder oföränderlig lagring. Du kan ändra åtkomstnivån för en blob med åtgärden Ange blobnivå. Mer information finns i Åtkomstnivåer för blobdata.
Redundanskonfigurationer
Alla redundanskonfigurationer stöder oföränderlig lagring. Mer information om redundanskonfigurationer finns i Azure Storage-redundans.
Rekommenderade blobtyper
Microsoft rekommenderar att du konfigurerar oföränderlighetsprinciper främst för blockblobar och tilläggsblobar. Att konfigurera en oföränderlighetsprincip för en sidblob som lagrar en VHD-disk för en aktiv virtuell dator rekommenderas inte eftersom skrivningar till disken blockeras, eller om versionshantering är aktiverat lagras varje skrivning som en ny version. Microsoft rekommenderar att du noggrant granskar dokumentationen och testar dina scenarier innan du låser några tidsbaserade principer.
Oföränderlig lagring med mjuk blobborttagning
När mjuk borttagning av blobar har konfigurerats för ett lagringskonto gäller det för alla blobar i kontot oavsett om en princip för bevarande av juridiska skäl eller tidsbaserad kvarhållning gäller. Microsoft rekommenderar att du aktiverar mjuk borttagning för extra skydd innan några oföränderliga principer tillämpas.
Om du aktiverar mjuk borttagning av blobar och sedan konfigurerar en oföränderlighetsprincip tas alla blobar som redan har tagits bort permanent när kvarhållningsprincipen för mjuk borttagning har upphört att gälla. Mjuk borttagna blobar kan återställas under kvarhållningsperioden för mjuk borttagning. En blob eller version som ännu inte har tagits bort är skyddad av oföränderlighetsprincipen och kan inte tas bort mjukt förrän den tidsbaserade kvarhållningsprincipen har upphört att gälla eller om det juridiska undantaget har tagits bort.
Använda blobinventering för att spåra oföränderlighetsprinciper
Azure Storage Blob Inventory ger en översikt över containrarna i dina lagringskonton och blobar, ögonblicksbilder och blobversioner i dem. Du kan använda blobinventeringsrapporten för att förstå attributen för blobar och containrar, inklusive om en resurs har en konfigurerad oföränderlighetsprincip.
När du aktiverar blobinventering genererar Azure Storage en inventeringsrapport dagligen. Rapporten ger en översikt över dina data för affärs- och efterlevnadskrav.
Mer information om blobinventering finns i Azure Storage-blobinventering.
Kommentar
Du kan inte konfigurera en inventeringsprincip i ett konto om stöd för oföränderlighet på versionsnivå har aktiverats för det kontot, eller om stöd för oföränderlighet på versionsnivå är aktiverat på målcontainern som definieras i inventeringsprincipen.
Konfigurera principer i stor skala
Du kan använda en lagringsuppgift för att konfigurera oföränderlighetsprinciper i stor skala över flera lagringskonton baserat på en uppsättning villkor som du definierar. En lagringsuppgift är en resurs som är tillgänglig i Azure Storage Actions. Ett serverlöst ramverk som du kan använda för att utföra vanliga dataåtgärder på miljontals objekt i flera lagringskonton. Mer information finns i Vad är Azure Storage Actions?.
Prissättning
Det finns ingen extra kapacitetsavgift för att använda oföränderlig lagring. Oföränderliga data prissätts på samma sätt som föränderliga data. Om du använder WORM på versionsnivå kan fakturan vara högre eftersom du har aktiverat versionshantering och det finns en kostnad som är kopplad till att extra versioner lagras. Mer information finns i prissättningsprincipen för versionshantering. Prisinformation om Azure Blob Storage finns på sidan med priser för Azure Storage.
Om du skapar, ändrar eller tar bort en tidsbaserad kvarhållningsprincip eller ett juridiskt undantag för en blobversion blir det en skrivtransaktionsavgift.
Om du inte betalar din faktura och ditt konto har en aktiv tidsbaserad kvarhållningsprincip i praktiken gäller normala datakvarhållningsprinciper enligt villkoren i ditt avtal med Microsoft. Allmän information finns i Datahantering på Microsoft.
Funktionsstöd
Den här funktionen är inte kompatibel med återställning till tidpunkt och spårning av senaste åtkomst. Den här funktionen är kompatibel med kundhanterad oplanerad redundans, men alla ändringar som görs i den oföränderliga principen efter den senaste synkroniseringstiden (till exempel att låsa en tidsbaserad kvarhållningsprincip, utöka den osv.) synkroniseras inte till den sekundära regionen. När redundansväxlingen är klar kan du göra om ändringarna i den sekundära regionen för att säkerställa att den är uppdaterad med dina krav på oföränderlighet. Oföränderlighetsprinciper stöds inte i konton som har NFS 3.0-protokoll (Network File System) eller SFTP (SFTP) aktiverat på dem.
Vissa arbetsbelastningar, till exempel SQL Backup till URL, skapar en blob och lägger sedan till den. Om en container har en aktiv tidsbaserad kvarhållningsprincip eller ett bevarande av juridiska skäl lyckas inte det här mönstret. Mer information finns i Tillåt skyddade tilläggsblobskrivningar.
Mer information finns i Stöd för bloblagringsfunktioner i Azure Storage-konton.