Lägg till blob-tätning

Syftet med åtgärden Append Blob Seal är att tillåta användare och program att försegla tilläggsblobar och markera dem som skrivskyddade. Det här dokumentet beskriver de föreslagna REST API-specifikationerna för den här funktionen.

Förfrågan

Du kan skapa begäran på Append Blob Seal följande sätt. HTTPS rekommenderas. Ersätt myaccount med namnet på ditt lagringskonto.

URI för PUT-metodbegäran	HTTP-version
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=seal	HTTP/1.1

Sidhuvuden

Append Blob Sealreturnerar vanliga API-huvuden, ETag/LMT (senast ändrad tid), x-ms-request-id, x-ms-version, content-lengthoch .Date Append Blob Seal ändrar ETag/LMTinte .

Svarsrubrik	Värde	Beskrivning
x-ms-blob-sealed	sant/falskt	Valfritt. Falskt som standard. Om bloben är förseglad inkluderas den här rubriken i svaret när du förseglar och hämtar egenskaper för en blob. Det här huvudet ska visas i GetBlob, GetBlobProperties, AppendBlobSealoch ListBlobs för tilläggsblobar.

Frågeparametrar

Inga ytterligare URI-parametrar.

Begärandetext

Inga.

Svarsåtgärder

Svaret innehåller en HTTP-statuskod och en lista över svarshuvuden.

Statuskod

Du kan få någon av följande statuskoder:

• 200 (lyckades): Bloben är förseglad. Anropet är idempotent och lyckas om blobben redan är förseglad.

• 409 (InvalidBlobType): Tjänsten returnerar den här statuskoden om anropet finns på en befintlig sidblob eller blockblob.

• 404 (BlobNotFound): Tjänsten returnerar den här statuskoden om anropet finns på en icke-befintlig blob.

Auktorisering

Auktorisering krävs när du anropar en dataåtkomståtgärd i Azure Storage. Du kan auktorisera åtgärden enligt beskrivningen Append Blob Seal nedan.

Viktigt

Microsoft rekommenderar att du använder Microsoft Entra ID med hanterade identiteter för att auktorisera begäranden till Azure Storage. Microsoft Entra ID ger överlägsen säkerhet och användarvänlighet jämfört med auktorisering av delad nyckel.

Microsoft Entra ID (rekommenderas)

Azure Storage stöder användning av Microsoft Entra ID för att auktorisera begäranden till blobdata. Med Microsoft Entra ID kan du använda rollbaserad åtkomstkontroll i Azure (Azure RBAC) för att bevilja behörigheter till ett säkerhetsobjekt. Säkerhetsobjektet kan vara en användare, grupp, programtjänstens huvudnamn eller en hanterad Azure-identitet. Säkerhetsobjektet autentiseras av Microsoft Entra ID för att returnera en OAuth 2.0-token. Token kan sedan användas för att auktorisera en begäran mot Blob-tjänsten.

Mer information om auktorisering med Microsoft Entra ID finns i Auktorisera åtkomst till blobar med Microsoft Entra ID.

Behörigheter

Nedan visas den RBAC-åtgärd som krävs för att en Microsoft Entra användare, grupp, hanterad identitet eller tjänstens huvudnamn ska anropa Append Blob Seal åtgärden och den minst privilegierade inbyggda Azure RBAC-rollen som inkluderar den här åtgärden:

• Azure RBAC-åtgärd:Microsoft.Storage/storageAccounts/blobServices/containers/blobar/write
• Minst privilegierad inbyggd roll:Storage Blob Data-deltagare

Mer information om hur du tilldelar roller med Azure RBAC finns i Tilldela en Azure-roll för åtkomst till blobdata.

Signaturer för delad åtkomst (SAS)

En signatur för delad åtkomst (SAS) ger säker delegerad åtkomst till resurser i ett lagringskonto. Med en SAS har du detaljerad kontroll över hur en klient kan komma åt data. Du kan ange vilken resurs klienten kan komma åt, vilka behörigheter de har till dessa resurser och hur länge SAS är giltigt.

Åtgärden Append Blob Seal stöder tre typer av signaturer för delad åtkomst: SAS för användardelegering, sas för tjänsten och konto-SAS.

Vi rekommenderar att du använder Microsoft Entra autentiseringsuppgifter i stället för lagringskontonyckeln, vilket är enklare att kompromettera. Om din programdesign kräver signaturer för delad åtkomst använder du Microsoft Entra autentiseringsuppgifter för att skapa en SAS för användardelegering när det är möjligt.

