Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Azure Storage ondersteunt het gebruik van Microsoft Entra ID om aanvragen voor blobgegevens te autoriseren. Met behulp van Microsoft Entra ID kunt u Azure op rollen gebaseerd toegangsbeheer (Azure RBAC) gebruiken om machtigingen te verlenen aan een beveiligingsprincipaal, dat een gebruiker, groep of toepassingsservice-principal kan zijn. Microsoft Entra ID verifieert de beveiligingsprincipaal en retourneert een OAuth 2.0-token. Gebruik het token om een verzoek bij de Blob-service te autoriseren.
U kunt Microsoft Entra ID-autorisatie gebruiken met alle accounts voor algemeen gebruik en Blob Storage in alle openbare regio's en nationale clouds. Alleen opslagaccounts die zijn gemaakt met behulp van het Azure Resource Manager-implementatiemodel ondersteunen Microsoft Entra autorisatie.
Belangrijk
Voor optimale beveiliging raadt Microsoft aan om Microsoft Entra ID met beheerde identiteiten te gebruiken om aanvragen te autoriseren voor blob-, wachtrij- en tabelgegevens, indien mogelijk. Autorisatie met Microsoft Entra ID en beheerde identiteiten biedt superieure beveiliging en gebruiksgemak ten opzichte van autorisatie van gedeelde sleutels. Zie Wat zijn beheerde identiteiten voor Azure-resources voor meer informatie over beheerde identiteiten. Voor een voorbeeld van hoe u een beheerde identiteit inschakelt en gebruikt voor een .NET-toepassing, raadpleegt u Authenticatie van door Azure gehoste apps naar Azure-resources met .NET.
Voor resources die buiten Azure worden gehost, zoals on-premises toepassingen, kunt u beheerde identiteiten gebruiken via Azure Arc. Apps die worden uitgevoerd op servers met Azure Arc kunnen bijvoorbeeld beheerde identiteiten gebruiken om verbinding te maken met Azure-services. Zie voor meer informatie Verifiëren bij Azure-resources met Azure Arc-ingeschakelde servers.
Voor scenario's waarin SHARED Access Signatures (SAS) worden gebruikt, raadt Microsoft aan een SAS voor gebruikersdelegering te gebruiken. Een SAS voor gebruikersdelegering wordt beveiligd met Microsoft Entra-referenties in plaats van de accountsleutel. Zie voor meer informatie over handtekeningen voor gedeelde toegang Beperkte toegang verlenen tot gegevens met handtekeningen voor gedeelde toegang. Zie Een SAS voor gebruikersdelegering maken en gebruiken met .NET voor een voorbeeld van het maken en gebruiken van een SAS voor gebruikersdelegatie voor een blob met .NET.
Overzicht van Microsoft Entra-id voor blobs
Wanneer een beveiligingsprincipaal (een gebruiker, groep of toepassing) toegang probeert te krijgen tot een blobresource, moet de aanvraag worden geautoriseerd, tenzij deze een blob is die beschikbaar is voor anonieme toegang. Met behulp van Microsoft Entra ID is de toegang tot een resource een proces in twee stappen:
Eerst wordt de identiteit van de beveiligingsprincipaal geverifieerd en wordt een OAuth 2.0-token geretourneerd.
Voor de verificatiestap is vereist dat een toepassing tijdens runtime een OAuth 2.0-toegangstoken aanvraagt. Als een toepassing wordt uitgevoerd vanuit een Azure-entiteit zoals een Azure-VM, een virtuele-machineschaalset of een Azure Functions-app, kan deze een beheerde identiteit gebruiken om toegang te krijgen tot blobgegevens.
Vervolgens wordt het token doorgegeven als onderdeel van een aanvraag aan de Blob-service en de service gebruikt het om toegang tot de opgegeven resource te autoriseren.
Voor de autorisatiestap moet een of meer Azure RBAC-rollen worden toegewezen aan de beveiligingsprincipaal die de aanvraag indient. Zie Azure-rollen toewijzen voor toegangsrechten voor meer informatie.
Een Microsoft Entra-account gebruiken met portal, PowerShell of Azure CLI
Zie Gegevenstoegang vanuit de Azure-portal voor meer informatie over het openen van gegevens in de Azure-portal met behulp van een Microsoft Entra-account. Zie
Microsoft Entra-id gebruiken om toegang in toepassingscode te autoriseren
Als u toegang tot Azure Storage wilt autoriseren met behulp van Microsoft Entra ID, gebruikt u een van de volgende clientbibliotheken om een OAuth 2.0-token te verkrijgen:
- De Azure Identity-clientbibliotheek wordt aanbevolen voor de meeste ontwikkelscenario's.
- De Microsoft Authentication Library (MSAL) is mogelijk geschikt voor bepaalde geavanceerde scenario's.
Azure Identity-clientbibliotheek
De Azure Identity-clientbibliotheek vereenvoudigt het proces van het ophalen van een OAuth 2.0-toegangstoken voor autorisatie met behulp van Microsoft Entra ID via de Azure SDK. De nieuwste versies van de Azure Storage-clientbibliotheken voor .NET, Java, Python, JavaScript en Go kunnen worden geïntegreerd met de Azure Identity-bibliotheken voor elk van deze talen om een eenvoudig en veilig manier te bieden om een toegangstoken te verkrijgen voor autorisatie van Azure Storage aanvragen.
Een voordeel van de Azure Identity-clientbibliotheek is dat u dezelfde code kunt gebruiken om het toegangstoken te verkrijgen, ongeacht of uw toepassing wordt uitgevoerd in de ontwikkelomgeving of in Azure. De Azure Identity-clientbibliotheek retourneert een toegangstoken voor een security principal. Wanneer uw code wordt uitgevoerd in Azure, kan de beveiligingsprincipaal een beheerde identiteit zijn voor Azure-resources, een service-principal of een gebruiker of groep. In de ontwikkelomgeving biedt de clientbibliotheek een toegangstoken voor een gebruiker of een service-principal voor testdoeleinden.
Het toegangstoken dat door de Azure Identity-clientbibliotheek wordt geretourneerd, wordt ingekapseld in een tokenreferentie. Vervolgens kunt u de tokenreferentie gebruiken om een serviceclientobject op te halen voor gebruik bij het uitvoeren van geautoriseerde bewerkingen voor Azure Storage. Een eenvoudige manier om het toegangstoken en de tokenreferentie op te halen, is door de klasse DefaultAzureCredential te gebruiken die de Azure Identity-clientbibliotheek biedt. DefaultAzureCredential probeert de tokenreferentie op te halen door opeenvolgend verschillende referentietypen te proberen. DefaultAzureCredential werkt in zowel de ontwikkelomgeving als in Azure.
De volgende tabel verwijst naar aanvullende informatie voor het autoriseren van toegang tot gegevens in verschillende scenario's:
Microsoft Authentication Library (MSAL)
Hoewel Microsoft het gebruik van de Azure Identity-clientbibliotheek indien mogelijk aanbeveelt, is de MSAL-bibliotheek mogelijk geschikt voor gebruik in bepaalde geavanceerde scenario's. Zie Meer informatie over MSAL voor meer informatie.
Wanneer u MSAL gebruikt om een OAuth-token te verkrijgen voor toegang tot Azure Storage, moet u een Microsoft Entra-resource-id opgeven. De Microsoft Entra-resource-id geeft de doelgroep aan waarvoor een token dat wordt uitgegeven, kan worden gebruikt om toegang te verlenen tot een Azure-resource. In het geval van Azure Storage is de resource-id mogelijk specifiek voor één opslagaccount of kan deze van toepassing zijn op elk opslagaccount.
Wanneer u een resource-id opgeeft die specifiek is voor één opslagaccount en -service, wordt de resource-id gebruikt om een token te verkrijgen voor het autoriseren van aanvragen voor het opgegeven account en de opgegeven service. De volgende tabel bevat de waarde die moet worden gebruikt voor de resource-id, op basis van de cloud waarmee u werkt. Vervang <account-name> door de naam van uw opslagaccount.
| Wolk | Resource ID |
|---|---|
| Azure Global | https://<account-name>.blob.core.windows.net |
| Azure Overheid | https://<account-name>.blob.core.usgovcloudapi.net |
| Azure China 21Vianet | https://<account-name>.blob.core.chinacloudapi.cn |
U kunt ook een resource-id opgeven die van toepassing is op elk opslagaccount, zoals wordt weergegeven in de volgende tabel. Deze resource-id is hetzelfde voor alle openbare en onafhankelijke clouds en wordt gebruikt om een token te verkrijgen voor het autoriseren van aanvragen voor elk opslagaccount.
| Wolk | Bron-ID |
|---|---|
| Azure Global Azure Overheid Azure China 21Vianet |
https://storage.azure.com/ |
Azure-rollen toewijzen voor toegangsrechten
Microsoft Entra autoriseert toegangsrechten voor beveiligde resources via Azure RBAC. Azure Storage definieert een set ingebouwde RBAC-rollen die algemene sets machtigingen omvatten die worden gebruikt voor toegang tot blobgegevens. U kunt ook aangepaste rollen definiëren voor toegang tot blobgegevens. Zie Een Azure-rol toewijzen voor toegang tot blobs voor meer informatie over het toewijzen van Azure-rollen voor toegang tot blobgegevens.
Een Microsoft Entra-beveiligingsprincipaal kan een gebruiker, een groep, een toepassingsservice-principal of een beheerde identiteit voor Azure-resources zijn. De RBAC-rollen die u aan een beveiligingsprincipaal toewijst, bepalen de machtigingen die de principal heeft voor de opgegeven resource.
Zie Assign an Azure role for access to blob data voor meer informatie over het toewijzen van Azure rollen voor blobtoegang.
In sommige gevallen moet u mogelijk verfijnde toegang tot blobresources inschakelen of machtigingen vereenvoudigen wanneer u een groot aantal roltoewijzingen voor een opslagresource hebt. Gebruik Azure op kenmerken gebaseerd toegangsbeheer (Azure ABAC) om voorwaarden voor roltoewijzingen te configureren. U kunt voorwaarden gebruiken met een aangepaste rol of ingebouwde rollen selecteren. Zie Toegang tot blobs autoriseren met behulp van voorwaarden voor Azure-roltoewijzing (preview) voor meer informatie over het configureren van voorwaarden voor Azure-opslagresources met ABAC. Zie Acties en kenmerken voor voorwaarden voor Azure-roltoewijzing in Azure Storage (preview) voor meer informatie over ondersteunde voorwaarden voor blobgegevensbewerkingen.
Notitie
Wanneer u een Azure Storage-account maakt, worden er niet automatisch machtigingen toegewezen voor toegang tot gegevens via Microsoft Entra ID. U moet uzelf expliciet een Azure-rol toewijzen voor toegang tot Blob Storage. U kunt deze toewijzen op het niveau van uw abonnement, resourcegroep, opslagaccount of container.
Resourcebereik
Voordat u een Azure RBAC-rol toewijst aan een beveiligingsprincipaal, bepaalt u het toegangsbereik dat de beveiligingsprincipaal moet hebben. Wijs altijd alleen het smalste bereik toe. Azure RBAC-rollen die op een ruimer niveau zijn gedefinieerd, worden geërfd door de onderliggende resources.
U kunt toegang tot Azure Blob-resources op de volgende niveaus instellen, te beginnen met het smalste bereik:
- Een afzonderlijke container. In dit bereik is een roltoewijzing van toepassing op alle blobs in de container en op de containereigenschappen en metagegevens.
- Het opslagaccount. In dit bereik is een roltoewijzing van toepassing op alle containers en de bijbehorende blobs.
- De resourcegroep. In dit bereik is een roltoewijzing van toepassing op alle containers in alle opslagaccounts in de resourcegroep.
- Het abonnement. In dit bereik is een roltoewijzing van toepassing op alle containers in alle opslagaccounts in alle resourcegroepen in het abonnement.
- Een beheergroep. In dit bereik is een roltoewijzing van toepassing op alle containers in alle opslagaccounts in alle resourcegroepen in alle abonnementen in de beheergroep.
Zie Begrijpen van bereik voor Azure RBAC voor meer informatie over het bereik van Azure RBAC-roltoewijzingen.
Ingebouwde Azure-rollen voor blobs
Azure RBAC biedt verschillende ingebouwde rollen voor het autoriseren van toegang tot blobgegevens met behulp van Microsoft Entra ID en OAuth. Enkele voorbeelden van rollen die machtigingen bieden voor gegevensbronnen in Azure Storage zijn:
- Eigenaar van opslagblobgegevens: hiermee kunt u het eigendom instellen en POSIX-toegangsbeheer voor Azure Data Lake Storage beheren. Zie Toegangsbeheer in Azure Data Lake Storage voor meer informatie.
- Inzender voor opslagblobgegevens: gebruik deze functie om lees-, schrijf- en verwijdermachtigingen te verlenen aan Blob Storage-resources.
- Lezer voor opslagblobgegevens: Gebruik om alleen-lezenrechten toe te kennen aan Blob-opslagresources.
- Storage Blob Delegator: Haal een gebruikersdelegatiesleutel op om een shared access signature te maken die is ondertekend door Microsoft Entra referenties voor een container of blob.
Zie Een Azure-rol toewijzen voor toegang tot blobgegevens voor meer informatie over het toewijzen van een ingebouwde Azure-rol aan een beveiligingsprincipaal. Zie Lijst met Azure-roldefinities voor meer informatie over het weergeven van Azure RBAC-rollen en hun machtigingen.
Zie Roldefinities begrijpen voor meer informatie over hoe ingebouwde rollen worden gedefinieerd voor Azure Storage. Zie Aangepaste Azure-rollen voor informatie over het maken van aangepaste Azure-rollen.
Alleen rollen die expliciet zijn gedefinieerd voor gegevenstoegang geven een beveiligingsprincipaal toegang tot blobgegevens. Ingebouwde rollen, zoals Eigenaar, Inzender en Inzender voor opslagaccounts, staan een beveiligingsprincipaal toe om een opslagaccount te beheren, maar bieden geen toegang tot de blobgegevens binnen dat account via Microsoft Entra-id. Als een rol echter Microsoft.Storage/storageAccounts/listKeys/action bevat, dan kan een gebruiker aan wie die rol is toegewezen toegang krijgen tot gegevens in het opslagaccount via autorisatie via gedeelde sleutel, door gebruik te maken van de toegangssleutels van het account. Zie Kiezen hoe u toegang tot blobgegevens in Azure Portal autoriseert voor meer informatie.
Voor gedetailleerde informatie over ingebouwde rollen van Azure voor Azure Storage voor zowel de gegevensservices als de beheerservice raadpleegt u de sectie Storage in Ingebouwde Azure-rollen voor Azure RBAC. Zie daarnaast Azure-rollen, Microsoft Entra-rollen en klassieke abonnementsbeheerdersrollen voor informatie over de verschillende typen rollen die machtigingen bieden in Azure.
Belangrijk
Azure roltoewijzingen kunnen tot 30 minuten duren voordat ze volledig zijn doorgevoerd.
Toegangsmachtigingen voor gegevensbewerkingen
Zie Machtigingen voor het aanroepen van gegevensbewerkingen voor meer informatie over de machtigingen die zijn vereist voor het aanroepen van specifieke Blob-servicebewerkingen.
Doorgiftevertragingen voor roltoewijzingen voor toegang tot blobgegevens
Wanneer u rollen toewijst of roltoewijzingen verwijdert, kan het tot tien minuten duren voordat wijzigingen van kracht worden. Als u rollen toewijst binnen het bereik van de beheergroep, kan het veel langer duren.
U kunt ingebouwde rollen toewijzen met gegevensacties binnen het bereik van de beheergroep. In zeldzame scenario's kan er echter een aanzienlijke vertraging (maximaal 12 uur) optreden voordat machtigingen voor gegevensacties effectief zijn voor bepaalde resourcetypen. Toestemmingen worden uiteindelijk toegepast. Voor ingebouwde rollen met gegevensacties wordt het toevoegen of verwijderen van roltoewijzingen binnen het bereik van de beheergroep niet aanbevolen voor scenario's waarin tijdige activering of intrekking van machtigingen, zoals Microsoft Entra Privileged Identity Management (PIM), is vereist.
Als u de juiste machtigingen instelt voor toegang tot gegevens via Microsoft Entra ID en u geen toegang hebt tot de gegevens, bijvoorbeeld als u de foutmelding AuthorizationPermissionMismatch krijgt, moet u voldoende tijd toestaan voor de wijzigingen in machtigingen die u in Microsoft Entra ID hebt aangebracht om te repliceren. Zorg er ook voor dat u geen ontkenningsopdrachten hebt die uw toegang blokkeren. Zie Azure-weigeringstoewijzingen begrijpen voor meer informatie.
Toegang tot gegevens met een Microsoft Entra-account
U kunt toegang tot blobgegevens autoriseren via de Azure-portal, PowerShell of Azure CLI via uw Microsoft Entra-account of met behulp van de toegangssleutels voor het account (autorisatie voor gedeelde sleutels).
Let op
Autorisatie met gedeelde sleutel wordt niet aanbevolen omdat deze mogelijk minder veilig is. Schakel voor optimale beveiliging autorisatie uit via een gedeelde sleutel voor uw opslagaccount, zoals beschreven in Autorisatie van gedeelde sleutels voorkomen voor een Azure Storage-account.
Het gebruik van toegangssleutels en verbindingsreeksen moet worden beperkt tot initiële proof-of-concept-apps of ontwikkelingsprototypes die geen toegang hebben tot productie- of gevoelige gegevens. Anders moeten de verificatieklassen op basis van tokens die beschikbaar zijn in de Azure SDK altijd de voorkeur krijgen bij het verifiëren bij Azure-resources.
Microsoft raadt aan dat clients Microsoft Entra ID of sas (Shared Access Signature) gebruiken om toegang tot gegevens in Azure Storage te autoriseren. Zie Bewerkingen autoriseren voor gegevenstoegang voor meer informatie.
Gegevenstoegang vanuit Azure Portal
De Azure-portal kan uw Microsoft Entra-account of de toegangssleutels van het account gebruiken om toegang tot blobgegevens te krijgen in een Azure-opslagaccount. Welk autorisatieschema de Azure-portal gebruikt, is afhankelijk van de Azure-rollen die aan u zijn toegewezen.
Wanneer u probeert toegang te krijgen tot blobgegevens, controleert de Azure portal eerst of u een Azure-rol hebt toegewezen met Microsoft. Storage/storageAccounts/listkeys/action. Als u met deze actie een rol hebt toegewezen, gebruikt de Azure-portal de accountsleutel voor toegang tot blobgegevens via autorisatie van gedeelde sleutels. Als u met deze actie geen rol hebt toegewezen, probeert de Azure portal toegang te krijgen tot gegevens met behulp van uw Microsoft Entra-account.
Als u toegang wilt krijgen tot blobgegevens vanuit de Azure-portal met behulp van uw Microsoft Entra-account, hebt u machtigingen nodig voor toegang tot blobgegevens en hebt u ook machtigingen nodig om door de resources van het opslagaccount in de Azure-portal te navigeren. De ingebouwde rollen die worden geboden in Azure Storage, verlenen toegang tot blob-resources, maar ze verlenen geen toegangsmachtigingen voor opslagaccounts. Daarom moet voor toegang tot de portal ook een Azure Resource Manager-rol zijn toegewezen, zoals de rol Lezer, toegepast op opslagaccountniveau of hoger. De rol Lezer verleent de meest beperkte machtigingen, maar een andere Azure Resource Manager-rol die toegang verleent tot resources voor het beheren van opslagaccounts is ook acceptabel. Zie Een Azure-rol toewijzen voor toegang tot blob-gegevens voor meer informatie over het toewijzen van machtigingen aan gebruikers zodat deze met een Microsoft Entra-account toegang hebben tot gegevens in Azure Portal.
Azure Portal laat zien welk autorisatieschema wordt gebruikt wanneer u naar een container navigeert. Zie Kiezen hoe toegang tot blob-gegevens in Azure Portal moet worden geautoriseerd voor meer informatie over gegevenstoegang in Azure Portal.
Gegevenstoegang vanuit PowerShell of Azure CLI
Azure CLI en PowerShell bieden ondersteuning voor aanmelden met Microsoft Entra-referenties. Nadat u zich hebt aangemeld, wordt uw sessie uitgevoerd met die inloggegevens. Zie een van de volgende artikelen voor meer informatie:
- Kies hoe u toegang tot blobgegevens wilt autoriseren met Azure CLI
- PowerShell-opdrachten uitvoeren met Microsoft Entra-aanmeldingsgegevens voor toegang tot blobgegevens
Functieondersteuning
Ondersteuning voor deze functie kan worden beïnvloed door het inschakelen van Data Lake Storage Gen2, het NFS-protocol (Network File System) 3.0 of het SSH File Transfer Protocol (SFTP). Als u een van deze mogelijkheden hebt ingeschakeld, raadpleegt u de ondersteuning voor Blob Storage-functies in Azure Storage-accounts om ondersteuning voor deze functie te beoordelen.
Het autoriseren van blobgegevensbewerkingen met Microsoft Entra ID wordt alleen ondersteund voor REST API-versies 2017-11-09 en hoger. Zie Versiebeheer voor de Azure Storage-services voor meer informatie.