Bedrijfskritieke blobgegevens opslaan met onveranderbare opslag in een schrijfbewerking één keer, veel (WORM)-status lezen
Met de onveranderbare opslag voor Azure Blob Storage kunnen gebruikers bedrijfskritieke gegevens in een WORM-status (Write Once Read Many) opslaan. In een WORM-status kunnen gegevens niet worden gewijzigd of verwijderd voor een door de gebruiker opgegeven interval. Door onveranderbaarheidsbeleid voor blobgegevens te configureren, kunt u uw gegevens beschermen tegen overschrijven en verwijderen.
Onveranderbare opslag voor Azure Blob Storage ondersteunt twee typen onveranderbaarheidsbeleid:
Bewaarbeleid op basis van tijd: Met een bewaarbeleid op basis van tijd kunnen gebruikers beleidsregels instellen voor het opslaan van gegevens voor een bepaald interval. Wanneer een bewaarbeleid op basis van tijd is ingesteld, kunnen objecten worden gemaakt en gelezen, maar niet gewijzigd of verwijderd. Nadat de bewaarperiode is verlopen, kunnen objecten worden verwijderd, maar niet worden overschreven.
Beleidsregels voor juridische bewaring: in een juridische bewaring worden onveranderbare gegevens opgeslagen totdat de juridische bewaring expliciet wordt gewist. Wanneer een juridische bewaring is ingesteld, kunnen objecten worden gemaakt en gelezen, maar niet gewijzigd of verwijderd.
Deze beleidsregels kunnen tegelijkertijd met elkaar worden ingesteld. Een gebruiker kan bijvoorbeeld een bewaarbeleid op basis van tijd en een juridische bewaring op hetzelfde niveau en tegelijkertijd hebben ingesteld. Als u een schrijfbewerking wilt laten slagen, moet versiebeheer zijn ingeschakeld of moet er geen juridisch bewaringsbeleid of bewaarbeleid op basis van tijd zijn voor de gegevens. Om een verwijdering te laten slagen, mag er ook geen juridische bewaring of bewaarbeleid op basis van tijd zijn voor de gegevens.
In het volgende diagram ziet u hoe bewaarbeleid op basis van tijd en juridische bewaring schrijf- en verwijderbewerkingen verhindert terwijl ze van kracht zijn.
Er zijn twee functies onder de onveranderbare opslagparaplu: WORM op containerniveau en WORM op versieniveau. Met WORM op containerniveau kunnen beleidsregels alleen op containerniveau worden ingesteld, terwijl WORM op versieniveau toestaat dat beleidsregels worden ingesteld op account-, container- of versieniveau.
Over onveranderbare opslag voor blobs
Onveranderbare opslag helpt zorgorganisaties, financiële instellingen en gerelateerde branches, met name broker-dealerorganisaties, om gegevens veilig op te slaan. Onveranderbare opslag kan in elk scenario worden gebruikt om kritieke gegevens te beschermen tegen wijziging of verwijdering.
Typische toepassingen zijn onder andere:
Naleving van regelgeving: onveranderbare opslag voor Azure Blob Storage helpt organisaties om SEC 17a-4(f), CFTC 1.31(d), FINRA en andere regelgeving te adresseren.
Veilige documentretentie: onveranderbare opslag voor blobs zorgt ervoor dat gegevens niet door een gebruiker kunnen worden gewijzigd of verwijderd, zelfs niet door gebruikers met beheerdersbevoegdheden voor accounts.
Juridische bewaring: onveranderbare opslag voor blobs stelt gebruikers in staat gevoelige informatie op te slaan die essentieel is voor juridische procedures of bedrijfsgebruik in een manipulatiebestendige status voor de gewenste duur totdat de bewaring wordt verwijderd. Deze functie is niet alleen beperkt tot juridische use cases, maar kan ook worden beschouwd als een bewaring op basis van gebeurtenissen of een bedrijfsvergrendeling, waarbij de noodzaak om gegevens te beveiligen op basis van gebeurtenistriggers of bedrijfsbeleid is vereist.
Naleving van regelgeving
Microsoft heeft een toonaangevende onafhankelijke evaluatiefirma bewaard die gespecialiseerd is in recordbeheer en informatiebeheer, Cohasset Associates, om onveranderbare opslag te evalueren voor blobs en de naleving van vereisten die specifiek zijn voor de financiële dienstverlening. Cohasset heeft gevalideerd dat onveranderbare opslag, wanneer deze wordt gebruikt om blobs in een WORM-status te bewaren, voldoet aan de relevante opslagvereisten van CFTC-regel 1.31(c)-(d), FINRA-regel 4511 en SEC-regel 17a-4(f). Microsoft heeft zich gericht op deze set regels omdat ze de meest beschrijvende richtlijnen voor het bewaren van records voor financiële instellingen vertegenwoordigen.
Het Cohasset-rapport is beschikbaar in het Vertrouwenscentrum van Microsoft Service. Het Vertrouwenscentrum van Azure bevat gedetailleerde informatie over de nalevingscertificeringen van Microsoft. Neem contact op met de ondersteuning van Azure als u een verklaring van Microsoft wilt aanvragen met betrekking tot de compatibiliteit van WORM-onveranderbaarheid.
Bewaarbeleid op basis van tijd
In een bewaarbeleid op basis van tijd worden blobgegevens opgeslagen in een WORM-indeling voor een bepaald interval. Wanneer een bewaarbeleid op basis van tijd is ingesteld, kunnen clients blobs maken en lezen, maar ze niet wijzigen of verwijderen. Nadat het bewaarinterval is verlopen, kunnen blobs worden verwijderd, maar niet worden overschreven.
Bereik
Een bewaarbeleid op basis van tijd kan worden geconfigureerd op de volgende bereiken:
- WORM-beleid op versieniveau: een bewaarbeleid op basis van tijd kan worden geconfigureerd op account-, container- of versieniveau. Als deze is geconfigureerd op account- of containerniveau, wordt deze overgenomen door alle blobs in het respectieve account of de container.
- WORM-beleid op containerniveau: een bewaarbeleid op basis van tijd dat op containerniveau is geconfigureerd, is van toepassing op alle blobs in die container. Afzonderlijke blobs kunnen niet worden geconfigureerd met hun eigen onveranderbaarheidsbeleid.
Retentie-interval voor beleid op basis van tijd
Het minimale bewaarinterval voor een bewaarbeleid op basis van tijd is één dag en het maximum is 146.000 dagen (400 jaar). Wanneer u een bewaarbeleid op basis van tijd configureert, blijven de betrokken objecten onveranderbaar gedurende de effectieve bewaarperiode. De effectieve bewaarperiode voor objecten is gelijk aan het verschil tussen de aanmaaktijd van de blob en het door de gebruiker opgegeven retentie-interval. Omdat het bewaarinterval van een beleid kan worden verlengd, gebruikt onveranderbare opslag de meest recente waarde van het door de gebruiker opgegeven retentie-interval om de effectieve bewaarperiode te berekenen.
Stel dat een gebruiker een bewaarbeleid op basis van tijd maakt met een bewaarperiode van vijf jaar. Een bestaande blob in die container, testblob1, is één jaar geleden gemaakt, dus de effectieve bewaarperiode voor testblob1 is vier jaar. Wanneer een nieuwe blob, testblob2, wordt geüpload naar de container, is de effectieve bewaarperiode voor testblob2 vijf jaar na het maken ervan.
Vergrendeld versus ontgrendeld beleid
Wanneer u voor het eerst een bewaarbeleid op basis van tijd configureert, wordt het beleid ontgrendeld voor testdoeleinden. Wanneer u klaar bent met testen, kunt u het beleid vergrendelen zodat het volledig compatibel is met SEC 17a-4(f) en andere naleving van regelgeving.
Zowel vergrendelde als ontgrendelde beleidsregels beschermen tegen verwijderingen en overschrijven. U kunt echter een ontgrendeld beleid wijzigen door de bewaarperiode te verkorten of uit te breiden. U kunt ook een ontgrendeld beleid verwijderen. U kunt een op tijd gebaseerd bewaarbeleid niet verwijderen. U kunt de bewaarperiode verlengen, maar u kunt deze niet verlagen. Een maximum van vijf verhogingen tot de effectieve bewaarperiode is toegestaan gedurende de levensduur van een vergrendeld beleid dat is gedefinieerd op containerniveau. Voor een beleid dat is geconfigureerd voor een blobversie, is er geen limiet voor het aantal verhogingen tot de effectieve periode.
Belangrijk
Een bewaarbeleid op basis van tijd moet zijn vergrendeld om de blob in een compatibele onveranderbare status (beveiligd schrijven en verwijderen) te hebben voor SEC 17a-4(f) en andere naleving van regelgeving. Microsoft raadt u aan het beleid binnen een redelijke tijd te vergrendelen, meestal minder dan 24 uur. Hoewel de ontgrendelde status onveranderbaarheidsbeveiliging biedt, wordt het gebruik van de ontgrendelde status voor andere doeleinden dan het testen op korte termijn niet aanbevolen.
Auditlogboekregistratie van bewaarbeleid
Elke container waarvoor een bewaarbeleid op basis van tijd is ingeschakeld, biedt een auditlogboek voor beleid. Het auditlogboek bevat maximaal zeven op tijd gebaseerde bewaaropdrachten voor retentiebeleid op basis van tijd. Logboekregistratie wordt meestal gestart zodra u het beleid hebt vergrendeld. Logboekvermeldingen bevatten de gebruikers-id, het opdrachttype, de tijdstempels en het retentieinterval. Het auditlogboek wordt bewaard voor de levensduur van het beleid in overeenstemming met de regelgevingsrichtlijnen SEC 17a-4(f).
Het Azure-activiteitenlogboek biedt een uitgebreider logboek van alle beheerserviceactiviteiten. Azure-resourcelogboeken behouden informatie over gegevensbewerkingen. Het is de verantwoordelijkheid van de gebruiker om deze logboeken permanent op te slaan, zoals mogelijk vereist is voor regelgeving of andere doeleinden.
Wijzigingen in bewaarbeleid op basis van tijd op versieniveau worden niet gecontroleerd.
Juridische bewaring
Een juridische bewaring is een tijdelijk onveranderbaarheidsbeleid dat kan worden toegepast voor juridische onderzoeksdoeleinden of algemeen beveiligingsbeleid. In een juridische bewaring worden blobgegevens opgeslagen in een WORM-indeling (Write-Once, Read-Many) totdat de bewaring expliciet wordt gewist. Wanneer een juridische bewaring van kracht is, kunnen blobs worden gemaakt en gelezen, maar niet gewijzigd of verwijderd. Gebruik een juridische bewaring wanneer de periode waarin de gegevens moeten worden bewaard in een WORM-status onbekend is.
Bereik
Een beleid voor juridische bewaring kan worden geconfigureerd op een van de volgende bereiken:
WORM-beleid op versieniveau: Een juridische bewaring kan worden geconfigureerd op een afzonderlijk blobversieniveau voor gedetailleerd beheer van gevoelige gegevens.
WORM-beleid op containerniveau: een juridische bewaring die op containerniveau is geconfigureerd, is van toepassing op alle blobs in die container. Afzonderlijke blobs kunnen niet worden geconfigureerd met hun eigen onveranderbaarheidsbeleid.
Tags
Een juridische bewaring op containerniveau moet worden gekoppeld aan een of meer door de gebruiker gedefinieerde alfanumerieke tags die fungeren als id-tekenreeksen. Een tag kan bijvoorbeeld een case-id of gebeurtenisnaam bevatten.
Controlegebeurtenissen vastleggen
Elke container met een juridische bewaring biedt een auditlogboek voor beleid. Het logboek bevat de gebruikers-id, het opdrachttype, de tijdstempels en de tags voor juridische bewaring. Het auditlogboek wordt bewaard voor de levensduur van het beleid in overeenstemming met de regelgevingsrichtlijnen SEC 17a-4(f).
Het Azure-activiteitenlogboek biedt een uitgebreider logboek van alle beheerserviceactiviteiten. Azure-resourcelogboeken behouden informatie over gegevensbewerkingen. Het is de verantwoordelijkheid van de gebruiker om deze logboeken permanent op te slaan, zoals mogelijk vereist is voor regelgeving of andere doeleinden.
Wijzigingen in juridische bewaringen op versieniveau worden niet gecontroleerd.
Onveranderbare opslagfunctieopties
In de volgende tabel ziet u een uitsplitsing van de verschillen tussen WORM op containerniveau en WORM op versieniveau:
| Categorie | WORM op containerniveau | WORM op versieniveau |
|---|---|---|
| Niveau van beleidsgranulariteit | Beleidsregels kunnen alleen op containerniveau worden geconfigureerd. Elk object dat naar de container wordt geüpload, neemt de onveranderbare beleidsset over. | Beleidsregels kunnen worden geconfigureerd op account-, container- of blobniveau. Als een beleid is ingesteld op accountniveau, nemen alle blobs die in dat account worden geüpload het beleid over. Dezelfde logica volgt met containers. Als een beleid op meerdere niveaus is ingesteld, is de volgorde van prioriteit altijd Blob -> Container -> Account. |
| Beschikbare typen beleidsregels | Er kunnen twee verschillende soorten beleidsregels worden ingesteld op containerniveau: bewaarbeleid op basis van tijd en juridische bewaring. | Op account- en containerniveau kan alleen bewaarbeleid op basis van tijd worden ingesteld. Op blobniveau kunnen zowel bewaarbeleid op basis van tijd als juridische bewaring worden ingesteld. |
| Functieafhankelijkheden | Er zijn geen andere functies die een vereiste of vereiste zijn om deze functie te laten functioneren. | Versiebeheer is een vereiste voor deze functie die moet worden gebruikt. |
| Inschakelen voor bestaande accounts/container | Deze functie kan op elk gewenst moment worden ingeschakeld voor bestaande containers. | Afhankelijk van het granulariteitsniveau is deze functie mogelijk niet ingeschakeld voor alle bestaande accounts/containers. |
| Account-/containerverwijdering | Zodra een bewaarbeleid op basis van tijd is vergrendeld voor een container, kunnen containers alleen worden verwijderd als ze leeg zijn. | Zodra WORM op versieniveau is ingeschakeld op account- of containerniveau, kunnen ze alleen worden verwijderd als ze leeg zijn. |
| Ondersteuning voor Azure Data Lake Storage Gen2 (opslagaccounts waarvoor een hiërarchische naamruimte is ingeschakeld) | WORM-beleid op containerniveau wordt ondersteund in accounts met een hiërarchische naamruimte. | WORM-beleid op versieniveau wordt nog niet ondersteund in accounts met een hiërarchische naamruimte. |
Zie WORM-beleid op containerniveau voor meer informatie over WORM-beleid op containerniveau. Ga naar het WORM-beleid op versieniveau voor meer informatie over WORM-beleid op versieniveau.
WORM op containerniveau versus versieniveau
In de volgende tabel kunt u bepalen welk type WORM-beleid u wilt gebruiken.
| Criteria | WORM-gebruik op containerniveau | WORM-gebruik op versieniveau |
|---|---|---|
| Organisatie van gegevens | U wilt beleidsregels instellen voor specifieke gegevenssets, die kunnen worden gecategoriseerd op container. Alle gegevens in die container moeten gedurende dezelfde tijd in een WORM-status worden bewaard. | U kunt objecten niet groeperen op bewaarperioden. Alle blobs moeten worden opgeslagen met een afzonderlijke bewaartijd op basis van de scenario's van die blob, of de gebruiker heeft een gemengde workload, zodat sommige groepen gegevens kunnen worden geclusterd in containers terwijl andere blobs dat niet kunnen. Mogelijk wilt u ook beleid op containerniveau en beleid op blobniveau instellen binnen hetzelfde account. |
| Hoeveelheid gegevens waarvoor onveranderbaar beleid is vereist | U hoeft geen beleid in te stellen voor meer dan 10.000 containers per account. | U wilt beleidsregels instellen voor alle gegevens of grote hoeveelheden gegevens die per account kunnen worden afgebakend. Als u WORM op containerniveau gebruikt, moet u de limiet van 10.000 containers overschrijden. |
| Interesse in het inschakelen van versiebeheer | U wilt niet omgaan met het inschakelen van versiebeheer vanwege de kosten, of omdat de workload talloze extra versies zou maken om mee om te gaan. | U wilt versiebeheer gebruiken of het niet erg vinden om het te gebruiken. U weet dat als ze versiebeheer niet inschakelen, u geen bewerkingen kunt behouden of overschrijven naar onveranderbare blobs als afzonderlijke versies. |
| Opslaglocatie (Blob Storage versus Data Lake Storage Gen2) | Uw workload is volledig gericht op Azure Data Lake Storage Gen2. U hebt geen directe interesse of wilt overschakelen naar het gebruik van een account waarvoor de hiërarchische naamruimtefunctie niet is ingeschakeld. | Uw workload bevindt zich in Blob Storage in een account waarvoor de hiërarchische naamruimtefunctie niet is ingeschakeld en die nu WORM op versieniveau kan gebruiken, of u wilt wachten tot versiebeheer beschikbaar is voor accounts waarvoor een hiërarchische naamruimte is ingeschakeld (Azure Data Lake Storage Gen2). |
Toegangslagen
Alle blob-toegangslagen ondersteunen onveranderbare opslag. U kunt de toegangslaag van een blob wijzigen met de bewerking Blob-laag instellen. Zie Access-lagen voor blobgegevens voor meer informatie.
Redundantieconfiguraties
Alle redundantieconfiguraties ondersteunen onveranderbare opslag. Zie Azure Storage-redundantie voor meer informatie over redundantieconfiguraties.
Aanbevolen blobtypen
Microsoft raadt u aan beleid voor onveranderbaarheid te configureren, voornamelijk voor blok-blobs en toevoeg-blobs. Het configureren van een onveranderbaarheidsbeleid voor een pagina-blob waarin een VHD-schijf voor een actieve virtuele machine wordt opgeslagen, wordt afgeraden omdat schrijfbewerkingen naar de schijf worden geblokkeerd of als versiebeheer is ingeschakeld, wordt elke schrijfbewerking opgeslagen als een nieuwe versie. Microsoft raadt u aan de documentatie grondig te bekijken en uw scenario's te testen voordat u beleid op basis van tijd vergrendelt.
Onveranderbare opslag met voorlopig verwijderen van blob
Wanneer voorlopig verwijderen van blobs is geconfigureerd voor een opslagaccount, is dit van toepassing op alle blobs binnen het account, ongeacht of een wettelijk bewaarbeleid of bewaarbeleid op basis van tijd van kracht is. Microsoft raadt aan voorlopig verwijderen in te schakelen voor extra beveiliging voordat beleid voor onveranderbaarheid wordt toegepast.
Als u voorlopig verwijderen van blobs inschakelt en vervolgens een beleid voor onveranderbaarheid configureert, worden blobs die al voorlopig zijn verwijderd definitief verwijderd zodra het bewaarbeleid voor voorlopig verwijderen is verlopen. Voorlopig verwijderde blobs kunnen worden hersteld tijdens de bewaarperiode voor voorlopig verwijderen. Een blob of versie die nog niet voorlopig is verwijderd, wordt beveiligd door het onveranderbaarheidsbeleid en kan pas voorlopig worden verwijderd nadat het bewaarbeleid op basis van tijd is verlopen of de juridische bewaring wordt verwijderd.
Blob-inventaris gebruiken om beleid voor onveranderbaarheid bij te houden
Azure Storage-blobinventaris biedt een overzicht van de containers in uw opslagaccounts en de blobs, momentopnamen en blobversies hierin. U kunt het blob-inventarisrapport gebruiken om inzicht te hebben in de kenmerken van blobs en containers, inclusief of een resource een onveranderbaar beleid heeft geconfigureerd.
Wanneer u blob-inventarisatie inschakelt, genereert Azure Storage dagelijks een inventarisrapport. Het rapport biedt een overzicht van uw gegevens voor zakelijke en nalevingsvereisten.
Zie Azure Storage-blob-inventaris voor meer informatie over blob-inventaris.
Notitie
U kunt een inventarisbeleid in een account niet configureren als ondersteuning voor onveranderbaarheid op versieniveau is ingeschakeld voor dat account of als ondersteuning voor onveranderbaarheid op versieniveau is ingeschakeld op de doelcontainer die is gedefinieerd in het inventarisbeleid.
Beleid op schaal configureren
U kunt een opslagtaak gebruiken om een beleid voor onveranderbaarheid op schaal te configureren voor meerdere opslagaccounts op basis van een set voorwaarden die u definieert. Een opslagtaak is een resource die beschikbaar is in Azure Storage Actions; een serverloos framework dat u kunt gebruiken om algemene gegevensbewerkingen uit te voeren op miljoenen objecten in meerdere opslagaccounts. Zie Wat is Azure Storage Actions?voor meer informatie.
Prijzen
Er worden geen extra capaciteitskosten in rekening gebracht voor het gebruik van onveranderbare opslag. Onveranderbare gegevens worden op dezelfde manier geprijsd als onveranderbare gegevens. Als u WORM op versieniveau gebruikt, is de factuur mogelijk hoger omdat u versiebeheer hebt ingeschakeld en er kosten zijn verbonden aan extra versies die worden opgeslagen. Bekijk het prijsbeleid voor versiebeheer voor meer informatie. Zie de pagina met prijzen voor Azure Blob Storage voor meer informatie over prijzen in Azure Blob Storage.
Het maken, wijzigen of verwijderen van een bewaarbeleid op basis van tijd of juridische bewaring op een blobversie resulteert in een schrijftransactiekosten.
Als u uw factuur niet betaalt en uw account een actief bewaarbeleid op basis van tijd heeft, zijn normale beleidsregels voor gegevensretentie van toepassing zoals bepaald in de voorwaarden van uw contract met Microsoft. Zie Gegevensbeheer bij Microsoft voor algemene informatie.
Functieondersteuning
Deze functie is niet compatibel met herstel naar een bepaald tijdstip en het bijhouden van laatste toegang. Deze functie is compatibel met door de klant beheerde niet-geplande failover, maar wijzigingen die worden aangebracht in het onveranderbare beleid na de laatste synchronisatietijd (zoals het vergrendelen van een bewaarbeleid op basis van tijd, uitbreiden, enzovoort) worden niet gesynchroniseerd naar de secundaire regio. Zodra de failover is voltooid, kunt u de wijzigingen in de secundaire regio opnieuw uitvoeren om ervoor te zorgen dat deze up-to-date is met uw onveranderbaarheidsvereisten. Beleid voor onveranderbaarheid wordt niet ondersteund in accounts waarvoor het NFS-protocol (Network File System) 3.0 of het SSH File Transfer Protocol (SFTP) is ingeschakeld.
Sommige workloads, zoals SQL Backup naar URL, maken een blob en voegen er vervolgens aan toe. Als een container een actief bewaarbeleid op basis van tijd of juridische bewaring heeft, slaagt dit patroon niet. Zie de schrijfbewerkingen voor beveiligde toevoeg-blob toestaan voor meer informatie.
Zie de ondersteuning voor Blob Storage-functies in Azure Storage-accounts voor meer informatie.