Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Oföränderlig lagring för Azure Blob Storage gör att du kan lagra affärskritiska data i ett WORM-läge (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 juridisk kvarhållning: En juridisk kvarhållning lagrar oföränderliga data tills den juridiska kvarhållningen uttryckligen tas bort. När ett bevarande av juridiska skäl har angetts kan objekt skapas och läsas, men inte ändras eller tas bort.
Du kan sätta ihop dessa försäkringar. Till exempel kan du ha både en tidsbaserad retentionspolicy och en laglig reservation på samma nivå och vid samma tidpunkt. För att en skrivning ska lyckas måste du antingen ha versionshantering aktiverad eller varken ha någon juridisk kontroll eller en tidsbaserad lagringspolicy för datan. För att en borttagning ska lyckas får det inte finnas någon juridisk reservation eller tidsbaserad lagringspolicy för datan.
Följande diagram visar hur tidsbaserade lagringspolicyer och juridiska reservationer förhindrar skriv- och borttagningsoperationer medan de är i kraft.
Det finns två funktioner under det oföränderliga lagringsparaplyet: WORM på containernivå och WORM på versionsnivå. Container-nivå WORM tillåter dig att sätta policyer endast på containernivå, medan versionsnivå WORM tillåter policys på konto-, container- eller versionsnivå.
Om oföränderlig lagring för blobar
Oföränderlig lagring hjälper vårdorganisationer, finansiella institutioner och närliggande branscher (särskilt mäklare-handlarorganisationer) att lagra data säkert. 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.
Kvarhållningsprincip: Oföränderlig lagring för blobbar gör att du kan lagra känslig information som är kritisk för rättstvister eller affärsverksamheten i ett manipulationssäkert tillstånd under önskad tidsperiod tills kvarhållningen 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-tjänst Trust Center. Azure Trust Center innehåller detaljerad information om Microsofts efterlevnadscertifieringar. Kontakta Azure Support om du vill begära ett attesteringsbrev från Microsoft angående WORM-efterlevnad för oföränderlighet.
Tidsbaserade kvarhållningsprinciper
En tidsbaserad kvarhållningsprincip lagrar blobdata i WORM-format för ett angivet intervall. När du sätter en tidsbaserad lagringspolicy kan klienter skapa och läsa blobs, men kan inte ändra eller ta bort dem. Efter att lagringsintervallet löpt ut kan blobs tas bort men inte skrivas över.
Omfattning
Du kan konfigurera en tidsbaserad lagringspolicy vid följande omfattningar:
- Versionsnivå-WORM-policy: Konfigurera en tidsbaserad lagringspolicy på konto-, container- eller versionsnivå (versionshantering måste vara aktiverad på kontot). Om du konfigurerar det på konto- eller containernivå, ärver alla blobs i respektive konto eller container policyn. Om det finns en laglig reservation på en container kan du inte skapa versionsnivå-WORM för samma container. Denna begränsning finns eftersom den juridiska reservationen förhindrar att versionerna genereras.
- WORM-princip på containernivå: En tidsbaserad kvarhållningsprincip som konfigurerats på containernivå gäller för alla blobar i containern. Du kan inte konfigurera enskilda blobs med deras egna oföränderlighetspolicyer.
Kvarhållningsintervall för en tidsbaserad policy
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 policy genom att förkorta eller förlänga kvarhållningsperioden. Du kan också ta bort en olåst policy. 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 policy som fastställs 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 skälig tid, vanligtvis mindre än 24 timmar. Även om det olåsta tillståndet ger skydd mot oföränderlighet, rekommenderar vi inte att använda det olåsta tillståndet för annat än korttidstestning.
Granskningsloggning för kvarhållningspolicy
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 policyn. Loggposter inkluderar användar-ID, kommandotyp, tidsstämplar och kvarhållningsintervall. Granskningsloggen behålls under riktlinjernas livslängd i enlighet med SEC 17a-4(f) regleringsriktlinjer.
Azure-aktivitetsloggen innehåller en mer omfattande logg över alla hanteringstjänstaktiviteter. Azure-resursloggar behåller information om dataåtgärder. Du är ansvarig för att lagra dessa loggar kontinuerligt, vilket kan krävas för regulatoriska 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. En laglig spärr lagrar blobdata i ett Write Once, Read Many (WORM)-format tills spärren uttryckligen är avslutad. När ett juridiskt undantag gäller kan blobar skapas och läsas, men inte ändras eller tas bort. Använd ett juridiskt bevarande när tidsperioden under vilken data måste bevaras i ett WORM-tillstånd är okänd.
Omfattning
En princip för bevarande av juridiska skäl kan konfigureras i något av följande omfång:
Versionsnivå-WORM-policy: En juridisk reservation kan konfigureras på en individuell blob-versionsnivå för detaljerad hantering av känslig data (versionshantering måste vara aktiverad på kontot).
WORM-princip på containernivå: En juridisk kvarstad 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
Du måste associera en kvarhållningsmarkering på containernivå med en eller flera användardefinierade alfanumeriska taggar som fungerar som identifieringssträngar. Till exempel kan en tagg innehålla ett ärende-ID eller ett 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 under riktlinjernas livslängd i enlighet med SEC 17a-4(f) regleringsriktlinjer.
Azure-aktivitetsloggen innehåller en mer omfattande logg över alla hanteringstjänstaktiviteter. Azure-resursloggar behåller information om dataåtgärder. Du är ansvarig för att lagra dessa loggar kontinuerligt, vilket kan krävas för regulatoriska 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å | Versionsnivå WORM |
|---|---|---|
| Principkornighetsnivå | Konfigurera policyer endast på containernivå. Varje objekt som du laddar upp i containern ärver den oföränderliga policyuppsättningen. | Konfigurera policyer på konto-, container- eller blob-nivå. Om du anger en policy på kontonivån ärver alla blobs som du laddar upp till det kontot den policyn. Samma logik följer med containrar. Om du sätter en policy på flera nivåer är prioritetsordningen alltid Blob -> Container -> Account. |
| Tillgängliga typer av principer | Ange två olika typer av policyer på behållarnivå: tidsbaserade lagringspolicyer och rättsliga spärrar. | På konto- och containernivå, sätt endast tidsbaserade lagringspolicyer. På blobnivå anger du både tidsbaserade kvarhållningsprinciper och rättsliga spärrar. |
| 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 och containrar | Aktivera denna funktion när som helst för befintliga containrar. | Beroende på detaljnivån kan denna funktion vara omöjlig för alla befintliga konton och containrar. |
| Borttagning av konto/container | Efter att du låst en tidsbaserad lagringspolicy på en container kan du bara ta bort containrar om de är tomma. | Efter att du aktiverat versionsnivå WORM på konto- eller containernivå kan du bara ta bort dem om de är tomma. |
| Stöd för Azure Data Lake Storage (lagringskonton som har ett hierarkiskt namnområde aktiverat) | Stöder WORM-policyer på containernivå i konton som har en hierarkisk namnrymd. | WORM-principer på versionsnivå stöds ännu inte för konton som har en hierarkisk namnrymd. |
Mer information om WORM på containernivå finns i WORM-policyer på containernivå. För att lära dig mer om versionsnivå-WORM, se versionsnivå-WORM-policys.
WORM på containernivå kontra på versionsnivå
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 sätta policyer för specifika datamängder, som du kan kategorisera 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 blobs måste lagras med en individuell lagringstid baserat på blobens scenarier, annars har du en blandad arbetsbelastning så att vissa datagrupper kan klustras i containrar medan andra blobs inte kan. Du kanske också vill ange principer på containernivå och principer på blobnivå inom samma konto. |
| Datamängd som kräver en oföränderlig policy | Du behöver inte ange principer för fler än 10 000 containrar per konto. | Du vill sätta policyer för all data eller stora mängder data som du kan avgränsa per 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 du inte aktiverar versionshantering kan du inte behålla redigeringar eller överskrivningar till oföränderliga blobs 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 och planerar inte att växla till ett konto där funktionen för hierarkisk namnrymd inte är 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 operationen Set Blob Tier . 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änderlighetspolicy för en sidblob som lagrar en VHD-disk för en aktiv virtuell maskin avråds eftersom skrivningar till disken blockeras, eller om versionshantering är aktiverad, 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 du konfigurerar blob soft delete för ett lagringskonto gäller det för alla blobs inom kontot oavsett om en laglig reservation eller tidsbaserad lagringspolicy 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 blob soft delete och sedan konfigurerar en oförändralighetspolicy, raderas alla blobs som du redan visst raderat permanent när soft delete-bevarandepolicyn löper ut. Du kan återställa mjukt raderade blobs under lagringsperioden för mjuk borttagning. En blob eller version som du ännu inte mjukraderat skyddas av oföränderlighetspolicyn och kan inte mjukraderas förrän efter att den tidsbaserade lagringspolicyn löpt ut eller den juridiska spärren har tagits bort.
Använd blobinventering för att spåra oföränderlighetsprinciper
Azure Storage Blob Inventory ger en översikt över containrarna i dina lagringskonton samt blobarna, ögonblicksbilderna och blobversionerna däri. 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.
Anteckning
Du kan inte konfigurera en inventariepolicy i ett konto om stöd för versionsnivå-oföränderlighet är aktiverat på det kontot, eller om stöd för versionsnivå-oföränderlighet är aktiverat i destinationscontainern som du definierar i inventariepolicyn.
Konfigurera principer i stor skala
Du kan använda en lagringsuppgift för att konfigurera oföränderlighetspolicyer 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 versionsnivå-WORM kan kostnaden bli högre eftersom du aktiverade versionshantering, och det tillkommer en kostnad för att extra versioner lagras. Granska prissättningspolicyn för versionshantering för mer information. Prisinformation om Azure Blob Storage finns på sidan med priser för Azure Storage.
Om du skapar eller tar bort en tidsbaserad kvarhållningsprincip eller ett juridiskt undantag för en blobversion resulterar det i en skrivtransaktionsavgift. Att ändra en tidsbaserad lagringspolicy (antingen låsa eller förlänga den) resulterar i en avgift för andra operationer. För mer information om transaktionsavgifter, se Drift och dataöverföring.
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
Viktigt!
Den här funktionen är inte kompatibel med återställning till tidpunkt och spårning av senaste åtkomst.
Denna funktion är kompatibel med kundhanterad oplanerad failover. Men alla ändringar du gör i den oföränderliga policyn efter senaste synkroniseringstiden (som att låsa en tidsbaserad lagringspolicy eller förlänga den) synkar inte till den sekundära regionen. När redundansväxlingen är klar kan du tillämpa ändringarna på nytt i den sekundära regionen för att säkerställa att den är uppdaterad enligt dina krav på oföränderlighet. Oföränderlighetsprinciper stöds inte av konton med aktiverat NFS 3.0-protokoll eller SFTP.
Vissa arbetsbelastningar, till exempel SQL Backup till URL, skapar en blob och lägger sedan till innehåll i den. Om en container har en aktiv tidsbaserad förvaringspolicy eller juridisk reservation lyckas inte detta mönster. Mer information finns i Tillåt skyddade tilläggsblobskrivningar.
Mer information finns i Stöd för bloblagringsfunktioner i Azure Storage-konton.