Toevoeg-blobafdichting

Het doel van de Append Blob Seal bewerking is om gebruikers en toepassingen in staat te stellen toevoeg-blobs te verzegelen door ze als alleen-lezen te markeren. Dit document bevat een overzicht van de voorgestelde REST API-specificaties voor deze functie.

Aanvraag

U kunt de Append Blob Seal aanvraag als volgt samenstellen. HTTPS wordt aanbevolen. Vervang myaccount door de naam van uw opslagaccount.

AANVRAAG-URI voor PUT-methode	HTTP-versie
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=seal	HTTP/1.1

Kopteksten

Append Blob Seal retourneert algemene API-headers, ETag/LMT (laatst gewijzigd-tijd), x-ms-request-id, x-ms-version, content-lengthen Date. Append Blob Seal wijzigt de ETag/LMTniet.

Antwoordheader	Waarde	Beschrijving
x-ms-blob-sealed	waar/onwaar	Optioneel. Standaard onwaar. Als de blob is verzegeld, wordt deze header opgenomen in het antwoord wanneer u de eigenschappen van een blob verzegelt en opgeeft. Deze koptekst moet worden weergegeven in GetBlob, GetBlobProperties, AppendBlobSealen ListBlobs voor toevoeg-blobs.

Queryparameters

Geen extra URI-parameters.

Aanvraagbody

Geen.

Antwoord

Het antwoord bevat een HTTP-statuscode en een lijst met antwoordheaders.

Statuscode

Mogelijk ontvangt u een van de volgende statuscodes:

• 200 (geslaagd): de blob is verzegeld. De aanroep is idempotent en slaagt als de blob al is verzegeld.

• 409 (InvalidBlobType): de service retourneert deze statuscode als de aanroep zich op een bestaande pagina- of blok-blob bevindt.

• 404 (BlobNotFound): de service retourneert deze statuscode als de aanroep zich in een niet-bestaande blob bevindt.

Autorisatie

Autorisatie is vereist bij het aanroepen van een bewerking voor gegevenstoegang in Azure Storage. U kunt de Append Blob Seal bewerking autoriseren zoals hieronder wordt beschreven.

Belangrijk

Microsoft raadt het gebruik van Microsoft Entra ID met beheerde identiteiten aan om aanvragen voor Azure Storage te autoriseren. Microsoft Entra ID biedt superieure beveiliging en gebruiksgemak in vergelijking met autorisatie met gedeelde sleutels.

Microsoft Entra ID (aanbevolen)

Azure Storage ondersteunt het gebruik van Microsoft Entra ID om aanvragen voor blobgegevens te autoriseren. Met Microsoft Entra ID kunt u op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) gebruiken om machtigingen te verlenen aan een beveiligingsprincipal. De beveiligingsprincipal kan een gebruiker, groep, toepassingsservice-principal of beheerde Azure-identiteit zijn. De beveiligingsprincipal wordt geverifieerd door Microsoft Entra ID om een OAuth 2.0-token te retourneren. Het token kan vervolgens worden gebruikt om een aanvraag voor de Blob-service te autoriseren.

Zie Toegang tot blobs autoriseren met Microsoft Entra ID voor meer informatie over autorisatie met behulp van Microsoft Entra ID.

Machtigingen

Hieronder vindt u de RBAC-actie die nodig is voor een Microsoft Entra gebruiker, groep, beheerde identiteit of service-principal om de Append Blob Seal bewerking aan te roepen, en de ingebouwde Azure RBAC-rol met de minste bevoegdheden die deze actie omvat:

• Azure RBAC-actie:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
• Ingebouwde rol met minimale bevoegdheden:Inzender voor opslagblobgegevens

Zie Een Azure-rol toewijzen voor toegang tot blobgegevens voor meer informatie over het toewijzen van rollen met behulp van Azure RBAC.

Shared Access Signatures (SAS)

Een Shared Access Signature (SAS) biedt beveiligde gedelegeerde toegang tot resources in een opslagaccount. Met een SAS hebt u gedetailleerde controle over hoe een client toegang heeft tot gegevens. U kunt opgeven tot welke resource de client toegang heeft, welke machtigingen ze hebben voor deze resources en hoe lang de SAS geldig is.

De Append Blob Seal bewerking ondersteunt drie typen handtekeningen voor gedeelde toegang: sas voor gebruikersdelegatie, service-SAS en account-SAS.

Als best practice voor beveiliging raden we u aan Microsoft Entra referenties te gebruiken in plaats van de sleutel van het opslagaccount, die gemakkelijker kan worden aangetast. Als voor uw toepassingsontwerp handtekeningen voor gedeelde toegang zijn vereist, gebruikt u Microsoft Entra referenties om, indien mogelijk, een SAS voor gebruikersdelegatie te maken.

