Microsoft Entra ID を使用して BLOB へのアクセスを認可する
Azure Storage では、Microsoft Entra ID を使用して BLOB データへの要求を認可できます。 Microsoft Entra ID では、Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、セキュリティ プリンシパル (ユーザー、グループ、またはアプリケーションのサービス プリンシパルなど) にアクセス許可を付与できます。 セキュリティ プリンシパルは、Microsoft Entra ID によって認証されて OAuth 2.0 トークンを返します。 その後、そのトークンを、Blob service に対する要求を認可するために使用できます。
Microsoft Entra ID を使用した認可は、すべてのパブリック リージョンおよび国のクラウドで、あらゆる汎用目的および BLOB ストレージ アカウントで利用できます。 Microsoft Entra 認可をサポートしているのは、Azure Resource Manager デプロイ モデルで作成されたストレージ アカウントのみです。
重要
最適なセキュリティのため、Microsoft では、可能な限り、Microsoft Entra ID とマネージド ID を使って、BLOB、キュー、テーブルのデータに対する要求を認可することをお勧めします。 Microsoft Entra ID とマネージド ID を使った認可によって、共有キー認可よりもセキュリティが向上し、使いやすくなります。 マネージド ID について詳しくは、「Azure リソースのマネージド ID とは」をご覧ください。 .NET アプリケーションでマネージド ID を有効にして使用する方法の例については、.NET での Azure リソースに対する Azure でホストされたアプリの認証に関する記事をご覧ください。
オンプレミス アプリケーションなど、Azure の外部でホストされているリソースの場合は、Azure Arc 経由でマネージド ID を使用できます。たとえば、Azure Arc 対応サーバーで実行されているアプリでは、マネージド ID を使用して Azure サービスに接続できます。 詳細については、「Azure Arc 対応サーバーでの Azure リソースに対して認証を行う」を参照してください。
Microsoft では、Shared Access Signature (SAS) を使うシナリオにはユーザー委任 SAS を使うことをお勧めします。 ユーザー委任 SAS は、アカウント キーの代わりに Microsoft Entra 資格情報で保護されます。 Shared Access Signature について詳しくは、Shared Access Signature によるデータへの制限付きアクセスの許可に関する記事をご覧ください。 .NET でユーザー委任 SAS を作成および使用する方法の例については、「.NET を使用して BLOB 用のユーザー委任 SAS を作成する」を参照してください。
BLOB のための Microsoft Entra ID の概要
セキュリティ プリンシパル (ユーザー、グループ、またはアプリケーション) が BLOB リソースにアクセスしようとする場合、BLOB を匿名アクセスに利用できる場合を除き、要求は承認される必要があります。 Microsoft Entra ID では、リソースへのアクセスは次の 2 段階のプロセスです。
まず、セキュリティ プリンシパルの ID が認証され、OAuth 2.0 トークンが返されます。
認証の手順では、アプリケーションが実行時に OAuth 2.0 アクセス トークンを要求する必要があります。 アプリケーションが Azure VM、仮想マシン スケール セット、または Azure Functions アプリなどの Azure エンティティ内から実行されている場合、マネージド ID を使用して BLOB データにアクセスできます。
次に、そのトークンが Blob service への要求の一部として渡され、指定されたリソースへのアクセスを認可するためにサービスによって使用されます。
承認の手順では、要求を行うセキュリティ プリンシパルに 1 つまたは複数の Azure RBAC ロールを割り当てる必要があります。 詳細については、「アクセス権の Azure ロールを割り当てる」を参照してください。
ポータル、PowerShell、または Azure CLI で Microsoft Entra アカウントを使用する
Microsoft Entra アカウントを使用して Azure portal でデータにアクセスする方法については、「Azure portal からのデータ アクセス」を参照してください。 Microsoft Entra アカウントを使用して Azure PowerShell または Azure CLI コマンドを呼び出す方法については、「PowerShell または Azure CLI からのデータ アクセス」を参照してください。
Microsoft Entra ID を使用してアプリケーション コードでのアクセスを認可する
Microsoft Entra ID を使用して Azure Storage へのアクセスを認可するには、次のいずれかのクライアント ライブラリを使用して OAuth 2.0 トークンを取得できます。
- ほとんどの開発シナリオでは、Azure ID クライアント ライブラリをお勧めします。
- Microsoft Authentication Library (MSAL) は、特定の高度なシナリオに適している場合があります。
Azure ID クライアント ライブラリ
Azure ID クライアントライブラリを使うと、Azure SDK を介して Microsoft Entra ID を使って認可するための OAuth 2.0 アクセス トークンを取得するプロセスが簡単になります。 .NET、Java、Python、JavaScript、Go 用の最新バージョンの Azure Storage クライアント ライブラリは、各言語用の Azure ID ライブラリに統合され、Azure Storage 要求を承認するためのアクセス トークンを取得するための簡単で安全な手段が提供されます。
Azure ID クライアント ライブラリの利点は、アプリケーションが開発環境または Azure のどちらで実行されているかにかかわらず、同じコードを使用してアクセス トークンを取得できることです。 Azure ID クライアント ライブラリからは、セキュリティ プリンシパルのためのアクセス トークンが返されます。 コードが Azure で実行されている場合は、セキュリティ プリンシパルは、Azure リソース用のマネージド ID、サービス プリンシパル、またはユーザーやグループのいずれでもかまいません。 開発環境では、クライアント ライブラリにより、ユーザーまたはサービス プリンシパルにテストのためのアクセス トークンが提供されます。
Azure ID クライアント ライブラリによって返されるアクセス トークンは、トークン資格情報にカプセル化されています。 その後、トークン資格情報を使用してサービス クライアント オブジェクトを取得し、Azure Storage に対する承認された操作の実行で使用できます。 アクセス トークンとトークン資格情報を取得する簡単な方法は、Azure ID クライアント ライブラリによって提供される DefaultAzureCredential クラスを使用することです。 DefaultAzureCredential では、複数の異なる資格情報の種類を順番に試行して、トークン資格情報の取得を試みます。 DefaultAzureCredential は、開発環境と Azure の両方で機能します。
次の表は、さまざまなシナリオでデータへのアクセスを承認するための追加情報を示しています。
Microsoft Authentication Library (MSAL)
Microsoft では可能であれば Azure ID クライアント ライブラリを使用することをお勧めしますが、MSAL ライブラリは特定の高度なシナリオで使用するのに適している場合があります。 詳細については、MSAL の詳細に関するページを参照してください。
MSAL を使用して Azure Storage へのアクセスのための OAuth トークンを取得する場合は、Microsoft Entra リソース ID を指定する必要があります。 Microsoft Entra リソース ID は、発行されたトークンを使用して Azure リソースへのアクセスを提供できる対象のユーザーを示します。 Azure Storage の場合、リソース ID は 1 つのストレージ アカウントに固有となるか、あらゆるストレージ アカウントに適用されます。
1 つのストレージ アカウントとサービスに固有のリソース ID を指定すると、そのリソース ID は、指定されたアカウントとサービスのみへの要求を認可するためのトークンを取得するために使用されます。 次の表は、操作しているクラウドに基づいて、リソース ID に使用する値の一覧を示しています。 <account-name> をストレージ アカウントの名前に置き換えます。
| クラウド | リソース ID |
|---|---|
| Azure Global | https://<account-name>.blob.core.windows.net |
| Azure Government | https://<account-name>.blob.core.usgovcloudapi.net |
| Azure China 21Vianet | https://<account-name>.blob.core.chinacloudapi.cn |
次の表に示すように、任意のストレージ アカウントに適用されるリソース ID を指定することもできます。 このリソース ID はすべてのパブリックおよびソブリン クラウドに対して同じであり、任意のストレージ アカウントへの要求を認可するためのトークンを取得するために使用されます。
| クラウド | リソース ID |
|---|---|
| Azure Global Azure Government Azure China 21Vianet |
https://storage.azure.com/ |
アクセス権の Azure ロールを割り当てる
Microsoft Entra では、Azure RBAC を使用して、セキュリティで保護されたリソースへのアクセス権を認可します。 BLOB データへのアクセスに使用される一般的なアクセス許可セットを含む一連の組み込み RBAC ロールは、Azure Storage によって定義されます。 BLOB データにアクセスするためのカスタム ロールを定義することもできます。 BLOB アクセス用の Azure ロールの割り当ての詳細については、「BLOB データにアクセスするための Azure ロールを割り当てる」を参照してください。
Microsoft Entra のセキュリティ プリンシパルは、ユーザー、グループ、アプリケーション サービス プリンシパル、または Azure リソースのマネージド ID の場合があります。 セキュリティ プリンシパルに割り当てられた RBAC ロールによって、指定されたリソースに対するそのプリンシパルのアクセス許可が決まります。 BLOB アクセス用の Azure ロールの割り当ての詳細については、「BLOB データにアクセスするための Azure ロールを割り当てる」を参照してください。
場合によっては、BLOB リソースへのきめ細かなアクセスを有効にしたり、ストレージ リソースに対するロールの割り当てが多数ある場合にアクセス許可を簡略化したりする必要があります。 Azure 属性ベースのアクセス制御 (Azure ABAC) を使用して、ロール割り当てに関する条件を構成できます。 カスタム役割で条件を使用したり、組み込みロールを選択したりすることができます。 ABAC を使用した Azure ストレージ リソースの条件の構成に関する詳細については、「Azure ロールの割り当て条件を使用して BLOB へのアクセスを承認する (プレビュー)」を参照してください。 BLOB データ操作でサポートされる条件の詳細については、「Azure Storage 内での Azure のロールの割り当て条件のアクションと属性 (プレビュー)」を参照してください。
Note
Azure Storage アカウントを作成するとき、Microsoft Entra ID を介してデータにアクセスするためのアクセス許可は自動的に割り当てられません。 Blob Storage にアクセスするための Azure ロールを自分自身に明示的に割り当てる必要があります。 これは、サブスクリプション、リソース グループ、ストレージ アカウント、あるいはコンテナーのレベルで割り当てることができます。
リソースのスコープ
セキュリティ プリンシパルに Azure RBAC ロールを割り当てる前に、セキュリティ プリンシパルに必要なアクセスのスコープを決定します。 ベスト プラクティスとしては、常にできるだけ狭いスコープのみを付与するのが最善の方法です。 より広い範囲で定義されている Azure RBAC ロールは、その下のリソースによって継承されます。
Azure BLOB リソースへのアクセスのスコープは、次のレベルで指定できます (最も狭いスコープから順に示します)。
- 個々のコンテナー。 このスコープでは、ロールの割り当ては、コンテナー内のすべての BLOB と、コンテナーのプロパティおよびメタデータに適用されます。
- ストレージ アカウント。 このスコープでは、ロールの割り当てはすべてのコンテナーとその BLOB に適用されます。
- リソース グループです。 このスコープでは、ロールの割り当ては、リソース グループ内のすべてのストレージ アカウントのすべてのコンテナーに適用されます。
- サブスクリプション。 このスコープでは、ロールの割り当ては、サブスクリプション内のすべてのリソース グループ内の、すべてのストレージ アカウントのすべてのコンテナーに適用されます。
- 管理グループ。 このスコープでは、ロールの割り当ては、管理グループ内のすべてのサブスクリプション内のすべてのリソース グループ内のすべてのストレージ アカウントのすべてのコンテナーに適用されます。
Azure RBAC ロールの割り当てのスコープの詳細については、「Azure RBAC のスコープについて」を参照してください。
BLOB 用の Azure 組み込みロール
Azure RBAC には、Microsoft Entra ID と OAuth を使用して BLOB データへのアクセスを認可するための組み込みロールがいくつか用意されています。 Azure Storage のデータ リソースへのアクセス許可を付与するロールの例を次に示します。
- ストレージ BLOB データ所有者:Azure Data Lake Storage Gen2 で、所有権の設定と POSIX アクセス制御の管理に使用します。 詳細については、Azure Data Lake Storage Gen2 でのアクセス制御に関するページを参照してください。
- ストレージ BLOB データ共同作成者:BLOB ストレージ リソースの読み取り/書き込み/削除のアクセス許可を付与するために使用します。
- ストレージ BLOB データ閲覧者:BLOB ストレージ リソースの読み取り専用アクセス許可を付与するために使用します。
- Storage Blob デリゲータ: Microsoft Entra 資格情報で署名された、コンテナーまたは BLOB 用の共有アクセス署名を作成するために使用するユーザー委任キーを取得します。
Azure 組み込みロールをセキュリティ プリンシパルに割り当てる方法については、「BLOB データにアクセスするための Azure ロールを割り当てる」を参照してください。 Azure RBAC ロールとそのアクセス許可を一覧表示する方法については、「Azure ロールの定義を一覧表示する」を参照してください。
Azure Storage の組み込みロールの定義方法については、「ロール定義について」を参照してください。 Azure カスタム ロールの作成については、「Azure カスタム ロール」を参照してください。
データ アクセスに対して明示的に定義されたロールによってのみ、セキュリティ プリンシパルによる BLOB データへのアクセスが許可されます。 所有者、共同作成者、ストレージ アカウント共同作成者などの組み込みロールでは、ストレージ アカウントを管理するためのセキュリティ プリンシパルが許可されますが、Microsoft Entra ID によるそのアカウント内の BLOB データへのアクセスは提供されません。 ただし、ロールに Microsoft.Storage/storageAccounts/listKeys/action が含まれている場合、そのロールが割り当てられているユーザーは、アカウント アクセス キーを使った共有キーによる承認を介してストレージ アカウントのデータにアクセスできます。 詳細については、「Azure portal で BLOB データへのアクセスの承認方法を選択する」を参照してください。
データ サービスと管理サービスの両方に対する Azure Storage 用の Azure 組み込みロールの詳細については、「Azure RBAC の Azure 組み込みロール」の「ストレージ」セクションを参照してください。 追加情報として、Azure でアクセス許可を付与するさまざまな種類のロールについては、「Azure ロール、Microsoft Entra ロール、従来のサブスクリプション管理者ロール」を参照してください。
重要
Azure ロールの割り当ての反映には最大で 30 分かかる可能性があります。
データ操作用のアクセス許可
特定の Blob service の操作を呼び出すために必要なアクセス許可の詳細については、「データ操作呼び出しのアクセス許可」を参照してください。
Microsoft Entra アカウントを使用してデータにアクセスする
Azure portal、PowerShell、または Azure CLI による BLOB データへのアクセスは、ユーザーの Microsoft Entra アカウントを使用するか、またはアカウント アクセス キー (共有キー認可) を使用して認可できます。
注意事項
共有キーを使用した承認は、安全性が低い可能性があるため、お勧めしません。 最適なセキュリティを確保するには、「Azure Storage アカウントの共有キーによる承認を禁止する」の説明に従って、ストレージ アカウントの共有キーによる承認を無効にします。
アクセス キーと接続文字列の使用は、運用環境や機密データにアクセスしない概念実証アプリまたは開発プロトタイプに限定する必要があります。 それ以外の場合は、Azure リソースに対する認証時に、Azure SDK で使用できるトークンベースの認証クラスを常に優先する必要があります。
Microsoft は、クライアントが Microsoft Entra ID または Shared Access Signature (SAS) を使って、Azure Storage 内のデータへのアクセスを認可することをお勧めします。 詳細については、「Azure Storage 内のデータへのアクセスを承認する」を参照してください。
Azure portal からのデータ アクセス
Azure portal では、Microsoft Entra アカウントまたはアカウント アクセス キーのどちらかを使用して、Azure ストレージ アカウント内の BLOB データにアクセスできます。 Azure portal で使用する認証スキームは、お客様に割り当てられている Azure ロールに応じて異なります。
BLOB データにアクセスしようとすると、Azure portal によって、まず Microsoft.Storage/storageAccounts/listkeys/action を持つ Azure ロールが割り当てられているかどうかが確認されます。 このアクションを持つロールが割り当てられている場合、Azure portal では共有キー承認によって BLOB データにアクセスするためのアカウント キーが使用されます。 このアクションを持つロールが割り当てられていない場合、Azure portal では Microsoft Entra アカウントを使ってデータへのアクセスを試みます。
Microsoft Entra アカウントを使って Azure portal から BLOB データにアクセスするには、その BLOB データにアクセスするためのアクセス許可が必要です。また、Azure portal でストレージ アカウント リソース内を移動するためのアクセス許可も必要です。 Azure Storage によって提供されている組み込みロールでは BLOB リソースへのアクセス権が付与されますが、ストレージ アカウント リソースへのアクセス許可は付与されません。 このため、ポータルへのアクセスには、スコープがストレージ アカウント以上のレベルに設定された、閲覧者ロールなどの Azure Resource Manager ロールの割り当ても必要です。 リーダー役割は最も制限の厳しいアクセス許可を付与しますが、ストレージ アカウントの管理リソースへのアクセス権を付与する別の Azure Resource Manager ロールも受け入れることができます。 Microsoft Entra アカウントを使用した Azure portal 内のデータ アクセスのためにユーザーにアクセス許可を割り当てる方法の詳細については、「BLOB データへのアクセスのための Azure ロールを割り当てる」を参照してください。
Azure portal では、コンテナーに移動すると、どの認可スキームが使用されているかが示されます。 ポータルでのデータ アクセスの詳細については、「Azure portal で BLOB データへのアクセスの承認方法を選択する」を参照してください。
PowerShell または Azure CLI からのデータ アクセス
Azure CLI と PowerShell では、Microsoft Entra 資格情報を使用したサインインがサポートされています。 サインインした後、セッションはその資格情報で実行されます。 詳細については、次のいずれかの記事を参照してください。
機能サポート
Data Lake Storage Gen2、Network File System (NFS) 3.0 プロトコル、または SSH ファイル転送プロトコル (SFTP) を有効にすると、この機能のサポートが影響を受ける場合があります。 これらの機能のいずれかを有効にしている場合は、「Azure Storage アカウントでの Blob Storage 機能のサポート」 を参照して、この機能のサポートを評価してください。
Microsoft Entra ID を使った BLOB データ操作の認可は、REST API バージョン 2017-11-09 以降でのみサポートされています。 詳細については、「Azure Storage サービスのバージョン管理」を参照してください。