AzureData Lake Storage Gen2 のアクセス制御リスト (ACL)

[アーティクル]
08/30/2023

Azure Data Lake Storage Gen2 では、Azure ロールベースのアクセス制御 (Azure RBAC) と POSIX のようなアクセス制御リスト (ACL) の両方をサポートするアクセス制御モデルが実装されています。この記事では、Data Lake Storage Gen2 のアクセス制御リストについて説明します。 Azure RBAC を ACL に一緒に組み込む方法と、それらをシステムで評価して認可の決定を行う方法の詳細については、「Azure Data Lake Storage Gen2 でのアクセス制御モデル」を参照してください。

ACL について

セキュリティプリンシパルをファイルおよびディレクトリに対するアクセスレベルと関連付けることができます。各関連付けは、アクセス制御リスト (ACL) のエントリとしてキャプチャされます。ストレージアカウント内の各ファイルおよびディレクトリは、アクセス制御リストを持っています。セキュリティプリンシパルがファイルまたはディレクトリに対して操作を実行しようとすると、ACL チェックによって、そのセキュリティプリンシパル (ユーザー、グループ、サービスプリンシパル、またはマネージド ID) が、その操作を実行するための適切なアクセス許可レベルを持っているかどうかが判断されます。

Note

ACL は同じテナント内のセキュリティプリンシパルにのみ適用され、共有キーまたは Shared Access Signature (SAS) トークン認証を使用するユーザーには適用されません。これは、呼び出し元に ID が関連付けられていないため、セキュリティプリンシパルのアクセス許可ベースの認可を実行できないことが原因です。

ACL を設定する方法

ファイルおよびディレクトリレベルのアクセス許可を設定するには、次のいずれかの記事をご覧ください。

環境	[アーティクル]
Azure ストレージエクスプローラー	Azure Storage Explorer を使用して Azure Data Lake Storage Gen2 での ACL を管理する
Azure portal	Azure portal を使用して Azure Data Lake Storage Gen2 で ACL を管理する
.NET	Azure Data Lake Storage Gen2 で .NET を使用して ACL を管理する
Java	Azure Data Lake Storage Gen2 で Java を使用して ACL を管理する
Python	Azure Data Lake Storage Gen2 で Python を使用して ACL を管理する
JavaScript (Node.js)JavaScript (Node.js)	Azure Data Lake Storage Gen2 で JavaScript (Node.js の SDK) を使用して ACL を管理する
PowerShell	Azure Data Lake Storage Gen2 で PowerShell を使用して ACL を管理する
Azure CLI	Azure Data Lake Storage Gen2 で Azure CLI を使用して ACL を管理する
REST API	Path - Update (パス - 更新)

重要

セキュリティプリンシパルが "サービス" プリンシパルである場合は、関連するアプリ登録のオブジェクト ID ではなく、サービスプリンシパルのオブジェクト ID を使うことが重要です。サービスプリンシパルのオブジェクト ID を取得するには、Azure CLI を開き、az ad sp show --id <Your App ID> --query objectId コマンドを使います。 <Your App ID> プレースホルダーは、アプリ登録のアプリ ID に置き換えます。サービスプリンシパルは、名前付きユーザーとして扱われます。この ID は、任意の名前付きユーザーの場合と同様に ACL に追加します。名前付きユーザーについては、この記事の後半で説明します。

ACL の種類

アクセス制御リストには、"アクセス ACL" と "既定の ACL" の 2 種類があります。

アクセス ACL はオブジェクトへのアクセスを制御します。ファイルとディレクトリの両方がアクセス ACL を持っています。

既定の ACL は、ディレクトリに関連付けられた ACL のテンプレートです。この ACL によって、そのディレクトリの下に作成されるすべての子項目のアクセス ACL が決まります。ファイルには既定の ACL がありません。

アクセス ACL と既定の ACL はどちらも同じ構造です。

Note

親の既定の ACL を変更しても、既存の子項目のアクセス ACL または既定の ACL には影響しません。

アクセス許可のレベル

コンテナー内のディレクトリとファイルに対するアクセス許可は、読み取り、書き込み、実行です。これらは、次の表に示すようにファイルとディレクトリに対して使用できます。

	ファイル	ディレクトリ
