Azure Data Lake Storage のアクセス制御リスト (ACL)

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

ACL について

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

ACL を設定する方法

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

ACL の種類

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

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

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

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

アクセス許可のレベル

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

アクセス許可の短い形式

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

アクセス許可の継承

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

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

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

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

ファイルとディレクトリの削除

前の表に示すように、ディレクトリのアクセス許可が適切に設定されていれば、ファイルを削除するために、ファイルに対する書き込みアクセス許可は必要ありません。 ただし、ディレクトリとそのすべての内容を削除するには、親ディレクトリに書き込み + 実行のアクセス許可が必要です。 削除対象のディレクトリとその中のすべてのディレクトリには、読み取り + 書き込み + 実行アクセス許可が必要

ユーザーと ID

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

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

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

スーパー ユーザー

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

• すべてのファイルとフォルダーに対して、RWX アクセス許可を持ちます。

• 任意のファイルまたはフォルダーのアクセス許可を変更できます。

• 任意のファイルまたはフォルダーの所有ユーザーまたは所有グループを変更できます。

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

所有ユーザー

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

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

所有グループ

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

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

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

所有グループの変更

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

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

権限を評価する方法

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

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

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

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

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

スティッキー ビット

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

スティッキー ビットは、Azure portal には表示されません。 スティッキー ビットとその設定方法の詳細については、「Data Lake Storage のスティッキー ビットは何ですか?」を参照してください。

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

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

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

umask

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

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

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

よく寄せられる質問

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

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

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

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

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

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

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

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

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

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

または

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

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

ファイルまたはディレクトリの作成者が所有者になります。 ルート ディレクトリの場合、これはコンテナーを作成したユーザーの 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 が ffffffff-eeee-dddd-cccc-bbbbbbbbbbb0 のアプリ登録に対応するサービス プリンシパルの 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 データの匿名読み取りアクセスの修復」を参照してください。

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

• POSIX Access Control Lists on Linux (Linux での POSIX アクセス制御リスト)
• HDFS Permission Guide (HDFS アクセス許可ガイド)
• POSIX FAQ (POSIX のよく寄せられる質問)
• POSIX 1003.1 2008
• POSIX 1003.1 2013
• POSIX 1003.1 2016
• Ubuntu での POSIX ACL

関連項目

• Azure Data Lake Storage のアクセス制御モデル