Azure Maps による認証

[アーティクル]
09/26/2024

Azure Maps では、要求を認証する 3 つの方法 (共有キー認証、Microsoft Entra ID 認証、Shared Access Signature (SAS) トークン認証) がサポートされています。この記事では、Azure Maps サービスの実装の参考になるように、これらの認証方法について説明します。また、この記事では、Azure Policy のローカル認証の無効化やクロス origin リソース共有 (CORS) など、その他のアカウント制御について説明します。

Note

Azure Maps とのセキュリティで保護された通信を強化するために、TLS (トランスポート層セキュリティ) 1.2 がサポートされるようになりました。TLS 1.0 と 1.1 のサポートは廃止されます。現在 TLS 1.x を使用している場合は、TLS 1.0 の問題の解決に関する記事で説明されているテストを使用して、TLS 1.2 の準備を評価し、移行計画を作成します。

共有キー認証

Azure portal でキーを表示する方法については、「認証の詳細を表示する」をご覧ください。

Azure Maps アカウントの作成後、主キーと 2 次キーが生成されます。共有キー認証を使用して Azure Maps を呼び出す場合は、主キーをサブスクリプションキーとして使用することをお勧めします。共有キー認証では、Azure Maps アカウントによって生成されたキーを Azure Maps サービスに渡します。 Azure Maps サービスへの要求ごとに、サブスクリプションキーをパラメーターとして URL に追加します。 2 次キーは、キーのローリング変更などのシナリオで使用できます。

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

重要

プライマリキーとセカンダリキーは、機微なデータとして扱う必要があります。共有キーは、すべての Azure Maps REST API を認証するために使用されます。共有キーを使用するユーザーは、環境変数またはセキュリティで保護されたシークレットストレージを使用して API キーを抽象化し、一元的に管理できます。

Microsoft Entra 認証

Azure サブスクリプションでは、Microsoft Entra テナントが提供されており、きめ細かなアクセス制御が可能です。 Azure Maps は、Azure Maps サービスでの Microsoft Entra ID を使った認証を提供します。 Microsoft Entra ID では、Microsoft Entra テナントに登録されたユーザーとアプリケーションの ID ベースの認証が可能です。

Azure Maps では、Azure Maps アカウントを含む Azure サブスクリプションに関連付けられている Microsoft Entra テナントの OAuth 2.0 アクセストークンを受け付けます。 Azure Maps は、次のトークンも受け付けます。

Microsoft Entra ユーザー
ユーザーによって委任されたアクセス許可を使用するパートナーアプリケーション
Azure リソースのマネージド ID

Azure Maps では、Azure Maps アカウントごとに一意の識別子 (クライアント ID) を生成します。このクライアント ID を他のパラメーターと組み合わせると、Microsoft Entra ID からトークンを要求できます。

Microsoft Entra ID を構成して Azure Maps のトークンを要求する方法について詳しくは、「Azure Maps での認証の管理」を参照してください。

Microsoft Entra ID による認証に関する一般的な情報については、「認証と認可」を参照してください。

Azure リソースと Azure Maps のマネージド ID

Azure リソースのマネージド ID を使うと、Microsoft Entra ID で認証可能な、自動的に管理されるアプリケーションベースのセキュリティプリンシパルが Azure サービスに提供されます。 Azure ロールベースのアクセス制御 (Azure RBAC) を使用すると、マネージド ID セキュリティプリンシパルに対して、Azure Maps サービスへのアクセスを承認することができます。マネージド ID の例としては、次のものがあります。Azure App Service、Azure Functions、Azure Virtual Machines。マネージド ID の一覧については、「マネージド ID を使用して他のサービスにアクセスできる Azure サービス」を参照してください。マネージド ID の詳細については、「Azure Maps での認証の管理」をご覧ください。

アプリケーション Microsoft Entra 認証を構成する