読み取り (R)	ファイルの内容を読み取ることができる	ディレクトリの内容を一覧表示するには、読み取りと実行が必要です。
書き込み (W)	ファイルへの書き込みまたは追加を実行できる	ディレクトリに子項目を作成するには、書き込みと実行が必要です。
実行 (X)	Data Lake Storage Gen2 のコンテキストでは、何も意味しない	ディレクトリの子項目をスキャンするために必要です。

Note

ACL のみを使用して (Azure RBAC なしで) アクセス許可を付与する場合、セキュリティプリンシパルにファイルの読み取りまたは書き込みアクセス権を付与するには、コンテナーのルートフォルダー、およびそのファイルに至るフォルダー階層内の各フォルダーに対する実行アクセス許可をセキュリティプリンシパルに付与する必要があります。

アクセス許可の短い形式

RWX は、読み取り + 書き込み + 実行を示すために使用されます。さらに縮約された数値形式もあります。読み取り = 4、書き込み = 2、実行 = 1 で、その合計でアクセス許可を表します。次は一部の例です。

数値形式	短縮形式	意味
7	`RWX`	読み取り + 書き込み + 実行
5	`R-X`	読み取り + 実行
4	`R--`	Read
0	`---`	アクセス許可なし

アクセス許可の継承

Data Lake Storage Gen2 で使用されている POSIX 形式のモデルでは、項目のアクセス許可は項目自体に格納されます。つまり、子アイテムがすでに作成された後に権限が設定されている場合、親アイテムからアイテムの権限を継承することはできません。子項目が作成される前に、親項目で既定のアクセス許可が設定されている場合にのみ、アクセス許可が継承されます。

次の表は、Operation 列に示されている操作を実行するためにセキュリティプリンシパルを有効にするのに必要な ACL エントリを示します。

この表は、架空のディレクトリ階層の各レベルを表す列を示しています。コンテナーのルートディレクトリ (/)、Oregon という名前のサブディレクトリ、Portland という名前の Oregon ディレクトリのサブディレクトリ、および Data.txt という名前の Portland ディレクトリのテキストファイルの列があります。

重要

この表は、Azure ロールの割り当てを使用せずに ACL のみを使用していることを前提としています。 Azure RBAC と ACL を組み合わせた同様の表を確認するには、「アクセス許可の表: Azure RBAC、ABAC、および ACL の組み合わせ」を参照してください。

Operation	/	Oregon/	Portland/	Data.txt
Read Data.txt	`--X`	`--X`	`--X`	`R--`
Append to Data.txt	`--X`	`--X`	`--X`	`RW-`
Delete Data.txt	`--X`	`--X`	`-WX`	`---`
Create Data.txt	`--X`	`--X`	`-WX`	`---`
List /	`R-X`	`---`	`---`	`---`
List /Oregon/	`--X`	`R-X`	`---`	`---`
List /Oregon/Portland/	`--X`	`--X`	`R-X`	`---`

Note

上の 2 つの条件が満たされていれば、ファイルを削除するために、ファイルに対する書き込みアクセス許可は必要ありません。

ユーザーと ID

すべてのファイルとディレクトリは、以下の ID の個別のアクセス許可を持っています。

所有ユーザー
所有グループ
名前付きユーザー
名前付きグループ
名前付きサービスプリンシパル
名前付きマネージド ID
その他のすべてのユーザー

ユーザーとグループの ID は、Microsoft Entra ID です。そのため、注記がない限り、Data Lake Store Gen2 のコンテキストでの "ユーザー" は、Microsoft Entra のユーザー、サービスプリンシパル、マネージド ID、またはセキュリティグループを意味します。

スーパーユーザー

スーパーユーザーは、すべてのユーザーの中で、最高の権限を持ちます。スーパーユーザーには、次の特長があります。

すべてのファイルとフォルダーに対して、RWX アクセス許可を持ちます。
任意のファイルまたはフォルダーのアクセス許可を変更できます。
任意のファイルまたはフォルダーの所有ユーザーまたは所有グループを変更できます。

共有キー、アカウント SAS、またはサービス SAS を使ってコンテナー、ファイル、またはディレクトリを作成した場合は、所有者と所有グループは $superuser に設定されます。

