向 Azure 地圖服務驗證

發行項
03/20/2024

Azure 地圖服務支援三種方式來驗證要求：共用金鑰驗證、Microsoft Entra ID 驗證，以及共用存取簽章 (SAS) 權杖驗證。本文說明這些驗證方法，協助指導 Azure 地圖服務的實作。本文也會說明其他帳戶控制項，例如停用 Azure 原則和跨原點資源共用 (CORS) 的本機驗證。

注意

為了改善與 Azure 地圖服務的安全通訊，我們現在支援傳輸層安全性 (TLS) 1.2，並淘汰 TLS 1.0 和 1.1 的支援。如果您目前使用 TLS 1.x，請評估 TLS 1.2 整備程度，並使用解決 TLS 1.0 問題中所述的測試來開發移轉計畫。

共用金鑰驗證

如需在 Azure 入口網站中檢視金鑰的相關資訊，請參閱檢視驗證詳細資料。

建立 Azure 地圖服務帳戶之後，會產生主要和次要金鑰。當您使用共用金鑰驗證呼叫 Azure 地圖服務時，建議您使用主要金鑰做為訂用帳戶金鑰。共用金鑰驗證會將 Azure 地圖服務帳戶所產生的金鑰傳遞至 Azure 地圖服務。對於 Azure 地圖服務的每個要求，請將訂用帳戶金鑰新增為 URL 的參數。在輪替金鑰變更等情節中，可以使用次要金鑰。

在 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 地圖服務 REST API。使用共用金鑰的使用者應該透過環境變數或安全祕密儲存體，將 API 金鑰抽象化，以便集中管理。

Microsoft Entra 驗證

Azure 訂用帳戶會與 Microsoft Entra 租用戶一起提供，以實現更精細的存取控制。 Azure 地圖服務會使用 Microsoft Entra ID 為 Azure 地圖服務提供驗證。 Microsoft Entra ID 會為在 Microsoft Entra 租用戶中註冊的使用者和應用程式提供身分識別型驗證。

針對與包含 Azure 地圖服務帳戶的 Azure 訂用帳戶相關聯的 Microsoft Entra 租用戶，Azure 地圖服務可接受 OAuth 2.0 存取權杖。 Azure 地圖服務也可接受下列項目的權杖：

Microsoft Entra 使用者
使用使用者所委派權限的合作夥伴應用程式
適用於 Azure 資源的受控識別

Azure 地圖服務會為每個 Azure 地圖服務帳戶產生「唯一識別碼 (用戶端識別碼)」。當您將此用戶端識別碼與其他參數結合時，您可以從 Microsoft Entra ID 要求權杖。

如需如何為 Azure 地圖服務設定 Microsoft Entra ID 和要求權杖的詳細資訊，請參閱管理 Azure 地圖服務中的驗證。

如需使用 Microsoft Entra ID 進行驗證的一般資訊，請參閱驗證與授權。

Azure 資源和 Azure 地圖服務的受控識別

適用於 Azure 資源的受控識別可為 Azure 服務提供可向 Microsoft Entra ID 進行驗證的自動受控應用程式型安全性主體。透過 Azure 角色型存取控制 (Azure RBAC)，受控識別安全性主體可以獲授權存取 Azure 地圖服務。受控識別的一些範例包括：Azure App 服務、Azure Functions 和 Azure 虛擬機器。如需受控識別的清單，請參閱可以使用受控識別來存取其他服務的 Azure 服務。如需受控識別的詳細資訊，請參閱管理 Azure 地圖服務中的驗證。

設定應用程式 Microsoft Entra 驗證

應用程式會使用 Microsoft Entra ID 提供的一或多個支援情節，向 Microsoft Entra 租用戶進行驗證。每個 Microsoft Entra 應用程式情節都會根據業務需求來代表不同的需求。某些應用程式可能需要使用者登入體驗，而其他應用程式可能需要應用程式登入體驗。如需詳細資訊，請參閱驗證流程和應用程式情節。

應用程式收到存取權杖之後，SDK 和/或應用程式除了其他 REST API HTTP 標頭之外，還會傳送具有下列一組必要 HTTP 標頭的 HTTPS 要求：

標頭名稱	值
x-ms-client-id	30d7cc…9f55
授權	Bearer eyJ0e…HNIVN

注意

x-ms-client-id 是以 Azure 地圖服務帳戶為基礎的 GUID，其顯示在 Azure 地圖服務的驗證頁面上。