アプリケーションでは、Microsoft Entra ID に用意されている 1 つ以上のサポートされるシナリオを使って、Microsoft Entra テナントで認証を行います。各 Microsoft Entra アプリケーションシナリオは、ビジネスニーズに基づいたさまざまな要件を表しています。ユーザーのサインインエクスペリエンスを必要とするアプリケーションもあれば、アプリケーションのサインインエクスペリエンスを必要とするアプリケーションもあります。詳細については、「認証フローとアプリケーションのシナリオ」を参照してください。

アプリケーションでアクセストークンが受け取られた後、SDK またはアプリケーションによって HTTPS 要求が送信されます。これには、他の REST API HTTP ヘッダーに加えて次の必須 HTTP ヘッダーが含まれます。

ヘッダー名	値
x-ms-client-id	30d7cc…9f55
承認	Bearer eyJ0e…HNIVN

Note

x-ms-client-id は、Azure Maps 認証ページに表示される Azure Maps アカウントベースの GUID です。

Microsoft Entra ID OAuth ベアラートークンを使用する Azure Maps ルート要求の例を次に示します。

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

クライアント ID を表示する方法については、「認証の詳細を表示する」をご覧ください。

ヒント

プログラムによるクライアント ID の取得

PowerShell を使用する場合、クライアント ID は IMapsAccount オブジェクトの UniqueId プロパティとして格納されます。このプロパティは、Get-AzMapsAccount を使用して取得します。次に例を示します:

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

Azure CLI を使用している場合、 --query パラメーターを指定してaz maps account show コマンドを使用します。次に例を示します:

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

ロールベースのアクセス制御による認証

前提条件

Azure RBAC を使用する場合、Azure ロールベースのアクセス制御 (Azure RBAC) の概要では、プリンシパルの種類にロール定義とも呼ばれる一連のアクセス許可が付与されます。ロールの定義は、REST API アクションに対するアクセス許可を提供します。 Azure Maps は、個別の Microsoft Entra ユーザー、グループ、アプリケーション、Azure リソース、Azure マネージド ID など、Azure ロールベースのアクセス制御 (Azure RBAC) のすべてのプリンシパルの種類へのアクセスをサポートしています。 1 つ以上の Azure Maps アカウントにアクセスを適用することをスコープと呼びます。ロールの割り当ては、プリンシパル、ロールの定義、スコープを適用すると作成されます。

概要

次のセクションでは、Azure Maps と Azure RBAC との統合の概念とコンポーネントについて説明します。 Azure Maps アカウントを設定するプロセスの一環として、Microsoft Entra ディレクトリは、Azure Maps アカウントがある Azure サブスクリプションに関連付けられます。

Azure RBAC を構成する場合、セキュリティプリンシパルを選択して、それをロールの割り当てに適用します。 Azure portal でロールの割り当てを追加する方法については、「Azure portal を使用して Azure ロールを割り当てる」を参照してください。

ロールの定義の選択

アプリケーションシナリオがサポートされるロールの定義の種類は、次のとおりです。

Azure ロールの定義	説明
Azure Maps 検索とレンダリングデータ閲覧者	基本的な Web ブラウザーの使用例へのアクセスを制限するため、Azure Maps REST API のみを検索およびレンダリングするアクセスを提供します。
Azure Maps データ閲覧者	不変の Azure Maps REST API へのアクセスを提供します。
Azure Maps データ共同作成者	変更可能な Azure Maps REST API へのアクセスを提供します。変更可能性は、書き込みおよび削除のアクションによって定義されます。
Azure Maps のデータ読み取りとバッチロール	このロールを使用して、Azure Maps に対して読み取りとバッチの操作を割り当てることができます。
カスタムロールの定義	Azure Maps REST API に対する柔軟な制限付きアクセスを可能にするロールを作成します。

