Azure Data Lake Storage Gen2 のアクセス制御Access control in Azure Data Lake Storage Gen2

Azure Data Lake Storage Gen2 では、Azure のロールベースのアクセス制御 (RBAC) と POSIX のようなアクセス制御リスト (ACL) の両方をサポートするアクセス制御モデルが実装されています。Azure Data Lake Storage Gen2 implements an access control model that supports both Azure role-based access control (RBAC) and POSIX-like access control lists (ACLs). この記事では、Data Lake Storage Gen2 のアクセス制御モデルの基本について説明します。This article summarizes the basics of the access control model for Data Lake Storage Gen2.

ロールベースのアクセス制御Role-based access control

RBAC では、ロールの割り当てを使用して、"セキュリティ プリンシパル" にアクセス許可のセットが効果的に適用されます。RBAC uses role assignments to effectively apply sets of permissions to security principals. "セキュリティ プリンシパル" は、Azure リソースへのアクセスを要求している、Azure Active Directory (AD) で定義されたユーザー、グループ、サービス プリンシパル、またはマネージド ID を表すオブジェクトです。A security principal is an object that represents a user, group, service principal, or managed identity that is defined in Azure Active Directory (AD) that is requesting access to Azure resources.

通常、それらの Azure リソースは、最上位のリソースに制約されます (例: Azure ストレージ アカウント)。Typically, those Azure resources are constrained to top-level resources (For example: Azure Storage accounts). Azure Storage およびその結果の Azure Data Lake Storage Gen2 の場合、このメカニズムは、コンテナー (ファイル システム) のリソースに拡張されています。In the case of Azure Storage, and consequently Azure Data Lake Storage Gen2, this mechanism has been extended to the container (file system) resource.

お使いのストレージ アカウントのスコープでセキュリティ プリンシパルにロールを割り当てる方法については、「Azure portal で RBAC を使用して Azure BLOB とキューのデータへのアクセスを付与する」をご覧ください。To learn how to assign roles to security principals in the scope of your storage account, see Grant access to Azure blob and queue data with RBAC in the Azure portal.

注意

ゲスト ユーザーがロールの割り当てを作成することはできません。A guest user can't create a role assignment.

ファイルおよびディレクトリ レベルのアクセス制御リストでのロール割り当ての影響The impact of role assignments on file and directory level access control lists

RBAC のロール割り当ての使用は、アクセス許可を制御する強力なメカニズムですが、ACL と比較すると、非常にきめの粗いメカニズムです。While using RBAC role assignments is a powerful mechanism to control access permissions, it is a very coarsely grained mechanism relative to ACLs. RBAC の最小粒度は、コンテナー レベルで、これは ACL よりも高い優先順位で評価されます。The smallest granularity for RBAC is at the container level and this will be evaluated at a higher priority than ACLs. したがって、セキュリティ プリンシパルにコンテナーのスコープでロールを割り当てた場合、ACL の割り当てに関係なく、そのセキュリティ プリンシパルには、そのコンテナー内の "すべて" のディレクトリとファイルに対してそのロールに関連付けられている承認レベルが適用されます。Therefore, if you assign a role to a security principal in the scope of a container, that security principal has the authorization level associated with that role for ALL directories and files in that container, regardless of ACL assignments.

組み込みロールまたはカスタム ロールを通じて、セキュリティ プリンシパルに RBAC データのアクセス許可が付与されると、要求の承認時に、これらのアクセス許可がまず評価されます。When a security principal is granted RBAC data permissions through a built-in role, or through a custom role, these permissions are evaluated first upon authorization of a request. 要求された操作がセキュリティ プリンシパルの RBAC の割り当てによって承認されている場合は、承認はすぐに解決され、追加の ACL チェックは実行されません。If the requested operation is authorized by the security principal's RBAC assignments then authorization is immediately resolved and no additional ACL checks are performed. また、セキュリティ プリンシパルに RBAC 割り当てがない場合、または要求の操作が割り当てられたアクセス許可と一致しない場合、ACL チェックが実行され、要求された操作を実行する権限がセキュリティ プリンシパルに付与されているかどうかが判断されます。Alternatively, if the security principal does not have an RBAC assignment, or the request's operation does not match the assigned permission, then ACL checks are performed to determine if the security principal is authorized to perform the requested operation.