所有ユーザー

項目を作成したユーザーは、自動的に項目の所有ユーザーになります。所有ユーザーは、次のことができます。

所有しているファイルのアクセス許可を変更します。
所有しているファイルの所有グループを変更します。ただし、所有ユーザーが変更後のグループのメンバーでもある必要があります。

Note

所有ユーザーが、ファイルやディレクトリの所有ユーザーを変更することはできません。ファイルまたはディレクトリの所有ユーザーを変更できるのは、スーパーユーザーだけです。

所有グループ

POSIX ACL では、すべてのユーザーがプライマリグループに関連付けられています。たとえば、ユーザー "Alice" が "finance" グループに属しているとします。 Alice は複数のグループに属している可能性がありますが、1 つのグループが常にプライマリグループとして指定されています。 POSIX では、Alice がファイルを作成すると、そのファイルの所有グループが彼女のプライマリグループに設定されます。ここでは、"finance" グループです。その他の点では、所有グループの動作は、他のユーザーまたはグループに割り当てられているアクセス許可と同様です。

新しいファイルまたはディレクトリに対する所有グループの割り当て

ケース 1: ルートディレクトリ /。このディレクトリは、Data Lake Storage Gen2 コンテナーの作成時に作成されます。この場合、OAuth を使用してコンテナーが作成された場合は、所有グループはそれを作成したユーザーに設定されます。共有キー、アカウント SAS、またはサービス SAS を使用してコンテナーを作成した場合は、所有者と所有グループは $superuser に設定されます。
ケース 2 (その他すべてのケース): 新しい項目が作成されると、所有グループが親ディレクトリからコピーされます。

所有グループの変更

所有グループを変更できるユーザーは次のとおりです。

すべてのスーパーユーザー
所有ユーザー (所有ユーザーが変更後のグループのメンバーでもある場合)

Note

所有グループが、ファイルやディレクトリの ACL を変更することはできません。ルートディレクトリの場合 (上記のケース 1)、所有グループはアカウントを作成したユーザーに設定されますが、所有グループを介したアクセス許可の付与に関して、単一ユーザーアカウントは有効ではありません。この権限は、有効なユーザーグループに対して、該当する場合に割り当てることができます。

権限を評価する方法

ID は、次の順序で評価されます。

スーパーユーザー
所有ユーザー
名前付きユーザー、サービスプリンシパル、またはマネージド ID
所有グループまたは名前付きグループ
その他のすべてのユーザー

これらの ID のうち複数の ID がセキュリティプリンシパルに適用される場合、最初の ID に関連付けられているアクセス許可レベルが付与されます。たとえば、セキュリティプリンシパルが所有ユーザーと名前付きユーザーの両方である場合、所有ユーザーに関連付けられているアクセス許可レベルが適用されます。

名前付きグループはすべて一緒に考慮されます。セキュリティプリンシパルが複数の名前付きグループのメンバーである場合、必要なアクセス許可が付与されるまで、システムでは各グループが評価されます。名前付きグループのいずれも目的のアクセス許可を提供しない場合、システムは他のすべてのユーザーに関連付けられているアクセス許可に対する要求の評価に移ります。

次の擬似コードは、ストレージアカウントのアクセス確認アルゴリズムを示しています。このアルゴリズムは、ID が評価される順序を示します。

