Beperkte toegang verlenen tot Azure Storage-resources door middel van een SAS

Een Shared Access Signature (SAS) biedt beveiligde gedelegeerde toegang tot resources in uw opslagaccount. Met een SAS hebt u gedetailleerde controle over hoe een client toegang heeft tot uw gegevens. Bijvoorbeeld:

• Tot welke resources de client toegang heeft.

• Welke machtigingen ze hebben voor deze resources.

• Hoe lang de SAS geldig is.

Typen handtekeningen voor gedeelde toegang

Azure Storage ondersteunt drie typen handtekeningen voor gedeelde toegang:

• SAS voor gebruikersdelegering

• Service-SAS

• Account-SAS

SAS voor gebruikersdelegering

Een SAS voor gebruikersdelegering wordt beveiligd met Microsoft Entra-referenties en ook met de machtigingen die zijn opgegeven voor de SAS. Een SAS voor gebruikersdelegering is alleen van toepassing op Blob Storage.

Zie Een SAS voor gebruikersdelegatie maken (REST API) voor meer informatie over de SAS voor gebruikersdelegatie.

Service-SAS

Een service-SAS wordt beveiligd met de sleutel van het opslagaccount. Een service-SAS delegeert de toegang tot een resource in slechts één van de Azure Storage-services: Blob Storage, Queue Storage, Table Storage of Azure Files.

Zie Een service-SAS (REST API) maken voor meer informatie over de service-SAS.

Account-SAS

Een account-SAS wordt beveiligd met de sleutel van het opslagaccount. Een account-SAS delegeert toegang tot resources in een of meer van de opslagservices. Alle bewerkingen die beschikbaar zijn via een service of gebruikersdelegering-SAS, zijn ook beschikbaar via een account-SAS.

U kunt ook de toegang tot het volgende delegeren:

• Bewerkingen op serviceniveau (bijvoorbeeld de bewerkingen Get/Set Service Properties en Get Service Stats ).

• Lees-, schrijf- en verwijderbewerkingen die niet zijn toegestaan met een service-SAS.

Maak een account-SAS (REST API) voor meer informatie over de account-SAS.

Een handtekening voor gedeelde toegang kan een van de volgende twee vormen hebben:

• Ad hoc SAS. Wanneer u een ad-hoc-SAS maakt, worden de begintijd, verlooptijd en machtigingen opgegeven in de SAS-URI. Elk type SAS kan een ad-hoc-SAS zijn.

• Service-SAS met opgeslagen toegangsbeleid. Er wordt een opgeslagen toegangsbeleid gedefinieerd voor een resourcecontainer. Dit kan een blobcontainer, tabel, wachtrij of bestandsshare zijn. Het opgeslagen toegangsbeleid kan worden gebruikt voor het beheren van beperkingen voor een of meer handtekeningen voor gedeelde toegang van services. Wanneer u een service-SAS koppelt aan een opgeslagen toegangsbeleid, neemt de SAS de beperkingen over (de begintijd, verlooptijd en machtigingen) die zijn gedefinieerd voor het opgeslagen toegangsbeleid.

Hoe een Shared Access Signature werkt

Een handtekening voor gedeelde toegang is een token dat wordt toegevoegd aan de URI voor een Azure Storage-resource. Het token dat een speciale set queryparameters bevat die aangeven hoe de resources toegankelijk zijn voor de client. Een van de queryparameters, de handtekening, wordt samengesteld op basis van de SAS-parameters en ondertekend met de sleutel die is gebruikt om de SAS te maken. Deze handtekening wordt door Azure Storage gebruikt om toegang tot de opslagresource te autoriseren.

SAS-handtekening en -autorisatie

U kunt een SAS-token ondertekenen met een gebruikersdelegeringssleutel of met een opslagaccountsleutel (gedeelde sleutel).

Een SAS-token ondertekenen met een gebruikersdelegatiesleutel

U kunt een SAS-token ondertekenen met behulp van een gebruikersdelegeringssleutel die is gemaakt met behulp van Microsoft Entra-referenties. Een SAS voor gebruikersdelegering is ondertekend met de gebruikersdelegeringssleutel.

Als u de sleutel wilt ophalen en vervolgens de SAS wilt maken, moet aan een Microsoft Entra-beveiligingsprincipaal een Azure-rol worden toegewezen die de Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey actie bevat. Zie Een SAS voor gebruikersdelegatie maken (REST API) voor meer informatie.

Een SAS-token ondertekenen met een accountsleutel

Zowel een service-SAS als een account-SAS zijn ondertekend met de sleutel van het opslagaccount. Als u een SAS wilt maken die is ondertekend met de accountsleutel, moet een toepassing toegang hebben tot de accountsleutel.

