Aanbevolen procedures voor verificatie

De beveiliging van uw toepassing is van cruciaal belang. Ongeacht hoe uitstekend de gebruikerservaring is, kan een onveilige toepassing worden aangetast door hackers, de integriteit ervan ondermijnen en het vertrouwen van gebruikers verslechteren.

Dit artikel bevat tips om de beveiliging van uw Azure Maps-toepassing te garanderen. Wanneer u Azure gebruikt, is het belangrijk om vertrouwd te raken met de beschikbare beveiligingshulpprogramma's. Zie Inleiding tot Azure-beveiliging in de Documentatie voor Azure-beveiliging voor meer informatie.

Beveiligingsrisico's begrijpen

Als hackers toegang krijgen tot uw account, kunnen ze mogelijk onbeperkte factureerbare transacties uitvoeren, wat leidt tot onverwachte kosten en verminderde prestaties vanwege QPS-limieten.

Voor het implementeren van best practices voor het beveiligen van uw Azure Maps-toepassingen is het essentieel om inzicht te hebben in de verschillende beschikbare verificatieopties.

Aanbevolen procedures voor verificatie in Azure Maps

Bij het ontwikkelen van openbaar gerichte clienttoepassingen met Azure Maps is het van cruciaal belang dat uw verificatiegeheimen privé blijven en 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 methode voor het beveiligen van uw toepassing of webservice. Dit komt doordat de sleutel eenvoudig kan worden geëxtraheerd uit een HTTP-aanvraag, waarbij toegang wordt verleend tot alle Azure Maps REST API's die beschikbaar zijn in de SKU (prijscategorie). Als u abonnementssleutels gebruikt, moet u deze regelmatig roteren en er rekening mee houden dat gedeelde sleutel geen ondersteuning biedt voor configureerbare levensduur, dus moet u handmatig rouleren. Overweeg om gedeelde sleutelverificatie te gebruiken met Azure Key Vault om uw geheim veilig op te slaan in Azure.

Wanneer u Verificatie van Microsoft Entra of SAS-tokenverificatie (Shared Access Signature) gebruikt, wordt toegang tot Azure Maps REST API's geautoriseerd met behulp van op rollen gebaseerd toegangsbeheer (RBAC). Met RBAC kunt u het toegangsniveau opgeven dat wordt verleend aan de uitgegeven tokens. Het is belangrijk om rekening te houden met de duur waarvoor toegang moet worden verleend. In tegenstelling tot verificatie met gedeelde sleutels kan de levensduur van deze tokens worden geconfigureerd.

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 toepassingen die worden uitgevoerd op apparaten, desktopcomputers of webbrowsers, is het raadzaam om te definiëren welke domeinen toegang hebben tot uw Azure Maps-account met CORS (Cross Origin Resource Sharing). CORS informeert de browser van de client welke oorsprongen, zoals 'https://microsoft.com,' zijn toegestaan om resources voor het Azure Maps-account aan te vragen.

Vertrouwelijke clienttoepassingen

Voor servertoepassingen, zoals webservices en service-/daemon-apps, kunt u overwegen beheerde identiteiten te gebruiken om de complexiteit van het beheren van geheimen te voorkomen. Beheerde identiteiten kunnen een identiteit bieden voor uw webservice om verbinding te maken met Azure Maps met behulp van Microsoft Entra-verificatie. Uw webservice kan deze identiteit vervolgens gebruiken om de benodigde Microsoft Entra-tokens te verkrijgen. Het is raadzaam om Azure RBAC te gebruiken om de toegang te configureren die is verleend aan de webservice, waarbij de rollen met minimale bevoegdheden mogelijk worden toegepast.

Volgende stappen