注意

セキュリティ プリンシパルにストレージ BLOB データ所有者の組み込みロールが割り当てられている場合、そのセキュリティ プリンシパルは "スーパー ユーザー" と見なされ、すべての変更操作 (ディレクトリやファイルの所有権の設定や、自分が所有者ではないディレクトリやファイルへの ACL の設定など) へのフル アクセス権が付与されます。If the security principal has been assigned the Storage Blob Data Owner built-in role assignment, then the security principal is considered a super-user and is granted full access to all mutating operations, including setting the owner of a directory or file as well as ACLs for directories and files for which they are not the owner. スーパー ユーザーのアクセス権は、リソースの所有者を変更するために承認された唯一の方法です。Super-user access is the only authorized manner to change the owner of a resource.

共有キーと Shared Access Signature (SAS) 認証Shared Key and Shared Access Signature (SAS) authentication

Azure Data Lake Storage Gen2 では、認証に共有キーと SAS の方法がサポートされています。Azure Data Lake Storage Gen2 supports Shared Key and SAS methods for authentication. これらの認証方法の特徴は、呼び出し元に ID が関連付けられていないため、セキュリティ プリンシパルのアクセス許可ベースの承認を実行できないことです。A characteristic of these authentication methods is that no identity is associated with the caller and therefore security principal permission-based authorization cannot be performed.

共有キーの場合、呼び出し元は効果的に 'スーパー ユーザー' のアクセス権を得られます。つまり、所有者の設定や ACL の変更を含む、すべてのリソースですべての操作に対してフル アクセス権を持つことになります。In the case of Shared Key, the caller effectively gains 'super-user' access, meaning full access to all operations on all resources, including setting owner and changing ACLs.

SAS トークンには、トークンの一部として許可されるアクセス許可が含まれます。SAS tokens include allowed permissions as part of the token. SAS トークンに含まれるアクセス許可は、すべての承認の決定に効果的に適用されますが、追加の ACL チェックは行われません。The permissions included in the SAS token are effectively applied to all authorization decisions, but no additional ACL checks are performed.

ファイルとディレクトリのアクセス制御リストAccess control lists on files and directories

セキュリティ プリンシパルをファイルおよびディレクトリに対するアクセス レベルと関連付けることができます。You can associate a security principal with an access level for files and directories. これらの関連付けは、"アクセス制御リスト (ACL) " でキャプチャされます。These associations are captured in an access control list (ACL). ストレージ アカウント内の各ファイルおよびディレクトリは、アクセス制御リストを持っています。Each file and directory in your storage account has an access control list.

注意

ACL は、同じテナント内のセキュリティ プリンシパルにのみ適用されます。ACLs apply only to security principals in the same tenant.

ストレージ アカウント レベルでセキュリティ プリンシパルにロールを割り当てた場合、アクセス制御リストを使って、そのセキュリティ プリンシパルに、特定のファイルおよびディレクトリに対する昇格されたアクセス権を付与することができます。If you assigned a role to a security principal at the storage account-level, you can use access control lists to grant that security principal elevated access to specific files and directories.

アクセス制御リストを使って、ロール割り当てによって許可されるレベルより低いアクセスのレベルを提供することはできません。You can't use access control lists to provide a level of access that is lower than a level granted by a role assignment. たとえば、ストレージ BLOB データ共同作成者ロールをセキュリティ プリンシパルに割り当てた場合、アクセス制御リストを使って、そのセキュリティ プリンシパルによるディレクトリへの書き込みを禁止することはできません。For example, if you assign the Storage Blob Data Contributor role to a security principal, then you can't use access control lists to prevent that security principal from writing to a directory.

