Opprett signaturer for delt tilgang

  • 5 minutter

En delt tilgangssignatur (SAS) er en ensartet ressursidentifikator (URI) som gir begrensede tilgangsrettigheter til Azure Storage-ressurser. SAS er en sikker måte å dele lagringsressursene dine på, uten å gå på akkord med kontonøklene.

Du kan gi en SAS til klienter som ikke skal ha tilgang til lagringskontonøkkelen. Ved å distribuere en SAS-URI til disse klientene, gir du dem tilgang til en ressurs i en angitt tidsperiode. Du vil vanligvis bruke en SAS for en tjeneste der brukere leser og skriver dataene sine til lagringskontoen.

  • En brukerdelegering sas er sikret med Microsoft Entra legitimasjon og også av tillatelsene som er angitt for SAS. En brukerdelegering sas støttes for Blob Storage og Data Lake Storage,

  • Et sas på kontonivå for å gi tilgang til alt som et sas på tjenestenivå kan tillate, i tillegg til andre ressurser og evner. Du kan for eksempel bruke en SAS på kontonivå for å gi mulighet til å opprette filsystemer.

  • Et sas på tjenestenivå for å gi tilgang til bestemte ressurser i en lagringskonto. Du vil for eksempel bruke denne typen SAS til å tillate en app å hente en liste over filer i et filsystem, eller for å laste ned en fil.

  • En lagret tilgangspolicy kan gi et annet kontrollnivå når du bruker et sas på tjenestenivå på serversiden. Du kan gruppere SAS-er og gi andre begrensninger ved hjelp av en lagret tilgangspolicy.

Anbefalinger for å håndtere risikoer

La oss se på noen anbefalinger som kan bidra til å redusere risikoen når du arbeider med en SAS.

Anbefaling Beskrivelse
Bruk alltid HTTPS for oppretting og distribusjon Hvis en SAS sendes over HTTP og fanges opp, kan en angriper fange opp og bruke SAS. Disse mann-i-midten angrep kan kompromittere sensitive data eller tillate datakorrupsjon av den ondsinnede brukeren.
Referere til lagrede tilgangspolicyer der det er mulig Lagrede tilgangspolicyer gir deg muligheten til å tilbakekalle tillatelser uten å måtte generere azure-lagringskontonøklene på nytt. Angi utløpsdatoen for lagringskontonøkkelen langt i fremtiden.
angi utløpstider på kort sikt for en ikke-planlagt SAS- Hvis en SAS er kompromittert, kan du redusere angrep ved å begrense SAS-gyldigheten til kort tid. Denne praksisen er viktig hvis du ikke kan referere til en lagret tilgangspolicy. Utløpstider på kort sikt begrenser også mengden data som kan skrives til en blob, ved å begrense tiden som er tilgjengelig for opplasting til den.
Krev at klienter fornyer SAS- automatisk Krev at kundene fornyer SAS i god tid før utløpsdatoen. Ved å fornye tidlig, gir du tid til nye forsøk hvis tjenesten som leverer SAS, ikke er tilgjengelig.
Planlegg nøye for sas starttidspunkt Hvis du angir starttidspunktet for en SAS til nå, så på grunn av klokkespyd (forskjeller i gjeldende tid i henhold til forskjellige maskiner), kan feil bli observert midlertidig de første minuttene. Generelt sett starttidspunktet til minst 15 minutter tidligere. Eller ikke angi et bestemt starttidspunkt, noe som fører til at SAS er gyldig umiddelbart i alle tilfeller. De samme betingelsene gjelder vanligvis for utløpstiden. Du kan observere opptil 15 minutter med klokkespyd i begge retninger på alle forespørsler. For klienter som bruker en REST-API-versjon tidligere enn 2012-02-12, er maksimal varighet for en SAS som ikke refererer til en lagret tilgangspolicy, 1 time. Policyer som angir en lengre periode, mislykkes.
Definer minimum tilgangstillatelser for ressurser En anbefalt fremgangsmåte for sikkerhet er å gi en bruker minimum nødvendige rettigheter. Hvis en bruker bare trenger lesetilgang til én enkelt enhet, kan du gi dem lesetilgang til den ene enheten, og ikke lese/skrive/slette tilgang til alle enheter. Denne praksisen bidrar også til å redusere skaden hvis en SAS er kompromittert fordi SAS har mindre strøm i hendene på en angriper.
Valider data skrevet ved hjelp av en SAS- Når et klientprogram skriver data til Azure-lagringskontoen, må du huske på at det kan være problemer med dataene. Hvis programmet krever validerte eller autoriserte data, validerer du dataene etter at de er skrevet, men før bruk. Denne praksisen beskytter også mot at skadede eller skadelige data blir skrevet til kontoen din, enten av en bruker som anskaffet SAS på riktig måte, eller av en bruker som utnyttet en lekket SAS.
Ikke anta at sas alltid er det riktige valget I noen scenarioer oppveier risikoen forbundet med en bestemt operasjon mot Azure-lagringskontoen fordelene ved å bruke en SAS. For slike operasjoner kan du opprette en mellomnivåtjeneste som skriver til lagringskontoen etter at du har utført validering, godkjenning og revisjon av forretningsregler. Noen ganger er det også enklere å administrere tilgang på andre måter. Hvis du vil gjøre alle blober i en beholder offentlig lesbar, kan du gjøre beholderen offentlig, i stedet for å gi en SAS til hver klient for tilgang.