Grant limited access to Azure Storage resources using shared access signatures (SAS) (Bevilja begränsad åtkomst till Azure Storage-resurser med hjälp av signaturer för delad åtkomst (SAS))

  • Artikel

En signatur för delad åtkomst (SAS) ger säker delegerad åtkomst till resurser i ditt lagringskonto. Med en SAS har du detaljerad kontroll över hur en klient kan komma åt dina data. Till exempel:

  • Vilka resurser klienten kan komma åt.

  • Vilka behörigheter de har för dessa resurser.

  • Hur länge SAS är giltigt.

Typer av signaturer för delad åtkomst

Azure Storage har stöd för tre typer av signaturer för delad åtkomst:

  • SAS för användardelegering

  • Tjänst-SAS

  • Konto-SAS

SAS för användardelegering

En SAS för användardelegering skyddas med Microsoft Entra-autentiseringsuppgifter och även av de behörigheter som angetts för SAS. Sas för användardelegering gäller endast bloblagring.

Mer information om SAS för användardelegering finns i Skapa en SAS (REST API) för användardelegering.

Tjänst-SAS

En tjänst-SAS skyddas med lagringskontonyckeln. En tjänst-SAS delegerar åtkomst till en resurs i endast en av Azure Storage-tjänsterna: Blob Storage, Queue Storage, Table Storage eller Azure Files.

Mer information om tjänstens SAS finns i Skapa en tjänst-SAS (REST API).

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.

Du kan också delegera åtkomst till följande:

  • Åtgärder på servicenivå (till exempel åtgärderna Get/Set Service Properties och Get Service Stats ).

  • Läs-, skriv- och borttagningsåtgärder som inte är tillåtna med en tjänst-SAS.

Mer information om kontot SAS finns i Skapa ett KONTO-SAS (REST API).

Kommentar

Microsoft rekommenderar att du använder Microsoft Entra-autentiseringsuppgifter när det är möjligt som bästa praxis för säkerhet, i stället för att använda kontonyckeln, som är enklare att kompromettera. När programdesignen kräver signaturer för delad åtkomst för åtkomst till Blob Storage använder du Microsoft Entra-autentiseringsuppgifter för att skapa en SAS för användardelegering när det är möjligt för överlägsen säkerhet. Mer information finns i Auktorisera åtkomst till data i Azure Storage.

En signatur för delad åtkomst kan ha något av följande två formulär:

  • Ad hoc SAS. När du skapar en ad hoc-SAS anges starttid, förfallotid och behörigheter i SAS-URI:n. Alla typer av SAS kan vara en ad hoc-SAS.

  • Tjänst-SAS med lagrad åtkomstprincip. En lagrad åtkomstprincip definieras på en resurscontainer, som kan vara en blobcontainer, tabell, kö eller filresurs. Den lagrade åtkomstprincipen kan användas för att hantera begränsningar för en eller flera tjänstsignaturer för delad åtkomst. När du associerar en tjänst-SAS med en lagrad åtkomstprincip ärver SAS de begränsningar – starttid, förfallotid och behörigheter – som definierats för den lagrade åtkomstprincipen.

Kommentar

En SAS för användardelegering eller ett konto-SAS måste vara en ad hoc-SAS. Lagrade åtkomstprinciper stöds inte för sas för användardelegering eller konto-SAS.

Så här fungerar en signatur för delad åtkomst

En signatur för delad åtkomst är en token som läggs till i URI:n för en Azure Storage-resurs. Token som innehåller en särskild uppsättning frågeparametrar som anger hur resurserna kan nås av klienten. En av frågeparametrarna, signaturen, konstrueras från SAS-parametrarna och signeras med nyckeln som användes för att skapa SAS. Den här signaturen används av Azure Storage för att auktorisera åtkomst till lagringsresursen.

Kommentar

Det går inte att granska genereringen av SAS-token. Alla användare som har behörighet att generera en SAS-token, antingen med hjälp av kontonyckeln eller via en Azure-rolltilldelning, kan göra det utan att lagringskontots ägare känner till det. Var noga med att begränsa behörigheter som gör det möjligt för användare att generera SAS-token. Om du vill förhindra att användare genererar en SAS som är signerad med kontonyckeln för blob- och köarbetsbelastningar kan du neka åtkomst till delad nyckel till lagringskontot. Mer information finns i Förhindra auktorisering med delad nyckel.

