Ověřování s využitím Azure Maps

Azure Maps podporuje tři způsoby ověřování požadavků: ověřování pomocí sdíleného klíče, ověřování POMOCÍ ID Microsoftu a ověřování tokenu sdíleného přístupového podpisu (SAS). Tento článek vysvětluje metody ověřování, které vám pomůžou s implementací služeb Azure Maps. Tento článek také popisuje další ovládací prvky účtu, jako je zakázání místního ověřování pro Azure Policy a sdílení prostředků mezi zdroji (CORS).

Ověřování pomocí sdíleného klíče

Informace o zobrazení klíčů na webu Azure Portal najdete v tématu Zobrazení podrobností o ověřování.

Primární a sekundární klíče se generují po vytvoření účtu Azure Maps. Doporučujeme použít primární klíč jako klíč předplatného při volání Služby Azure Maps se sdíleným klíčem. Ověřování pomocí sdíleného klíče předává klíč vygenerovaný účtem Azure Maps do služby Azure Maps. Pro každou žádost o služby Azure Maps přidejte klíč předplatného jako parametr do adresy URL. Sekundární klíč je možné použít ve scénářích, jako jsou změny postupného klíče.

Příklad použití klíče předplatného jako parametru v adrese URL:

https://atlas.microsoft.com/map/tile?subscription-key={Your-Azure-Maps-Subscription-key}&api-version=2024-04-01&tilesetId=microsoft.base.road&zoom=15&x=5236&y=12665&tileSize=256

Ověřování Microsoft Entra

Předplatná Azure jsou k dispozici s tenantem Microsoft Entra, aby bylo možné jemně odstupňované řízení přístupu. Azure Maps nabízí ověřování pro služby Azure Maps pomocí ID Microsoft Entra. Id Microsoft Entra poskytuje ověřování na základě identity pro uživatele a aplikace zaregistrované v tenantovi Microsoft Entra.

Azure Maps přijímá přístupové tokeny OAuth 2.0 pro tenanty Microsoft Entra přidružené k předplatnému Azure, které obsahuje účet Azure Maps. Azure Maps také přijímá tokeny pro:

• Uživatelé Microsoft Entra
• Partnerské aplikace, které používají oprávnění delegovaná uživateli
• Spravované identity pro prostředky Azure

Azure Maps generuje jedinečný identifikátor (ID klienta) pro každý účet Azure Maps. Tokeny můžete vyžádat z ID Microsoft Entra, když toto ID klienta zkombinujete s dalšími parametry.

Další informace o konfiguraci ID Microsoft Entra a tokenů žádostí pro Azure Maps najdete v tématu Správa ověřování v Azure Maps.

Obecné informace o ověřování pomocí MICROSOFT Entra ID naleznete v tématu Ověřování vs. autorizace.

Spravované identity pro prostředky Azure a Azure Maps

Spravované identity pro prostředky Azure poskytují službám Azure automaticky spravovaný objekt zabezpečení založený na aplikacích, který se může ověřit pomocí ID Microsoft Entra. Pomocí řízení přístupu na základě role v Azure (Azure RBAC) je možné instanční objekt zabezpečení spravované identity autorizovat pro přístup ke službám Azure Maps. Mezi příklady spravovaných identit patří: Aplikace Azure Service, Azure Functions a Azure Virtual Machines. Seznam spravovaných identit najdete ve službách Azure, které můžou používat spravované identity pro přístup k jiným službám. Další informace o spravovaných identitách najdete v tématu Správa ověřování v Azure Maps.

Konfigurace ověřování Microsoft Entra v aplikaci

Aplikace se ověřují pomocí tenanta Microsoft Entra pomocí jednoho nebo více podporovaných scénářů poskytovaných ID Microsoft Entra. Každý scénář aplikace Microsoft Entra představuje různé požadavky na základě obchodních potřeb. Některé aplikace můžou vyžadovat přihlašování uživatelů a jiné aplikace můžou vyžadovat přihlašování k aplikaci. Další informace najdete v tématu Toky ověřování a scénáře aplikací.