以下是使用 Microsoft Entra ID OAuth 持有人權杖的 Azure 地圖服務路由要求範例：

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

如需檢視用戶端識別碼的相關資訊，請參閱檢視驗證詳細資料。

提示

以程式設計方式取得用戶端識別碼

使用 PowerShell 時，用戶端識別碼會儲存為 IMapsAccount 物件中的 UniqueId 屬性。您可以使用 Get-AzMapsAccount 擷取此屬性，例如：

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

例如，使用 Azure CLI，將 az maps account show 命令與 --query 參數搭配使用時：

$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 地圖服務支援存取 Azure 角色型存取控制 (Azure RBAC) 的所有主體型別，包括：個別的 Microsoft Entra 使用者、群組、應用程式、Azure 資源和 Azure 受控識別。將存取權套用至一或多個 Azure 地圖服務帳戶稱為範圍。套用主體、角色定義和範圍時，即會建立角色指派。

概觀

下一節將討論 Azure 地圖服務與 Azure RBAC 整合的概念和元件。在設定 Azure 地圖服務帳戶的過程中，Microsoft Entra 目錄會與 Azure 地圖服務帳戶所在的 Azure 訂用帳戶相關聯。

當您設定 Azure RBAC 時，您可以選擇安全性主體，並將其套用至角色指派。若要瞭解如何在 Azure 入口網站上新增角色指派，請參閱使用 Azure 入口網站指派 Azure 角色。

挑選角色定義

下列角色定義類型存在，可支援應用程式情節。

Azure 角色定義	描述
Azure 地圖服務搜尋及轉譯器資料讀取器	僅提供搜尋和轉譯 Azure 地圖服務 REST API 的存取權，以限制對基本網頁瀏覽器使用案例的存取。
Azure 地圖服務資料讀者	提供不可變 Azure 地圖服務 REST API 的存取權。
Azure 地圖服務資料參與者	提供不可變 Azure 地圖服務 REST API 的存取權。可變動性是由動作所定義：寫入和刪除。
Azure 地圖服務資料讀取和批次角色	此角色可用來在 Azure 地圖服務上指派讀取和批次動作。
自訂角色定義	建立製作的角色，以彈性地限制對 Azure 地圖服務 REST API 的存取。

某些 Azure 地圖服務服務可能需要提高的權限，才能對 AZURE 地圖服務 REST API 執行寫入或刪除動作。服務需要 Azure 地圖服務資料參與者角色，以提供寫入或刪除動作。下表說明在使用寫入或刪除動作時，Azure 地圖服務資料參與者適用哪些服務。只需要讀取動作時，可以使用 Azure 地圖服務資料讀取者角色來取代 Azure 地圖服務資料參與者角色。

Azure 地圖服務	Azure 地圖服務角色定義
Creator (已取代¹)	Azure 地圖服務資料參與者
空間 (已取代¹)	Azure 地圖服務資料參與者
批次搜尋和路由	Azure 地圖服務資料參與者

¹ Azure 地圖服務 Creator 及資料登錄和空間服務現已被取代，將於 9/30/25 被取代。

如需檢視 Azure RBAC 設定的相關資訊，請參閱如何設定 Azure 地圖服務的 Azure RBAC。

自訂角色定義

應用程式安全性的其中一個層面是最低權限原則，做法是將存取權限限制為目前的作業所需要的權限。若要限制存取權限，請建立支援使用案例的自訂角色定義，這需要更精細的存取控制。若要建立自訂角色定義，請選取要包含或排除定義的特定資料動作。

然後，自訂角色定義可以用於任何安全性主體的角色指派中。若要深入瞭解 Azure 自訂角色定義，請參閱 Azure 自訂角色。

以下是自訂角色可以改善應用程式安全性的一些範例情節。

案例	自訂角色資料動作
具有基底地圖底圖的公開或互動式登入網頁，且沒有其他 REST API。	`Microsoft.Maps/accounts/services/render/read`
只需要反向地理編碼且不需要其他 REST API 的應用程式。	`Microsoft.Maps/accounts/services/search/read`
安全性主體的角色，要求讀取以 Azure 地圖服務建立者為基礎的地圖資料和基底地圖底圖 REST API。	%
安全性主體的角色，需要讀取、寫入和刪除以建立者為基礎的地圖資料。定義為地圖資料編輯器角色，不允許存取基底地圖底圖之類的其他 REST API。	`Microsoft.Maps/accounts/services/data/read` },

了解範圍