När åtkomst med delad nyckel inte tillåts för lagringskontot tillåts inte en SAS-token för tjänsten eller en SAS-kontotoken för en begäran till Blob Storage. Mer information finns i Förstå hur nekande av delad nyckel påverkar SAS-token.

SAS för användardelegering

En SAS för användardelegering skyddas med Microsoft Entra autentiseringsuppgifter och även av de behörigheter som anges för SAS.

Append Blob Seal Att anropa åtgärden med hjälp av en SAS-token som delegerats till en container eller blobresurs kräver behörigheten Skriv (w) som en del av SAS-token för användardelegering.

Mer information om SAS för användardelegering finns i Skapa en SAS för användardelegering.

Tjänst-SAS

En tjänst-SAS skyddas med lagringskontonyckeln. En tjänst-SAS delegerar åtkomst till en resurs i en enda Azure Storage-tjänst, till exempel bloblagring.

Att anropa åtgärden Append Blob Seal med hjälp av en SAS-token som delegerats till en container eller blobresurs kräver behörigheten Skriv (w) som en del av tjänstens SAS-token.

Mer information om sas-tjänsten finns i Skapa en tjänst-SAS.

Konto-SAS

Ett SAS-konto skyddas med lagringskontonyckeln. En konto-SAS delegerar åtkomst till resurser i en eller flera av lagringstjänsterna. Alla åtgärder som är tillgängliga via en tjänst eller sas för användardelegering är också tillgängliga via ett konto-SAS.

Följande tabell anger den signerade resurstypen och signerade behörigheter som ska anges när åtkomst delegeras:

Åtgärd	Signerad tjänst	Signerad resurstyp	Signerad behörighet
Lägg till blob-tätning	Blob (b)	Objekt (o)	Skriva (w)

Mer information om kontots SAS finns i Skapa ett KONTO-SAS.

Delad nyckel

Åtgärden Append Blob Seal stöder auktorisering av delad nyckel. Auktorisering med kontonycklar rekommenderas inte för de flesta scenarier, eftersom det är mindre säkert.

Microsoft rekommenderar att du inte tillåter auktorisering av delad nyckel för lagringskontot när det är möjligt. Mer information finns i Förhindra auktorisering med delad nyckel.

Kommentarer

Om en tilläggsblob har ett lån behöver du ett låne-ID för att försegla bloben.

När du har förseglat en blob kan du fortfarande uppdatera egenskaper, blobindextaggar och metadata. Mjuk borttagning av en förseglad blob bevarar det förseglade tillståndet. Du kan skriva över förseglade blobar.  

Om du tar en ögonblicksbild av en förseglad blob innehåller ögonblicksbilden den förseglade flaggan. För befintliga ögonblicksbilder i den nya versionen returnerar Microsoft egenskapen.

När du kopierar en förseglad blob sprids den förseglade flaggan som standard. En rubrik exponeras som gör att flaggan kan skrivas över.

Ett nytt XML-element läggs till i svaret ListBlob med namnet Sealed. Värdet kan vara antingen true eller false.

Om du anropar AppendBlock på en blob som redan är förseglad returnerar tjänsten felmeddelandet som visas i följande tabell. Detta gäller för äldre versioner av API:et.

Felkod	HTTP-statuskod	Användarmeddelande
BlobIsSealed	Konflikt (409)	Den angivna bloben är förseglad och dess innehåll kan inte ändras om inte bloben återskapas efter en borttagning.

Om du anropar Append Blob Seal en tilläggsblob som redan har förseglats visas bara statuskoden 200 (lyckades).

Fakturering

Prisbegäranden kan komma från klienter som använder Blob Storage-API:er, antingen direkt via REST-API:et för Blob Storage eller från ett Azure Storage-klientbibliotek. Dessa begäranden ackumulerar avgifter per transaktion. Typen av transaktion påverkar hur kontot debiteras. Lästransaktioner ackumuleras till exempel till en annan faktureringskategori än skrivtransaktioner. I följande tabell visas faktureringskategorin för Append Blob Seal begäranden baserat på lagringskontotypen:

Åtgärd	Typ av lagringskonto	Faktureringskategori
Tilläggsblobtätning	Premium-blockblob Standard generell användning v2 Standard generell användning v1	Skrivåtgärder

Mer information om priser för den angivna faktureringskategorin finns i Azure Blob Storage Prissättning.

Se även

Azure Blob Storage felkoder