Jakmile aplikace obdrží přístupový token, sada SDK a/nebo aplikace odešle požadavek HTTPS s následující sadou požadovaných hlaviček HTTP kromě dalších hlaviček HTTP rozhraní REST API:

Tady je příklad požadavku na trasu Azure Maps, který používá nosný token Microsoft Entra ID OAuth:

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

Informace o zobrazení ID klienta najdete v tématu Zobrazení podrobností o ověřování.

$maps = Get-AzMapsAccount -Name {Azure-Maps_Account-Name} -ResourceGroupName {Resource-Group-Name} -SubscriptionId {SubscriptionId}
$ClientId = $maps.UniqueId

$ClientId = az maps account show --name {Azure-Maps_Account-Name} --resource-group {Resource-Group-Name} --subscription {SubscriptionId} --query properties.uniqueId

Autorizace pomocí řízení přístupu na základě role

Požadavky

Pokud s Azure RBAC začínáte, poskytuje přehled řízení přístupu na základě role v Azure (Azure RBAC) sadu oprávnění, která se označuje také jako definice role. Definice role poskytuje oprávnění k akcím rozhraní REST API. Azure Maps podporuje přístup ke všem typům objektů zabezpečení pro řízení přístupu na základě role Azure (Azure RBAC), včetně jednotlivých uživatelů Microsoft Entra, skupin, aplikací, prostředků Azure a spravovaných identit Azure. Použití přístupu k jednomu nebo více účtům Azure Maps se označuje jako obor. Přiřazení role se vytvoří při použití objektu zabezpečení, definice role a oboru.

Přehled

V dalších částech najdete informace o konceptech a komponentách integrace Azure Maps s Azure RBAC. V rámci procesu nastavení účtu Azure Maps je adresář Microsoft Entra přidružený k předplatnému Azure, ve kterém se nachází účet Azure Maps.

Při konfiguraci Azure RBAC zvolíte objekt zabezpečení a použijete ho na přiřazení role. Informace o tom, jak přidat přiřazení rolí na webu Azure Portal, najdete v tématu Přiřazení rolí Azure pomocí webu Azure Portal.

Výběr definice role

Pro podporu scénářů aplikace existují následující typy definic rolí.

Některé služby Azure Maps mohou vyžadovat zvýšená oprávnění k provádění akcí zápisu nebo odstranění v rozhraních REST API služby Azure Maps. Role Přispěvatel dat Azure Maps se vyžaduje pro služby, které poskytují akce zápisu nebo odstranění. Následující tabulka popisuje, které služby Azure Maps Data Contributor se vztahují při použití akcí zápisu nebo odstranění. Pokud jsou vyžadovány pouze akce čtení, je možné místo role Přispěvatel dat Azure Maps použít roli Čtenář dat Azure Maps.

¹ Azure Maps Creator a registr dat a prostorové služby jsou nyní zastaralé a budou vyřazeny 30. 9. 25.

Informace o zobrazení nastavení Azure RBAC najdete v tématu Konfigurace Azure RBAC pro Azure Maps.

Vlastní definice rolí

Jedním z aspektů zabezpečení aplikací je princip nejnižších oprávnění, postup omezení přístupových práv na práva požadovaná pro aktuální úlohu. Omezení přístupových práv se provádí vytvořením vlastních definic rolí, které podporují případy použití vyžadující další členitost řízení přístupu. Pokud chcete vytvořit vlastní definici role, vyberte konkrétní akce dat, které se mají zahrnout nebo vyloučit pro definici.

Vlastní definici role je pak možné použít v přiřazení role pro libovolný objekt zabezpečení. Další informace o definicích vlastních rolí Azure najdete v tématu Vlastní role Azure.

Tady je několik ukázkových scénářů, ve kterých můžou vlastní role zlepšit zabezpečení aplikací.

Orientace v oborech