一部の Azure Maps サービスでは、Azure Maps REST API で書き込みまたは削除アクションを実行するために、昇格された特権が必要になる場合があります。 Azure Maps データ共同作成者は、書き込みまたは削除アクションを提供するサービスで必要となります。次の表では、書き込みまたは削除アクションを使用する場合に Azure Maps データ共同作成者を適用できるサービスについて説明します。読み取りアクションのみが必要な場合は、Azure Maps データ共同作成者ロールの代わりに、Azure Maps データ閲覧者ロールを使用できます。

Azure Maps サービス	Azure Maps ロールの定義
Creator (非推奨¹)	Azure Maps データ共同作成者
Spatial (非推奨¹)	Azure Maps データ共同作成者
バッチ検索とルート	Azure Maps データ共同作成者

¹ Azure Maps Creator、Data Registry、Spatial の各サービスは非推奨となり、2025 年 9 月 30 日に廃止されます。

Azure RBAC 設定を確認する方法については、Azure Maps 用に Azure RBAC を構成する方法に関するページをご覧ください。

カスタムロールの定義

アプリケーションのセキュリティの 1 つの側面は、最小限の特権の原則です。これは、アクセス権を現在のジョブに必要なものだけに制限するという方法です。アクセス権を制限するには、より細分性の高いアクセス制御が必要なユースケースをサポートするカスタムロールの定義を作成します。カスタムロールの定義を作成するには、その定義に含まれる、またはその定義から除外される特定のデータアクションを選択します。

カスタムロールの定義は、セキュリティプリンシパルのロールの割り当てで使用できます。 Azure カスタムロールの定義の詳細については、「Azure カスタムロール」を参照してください。

カスタムロールによってアプリケーションのセキュリティを向上できるシナリオ例をいくつか紹介します。

シナリオ	カスタムロールのデータアクション
ベースマップタイルがあり、他の REST API がない一般公開用またはインタラクティブなサインイン Web ページ。	`Microsoft.Maps/accounts/services/render/read`
リバースジオコーディングのみを必要として、他の REST API を必要としないアプリケーション。	`Microsoft.Maps/accounts/services/search/read`
Azure Maps ベースのマップデータの読み取りと基本マップタイル REST API を要求するセキュリティプリンシパルのロール。	`Microsoft.Maps/accounts/services/data/read`、`Microsoft.Maps/accounts/services/render/read`
作成者ベースのマップデータの読み取り、書き込み、削除を要求するセキュリティプリンシパルのロール。マップデータ編集者のロールとして定義できますが、基本マップタイルなどの他の REST API へのアクセスは許可されません。	`Microsoft.Maps/accounts/services/data/read`、`Microsoft.Maps/accounts/services/data/write`、`Microsoft.Maps/accounts/services/data/delete`

スコープを理解する

ロールの割り当てを作成する場合、Azure リソースの階層内で定義されます。この階層の最上位は管理グループで、最下位は Azure Maps アカウントなどの Azure リソースです。ロールの割り当てをリソースグループに割り当てると、グループ内の複数の Azure Maps アカウントまたはリソースにアクセスできるようになります。

ヒント

Microsoft の一般的な推奨事項は、Azure Maps アカウントスコープへのアクセスを割り当てることです。これにより、同じ Azure サブスクリプション内にある他の Azure Maps アカウントへの意図しないアクセスを防止するためです。

ローカル認証の無効化

Azure Maps アカウントでは、Microsoft.Maps/accounts 用の Management API で、disableLocalAuth という名前の標準 Azure プロパティがサポートされます。 true の場合、Microsoft Entra 認証を除き、Azure Maps データプレーン REST API に対するすべての認証が無効になります。これは、共有キーと SAS トークンの配布と管理を制御するために、Azure Policy を使用して構成されます。詳細については、「Azure Policy とは」を参照してください。

ローカル認証を無効にしても、すぐに効果が現れるわけではありません。このサービスによって将来の認証要求がブロックされるようになるまで数分かかります。ローカル認証を再度有効にするには、プロパティを false に設定します。数分後、ローカル認証が再開します。

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

