SMB でディレクトリとファイルレベルのアクセス許可を構成する

[アーティクル]
01/11/2024

この記事を読み始める前に、「ID に共有レベルのアクセス許可を割り当てる」を読み、Azure のロールベースのアクセス制御 (RBAC) を使って共有レベルのアクセス許可を設定しておいてください。

共有レベルのアクセス許可を割り当てたら、ルート、ディレクトリ、またはファイルレベルで Windows アクセス制御リスト (ACL) (NTFS アクセス許可とも呼ぶ) を構成できます。共有レベルのアクセス許可は、ユーザーが共有にアクセスできるかどうかを決定する高度なゲートキーパーですが、Windows ACL はユーザーがディレクトリまたはファイルレベルでどのような操作を実行できるかを制御するために、より詳細なレベルで動作すると考えることができます。

ユーザーがファイルやディレクトリにアクセスしようとすると、共有レベルおよびファイルとディレクトリレベルの両方のアクセス許可が適用されるので、両方に違いがある場合は、最も制限の厳しい方だけが適用されます。たとえば、ユーザーがファイルレベルで読み取り/書き込みアクセス権を持っているが、共有レベルでは読み取りアクセス権しかない場合は、そのファイルは読み取ることしかできません。同じことはこの逆にも当てはまります。ユーザーが共有レベルで読み取り/書き込みアクセス権を持っていても、ファイルレベルでは読み取りアクセス権しか持っていない場合は、やはりファイルを読み取ることしかできません。

重要

Windows ACL を構成するには、ドメインコントローラーへのスムーズなネットワーク接続を持つ Windows を実行しているクライアントマシンが必要です。 Active Directory Domain Services (AD DS) またはハイブリッド ID 用の Microsoft Entra Kerberos を使用して Azure Files で認証する場合、これにはオンプレミス AD へのスムーズなネットワーク接続が必要になります。 Microsoft Entra Domain Services を使用する場合、クライアントマシンには、Microsoft Entra Domain Services によって管理され、Azure に配置されているドメインコントローラーへのスムーズなネットワーク接続が必要です。

適用対象

ファイル共有の種類	SMB	NFS
Standard ファイル共有 (GPv2)、LRS/ZRS
Standard ファイル共有 (GPv2)、GRS/GZRS
Premium ファイル共有 (FileStorage)、LRS/ZRS

Azure RBAC アクセス許可

次の表は、この構成に関連する Azure RBAC アクセス許可を示しています。 Azure Storage Explorer を使用している場合は、ファイル共有を読み取ったりアクセスしたりするために、閲覧者とデータアクセスロールも必要です。

共有レベルのアクセス許可 (組み込みロール)	NTFS アクセス許可	結果のアクセス
記憶域ファイルデータの SMB 共有の閲覧者	フルコントロール、変更、読み取り、書き込み、実行	読み取りと実行
	Read	Read
記憶域ファイルデータの SMB 共有の共同作成者	フルコントロール	変更、読み取り、書き込み、実行
	変更	Modify
	読み取りと実行	読み取りと実行
	Read	Read
	Write	Write
記憶域ファイルデータの SMB 共有の管理者特権共同作成者	フルコントロール	変更、読み取り、書き込み、編集 (変更アクセス許可)、実行
	変更	Modify
	読み取りと実行	読み取りと実行
	Read	Read
	Write	Write

サポートされている Windows ACL

Azure Files では、基本的な Windows ACL と詳細な Windows ACL で構成される完全なセットをサポートします。

ユーザー	定義
`BUILTIN\Administrators`	ファイルサーバーの管理者を表す組み込みのセキュリティグループ。このグループは空で、誰も追加できません。
`BUILTIN\Users`	ファイルサーバーのユーザーを表す組み込みのセキュリティグループ。既定で `NT AUTHORITY\Authenticated Users` が含まれています。従来のファイルサーバーの場合は、サーバーごとにメンバーシップの定義を構成できます。 Azure Files の場合は、ホスティングサーバーが存在しないため、`BUILTIN\Users` には `NT AUTHORITY\Authenticated Users` と同じユーザーのセットが含まれます。
`NT AUTHORITY\SYSTEM`	ファイルサーバーのオペレーティングシステムのサービスアカウント。このようなサービスアカウントは、Azure Files コンテキストでは適用されません。これは、ハイブリッドシナリオでの Windows Files サーバーエクスペリエンスと一貫性を持たせるために、ルートディレクトリに含まれています。
`NT AUTHORITY\Authenticated Users`	有効な Kerberos トークンを取得できる AD 内のすべてのユーザー。
`CREATOR OWNER`	ディレクトリまたはファイルのオブジェクトにはそれぞれ、そのオブジェクトの所有者が含まれています。そのオブジェクト上で `CREATOR OWNER` に ACL が割り当てられている場合、このオブジェクトの所有者であるユーザーは、ACL によって定義されたオブジェクトに対するアクセス許可を持っています。

ファイル共有のルートディレクトリには、次のアクセス許可が含まれています。

BUILTIN\Administrators:(OI)(CI)(F)
BUILTIN\Users:(RX)
BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
NT AUTHORITY\Authenticated Users:(OI)(CI)(M)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(F)
CREATOR OWNER:(OI)(CI)(IO)(F)

これらの高度なアクセス許可について詳しくは、icacls のコマンドラインリファレンスに関する記事をご覧ください。

しくみ

Windows ACL の構成と編集には、次の 2 つの方法があります。

毎回ユーザー名とストレージアカウントキーを使用するログイン: ACL を構成したい場合はいつでも、ドメインコントローラーへのスムーズなネットワーク接続を持つマシン上のストレージアカウントキーを使用してファイル共有をマウントします。
1 回限りのユーザー名、ストレージアカウントキーの設定:

Note

新しいファイル/ディレクトリは、構成されたルートアクセス許可を継承するため、このセットアップは、新しく作成されたファイル共有に対して機能します。既存の ACL と共に移行されたファイル共有の場合、または新しいファイル共有で既存のアクセス許可を持つオンプレミスのファイル/ディレクトリを移行する場合、移行されたファイルでは構成済みのルート ACL を継承しないため、この方法が機能しない可能性があります。

ドメインコントローラーへのスムーズなネットワーク接続を持つマシン上のユーザー名とストレージアカウントキーを使用してログインし、ファイル共有のルートに対するアクセス許可を編集するアクセス許可を一部のユーザー (またはグループ) に付与します。
これらのユーザーに、ストレージファイルデータ SMB 共有管理者特権共同作成者 Azure RBAC ロールを割り当てます。
今後、ACL を更新したい場合は、これらの許可されているユーザーの 1 人を使用して、ドメインコントローラーへのスムーズなネットワーク接続を持つマシンからログインして ACL を編集できます。

Windows ACL を構成する前にまず、ストレージアカウントキーを使ってファイル共有をマウントする必要があります。これを行うには、ドメイン参加済みのデバイスにログインし、Windows コマンドプロンプトを開いて、次のコマンドを実行します。忘れずに、<YourStorageAccountName>、<FileShareName>、<YourStorageAccountKey> を独自の値に置き換えてください。 Z: が既に使用されている場合は、使用可能なドライブ文字に置き換えます。ストレージアカウントキーを確認するには、Azure portal でストレージアカウントに移動し、[セキュリティとネットワーク]>[アクセスキー] を選びます。または、Get-AzStorageAccountKey PowerShell コマンドレットを使うこともできます。

このステージで共有をマウントするには、PowerShell ではなく、Windows コマンド net use を使うことが重要です。 PowerShell を使って共有をマウントすると、共有は Windows のエクスプローラーまたは cmd.exe に表示されないため、Windows ACL の構成が難しくなります。

注意

ロールには、フルコントロールの ACL が既に適用されている可能性があります。これにより、通常、アクセス許可を割り当てる機能が既に提供されています。しかし、2 つのレベル (共有レベルとファイルまたはディレクトリレベル) でアクセスチェックが行われるため、これは制限されます。 SMB の管理者特権の共同作成者ロールを持ち、新しいファイルまたはディレクトリを作成するユーザーのみが、ストレージアカウントキーを使用せずに、これらの新しいファイルまたはディレクトリに対するアクセス許可を割り当てることができます。その他のファイルまたはディレクトリのアクセス許可の割り当てはすべて、最初にストレージアカウントキーを使用して共有に接続する必要があります。

net use Z: \\<YourStorageAccountName>.file.core.windows.net\<FileShareName> /user:localhost\<YourStorageAccountName> <YourStorageAccountKey>

Windows ACL を構成する

Windows ACL を構成するには、icacls または Windows エクスプローラーのどちらかを使用する必要があります。 Set-ACL PowerShell コマンドを使うこともできます。

重要

環境内に複数の AD DS フォレストがある場合は、Windows エクスプローラーを使用して ACL を構成しないでください。代わりに icacls を使用してください。

オンプレミスのファイルサーバーに、AD DS の ID に対して Windows ACL が構成されたディレクトリまたはファイルがある場合は、Robocopy や Azure AzCopy v 10.4 以降などの従来のファイルコピーツールを使って、ACL が保持されている Azure Files にそれらをコピーできます。 Azure File Sync によってディレクトリとファイルが Azure Files に階層化されている場合は、ACL が引き継がれ、ネイティブ形式で保持されます。

設定したアクセス許可を有効にするために、忘れずに ID を同期してください。同期されていない ID に ACL を設定できますが、同期されていない ID は認証と認可に使われる Kerberos チケットには存在しないため、これらの ACL は適用されません。

icacls で Windows ACL を構成する

ルートディレクトリを含め、ファイル共有内のすべてのディレクトリとファイルに完全なアクセス許可を付与するには、AD ドメインコントローラーへの通信経路を持つコンピューターから次の Windows コマンドを実行します。例中のプレースホルダーをお客様独自の値に置き換えてください。

icacls <mapped-drive-letter>: /grant <user-upn>:(f)

icacls を使用して Windows ACL を設定する方法や、サポートされるさまざまな種類のアクセス許可の詳細については、コマンドラインリファレンスの icacls に関するページをご覧ください。

Windows エクスプローラーを使用して Windows ACL を構成する

ドメインに参加している Windows クライアントにログオンしている場合は、Windows エクスプローラーを使用して、ルートディレクトリを含む、ファイル共有内のすべてのディレクトリとファイルに完全なアクセス許可を付与できます。クライアントがドメインに参加していない場合は、Windows ACL の構成に icacls を使用します。

Windows エクスプローラーを開き、ファイルまたはディレクトリを右クリックし、 [プロパティ] を選択します。
[セキュリティ] タブをクリックします。
[編集...] を選んでアクセス許可を変更します。
既存のユーザーの権限を変更することや、 [追加] を選択して新しいユーザーにアクセス許可を付与することができます。
新しいユーザーを追加するためのプロンプトウィンドウで、アクセス許可を付与するターゲットユーザーの名前を [選択するオブジェクト名を入力してください] ボックスに入力し、 [名前の確認] を選択して、ターゲットユーザーの完全な UPN 名を見つけます。
[OK] を選択します。
[セキュリティ] タブで、新しいユーザーに付与するすべてのアクセス許可を選択します。
[適用] を選択します。

次のステップ

AD DS で ID ベースの認証を有効にして構成したので、ファイル共有をマウントできます。

SMB でディレクトリとファイル レベルのアクセス許可を構成する