Při vytváření přiřazení role se definuje v hierarchii prostředků Azure. V horní části hierarchie je skupina pro správu a nejnižší je prostředek Azure, jako je účet Azure Maps. Přiřazení role ke skupině prostředků může povolit přístup k více účtům nebo prostředkům Azure Maps ve skupině.

Zakázání místního ověřování

Účty Azure Maps podporují standardní vlastnost Azure v rozhraní API pro správu pro Microsoft.Maps/accounts volání disableLocalAuth. Pokud trueje veškeré ověřování pro rozhraní REST API roviny dat Azure Maps zakázané, s výjimkou ověřování Microsoft Entra. To se konfiguruje pomocí Služby Azure Policy k řízení distribuce a správy sdílených klíčů a tokenů SAS. Další informace najdete v tématu Co je Azure Policy?.

Zakázání místního ověřování se neprojeví okamžitě. Počkejte několik minut, než služba zablokuje budoucí žádosti o ověření. Pokud chcete znovu povolit místní ověřování, nastavte vlastnost na false místní ověření a po několika minutách se obnoví.

{
  // omitted other properties for brevity.
  "properties": {
    "disableLocalAuth": true
  }
}

Ověřování tokenu sdíleného přístupového podpisu

Tokeny sdíleného přístupového podpisu (SAS) jsou ověřovací tokeny vytvořené ve formátu JSON Web Token (JWT) a jsou kryptograficky podepsané, aby bylo možné ověřit ověřování pro aplikaci v rozhraní REST API služby Azure Maps. Token SAS vytvořený integrací spravované identity přiřazené uživatelem s účtem Azure Maps ve vašem předplatném Azure. Spravovaná identita přiřazená uživatelem má autorizaci k účtu Azure Maps prostřednictvím Azure RBAC pomocí předdefinovaných nebo vlastních definic rolí.

Funkční klíčové rozdíly tokenu SAS z přístupových tokenů Microsoft Entra:

• Životnost tokenu pro maximální vypršení platnosti jednoho dne (24 hodin).
• Umístění Azure a geografické řízení přístupu na token
• Omezení rychlosti na token pro přibližně 1 až 500 požadavků za sekundu.
• Privátní klíče tokenu jsou primární a sekundární klíče prostředku účtu Azure Maps.
• Objekt instančního objektu pro autorizaci poskytuje spravovaná identita přiřazená uživatelem.

Tokeny SAS jsou neměnné. To znamená, že po vytvoření tokenu je token SAS platný až do dosažení vypršení platnosti a nejde změnit konfiguraci povolených oblastí, omezení rychlosti a spravované identity přiřazené uživatelem. Další informace o porozumění řízení přístupu pro odvolání tokenu SAS a změnách řízení přístupu najdete níže.

Vysvětlení limitů rychlosti tokenů SAS

Maximální limit rychlosti tokenu SAS může řídit fakturaci prostředku Azure Maps.

Při zadávání maximálního limitu sazby u tokenu (maxRatePerSecond) se nadbytečné sazby neúčtují na účet, takže při použití tokenu nastavíte horní limit fakturovatelných transakcí. Aplikace však obdrží chybové odpovědi klienta pro 429 (TooManyRequests) všechny transakce po dosažení limitu. Za správu opakování a distribuce tokenů SAS zodpovídá aplikace. Neexistuje žádný limit počtu tokenů SAS, které je možné pro účet vytvořit. Povolení zvýšení nebo snížení limitu existujícího tokenu; Je nutné vytvořit nový token SAS. Starý token SAS je stále platný až do vypršení platnosti.

Odhadovaný příklad:

Skutečné limity rychlosti se liší v závislosti na schopnosti Azure Maps vynucovat konzistenci v rámci časového intervalu. To však umožňuje preventivní kontrolu fakturačních nákladů.

Omezení rychlosti se vynucují pro umístění Azure, ne globálně nebo geograficky.