Shared Access Signature トークン認証

Shared Access Signature (SAS) トークンは、JSON Web トークン (JWT) 形式を使用して作成された認証トークンであり、Azure Maps REST API に対するアプリケーションの認証を証明するために暗号化され署名されます。 SAS トークンは、ユーザー割り当てマネージド ID を Azure サブスクリプション内の Azure Maps アカウントに統合することで作成されます。ユーザー割り当てマネージド ID には、Azure RBAC の組み込みロール定義またはカスタムロール定義のいずれかを使用して、Azure Maps アカウントに対する承認が付与されます。

SAS トークンと Microsoft Entra アクセストークンには、次のような機能の違いがあります。

1 日間 (24 時間) の最大有効期限のトークンの有効期間。
トークンあたりの Azure の場所と地域のアクセス制御。
1 秒あたり約 1 ~ 500 要求のトークンあたりのレート制限。
トークンの秘密キーは、Azure Maps アカウントリソースのプライマリキーとセカンダリキーです。
承認のサービスプリンシパルオブジェクトは、ユーザー割り当てマネージド ID によって提供されます。

SAS トークンは変更できません。つまり、トークンが作成されると、有効期限が満たされるまで SAS トークンが有効になり、許可されるリージョン、レート制限、ユーザー割り当てマネージド ID の構成を変更できません。 SAS トークン失効のアクセス制御およびアクセス制御の変更については、以下を参照してください。

SAS トークンのレート制限について

SAS トークンの最大レート制限により、Azure Maps リソースの課金を制御できます

トークンの最大レート制限 (maxRatePerSecond) を指定すると、レートの超過分がアカウントに請求されないため、トークンの使用時にアカウントに対して請求可能なトランザクションの上限を設定できます。ただし、アプリケーションはこの上限に達すると、すべてのトランザクションに対して 429 (TooManyRequests) のクライアントエラー応答を受け取ります。アプリケーションは、SAS トークンの再試行と配布を管理する責任があります。アカウントに対して作成できる SAS トークンの数に制限はありません。既存のトークンの制限の増減を可能にするため。新しい SAS トークンを作成する必要があります。古い SAS トークンは有効期限が切れるまで有効です。

推測例:

1 秒あたりの概算最大レート	1 秒あたりの実際のレート	持続レートの継続時間 (秒)	請求可能なトランザクションの合計
10	20	600	6,000

実際のレート制限は、一定時間内に一貫性を適用する Azure Maps 機能によって異なります。ただし、これにより、課金コストを予防的に制御できます。

レート制限は、グローバルまたは地理的にではなく、Azure の場所ごとに適用されます

たとえば、maxRatePerSecond が 10 の単一の SAS トークンを使用して、East US の場所のスループットを制限できます。 West US 2 で同じトークンが使用されている場合は、East US の場所に依存しない、その場所のスループットを 10 に制限する新しいカウンターが作成されます。コストを制御し、予測可能性を向上させるために、次の作業をお勧めします:

ターゲット地域に対して許可されている Azure の場所を指定して SAS トークンを作成します。 SAS トークンの作成については、引き続きお読みください。
地理的なデータプレーン REST API の https://us.atlas.microsoft.com または https://eu.atlas.microsoft.com を使用します。

エンドポイント https://us.atlas.microsoft.com が、Azure Maps サービスがホストされているのと同じ米国の場所 (East US、West Central US、West US 2 など) にルーティングするアプリケーショントポロジを検討してください。 West Europe と North Europe の間の https://eu.atlas.microsoft.com など、他の地理的エンドポイントにも同じ考えが適用されます。予期しない認可拒否を防ぐには、アプリケーションが使用するのと同じ Azure の場所を使用する SAS トークンを使用します。エンドポイントの場所は、Azure Maps Management REST API を使用して定義されます。