アクセス制御リストを使ってファイルおよびディレクトリ レベルのアクセス許可を設定するSet file and directory level permissions by using access control lists

ファイルおよびディレクトリ レベルのアクセス許可を設定するには、次のいずれかの記事をご覧ください。To set file and directory level permissions, see any of the following articles:

Azure ストレージ エクスプローラーAzure Storage Explorer Azure Storage Explorer を使用して Azure Data Lake Storage Gen2 のディレクトリ、ファイル、ACL を管理するUse Azure Storage Explorer to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
.NET.NET .NET を使用して Azure Data Lake Storage Gen2 のディレクトリ、ファイル、ACL を管理するUse .NET to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
JavaJava Java を使用して Azure Data Lake Storage Gen2 のディレクトリ、ファイル、ACL を管理するUse Java to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
PythonPython Python を使用して Azure Data Lake Storage Gen2 のディレクトリ、ファイル、ACL を管理するUse Python to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
PowerShellPowerShell PowerShell を使用して Azure Data Lake Storage Gen2 のディレクトリ、ファイル、ACL を管理するUse PowerShell to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
Azure CLIAzure CLI Azure CLI を使用して Azure Data Lake Storage Gen2 のディレクトリ、ファイル、ACL を管理するUse Azure CLI to manage directories, files, and ACLs in Azure Data Lake Storage Gen2
REST APIREST API Path - Update (パス - 更新)Path - Update

重要

セキュリティ プリンシパルが "サービス" プリンシパルである場合は、関連するアプリ登録のオブジェクト ID ではなく、サービス プリンシパルのオブジェクト ID を使うことが重要です。If the security principal is a service principal, it's important to use the object ID of the service principal and not the object ID of the related app registration. サービス プリンシパルのオブジェクト ID を取得するには、Azure CLI を開き、az ad sp show --id <Your App ID> --query objectId コマンドを使います。To get the object ID of the service principal open the Azure CLI, and then use this command: az ad sp show --id <Your App ID> --query objectId. <Your App ID> プレースホルダーは、アプリ登録のアプリ ID に置き換えます。make sure to replace the <Your App ID> placeholder with the App ID of your app registration.

アクセス制御リストの種類Types of access control lists

アクセス制御リストには、"アクセス ACL" と "既定の ACL" の 2 種類があります。There are two kinds of access control lists: access ACLs and default ACLs.

アクセス ACL はオブジェクトへのアクセスを制御します。Access ACLs control access to an object. ファイルとディレクトリの両方がアクセス ACL を持っています。Files and directories both have access ACLs.

既定の ACL は、ディレクトリに関連付けられた ACL のテンプレートです。この ACL によって、そのディレクトリの下に作成されるすべての子項目のアクセス ACL が決まります。Default ACLs are templates of ACLs associated with a directory that determine the access ACLs for any child items that are created under that directory. ファイルには既定の ACL がありません。Files do not have default ACLs.

アクセス ACL と既定の ACL はどちらも同じ構造です。Both access ACLs and default ACLs have the same structure.

注意

親の既定の ACL を変更しても、既存の子項目のアクセス ACL または既定の ACL には影響しません。Changing the default ACL on a parent does not affect the access ACL or default ACL of child items that already exist.

アクセス許可のレベルLevels of permission

コンテナー オブジェクトに対するアクセス許可は、読み取り書き込み実行であり、次の表に示すように、ファイルとディレクトリに対して使用できます。The permissions on a container object are Read, Write, and Execute, and they can be used on files and directories as shown in the following table:

ファイルFile ディレクトリDirectory
読み取り (R)Read (R) ファイルの内容を読み取ることができるCan read the contents of a file ディレクトリの内容を一覧表示するには、読み取り実行が必要です。Requires Read and Execute to list the contents of the directory
書き込み (W)Write (W) ファイルへの書き込みまたは追加を実行できるCan write or append to a file ディレクトリに子項目を作成するには、書き込み実行が必要です。Requires Write and Execute to create child items in a directory
実行 (X)Execute (X) Data Lake Storage Gen2 のコンテキストでは、何も意味しないDoes not mean anything in the context of Data Lake Storage Gen2 ディレクトリの子項目をスキャンするために必要です。Required to traverse the child items of a directory

注意

ACL のみを使用して (RBAC なしで) アクセス許可を付与する場合、ファイルにセキュリティ プリンシパルの読み取りまたは書き込みアクセス権を付与するには、コンテナーとそのファイルまでつながるフォルダー階層内の各フォルダーにセキュリティ プリンシパルの実行のアクセス許可を付与する必要があります。If you are granting permissions by using only ACLs (no RBAC), then to grant a security principal read or write access to a file, you'll need to give the security principal Execute permissions to the container, and to each folder in the hierarchy of folders that lead to the file.

アクセス許可の短い形式Short forms for permissions

RWX は、読み取り + 書き込み + 実行を示すために使用されます。RWX is used to indicate Read + Write + Execute. さらに縮約された数値形式もあります。読み取り = 4書き込み = 2実行 = 1 で、その合計でアクセス許可を表します。A more condensed numeric form exists in which Read=4, Write=2, and Execute=1, the sum of which represents the permissions. 次は一部の例です。Following are some examples.

数値形式Numeric form 短縮形式Short form 意味What it means
77 RWX 読み取り + 書き込み + 実行Read + Write + Execute
55 R-X 読み取り + 実行Read + Execute
44 R-- ReadRead
00 --- アクセス許可なしNo permissions

アクセス許可の継承Permissions inheritance

Data Lake Storage Gen2 で使用されている POSIX 形式のモデルでは、項目のアクセス許可は項目自体に格納されます。In the POSIX-style model that's used by Data Lake Storage Gen2, permissions for an item are stored on the item itself. つまり、子項目が既に作成された後にアクセス許可を設定すると、項目のアクセス許可を親項目から継承できません。In other words, permissions for an item cannot be inherited from the parent items if the permissions are set after the child item has already been created. 子項目が作成される前に、親項目で既定のアクセス許可が設定されている場合にのみ、アクセス許可が継承されます。Permissions are only inherited if default permissions have been set on the parent items before the child items have been created.

ストレージ アカウントに対する特定の操作の実行に必要なアクセス許可について理解できるように、一般的なシナリオを次の表に示します。The following table lists some common scenarios to help you understand which permissions are needed to perform certain operations on a storage account.

OperationOperation / Oregon/Oregon/ Portland/Portland/ Data.txtData.txt
Read Data.txtRead Data.txt --X --X --X R--
Append to Data.txtAppend to Data.txt --X --X --X RW-
Delete Data.txtDelete Data.txt --X --X -WX ---
Create Data.txtCreate Data.txt --X --X -WX ---
List /List / R-X --- --- ---
List /Oregon/List /Oregon/ --X R-X --- ---
List /Oregon/Portland/List /Oregon/Portland/ --X --X R-X ---

注意

上の 2 つの条件が満たされていれば、ファイルを削除するために、ファイルに対する書き込みアクセス許可は必要ありません。Write permissions on the file are not required to delete it, so long as the previous two conditions are true.

ユーザーと IDUsers and identities

すべてのファイルとディレクトリは、以下の ID の個別のアクセス許可を持っています。Every file and directory has distinct permissions for these identities:

  • 所有ユーザーThe owning user
  • 所有グループThe owning group
  • 名前付きユーザーNamed users
  • 名前付きグループNamed groups
  • 名前付きサービス プリンシパルNamed service principals
  • 名前付きマネージド IDNamed managed identities
  • その他のすべてのユーザーAll other users