Například jeden token SAS s maxRatePerSecond 10 je možné použít k omezení propustnosti v East US umístění. Pokud se použije West US 2stejný token, vytvoří se nový čítač, který omezí propustnost na 10 v daném umístění nezávisle na East US umístění. Pokud chcete řídit náklady a zlepšit předvídatelnost, doporučujeme:

1. Vytvořte tokeny SAS s určenými povolenými umístěními Azure pro cílovou geografickou oblast. Pokračujte ve čtení a seznamte se s vytvářením tokenů SAS.
2. Použijte koncové body https://us.atlas.microsoft.com rozhraní REST API roviny geografických dat nebo https://eu.atlas.microsoft.com.

Zvažte topologii aplikace, kde se koncový bod https://us.atlas.microsoft.com směruje do stejných umístění v USA, kde jsou hostované služby Azure Maps, například East US, West Central USnebo West US 2. Stejná myšlenka se vztahuje na jiné geografické koncové body, jako https://eu.atlas.microsoft.com jsou mezi West Europe a North Europe. Pokud chcete zabránit neočekávaným odepření autorizace, použijte token SAS, který používá stejná umístění Azure, která aplikace využívá. Umístění koncového bodu se definuje pomocí rozhraní REST API služby Azure Maps Management.

Výchozí limity sazeb přebírají předchůdci nad limity rychlosti tokenů SAS

Jak je popsáno v limitech rychlosti služby Azure Maps, jednotlivé nabídky služeb mají různá omezení rychlosti, která se vynucují jako agregace účtu.

Vezměte v úvahu případ Search – non-Batch Reverse, s limitem 250 dotazů za sekundu (QPS) pro následující tabulky. Každá tabulka představuje odhadovaný celkový počet úspěšných transakcí z ukázkového využití.

První tabulka ukazuje jeden token, který má maximální požadavek za sekundu 500 a skutečné využití aplikace je 500 požadavků za sekundu po dobu 60 sekund. Search – Nesádkové obrácení má limit rychlosti 250, což znamená, že celkem 30 000 žádostí provedených za 60 sekund; 15 000 těchto požadavků jsou fakturovatelné transakce. Zbývající požadavky mají za následek stavový kód 429 (TooManyRequests).

Pokud jsou například vytvořeny dva tokeny SAS a používají stejné umístění jako účet Azure Maps, každý token teď sdílí výchozí limit rychlosti 250 QPS. Pokud se každý token použije současně se stejným tokenem propustnosti 1 a tokenem 2, úspěšně udělí 7500 úspěšných transakcí.

Principy řízení přístupu tokenu SAS

Tokeny SAS používají RBAC k řízení přístupu k rozhraní REST API. Při vytváření tokenu SAS se požadované spravované identitě na mapovém účtu přiřadí role Azure RBAC, která uděluje přístup ke konkrétním akcím rozhraní REST API. Informace o tom, která rozhraní API aplikace umožňuje, najdete v tématu Výběr definice role.

Pokud chcete přiřadit dočasný přístup a odebrat přístup před vypršením platnosti tokenu SAS, odvolejte token. Další důvody odvolání přístupu můžou být v případě, že se token distribuuje neúmyslně s přiřazením Azure Maps Data Contributor role a každý, kdo má token SAS, může číst a zapisovat data do rozhraní REST API služby Azure Maps, která můžou vystavit citlivá data nebo neočekávané finanční náklady z využití.

existují dvě možnosti odvolání přístupu pro tokeny SAS:

1. Znovu vygenerujte klíč používaný tokenem SAS nebo sekundárním klíčem účtu mapy.
2. Odeberte přiřazení role pro spravovanou identitu v přidruženém účtu mapování.

Vytvoření tokenů SAS

Pokud chcete vytvořit tokeny SAS, musíte mít Contributor přístup role ke správě účtů Azure Maps i identit přiřazených uživatelem v předplatném Azure.

Nejprve byste měli vytvořit spravovanou identitu přiřazenou uživatelem ve stejném umístění jako účet Azure Maps.