既定のレート制限は、SAS トークンのレート制限よりも優先されます

Azure Maps マップレート制限で説明したように、個々のサービス内容には、アカウントの集計として適用されるさまざまなレート制限があります。

次の表に示すように 1 秒あたり 250 クエリ (QPS) という制限がある Search Service - バッチ以外の逆引きの場合を考えてみます。各テーブルは、使用例からの成功したトランザクションの推定合計を表します。

最初の表は、1 秒あたりの最大要求数が 500 件の 1 つのトークンを示しています。アプリケーションの実際の使用量は、1 秒あたりの要求数が 500 件、継続時間が 60 秒でした。 Search Service - バッチ以外の逆引きのレート制限は 250 です。つまり、60 秒間に合計 30,000 件の要求が行われても、そのうちの 15,000 件が請求対象トランザクションとなります。残りの要求は、状態コード 429 (TooManyRequests) になります。

名前	1 秒あたりの概算最大レート	1 秒あたりの実際のレート	持続レートの継続時間 (秒)	成功したトランザクションの概算合計
token	500	500	60	~15,000

たとえば、2 つの SAS トークンが作成され、Azure Maps アカウントと同じ場所を使用する場合、各トークンは既定のレート制限である 250 QPS を共有します。各トークンが同じスループットトークン 1 で同時に使用され、トークン 2 によってそれぞれ 7,500 件の成功したトランザクションが正常に許可される場合。

名前	1 秒あたりの概算最大レート	1 秒あたりの実際のレート	持続レートの継続時間 (秒)	成功したトランザクションの概算合計
トークン 1	250	250	60	～7500
トークン 2	250	250	60	～7500

SAS トークンのアクセス制御について

SAS トークンでは、RBAC を使用して、REST API へのアクセスを制御します。 SAS トークンを作成すると、マップアカウントの前提条件となるマネージド ID に、特定の REST API アクションへのアクセスを許可する Azure RBAC ロールが付与されます。アプリケーションで許可する API を決定する方法については、「ロールの定義の選択」を参照してください。

一時的なアクセス権を割り当て、SAS トークンの有効期限が切れる前にアクセス権を削除する場合は、トークンを取り消します。アクセス権を取り消すその他の理由は、トークンが意図せずに Azure Maps Data Contributor ロールの割り当てで配布され、SAS トークンを持つすべてのユーザーが Azure マップ REST API に対してデータの読み取りおよび書き込みを実行できる可能性がある場合があります。この API は、機密データや予期しない財務コストを使用状況から公開する可能性があります。

SAS トークンのアクセスを取り消すオプションは 2 つがあります:

マップアカウントの SAS トークンまたは secondaryKey によって使用されたキーを再生成します。
関連付けられているマップアカウントのマネージド ID のロールの割り当てを削除します。

警告

SAS トークンによって使用されるマネージド ID を削除したり、マネージド ID のアクセス制御を取り戻したりすると、SAS トークンとマネージド ID を使用するアプリケーションのインスタンスは、アプリケーションの中断を引き起こす Azure Maps REST API から意図的に、401 Unauthorized または 403 Forbiddenが返されます。

中断を回避するには:

2 つ目のマネージド ID をマップアカウントに追加し、新しいマネージド ID に正しいロールの割り当てを付与します。
secondaryKey または以前のものとは異なるマネージド ID を使って signingKey として SAS トークンを作成し、新しい SAS トークンをアプリケーションに配布します。
主キーを再生成し、アカウントからマネージド ID を削除し、マネージド ID のロールの割り当てを削除します。

SAS トークンを作成する

SAS トークンを作成するには、Azure サブスクリプションで Azure Maps アカウントとユーザー割り当て ID の両方を管理するための Contributor ロールアクセス権が必要です。

重要

Azure 保存先の global で作成される既存の Azure Maps アカウントでは、マネージド ID はサポートされていません。

まず、Azure Maps アカウントと同じ場所にユーザー割り当てマネージド ID を作成します。

