Handtekeningen voor gedeelde toegang maken

  • 5 minuten

Een Shared Access Signature (SAS) is een URI (Uniform Resource Identifier) die beperkte toegangsrechten verleent voor Azure Storage-resources. SAS is een veilige manier om uw opslagbronnen te delen zonder afbreuk te doen aan uw accountsleutels.

U kunt een SAS opgeven voor clients die geen toegang mogen hebben tot uw opslagaccountsleutel. Door een SAS-URI naar deze clients te distribueren, verleent u deze gedurende een opgegeven periode toegang tot een resource. Doorgaans gebruikt u een SAS voor een service waarbij gebruikers hun gegevens lezen en schrijven naar uw opslagaccount.

  • 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 wordt ondersteund voor Blob Storage en Data Lake Storage,

  • Een SAS op accountniveau om toegang te verlenen tot alles wat een SAS op serviceniveau kan toestaan, plus andere resources en mogelijkheden. U kunt bijvoorbeeld een SAS op accountniveau gebruiken om bestandssystemen te maken.

  • Een SAS op serviceniveau om toegang tot specifieke resources in een opslagaccount toe te staan. U gebruikt dit type SAS bijvoorbeeld om een app toe te staan een lijst met bestanden op te halen in een bestandssysteem of om een bestand te downloaden.

  • Een opgeslagen toegangsbeleid kan een ander beheerniveau bieden wanneer u een SAS op serviceniveau aan de serverzijde gebruikt. U kunt SAS's groeperen en andere beperkingen opgeven met behulp van een opgeslagen toegangsbeleid.

Aanbevelingen voor het beheren van risico's

Laten we eens kijken naar enkele aanbevelingen die u kunnen helpen bij het beperken van risico's bij het werken met een SAS.

Aanbeveling Beschrijving
Https altijd gebruiken voor het maken en distribueren Als een SAS wordt doorgegeven via HTTP en onderschept, kan een aanvaller de SAS onderscheppen en gebruiken. Deze man-in-the-middle-aanvallen kunnen gevoelige gegevens in gevaar komen of beschadiging van gegevens toestaan door de kwaadwillende gebruiker.
Waar mogelijk verwijzen naar opgeslagen toegangsbeleid Opgeslagen toegangsbeleid biedt u de mogelijkheid om machtigingen in te trekken zonder dat u de sleutels van het Azure-opslagaccount opnieuw hoeft te genereren. Stel de vervaldatum van de sleutel van het opslagaccount ver in de toekomst in.
Bijna-termijnverlooptijden instellen voor een niet-geplande SAS Als een SAS is aangetast, kunt u aanvallen beperken door de geldigheid van de SAS te beperken tot een korte tijd. Deze procedure is belangrijk als u niet kunt verwijzen naar een opgeslagen toegangsbeleid. Verlooptijden op korte termijn beperken ook de hoeveelheid data die naar een blob geschreven kan worden door de beschikbare tijd om ernaar te uploaden te beperken.
Clients automatisch vernieuwen van de SAS Vereisen dat uw clients de SAS-bron vóór de vervaldatum vernieuwen. Als u vroeg verlengt, kunt u tijd voor nieuwe pogingen toestaan als de service die de SAS levert niet beschikbaar is.
Zorgvuldig plannen voor de SAS-begintijd Als u de begintijd voor een SAS instelt op nu, worden fouten mogelijk af en toe waargenomen vanwege scheeftrekken van de klok (verschillen in de huidige tijd op basis van verschillende computers), kunnen fouten af en toe worden waargenomen voor de eerste paar minuten. Over het algemeen stelt u de begintijd in op ten minste 15 minuten in het verleden. Of stel geen specifieke begintijd in, waardoor de SAS in alle gevallen onmiddellijk geldig is. Dezelfde voorwaarden gelden over het algemeen voor de verlooptijd. U kunt tot 15 minuten van de klok scheeftrekken in beide richtingen op elk verzoek observeren. Voor clients die een REST API-versie gebruiken die ouder is dan 2012-02-12, is de maximale duur voor een SAS die niet verwijst naar een opgeslagen toegangsbeleid 1 uur. Beleidsregels die een langere termijn opgeven, mislukken.
Minimale toegangsmachtigingen voor resources definiëren Een aanbevolen beveiligingspraktijk is om een gebruiker de minimale vereiste bevoegdheden te bieden. Als een gebruiker alleen leestoegang tot één entiteit nodig heeft, verleent u ze leestoegang tot die ene entiteit en geen lees-/schrijf-/verwijdertoegang tot alle entiteiten. Deze praktijk helpt ook de schade te verminderen als een SAS wordt aangetast omdat de SAS minder vermogen heeft in handen van een aanvaller.
Gegevens valideren die zijn geschreven met behulp van een SAS Wanneer een clienttoepassing gegevens naar uw Azure-opslagaccount schrijft, moet u er rekening mee houden dat er problemen zijn met de gegevens. Als voor uw toepassing gevalideerde of geautoriseerde gegevens zijn vereist, valideert u de gegevens nadat deze zijn geschreven, maar voordat u deze hebt 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.
Stel niet dat een SAS altijd de juiste keuze is In sommige scenario's wegen de risico's die zijn gekoppeld aan een bepaalde bewerking voor uw Azure-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 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.