Azure NetApp Files のデュアルプロトコル セキュリティ スタイルとアクセス許可の動作について
SMB と NFS では、ユーザーとグループのアクセスに異なるアクセス許可モデルが使用されます。 その結果、プロトコル アクセスに必要なアクセス許可モデルを受け入れるように Azure NetApp File ボリュームを構成する必要があります。 NFS のみの環境の場合、決定は簡単です。UNIX のセキュリティ スタイルを使用します。 SMB のみの環境では、NTFS セキュリティ スタイルを使用します。
同じデータセットで NFS と SMB (デュアルプロトコル) が必要な場合は、次の 2 つの質問に基づいて決定する必要があります。
- ユーザーが最も多くアクセス許可を管理するプロトコルは何ですか?
- 必要なアクセス許可の管理エンドポイントは何ですか? 言い換えると、ユーザーは NFS クライアントまたは Windows クライアントからアクセス許可を管理する機能を必要としますか? それとも、両方のアプリケーションにアクセスしますか。
ACL 管理の必要なスタイルが決定要因である場合、ボリューム セキュリティ スタイルは実際にはアクセス許可スタイルと見なすことができます。
Note
セキュリティ スタイルは、ボリュームの作成時に選択されます。 セキュリティ スタイルを選択した後で変更することはできません。
Azure NetApp Files のボリューム セキュリティ スタイルについて
Azure NetApp Files のボリューム セキュリティ スタイルには、主に次の 2 つの選択肢があります。
UNIX - UNIX セキュリティ スタイルでは、基本的な POSIX モード ビット (0755 など、標準の読み取り/書き込み/実行アクセス許可を持つ所有者/グループ/全員のアクセス権) や NFSv4.x ACL などの UNIX スタイルのアクセス許可が提供されます。 POSIX ACL はサポートされていません。
NTFS - NTFS セキュリティ スタイルでは、標準の Windows NTFS アクセス許可と同じ機能が提供され、ACL 内の詳細なユーザーとグループおよび詳細なセキュリティ/監査アクセス許可が示されます。
デュアルプロトコル NAS 環境では、アクティブにできるセキュリティ アクセス許可スタイルは 1 つだけです。 セキュリティ スタイルを選ぶ前に、それぞれの考慮事項を評価する必要があります。
| セキュリティ スタイル | 考慮事項 |
|---|---|
| UNIX | - Windows クライアントは、UNIX 属性にマップされる SMB を介してのみ UNIX アクセス許可属性を設定できます (読み取り/書き込み/実行のみ、特別なアクセス許可はありません)。 - NFSv4.x ACL には GUI 管理がありません。 管理は、nfs4_getfacl と nfs4_setfacl コマンドを使用して CLI 経由でのみ行われます。 - ファイルまたはフォルダーに NFSv4.x ACL がある場合、Windows の [セキュリティ] プロパティ タブでは表示できません。 |
| NTFS | - UNIX クライアントでは、chown/chmod などのコマンドを使用して NFS を介して属性を設定することはできません。 - NFS クライアントでは、 ls コマンドを使用する場合、近似の NTFS アクセス許可のみが表示されます。 たとえば、ユーザーが Windows NTFS ACL のアクセス許可を持っていて、POSIX モード ビット (走査ディレクトリなど) にクリーンに変換できない場合、最も近い POSIX モード ビット値 (実行用の 1 など) に変換されます。 |
ボリューム セキュリティ スタイルの選択によって、ユーザーの名前マッピングの実行方法が決まります。 この操作は、使用中のプロトコルに関係なく、デュアルプロトコル ボリュームで予測可能なアクセス許可が維持される方法の中核となる部分です。
適切なボリューム セキュリティ スタイルを選択するための決定マトリックスとして、次の表を使用します。
| セキュリティ スタイル | 主に NFS | 主に SMB | 詳細なセキュリティの必要性 |
|---|---|---|---|
| UNIX | x | - | X (NFSv4.x ACL を使用) |
| NTFS | - | x | x |
Azure NetApp Files での名前マッピングのしくみ
Azure NetApp Files では、ユーザーのみが認証され、マップされます。 グループはマップされません。 代わりに、グループ メンバーシップはユーザー ID を使用して決定されます。
ユーザーが Azure NetApp Files ボリュームにアクセスしようとすると、その試行で ID がサービスに伝えられます。 この ID には、ユーザー名と一意の数値識別子 (NFSv3 の場合は UID 番号、NFSv4.1 の場合は名前文字列、SMB の場合は SID) が含まれます。 Azure NetApp Files ではその ID を使用して、構成されたネーム サービスに対する認証が行われ、ユーザーの身元が確認されます。
- 数値 ID の LDAP 検索は、Active Directory でユーザー名を検索するために使用されます。
- 名前文字列では LDAP 検索を使用してユーザー名が検索され、クライアントとサーバーによって、NFSv4.1 用に構成された ID ドメインが参照され、一致することが確かめられます。
- Windows ユーザーは、Active Directory に対する標準の Windows RPC 呼び出しを使用して照会されます。
- グループ メンバーシップも照会され、すべてが資格情報キャッシュに追加され、ボリュームに対する後続の要求の処理が高速化されます。
- 現時点では、カスタム ローカル ユーザーを Azure NetApp Files で使用することはできません。 デュアル プロトコルで使用できるのは、Active Directory 内のユーザーだけです。
- 現時点では、デュアルプロトコル ボリュームで使用できるローカル ユーザーは root と
nfsnobodyユーザーだけです。
Azure NetApp Files によってユーザー名が認証および検証された後、デュアルプロトコル ボリューム認証の次の手順は、UNIX と Windows の相互運用性のためのユーザー名のマッピングです。
ボリュームのセキュリティ スタイルによって、Azure NetApp Files での名前マッピングの実行方法が決まります。 Windows と UNIX のアクセス許可セマンティクスは異なります。 名前マッピングを実行できない場合、認証は失敗し、クライアントからのボリュームへのアクセスは拒否されます。 この状況が発生する一般的なシナリオは、NTFS セキュリティ スタイルのボリュームに対して NFSv3 アクセスが試行される場合です。 NFSv3 からの初期アクセス要求は、数値 UID として Azure NetApp Files に送信されます。 1001 の数値 ID を持つ user1 という名前のユーザーが NFSv3 マウントにアクセスしようとすると、認証要求は数値 ID 1001 として到着します。 その後、Azure NetApp Files は数値 ID 1001 を受け取り、1001 をユーザー名に解決しようとします。 ボリュームの NTFS アクセス許可には、数値 ID ではなく Windows ユーザー名が含まれるため、有効な Windows ユーザーへのマッピングには、このユーザー名が必要です。 Azure NetApp Files では、構成されたネーム サービス サーバー (LDAP) を使用してユーザー名が検索されます。 ユーザー名が見つからない場合、認証は失敗し、アクセスは拒否されます。 この操作は、ファイルやフォルダーへの不要なアクセスを防ぐための設計によるものです。
セキュリティ スタイルに基づく名前マッピング
名前マッピングが Azure NetApp Files で行われる方向 (Windows から UNIX、または UNIX から Windows) は、使用されているプロトコルだけでなく、ボリュームのセキュリティ スタイルによっても決まります。 Windows クライアントでは、アクセスを許可するために Windows から UNIX への名前マッピングが常に必要ですが、一致する UNIX ユーザー名は必ずしも必要ありません。 構成されたネーム サービス サーバーに有効な UNIX ユーザー名が存在しない場合、Azure NetApp Files によって、SMB 接続の初期認証を許可する 65534 の数値 UID を持つフォールバックの既定の UNIX ユーザーが提供されます。 その後、ファイルとフォルダーのアクセス許可によってアクセスが制御されます。 65534 は通常、nfsnobody ユーザーに対応するため、ほとんどの場合、アクセスは制限されます。 逆に、NFS クライアントでは、NTFS セキュリティ スタイルが使用されている場合にのみ、UNIX から Windows への名前マッピングを使用する必要があります。 Azure NetApp Files には既定の Windows ユーザーが存在しません。 そのため、要求した名前と一致する有効な Windows ユーザーが見つからない場合、アクセスは拒否されます。
次の表では、さまざまな名前マッピングの順列と、使用中のプロトコルに応じた動作について詳しく説明します。
| プロトコル | セキュリティ スタイル | 名前マッピングの方向 | 適用されるアクセス許可 |
|---|---|---|---|
| SMB | UNIX | Windows から UNIX | UNIX (モード ビットまたは NFSv4.x ACL) |
| SMB | NTFS | Windows から UNIX | NTFS ACL (Windows SID アクセス共有に基づく) |
| NFSv3 | UNIX | なし | UNIX (モード ビットまたは NFSv4.x ACL*) |
| NFSv4.x | UNIX | UNIX ユーザー名に対する数値 ID | UNIX (モード ビットまたは NFSv4.x ACL) |
| NFS3/4.x | NTFS | UNIX から Windows | NTFS ACL (マップされた Windows ユーザー SID に基づく) |
Note
Azure NetApp Files の名前マッピング規則は、現在、LDAP を使用してのみ制御できます。 サービス内で明示的な名前マッピング規則を作成するオプションはありません。
ネーム サービスとデュアルプロトコル ボリューム
使用されている NAS プロトコルに関係なく、デュアルプロトコル ボリュームでは、名前マッピングの概念を使用してアクセス許可が適切に処理されます。 そのため、ネーム サービスは、ボリュームへのアクセスに SMB と NFS の両方を使用する環境で機能を維持する上で重要な役割を果たします。
ネーム サービスは、NAS ボリュームにアクセスするユーザーとグループの ID ソースとして機能します。 この操作には Active Directory が含まれます。これは、標準ドメイン サービスと LDAP 機能の両方を使用して、Windows と UNIX の両方のユーザーとグループのソースとして機能できます。
ネーム サービスは厳格な要件ではありませんが、Azure NetApp Files デュアルプロトコル ボリュームには強くお勧めします。 サービス内にカスタム ローカル ユーザーとグループを作成する概念はありません。 そのため、プロトコル間で適切な認証と正確なユーザーとグループの所有者情報を持つには、LDAP が必要です。 ユーザーの数がわずかで、正確なユーザーとグループ ID の情報を入力する必要がない場合は、LDAP を使用するローカル NFS ユーザーにデュアルプロトコル ボリュームへのアクセスを許可する機能を使用することを検討してください。 この機能を有効にすると、拡張グループ機能が無効になることに注意してください。
クライアント、ネーム サービス、ストレージが異なる領域に存在する場合
場合によっては、NAS クライアントは、ストレージおよびネーム サービスへの接続が分離された複数のインターフェイスを備えたセグメント化されたネットワークに存在する可能性があります。
このような例の 1 つは、ストレージが Azure NetApp Files に存在し、NAS クライアントとドメイン サービスがすべてオンプレミスにある (Azure のハブとスポークのアーキテクチャなど) 場合です。 このようなシナリオでは、NAS クライアントとネーム サービスの両方にネットワーク アクセスを提供する必要があります。
次の図は、その種類の構成の例を示しています。