ユーザーとグループの ID は、Azure Active Directory (Azure AD) の ID です。The identities of users and groups are Azure Active Directory (Azure AD) identities. そのため、注記がない限り、Data Lake Store Gen2 のコンテキストでの "ユーザー" は、Azure AD ユーザー、サービス プリンシパル、マネージド ID、またはセキュリティ グループを意味します。So unless otherwise noted, a user, in the context of Data Lake Storage Gen2, can refer to an Azure AD user, service principal, managed identity, or security group.

所有ユーザーThe owning user

項目を作成したユーザーは、自動的に項目の所有ユーザーになります。The user who created the item is automatically the owning user of the item. 所有ユーザーは、次のことができます。An owning user can:

  • 所有しているファイルのアクセス許可を変更します。Change the permissions of a file that is owned.
  • 所有しているファイルの所有グループを変更します。ただし、所有ユーザーが変更後のグループのメンバーでもある必要があります。Change the owning group of a file that is owned, as long as the owning user is also a member of the target group.

注意

所有ユーザーが、ファイルやディレクトリの所有ユーザーを変更することはできませんThe owning user cannot change the owning user of a file or directory. ファイルまたはディレクトリの所有ユーザーを変更できるのは、スーパー ユーザーだけです。Only super-users can change the owning user of a file or directory.

所有グループThe owning group

POSIX ACL では、すべてのユーザーがプライマリ グループに関連付けられています。In the POSIX ACLs, every user is associated with a primary group. たとえば、ユーザー "Alice" が "finance" グループに属しているとします。For example, user "Alice" might belong to the "finance" group. Alice は複数のグループに属している可能性がありますが、1 つのグループが常にプライマリ グループとして指定されています。Alice might also belong to multiple groups, but one group is always designated as their primary group. POSIX では、Alice がファイルを作成すると、そのファイルの所有グループが彼女のプライマリ グループに設定されます。ここでは、"finance" グループです。In POSIX, when Alice creates a file, the owning group of that file is set to her primary group, which in this case is "finance." その他の点では、所有グループの動作は、他のユーザー/グループに割り当てられているアクセス許可と同様です。The owning group otherwise behaves similarly to assigned permissions for other users/groups.

新しいファイルまたはディレクトリに対する所有グループの割り当てAssigning the owning group for a new file or directory
  • ケース 1:ルート ディレクトリ "/"。Case 1: The root directory "/". このディレクトリは、Data Lake Storage Gen2 コンテナーの作成時に作成されます。This directory is created when a Data Lake Storage Gen2 container is created. この場合、OAuth を使用してコンテナーが作成された場合は、所有グループはそれを作成したユーザーに設定されます。In this case, the owning group is set to the user who created the container if it was done using OAuth. 共有キー、アカウント SAS、またはサービス SAS を使用してコンテナーを作成した場合は、所有者と所有グループは $superuser に設定されます。If the container is created using Shared Key, an Account SAS, or a Service SAS, then the owner and owning group are set to $superuser.
  • ケース 2 (その他すべての場合):新しい項目が作成されると、所有グループが親ディレクトリからコピーされます。Case 2 (Every other case): When a new item is created, the owning group is copied from the parent directory.
所有グループの変更Changing the owning group

所有グループを変更できるユーザーは次のとおりです。The owning group can be changed by:

  • すべてのスーパー ユーザーAny super-users.
  • 所有ユーザー (所有ユーザーが変更後のグループのメンバーでもある場合)The owning user, if the owning user is also a member of the target group.

注意

所有グループが、ファイルやディレクトリの ACL を変更することはできません。The owning group cannot change the ACLs of a file or directory. ルート ディレクトリの場合 (上記のケース 1)、所有グループはアカウントを作成したユーザーに設定されますが、所有グループを介したアクセス許可の付与に関して、単一ユーザー アカウントは有効ではありません。While the owning group is set to the user who created the account in the case of the root directory, Case 1 above, a single user account isn't valid for providing permissions via the owning group. この権限は、有効なユーザー グループに対して、該当する場合に割り当てることができます。You can assign this permission to a valid user group if applicable.

