選取並設定存取 Azure Blob 的適當方法

已完成

Azure 儲存體支援使用 Microsoft Entra ID 來授權對 Blob 資料的要求。 使用 Microsoft Entra ID,您可以使用 Azure 角色型存取控制 (Azure RBAC) 將權限授與安全性主體,其可能是使用者、群組或應用程式服務主體。 安全性主體是由 Microsoft Entra ID 進行驗證,以傳回 OAuth 2.0 權杖。 權杖接著可以用來授權對 Blob 服務的要求。

Microsoft Entra ID 的授權適用於所有公用區域和國家雲端的一般用途和 Blob 儲存體帳戶。 只有使用 Azure Resource Manager 部署模型所建立的儲存體帳戶才支援 Microsoft Entra 授權。

為了獲得最佳安全性,Microsoft 建議盡可能使用具有受控識別的 Microsoft Entra ID 來授權對 Blob、佇列和數據表數據的要求。 使用 Microsoft Entra 識別碼和受控識別進行授權,提供優於共用密鑰授權的安全性和使用便利性。 若要深入瞭解受控識別,請參閱 什麼是 Azure 資源的受控識別。 如需如何為 .NET 應用程式啟用和使用受控識別的範例,請參閱 使用 .NET 向 Azure 資源驗證 Azure 裝載的應用程式。

針對裝載於 Azure 外部的資源,例如內部部署應用程式,您可以透過 Azure Arc 使用受控識別。例如,在已啟用 Azure Arc 的伺服器上執行的應用程式可以使用受控識別來連線到 Azure 服務。 若要深入瞭解,請參閱 使用已啟用 Azure Arc 的伺服器對 Azure 資源進行驗證。

針對使用共用存取簽章 (SAS) 的案例,Microsoft 建議使用使用者委派 SAS。 使用者委派 SAS 會使用 Microsoft Entra 認證來保護,而不是帳戶密鑰。 若要了解共用存取簽章,請參閱 使用共用存取簽章授與有限的數據存取權。 如需如何建立和使用使用者委派 SAS 搭配 .NET 的範例,請參閱 使用 .NET 建立 Blob 的使用者委派 SAS。

針對 Blob 的 Microsoft Entra ID 概觀

當安全性主體 (使用者、群組或應用程式) 嘗試存取 Blob 資源時,除非它是可供匿名存取的 Blob,否則要求必須獲得授權。 使用 Microsoft Entra ID 時,存取資源的流程分為兩個步驟:

  1. 首先,安全性主體的身分識別已通過驗證,並傳回 OAuth 2.0 權杖。
  • 驗證步驟需要應用程式在執行階段要求 OAuth 2.0 存取權杖。 如果應用程式在 Azure 實體 (例如 Azure VM、虛擬機器擴展集或 Azure Functions 應用程式) 內執行,則可使用受控識別來存取 Blob 資料。
  1. 接下來,會將權杖當成要求的一部分來傳遞給 Blob 服務,並由該服務用來授權對指定資源的存取。
  • 接下來,會將權杖當成要求的一部分來傳遞給 Blob 服務,並由該服務用來授權對指定資源的存取。

透過入口網站、PowerShell 或 Azure CLI 使用 Microsoft Entra 帳戶

若要了解如何使用 Microsoft Entra 帳戶存取 Azure 入口網站中的資料,請參閱從 Azure 入口網站進行的資料存取。 若要了解如何使用 Microsoft Entra 帳戶呼叫 Azure PowerShell 或 Azure CLI 命令,請參閱從 PowerShell 或 Azure CLI 進行的資料存取

使用 Microsoft Entra ID 在應用程式程式碼中授權存取

若要透過 Microsoft Entra ID 授權對 Azure 儲存體的存取,您可以使用下列其中一個用戶端程式庫來取得 OAuth 2.0 權杖:

Azure 身分識別用戶端程式庫

Azure 身分識別用戶端程式庫可透過 Azure SDK,簡化使用 Microsoft Entra ID 取得 OAuth 2.0 存取權杖以進行授權的程序。 適用於 .NET、Java、Python、JavaScript 和 Go 的最新版本的 Azure 儲存體用戶端程式庫與這些每一種語言的 Azure 身分識別程式庫整合,以提供一種簡單且安全的方法來取得存取權杖以授權 Azure 儲存體要求。

