Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Met onveranderbare opslag voor Azure Blob Storage kunt u bedrijfskritieke gegevens opslaan met de WORM-status (Write Once, Read Many). 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.
Je kunt deze polissen samenstellen. Je kunt bijvoorbeeld zowel een tijdsgebaseerd retentiebeleid als een wettelijke reservering op hetzelfde niveau en op hetzelfde moment hebben ingesteld. Om een schrijfproces te laten slagen, moet je ofwel versiebeheer ingeschakeld hebben of geen wettelijke vasthoudendheid of een tijdsgebaseerd bewaarbeleid op de data hebben. Om een verwijdering te laten slagen, mag er geen wettelijke opslag of tijdsgebaseerd bewaarbeleid op de gegevens zijn.
Het volgende diagram laat zien hoe tijdgebaseerde retentiebeleid en juridische blokken schrijf- en verwijderingsoperaties voorkomen zolang ze van kracht zijn.
Er zijn twee functies onder de onveranderbare opslagparaplu: WORM op containerniveau en WORM op versieniveau. Container-level WORM stelt je in staat om policies alleen op containerniveau in te stellen, terwijl versie-level WORM het mogelijk maakt om policies in te stellen op account-, container- of versieniveau.
Over onveranderbare opslag voor blobs
Onveranderlijke opslag helpt zorgorganisaties, financiële instellingen en aanverwante sectoren (vooral broker-dealer organisaties) om data 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 opslag: Onveranderlijke opslag voor blobs stelt u in staat gevoelige informatie die cruciaal is voor rechtszaken of zakelijk gebruik in een manipulatievrije staat op te slaan voor de gewenste duur totdat de blokkade wordt opgeheven. 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 ingeschakeld die gespecialiseerd is in documentbeheer en informatiebeheer en -bestuur, Cohasset Associates, om onveranderbare opslag voor blobs te evalueren 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 je een tijdgebaseerd retentiebeleid instelt, kunnen clients blobs aanmaken en lezen, maar niet wijzigen of verwijderen. Nadat het retentieinterval is verstreken, kunnen blobs worden verwijderd maar niet worden overschreven.
Bereik
U kunt een tijdgebaseerd retentiebeleid instellen op de volgende scopes:
- Versieniveau WORM-beleid: Configureer een tijdgebaseerd retentiebeleid op account-, container- of versieniveau (versiebeheer moet op het account zijn ingeschakeld). Als je het configureert op account- of containerniveau, erven alle blobs in het betreffende account of container het beleid. Als er een wettelijke blokkade op een container zit, kun je geen versieniveau WORM maken voor dezelfde container. Deze beperking bestaat omdat de wettelijke beperking het genereren van de versies verhindert.
- WORM-beleid op containerniveau: een bewaarbeleid op basis van tijd dat op containerniveau is geconfigureerd, is van toepassing op alle blobs in die container. Je kunt geen individuele blobs configureren met hun eigen onveranderlijkheidsbeleid.
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 toestand bescherming biedt tegen onveranderlijkheid, raden we niet aan om de ontgrendelde toestand voor iets anders dan kortdurend testen te gebruiken.
Registratie van auditlogs voor retentiebeleid
Elke container waarvoor een bewaarbeleid op basis van tijd is ingeschakeld, biedt een auditlogboek voor beleid. Het controlelogboek bevat maximaal zeven tijdgebaseerde bewaarcommando's voor tijdgebaseerde vergrendelde retentiebeleid. Loggen start meestal wanneer 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. Je bent verantwoordelijk voor het continu opslaan van die logs, zoals mogelijk vereist is voor regelgevende of andere doeleinden.
Wijzigingen in bewaarbeleid op basis van tijd op versieniveau worden niet gecontroleerd.
Juridische beperkingen
Een juridische bewaring is een tijdelijk onveranderbaarheidsbeleid dat kan worden toegepast voor juridische onderzoeksdoeleinden of algemeen beveiligingsbeleid. Een juridische bewaarplicht bewaart blobgegevens in een Write Once, Read Many (WORM)-formaat totdat de bewaarplicht expliciet wordt opgeheven. 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 juridisch bewaarbeleid kan worden geconfigureerd op een van de volgende niveaus:
WORM-beleid op versieniveau: Een juridische blokkering kan worden ingesteld op het niveau van een afzonderlijke blobversie voor fijnmazig beheer van gevoelige gegevens (versiebeheer moet zijn ingeschakeld voor het account).
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
Je moet een juridische blokkering op containerniveau koppelen aan een of meer door de gebruiker gedefinieerde alfanumerieke tags die als identificatiereeksen dienen. Een tag kan bijvoorbeeld een case-ID of een gebeurtenisnaam bevatten.
Auditlogboek bijhouden
Elke container met een juridische bewaringsplicht biedt een beleid auditlogboek. 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. Je bent verantwoordelijk voor het continu opslaan van die logs, zoals mogelijk vereist is voor regelgevende of andere doeleinden.
Wijzigingen in juridische bewaarplichten op versieniveau worden niet geauditeerd.
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 | Configureer beleidsregels alleen op containerniveau. Elk object dat je in de container uploadt, erft de onveranderlijke beleidsset. | Configureer beleidsregels op account-, container- of blobniveau. Als je een beleid op accountniveau instelt, erven alle blobs die je uploadt in dat account het beleid. Dezelfde logica volgt met containers. Als je een beleid op meerdere niveaus instelt, is de volgorde van prioriteit altijd Blob -> Container -> Account. |
| Beschikbare typen beleidsregels | Stel twee verschillende soorten beleidsregels op containerniveau in: tijdgebaseerde retentiebeleid en wettelijke reserveringen. | Op account- en containerniveau stel je alleen tijdsgebaseerde retentiebeleid in. Stel op blobniveau zowel retentiebeleid op basis van tijd als juridische bewaringen in. |
| Functieafhankelijkheden | Er zijn geen andere functies die een vereiste of vereiste zijn om deze functie te laten functioneren. | Versiebeheer is een vereiste om deze functie te gebruiken. |
| Inschakelen voor bestaande accounts en containers | Schakel deze functie op elk moment in voor bestaande containers. | Afhankelijk van het niveau van granulariteit is deze functie mogelijk niet ingeschakeld voor alle bestaande accounts en containers. |
| Account-/containerverwijdering | Nadat je een tijdgebaseerd retentiebeleid op een container hebt vergrendeld, kun je containers alleen verwijderen als ze leeg zijn. | Nadat je versieniveau WORM hebt ingeschakeld op account- of containerniveau, kun je ze alleen verwijderen als ze leeg zijn. |
| Ondersteuning voor Azure Data Lake Storage (opslagaccounts waarvoor een hiërarchische naamruimte is ingeschakeld) | Ondersteun WORM-beleid op containerniveau in accounts met een hiërarchische naamruimte. | WORM-beleidsregels op versieniveau worden nog niet ondersteund voor accounts met een hiërarchische naamruimte. |
Voor meer informatie over container-level WORM, zie Container-level WORM-beleid. Voor meer informatie over versieniveau WORM, zie versieniveau WORM-beleid.
Container-niveau versus versie-niveau WORM
In de volgende tabel kunt u bepalen welk type WORM-beleid u wilt gebruiken.
| Criterium | WORM-gebruik op containerniveau | WORM-gebruik op versieniveau |
|---|---|---|
| Organisatie van gegevens | Je wilt beleidsregels instellen voor specifieke datasets, die je per container kunt categoriseren. 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 individuele retentietijd gebaseerd op de scenario's van die blob, anders heb je een gemengde werklast zodat sommige datagroepen in containers kunnen worden geclusterd 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. | Je wilt beleid instellen op alle data of grote hoeveelheden data die je per account kunt afbakenen. 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. | Of u wilt gebruik maken van versiebeheer, of u vindt het niet erg om het te gebruiken. Je weet dat als je versiebeheer niet inschakelt, je bewerkingen of overschrijvingen naar onveranderlijke blobs niet als aparte versies kunt houden. |
| Opslaglocatie (Blob Storage versus Data Lake Storage) | Uw workload is volledig gericht op Azure Data Lake Storage. U hebt geen directe interesse of wilt overschakelen naar het gebruik van een account waarvoor de hiërarchische naamruimtefunctie niet is ingeschakeld. | Uw werkbelasting 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). |
Toegangslagen
Alle blob-toegangslagen ondersteunen onveranderbare opslag. Je kunt de toegangslaag van een blob wijzigen met de Set Blob Tier-operatie . 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 onveranderlijkheidsbeleid voor een paginablob die een VHD-schijf opslaat voor een actieve virtuele machine wordt afgeraden omdat schrijfacties naar de schijf worden geblokkeerd, of als versiebeheer is ingeschakeld, wordt elke schrijf als een nieuwe versie opgeslagen. 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 zachte verwijdering van blob
Wanneer je blob soft delete instelt voor een opslagaccount, geldt dit voor alle blobs binnen het account, ongeacht of er een wettelijke opslag of tijdgebaseerd retentiebeleid van kracht is. Microsoft raadt aan voorlopig verwijderen in te schakelen voor extra beveiliging voordat beleid voor onveranderbaarheid wordt toegepast.
Als je voorlopig verwijderen voor blobs inschakelt en vervolgens een onveranderbaarheidsbeleid configureert, worden alle blobs die je al voorlopig had verwijderd permanent verwijderd zodra de bewaartermijn van het beleid voor voorlopig verwijderen is verstreken. Je kunt voor voorlopig verwijderen gemarkeerde blobs herstellen tijdens de bewaartermijn voor voorlopig verwijderen. Een blob of versie die je nog niet hebt zacht verwijderd, wordt beschermd door het onveranderlijkheidsbeleid en kan pas zacht verwijderd worden nadat het tijdgebaseerde retentiebeleid is verlopen of de wettelijke blokkade is opgeheven.
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 de blob-inventaris.
Notitie
Je kunt geen inventarisbeleid configureren in een account als ondersteuning voor versieniveau-onveranderlijkheid op dat account is ingeschakeld, of als ondersteuning voor versie-niveau onveranderlijkheid is ingeschakeld in de bestemmingscontainer die je definieert in het inventarisbeleid.
Beleid op schaal configureren
Je kunt een opslagtaak gebruiken om immutabiliteitsbeleid op schaal te configureren over meerdere opslagaccounts op basis van een set voorwaarden die je 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. Voor meer informatie, zie Wat is Azure Storage Actions?
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 je versieniveau WORM gebruikt, kan de rekening hoger zijn omdat je versiebeheer hebt ingeschakeld, en er zijn kosten verbonden aan het opslaan van extra versies. Bekijk het prijsbeleid voor versiebeheer voor meer informatie. Voor prijsdetails over Azure Blob Storage, zie de Azure Storage-prijs pagina.
Het maken of verwijderen van een tijdgebaseerd bewaarbeleid of juridische blokkering op een blobversie resulteert in de kosten voor schrijftransacties. Het wijzigen van een op tijd gebaseerd retentiebeleid (door het te vergrendelen of te verlengen) leidt tot kosten voor 'Other operations'. Voor meer informatie over transactiekosten, zie Operations and Data Transfer.
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
Belangrijk
Deze functie is niet compatibel met herstel naar een bepaald tijdstip en het bijhouden van laatste toegang.
Deze functie is compatibel met klantbeheerde ongeplande failover. Echter, wijzigingen die je aanbrengt aan het onveranderlijke beleid na de laatste synchronisatietijd (zoals het vergrendelen van een tijdgebaseerd retentiebeleid of het verlengen ervan) synchroniseren niet met de secundaire regio. Nadat de failover is voltooid, kunt u de wijzigingen opnieuw toepassen in de secundaire regio om ervoor te zorgen dat deze up-to-date is met uw vereisten voor onveranderlijkheid. 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, tijdgebaseerd retentiebeleid heeft of onder een juridische blokkering valt, werkt dit patroon niet. Voor meer informatie, zie Beveiligde toevoeg-blob-schrijfbewerkingen toestaan.
Zie de ondersteuning voor Blob Storage-functies in Azure Storage-accounts voor meer informatie.