アクセス確認アルゴリズムAccess check algorithm

次の擬似コードは、ストレージ アカウントのアクセス確認アルゴリズムを示しています。The following pseudocode represents the access check algorithm for storage accounts.

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 )
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)

マスクThe mask

アクセス確認アルゴリズムに示されているように、マスクによって、名前付きユーザー、所有グループ、および名前付きグループのアクセスが制限されます。As illustrated in the Access Check Algorithm, the mask limits access for named users, the owning group, and named groups.

注意

新しい Data Lake Storage Gen2 コンテナーでは、ルート ディレクトリ ("/") のアクセス ACL のマスクは、ディレクトリの場合は 750、ファイルの場合は 640 に既定で設定されています。For a new Data Lake Storage Gen2 container, the mask for the access ACL of the root directory ("/") defaults to 750 for directories and 640 for files. ファイルは格納専用のシステム内のファイルとは無関係であるため、X ビットを受け取りません。Files do not receive the X bit as it is irrelevant to files in a store-only system.

マスクは、呼び出しごとに指定できます。The mask may be specified on a per-call basis. これにより、クラスターなどのさまざまな使用システムが、ファイル操作に対して異なる有効なマスクを持つことができます。This allows different consuming systems, such as clusters, to have different effective masks for their file operations. 特定の要求でマスクが指定されると、既定のマスクが完全にオーバーライドされます。If a mask is specified on a given request, it completely overrides the default mask.

スティッキー ビットThe sticky bit

スティッキー ビットは、POSIX コンテナーのより高度な機能です。The sticky bit is a more advanced feature of a POSIX container. Data Lake Storage Gen2 のコンテキストでは、スティッキー ビットが必要になることはあまりありません。In the context of Data Lake Storage Gen2, it is unlikely that the sticky bit will be needed. つまり、ディレクトリでスティッキー ビットが有効になっている場合、子項目を削除または名前変更できるのは、子項目を所有しているユーザーのみです。In summary, if the sticky bit is enabled on a directory, a child item can only be deleted or renamed by the child item's owning user.

スティッキー ビットは、Azure portal には表示されません。The sticky bit isn't shown in the Azure portal.

新しいファイルとディレクトリの既定のアクセス許可Default permissions on new files and directories

既存のディレクトリの下に新しいファイルまたはディレクトリが作成されると、親ディレクトリの既定の ACL によって、次のものが決定します。When a new file or directory is created under an existing directory, the default ACL on the parent directory determines:

  • 子ディレクトリの既定の ACL とアクセス ACL。A child directory's default ACL and access ACL.
  • 子ファイルのアクセス ACL (ファイルには既定の ACL がありません)。A child file's access ACL (files do not have a default ACL).

umaskumask

ファイルまたはディレクトリを作成するときに、umask を使用して、子項目に既定の ACL がどのように設定されるかを変更します。When creating a file or directory, umask is used to modify how the default ACLs are set on the child item. umask は親ディレクトリに設定される 9 ビットの値であり、所有ユーザー所有グループ、およびその他に対する RWX 値が含まれています。umask is a 9-bit value on parent directories that contains an RWX value for owning user, owning group, and other.

Azure Data Lake Storage Gen2 に対する umask は、007 に設定される定数値です。The umask for Azure Data Lake Storage Gen2 a constant value that is set to 007. この値の変換値:This value translates to:

umask コンポーネントumask component 数値形式Numeric form 短縮形式Short form 意味Meaning
umask.owning_userumask.owning_user 00 --- 所有ユーザーの場合、親の既定の ACL を子のアクセス ACL にコピーしますFor owning user, copy the parent's default ACL to the child's access ACL
umask.owning_groupumask.owning_group 00 --- 所有グループの場合、親の既定の ACL を子のアクセス ACL にコピーしますFor owning group, copy the parent's default ACL to the child's access ACL
umask.otherumask.other 77 RWX その他の場合、子のアクセス ACL 上のすべてのアクセス許可を削除しますFor other, remove all permissions on the child's access ACL

