Azure Data Lake Storage Gen1 でのアクセス制御

Azure Data Lake Storage Gen1 は、HDFS から派生したアクセス制御モデルを実装します。これは、POSIX アクセス制御モデルから派生します。 この記事では、Data Lake Storage Gen1 のアクセス制御モデルの基本について説明します。

ファイルとフォルダーのアクセス制御リスト

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

• アクセス ACL: オブジェクトへのアクセスを制御します。 ファイルとフォルダーの両方にアクセス ACL があります。

• 既定の ACL: そのフォルダーの下に作成されるすべての子アイテムのアクセス ACL を決定するフォルダーに関連付けられている ACL の "テンプレート" です。 ファイルには既定の ACL がありません。

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

権限

ファイルシステム オブジェクトに対するアクセス許可は 読み取り、 書き込み、 実行であり、次の表に示すように、ファイルとフォルダーで使用できます。

アクセス許可の簡略形

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

アクセス許可が継承されない

Data Lake Storage Gen1 によって使用される POSIX スタイルのモデルでは、項目に対するアクセス許可が項目自体に格納されます。 つまり、アイテムのアクセス許可を親アイテムから継承することはできません。

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

Data Lake Storage Gen1 アカウントで特定の操作を実行するために必要なアクセス許可を理解するのに役立つ一般的なシナリオを次に示します。

ユーザーと ID

すべてのファイルとフォルダーには、これらの ID に対する個別のアクセス許可があります。

• 所有権を持つユーザー
• 所有するグループ
• 名前付きユーザー
• 名前付きグループ
• その他のすべてのユーザー

ユーザーとグループの ID は、Microsoft Entra ID です。 したがって、特に明記されていない限り、Data Lake Storage Gen1 のコンテキストにおける "ユーザー" は、Microsoft Entra ユーザーまたは Microsoft Entra セキュリティ グループを意味します。

スーパー ユーザー

スーパー ユーザーは、Data Lake Storage Gen1 アカウント内のすべてのユーザーの最も多くの権限を持ちます。 スーパー ユーザーには、次の特長があります。

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

Data Lake Storage Gen1 アカウントの 所有者 ロールに含まれるすべてのユーザーは、自動的にスーパー ユーザーになります。

所有権を持つユーザー

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

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

所有しているグループ

背景

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

Data Lake Storage Gen1 のユーザーに関連付けられている "プライマリ グループ" がないため、所有グループは次のように割り当てられます。

新しいファイルまたはフォルダーの所有グループの割り当て

• ケース 1: ルート フォルダー "/" このフォルダーは、Data Lake Storage Gen1 アカウントの作成時に作成されます。 この場合、所有グループは、すべての桁が 0 の GUID に設定されます。 この値は、アクセスを許可しません。 これは、グループが割り当てられるまでプレースホルダーです。
• ケース 2 (他のすべてのケース): 新しいアイテムが作成されると、所有グループが親フォルダーからコピーされます。

所有グループの変更

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

• 任意のスーパー ユーザー
• 対象グループのメンバーでもある場合の所有ユーザー

アクセス チェック アルゴリズム

次の擬似コードは、Data Lake Storage Gen1 アカウントのアクセス チェック アルゴリズムを表します。

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 folder
  # Note: the "sticky bit" is not illustrated in this algorithm
  
# Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask IS NOT 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.permmissions & mask) == desired_perms)

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

マスク

アクセス チェック アルゴリズムに示すように、マスクは 、名前付きユーザー、 所有グループ、および 名前付きグループのアクセスを制限します。

スティッキービット (sticky bit)

スティッキー ビットは POSIX ファイルシステムのより高度な機能です。 Data Lake Storage Gen1 のコンテキストでは、スティッキー ビットが必要になることはほとんどありません。 要約すると、フォルダーでスティッキー ビットが有効になっている場合、子アイテムは、子アイテムの所有ユーザーのみが削除または名前変更できます。

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

新しいファイルとフォルダーに対する既定のアクセス許可

既存のフォルダーの下に新しいファイルまたはフォルダーを作成すると、親フォルダーの既定の ACL によって以下が決定されます。