Wanneer gedeelde sleuteltoegang niet is toegestaan voor het opslagaccount, is een service-SAS-token of een ACCOUNT-SAS-token niet toegestaan op een aanvraag voor Blob Storage. Zie Begrijpen hoe het niet toewijzen van gedeelde sleutel van invloed is op SAS-tokens voor meer informatie.

SAS voor gebruikersdelegatie

Een SAS voor gebruikersdelegatie wordt beveiligd met Microsoft Entra referenties en ook met de machtigingen die zijn opgegeven voor de SAS.

Voor het aanroepen van de Append Blob Seal bewerking met behulp van een SAS-token dat is gedelegeerd aan een container of blob-resource, is de machtiging Schrijven (w) vereist als onderdeel van het SAS-token voor gebruikersdelegatie.

Zie een SAS voor gebruikersdelegatie Creatie voor meer informatie over de SAS voor gebruikersdelegatie.

Service-SAS

Een service-SAS wordt beveiligd met de sleutel van het opslagaccount. Een service-SAS delegeert de toegang tot een resource in één Azure Storage-service, zoals blobopslag.

Voor het aanroepen van de Append Blob Seal bewerking met behulp van een SAS-token dat is gedelegeerd aan een container of blob-resource, is de machtiging Schrijven (w) vereist als onderdeel van het service-SAS-token.

Zie een service-SAS Creatie voor meer informatie over de service-SAS.

Account-SAS

Een account-SAS wordt beveiligd met de sleutel van het opslagaccount. Een account-SAS delegeert toegang tot resources in een of meer van de opslagservices. Alle bewerkingen die beschikbaar zijn via een service of gebruikersdelegatie-SAS zijn ook beschikbaar via een account-SAS.

In de volgende tabel ziet u het ondertekende resourcetype en de ondertekende machtigingen die moeten worden opgegeven bij het delegeren van toegang:

Bewerking	Ondertekende service	Ondertekend resourcetype	Ondertekende machtiging
Toevoeg-blobafdichting	Blob (b)	Object (o)	Schrijven (w)

Zie Creatie een account-SAS Creatie voor meer informatie over de account-SAS.

Gedeelde sleutel

De Append Blob Seal bewerking ondersteunt autorisatie van gedeelde sleutels. Autoriseren met accountsleutels wordt niet aanbevolen voor de meeste scenario's, omdat dit minder veilig is.

Microsoft raadt aan om indien mogelijk autorisatie voor gedeelde sleutels voor het opslagaccount ongedaan te maken. Zie Autorisatie met gedeelde sleutel voorkomen voor meer informatie.

Opmerkingen

Als een toevoeg-blob een lease heeft, hebt u een lease-id nodig om de blob te verzegelen.

Nadat u een blob hebt verzegeld, kunt u nog steeds eigenschappen, blobindextags en metagegevens bijwerken. Als u een verzegelde blob voorlopig verwijdert, blijft de verzegelde status behouden. U kunt verzegelde blobs overschrijven.  

Als u een momentopname van een verzegelde blob maakt, bevat de momentopname de verzegelde vlag. Voor bestaande momentopnamen in de nieuwe versie retourneert Microsoft de eigenschap.

Wanneer u een verzegelde blob kopieert, wordt de verzegelde vlag standaard doorgegeven. Er wordt een header weergegeven waarmee de vlag kan worden overschreven.

Er wordt een nieuw XML-element toegevoegd aan het antwoord, met de ListBlob naam Sealed. De waarde kan true of false zijn.

Als u aanroept AppendBlock op een blob die al is verzegeld, retourneert de service het foutbericht dat wordt weergegeven in de volgende tabel. Dit geldt voor oudere versies van de API.

Foutcode	HTTP-statuscode	Gebruikersbericht
Verzegelde blobis	Conflict (409)	De opgegeven blob is verzegeld en de inhoud ervan kan niet worden gewijzigd, tenzij de blob opnieuw wordt gemaakt na een verwijdering.

Als u een toevoeg-blob aanroept Append Blob Seal die al is verzegeld, ziet u gewoon de statuscode 200 (Geslaagd).

Billing

Prijsaanvragen kunnen afkomstig zijn van clients die gebruikmaken van Blob Storage-API's, rechtstreeks via de Blob Storage REST API of vanuit een Azure Storage-clientbibliotheek. Met deze aanvragen worden kosten per transactie in rekening gebracht. Het type transactie is van invloed op de manier waarop de rekening in rekening wordt gebracht. Leestransacties worden bijvoorbeeld toegevoegd aan een andere factureringscategorie dan schrijftransacties. In de volgende tabel ziet u de factureringscategorie voor Append Blob Seal aanvragen op basis van het type opslagaccount:

Bewerking	Type opslagaccount	Factureringscategorie
Toevoeg-blobafdichting	Premium-blok-blob Standard v2 voor algemeen gebruik Standard v1 voor algemeen gebruik	Schrijfbewerkingen

Zie prijzen voor Azure Blob Storage voor meer informatie over prijzen voor de opgegeven factureringscategorie.

Zie ook

Azure Blob Storage foutcodes