Po vytvoření spravované identity můžete vytvořit nebo aktualizovat účet Azure Maps a připojit ji. Další informace najdete v tématu Správa účtu Azure Maps.

Po úspěšném vytvoření nebo aktualizaci účtu spravovanou identitou; přiřaďte řízení přístupu na základě role pro spravovanou identitu k roli dat Azure Maps v oboru účtu. To umožňuje, aby spravovaná identita byla udělena přístup k rozhraní REST API služby Azure Maps pro váš účet mapy.

Dále vytvořte token SAS pomocí nástrojů sady Sdk pro správu Azure, operace Výpis SAS v rozhraní API pro správu účtů nebo stránky sdíleného přístupového podpisu webu Azure Portal prostředku účtu mapování.

Parametry tokenu SAS:

Konfigurace aplikace pomocí tokenu SAS

Jakmile aplikace obdrží token SAS, sada Azure Maps SDK nebo aplikace odešlou požadavek HTTPS s následující povinnou hlavičkou HTTP kromě dalších hlaviček HTTP rozhraní REST API:

Sdílení prostředků mezi zdroji (CORS)

CORS je protokol HTTP, který umožňuje webové aplikaci spuštěné v jedné doméně přistupovat k prostředkům v jiné doméně. Webové prohlížeče implementují omezení zabezpečení známé jako zásady stejného původu, které brání webové stránce v volání rozhraní API v jiné doméně; CORS poskytuje bezpečný způsob, jak povolit, aby jedna doména (původní doména) volala rozhraní API v jiné doméně. Pomocí prostředku účtu Azure Maps můžete nakonfigurovat, které zdroje mají povolený přístup k rozhraní REST API služby Azure Maps z vašich aplikací.

Požadavky

Aby se zabránilo spuštění škodlivého kódu na klientovi, moderní prohlížeče blokují požadavky z webových aplikací na prostředky spuštěné v samostatné doméně.

• Pokud cors neznáte, přečtěte si téma Sdílení prostředků mezi zdroji (CORS), umožňuje hlavičku Access-Control-Allow-Origin deklarovat, které zdroje můžou volat koncové body účtu Azure Maps. Protokol CORS není specifický pro Azure Maps.

Požadavky CORS

Žádost CORS z původní domény se může skládat ze dvou samostatných požadavků:

• Předběžný požadavek, který se dotazuje omezení CORS, která služba uložila. Předběžný požadavek se vyžaduje, pokud se nejedná o standardní metodu GET, HEAD, POST nebo požadavky, které obsahují Authorization hlavičku požadavku.

• Skutečný požadavek provedený proti požadovanému prostředku.

Předběžný požadavek

Předběžný požadavek se provádí nejen jako bezpečnostní opatření, které zajistí, že server rozumí metodě a hlaviček odesílaných ve skutečném požadavku a že server ví a důvěřuje zdroji požadavku, ale také se dotazuje omezení CORS, která byla stanovena pro účet mapy. Webový prohlížeč (nebo jiný uživatelský agent) odešle požadavek OPTIONS, který obsahuje hlavičky požadavku, metodu a původní doménu. Služba mapového účtu se pokusí načíst všechna pravidla CORS, pokud je ověřování účtu možné prostřednictvím předběžného protokolu CORS.

Pokud ověřování není možné, služba Maps vyhodnocuje předem nakonfigurovanou sadu pravidel CORS, která určují, které domény původu, metody požadavků a hlavičky požadavků mohou být zadány na skutečném požadavku vůči službě Maps. Ve výchozím nastavení je účet maps nakonfigurovaný tak, aby umožňoval bezproblémovou integraci do webových prohlížečů.

Služba odpoví na předběžný požadavek s požadovanými hlavičkami řízení přístupu, pokud jsou splněna následující kritéria:

1. Požadavek OPTIONS obsahuje požadovaná hlavička CORS (hlavičky Origin a Access-Control-Request-Method).
2. Ověření proběhlo úspěšně a pro účet, který odpovídá předběžné žádosti, je povolené pravidlo CORS.
3. Ověřování se přeskočilo kvůli požadovaným Authorization hlavičkám požadavků, které není možné zadat v předběžném požadavku.

