使用 Microsoft Entra 識別碼進行授權

Azure 記憶體提供與 Microsoft Entra ID 的整合，以身分識別為基礎的 Blob、檔案、佇列和數據表服務要求授權。 使用 Microsoft Entra 識別符，您可以使用角色型訪問控制 （RBAC） 將 Blob、檔案、佇列和數據表資源的存取權授與使用者、群組或應用程式。 您可以授與範圍設定為個別容器、共用、佇列或數據表層級的許可權。

若要深入瞭解 Azure 記憶體中的Microsoft Entra ID 整合，請參閱 使用 Microsoft Entra ID授權存取 Azure Blob 和佇列。

如需在應用程式中使用 Microsoft Entra ID 的優點詳細資訊，請參閱 與 Microsoft 身分識別平臺整合。

使用 OAuth 存取令牌進行驗證

Azure 記憶體會接受與包含記憶體帳戶之訂用帳戶相關聯的Microsoft Entra 租使用者 OAuth 2.0 存取令牌。 Azure 記憶體接受下列專案的存取令牌：

• 使用者和群組
• 服務主體
• Azure 資源的受控識別
• 使用使用者委派的許可權的應用程式

Azure 記憶體會公開名為 user_impersonation 的單一委派範圍，允許應用程式採取用戶允許的任何動作。

若要要求 Azure 記憶體的令牌，請指定資源識別碼的值 https://storage.azure.com/。 如需資源識別碼的詳細資訊，請參閱 Microsoft 身分識別平臺範圍、許可權、& 同意。

如需從使用者和服務主體Microsoft Entra ID 要求存取令牌的詳細資訊，請參閱 驗證流程和應用程式案例。

如需針對使用受控識別設定之資源要求存取令牌的詳細資訊，請參閱 如何在 Azure VM 上使用 Azure 資源的受控識別，以取得存取令牌。

使用 OAuth 令牌呼叫記憶體作業

若要使用 OAuth 存取令牌呼叫 Blob、檔案、佇列和數據表服務作業，請使用 Bearer 配置，在 授權 標頭中傳遞存取令牌， 和 指定 2017-11-09 的服務版本（2022-11-02 適用於 檔案 資源和 Directory 資源或 2024-11-04，以用於 FileService 資源及 FileShare 資源） 或更新版本， 如下列範例所示：