建立角色指派時，會在 Azure 資源階層中提供其定義。階層頂端是管理群組，最低層是 Azure 資源，例如 Azure 地圖服務帳戶。將角色指派指派給資源群組，可以存取群組中的多個 Azure 地圖服務帳戶或資源。

提示

Microsoft 的一般建議是將存取權指派給 Azure 地圖服務帳戶範圍，因為其可防止非預期存取相同 Azure 訂用帳戶中現有的其他Azure 地圖服務帳戶。

停用本機驗證

Azure 地圖服務帳戶針對名為 disableLocalAuth 的 Microsoft.Maps/accounts，在管理 API 中支援標準 Azure 屬性。當 true 時，Azure 地圖服務資料平面 REST API 的所有驗證都會停用，但 Microsoft Entra 驗證除外。這是使用Azure 原則來設定，以控制共用金鑰和 SAS 權杖的散發和管理。如需詳細資訊，請參閱何謂 Azure 原則？。

停用本地驗證不會立即生效。允許服務的幾分鐘來封鎖未來的驗證要求。若要重新啟用本機驗證，請將屬性設定為 false，並在幾分鐘後繼續本機驗證。

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

共用存取簽章權杖驗證

共用存取簽章 (SAS) 權杖是使用 JSON Web 權杖 (JWT) 格式建立的驗證權杖，並以密碼編譯方式簽署，以向 Azure 地圖服務 REST API 證明應用程式的驗證。系統會藉由整合使用者指派的受控識別與 Azure 訂用帳戶中的 Azure 地圖服務帳戶，以建立 SAS 權杖。使用者指派的受控識別會使用內建或自訂角色定義，透過 Azure RBAC 授與 Azure 地圖服務帳戶的授權。

SAS 權杖與 Microsoft Entra 存取權杖的功能主要差異：

權杖的存留期上限為一天 (24 小時)。
每個權杖的 Azure 位置和地理位置存取控制。
每個權杖的速率限制大約每秒 1 到 500 個要求。
權杖的私密金鑰是 Azure 地圖服務帳戶資源的主要和次要金鑰。
授權的服務主體物件是由使用者指派的受控識別所提供。

SAS 權杖是不可變的。這表示一旦建立了權杖，SAS 權杖直到到期以前會一直有效，而且允許之區域、速率限制以及使用者指派的受控識別設定都無法變更。請閱讀以下的瞭解 SAS 權杖撤銷的存取控制和存取控制的變更。

瞭解 SAS 權杖速率限制

SAS 權杖最大速率限制可以控制Azure 地圖服務資源的計費

若在權杖 (maxRatePerSecond) 上指定最大速率限制，則在使用權杖時就不會以超額費率向帳戶計費，讓您可以設定帳戶可計費交易的上限。但在達到上限後的所有交易，應用程式都會收到 429 (TooManyRequests) 的用戶端錯誤回應。應用程式必須負責管理 SAS 權杖的重試和散發。一個帳戶可以建立的 SAS 權杖數目沒有限制。若要允許增加或減少現有權杖限制，必須建立新的 SAS 權杖。舊的 SAS 權杖在到期之前仍持續有效。

估計範例：

每秒速率上限近似值	每秒實際速率	持續速率的持續時間 (以秒為單位)	可計費交易總數
10	20	600	6,000

實際速率限制會視 Azure 地圖服務在一段時間內強制執行一致性的能力而有所不同。不過，這允許對計費成本進行預防性控制。

每個 Azure 位置 (而不是全域或地理位置) 都會強制執行速率限制

例如，具有 10 個 maxRatePerSecond 的單一 SAS 權杖可用來限制 East US 位置中的輸送量。如果在 West US 2 中使用相同的權杖，則會建立新的計數器，以將該位置的輸送量限制為 10，與 East US 位置無關。若要控制成本並改善可預測性，建議您：

