Beperkte toegang verlenen tot Azure Storage resources met behulp van Shared Access Signatures (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 shared access signatures:

• SAS voor gebruikersdelegatie

• Service-SAS

• ACCOUNT-SAS

SAS voor gebruikersdelegatie

Een SAS voor gebruikersdelegatie wordt beveiligd met Azure Active Directory referenties (Azure AD) en ook door de machtigingen die zijn opgegeven voor de SAS. Een SAS voor gebruikersdelegatie 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 SAS voor de service wordt beveiligd met de sleutel van het opslagaccount. Een SERVICE-SAS delegeert 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 maken (REST API) 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 sas voor service- of gebruikersdelegatie zijn ook beschikbaar via een account-SAS.

U kunt ook 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 aannemen:

• 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. Een opgeslagen toegangsbeleid wordt gedefinieerd in een resourcecontainer. Dit kan een blobcontainer, tabel, wachtrij of bestands share zijn. Het opgeslagen toegangsbeleid kan worden gebruikt voor het beheren van beperkingen voor een of meer handtekeningen voor gedeelde toegang van de service. Wanneer u een service-SAS koppelt aan een opgeslagen toegangsbeleid, neemt de SAS de beperkingen over van de begintijd, verlooptijd en machtigingen die zijn gedefinieerd voor het opgeslagen — — toegangsbeleid.

Hoe een Shared Access Signature werkt

Een Shared Access Signature is een ondertekende URI die naar een of meer opslagresources wijst. De URI bevat een token dat een speciale set queryparameters bevat. Het token geeft aan hoe de resources kunnen worden gebruikt door de client. Een van de queryparameters, de handtekening, is samengesteld uit de SAS-parameters en ondertekend met de sleutel die is gebruikt om de SAS te maken. Deze handtekening wordt gebruikt door Azure Storage toegang tot de opslagresource te verlenen.

SAS-handtekening en autorisatie

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

Een SAS-token ondertekenen met een sleutel voor gebruikersdelegatie

U kunt een SAS-token ondertekenen met behulp van een sleutel voor gebruikersdelegatie die is gemaakt met Azure Active Directory referenties (Azure AD). Een SAS voor gebruikersdelegatie is ondertekend met de sleutel voor gebruikersdelegatie.

Om de sleutel op te halen en vervolgens de SAS te maken, moet aan een Azure AD-beveiligingsprincipaal een Azure-rol worden toegewezen die de actie Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey 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 manier waarop dat SAS-token is ondertekend. De toegangssleutel of referenties die u gebruikt om een SAS-token te maken, worden ook gebruikt door Azure Storage om toegang te verlenen aan een client die de SAS bezit.

In de volgende tabel wordt samengevat hoe elk type SAS-token wordt geautoriseerd.

Microsoft raadt u aan om indien mogelijk een SAS voor gebruikersdelegatie te gebruiken voor een betere 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 Azure Storage bij te houden. U kunt een onbeperkt aantal SAS-tokens aan de clientzijde maken. Nadat u een SAS hebt aangemaakt, 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 zijn. Als de service controleert of de handtekening geldig is, wordt de aanvraag geautoriseerd. Anders wordt de aanvraag geweigerd met foutcode 403 (verboden).

Hier is een voorbeeld van een SAS-URI voor de service, met de resource-URI en het SAS-token. Omdat het SAS-token de URI-querytekenreeks bevat, moet de resource-URI eerst worden gevolgd door een vraagteken en vervolgens door het SAS-token:

Wanneer gebruikt u een Shared Access Signature?

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

Een veelvoorkomende situatie 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 hoog volume kan het maken van een service die kan worden geschaald om aan de vraag te voldoen duur of moeilijk 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 gebruikmaken van een hybride van deze twee benaderingen. 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 autoreren 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 autor toestemming te geven.

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

  U kunt eventueel ook een SAS gebruiken om toegang tot het doelbestand toe te staan.

• 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 binnen 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 in gevaar kan komen.

• Als een SAS die aan een clienttoepassing wordt geleverd, verloopt en de toepassing geen nieuwe SAS kan ophalen uit uw service, kan de functionaliteit van de toepassing worden beperkt.

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 wordt onderschept, kan een aanvaller die een man-in-the-middle-aanval uitvoeren, de SAS lezen. Vervolgens kunnen ze die SAS net als de beoogde gebruiker gebruiken. Hierdoor kunnen gevoelige gegevens in gevaar komen of gegevens worden aangetast door de kwaadwillende gebruiker.

• Gebruik waar mogelijk een SAS voor gebruikersdelegatie. Een SAS voor gebruikersdelegatie biedt een betere beveiliging dan een service-SAS of een account-SAS. Een SAS voor gebruikersdelegatie wordt beveiligd met Azure AD-referenties, zodat u uw accountsleutel niet met uw code hoeft op te slaan.

• Er is een intrekkingsplan voor een SAS. Zorg ervoor dat u voorbereid bent om te reageren als er met een SAS is geknoeed.

• Definieer een opgeslagen toegangsbeleid voor een service-SAS. Opgeslagen toegangsbeleid biedt u de mogelijkheid om machtigingen voor een service-SAS in te trekken zonder dat u de sleutels van het opslagaccount opnieuw moet maken. Stel de vervaldatum voor deze zeer ver in de toekomst (of oneindig) in en zorg ervoor dat deze regelmatig wordt bijgewerkt om deze verder naar de toekomst te verplaatsen.

• Gebruik verlooptijden op korte termijn voor een SAS- of account-SAS voor ad-hoc SAS-service of -account. Op deze manier is een SAS slechts een korte tijd geldig, zelfs als er met een SAS is geknoeed. Deze praktijk is vooral belangrijk als u niet kunt verwijzen naar een opgeslagen toegangsbeleid. Verlooptijden op korte termijn beperken ook de hoeveelheid gegevens die naar een blob kunnen worden geschreven door de beschikbare tijd te beperken om er naar te uploaden.

• Vraag clients zo nodig automatisch de SAS te vernieuwen. Clients moeten de SAS ruim vóór de vervaldatum vernieuwen, om tijd te bieden voor nieuwe proberen als de service die de SAS levert niet beschikbaar is. In sommige gevallen is dit mogelijk niet nodig. U wilt bijvoorbeeld dat de SAS wordt gebruikt voor een klein aantal onmiddellijke bewerkingen met een korte duur. 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 verloop in het spel.

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

• Wees voorzichtig met sas-datum/tijd-indeling. Voor sommige hulpprogramma's (zoals AzCopy) hebt u datum/tijd-indelingen nodig die '+%Y-%m-%dT%H:%M:%SZ' zijn. Deze indeling bevat specifiek de seconden.

• Wees specifiek voor de resource die moet worden gebruikt. Een beveiligingsrisico best practice is om een gebruiker de minimaal vereiste bevoegdheden te bieden. Als een gebruiker alleen leestoegang tot één entiteit nodig heeft, verleent u hem/haar leestoegang tot die ene entiteit en niet tot lees-/schrijf-/verwijdertoegang tot alle entiteiten. Dit helpt ook om de schade te beperken als een SAS wordt aangetast, omdat de SAS minder vermogen heeft in handen van een aanvaller.

• U moet er rekening mee houden dat uw account wordt gefactureerd voor elk gebruik, ook via een SAS. Als u schrijftoegang tot een blob biedt, kan een gebruiker ervoor kiezen om een blob van 200 GB te uploaden. Als u hen ook leestoegang hebt gegeven, kunnen ze ervoor kiezen om deze 10 keer te downloaden, wat 2 TB aan kosten voor het aantal uit te gaan kosten voor u met zich mee kan brengen. Geef opnieuw beperkte machtigingen op om de mogelijke acties van kwaadwillende gebruikers te beperken. Gebruik kortdende SAS om deze bedreiging te verminderen (maar let wel op scheefheid 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, voert u die validatie uit nadat de gegevens zijn geschreven en voordat deze door uw toepassing worden gebruikt. Deze praktijk beschermt ook tegen beschadigde of schadelijke gegevens die naar uw account worden geschreven, door een gebruiker die de SAS correct heeft verkregen of door een gebruiker die misbruik maakt van een gelekte SAS.

• Weten wanneer u geen SAS moet gebruiken. Soms wegen de risico's die gepaard gaan met een bepaalde bewerking met 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 na het uitvoeren van validatie, verificatie en controle van bedrijfsregels. Soms is het ook eenvoudiger om 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 leveren voor toegang.

• Gebruik Azure Monitor en Azure Storage om uw toepassing te bewaken. Autorisatiefouten kunnen optreden vanwege een storing in uw SAS-providerservice. Ze kunnen ook optreden als een opgeslagen toegangsbeleid per ongeluk wordt verwijderd. U kunt de Azure Monitor en logboekregistratie van opslaganalyse gebruiken om eventuele pieken in dit soort autorisatiefouten te observeren. Zie Metrische gegevens in Azure Storage en Azure Monitor analytics-logboekregistratie voor Azure Storage 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 gebruikersdelegatie

• Een SAS voor gebruikersdelegatie 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 maken (REST API)
• Een account-SAS maken (REST API)