Azure 身分識別用戶端程式庫的優點是,無論您的應用程式是在開發環境還是在 Azure 中執行,它都可讓您使用相同的程式碼來取得存取權杖。 Azure 身分識別用戶端程式庫會傳回安全性主體的存取權杖。 當您的程式碼在 Azure 中執行時,安全性主體可能是 Azure 資源的受控識別、服務主體,或者是使用者或群組。 在開發環境中,用戶端程式庫會為使用者或服務主體提供存取權杖以用於測試目的。

Azure 身分識別用戶端程式庫所傳回的存取權杖會封裝在權杖認證中。 然後,您可以使用該權杖認證來取得服務用戶端物件,以用於對 Azure 儲存體執行授權的作業。 取得存取權杖和權杖認證的一個簡單方法是使用 Azure 身分識別用戶端程式庫所提供的 DefaultAzureCredential 類別。 DefaultAzureCredential 會嘗試透過連續嘗試幾種不同的認證類型來取得權杖認證。 DefaultAzureCredential 可在開發環境和在 Azure 中運作。

下表指出在各種案例中授權資料存取的其他資訊:

語言 .NET Java JavaScript Python Go
使用 Microsoft Entra ID 進行驗證的概觀 如何使用 Azure 服務驗證 .NET 應用程式 使用 Java 和 Azure 身分識別進行 Azure 驗證 使用 Azure SDK 向 Azure 驗證 JavaScript 應用程式 使用 Azure SDK向 Azure 驗證 Python 應用程式 N/A
使用開發人員服務主體驗證 於本機開發期間使用服務主體向 Azure 服務驗證 .NET 應用程式 使用服務主體進行 Azure 驗證 使用服務主體向 Azure 服務驗證 JS 應用程式 於本機開發期間使用服務主體向 Azure 服務驗證 Python 應用程式 使用服務主體進行 Azure SDK for Go 驗證
使用開發人員或用戶帳戶進行驗證 於本機開發期間使用開發人員帳戶向 Azure 服務驗證 .NET 應用程式 使用使用者認證進行 Azure 驗證 使用開發人員帳戶向 Azure 服務驗證 JS 應用程式 於本機開發期間使用開發人員帳戶向 Azure 服務驗證 Python 應用程式 使用 Azure SDK for Go 進行 Azure 驗證
從 Azure 裝載的應用程式驗證 使用 Azure SDK for .NET 向 Azure 資源驗證 Azure 裝載的應用程式 驗證 Azure 裝載的 Java 應用程式 使用 Azure SDK for JavaScript 向 Azure 資源驗證 Azure 裝載的 JavaScript 應用程式 使用 Azure SDK for Python 向 Azure 資源驗證 Azure 裝載的應用程式 使用受控識別向 Azure SDK for Go 進行驗證
從內部部署應用程式驗證 從裝載於內部部署的 .NET 應用程式向 Azure 資源進行驗證 N/A 向 Azure 資源驗證內部部署 JavaScript 應用程式 從裝載於內部部署的 Python 應用程式向 Azure 資源進行驗證 N/A
身分識別用戶端程式庫概觀 適用於 .NET 的 Azure 身分識別用戶端程式庫 適用於 Java 的 Azure 身分識別用戶端程式庫 適用於 JavaScript 的 Azure 身分識別用戶端程式庫 適用於 Python 的 Azure 身分識別用戶端程式庫 適用於 Go 的 Azure 身分識別用戶端程式庫

Microsoft Authentication Library (MSAL)

雖然 Microsoft 建議盡可能使用 Azure Identity 用戶端程式庫,但 MSAL 程式庫可能適合在特定的進階案例中使用。 如需詳細資訊,請參閱了解 MSAL

當您使用 MSAL 取得 OAuth 權杖以存取 Azure 儲存體時,您必須提供 Microsoft Entra 資源識別碼。 Microsoft Entra 資源識別碼代表為其發出的權杖可用來提供對 Azure 資源的存取的對象。 對於 Azure 儲存體,資源識別碼可能專屬於單一的儲存體帳戶,也可能適用於任何的儲存體帳戶。

當您提供專屬於單一儲存體帳戶和服務的資源識別碼時,該資源識別碼會用來取得權杖,以便只授權對指定帳戶和服務的要求。 下表根據您正在使用的雲端列出了用於資源識別碼的值範例。 請以您的儲存體帳戶名稱取代 <account-name>