def access_check( user, desired_perms, path ) :
  # access_check returns true if user has the desired permissions on the path, false otherwise
  # user is the identity that wants to perform an operation on path
  # desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
  # path is the file or directory
  # Note: the "sticky bit" isn't illustrated in this algorithm

  # Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask isn't used.
  entry = get_acl_entry( path, OWNER )
  if (user == entry.identity)
      return ( (desired_perms & entry.permissions) == desired_perms )

  # Handle the named users. Note that mask IS used.
  entries = get_acl_entries( path, NAMED_USER )
  for entry in entries:
      if (user == entry.identity ) :
          mask = get_mask( path )
          return ( (desired_perms & entry.permissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  mask = get_mask( path )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
        if ((desired_perms & entry.permissions & mask) == desired_perms)
            return True

  # Handle other
  perms = get_perms_for_other(path)
  mask = get_mask( path )
  return ( (desired_perms & perms & mask ) == desired_perms)

マスク

アクセス確認アルゴリズムに示されているように、マスクによって、名前付きユーザー、所有グループ、および名前付きグループのアクセスが制限されます。

新しい Data Lake Storage Gen2 コンテナーでは、ルートディレクトリ ("/") のアクセス ACL のマスクは、ディレクトリの場合は 750、ファイルの場合は 640 に既定で設定されています。次の表は、これらのアクセス許可レベルのシンボリック表記を示しています。

Entity	ディレクトリ	ファイル
所有ユーザー	`rwx`	`rw-`
所有グループ	`r-x`	`r--`
その他	`---`	`---`

ファイルは格納専用のシステム内のファイルとは無関係であるため、X ビットを受け取りません。

マスクは、呼び出しごとに指定できます。これにより、クラスターなどのさまざまな使用システムが、ファイル操作に対して異なる有効なマスクを持つことができます。特定の要求でマスクが指定されると、既定のマスクが完全にオーバーライドされます。

スティッキービット

スティッキービットは、POSIX コンテナーのより高度な機能です。 Data Lake Storage Gen2 のコンテキストでは、スティッキービットが必要になることはあまりありません。つまり、ディレクトリでスティッキービットが有効になっている場合、子項目を削除または名前変更できるのは、子項目を所有しているユーザー、ディレクトリの所有者、またはスーパーユーザー ($superuser) のみです。

スティッキービットは、Azure portal には表示されません。

新しいファイルとディレクトリの既定のアクセス許可

既存のディレクトリの下に新しいファイルまたはディレクトリが作成されると、親ディレクトリの既定の ACL によって、次のものが決定します。

子ディレクトリの既定の ACL とアクセス ACL。
子ファイルのアクセス ACL (ファイルには既定の ACL がありません)。

umask

既定の ACL を作成するときに、umask がアクセス ACL に適用され、既定の ACL の初期アクセス許可が決定されます。親ディレクトリに既定の ACL が定義されている場合、umask は実質的に無視され、代わりに親ディレクトリの既定の ACL を使用してこれらの初期値が定義されます。

umask は親ディレクトリに設定される 9 ビットの値であり、所有ユーザー、所有グループ、その他に対する RWX 値が含まれています。

Azure Data Lake Storage Gen2 に対する umask は、007 に設定される定数値です。この値の変換値:

umask コンポーネント	数値形式	短縮形式	意味
umask.owning_user	0	`---`	所有ユーザーの場合、親のアクセス ACL を子の既定の ACL にコピーします
umask.owning_group	0	`---`	所有グループの場合、親のアクセス ACL を子の既定の ACL にコピーします
umask.other	7	`RWX`	その他の場合、子のアクセス ACL 上のすべてのアクセス許可を削除します

よく寄せられる質問

ACL のサポートを有効にする必要はありますか

いいえ。階層型名前空間 (HNS) 機能がオンになっている限り、ストレージアカウントの ACL によるアクセス制御は有効です。

HNS がオフになっている場合、Azure RBAC の承認規則が引き続き適用されます。

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 RBAC と ACL のアクセス許可はどのように評価されますか?

システムが Azure RBAC と ACL をまとめて評価し、ストレージアカウントリソースに対する認可の決定を行う方法については、「アクセス許可の評価方法」を参照してください。

Azure ロールの割り当てと ACL エントリにはどのような制限がありますか。

次の表に、Azure RBAC を使用して "粒度の粗い" アクセス許可 (ストレージアカウントまたはコンテナーに適用されるアクセス許可) を管理し、ACL を使用して "粒度の細かい" アクセス許可 (ファイルとディレクトリに適用されるアクセス許可) を管理する際に考慮する制限の概要ビューを示します。 ACL 割り当て用のセキュリティグループを使用します。グループを使用すると、サブスクリプションごとのロール割り当ての最大数と、ファイルやディレクトリごとの ACL エントリの最大数を超える可能性が低くなります。

メカニズム	Scope	制限	サポートされているアクセス許可のレベル
Azure RBAC	ストレージアカウント、コンテナー。サブスクリプションレベルまたはリソースグループレベルでのクロスリソース Azure ロールの割り当て。	サブスクリプションで 4,000 個の Azure ロールの割り当て	Azure ロール (組み込みまたはカスタム)
ACL	ディレクトリ、ファイル	ファイルごと、およびディレクトリごとに 32 個の ACL エントリ (実質的に 28 個の ACL エントリ)。アクセス ACL と既定の ACL それぞれに、独自の 32 個の ACL エントリの制限があります。	ACL アクセス許可

Data Lake Storage Gen2 は Azure RBAC の継承をサポートしていますか。

Azure ロールの割り当ては継承されます。割り当ては、サブスクリプション、リソースグループ、ストレージアカウントリソースからコンテナーリソースに渡されます。

Data Lake Storage Gen2 は ACL の継承をサポートしていますか。

親ディレクトリの下に作成される新しい子サブディレクトリやファイルについては、既定の ACL を使用して ACL を設定できます。既存の子項目の ACL を更新するには、目的のディレクトリ階層に対して ACL を再帰的に追加、更新、または削除する必要があります。ガイダンスについては、この記事の「ACL を設定する方法」セクションを参照してください。

ディレクトリとその内容を再帰的に削除するのに必要なアクセス許可を教えてください

呼び出し元に 'スーパーユーザー' アクセス許可がある

または

親ディレクトリには、書き込み + 実行アクセス許可が必要
削除対象のディレクトリとその中のすべてのディレクトリには、読み取り + 書き込み + 実行アクセス許可が必要

Note

ディレクトリ内のファイルを削除するには、書き込みアクセス許可は必要ありません。また、ルートディレクトリ "/" を削除することはできません。

ファイルまたはディレクトリの所有者として設定されるのはだれですか

ファイルまたはディレクトリの作成者が所有者になります。ルートディレクトリの場合、これはコンテナーを作成したユーザーの ID です。

ファイルまたはディレクトリの作成時に、所有グループとして設定されるのはどのグループですか

所有グループは、新しいファイルまたはディレクトリが作成される親ディレクトリの所有グループからコピーされます。

ファイルの所有ユーザーですが、必要な RWX アクセス許可を持っていません。どうすればよいですか。

所有ユーザーは、ファイルのアクセス許可を変更して、必要な任意の RWX アクセス許可を自分に与えることができます。

ACL に GUID が表示されることがあるのはなぜですか

エントリがユーザーを表し、そのユーザーがもう Microsoft Entra に存在しなくなった場合に、GUID が表示されます。通常、ユーザーが会社を辞めた場合や Microsoft Entra ID でそのアカウントが削除された場合に、この現象が発生します。さらに、サービスプリンシパルおよびセキュリティグループには、それらを識別するためのユーザープリンシパル名 (UPN) がないため、これらは自身の OID 属性 (guid) で表されます。 ACL をクリーンアップするには、これらの GUID エントリを手動で削除します。

サービスプリンシパル用 ACL を正しく設定するにはどうすればよいですか。

サービスプリンシパル用 ACL を定義するときは、作成したアプリ登録に対応する "サービスプリンシパル" のオブジェクト ID (OID) を使用することが重要です。登録済みアプリについては、特定の Microsoft Entra テナントに個別のサービスプリンシパルがあることに注意してください。登録済みアプリの OID は Azure portal に表示されていますが、その "サービスプリンシパル" には別の (異なる) OID があります。アプリ登録に対応するサービスプリンシパルの OID を取得するには、az ad sp show コマンドを使用できます。パラメーターとしてアプリケーション ID を指定します。アプリ ID が 18218b12-1895-43e9-ad80-6e8fc1ea88ce のアプリ登録に対応するサービスプリンシパルの OID を取得する例を次に示します。 Azure CLI で、次のコマンドを実行します。

az ad sp show --id 18218b12-1895-43e9-ad80-6e8fc1ea88ce --query objectId

OID が表示されます。

サービスプリンシパルの正しい OID を取得したら、Storage Explorer で [アクセスの管理] ページに移動して OID を追加し、その OID に対する適切なアクセス許可を割り当てます。その後、必ず [保存] を選択してください

コンテナーの ACL を設定できますか。

いいえ。コンテナーに ACL がありません。ただし、コンテナーのルートディレクトリの ACL を設定できます。すべてのコンテナーにはルートディレクトリがあり、コンテナーと同じ名前を共有します。たとえば、コンテナーに my-container という名前が付けられている場合、ルートディレクトリの名前は my-container/ になります。

Azure Storage REST API には Set Container ACLという操作が含まれていますが、この操作を使用してコンテナーの ACL またはコンテナーのルートディレクトリを設定することはできません。そうではなく、コンテナー内の BLOB が匿名要求を使ってアクセス可能かどうかを示すためにこの操作が使われます。 BLOB データに対するすべての要求に対して認可を要求することをお勧めします。詳細については、「概要: BLOB データの匿名読み取りアクセスの修復」を参照してください。

AzureData Lake Storage Gen2 のアクセス制御リスト (ACL)

ACL について

ACL を設定する方法

ACL の種類

アクセス許可のレベル

アクセス許可の短い形式

アクセス許可の継承

ユーザーと ID

スーパーユーザー

所有ユーザー

所有グループ

新しいファイルまたはディレクトリに対する所有グループの割り当て

所有グループの変更

権限を評価する方法

マスク

スティッキービット

新しいファイルとディレクトリの既定のアクセス許可

umask

よく寄せられる質問

ACL のサポートを有効にする必要はありますか

ACL を適用する最善の方法

Azure RBAC と ACL のアクセス許可はどのように評価されますか?

Azure ロールの割り当てと ACL エントリにはどのような制限がありますか。

Data Lake Storage Gen2 は Azure RBAC の継承をサポートしていますか。

Data Lake Storage Gen2 は ACL の継承をサポートしていますか。

ディレクトリとその内容を再帰的に削除するのに必要なアクセス許可を教えてください

ファイルまたはディレクトリの所有者として設定されるのはだれですか

ファイルまたはディレクトリの作成時に、所有グループとして設定されるのはどのグループですか

ファイルの所有ユーザーですが、必要な RWX アクセス許可を持っていません。どうすればよいですか。

ACL に GUID が表示されることがあるのはなぜですか

サービスプリンシパル用 ACL を正しく設定するにはどうすればよいですか。

コンテナーの ACL を設定できますか。

POSIX アクセス制御モデルの詳細はどこで確認できますか

関連項目

その他のリソース

AzureData Lake Storage Gen2 のアクセス制御リスト (ACL)

ACL について

ACL を設定する方法

ACL の種類

アクセス許可のレベル

アクセス許可の短い形式

アクセス許可の継承

ACL アクセス許可に関連する一般的なシナリオ

ユーザーと ID

スーパー ユーザー

所有ユーザー

所有グループ

新しいファイルまたはディレクトリに対する所有グループの割り当て

所有グループの変更

権限を評価する方法

マスク

スティッキー ビット

新しいファイルとディレクトリの既定のアクセス許可

umask

よく寄せられる質問

ACL のサポートを有効にする必要はありますか

ACL を適用する最善の方法

Azure RBAC と ACL のアクセス許可はどのように評価されますか?

Azure ロールの割り当てと ACL エントリにはどのような制限がありますか。

Data Lake Storage Gen2 は Azure RBAC の継承をサポートしていますか。

Data Lake Storage Gen2 は ACL の継承をサポートしていますか。

ディレクトリとその内容を再帰的に削除するのに必要なアクセス許可を教えてください

ファイルまたはディレクトリの所有者として設定されるのはだれですか

ファイルまたはディレクトリの作成時に、所有グループとして設定されるのはどのグループですか

ファイルの所有ユーザーですが、必要な RWX アクセス許可を持っていません。 どうすればよいですか。

ACL に GUID が表示されることがあるのはなぜですか

サービス プリンシパル用 ACL を正しく設定するにはどうすればよいですか。

コンテナーの ACL を設定できますか。

POSIX アクセス制御モデルの詳細はどこで確認できますか

関連項目

その他のリソース

スーパーユーザー

スティッキービット

ファイルの所有ユーザーですが、必要な RWX アクセス許可を持っていません。どうすればよいですか。

サービスプリンシパル用 ACL を正しく設定するにはどうすればよいですか。