Wanneer een aanvraag een SAS-token bevat, wordt die aanvraag geautoriseerd op basis van de wijze waarop dat SAS-token is ondertekend. De toegangssleutel of referenties die u gebruikt om een SAS-token te maken, worden ook door Azure Storage gebruikt om toegang te verlenen aan een client die de SAS bezit.

De volgende tabel geeft een overzicht van hoe elk type SAS-token is geautoriseerd.

Microsoft raadt het gebruik van een SAS voor gebruikersdelegering aan, indien mogelijk voor superieure beveiliging.

SAS-token

Het SAS-token is een tekenreeks die u aan de clientzijde genereert, bijvoorbeeld met behulp van een van de Azure Storage-clientbibliotheken. Het SAS-token wordt op geen enkele manier bijgehouden door Azure Storage. U kunt een onbeperkt aantal SAS-tokens maken aan de clientzijde. Nadat u een SAS hebt gemaakt, kunt u deze distribueren naar clienttoepassingen waarvoor toegang tot resources in uw opslagaccount is vereist.

Clienttoepassingen bieden de SAS-URI aan Azure Storage als onderdeel van een aanvraag. Vervolgens controleert de service de SAS-parameters en de handtekening om te controleren of deze geldig is. Als de service controleert of de handtekening geldig is, wordt de aanvraag geautoriseerd. Anders wordt de aanvraag geweigerd met foutcode 403 (Verboden).

Hier volgt een voorbeeld van een SAS-URI van de service, met de resource-URI, het scheidingsteken ('?') en het SAS-token.

Wanneer gebruikt u een handtekening voor gedeelde toegang

Gebruik een SAS om beveiligde toegang te verlenen tot resources in uw opslagaccount voor elke client die anders geen machtigingen heeft voor deze resources.

Een veelvoorkomend scenario waarbij een SAS nuttig is, is een service waarbij gebruikers hun eigen gegevens lezen en schrijven naar uw opslagaccount. In een scenario waarin een opslagaccount gebruikersgegevens opslaat, zijn er twee typische ontwerppatronen:

1. Clients uploaden en downloaden gegevens via een front-endproxyservice, waarmee verificatie wordt uitgevoerd. Met deze front-endproxyservice kunnen bedrijfsregels worden gevalideerd. Maar voor grote hoeveelheden gegevens of transacties met een groot volume kan het maken van een service die kan worden geschaald om aan de vraag te voldoen, duur of moeilijk kan zijn.

   

2. Met een eenvoudige service wordt de client indien nodig geverifieerd en vervolgens een SAS gegenereerd. Zodra de clienttoepassing de SAS ontvangt, heeft deze rechtstreeks toegang tot opslagaccountbronnen. Toegangsmachtigingen worden gedefinieerd door de SAS en voor het interval dat is toegestaan door de SAS. Dankzij de SAS hoeven alle gegevens niet via de front-endproxyservice te worden doorgestuurd.

   

Veel echte services kunnen een hybride van deze twee benaderingen gebruiken. Sommige gegevens kunnen bijvoorbeeld worden verwerkt en gevalideerd via de front-endproxy. Andere gegevens worden opgeslagen en/of rechtstreeks gelezen met behulp van SAS.

Daarnaast is een SAS vereist voor het autoriseren van toegang tot het bronobject in een kopieerbewerking in bepaalde scenario's:

• Wanneer u een blob kopieert naar een andere blob die zich in een ander opslagaccount bevindt.

  U kunt eventueel ook een SAS gebruiken om toegang tot de doel-blob te autoriseren.

• Wanneer u een bestand kopieert naar een ander bestand dat zich in een ander opslagaccount bevindt.

  U kunt desgewenst ook een SAS gebruiken om toegang tot het doelbestand te autoriseren.

• Wanneer u een blob kopieert naar een bestand of een bestand naar een blob.

  U moet een SAS gebruiken, zelfs als de bron- en doelobjecten zich in hetzelfde opslagaccount bevinden.

Best practices bij gebruik van SAS

Wanneer u handtekeningen voor gedeelde toegang in uw toepassingen gebruikt, moet u rekening houden met twee mogelijke risico's:

• Als een SAS wordt gelekt, kan deze worden gebruikt door iedereen die deze verkrijgt, waardoor uw opslagaccount mogelijk wordt aangetast.

• Als een SAS die aan een clienttoepassing is verstrekt, verloopt en de toepassing geen nieuwe SAS kan ophalen uit uw service, kan de functionaliteit van de toepassing worden belemmerd.

De volgende aanbevelingen voor het gebruik van handtekeningen voor gedeelde toegang kunnen helpen deze risico's te beperken:

