Bevilja begränsad åtkomst till Azure Storage resurser med hjälp av signaturer för delad åtkomst (SAS)

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. Exempel:

• Vilka resurser klienten kan komma åt.

• Vilka behörigheter de har till dessa resurser.

• Hur länge SAS är giltig.

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 Azure Active Directory autentiseringsuppgifter (Azure AD) och även av de behörigheter som anges för SAS. En SAS för användardelegering gäller endast bloblagring.

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

Tjänst-SAS

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

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

Konto-SAS

En konto-SAS 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 en konto-SAS.

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

• Servicenivååtgärder (till exempel åtgärderna Hämta/ange tjänstegenskaper och Hämta tjänststatistik).

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

Mer information om kontots SAS finns i Skapa en konto-SAS (REST API).

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

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

• Tjänst-SAS med lagrad åtkomstprincip. En lagrad åtkomstprincip definieras i 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 signaturer för delad åtkomst för tjänsten. När du associerar en tjänst-SAS med en lagrad åtkomstprincip ärver SAS begränsningarna för starttid, förfallotid och behörigheter som definierats för den lagrade — — åtkomstprincipen.

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

En signatur för delad åtkomst är en signerad URI som pekar på en eller flera lagringsresurser. URI:en innehåller en token som innehåller en särskild uppsättning frågeparametrar. Token anger hur resurserna kan kommas åt av klienten. En av frågeparametrarna, signaturen, skapas från SAS-parametrarna och signeras med nyckeln som användes för att skapa SAS. Signaturen används av Azure Storage för att ge åtkomst till lagringsresursen.

SAS-signatur och auktorisering

Du kan signera en SAS-token med en nyckel för användardelegering 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 nyckel för användardelegering som har skapats med Azure Active Directory autentiseringsuppgifter (Azure AD). En SAS för användardelegering signeras med nyckeln för användardelegering.

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

Signera en SAS-token med en kontonyckel

Både en tjänst-SAS och en konto-SAS 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 auktoriserats 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:en.

I följande tabell sammanfattas hur varje typ av SAS-token auktoriserats.

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

SAS-token

SAS-token är en sträng som du genererar på klientsidan, till exempel genom att använda ett 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 för Azure Storage som en del av en begäran. Sedan kontrollerar tjänsten SAS-parametrarna och signaturen för att verifiera att den är giltig. Om tjänsten verifierar att signaturen är giltig godkänns begäran. Annars avvisas begäran med felkoden 403 (förbjudet).

Här är ett exempel på en SAS-URI för tjänsten som visar resurs-URI och SAS-token. Eftersom SAS-token består av URI-frågesträngen måste resurs-URI:en först följas av ett frågetecken och sedan av SAS-token:

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 inte annars 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 frontend-proxytjänsten gör det möjligt att validera 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.

   

2. En förenklad tjänst autentiserar klienten efter behov och genererar sedan en SAS. När klientprogrammet tar emot 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.

   

Många verkliga tjänster kan använda en hybrid av dessa två metoder. Till exempel kan vissa data bearbetas och valideras via frontend-proxyn. Andra data sparas och/eller läses 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äcks kan den användas av alla som får den, vilket 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 hjälpa dig 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 den SAS:en precis som den avsedda användaren. Detta kan potentiellt kompromettera känsliga data eller tillåta att data skadas av den skadliga användaren.

• Använd 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 en konto-SAS. En SAS för användardelegering skyddas med Azure AD-autentiseringsuppgifter, så att du inte behöver lagra din kontonyckel med din kod.

• Ha en återkallningsplan för en SAS. Se till att du är beredd att svara om en SAS komprometteras.

• Definiera en lagrad åtkomstprincip för en tjänst-SAS. Lagrade åtkomstprinciper ger dig möjlighet att återkalla behörigheter för en tjänst-SAS utan att behöva återskapa lagringskontonycklarna. Ange förfallotiden för dessa mycket långt i framtiden (eller oändligt) och se till att den uppdateras regelbundet för att flytta den längre fram i framtiden.

• Använd närtidsförfallotider på en ad hoc SAS-tjänst eller sas för konto. På så sätt är det bara giltigt under en kort tid även om en SAS komprometteras. Den här praxis ä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.

• Be klienterna att förnya SAS automatiskt om det behövs. Klienterna bör förnya SAS väl 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 i vissa fall vara onödigt. Du kanske till exempel vill 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 regelbundet gör begäranden via SAS kommer möjligheten att förfalla att gälla.

• Var försiktig med SAS-starttiden. Om du ställer in starttiden för en SAS på den aktuella tiden kan fel inträffa tillfälligt under de första minuterna. Detta beror på att olika datorer har något olika aktuella tider (kallas för klockskevna). I allmänhet anger du starttiden till minst 15 minuter tidigare. Eller ange den inte alls, vilket gör den giltig direkt i samtliga fall. Samma gäller vanligtvis även för förfallotid – kom ihåg att du kan observera upp till 15 minuters klockskevhet i båda riktningarna på alla förfrågningar. 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. Principer som anger en längre period än 1 timme kommer att misslyckas.

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

• Var specifik för den resurs som ska nås. En bra säkerhetspraxis är att ge en användare de lägsta behörigheter som krävs. Om en användare bara behöver läsbehörighet till en enda entitet ger du dem läsbehörighet till den enskilda entiteten och inte läs-/skriv-/borttagningsåtkomst till alla entiteter. Detta bidrar också till att minska skadorna om en SAS komprometteras eftersom SAS har mindre kraft i händerna på en angripare.

• 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 blob på 200 GB. Om du även har gett dem läsåtkomst kan de välja att ladda ned den 10 gånger, vilket medför 2 TB 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 var ihåg att klockan är sned vid sluttiden).

• Verifiera data som skrivits med hjälp av en SAS. Tänk på att det kan finnas problem med dessa data när ett klientprogram skriver data till ditt lagringskonto. Om du planerar att validera data utför du verifieringen när data har skrivits och innan de används av ditt program. Den här praxis skyddar också mot skadade eller skadliga data som skrivs till ditt konto, antingen av en användare som har köpt SAS på rätt sätt eller genom att en användare utnyttjar en läckt SAS.

• Veta när du inte ska använda en SAS. Ibland överväger riskerna som är associerade 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ärsregel. 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 för varje klient för åtkomst.

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

Kom igång med SAS

Om du vill komma igång med signaturer för delad åtkomst kan du läsa följande artiklar för varje SAS-typ.

SAS för användardelegering

• Skapa en SAS för användardelegering för en container eller blob med PowerShell
• Skapa en SAS för användardelegering för en container eller blob med Azure CLI
• Skapa en SAS för användardelegering för en container eller blob med .NET

Tjänst-SAS

• Skapa en tjänst-SAS för en container eller blob med .NET

Konto-SAS

• Skapa en konto-SAS med .NET

Nästa steg

• Delegera åtkomst med en signatur för delad åtkomst (REST API)
• Skapa en SAS för användardelegering (REST API)
• Skapa en SAS för tjänsten (REST API)
• Skapa en konto-SAS (REST API)