Request:
GET /container/file.txt
x-ms-version: 2017-11-09
Authorization: Bearer eyJ0eXAiO...V09ccgQ
User-Agent: PostmanRuntime/7.6.0
Accept: */*
Host: sampleoautheast2.blob.core.windows.net
accept-encoding: gzip, deflate

Response:
HTTP/1.1 200
status: 200
Content-Length: 28
Content-Type: text/plain
Content-MD5: dxG7IgOBzApXPcGHxGg5SA==
Last-Modified: Wed, 30 Jan 2019 07:21:32 GMT
Accept-Ranges: bytes
ETag: "0x8D686838F9E8BA7"
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: 09f31964-e01e-00a3-8066-d4e6c2000000
x-ms-version: 2017-11-09
x-ms-creation-time: Wed, 29 Aug 2018 04:22:47 GMT
x-ms-lease-status: unlocked
x-ms-lease-state: available
x-ms-blob-type: BlockBlob
x-ms-server-encrypted: true
Date: Wed, 06 Mar 2019 21:50:50 GMT
Welcome to Azure Storage!!

持有人挑戰

持有人挑戰是 OAuth 通訊協定 RFC 6750 的一部分，並用於授權單位探索。 對於對 Blob 服務的匿名要求，或針對具有無效 OAuth 持有人令牌的要求，伺服器會傳回具有識別提供者和資源資訊的狀態代碼 401（未經授權）。 請參閱 連結，瞭解如何在驗證期間使用這些值搭配 Microsoft Entra ID。

Azure 記憶體 Blob 和佇列服務會針對 2019-12-12 版和更新版本傳回持有人挑戰。 Azure 記憶體數據表服務會針對 2020-12-06 版和更新版本傳回持有人挑戰。 Azure Data Lake Storage Gen2 會針對 2017-11-09 版和更新版本傳回持有人挑戰。 Azure 檔案服務會從 2022-11-02 版和更新版本傳回持有人挑戰。

匿名讀取要求的回應

當 Blob 記憶體收到匿名要求時，如果下列所有條件都成立，該要求將會成功：

• 記憶體帳戶允許匿名公用存取。
• 容器已設定為允許匿名公用存取。
• 要求是用於讀取存取。

如果上述任何條件都不是 true，則要求將會失敗。 失敗的回應碼取決於匿名要求是否使用支援持有人挑戰的服務版本提出。 服務版本 2019-12-12 和更新版本支援持有人挑戰：

• 如果使用支援持有人挑戰的服務版本提出匿名要求，則服務會傳回錯誤碼 401 （未經授權）。
• 如果使用不支援持有人挑戰的服務版本提出匿名要求，且不允許記憶體帳戶的匿名公用存取，則服務會傳回錯誤碼 409 （衝突）。
• 如果使用不支援持有人挑戰的服務版本提出匿名要求，且記憶體帳戶允許匿名公用存取，則服務會傳回錯誤碼 404 （找不到）。

如需持有人挑戰的詳細資訊，請參閱 持有人挑戰。

對持有人挑戰的範例回應

當用戶端要求不包含匿名下載 Blob 要求中的持有人令牌時，以下是持有人挑戰回應的範例：

Request:
GET /container/file.txt
x-ms-version: 2019-12-12
Host: sampleoautheast2.blob.core.windows.net

Response:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer authorization_uri=https://login.microsoftonline.com/<tenant_id>/oauth2/authorize resource_id=https://storage.azure.com

<?xml version="1.0" encoding="utf-8"?>
<Error>
    <Code>NoAuthenticationInformation</Code>
    <Message>Server failed to authenticate the request. Please refer to the information in the www-authenticate header.
RequestId:ec4f02d7-1003-0006-21f9-c55bc8000000
Time:2020-01-08T08:01:46.2063459Z</Message>
</Error>

使用 RBAC 管理訪問許可權

Microsoft Entra ID 會處理透過 RBAC 存取受保護資源的授權。 使用 RBAC，您可以將角色指派給使用者、群組或服務主體。 每個角色都包含一組資源的許可權。 將角色指派給使用者、群組或服務主體之後，他們就能夠存取該資源。 您可以使用 Azure 入口網站、Azure 命令行工具和 Azure 管理 API 來指派訪問許可權。 如需 RBAC 的詳細資訊，請參閱 開始使用 Role-Based 存取控制。

針對 Azure 記憶體，您可以授與記憶體帳戶中容器或佇列中數據的存取權。 Azure 記憶體提供這些內建的 RBAC 角色，以搭配 Microsoft Entra 標識碼使用：

• 記憶體 Blob 資料擁有者
• 記憶體 Blob 數據參與者
• 記憶體 Blob 資料讀取器
• 記憶體 Blob 委派器
• 記憶體佇列數據參與者
• 記憶體佇列數據讀取器
• 記憶體佇列數據訊息處理器
• 記憶體佇列數據訊息傳送者
• 記憶體數據表數據讀取器
• 記憶體數據表數據參與者
• 記憶體檔案數據特殊許可權參與者
• 記憶體檔案數據特殊許可權讀取器

如需如何為 Azure 記憶體定義內建角色的詳細資訊，請參閱 瞭解 Azure 資源的角色定義。

您也可以定義自定義角色，以搭配 Blob 記憶體和 Azure 佇列使用。 如需詳細資訊，請參閱 為 Azure Role-Based 訪問控制建立自定義角色。

呼叫數據作業的許可權

下表描述Microsoft Entra 使用者、群組、受控識別或服務主體呼叫特定 Azure 記憶體作業所需的許可權。 若要讓用戶端呼叫特定作業，請確定用戶端指派的 RBAC 角色為該作業提供足夠的許可權。

Blob 服務作業的許可權

佇列服務作業的許可權

數據表服務作業的許可權

檔案服務作業的許可權

另請參閱

• 授權對 Azure 記憶體的要求