SAS-signatur och auktorisering

Du kan signera en SAS-token med en användardelegeringsnyckel eller med en lagringskontonyckel (delad nyckel).

Signera en SAS-token med en användardelegeringsnyckel

Du kan signera en SAS-token med hjälp av en användardelegeringsnyckel som skapades med Microsoft Entra-autentiseringsuppgifter. En SAS för användardelegering är signerad med användardelegeringsnyckeln.

För att hämta nyckeln och sedan skapa SAS måste ett Microsoft Entra-säkerhetsobjekt tilldelas en Azure-roll som innehåller åtgärden Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey . Mer information finns i Skapa en SAS (REST API) för användardelegering.

Signera en SAS-token med en kontonyckel

Både en tjänst-SAS och ett sas-konto signeras med lagringskontonyckeln. Om du vill skapa en SAS som är signerad med kontonyckeln måste ett program ha åtkomst till kontonyckeln.

När en begäran innehåller en SAS-token auktoriseras den begäran baserat på hur SAS-token signeras. Åtkomstnyckeln eller autentiseringsuppgifterna som du använder för att skapa en SAS-token används också av Azure Storage för att bevilja åtkomst till en klient som har SAS.

I följande tabell sammanfattas hur varje typ av SAS-token har behörighet.

Typ av SAS Typ av auktorisering
SAS för användardelegering (endast bloblagring) Microsoft Entra ID
Tjänst-SAS Delad nyckel
Konto-SAS Delad nyckel

Microsoft rekommenderar att du använder en SAS för användardelegering när det är möjligt för överlägsen säkerhet.

SAS-token

SAS-token är en sträng som du genererar på klientsidan, till exempel med hjälp av något av Azure Storage-klientbiblioteken. SAS-token spåras inte av Azure Storage på något sätt. Du kan skapa ett obegränsat antal SAS-token på klientsidan. När du har skapat en SAS kan du distribuera den till klientprogram som kräver åtkomst till resurser i ditt lagringskonto.

Klientprogram tillhandahåller SAS-URI:n till Azure Storage som en del av en begäran. Sedan kontrollerar tjänsten SAS-parametrarna och signaturen för att kontrollera att den är giltig. Om tjänsten verifierar att signaturen är giltig godkänns begäran. Annars avvisas begäran med felkoden 403 (förbjuden).

Här är ett exempel på en TJÄNST-SAS-URI som visar resurs-URI:n, avgränsartecknet ('?') och SAS-token.

Diagram showing the components of a resource URI with SAS token.

Kommentar

Avgränsarens tecken ('?') för frågesträngen är inte en del av SAS-token. Om du genererar en SAS-token från portalen, PowerShell, Azure CLI eller någon av Azure Storage SDK:erna kan du behöva lägga till avgränsartecknet i resurs-URL:en.

När du ska använda en signatur för delad åtkomst

Använd en SAS för att ge säker åtkomst till resurser i ditt lagringskonto till alla klienter som annars inte har behörighet till dessa resurser.

Ett vanligt scenario där en SAS är användbar är en tjänst där användare läser och skriver sina egna data till ditt lagringskonto. I ett scenario där ett lagringskonto lagrar användardata finns det två typiska designmönster:

  1. Klienter laddar upp och laddar ned en via en klientproxytjänst, som utför autentisering. Den här klientdelsproxytjänsten tillåter validering av affärsregler. Men för stora mängder data eller transaktioner med stora volymer kan det vara dyrt eller svårt att skapa en tjänst som kan skalas för att matcha efterfrågan.

    Scenario diagram: Front-end proxy service

  2. En förenklad tjänst autentiserar klienten efter behov och genererar sedan en SAS. När klientprogrammet har fått SAS kan det komma åt lagringskontoresurser direkt. Åtkomstbehörigheter definieras av SAS och för det intervall som tillåts av SAS. SAS minskar behovet att dirigera alla data genom klientproxytjänsten.

    Scenario diagram: SAS provider service

Många verkliga tjänster kan använda en hybrid av dessa två metoder. Vissa data kan till exempel bearbetas och verifieras via klientdelsproxyn. Andra data sparas och/eller läss direkt med hjälp av SAS.

