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

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

Azure Data Lake Storageの ACL について

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

Azure Data Lake Storageで ACL を設定する方法

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

ACL の種類: アクセス ACL と既定の ACL

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

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

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

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

アクセス許可のレベル

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

アクセス許可の短い形式

RWX を使用して、読み取り + 書き込み + 実行のアクセス許可を表示します。 数値形式もあります。 Read=4、 Write=2、 Execute=1 です。 これらの番号を追加して、アクセス許可を表示します。 次に例をいくつか示します。

アクセス許可の継承

Data Lake Storage使用する POSIX スタイルのモデルでは、アイテム自体に対するアクセス許可をアイテムに格納します。 つまり、子項目の作成後にアクセス許可を設定した場合、子項目は親アイテムからアクセス許可を継承できません。 アイテムは、子アイテムを作成する前に親アイテムに既定のアクセス許可を設定した場合にのみアクセス許可を継承します。 たとえば、ディレクトリを作成し、後で既定の ACL を設定した場合、そのディレクトリに既に存在するファイルは新しい既定の ACL を継承しません。 ACL を設定した後に作成されたファイルのみが、それを継承します。

Azure Data Lake Storageでの ACL アクセス許可の一般的なシナリオ

次の表に、セキュリティ プリンシパルが [操作 ] 列に一覧表示されている操作を実行できるようにするために必要な ACL エントリを示します。

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

ファイルとディレクトリを削除する

ファイルを削除するには、ファイル自体に対する書き込みアクセス許可は必要ありません。 親ディレクトリには -WX アクセス許可のみが必要です。 ただし、ディレクトリとそのすべての内容を削除するには、親ディレクトリに書き込み + 実行のアクセス許可が必要です。 削除対象のディレクトリとその中のすべてのディレクトリには、読み取り + 書き込み + 実行アクセス許可が必要

ACL 内のユーザーと 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 (その他すべてのケース): 新しい項目が作成されると、所有グループが親ディレクトリからコピーされます。

所有グループの変更

所有グループは次の方法で変更できます。

• 任意のスーパー ユーザー。
• 所有ユーザー (その所有ユーザーがターゲットグループのメンバーである場合)

システムが ACL アクセス許可を評価する方法

システムは、次の順序で ID を評価します。

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

これらの 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)

ACL マスク

マスクは、名前付きユーザー、名前付きグループ、および所有グループの ACL エントリにのみ適用されます。 マスクは、アクセスの承認に使用される ACL エントリ内のアクセス許可を指定します。 これらの適用されたアクセス許可は、ACL エントリの "有効な" アクセス許可と呼ばれます。 システムは、ACL エントリ内の他のすべてのアクセス許可を無視します。 マスクを使用すると、アクセス許可レベルに上限を設定できます。

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

Data Lake Storage のスティッキー ビット

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

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

ルート ディレクトリの既定のアクセス許可

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

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

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

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

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

Data Lake Storage における umask

既定の ACL を作成すると、システムはアクセス ACL に umask を適用して、既定の ACL の初期アクセス許可を決定します。 親ディレクトリに既定の ACL を定義すると、システムは umask を無視し、親ディレクトリの既定の ACL を使用して初期値を設定します。

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

Azure Data Lake Storageの umask は、007 に設定された定数値です。 この値は次のとおりです：

FAQ

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

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

HNS がオフの場合でも、Azure RBAC 承認規則が適用されます。

ACL を適用する最善の方法

ACL エントリでの割り当て済みのプリンシパルとして、常に Microsoft Entra セキュリティ グループを使用します。 個々のユーザーまたはサービス プリンシパルを直接割り当てることを抑止します。 この構造体を使用すると、ユーザーまたはサービス プリンシパルを追加したり削除したりすることができます。ACL をディレクトリ構造全体に再適用する必要はありません。 代わりに、適切な Microsoft Entra セキュリティ グループでユーザーとサービス プリンシパルを追加または削除できます。

グループを設定するには、さまざまな方法があります。 たとえば、サーバーによって生成されたログ データを保持する /LogData という名前のディレクトリがあるとします。 Azure Data Factory (ADF) により、そのフォルダーにデータが取り込まれます。 サービス エンジニアリング チームの特定のユーザーは、ログをアップロードし、このフォルダーの他のユーザーを管理します。また、さまざまな Databricks クラスターによって、そのフォルダーのログが分析されます。

これらのアクティビティを有効にするには、LogsWriter グループと LogsReader グループを作成します。 その後、次のようにアクセス許可を割り当てることができます。

• LogsWriter グループをアクセス権限でrwx ディレクトリのACLに追加します。
• LogsReader グループをアクセス権限でr-x ディレクトリの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 が 00001111-aaaa-2222-bbbb-3333cccc4444 のアプリ登録に対応するサービス プリンシパルの OID を取得する例を次に示します。 Azure CLI で、次のコマンドを実行します。

az ad sp show --id 00001111-aaaa-2222-bbbb-3333cccc4444 --query objectId

このコマンドは OID を表示します。

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

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

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

Azure Storage REST API には、コンテナー 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 のアクセス制御モデル