雲端 資源識別碼
Azure 全域 example: account-name.blob.core.windows.net
Azure Government example: account-name.blob.core.usgovcloudapi.net
Azure 中國 21Vianet example: account-name.blob.core.chinacloudapi.cn

您也可以提供適用於任何儲存體帳戶的資源識別碼,如下表所示。 此資源識別碼對於所有公有雲和主權雲都是相同的,且可用來取得權杖以授權對任何儲存體帳戶的要求。

雲端 資源識別碼
Azure 全域
Azure Government
Azure 中國 21Vianet
example: storage.azure.com

指派 Azure 角色以取得存取權限

Microsoft Entra 會透過 Azure RBAC 來授權對受保護資源的存取權限。 Azure 儲存體定義了一組內建的 RBAC 角色,其中包含用來存取 Blob 資料的常見權限集。 您也可以定義自訂角色來取得對 Blob 資料的存取權。 若要深入了解如何指派 Azure 角色以存取 Blob,請參閱指派 Azure 角色以存取 Blob 資料

Microsoft Entra 安全性主體可以是使用者、群組或應用程式服務主體,或是適用於 Azure 資源的受控識別。 指派給安全性主體的 RBAC 角色可決定主體對指定資源擁有的權限。 若要深入了解如何指派 Azure 角色以存取 Blob,請參閱指派 Azure 角色以存取 Blob 資料

在某些情況下,當您對儲存體資源進行大量角色指派時,您可能需要啟用對 Blob 資源的精細存取或簡化權限。 您可以使用 Azure 屬性型存取控制 (Azure ABAC) 來設定角色指派的條件。 您可以使用條件搭配自訂角色,或選取內建角色。 如需使用 ABAC 針對 Azure 儲存體資源設定條件的詳細資訊,請參閱使用 Azure 角色指派條件授權存取 Blob (預覽)。 如需有關 Blob 資料作業支援條件的詳細資訊,請參閱 Azure 儲存體中 Azure 角色指派條件的動作和屬性 (預覽)

當您建立 Azure 儲存體帳戶時,不會自動向您指派透過 Microsoft Entra ID 存取資料的權限。 您必須明確為自己指派一個 Azure 角色才能存取 Blob 儲存體。 您可以在您的訂用帳戶、資源群組、儲存體帳戶或容器的層級指派它。

資源範圍

在將 Azure RBAC 角色指派給安全性主體之前,請先確定安全性主體應具有的存取範圍。 最佳做法指出,最好只授與最窄的可能範圍。 在更廣泛的範圍內定義的 Azure RBAC 角色會由其下的資源繼承。

您可以在下列層級設定對 Azure Blob 資源的存取範圍 (從最窄的範圍開始):

  • 個別容器。 在此範圍內,角色指派會套用至容器中的所有 Blob,以及容器屬性和中繼資料。
  • 儲存體帳戶。 在此範圍內,角色指派會套用至所有容器及其 Blob。
  • 資源群組。 在此範圍內,角色指派會套用至資源群組中所有儲存體帳戶中的所有容器。
  • 訂用帳戶。 在此範圍內,角色指派會套用至訂用帳戶中所有資源群組的所有儲存體帳戶中的所有容器。
  • 管理群組。 在此範圍內,角色指派會套用至管理群組中所有訂用帳戶的所有資源群組的所有儲存體帳戶中的所有容器。

用於存取 Blob 的 Azure 內建角色

Azure RBAC 提供了數個內建角色,用於授權使用 Microsoft Entra ID 和 OAuth 存取 Blob 資料。 可以對 Azure 儲存體中的資料資源提供權限的一些角色範例包括:

若要了解如何將 Azure 內建角色指派給安全性主體,請參閱指派 Azure 角色以存取 Blob 資料。 若要了解如何列出 Azure RBAC 角色及其權限,請參閱列出 Azure 角色定義

如需有關如何為 Azure 儲存體定義內建角色的詳細資訊,請參閱了解角色定義。 如需建立 Azure 自訂角色的相關資訊,請參閱 Azure 自訂角色

