Skapa signaturer för delad åtkomst

  • 5 minuter

En signatur för delad åtkomst (SAS) är en enhetlig resursidentifierare (URI) som ger begränsad åtkomstbehörighet till Azure Storage-resurser. SAS är ett säkert sätt att dela dina lagringsresurser utan att äventyra dina kontonycklar.

Du kan ange en SAS till klienter som inte ska ha åtkomst till din lagringskontonyckel. Genom att distribuera en SAS-URI till dessa klienter ger du dem åtkomst till en resurs under en angiven tidsperiod. Du använder vanligtvis en SAS för en tjänst där användare läser och skriver sina data till ditt lagringskonto.

  • En SAS för användardelegering skyddas med Microsoft Entra-autentiseringsuppgifter och av behörigheterna som angetts för SAS. En användardelegerings-SAS stöds för Blob Storage och Data Lake Storage.

  • En SAS på kontonivå som ger åtkomst till allt som en SAS på servicenivå kan tillåta, plus andra resurser och förmågor. Du kan till exempel använda en SAS på kontonivå för att tillåta möjligheten att skapa filsystem.

  • En SAS på tjänstnivå för att tillåta åtkomst till specifika resurser i ett lagringskonto. Du skulle till exempel använda den här typen av SAS för att tillåta att en app hämtar en lista över filer i ett filsystem eller för att ladda ned en fil.

  • En lagrad åtkomstprincip kan ge en annan kontrollnivå när du använder en SAS på tjänstnivå på serversidan. Du kan gruppera SAS och ange andra begränsningar med hjälp av en lagrad åtkomstprincip.

Rekommendationer för att hantera risker

Nu ska vi titta på några rekommendationer som kan bidra till att minska riskerna när du arbetar med en SAS.

Rekommendation Beskrivning
Använd alltid HTTPS för att skapa och distribuera Om en SAS skickas via HTTP och fångas upp kan en angripare fånga upp och använda SAS. Dessa man-in-the-middle-attacker kan kompromettera känsliga data eller leda till datakorruption av den skadliga användaren.
Referera till lagrade åtkomstprinciper där det är möjligt Med lagrade åtkomstprinciper kan du återkalla behörigheter utan att behöva återskapa Azure Storage-kontonycklarna. Ange förfallodatum för lagringskontonyckeln långt i framtiden.
Ange kortfristiga förfallotider för en oplanerad SAS Om en SAS komprometteras kan du minimera attacker genom att begränsa SAS-giltigheten till en kort tid. Den här metoden är 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.
Kräv att klienter förnyar SAS automatiskt Kräv att dina klienter förnyar SAS långt före förfallodatumet. Genom att förnya tidigt ger du tid för återförsök om tjänsten som tillhandahåller SAS inte är tillgänglig.
Planera noggrant för SAS-starttiden Om du anger starttiden för en SAS till nu kan fel observeras tillfälligt under de första minuterna på grund av klocksnedvridning (skillnader i aktuell tid enligt olika datorer). I allmänhet anger du starttiden till minst 15 minuter tidigare. Eller ange inte en specifik starttid, vilket gör att SAS är giltigt omedelbart i alla fall. Samma villkor gäller vanligtvis för förfallotiden. Du kan se upp till 15 minuters klocksnedställning i båda riktningarna på alla begäranden. För klienter som använder en REST API-version tidigare än 2012-02-12 är den maximala varaktigheten för en SAS som inte refererar till en lagrad åtkomstprincip 1 timme. Principer som anger ett mer långsiktigt fel.
Definiera minsta åtkomstbehörigheter för resurser Bästa praxis för säkerhet är att ge en användare de lägsta behörigheter som krävs. Om en användare bara behöver läsåtkomst till en enda entitet ger du dem läsbehörighet till den enskilda entiteten och inte läs-/skriv-/borttagningsåtkomst till alla entiteter. Den här metoden hjälper också till att minska skadan om en SAS komprometteras eftersom SAS har mindre ström i händerna på en angripare.
Verifiera data som skrivits med hjälp av en SAS När ett klientprogram skriver data till ditt Azure Storage-konto bör du tänka på att det kan uppstå problem med data. Om programmet kräver verifierade eller auktoriserade data verifierar du data efter att de har skrivits, men innan de används. 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.
Anta inte att en SAS alltid är rätt val I vissa scenarier uppväger riskerna med en viss åtgärd mot ditt Azure Storage-konto 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 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.