Best practices voor Azure Storage-beveiliging toepassen

  • 8 minuten

We hebben gelezen hoe u een Sas (Shared Access Signature) maakt en gebruikt en wat de voordelen zijn van uw opslagbeveiligingsoplossing.

Het is belangrijk om te weten dat wanneer u een SAS in uw toepassing gebruikt, er potentiële risico's kunnen zijn.

  • Als een SAS is gecompromitteerd, heeft iedereen die deze heeft verkregen toegang tot de opslag.

  • 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.

Bekijk deze video voor meer ideeën over het beveiligen van uw opslag. Deze video is gebaseerd op Azure Tips and Tricks #272 Azure Security Best Practices.

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. 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.
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.
Inzicht in facturering van accounts voor gebruik, inclusief een SAS Geef beperkte machtigingen om de mogelijke acties van kwaadwillende gebruikers te beperken. Lees- en schrijfmachtigingen kunnen factureringskosten veroorzaken. Gebruik een kortdurende SAS om deze bedreiging te verminderen.
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.
Uw toepassingen bewaken met Azure Opslaganalyse U kunt logboekregistratie en metrische gegevens gebruiken om eventuele pieken in verificatiefouten te observeren. Mogelijk ziet u pieken van een storing in uw SAS-providerservice of het onbedoeld verwijderen van een opgeslagen toegangsbeleid.