Azure Data Lake Storage Gen2 で umask の値が使用されると、実際上は、既定の ACL が何を示しているかに関係なく、既定では、その他に対する値は、新しい子では決して送信されないことを意味します。The umask value used by Azure Data Lake Storage Gen2 effectively means that the value for other is never transmitted by default on new children, regardless of what the default ACL indicates.

次の疑似コードは、子項目に ACL を作成するときに、unmask がどのように適用されるかを示しています。The following pseudocode shows how the umask is applied when creating the ACLs for a child item.

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 Gen2 の ACL に関する一般的な質問Common questions about ACLs in Data Lake Storage Gen2

ACL のサポートを有効にする必要はありますかDo I have to enable support for ACLs?

いいえ。No. 階層型名前空間 (HNS) 機能がオンになっている限り、ストレージ アカウントの ACL によるアクセス制御は有効です。Access control via ACLs is enabled for a storage account as long as the Hierarchical Namespace (HNS) feature is turned ON.

HNS がオフになっている場合、Azure RBAC の承認規則が引き続き適用されます。If HNS is turned OFF, the Azure RBAC authorization rules still apply.

ACL を適用する最善の方法What is the best way to apply ACLs?

ACL で割り当て済みのプリンシパルとして常に Azure AD セキュリティ グループを使用します。Always use Azure AD security groups as the assigned principal in ACLs. 個々のユーザーまたはサービス プリンシパルを直接割り当てることを抑止します。Resist the opportunity to directly assign individual users or service principals. この構造体を使用すると、ユーザーまたはサービス プリンシパルを追加したり削除したりすることができます。ACL をディレクトリ構造全体に再適用する必要はありません。Using this structure will allow you to add and remove users or service principals without the need to reapply ACLs to an entire directory structure. 代わりに、適切な Azure AD セキュリティ グループからユーザーまたはサービス プリンシパルを追加または削除するだけです。Instead, you simply need to add or remove them from the appropriate Azure AD security group. ACL は継承されないため、ACL の再適用には、すべてのファイルとサブディレクトリで ACL を更新する必要があることに注意してください。Keep in mind that ACLs are not inherited and so reapplying ACLs requires updating the ACL on every file and subdirectory.

ディレクトリとその内容を再帰的に削除するのに必要なアクセス許可を教えてくださいWhich permissions are required to recursively delete a directory and its contents?

  • 呼び出し元に 'スーパー ユーザー' アクセス許可があるThe caller has 'super-user' permissions,

またはOr

  • 親ディレクトリには、書き込み + 実行アクセス許可が必要The parent directory must have Write + Execute permissions.
  • 削除対象のディレクトリとその中のすべてのディレクトリには、読み取り + 書き込み + 実行アクセス許可が必要The directory to be deleted, and every directory within it, requires Read + Write + Execute permissions.

注意

ディレクトリ内のファイルを削除するには、書き込みアクセス許可は必要ありません。You do not need Write permissions to delete files in directories. また、ルート ディレクトリ "/" を削除することはできません。Also, the root directory "/" can never be deleted.

ファイルまたはディレクトリの所有者として設定されるのはだれですかWho is the owner of a file or directory?

ファイルまたはディレクトリの作成者が所有者になります。The creator of a file or directory becomes the owner. ルート ディレクトリの場合、これはコンテナーを作成したユーザーの ID です。In the case of the root directory, this is the identity of the user who created the container.

ファイルまたはディレクトリの作成時に、所有グループとして設定されるのはどのグループですかWhich group is set as the owning group of a file or directory at creation?

所有グループは、新しいファイルまたはディレクトリが作成される親ディレクトリの所有グループからコピーされます。The owning group is copied from the owning group of the parent directory under which the new file or directory is created.