ヒント

マネージド ID と Azure Maps アカウントの両方に同じ場所を使用する必要があります。

マネージド ID が作成されると、Azure Maps アカウントを作成または更新してアタッチできます。詳細については、「Azure Maps アカウントを管理する」を参照してください。

マネージド ID を使ってアカウントを正常に作成または更新したら、マネージド ID のロールベースのアクセス制御を、アカウントスコープで Azure Maps データロールに割り当てます。これにより、マネージド ID にマップアカウントの Azure Maps REST API アクセス権を与えられる可能性があります。

次に、Azure Management SDK ツール、アカウント管理 API での SAS 操作の一覧表示、または Azure portal でマップアカウントリソースの [Shared Access Signature] ページを使用して、SAS トークンを作成します。

SAS トークンパラメーター:

パラメーター名	値の例	説明
signingKey	`primaryKey`	必須。`primaryKey`、`secondaryKey`、またはマネージドキーを使用して SAS の署名を作成する signingKey の文字列列挙値。
principalId	`<GUID>`	必須。principalId は、マップアカウントにアタッチされているユーザー割り当てマネージド ID のオブジェクト (プリンシパル) ID です。
regions	`[ "eastus", "westus2", "westcentralus" ]`	省略可能。既定値は `null` です。 Azure Maps REST データプレーン API で SAS トークンを使用できるリージョンがどのリージョンかを制御します。リージョンパラメーターを省略すると、制約なしで SAS トークンを使用できます。 `us.atlas.microsoft.com` や `eu.atlas.microsoft.com` のような、Azure Maps データプレーンの地理的エンドポイントと組み合わせて使用すると、指定した地域の使用状況をアプリケーションで制御できます。これにより、他の地域での使用を防止できます。
maxRatePerSecond	500	必須。SAS トークンが付与される 1 秒あたりの指定した概数の最大要求数。上限に達すると、追加のスループットは HTTP 状態コード `429 (TooManyRequests)` でレート制限されます。
start	`2021-05-24T10:42:03.1567373Z`	必須。トークンがアクティブになる日時を指定する UTC 日付。
expiry	`2021-05-24T11:42:03.1567373Z`	必須。トークンが期限切れになる日時を指定する UTC 日付。開始から有効期限の間の期間は、24 時間を超えてはなりません。

SAS トークンを使用したアプリケーションの構成

アプリケーションで SAS トークンが受け取られた後、Azure Maps SDK またはアプリケーションによって HTTPS 要求が送信されます。これには、他の REST API HTTP ヘッダーに加えて次の必須 HTTP ヘッダーが含まれます:

ヘッダー名	値
承認	jwt-sas eyJ0e….HNIVN

注意

jwt-sas は、SAS トークンの使用を示す認証スキームです。その他の x-ms-client-id Authorization ヘッダーまたは subscription-key クエリ文字列パラメーターは含まれません。

CORS は、あるドメインで実行されている Web アプリケーションが別のドメイン内にあるリソースにアクセスできるようにする HTTP プロトコルです。 Web ブラウザーには、Web ページで別のドメインの API を呼び出すことができないようにする同一呼び出し元ポリシーと呼ばれるセキュリティ制限が実装されています。CORS を使用すると、あるドメイン (元のドメイン) から別のドメインの API を安全に呼び出すことができます。 Azure Maps アカウントリソースを使用して、どの origin が、アプリケーションから Azure Maps REST API にアクセスすることを許可されているかを構成できます。

重要

CORS は承認メカニズムではありません。 CORS が有効になっている場合に REST API を使用してマップアカウントに対して行われたすべての要求には、共有キー、Microsoft Entra ID、SAS トークンなどの有効なマップアカウント認証スキームも必要です。

CORS は、すべてのマップアカウントの価格レベル、データプレーンエンドポイント、および場所でサポートされています。

前提条件