Dessutom krävs en SAS för att auktorisera åtkomst till källobjektet i en kopieringsåtgärd i vissa scenarier:

  • När du kopierar en blob till en annan blob som finns i ett annat lagringskonto.

    Du kan också använda en SAS för att auktorisera åtkomst till målbloben.

  • När du kopierar en fil till en annan fil som finns i ett annat lagringskonto.

    Du kan också använda en SAS för att auktorisera åtkomst till målfilen.

  • När du kopierar en blob till en fil eller en fil till en blob.

    Du måste använda en SAS även om käll- och målobjekten finns i samma lagringskonto.

Metodtips när du använder SAS

När du använder signaturer för delad åtkomst i dina program måste du vara medveten om två potentiella risker:

  • Om en SAS läcker ut kan den användas av alla som hämtar den, vilket potentiellt kan äventyra ditt lagringskonto.

  • Om en SAS som tillhandahålls till ett klientprogram upphör att gälla och programmet inte kan hämta en ny SAS från din tjänst kan programmets funktioner hindras.

Följande rekommendationer för att använda signaturer för delad åtkomst kan bidra till att minska dessa risker:

  • Använd alltid HTTPS för att skapa eller distribuera en SAS. Om en SAS skickas via HTTP och fångas upp kan en angripare som utför en man-in-the-middle-attack läsa SAS. Sedan kan de använda sas precis som den avsedda användaren kan ha. Detta kan potentiellt äventyra känsliga data eller tillåta skadade data av den skadliga användaren.

  • Använd en SAS för användardelegering när det är möjligt. En SAS för användardelegering ger överlägsen säkerhet för en tjänst-SAS eller ett konto-SAS. En SAS för användardelegering skyddas med Microsoft Entra-autentiseringsuppgifter, så att du inte behöver lagra din kontonyckel med din kod.

  • Ha en återkallelseplan på plats för en SAS. Se till att du är beredd att svara om en SAS har komprometterats.

  • Konfigurera en SAS-förfalloprincip för lagringskontot. En SAS-förfalloprincip anger ett rekommenderat intervall som SAS är giltigt för. SAS-förfalloprinciper gäller för en tjänst-SAS eller ett konto-SAS. När en användare genererar tjänsten SAS eller ett konto-SAS med ett giltighetsintervall som är större än det rekommenderade intervallet visas en varning. Om Azure Storage-loggning med Azure Monitor är aktiverat skrivs en post till Azure Storage-loggarna. Mer information finns i Skapa en förfalloprincip för signaturer för delad åtkomst.

  • Skapa en lagrad åtkomstprincip för en tjänst-SAS. Med lagrade åtkomstprinciper kan du återkalla behörigheter för en tjänst-SAS utan att behöva återskapa lagringskontonycklarna. Ange förfallodatumet för dessa mycket långt i framtiden (eller oändligt) och se till att det uppdateras regelbundet för att flytta det längre in i framtiden. Det finns en gräns på fem lagrade åtkomstprinciper per container.

  • Använd förfallotid inom kort på en ad hoc SAS-tjänst SAS eller konto-SAS. På så sätt, även om en SAS komprometteras, är den endast giltig under en kort tid. Den här metoden är särskilt viktig om du inte kan referera till en lagrad åtkomstprincip. Närtidsförfallotider begränsar också mängden data som kan skrivas till en blob genom att begränsa den tid som är tillgänglig för uppladdning till den.

  • Låt klienterna förnya SAS automatiskt om det behövs. Klienter bör förnya SAS i god tid före förfallodatumet för att ge tid för återförsök om tjänsten som tillhandahåller SAS inte är tillgänglig. Detta kan vara onödigt i vissa fall. Du kan till exempel ha för avsikt att SAS ska användas för ett litet antal omedelbara, kortvariga åtgärder. Dessa åtgärder förväntas slutföras inom förfalloperioden. Därför förväntar du dig inte att SAS förnyas. Men om du har en klient som rutinmässigt gör begäranden via SAS, kommer möjligheten att upphöra att gälla att gälla.

  • Var försiktig med SAS starttid. Om du anger starttiden för en SAS till aktuell tid kan fel uppstå tillfälligt under de första minuterna. Detta beror på att olika datorer har lite olika aktuella tider (kallas för klocksnedställning). I allmänhet anger du starttiden till minst 15 minuter tidigare. Eller ange det inte alls, vilket gör det giltigt omedelbart i alla fall. Samma sak gäller vanligtvis för förfallotid och - kom ihåg att du kan observera upp till 15 minuters klocksnedvridning i båda riktningarna på alla begäranden. För klienter som använder en REST-version före 2012-02-12 är den maximala varaktigheten för en SAS som inte refererar till en lagrad åtkomstprincip 1 timme. Alla principer som anger en längre tid än 1 timme misslyckas.

  • Var försiktig med SAS datetime-format. För vissa verktyg (till exempel AzCopy) måste datum/tid-värden formateras som "+%Y-%m-%dT%H:%M:%SZ". Det här formatet innehåller specifikt sekunderna.

  • Bevilja minst möjliga behörigheter med SAS. Bästa praxis för säkerhet är att ge en användare minsta nödvändiga behörighet till så få resurser som möjligt. Använd en skrivskyddad SAS när det är möjligt. Om en användare bara behöver läsåtkomst till ett enskilt objekt kan du ge dem läsbehörighet till det enskilda objektet och inte läsa/skriva/ta bort åtkomst till alla objekt. Detta hjälper också till att minska skadan om en SAS komprometteras eftersom SAS har mindre ström i händerna på en angripare.

    Det finns inget direkt sätt att identifiera vilka klienter som har åtkomst till en resurs. Du kan dock använda de unika fälten i SAS, de signerade IP-fälten (sip), signerade startfälten (st) och signerade förfallodatum (se) för att spåra åtkomst. Du kan till exempel generera en SAS-token med en unik förfallotid som du sedan kan korrelera med klienten som den utfärdades till.

  • Förstå att ditt konto debiteras för all användning, inklusive via en SAS. Om du ger skrivåtkomst till en blob kan en användare välja att ladda upp en 200 GB blob. Om du har gett dem läsåtkomst kan de välja att ladda ned den 10 gånger, vilket medför 2 TB i utgående kostnader åt dig. Ge återigen begränsade behörigheter för att minimera potentiella åtgärder från skadliga användare. Använd kortlivad SAS för att minska det här hotet (men tänk på klocksnedvridning på sluttiden).

  • Verifiera data som skrivits med hjälp av en SAS. När ett klientprogram skriver data till ditt lagringskonto bör du tänka på att det kan uppstå problem med dessa data. Om du planerar att verifiera data utför du verifieringen när data har skrivits och innan de används av ditt program. Den här metoden skyddar också mot att skadade eller skadliga data skrivs till ditt konto, antingen av en användare som har skaffat SAS korrekt eller av en användare som utnyttjar en läckt SAS.

  • Vet när du inte ska använda en SAS. Ibland överväger riskerna med en viss åtgärd mot ditt lagringskonto fördelarna med att använda en SAS. För sådana åtgärder skapar du en mellannivåtjänst som skriver till ditt lagringskonto när du har utfört validering, autentisering och granskning av affärsregler. Ibland är det också enklare att hantera åtkomst på andra sätt. Om du till exempel vill göra alla blobar i en container offentligt läsbara kan du göra containern offentlig i stället för att tillhandahålla en SAS till varje klient för åtkomst.

  • Använd Azure Monitor- och Azure Storage-loggar för att övervaka ditt program. Auktoriseringsfel kan inträffa på grund av ett avbrott i SAS-providertjänsten. De kan också uppstå vid oavsiktlig borttagning av en lagrad åtkomstprincip. Du kan använda Azure Monitor- och lagringsanalysloggning för att observera eventuella toppar i dessa typer av auktoriseringsfel. Mer information finns i Azure Storage-mått i Azure Monitor och Azure Lagringsanalys loggning.

  • Konfigurera en SAS-förfalloprincip för lagringskontot. Bästa praxis rekommenderar att du begränsar intervallet för en SAS om den skulle komprometteras. Genom att ange en SAS-förfalloprincip för dina lagringskonton kan du ange en rekommenderad övre förfallogräns när en användare skapar en tjänst-SAS eller ett konto-SAS. Mer information finns i Skapa en förfalloprincip för signaturer för delad åtkomst.

Kommentar

Storage spårar inte antalet signaturer för delad åtkomst som har genererats för ett lagringskonto, och inget API kan ange den här informationen. Om du behöver känna till antalet signaturer för delad åtkomst som har genererats för ett lagringskonto måste du spåra numret manuellt.

Kom igång med SAS

Information om hur du kommer igång med signaturer för delad åtkomst finns i följande artiklar för varje SAS-typ.

SAS för användardelegering

Tjänst-SAS

Konto-SAS

Nästa steg