ファイルの所有ユーザーですが、必要な RWX アクセス許可を持っていません。I am the owning user of a file but I don't have the RWX permissions I need. どうすればよいですか。What do I do?

所有ユーザーは、ファイルのアクセス許可を変更して、必要な任意の RWX アクセス許可を自分に与えることができます。The owning user can change the permissions of the file to give themselves any RWX permissions they need.

ACL に GUID が表示されることがあるのはなぜですかWhy do I sometimes see GUIDs in ACLs?

エントリがユーザーを表し、そのユーザーがもう Azure AD に存在しなくなった場合に、GUID が表示されます。A GUID is shown if the entry represents a user and that user doesn't exist in Azure AD anymore. 通常、ユーザーが会社を辞めた場合や Azure AD でそのアカウントが削除された場合に、この現象が発生します。Usually this happens when the user has left the company or if their account has been deleted in Azure AD. さらに、サービス プリンシパルおよびセキュリティ グループには、それらを識別するためのユーザー プリンシパル名 (UPN) がないため、これらは自身の OID 属性 (guid) で表されます。Additionally, service principals and security groups do not have a User Principal Name (UPN) to identify them and so they are represented by their OID attribute (a guid).

サービス プリンシパル用 ACL を正しく設定するにはどうすればよいですか。How do I set ACLs correctly for a service principal?

サービス プリンシパル用 ACL を定義するときは、作成したアプリ登録に対応する "サービス プリンシパル" のオブジェクト ID (OID) を使用することが重要です。When you define ACLs for service principals, it's important to use the Object ID (OID) of the service principal for the app registration that you created. 登録済みアプリについては、特定の Azure AD テナントに個別のサービス プリンシパルがあることに注意してください。It's important to note that registered apps have a separate service principal in the specific Azure AD tenant. 登録済みアプリの OID は Azure portal に表示されていますが、その "サービス プリンシパル" には別の (異なる) OID があります。Registered apps have an OID that's visible in the Azure portal, but the service principal has another (different) OID.

アプリ登録に対応するサービス プリンシパルの OID を取得するには、az ad sp show コマンドを使用し、To get the OID for the service principal that corresponds to an app registration, you can use the az ad sp show command. パラメーターとしてアプリケーション ID を指定します。Specify the Application ID as the parameter. アプリ ID が 18218b12-1895-43e9-ad80-6e8fc1ea88ce のアプリ登録に対応するサービス プリンシパルの OID を取得する例を次に示します。Here's an example on obtaining the OID for the service principal that corresponds to an app registration with App ID = 18218b12-1895-43e9-ad80-6e8fc1ea88ce. Azure CLI で、次のコマンドを実行します。Run the following command in the Azure CLI:

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

OID が表示されます。OID will be displayed.

サービス プリンシパルの正しい OID を取得したら、Storage Explorer で [アクセスの管理] ページに移動して OID を追加し、その OID に対する適切なアクセス許可を割り当てます。When you have the correct OID for the service principal, go to the Storage Explorer Manage Access page to add the OID and assign appropriate permissions for the OID. その後、必ず [保存] を選択してください。Make sure you select Save.

Data Lake Storage Gen2 は ACL の継承をサポートしていますか。Does Data Lake Storage Gen2 support inheritance of ACLs?

Azure RBAC の割り当ては継承されます。Azure RBAC assignments do inherit. 割り当ては、サブスクリプション、リソース グループ、ストレージ アカウント リソースからコンテナー リソースに渡されます。Assignments flow from subscription, resource group, and storage account resources down to the container resource.

ACL は継承されません。ACLs do not inherit. ただし、親ディレクトリの下に作成される子サブディレクトリやファイルについては、既定の ACL を使用して ACL を設定できます。However, default ACLs can be used to set ACLs for child subdirectories and files created under the parent directory.

POSIX アクセス制御モデルの詳細はどこで確認できますかWhere can I learn more about POSIX access control model?

関連項目See also