Opslagaccounts en betrouwbaarheid

Azure Storage-accounts zijn ideaal voor werkbelastingen die snelle en consistente reactietijden vereisen of die een groot aantal IOP-bewerkingen (Input Output) per seconde hebben. Opslagaccounts bevatten al uw Azure Storage-gegevensobjecten, waaronder:

• Blobs
• Bestandsshares
• Wachtrijen
• Tabellen
• Disks

Opslagaccounts bieden een unieke naamruimte voor uw gegevens die overal toegankelijk zijn via HTTP of HTTPS.

Raadpleeg Typen opslagaccounts voor meer informatie over de verschillende typen opslagaccounts die ondersteuning bieden voor verschillende functies.

Raadpleeg de volgende artikelen om te begrijpen hoe een Azure-opslagaccount ondersteuning biedt voor tolerantie voor uw toepassingsworkload:

• Azure Storage-redundantie
• Herstel na noodgeval en failover van opslagaccount

De volgende secties bevatten ontwerpoverwegingen, een configuratiecontrolelijst en aanbevolen configuratieopties die specifiek zijn voor Azure-opslagaccounts en betrouwbaarheid.

Overwegingen bij het ontwerpen

Azure Storage-accounts bevatten de volgende ontwerpoverwegingen:

• Opslagaccounts voor algemeen gebruik v1 bieden toegang tot alle Azure Storage-services, maar hebben mogelijk niet de nieuwste functies of de lagere prijzen per gigabyte. Het wordt aanbevolen om in de meeste gevallen v2-opslagaccounts voor algemeen gebruik te gebruiken. Redenen om v1 te gebruiken zijn onder andere:

  • Voor toepassingen is het klassieke implementatiemodel vereist.
  • Toepassingen zijn transactie-intensief of gebruiken aanzienlijke bandbreedte voor geo-replicatie, maar vereisen geen grote capaciteit.
  • Het gebruik van een Storage Service REST API die ouder is dan 14 februari 2014, of een clientbibliotheek met een versie ouder dan 4.x vereist is. Een toepassingsupgrade is niet mogelijk.

Raadpleeg het Overzicht van opslagaccounts voor meer informatie.

• Namen van opslagaccounts moeten tussen drie en 24 tekens bevatten en mogen alleen cijfers en kleine letters bevatten.
• Raadpleeg SLA voor opslagaccounts voor de huidige SLA-specificaties.
• Ga naar Azure Storage-redundantie om te bepalen welke redundantieoptie het beste is voor een specifiek scenario.
• Namen van opslagaccounts moeten uniek zijn binnen Azure. Een opslagaccount kan niet dezelfde naam hebben als een ander opslagaccount.

Controlelijst

Hebt u uw Azure Storage-account geconfigureerd met het oog op betrouwbaarheid?

• Schakel voorlopig verwijderen voor blobgegevens in.
• Gebruik Microsoft Entra-id om toegang tot blobgegevens te autoriseren.
• Houd rekening met het principe van minimale bevoegdheden wanneer u machtigingen toewijst aan een Microsoft Entra beveiligingsprincipal via Azure RBAC.
• Beheerde identiteiten gebruiken voor toegang tot blob- en wachtrijgegevens.
• Gebruik blobversiebeheer of onveranderbare blobs om bedrijfskritieke gegevens op te slaan.
• Standaard internettoegang voor opslagaccounts beperken.
• Firewallregels inschakelen.
• Beperk de netwerktoegang tot specifieke netwerken.
• Vertrouwde Microsoft-services toegang geven tot het opslagaccount.
• Schakel de optie Veilige overdracht vereist in voor al uw opslagaccounts.
• Beperk SAS-tokens (Shared Access Signature) alleen tot HTTPS verbindingen.
• Vermijd en voorkom het gebruik van gedeelde sleutelautorisatie voor toegang tot opslagaccounts.
• Uw accountsleutels periodiek opnieuw genereren.
• Maak een intrekkingsplan en zorg ervoor dat dit is ingesteld voor elke SAS die u aan clients uitgeeft.
• Gebruik verlooptijden op korte termijn voor een ongeplande SAS, service-SAS of account-SAS.