• Gebruik altijd HTTPS om een SAS te maken of te distribueren. Als een SAS wordt doorgegeven via HTTP en onderschept, kan een aanvaller die een man-in-the-middle-aanval uitvoert de SAS lezen. Vervolgens kunnen ze die SAS gebruiken, net zoals de beoogde gebruiker zou kunnen hebben. Hierdoor kunnen gevoelige gegevens worden aangetast of kan gegevens beschadigd worden door de kwaadwillende gebruiker.

• Gebruik indien mogelijk een SAS voor gebruikersdelegering. Een SAS voor gebruikersdelegatie biedt superieure beveiliging voor een service-SAS of een account-SAS. Een SAS voor gebruikersdelegering is beveiligd met Microsoft Entra-referenties, zodat u uw accountsleutel niet hoeft op te slaan met uw code.

• Een intrekkingsplan hebben voor een SAS. Zorg ervoor dat u voorbereid bent om te reageren als een SAS is gecompromitteerd.

• Configureer een SAS-verloopbeleid voor het opslagaccount. Een SAS-verloopbeleid geeft een aanbevolen interval op waarvoor de SAS geldig is. Sas-verloopbeleid is van toepassing op een service-SAS of een account-SAS. Wanneer een gebruiker service-SAS of een account-SAS genereert met een geldigheidsinterval dat groter is dan het aanbevolen interval, zien ze een waarschuwing. Als Azure Storage-logboekregistratie met Azure Monitor is ingeschakeld, wordt er een vermelding naar de Azure Storage-logboeken geschreven. Zie Een verloopbeleid maken voor handtekeningen voor gedeelde toegang voor meer informatie.

• Maak een opgeslagen toegangsbeleid voor een service-SAS. Met opgeslagen toegangsbeleid kunt u machtigingen voor een service-SAS intrekken zonder dat u de sleutels van het opslagaccount opnieuw hoeft te genereren. Stel de vervaldatum in op deze zeer ver in de toekomst (of oneindig) en zorg ervoor dat deze regelmatig wordt bijgewerkt om deze verder in de toekomst te verplaatsen. Er geldt een limiet van vijf opgeslagen toegangsbeleidsregels per container.

• Gebruik bijna-termijnverlooptijden voor een AD-hoc SAS-service of account-SAS. Op deze manier, zelfs als een SAS is gecompromitteerd, is deze slechts een korte tijd geldig. Deze procedure is vooral belangrijk als u niet naar een opgeslagen toegangsbeleid kunt verwijzen. Bijna-termijnverlooptijden beperken ook de hoeveelheid gegevens die naar een blob kunnen worden geschreven door de tijd te beperken die beschikbaar is om ernaar te uploaden.

• Laat clients de SAS indien nodig automatisch vernieuwen. Clients moeten de SAS goed vernieuwen voordat de vervaldatum is verstreken, om tijd voor nieuwe pogingen mogelijk te maken als de service die de SAS levert niet beschikbaar is. Dit kan in sommige gevallen onnodig zijn. U kunt bijvoorbeeld voornemens zijn om de SAS te gebruiken voor een klein aantal directe bewerkingen met een korte levensduur. Deze bewerkingen worden naar verwachting binnen de verloopperiode voltooid. Als gevolg hiervan verwacht u niet dat de SAS wordt vernieuwd. Als u echter een client hebt die regelmatig aanvragen doet via SAS, komt de mogelijkheid van verlooptijd in het spel.

• Wees voorzichtig met de begintijd van SAS. Als u de begintijd voor een SAS instelt op de huidige tijd, kunnen fouten af en toe optreden voor de eerste paar minuten. Dit komt doordat verschillende machines iets verschillende huidige tijden hebben (ook wel klokverschil genoemd). Over het algemeen stelt u de begintijd in op ten minste 15 minuten in het verleden. Of stel deze helemaal niet in, waardoor het in alle gevallen onmiddellijk geldig wordt. Hetzelfde geldt over het algemeen ook voor de verlooptijd, en vergeet niet dat u maximaal 15 minuten van de klok scheeftrekken in beide richtingen op elk verzoek kunt observeren. Voor clients die een REST-versie gebruiken vóór 2012-02-12, is de maximale duur voor een SAS die niet verwijst naar een opgeslagen toegangsbeleid 1 uur. Beleidsregels die een langere termijn dan 1 uur opgeven, mislukken.

• Wees voorzichtig met de SAS-datum/tijd-indeling. Voor sommige hulpprogramma's (zoals AzCopy) moeten datum-/tijdwaarden worden opgemaakt als +%Y-%m-%dT%H:%M:%SZ. Deze indeling omvat specifiek de seconden.