針對目標地理位置建立具有指定允許 Azure 位置的 SAS 權杖。繼續閱讀以瞭解 SAS 權杖的建立。
使用地理資料平面 REST API 端點 (https://us.atlas.microsoft.com 或 https://eu.atlas.microsoft.com)。

請考慮應用程式拓撲，其中端點 https://us.atlas.microsoft.com 會路由至裝載 Azure 地圖服務的相同美國位置，例如 East US、West Central US 或 West US 2。相同的概念適用於其他地理端點，例如介於 West Europe 和 North Europe 之間的 https://eu.atlas.microsoft.com。若要防止非預期的授權拒絕，請使用其 Azure 位置與應用程式取用位置相同的 SAS 權杖。端點位置是使用 Azure 地圖服務管理 REST API 來定義。

預設速率限制優先於 SAS 權杖速率限制

如 Azure 地圖服務速率限制中所述，個別服務供應項目有不同的速率限制，系統會以帳戶的彙總形式強制執行這些限制。

請考慮搜尋服務 - 非批次反向案例，其限制為下表的每秒 250 個查詢 (QPS)。每個資料表都代表範例使用方式中預估的成功交易總數。

第一個資料表顯示一個權杖，其每秒要求上限為 500，然後應用程式的實際使用量為每秒 500 個要求，持續時間為 60 秒。 搜尋服務 - 非批次反向的速率限制為 250，這表示在 60 秒內發出的要求總計為 30000 個；15000 個要求將會是可計費的交易。其餘要求將會導致狀態碼 429 (TooManyRequests)。

名稱	每秒速率上限近似值	每秒實際速率	持續速率的持續時間 (以秒為單位)	大約的成功交易總計
token	500	500	60	~15,000

例如，如果建立兩個 SAS 權杖，並使用與 Azure 地圖服務帳戶相同的位置，則每個權杖現在都會共用預設速率限制 250 QPS。如果每個權杖同時使用相同的輸送量權杖 1 和權杖 2，則每個權杖都會成功授與 7500 個成功交易。

名稱	每秒速率上限近似值	每秒實際速率	持續速率的持續時間 (以秒為單位)	大約的成功交易總計
權杖 1	250	250	60	~7500
權杖 2	250	250	60	~7500

瞭解 SAS 權杖存取控制

SAS 權杖會使用 RBAC 來控制 REST API 的存取。當您建立 SAS 權杖時，地圖帳戶上的必要條件受控識別會獲指派 Azure RBAC 角色，以授與特定 REST API 動作的存取權。請參閱挑選角色定義，以判斷應用程式允許的 API。

如果您想要在 SAS 權杖到期之前指派暫時存取權並移除存取權，請撤銷權杖。撤銷存取權的其他原因可能是，如果以非預期的方式使用 Azure Maps Data Contributor 角色指派散發權杖，且具有 SAS 權杖的任何人都可以將資料讀取和寫入 Azure 地圖服務 REST API，這可能會公開敏感性資料或因使用方式而發生非預期的財務成本。

有兩個選項可撤銷 SAS 權杖的存取權：

重新產生 SAS 權杖所使用的金鑰，或地圖帳戶的 secondaryKey。
移除相關聯地圖帳戶上受控識別的角色指派。

警告

刪除 SAS 權杖所使用的受控識別，或撤銷受控識別的存取控制，會導致使用 SAS 權杖和受控識別的應用程式執行個體從 Azure 地圖服務 REST API 刻意傳回 401 Unauthorized 或 403 Forbidden，進而造成應用程式中斷。

若要避免中斷：

將第二個受控識別新增至地圖帳戶，並將正確的角色指派授與新的受控識別。
使用 secondaryKey 建立 SAS 權杖 (或與先前不同的受控識別) 作為 signingKey，並將新的 SAS 權杖散發至應用程式。
重新產生主索引鍵、從帳戶移除受控識別，以及移除受控識別的角色指派。

建立 SAS 權杖

若要建立 SAS 權杖，您必須具備 Contributor 角色存取權，以在 Azure 訂用帳戶中管理 Azure 地圖服務帳戶和使用者指派的身分識別。

重要

在 Azure 位置 global 中建立的現有Azure 地圖服務帳戶不支援受控識別。

首先，您應該在與 Azure 地圖服務帳戶相同的位置建立使用者指派的受控識別。

提示

您應該針對受控識別和 Azure 地圖服務帳戶使用相同的位置。

建立受控識別之後，您可以建立或更新 Azure 地圖服務帳戶並加以連結。如需詳細資訊，請參閱管理 Azure 地圖服務帳戶。

使用受控識別成功建立或更新帳戶之後，將受控識別的角色型存取控制指派給帳戶範圍 Azure 地圖服務資料角色。這可讓受控識別存取地圖帳戶的 Azure 地圖服務 REST API。

接下來，請使用 Azure 管理 SDK 工具、在帳戶管理 API 上列出 SAS 作業，或地圖帳戶資源的 [Azure 入口網站共用存取簽章] 頁面來建立 SAS 權杖。

SAS 權杖參數：

參數名稱	範例值	描述
signingKey	`primaryKey`	必要，使用 signingKey 的字串列舉值 (`primaryKey`、`secondaryKey` 或受控識別) 來建立 SAS 的簽章。
principalId	`<GUID>`	必要，principalId 是附加至地圖帳戶之使用者指派受控識別的物件 (主體) 識別碼。
區域	`[ "eastus", "westus2", "westcentralus" ]`	選擇性；預設值為 `null`。區域會控制哪些區域允許 SAS 權杖用於 Azure 地圖服務 REST 資料平面 API。省略區域參數可允許使用 SAS 權杖，而不需要任何條件約束。將 `us.atlas.microsoft.com` 和 `eu.atlas.microsoft.com` 之類的 Azure 地圖服務資料平面地理端點搭配使用時，可讓應用程式控制指定地理位置的使用方式。這可防止在其他地理位置使用。
maxRatePerSecond	500	必要，指定授與 SAS 權杖的每秒要求數上限近似值。達到限制之後，其他輸送量會受到 HTTP 狀態碼 `429 (TooManyRequests)` 的速率限制。
start	`2021-05-24T10:42:03.1567373Z`	必要，指定權杖變成作用中的日期和時間的 UTC 日期。
expiry	`2021-05-24T11:42:03.1567373Z`	必要，指定權杖過期的日期和時間的 UTC 日期。開始和到期之間的持續時間不能超過 24 小時。

使用 SAS 權杖設定應用程式

應用程式收到 SAS 權杖之後，Azure 地圖服務 SDK 和/或應用程式除了其他 REST API HTTP 標頭之外，還會傳送具有下列一組必要 HTTP 標頭的 HTTPS 要求：

標頭名稱	值
授權	jwt-sas eyJ0e….HNIVN

注意

jwt-sas 是使用 SAS 權杖表示的驗證配置。請勿包含 x-ms-client-id 或其他授權標頭或 subscription-key 查詢字串參數。

CORS 是一項 HTTP 通訊協定，可讓 Web 應用程式在某個網域下執行，以存取其他網域中的資源。網頁瀏覽器會實作稱為相同原始原則的安全性限制，它可防止網頁呼叫不同網域中的 API；CORS 則提供了一個安全的方式，可讓一個網域 (原始網域) 能夠呼叫其他網域中的 API。使用 Azure 地圖服務帳戶資源，您可以設定允許哪些原點從您的應用程式存取 Azure 地圖服務 REST API。

重要

CORS 不是授權機制。啟用 CORS 時，使用 REST API 對地圖帳戶提出的任何要求，也需要有效的地圖帳戶驗證配置，例如共用金鑰、Microsoft Entra ID 或 SAS 權杖。

所有地圖帳戶定價層、資料平面端點和位置都支援 CORS。

必要條件

為了防止在用戶端上執行惡意程式碼，新式瀏覽器會封鎖來自 Web 應用程式對在個別網域中執行之資源的要求。

如果您不熟悉 CORS，請參閱跨原點資源共用 (CORS)，其會讓 Access-Control-Allow-Origin 標頭宣告哪些原點可以呼叫 Azure 地圖服務帳戶的端點。 CORS 通訊協定不是 Azure 地圖服務特有的。

CORS 要求

來自原始網域的 CORS 要求可能包含兩個不同要求：

預檢要求，其會查詢服務所加諸的 CORS 限制。除非要求是標準方法 GET、HEAD、POST 或包含 Authorization 要求標頭的要求，否則需要預檢要求。
對所需資源提出的實際要求。

預檢要求

預檢要求不僅會做為安全性措施來完成，以確保伺服器瞭解會在實際要求中傳送的方法和標頭，而且伺服器知道並信任要求的來源，也會查詢已為地圖帳戶建立的 CORS 限制。 Web 瀏覽器 (或其他使用者代理程式) 會傳送包含要求標頭、方法和原始網域的 OPTIONS 要求。如果帳戶驗證可能透過 CORS 預檢通訊協定，地圖帳戶服務會嘗試擷取任何 CORS 規則。

如果無法驗證，地圖服務會評估一組預先設定的 CORS 規則，這些規則會指定需在對地圖服務提出的實際要求上指定哪些原點網域、要求方法和要求標頭。根據預設，地圖帳戶會設定為允許所有原點順暢地整合到網頁瀏覽器。

如果符合下列準則，服務會以所需的 Access-Control 標頭回應預檢要求：

OPTIONS 要求包含所需的 CORS 標頭 (來源和 Access-Control-Request-Method 標頭)
驗證成功，且已為符合預檢要求的帳戶啟用 CORS 規則。
已略過驗證，因為無法在預檢要求上指定必要的 Authorization 要求標頭。

當預檢要求成功時，服務會使用狀態碼 200 (OK) 回應，並在回應中包含必要的 Access-Control 標頭。

如果發生下列狀況，服務會拒絕預檢要求：

如果 OPTIONS 要求未包含必要的 CORS 標頭 (原點和 Access-Control-Request-Method 標頭)，服務會使用狀態碼 400 (Bad request) 回應。
如果在預檢要求上成功驗證，且沒有 CORS 規則符合預檢要求，則服務會使用狀態碼 403 (Forbidden) 回應。如果 CORS 規則設定為接受與目前瀏覽器用戶端原始要求標頭不符的原點，就可能發生此情況。

注意

預檢要求是針對服務 (而不是針對要求的資源) 進行評估。帳戶擁有者必須透過設定合適的帳戶服務屬性來啟用 CORS ，才能讓要求成功。

實際要求

一旦接受預檢要求並傳回回應之後，瀏覽器便會對地圖服務發送實際要求。如果預檢要求遭到拒絕，瀏覽器會立即拒絕實際要求。

實際要求會被視為對地圖服務提出的一般要求。 Origin 標頭的目前狀態表示要求是 CORS 要求，而服務會針對 CORS 規則進行驗證。如果找到相符項目，就會將 Access-Control 標頭加入回應並傳送回用戶端。如果找不到相符項目，回應會傳回 403 (Forbidden)，指出 CORS 原點錯誤。

啟用 CORS 原則

建立或更新地圖服務帳戶時，其屬性會指定要設定的允許原點。您可以透過 Azure 地圖服務管理 SDK、Azure 地圖服務管理 REST API 和入口網站，在 Azure 地圖服務帳戶屬性上設定 CORS 規則。一旦設定服務的 CORS 規則之後，即會評估從不同網域對服務所提出的適當授權要求，以判斷是否可根據您指定的規則來允許該要求。例如：

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

只能指定一個具有允許原點清單的 CORS 規則。每個原點允許在指定原點的網頁瀏覽器中向 Azure 地圖服務 REST API 提出的 HTTP 要求。

移除 CORS 原則

您可以移除 CORS：

在 Azure 入口網站中查詢
以程式設計方式使用：
- Azure 地圖服務 SDK
- Azure 地圖服務管理 REST API
- ARM 範本

提示

如果您使用 Azure 地圖服務管理 REST API，請使用 PUT 或 PATCH 搭配要求本文中的空白 corsRule 清單。

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

瞭解計費交易

Azure 地圖服務不會計算以下項目的計費交易：

5xx HTTP 狀態碼
401 (未經授權)
403 (禁止)
408 (逾時)
429 (TooManyRequests)
CORS 預檢要求

如需計費交易和其他 Azure 地圖服務定價資訊的詳細資訊，請參閱 Azure 地圖服務定價。

下一步

若要深入瞭解安全性最佳做法，請參閱：

驗證和授權的最佳做法

若要深入瞭解如何向 Microsoft Entra ID 和 Azure 地圖服務驗證應用程式，請參閱：

管理 Azure 地圖服務中的驗證

若要深入瞭解如何向 Microsoft Entra ID 驗證 Azure 地圖服務控制項，請參閱：

使用 Azure 地圖服務的地圖控制項

共用方式為

向 Azure 地圖服務驗證

共用金鑰驗證

Microsoft Entra 驗證

Azure 資源和 Azure 地圖服務的受控識別

設定應用程式 Microsoft Entra 驗證

使用角色型存取控制進行授權

必要條件

概觀

挑選角色定義

自訂角色定義

了解範圍

停用本機驗證

共用存取簽章權杖驗證

瞭解 SAS 權杖速率限制

SAS 權杖最大速率限制可以控制Azure 地圖服務資源的計費

每個 Azure 位置 (而不是全域或地理位置) 都會強制執行速率限制

預設速率限制優先於 SAS 權杖速率限制

瞭解 SAS 權杖存取控制

建立 SAS 權杖

使用 SAS 權杖設定應用程式

必要條件

CORS 要求

預檢要求

實際要求

啟用 CORS 原則

移除 CORS 原則

瞭解計費交易

下一步

意見反應

其他資源