• 子フォルダーの既定の ACL とアクセス ACL。
• 子ファイルのアクセス ACL (ファイルには既定の ACL がありません)。

umask

ファイルまたはフォルダーを作成するときに、umask を使用して、子項目に対する既定の ACL の設定方法を変更します。 umask は、所有ユーザー、所有グループ、およびその他のための RWX 値を含む親フォルダーの9ビット値です。

Azure Data Lake Storage Gen1 の umask は、007 に設定された定数値です。 この値は次の値に変換されます。

Azure Data Lake Storage Gen1 で使用される umask 値は、既定の ACL が示す内容に関係なく、新しいファイルやディレクトリに対して "その他" の権限が既定で設定されることは事実上ないことを意味します。

次の擬似コードは、子項目の ACL を作成するときに umask がどのように適用されるかを示しています。

def set_default_acls_for_new_child(parent, child):
    child.acls = []
    for entry in parent.acls :
        new_entry = None
        if (entry.type == OWNING_USER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_user))
        elif (entry.type == OWNING_GROUP) :
            new_entry = entry.clone(perms = entry.perms & (~umask.owning_group))
        elif (entry.type == OTHER) :
            new_entry = entry.clone(perms = entry.perms & (~umask.other))
        else :
            new_entry = entry.clone(perms = entry.perms )
        child_acls.add( new_entry )

Data Lake Storage Gen1 の ACL に関する一般的な質問

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

いいえ。 Data Lake Storage Gen1 アカウントでは、ACL を使用したアクセス制御が常にオンになっています。

フォルダーとその内容を再帰的に削除するには、どのアクセス許可が必要ですか?

• 親フォルダーには 、書き込み + 実行 のアクセス許可が必要です。
• 削除するフォルダーとその中のすべてのフォルダーには、 読み取り + 書き込み + 実行 のアクセス許可が必要です。

ファイルまたはフォルダーの所有者は誰ですか?

ファイルまたはフォルダーの作成者が所有者になります。

作成時にファイルまたはフォルダーの所有グループとして設定されるグループはどれですか?

所有グループは、新しいファイルまたはフォルダーが作成される親フォルダーの所有グループからコピーされます。

私はファイルの所有ユーザーですが、必要なRWXアクセス許可がありません。 どうしようか。

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

Azure portal で ACL を見ると、ユーザー名が表示されますが、API を介して GUID が表示されますが、それはなぜですか?

ACL 内のエントリは、Microsoft Entra ID のユーザーに対応する GUID として格納されます。 API は GUID をそのまま返します。 Azure portal では、可能な場合は GUID をフレンドリ名に変換することで、ACL の使用を容易にしようとします。

Azure portal を使用しているときに ACL に GUID が表示されることがあります。

ユーザーが Microsoft Entra に存在しなくなった場合は、GUID が表示されます。 通常、ユーザーが会社を辞めた場合や Microsoft Entra ID でそのアカウントが削除された場合に、この現象が発生します。 また、ACL の設定に適切な ID を使用していることを確認します (詳細については、以下を参照してください)。

サービス プリンシパルを使用する場合、ACL を設定するためにどのような ID を使用する必要がありますか?

Azure Portal で、 Microsoft Entra ID -> Enterprise アプリケーション に移動し、アプリケーションを選択します。 [ 概要 ] タブにはオブジェクト ID が表示されます。これは、データ アクセス用の ACL を追加するときに使用する必要があります (アプリケーション ID ではありません)。

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

いいえ。ただし、既定の ACL を使用して、親フォルダーの下に新しく作成された子ファイルとフォルダーの ACL を設定できます。

ファイルとフォルダーの ACL エントリの制限は何ですか?

ファイルごと、ディレクトリごとに 32 個の ACL を設定できます。 アクセス ACL と既定の ACL それぞれに、独自の 32 個の ACL エントリの制限があります。 可能であれば、ACL の割り当てにセキュリティ グループを使用します。 グループを使用すると、ファイルまたはディレクトリあたりの ACL エントリの最大数を超える可能性が低くなります。

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 Gen1 の概要