最新のブラウザーでは、クライアントで悪意のあるコードが実行されるのを防ぐために、Web アプリケーションから別のドメインで実行されるリソースへの要求をブロックします。

CORS に慣れていない場合は、クロス origin リソース共有 (CORS) を参照してください。これにより、Azure Maps アカウントのエンドポイントの呼び出しが許可されている origin を Access-Control-Allow-Origin ヘッダーで宣言できます。 CORS プロトコルは、Azure Maps 固有ではありません。

CORS 要求

元のドメインからの CORS 要求は、次の 2 つの異なる要求で構成されている場合があります。

サービスによって課されている CORS の制限を照会するプレフライト要求。要求が標準のメソッド GET、HEAD、POST でない場合、または Authorization 要求ヘッダーを含む要求ではない場合は、プレフライト要求が必要です。
目的のリソースに対して行う実際の要求。

プレフライト要求

プレフライト要求は、サーバーが実際の要求で送信されるメソッドとヘッダーを確実に理解し、要求のソースを把握して信頼し、マップアカウントに対して確立された CORS 制限を照会するためのセキュリティ対策として行われます。 Web ブラウザー (または他のユーザーエージェント) は、要求ヘッダー、メソッド、元のドメインを含む OPTIONS 要求を送信します。アカウント認証が CORS プレフライトプロトコルを介して可能な場合、マップアカウントサービスは CORS ルールをフェッチします。

認証できない場合、マップサービスはあらかじめ構成された一連の CORS ルールを評価します。この CORS ルールには、マップサービスに対する実際の要求で指定できる origin ドメイン、要求メソッド、要求ヘッダーが指定されています。既定では、すべての origin が Web ブラウザーへのシームレスな統合を可能にするようにマップアカウントが構成されています。

サービスは、次の条件が満たされた場合に、必須の Access-Control ヘッダーを使用してプレフライト要求に応答します。

OPTIONS 要求には、必要な CORS ヘッダー (origin およびアクセス制御要求メソッドヘッダーが含まれています)
認証が成功し、プレフライト要求に一致するアカウントに対して CORS ルールが有効になりました。
プレフライト要求では指定できない必須の Authorization 要求ヘッダーにより、認証がスキップされました。

プレフライト要求が成功すると、サービスは状態コード 200 (OK) で応答し、要求された Access-Control ヘッダーを応答に含めます。

次の状況が発生した場合、サービスはプレフライト要求を拒否します。

OPTIONS 要求に必須の CORS ヘッダー (Origin ヘッダーと Access-Control-Request-Method ヘッダー) が含まれていない場合、サービスはステータスコード 400 (Bad request) で応答します。
プレフライト要求で認証が成功し、プレフライト要求と一致する CORS ルールがない場合、サービスは状態コード 403 (Forbidden) で応答します。これは、CORS ルールが、現在のブラウザークライアント origin 要求ヘッダーと一致しない origin を受け入れるように構成されている場合に発生する可能性があります。

注意

プレフライト要求は、要求されたリソースではなく、サービスに対して評価されることに注意してください。要求を正常に終了させるには、アカウント所有者が適切なアカウントプロパティを設定することで CORS を有効にしておく必要があります。

実際の要求

プレフライト要求が受け入れられ、応答が返されると、ブラウザーはマップサービスに対する実際の要求をディスパッチします。プレフライト要求が拒否されると、ブラウザーは実際の要求を直ちに拒否します。

実際の要求は、マップサービスに対する通常の要求として扱われます。 Origin ヘッダーが存在する場合は要求が CORS 要求であることを示しており、サービスは CORS ルールに照らした検証を行います。一致が見つかった場合は、Access-Control ヘッダーを応答に追加し、クライアントに送り返します。一致が見つからない場合、CORS origin エラーを示す 403 (Forbidden) で応答が返されます。

CORS ポリシーを有効にする