• Verdeel de minst mogelijke bevoegdheden met de SAS. Een best practice voor beveiliging is om een gebruiker de minimale vereiste bevoegdheden te bieden voor de minste mogelijke resources. Gebruik indien mogelijk een alleen-lezen SAS. Als een gebruiker alleen leestoegang tot één object nodig heeft, verleent u ze leestoegang tot dat ene object en geen lees-/schrijf-/verwijdertoegang tot alle objecten. Dit helpt ook de schade te verminderen als een SAS wordt aangetast omdat de SAS minder vermogen heeft in handen van een aanvaller.

  Er is geen directe manier om te bepalen welke clients toegang hebben tot een resource. U kunt echter de unieke velden in de SAS, het ondertekende IP-adres (sip), de ondertekende begindatum (st) en de velden Voor hetse bijhouden van de toegang gebruiken om de toegang bij te houden. U kunt bijvoorbeeld een SAS-token genereren met een unieke verlooptijd die u vervolgens kunt correleren met de client aan wie het is uitgegeven.

• Begrijp dat uw account wordt gefactureerd voor elk gebruik, inclusief via een SAS. Als u schrijftoegang tot een blob opgeeft, kan een gebruiker ervoor kiezen om een blob van 200 GB te uploaden. Als u ze ook leestoegang hebt gegeven, kunnen ze ervoor kiezen deze 10 keer te downloaden, waardoor er 2 TB kosten voor uitgaand verkeer voor u in rekening worden gebracht. Geef nogmaals beperkte machtigingen op om de mogelijke acties van kwaadwillende gebruikers te beperken. Gebruik kortdurende SAS om deze bedreiging te verminderen (maar houd rekening met de scheeftrekken van de klok op de eindtijd).

• Valideer gegevens die zijn geschreven met behulp van een SAS. Wanneer een clienttoepassing gegevens naar uw opslagaccount schrijft, moet u er rekening mee houden dat er problemen kunnen zijn met die gegevens. Als u van plan bent om gegevens te valideren, moet u die validatie uitvoeren nadat de gegevens zijn geschreven en voordat deze door uw toepassing worden gebruikt. Deze procedure beschermt ook tegen beschadigde of schadelijke gegevens die naar uw account worden geschreven, hetzij door een gebruiker die de SAS correct heeft verkregen, of door een gebruiker die misbruik maakt van een gelekte SAS.

• Weet wanneer u geen SAS wilt gebruiken. Soms wegen de risico's voor een bepaalde bewerking tegen uw opslagaccount op tegen de voordelen van het gebruik van een SAS. Voor dergelijke bewerkingen maakt u een service in de middelste laag die naar uw opslagaccount schrijft nadat u bedrijfsregelvalidatie, verificatie en controle hebt uitgevoerd. Soms is het ook eenvoudiger om de toegang op andere manieren te beheren. Als u bijvoorbeeld alle blobs in een container openbaar leesbaar wilt maken, kunt u de container openbaar maken in plaats van een SAS aan elke client te verstrekken voor toegang.

• Gebruik Azure Monitor- en Azure Storage-logboeken om uw toepassing te bewaken. Autorisatiefouten kunnen optreden vanwege een storing in uw SAS-providerservice. Ze kunnen ook optreden bij een onbedoelde verwijdering van een opgeslagen toegangsbeleid. U kunt logboekregistratie van Azure Monitor en opslaganalyse gebruiken om eventuele pieken in deze typen autorisatiefouten te observeren. Zie metrische gegevens van Azure Storage in Azure Monitor en Azure Opslaganalyse logboekregistratie voor meer informatie.

• Configureer een SAS-verloopbeleid voor het opslagaccount. Aanbevolen procedures raden u aan om het interval voor een SAS te beperken voor het geval dit wordt aangetast. Door een SAS-verloopbeleid in te stellen voor uw opslagaccounts, kunt u een aanbevolen bovenverlooplimiet opgeven wanneer een gebruiker een service-SAS of een account-SAS maakt. Zie Een verloopbeleid maken voor handtekeningen voor gedeelde toegang voor meer informatie.

Aan de slag met SAS

Zie de volgende artikelen voor elk SAS-type om aan de slag te gaan met handtekeningen voor gedeelde toegang.

SAS voor gebruikersdelegering

• Een SAS voor gebruikersdelegering maken voor een container of blob met PowerShell
• Een SAS voor gebruikersdelegatie maken voor een container of blob met de Azure CLI
• Een SAS voor gebruikersdelegatie maken voor een container of blob met .NET

Service-SAS

• Een service-SAS maken voor een container of blob met .NET

Account-SAS

• Een account-SAS maken met .NET

Volgende stappen

• Toegang delegeren met een Shared Access Signature (REST API)
• Een SAS voor gebruikersdelegatie maken (REST API)
• Een SERVICE-SAS (REST API) maken
• Een ACCOUNT-SAS (REST API) maken