Když je předběžný požadavek úspěšný, služba odpoví stavovým kódem 200 (OK)a do odpovědi zahrne požadované hlavičky řízení přístupu.

Služba odmítne předběžné požadavky, pokud dojde k následujícím podmínkám:

1. Pokud požadavek OPTIONS neobsahuje požadovaná hlavička CORS (hlavičky Origin a Access-Control-Request-Method), služba odpoví stavovým kódem 400 (Bad request).
2. Pokud bylo ověření při předběžné žádosti úspěšné a žádné pravidlo CORS neodpovídá předběžnému požadavku, služba odpoví stavovým kódem 403 (Forbidden). K tomu může dojít, pokud je pravidlo CORS nakonfigurované tak, aby přijímalo zdroj, který neodpovídá aktuální hlavičce žádosti o původ klienta prohlížeče.

Skutečný požadavek

Jakmile se předběžný požadavek přijme a odpověď se vrátí, prohlížeč odešle skutečný požadavek do mapové služby. Prohlížeč okamžitě odmítne skutečnou žádost, pokud se předběžný požadavek odmítne.

Skutečný požadavek se považuje za normální požadavek vůči mapové službě. Origin Přítomnost hlavičky označuje, že požadavek je žádost CORS a služba pak ověří pravidla CORS. Pokud se najde shoda, hlavičky Řízení přístupu se přidají do odpovědi a odešlou se zpět klientovi. Pokud se shoda nenajde, vrátí 403 (Forbidden) odpověď indikující chybu původu CORS.

Povolení zásad CORS

Při vytvoření nebo aktualizaci účtu mapy určují jeho vlastnosti povolené zdroje, které se mají konfigurovat. Pravidlo CORS ve vlastnostech účtu Azure Maps můžete nastavit prostřednictvím sady AZURE Maps Management SDK, rozhraní REST API pro správu Služby Azure Maps a portálu. Jakmile nastavíte pravidlo CORS pro službu, vyhodnotí se správně autorizovaný požadavek na službu z jiné domény, abyste zjistili, jestli je povolené podle zadaného pravidla. Příklad:

{
  "location": "eastus",
  "sku": {
    "name": "G2"
  },
  "kind": "Gen2",
  "properties": {
    "cors": {
      "corsRules": [
        {
          "allowedOrigins": [
            "https://www.azure.com",
            "https://www.microsoft.com"
          ]
        }
      ]
    }
  }
}

Lze zadat pouze jedno pravidlo CORS se seznamem povolených zdrojů. Každý zdroj umožňuje provést požadavek HTTP do rozhraní REST API služby Azure Maps ve webovém prohlížeči zadaného původu.

Odebrání zásad CORS

CORS můžete odebrat:

• Ruční na webu Azure Portal
• Programově pomocí:
  • Sada Azure Maps SDK
  • Rozhraní REST API pro správu služby Azure Maps
  • Šablona ARM

{
  "location": "eastus",
  "sku": {
    "name": "G2"
  },
  "kind": "Gen2",
  "properties": {
        "cors": {
          "corsRules": []
        }
    }
  }
}

Vysvětlení fakturačních transakcí

Azure Maps nepočítá fakturační transakce pro:

• Stavové kódy HTTP 5xx
• 401 (Neautorizováno)
• 403 (zakázáno)
• 408 (časový limit)
• 429 (TooManyRequests)
• Předběžné požadavky CORS

Další informace o fakturačních transakcích a dalších cenách Azure Maps najdete v tématu Ceny služby Azure Maps.

Další kroky

Další informace oosvědčených

Další informace o ověřování aplikace pomocí Microsoft Entra ID a Azure Maps najdete tady:

Další informace o ověřování ovládacího prvku Azure Maps pomocí ID Microsoft Entra najdete tady: