SMB と NFS では、ユーザーとグループのアクセスに異なるアクセス許可モデルが使用されます。 その結果、プロトコル アクセスに必要なアクセス許可モデルを受け入れるよう、Azure NetApp File ボリュームを構成する必要があります。 NFS のみの環境の場合、決定は単純であり、UNIX のセキュリティ スタイルを使用します。 SMB のみの環境では、NTFS セキュリティ スタイルを使用します。
同じデータセット (デュアル プロトコル) 上の NFS と SMB が必要な場合は、次の 2 つの質問に基づいて決定する必要があります。
- ユーザーが最も多くアクセス許可を管理するプロトコルは何ですか?
- 目的のアクセス許可管理エンドポイントとは 言い換えると、ユーザーは NFS クライアントまたは Windows クライアントからアクセス許可を管理する機能を必要としますか? またはその両方?
ボリューム セキュリティ スタイルは実際にはアクセス許可スタイルと見なすことができます。ACL 管理の目的のスタイルが決定要因です。
注
セキュリティ スタイルは、ボリュームの作成時に選択されます。 セキュリティ スタイルを選択した後は、変更できません。
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 には、ユーザー名と一意の数値識別子 (NFSv3 の UID 番号、NFSv4.1 の名前文字列、SMB の SID) が含まれます。 Azure NetApp Files では、その ID を使用して構成されたネーム サービスに対する認証を行い、ユーザーの 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 に送信されます。
user1の数値 ID を持つ 1001 という名前のユーザーが 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 ユーザーが見つからない場合、アクセスは拒否されます。
次の表では、さまざまな名前マッピングの順列と、使用中のプロトコルに応じた動作を示します。
| プロトコル | セキュリティ スタイル | 名前マッピングの方向 | 適用されるアクセス許可 |
|---|---|---|---|
| 中小企業 | UNIX | Windows から UNIX | UNIX (モード ビットまたは NFSv4.x ACL) |
| 中小企業 | NTFS | Windows から UNIX | NTFS ACL (共有にアクセスしている Windows SID に基づく) |
| NFSv3 | UNIX | 無し | UNIX (モード ビットまたは NFSv4.x ACL*) |
| NFSv4.x | UNIX | 数値 ID から UNIX ユーザー名への変換 | UNIX (モード ビットまたは NFSv4.x ACL) |
| NFS3/4.x | NTFS | UNIX から Windows | NTFS ACL (マップされた Windows ユーザー SID に基づく) |
注
Azure NetApp Files の名前マッピング規則は、現在、LDAP を使用してのみ制御できます。 サービス内で明示的な名前マッピング 規則を作成するオプションはありません。
デュアル プロトコル ボリュームを使用してサービスに名前を付けます
使用されている NAS プロトコルに関係なく、デュアル プロトコル ボリュームでは、名前マッピングの概念を使用してアクセス許可を適切に処理します。 そのため、名前サービスは、ボリュームへのアクセスに SMB と NFS の両方を使用する環境で機能を維持する上で重要な役割を果たします。
ネーム サービスは、NAS ボリュームにアクセスするユーザーとグループの ID ソースとして機能します。 この操作には、Active Directory が含まれます。Active Directory は、標準ドメイン サービスと LDAP 機能の両方を使用して、Windows ユーザーと UNIX ユーザーとグループの両方のソースとして機能できます。
ネーム サービスは難しい要件ではありませんが、Azure NetApp Files デュアルプロトコル ボリュームには強くお勧めします。 サービス内にカスタム ローカル ユーザーとグループを作成する概念はありません。 そのため、プロトコル間で適切な認証と正確なユーザーとグループの所有者情報を持つには、LDAP が必要です。 ユーザーの数がわずかで、正確なユーザーとグループ ID の情報を入力する必要がない場合は、LDAP を使用して ローカル NFS ユーザーにデュアル プロトコル ボリューム機能へのアクセスを許可することを検討してください。 この機能を有効にすると、 拡張グループ機能が無効になります。
クライアント、ネーム サービス、ストレージが異なる領域に存在する場合
場合によっては、NAS クライアントは、ストレージおよびネーム サービスへの分離接続を持つ複数のインターフェイスを持つセグメント化されたネットワークに存在する場合があります。
そのような例の 1 つは、ストレージが Azure NetApp Files に存在し、NAS クライアントとドメイン サービスがすべてオンプレミス ( Azure のハブスポーク アーキテクチャなど) に存在する場合です。 このようなシナリオでは、NAS クライアントとネーム サービスの両方にネットワーク アクセスを提供する必要があります。
次の図は、その種類の構成の例を示しています。