Aanbevelingen voor configuratie

Houd rekening met de volgende aanbevelingen om de betrouwbaarheid te optimaliseren bij het configureren van uw Azure Storage-account:

Aanbeveling	Beschrijving
Schakel voorlopig verwijderen voor blobgegevens in.	Met voorlopig verwijderen voor Azure Storage-blobs kunt u blobgegevens herstellen nadat deze zijn verwijderd.
Gebruik Microsoft Entra-id om toegang tot blobgegevens te autoriseren.	Microsoft Entra-id biedt superieure beveiliging en gebruiksgemak ten opzichte van gedeelde sleutel voor het autoriseren van aanvragen voor blobopslag. Het is raadzaam om waar mogelijk Microsoft Entra autorisatie te gebruiken met uw blob- en wachtrijtoepassingen om potentiële beveiligingsproblemen die inherent zijn aan gedeelde sleutel te minimaliseren. Raadpleeg Toegang tot Azure-blobs en wachtrijen autoriseren met behulp van Microsoft Entra-id voor meer informatie.
Houd rekening met het principe van minimale bevoegdheden wanneer u machtigingen toewijst aan een Microsoft Entra beveiligingsprincipal via Azure RBAC.	Wanneer u een rol toewijst aan een gebruiker, groep of toepassing, verleent u die beveiligingsprincipal alleen de machtigingen die nodig zijn om hun taken uit te voeren. Door de toegang tot resources te beperken, voorkomt u zowel onbedoeld als kwaadwillig misbruik van uw gegevens.
Beheerde identiteiten gebruiken voor toegang tot blob- en wachtrijgegevens.	Azure Blob en Queue Storage ondersteunen Microsoft Entra verificatie met beheerde identiteiten voor Azure-resources. Beheerde identiteiten voor Azure-resources kunnen toegang tot blob- en wachtrijgegevens autoriseren met behulp van Microsoft Entra referenties van toepassingen die worden uitgevoerd in virtuele Azure-machines (VM's), functie-apps, virtuele-machineschaalsets en andere services. Door beheerde identiteiten voor Azure-resources te gebruiken in combinatie met Microsoft Entra-verificatie, kunt u voorkomen dat referenties worden opgeslagen met uw toepassingen die worden uitgevoerd in de cloud en problemen met verlopende service-principals. Raadpleeg Toegang tot blob- en wachtrijgegevens autoriseren met beheerde identiteiten voor Azure-resources voor meer informatie.
Gebruik blobversiebeheer of onveranderbare blobs om bedrijfskritieke gegevens op te slaan.	Overweeg het gebruik van Blob-versiebeheer om eerdere versies van een object te onderhouden of het gebruik van juridische bewaring en bewaarbeleid op basis van tijd om blobgegevens op te slaan in een WORM-status (Eenmaal schrijven, Veel lezen). Onveranderbare blobs kunnen worden gelezen, maar kunnen niet worden gewijzigd of verwijderd tijdens het retentie-interval. Raadpleeg Bedrijfskritieke blobgegevens opslaan met onveranderbare opslag voor meer informatie.
Standaard internettoegang voor opslagaccounts beperken.	Standaard is de netwerktoegang tot opslagaccounts niet beperkt en is deze open voor al het verkeer dat afkomstig is van internet. Toegang tot opslagaccounts moet alleen worden verleend aan specifieke Virtuele Azure-netwerken indien mogelijk of privé-eindpunten gebruiken om clients in een virtueel netwerk (VNet) veilig toegang te geven tot gegevens via een Private Link. Raadpleeg Privé-eindpunten gebruiken voor Azure Storage voor meer informatie. Er kunnen uitzonderingen worden gemaakt voor opslagaccounts die toegankelijk moeten zijn via internet.
Firewallregels inschakelen.	Configureer firewallregels om de toegang tot uw opslagaccount te beperken tot aanvragen die afkomstig zijn van opgegeven IP-adressen of bereiken, of van een lijst met subnetten in een Azure Virtual Network (VNet). Raadpleeg Azure Storage-firewalls en virtuele netwerken configureren voor meer informatie over het configureren van firewallregels.
Beperk de netwerktoegang tot specifieke netwerken.	Als u de netwerktoegang beperkt tot netwerken die clients hosten die toegang nodig hebben, vermindert u de blootstelling van uw resources aan netwerkaanvallen door gebruik te maken van de ingebouwde firewall- en virtuele netwerkfunctionaliteit of door gebruik te maken van privé-eindpunten.
Vertrouwde Microsoft-services toegang geven tot het opslagaccount.	Als u firewallregels voor opslagaccounts inschakelt, worden binnenkomende aanvragen voor gegevens standaard geblokkeerd, tenzij de aanvragen afkomstig zijn van een service die werkt binnen een Azure Virtual Network (VNet) of van toegestane openbare IP-adressen. Geblokkeerde aanvragen omvatten aanvragen van andere Azure-services, van de Azure Portal, van services voor logboekregistratie en metrische gegevens, enzovoort. U kunt aanvragen van andere Azure-services toestaan door een uitzondering toe te voegen om vertrouwde Microsoft-services toegang te geven tot het opslagaccount. Raadpleeg Firewalls en virtuele netwerken voor Azure Storage configureren voor meer informatie over het toevoegen van een uitzondering voor vertrouwde Microsoft-services.
Schakel de optie Veilige overdracht vereist in voor al uw opslagaccounts.	Wanneer u de optie Veilige overdracht vereist inschakelt, moeten alle aanvragen voor het opslagaccount worden uitgevoerd via beveiligde verbindingen. Aanvragen die via HTTP worden gedaan, mislukken. Raadpleeg Veilige overdracht vereisen in Azure Storage voor meer informatie.
Beperk SAS-tokens (Shared Access Signature) alleen tot HTTPS verbindingen.	Als HTTPS een client een SAS-token gebruikt om toegang te krijgen tot blobgegevens, wordt het risico op afluisteren geminimaliseerd. Raadpleeg Beperkte toegang verlenen tot Azure Storage-resources met sas (Shared Access Signatures) voor meer informatie.
Vermijd en voorkom het gebruik van gedeelde sleutelautorisatie voor toegang tot opslagaccounts.	Het wordt aanbevolen om Microsoft Entra-id te gebruiken om aanvragen voor Azure Storage te autoriseren en om autorisatie van gedeelde sleutels te voorkomen. Voor scenario's waarvoor autorisatie van gedeelde sleutels is vereist, geeft u altijd de voorkeur aan SAS-tokens boven het distribueren van de gedeelde sleutel.
Uw accountsleutels periodiek opnieuw genereren.	Door de accountsleutels periodiek te roteren, vermindert u het risico dat uw gegevens worden blootgesteld aan kwaadwillende actoren.
Maak een intrekkingsplan en zorg ervoor dat dit is ingesteld voor elke SAS die u aan clients uitgeeft.	Als een SAS is gecompromitteerd, moet u die SAS onmiddellijk intrekken. Als u een SAS voor gebruikersdelegatie wilt intrekken, trekt u de sleutel voor gebruikersdelegatie in om snel alle handtekeningen die aan die sleutel zijn gekoppeld, ongeldig te maken. Als u een service-SAS wilt intrekken die is gekoppeld aan een opgeslagen toegangsbeleid, kunt u het opgeslagen toegangsbeleid verwijderen, de naam van het beleid wijzigen of de verlooptijd wijzigen in een tijd die in het verleden ligt.
Gebruik verlooptijden op korte termijn voor een ongeplande SAS, service-SAS of account-SAS.	Als een SAS is gecompromitteerd, is deze slechts kort geldig. Deze procedure is vooral belangrijk als u niet kunt verwijzen naar een opgeslagen toegangsbeleid. Met verlooptijden op korte termijn wordt ook de hoeveelheid gegevens beperkt die naar een blob kan worden geschreven door de tijd te beperken die beschikbaar is om naar de blob te uploaden. Clients moeten de SAS ruim voor de vervaldatum vernieuwen, zodat er tijd is voor nieuwe pogingen als de service die de SAS levert niet beschikbaar is.

Volgende stap

Opslagaccounts en beveiliging