只有為資料存取明確定義的角色才允許安全性主體存取 Blob 資料。 內建角色 (例如擁有者參與者儲存體帳戶參與者) 會允許安全性主體管理儲存體帳戶,但是不會透過 Microsoft Entra ID 提供該帳戶內 Blob 資料的存取權。 不過,如果角色包含 Microsoft.Storage/storageAccounts/listKeys/action,則獲指派該角色的使用者可以透過具有帳戶存取金鑰的共用金鑰授權來存取儲存體帳戶中的資料。 如需詳細資訊,請參閱選擇如何在 Azure 入口網站中授權存取 Blob 資料

如需有關適用於資料服務和管理服務的 Azure 儲存體 Azure 內建角色的詳細資訊,請參閱 Azure RBAC 的 Azure 內建角色中的儲存體一節。 此外,如需在 Azure 中提供權限的不同類型角色的詳細資訊,請參閱 Azure 角色、Microsoft Entra 角色和傳統訂用帳戶管理員角色

Azure 角色指派最多需要 30 分鐘的時間來傳播。

適用於資料作業的存取權限

如需呼叫特定 Blob 服務作業所需權限的詳細資訊,請參閱呼叫資料作業的權限

使用 Microsoft Entra 帳戶存取資料

您可以使用使用者的 Microsoft Entra 帳戶或使用帳戶存取金鑰 (共用金鑰授權) 來授權透過 Azure 入口網站、PowerShell 或 Azure CLI 存取 Blob 資料

不建議使用「共用金鑰」來進行授權,因為它可能不太安全。 為了獲得最佳的安全性,請停用透過「共用金鑰」對您的儲存體帳戶進行授權,如「防止 Azure 儲存體帳戶的共用金鑰授權」中所述。

使用存取金鑰和連接字串應僅限於未存取生產或敏感性資料的初始概念證明應用程式或開發原型。 否則,在對 Azure 資源進行驗證時,應一律優先使用 Azure SDK 中所提供的權杖型驗證類別。

Microsoft 建議用戶端使用 Microsoft Entra ID 或共用存取簽章 (SAS) 來授權存取 Azure 儲存體中的資料。 如需詳細資訊,請參閱授權資料存取的作業

從 Azure 入口網站中存取資料

Azure 入口網站可以使用您的 Microsoft Entra 帳戶或帳戶存取金鑰來存取 Azure 儲存體帳戶中的 Blob 資料。 Azure 入口網站使用哪種授權方案取決於指派給您的 Azure 角色。

當您嘗試存取 Blob 資料時,Azure 入口網站會先檢查您是否已獲指派具有 Microsoft.Storage/storageAccounts/listkeys/action 的 Azure 角色。 如果您已獲指派具有此動作的角色,則 Azure 入口網站會使用帳戶金鑰透過「共用金鑰」授權來存取 Blob 資料。 如果您未獲指派具有此動作的角色,則 Azure 入口網站會嘗試使用您的 Microsoft Entra 帳戶來存取資料。

若要使用您的 Microsoft Entra 帳戶從 Azure 入口網站存取 Blob 資料,則您需要可存取 Blob 資料的權限,而且也需要可在 Azure 入口網站中瀏覽儲存體帳戶資源的權限。 Azure 儲存體提供的內建角色會授與 Blob 資源的存取權,但不會授與儲存體帳戶資源的權限。 基於這個理由,入口網站的存取也需要指派 Azure Resource Manager 角色 (例如讀者角色),並將範圍設定在儲存體帳戶層級或更高層級。 讀者角色會授與最受限制的權限,但也可以接受另一個 Azure Resource Manager 角色來授與儲存體帳戶管理資源的存取權。 若要深入了解如何將權限指派給使用者,以透過 Microsoft Entra 帳戶在 Azure 入口網站中存取資料,請參閱指派 Azure 角色以存取 Blob 資料

Azure 入口網站會指出您瀏覽至容器時,所使用的授權配置。 如需有關在入口網站中存取資料的詳細資訊,請參閱選擇如何授與在 Azure 入口網站中存取 Blob 資料的權限

從 PowerShell 或 Azure CLI 進行的資料存取

Azure CLI 和 PowerShell 支援使用 Microsoft Entra 認證登入。 登入之後,您的工作階段就會在那些認證下執行。

功能支援

啟用 Data Lake Storage Gen2、網路檔案系統 (NFS) 3.0 通訊協定,或 SSH 檔案傳輸通訊協定 (SFTP),可能會影響到此功能的支援。