Verificatie met Azure Maps
Azure Kaarten ondersteunt twee manieren om aanvragen te verifiëren: verificatie met gedeelde sleutel en verificatie met Azure Active Directory (Azure AD). In dit artikel worden beide verificatiemethoden uitgelegd om u te helpen bij de implementatie van Azure Kaarten services.
Notitie
Ter verbetering van beveiligde communicatie met Azure Kaarten ondersteunen we nu Transport Layer Security (TLS) 1.2 en wordt de ondersteuning voor TLS 1.0 en 1.1 niet meer ondersteund. Als u momenteel TLS 1.x gebruikt, evalueert u uw TLS 1.2-gereedheid en ontwikkelt u een migratieplan met de tests die worden beschreven in Het TLS 1.0-probleem oplossen.
Gedeelde sleutelverificatie
Primaire en secundaire sleutels worden gegenereerd nadat het Azure Kaarten account is gemaakt. U wordt aangeraden de primaire sleutel als abonnementssleutel te gebruiken bij het aanroepen van Azure Kaarten verificatie met gedeelde sleutels. Gedeelde sleutelverificatie geeft een sleutel die is gegenereerd door een Azure Kaarten-account door aan een Azure Kaarten service. Voeg voor elke aanvraag Kaarten Azure-services de abonnementssleutel als parameter toe aan de URL. De secundaire sleutel kan worden gebruikt in scenario's zoals wijzigingen in rolling sleutels.
Voorbeeld van het gebruik van de abonnementssleutel als parameter in uw URL:
https://atlas.microsoft.com/mapData/upload?api-version=1.0&dataFormat=zip&subscription-key={Azure-Maps-Primary-Subscription-key}
Zie Verificatie beheren voor meer informatie over het weergeven Azure Portal sleutels in de Azure Portal.
Notitie
Primaire en secundaire sleutels moeten worden behandeld als gevoelige gegevens. De gedeelde sleutel wordt gebruikt voor het verifiëren van alle Azure Kaarten REST API's. Gebruikers die een gedeelde sleutel gebruiken, moeten de API-sleutel abstraheeren, ofwel via omgevingsvariabelen of beveiligde geheime opslag, waar deze centraal kan worden beheerd.
Azure Active Directory-verificatie
Azure-abonnementen worden geleverd met een Azure AD-tenant om fijner toegangsbeheer mogelijk te maken. Azure Kaarten biedt verificatie voor Azure Kaarten-services met behulp van Azure AD. Azure AD biedt verificatie op basis van identiteit voor gebruikers en toepassingen die zijn geregistreerd in de Azure AD-tenant.
Azure Kaarten accepteert OAuth 2.0-toegangstokens voor Azure AD-tenants die zijn gekoppeld aan een Azure-abonnement dat een Azure Kaarten-account bevat. Azure Kaarten accepteert ook tokens voor:
- Azure AD-gebruikers
- Partnertoepassingen die gebruikmaken van machtigingen die zijn gedelegeerd door gebruikers
- Beheerde identiteiten voor Azure-resources
Azure Kaarten genereert een unieke id (client-id) voor elk Azure Kaarten-account. U kunt tokens aanvragen bij Azure AD wanneer u deze client-id combineert met aanvullende parameters.
Zie Verificatie beheren in Azure Kaarten voor meer informatie over het configureren van Azure AD en het aanvragen van tokens voor Azure Kaarten.
Zie Wat is verificatie?voor algemene informatie over verificatie met Azure AD.
Beheerde identiteiten voor Azure-resources en Azure-Kaarten
Beheerde identiteiten voor Azure-resources bieden Azure-services een automatisch beheerde beveiligingsprincipaal op basis van toepassingen die kan worden geverifieerd met Azure AD. Met op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) kan de beveiligingsprincipaal van de beheerde identiteit worden geautoriseerd voor toegang tot Azure Kaarten services. Enkele voorbeelden van beheerde identiteiten zijn: Azure App Service, Azure Functions en Azure Virtual Machines. Zie Beheerde identiteiten voor Azure-resources voor een lijst met beheerde identiteiten.
Azure AD-verificatie voor toepassingen configureren
Toepassingen worden geverifieerd bij de Azure AD-tenant met behulp van een of meer ondersteunde scenario's van Azure AD. Elk Azure AD-toepassingsscenario vertegenwoordigt verschillende vereisten op basis van bedrijfsbehoeften. Voor sommige toepassingen is mogelijk aanmeldingservaring van gebruikers vereist en voor andere toepassingen is mogelijk een aanmeldingservaring voor toepassingen vereist. Zie Verificatiestromen en toepassingsscenario's voor meer informatie.
Nadat de toepassing een toegangs token heeft ontvangen, verzendt de SDK en/of toepassing een HTTPS-aanvraag met de volgende set vereiste HTTP-headers naast andere HTTP REST API headers:
| Headernaam | Waarde |
|---|---|
| x-ms-client-id | 30d7cc….9f55 |
| Autorisatie | Bearer-token eyJ0e….HNIVN |
Notitie
x-ms-client-idis de guid Kaarten azure-account die wordt weergegeven op de pagina Azure Kaarten-verificatie.
Hier is een voorbeeld van een Azure Kaarten-routeaanvraag die gebruikmaakt van een Azure AD OAuth Bearer-token:
GET /route/directions/json?api-version=1.0&query=52.50931,13.42936:52.50274,13.43872
Host: atlas.microsoft.com
x-ms-client-id: 30d7cc….9f55
Authorization: Bearer eyJ0e….HNIVN
Zie Verificatiedetails weergeven voor meer informatie over het weergeven van uw client-id.
Autorisatie met op rollen gebaseerd toegangsbeheer
Azure Kaarten biedt ondersteuning voor toegang tot alle principaltypen voor op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC), waaronder: afzonderlijke Azure AD-gebruikers, -groepen, -toepassingen, Azure-resources en door Azure beheerde identiteiten. Principal-typen krijgen een set machtigingen, ook wel een roldefinitie genoemd. Een roldefinitie biedt machtigingen voor REST API acties. Het toepassen van toegang tot een of meer Azure Kaarten-accounts wordt een bereik genoemd. Bij het toepassen van een principal, roldefinitie en bereik wordt er een roltoewijzing gemaakt.
In de volgende secties worden concepten en onderdelen van Azure Kaarten integratie met Azure RBAC besproken. Als onderdeel van het instellen van uw Azure Kaarten-account, wordt een Azure AD-directory gekoppeld aan het Azure-abonnement, waarin het Azure Kaarten-account zich bevindt.
Wanneer u Azure RBAC configureert, kiest u een beveiligingsprincipaal en pas u deze toe op een roltoewijzing. Zie Azure-rollen toewijzen voor meer informatie Azure Portal roltoewijzingen kunt toevoegen aan de Azure Portal.
Een roldefinitie kiezen
De volgende typen roldefinitie bestaan ter ondersteuning van toepassingsscenario's.
| Azure-roldefinitie | Description |
|---|---|
| Azure Kaarten-gegevenslezer | Biedt toegang tot onveranderbare Azure Kaarten REST API's. |
| Azure Kaarten Data Contributor | Biedt toegang tot veranderlijke Azure Kaarten REST API's. Veranderbaarheid wordt gedefinieerd door de acties: schrijven en verwijderen. |
| Aangepaste roldefinitie | Maak een gemaakte rol om flexibele beperkte toegang tot Azure Kaarten REST API's mogelijk te maken. |
Voor sommige Azure Kaarten-services zijn mogelijk verhoogde bevoegdheden vereist om schrijf- of verwijderacties uit te voeren op Azure Kaarten REST API's. De rol Kaarten Azure-gegevensbijdrager is vereist voor services die schrijf- of verwijderacties bieden. In de volgende tabel wordt beschreven welke services Azure Kaarten Data Contributor van toepassing is bij het gebruik van schrijf- of verwijderacties. Wanneer alleen leesacties zijn vereist, kan de rol Azure Kaarten Data Reader worden gebruikt in plaats van de rol Azure Kaarten Data Contributor.
| Azure Kaarten Service | Roldefinitie van Azure Kaarten |
|---|---|
| Gegevens | Azure Kaarten Data Contributor |
| Creator | Azure Kaarten Data Contributor |
| Ruimtelijk | Azure Kaarten Data Contributor |
Zie Azure RBAC configureren voor Azure RBAC voor Azure Kaarten voor meer informatie over het weergeven van uw Azure RBAC-Kaarten.
Aangepaste roldefinities
Een aspect van toepassingsbeveiliging is het principe van de minste bevoegdheden, de praktijk van het beperken van toegangsrechten tot alleen de rechten die nodig zijn om de taak bij de hand te hebben. Hiervoor maakt u aangepaste roldefinities die use cases ondersteunen, waarvoor verdere granulariteit voor toegangsbeheer is vereist. Als u een aangepaste roldefinitie wilt maken, selecteert u specifieke gegevensacties die u wilt opnemen of uitsluiten voor de definitie.
De aangepaste roldefinitie kan vervolgens worden gebruikt in een roltoewijzing voor elke beveiligingsprincipaal. Zie Aangepaste Azure-rollen voor meer informatie over aangepaste Azure-roldefinities.
Hier volgen enkele voorbeeldscenario's waarin aangepaste rollen de beveiliging van toepassingen kunnen verbeteren.
| Scenario | Actie(en) voor aangepaste rolgegevens |
|---|---|
| Een openbare of interactieve aanmeldingswebpagina met basiskaarttegels en geen andere REST API's. | Microsoft.Maps/accounts/services/render/read |
| Een toepassing, waarvoor alleen reverse geocoderen is vereist en geen andere REST API's. | Microsoft.Maps/accounts/services/search/read |
| Een rol voor een beveiligingsprincipaal, die het lezen van op Azure Kaarten Creator gebaseerde kaartgegevens en REST API's voor basiskaarttegels aanvraagt. | Microsoft.Maps/accounts/services/data/read, Microsoft.Maps/accounts/services/render/read |
| Een rol voor een beveiligingsprincipaal, waarvoor het lezen, schrijven en verwijderen van kaartgegevens op basis van Creator is vereist. Dit kan worden gedefinieerd als een rol van kaartgegevenseditor, maar biedt geen toegang tot andere REST API's, zoals basiskaarttegels. | Microsoft.Maps/accounts/services/data/read, Microsoft.Maps/accounts/services/data/write, Microsoft.Maps/accounts/services/data/delete |
Inzicht in bereik
Wanneer u een roltoewijzing maakt, wordt deze gedefinieerd in de Azure-resourcehiërarchie. Bovenaan de hiërarchie staat een beheergroep en de laagste is een Azure-resource, zoals een Azure Kaarten account. Als u een roltoewijzing toewijst aan een resourcegroep, kunt u toegang krijgen tot meerdere Azure Kaarten of resources in de groep.
Tip
De algemene aanbeveling van Microsoft is om toegang toe te wijzen aan het Azure Kaarten-accountbereik, omdat hiermee onbedoelde toegang wordt voorkomen tot andere Azure Kaarten-accounts die in hetzelfde Azure-abonnement bestaan.
Volgende stappen
Zie voor meer informatie over Azure RBAC
Zie voor meer informatie over het authenticeren van een toepassing met Azure AD en Azure Kaarten
Zie voor meer informatie over het Kaarten Map Control azure-gegevens met Azure AD