Delen via


Aanbevolen procedures voor verificatie

Het belangrijkste onderdeel van uw toepassing is de beveiliging. Ongeacht hoe goed de gebruikerservaring kan zijn, als uw toepassing niet veilig is, kan een hacker het verpesten.

Hier volgen enkele tips om uw Azure Kaarten-toepassing veilig te houden. Wanneer u Azure gebruikt, moet u vertrouwd raken met de beveiligingshulpprogramma's die voor u beschikbaar zijn. Zie de inleiding tot Azure-beveiliging voor meer informatie.

Beveiligingsrisico's begrijpen

Hackers die toegang krijgen tot uw account, kunnen mogelijk onbeperkte factureerbare transacties maken, wat resulteert in onverwachte kosten en verminderde prestaties vanwege QPS-limieten.

Wanneer u de aanbevolen procedures voor het beveiligen van uw Azure Kaarten-toepassingen overweegt, moet u de verschillende beschikbare verificatieopties begrijpen.

Aanbevolen procedures voor verificatie in Azure Kaarten

Wanneer u openbaar gerichte clienttoepassingen maakt met Azure Kaarten, moet u ervoor zorgen dat uw verificatiegeheimen niet openbaar toegankelijk zijn.

Verificatie op basis van een abonnementssleutel (gedeelde sleutel) kan worden gebruikt in toepassingen aan de clientzijde of webservices, maar het is de minst veilige benadering voor het beveiligen van uw toepassing of webservice. De reden hiervoor is dat de sleutel eenvoudig wordt verkregen uit een HTTP-aanvraag en toegang verleent tot alle Azure Kaarten REST API die beschikbaar is in de SKU (prijscategorie). Als u abonnementssleutels gebruikt, moet u deze regelmatig roteren en er rekening mee houden dat gedeelde sleutel geen configureerbare levensduur toestaat, deze handmatig moet worden uitgevoerd. U moet ook overwegen om gedeelde sleutelverificatie te gebruiken met Azure Key Vault, waarmee u uw geheim veilig kunt opslaan in Azure.

Als u Microsoft Entra-verificatie of SAS-tokenverificatie (Shared Access Signature) gebruikt, wordt toegang tot Azure Kaarten REST API's geautoriseerd met behulp van op rollen gebaseerd toegangsbeheer (RBAC). Met RBAC kunt u bepalen welke toegang wordt verleend aan de uitgegeven tokens. U moet overwegen hoe lang toegang moet worden verleend voor de tokens. In tegenstelling tot verificatie met gedeelde sleutels kan de levensduur van deze tokens worden geconfigureerd.

Fooi

Zie voor meer informatie over het configureren van levensduur van tokens:

Openbare en vertrouwelijke clienttoepassingen

Er zijn verschillende beveiligingsproblemen tussen openbare en vertrouwelijke clienttoepassingen. Zie openbare client- en vertrouwelijke clienttoepassingen in de documentatie van het Microsoft Identity Platform voor meer informatie over wat wordt beschouwd als een openbare versus vertrouwelijke clienttoepassing.

Openbare clienttoepassingen

Voor apps die worden uitgevoerd op apparaten of desktopcomputers of in een webbrowser, moet u overwegen om te definiƫren welke domeinen toegang hebben tot uw Azure Map-account met CORS (Cross Origin Resource Sharing). CORS geeft de browser van de clients aan waarop oorsprongen zoals "https://microsoft.com" mogen resources aanvragen voor het Azure Map-account.

Notitie

Als u een webserver of service ontwikkelt, hoeft uw Azure Kaarten-account niet te worden geconfigureerd met CORS. Als u JavaScript-code in de webtoepassing aan de clientzijde hebt, is CORS van toepassing.

Vertrouwelijke clienttoepassingen

Voor apps die worden uitgevoerd op servers (zoals webservices en service-/daemon-apps), kunt u beheerde identiteiten overwegen als u liever de overhead en complexiteit van het beheren van geheimen vermijdt. Beheerde identiteiten kunnen een identiteit bieden die uw webservice kan gebruiken bij het maken van verbinding met Azure Kaarten met behulp van Microsoft Entra-verificatie. Zo ja, dan gebruikt uw webservice die identiteit om de vereiste Microsoft Entra-tokens te verkrijgen. U moet Azure RBAC gebruiken om te configureren welke toegang de webservice krijgt, met behulp van de rollen met minimale bevoegdheden die mogelijk zijn.

Volgende stappen