マップアカウントが作成または更新されると、そのプロパティによって、構成が必要な許可された origin が指定されます。 CORS ルールは、Azure Maps 管理 SDK、Azure Maps 管理 REST API、およびポータルを使用して、Azure Maps アカウントのプロパティで設定できます。サービスに対して CORS ルールを設定した場合、別のドメインからサービスに対して行われた要求が正しく認可されると、指定したルールに従ってその要求を許可するかどうかが評価されます。次に例を示します。

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

指定できるのは、許可された origin のリストを持つ 1 つの CORS ルールだけです。各 origin では、指定された origin の web ブラウザーで Azure Maps REST API に対してなされる HTTP 要求を行うことができます。

CORS ポリシーの削除

CORS は次の方法で削除できます。

Azure portal で手動で行う
次を使用してプログラムで行う
- Azure Maps SDK
- Azure Maps 管理 REST API
- ARM テンプレート

ヒント

Azure Maps 管理 REST API を使用する場合は、要求本文に空の corsRule リストを指定して PUT または PATCH を使用します。

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

課金トランザクションについて

Azure Maps では、次の請求トランザクションがカウントされません:

5xx HTTP 状態コード
401 (許可されていません)
403 (許可されていません)
408 (タイムアウト)
429 (TooManyRequests)
CORS プレフライト要求

請求トランザクションとその他の Azure Maps の価格情報の詳細については、「Azure Maps の価格」を参照してください。

次のステップ

セキュリティのベストプラクティスの詳細については、次の記事を参照してください。

認証と承認のベストプラクティス

Microsoft Entra ID と Azure Maps を使用してアプリケーションを認証する方法の詳細については、次の記事を参照してください。

Azure Maps での認証の管理

Microsoft Entra ID を使用した Azure Maps コントロールの認証の詳細については、次の記事を参照してください。

Azure Maps のマップコントロールを使用する

次の方法で共有

Azure Maps による認証

共有キー認証

Microsoft Entra 認証

Azure リソースと Azure Maps のマネージド ID

アプリケーション Microsoft Entra 認証を構成する

ロールベースのアクセス制御による認証

前提条件

概要

ロールの定義の選択

カスタムロールの定義

スコープを理解する

ローカル認証の無効化

Shared Access Signature トークン認証

SAS トークンのレート制限について

SAS トークンの最大レート制限により、Azure Maps リソースの課金を制御できます

レート制限は、グローバルまたは地理的にではなく、Azure の場所ごとに適用されます

既定のレート制限は、SAS トークンのレート制限よりも優先されます

SAS トークンのアクセス制御について

SAS トークンを作成する

SAS トークンを使用したアプリケーションの構成

前提条件

CORS 要求

プレフライト要求

実際の要求

CORS ポリシーを有効にする

CORS ポリシーの削除

課金トランザクションについて

次のステップ

フィードバック

その他のリソース

次の方法で共有

Azure Maps による認証

共有キー認証

Microsoft Entra 認証

Azure リソースと Azure Maps のマネージド ID

アプリケーション Microsoft Entra 認証を構成する

ロールベースのアクセス制御による認証

前提条件

概要

ロールの定義の選択

カスタム ロールの定義

スコープを理解する

ローカル認証の無効化

Shared Access Signature トークン認証

SAS トークンのレート制限について

SAS トークンの最大レート制限により、Azure Maps リソースの課金を制御できます

レート制限は、グローバルまたは地理的にではなく、Azure の場所ごとに適用されます

既定のレート制限は、SAS トークンのレート制限よりも優先されます

SAS トークンのアクセス制御について

SAS トークンを作成する

SAS トークンを使用したアプリケーションの構成

クロス origin リソース共有 (CORS)

前提条件

CORS 要求

プレフライト要求

実際の要求

CORS ポリシーを有効にする

CORS ポリシーの削除

課金トランザクションについて

次のステップ

フィードバック

その他のリソース

カスタムロールの定義