Azure Data Lake Storage Gen2 のアクセス制御モデル
Data Lake Storage Gen2 では、次の認可メカニズムがサポートされています。
- 共有キー認可
- Shared Access Signature (SAS) 認可
- ロールベースのアクセス制御 (Azure RBAC)
- 属性ベースのアクセス制御 (Azure ABAC)
- アクセス制御リスト (ACL)
共有キーと SAS 認可では、Microsoft Entra ID で ID を取得するように要求せずに、ユーザー (またはアプリケーション) へのアクセスが許可されます。 これらの 2 つの形式の認証を使用しても、Azure RBAC、Azure ABAC、ACL は影響を受けません。
Azure RBAC と ACL では両方とも、ユーザー (またはアプリケーション) が Microsoft Entra ID で ID を取得する必要があります。 Azure RBAC を使用すると、ストレージ アカウント内のすべてのデータへの読み取りまたは書き込みアクセス権など、ストレージ アカウント データへの "大ざっぱな" アクセス権を付与できます。 Azure ABAC を使用すると、条件を追加して RBAC ロールの割り当てを調整できます。 たとえば、特定のタグを持つ、ストレージ アカウント内のすべてのデータ オブジェクトへの読み取りまたは書き込みアクセス権を付与できます。 ACL を使用すると、特定のディレクトリやファイルへの書き込みアクセス権など、"きめ細かい" アクセス権を付与できます。
この記事では、Azure RBAC、ABAC、ACL を重点的に取り上げ、システムがそれらをまとめて評価してストレージ アカウント リソースに関する認可を決定する方法について説明します。
ロールベースのアクセス制御 (Azure RBAC)
Azure RBAC を使用すると、ロールの割り当てを使用して、"セキュリティ プリンシパル" にアクセス許可セットが適用されます。 セキュリティ プリンシパルは、Microsoft Entra ID で定義されたユーザー、グループ、サービス プリンシパル、またはマネージド ID を表すオブジェクトです。 アクセス許可セットを使用すると、セキュリティ プリンシパルに "粒度の粗い" アクセス レベル (ストレージ アカウント内のすべてのデータやコンテナー内のすべてのデータへの読み取りアクセスまたは書き込みアクセスなど) を付与できます。
次のロールでは、セキュリティ プリンシパルがストレージ アカウント内のデータにアクセスすることが許可されます。
| Role | 説明 |
|---|---|
| ストレージ BLOB データ所有者 | BLOB コンテナーおよびデータへのフル アクセス。 このアクセスでは、セキュリティ プリンシパルが所有者に項目を設定し、すべての項目の ACL を変更することが許可されます。 |
| ストレージ BLOB データ共同作成者 | BLOB ストレージ コンテナーと BLOB への読み取り、書き込み、削除アクセス。 このアクセスでは、セキュリティ プリンシパルが項目の所有権を設定することが許可されませんが、セキュリティ プリンシパルが所有している項目の ACL を変更することはできます。 |
| ストレージ BLOB データ閲覧者 | BLOB ストレージ コンテナーと BLOB を読み取り、一覧表示します。 |
所有者、共同作成者、閲覧者、ストレージ アカウント共同作成者などのロールでは、セキュリティ プリンシパルがストレージ アカウントを管理することが許可されますが、そのアカウント内のデータにアクセスすることはできません。 ただし、これらのロール (閲覧者を除く) では、データにアクセスするためにさまざまなクライアント ツールで使用できるストレージ キーへのアクセス権を取得できます。
属性ベースのアクセス制御 (Azure ABAC)
Azure ABAC は、Azure RBAC を基盤としたものであり、特定のアクションのコンテキストにおける属性に基づいたロールの割り当て条件を追加することにより構築されます。 ロールの割り当て条件は、よりきめ細かいアクセス制御を実現するために、ロールの割り当てに任意に追加できる追加チェックです。 条件を使用して特定のリソースに対するアクセスを明示的に拒否することはできません。
Azure ABAC を使用して Azure Storage へのアクセスを制御する方法について詳しくは、「Azure ロールの割り当て条件を使用して Azure Blob Storage へのアクセスを承認する」を参照してください。
アクセス制御リスト (ACL)
ACL を使用すると、ディレクトリやファイルに "粒度の細かい" アクセス レベルを適用できます。 "ACL" は、一連の "ACL エントリ" を含むアクセス許可の構成体です。 各 ACL エントリでは、セキュリティ プリンシパルとアクセス レベルが関連付けられます。 詳細については、Azure Data Lake Storage Gen2 でのアクセス制御リスト (ACL) に関するページを参照してください。
権限を評価する方法
セキュリティ プリンシパルベースの認可時に、次の図に示されているようにアクセス許可が評価されます。
- Azure で、プリンシパルに対してロールの割り当てが存在するかどうかが判別されます。
- ロールの割り当てが存在する場合、ロールの割り当て条件 (2) が次に評価されます。
- 存在しない場合、ACL (4) が次に評価されます。
- Azure で、ABAC ロールの割り当て条件が存在するかどうかが判別されます。
- 条件が存在しない場合、アクセス権が付与されます。
- 条件が存在する場合は、要求と一致するかどうかの評価が行われます (3)。
- Azure で、ABAC のロールの割り当てのすべての条件が要求の属性と一致しているかどうかが判別されます。
- すべて一致する場合、アクセス許可が付与されます。
- 1 つでも要求の属性と一致しないものがある場合、ACL (4) が次に評価されます。
- ロールの割り当てと条件が評価された後にアクセス権が明示的に付与されていない場合、ACL が評価されます。
- ACL で要求されたレベルのアクセスが許可される場合、アクセス権が付与されます。
- 許可されない場合、アクセスは拒否されます。
重要
システムでアクセス許可が評価される方法のため、ロールの割り当てとその条件によって既に付与されているアクセス権は、ACL を使用して制限できません。 これは、システムが最初に Azure ロールの割り当てと条件を評価し、その割り当てによって十分なアクセス許可が付与された場合は、ACL が無視されるためです。
次の図は、ディレクトリの内容の一覧表示、ファイルの読み取り、ファイルの書き込みという 3 つの一般的な操作に対するアクセス許可フローを示しています。
アクセス許可の表: Azure RBAC、ABAC、ACL の組み合わせ
次の表は、セキュリティ プリンシパルが [操作] 列に示されている操作を実行できるように、Azure ロール、条件、ACL エントリを組み合わせる方法を示しています。 この表は、架空のディレクトリ階層の各レベルを表す列を示しています。 コンテナーのルート ディレクトリ (/)、Oregon という名前のサブディレクトリ、Portland という名前の Oregon ディレクトリのサブディレクトリ、および Data.txt という名前の Portland ディレクトリのテキスト ファイルの列があります。 これらの列には、アクセス許可を付与するために必要な ACL エントリが短い形式で表示されます。 操作を実行するために ACL エントリが必要ない場合は、列に該当なし (適用できません) と表示されます。
| 操作 | 割り当てられた Azure ロール (条件ありまたは条件なし) | / | Oregon/ | Portland/ | Data.txt |
|---|---|---|---|---|---|
| Read Data.txt | ストレージ BLOB データ所有者 | 該当なし | 該当なし | 該当なし | 該当なし |
| ストレージ BLOB データ共同作成者 | 該当なし | 該当なし | 該当なし | 該当なし | |
| ストレージ BLOB データ閲覧者 | 該当なし | 該当なし | 該当なし | N/A | |
| None | --X |
--X |
--X |
R-- |
|
| Append to Data.txt | ストレージ BLOB データ所有者 | 該当なし | 該当なし | 該当なし | 該当なし |
| ストレージ BLOB データ共同作成者 | 該当なし | 該当なし | 該当なし | 該当なし | |
| ストレージ BLOB データ閲覧者 | --X |
--X |
--X |
-W- |
|
| なし | --X |
--X |
--X |
RW- |
|
| Delete Data.txt | ストレージ BLOB データ所有者 | 該当なし | 該当なし | 該当なし | 該当なし |
| ストレージ BLOB データ共同作成者 | 該当なし | 該当なし | 該当なし | 該当なし | |
| ストレージ BLOB データ閲覧者 | --X |
--X |
-WX |
N/A | |
| None | --X |
--X |
-WX |
該当なし | |
| Create Data.txt | ストレージ BLOB データ所有者 | 該当なし | 該当なし | 該当なし | 該当なし |
| ストレージ BLOB データ共同作成者 | 該当なし | 該当なし | 該当なし | 該当なし | |
| ストレージ BLOB データ閲覧者 | --X |
--X |
-WX |
N/A | |
| None | --X |
--X |
-WX |
該当なし | |
| List / | ストレージ BLOB データ所有者 | 該当なし | 該当なし | 該当なし | 該当なし |
| ストレージ BLOB データ共同作成者 | 該当なし | 該当なし | 該当なし | 該当なし | |
| ストレージ BLOB データ閲覧者 | 該当なし | 該当なし | 該当なし | N/A | |
| None | R-X |
該当なし | 該当なし | 該当なし | |
| List /Oregon/ | ストレージ BLOB データ所有者 | 該当なし | 該当なし | 該当なし | 該当なし |
| ストレージ BLOB データ共同作成者 | 該当なし | 該当なし | 該当なし | 該当なし | |
| ストレージ BLOB データ閲覧者 | 該当なし | 該当なし | 該当なし | N/A | |
| None | --X |
R-X |
該当なし | 該当なし | |
| List /Oregon/Portland/ | ストレージ BLOB データ所有者 | 該当なし | 該当なし | 該当なし | 該当なし |
| ストレージ BLOB データ共同作成者 | 該当なし | 該当なし | 該当なし | 該当なし | |
| ストレージ BLOB データ閲覧者 | 該当なし | 該当なし | 該当なし | N/A | |
| None | --X |
--X |
R-X |
該当なし |
Note
Azure Storage Explorer でコンテナーの内容を表示するには、セキュリティ プリンシパルが Microsoft Entra ID を使用して Storage Explorer にサインインし、(少なくとも) コンテナーのルート フォルダー (\) への読み取りアクセス (R--) を持っている必要があります。 このアクセス許可レベルでは、ルート フォルダーの内容を一覧表示できます。 ルート フォルダーの内容が表示されないようにするには、[閲覧者] ロールを割り当てます。 このロールでは、アカウント内のコンテナーを一覧表示できますが、コンテナーの内容を表示することはできません。 その後、ACL を使用して、特定のディレクトリやファイルへのアクセスを許可できます。
セキュリティ グループ
ACL エントリでの割り当て済みのプリンシパルとして、常に Microsoft Entra セキュリティ グループを使用します。 個々のユーザーまたはサービス プリンシパルを直接割り当てることを抑止します。 この構造体を使用すると、ユーザーまたはサービス プリンシパルを追加したり削除したりすることができます。ACL をディレクトリ構造全体に再適用する必要はありません。 代わりに、適切な Microsoft Entra セキュリティ グループでユーザーとサービス プリンシパルを追加または削除できます。
グループを設定するには、さまざまな方法があります。 たとえば、サーバーによって生成されたログ データを保持する /LogData という名前のディレクトリがあるとします。 Azure Data Factory (ADF) により、そのフォルダーにデータが取り込まれます。 サービス エンジニアリング チームの特定のユーザーは、ログをアップロードし、このフォルダーの他のユーザーを管理します。また、さまざまな Databricks クラスターによって、そのフォルダーのログが分析されます。
これらのアクティビティを有効にするには、LogsWriter グループと LogsReader グループを作成します。 その後、次のようにアクセス許可を割り当てることができます。
LogsWriterグループを、rwxというアクセス許可で、 /LogData ディレクトリの ACL に追加します。LogsReaderグループを、r-xというアクセス許可で、 /LogData ディレクトリの ACL に追加します。- ADF に対するサービス プリンシパル オブジェクトまたは管理サービス ID (MSI) を、
LogsWritersグループに追加します。 - サービス エンジニアリング チームのユーザーを、
LogsWriterグループに追加します。 - Databricks に対するサービス プリンシパル オブジェクトまたは MSI を、
LogsReaderグループに追加します。
サービス エンジニアリング チームのユーザーが退職した場合は、LogsWriter グループから削除するだけで済みます。 そのユーザーをグループに追加せず、代わりにそのユーザーに専用の ACL エントリを追加した場合は、その ACL エントリを /LogData ディレクトリから削除する必要があります。 また、 /LogData ディレクトリのディレクトリ階層全体のすべてのサブディレクトリとファイルからも、エントリを削除する必要があります。
グループを作成してメンバーを追加するには、「Microsoft Entra ID を使用して基本グループを作成してメンバーを追加する」を参照してください。
重要
Azure Data Lake Storage Gen2 は、セキュリティ グループを管理するために Microsoft Entra ID に依存しています。 Microsoft Entra ID では、特定のセキュリティ プリンシパルのグループ メンバーシップを 200 未満に制限することを推奨しています。 この推奨は、Microsoft Entra アプリケーション内でセキュリティ プリンシパルのグループ メンバーシップ情報を提供する JSON Web Token (JWT) の制限によるものです。 この制限を超えると、Data Lake Storage Gen2 で予期しないパフォーマンスの問題が発生する可能性があります。 詳細については、「Microsoft Entra ID を使用してアプリケーションのグループ要求を構成する」を参照してください。
Azure ロールの割り当てと ACL エントリに対する制限
グループを使用すると、サブスクリプションごとのロール割り当ての最大数と、ファイルやディレクトリごとの ACL エントリの最大数を超える可能性が低くなります。 次の表に制限事項を示します。
| メカニズム | Scope | 制限 | サポートされているアクセス許可のレベル |
|---|---|---|---|
| Azure RBAC | ストレージ アカウント、コンテナー。 サブスクリプション レベルまたはリソース グループ レベルでのクロス リソース Azure ロールの割り当て。 |
サブスクリプションで 4,000 個の Azure ロールの割り当て | Azure ロール (組み込みまたはカスタム) |
| ACL | ディレクトリ、ファイル | ファイルごと、およびディレクトリごとに 32 個の ACL エントリ (実質的に 28 個の ACL エントリ)。 アクセス ACL と既定の ACL それぞれに、独自の 32 個の ACL エントリの制限があります。 | ACL アクセス許可 |
共有キーと Shared Access Signature (SAS) 認可
Azure Data Lake Storage Gen2 では、認証に共有キーと SAS の方法がサポートされています。 これらの認証方法の特徴は、呼び出し元に ID が関連付けられていないため、セキュリティ プリンシパルのアクセス許可ベースの承認を実行できないことです。
共有キーの場合、呼び出し元では効果的に 'スーパー ユーザー' のアクセス権が取得されます。つまり、データ、所有者の設定、ACL の変更を含む、すべてのリソースですべての操作に対してフル アクセス権を持つことになります。
SAS トークンには、トークンの一部として許可されるアクセス許可が含まれます。 SAS トークンに含まれるアクセス許可は、すべての承認の決定に効果的に適用されますが、追加の ACL チェックは行われません。
次の手順
アクセス制御リストの詳細については、「Azure Data Lake Storage Gen2 のアクセス制御リスト (ACL)」を参照してください。