了解 Azure NetApp Files 中的雙重通訊協定安全性樣式和權限行為

發行項
05/30/2024

SMB 和 NFS 會使用不同的權限模型來存取使用者和群組。因此，必須將 Azure NetApp Files 磁碟區設定為接受通訊協定存取所需的權限模型。對於僅限 NFS 環境，決策很簡單 – 使用 UNIX 安全性樣式。對於僅限 SMB 環境，使用 NTFS 安全性樣式。

如果相同的資料集上需要 NFS 和 SMB (雙重通訊協定)，則應該根據兩個問題做出決策：

使用者最能管理權限的通訊協定為何？
什麼是所需的權限管理端點？換句話說，使用者是否需要能夠管理來自 NFS 用戶端或 Windows 用戶端的權限？或兩者？

磁碟區安全性樣式實際上可以視為權限樣式，其中所需的 ACL 管理樣式是決定因素。

注意

安全性樣式是在建立磁碟區時進行選擇。安全性樣式在選擇之後，就無法變更。

關於 Azure NetApp Files 磁碟區安全性樣式

在 Azure NetApp Files 中，磁碟區安全性樣式有兩個主要選擇：

UNIX - UNIX 安全性樣式提供 UNIX 樣式權限，例如基本 POSIX 模式位元 (具有標準讀取/寫入/執行權限的擁有者/群組/所有人存取權，例如 0755) 和 NFSv4.x ACL。不支援 POSIX ACL。

NTFS - NTFS 安全性樣式使用 ACL 中的細微使用者和群組以及詳細的安全性/稽核權限來提供與標準 Windows NTFS 權限相同的功能。

在雙重通訊協定 NAS 環境中，只能有一個安全性權限樣式作用中。您應該先評估每個安全性樣式的考量，再進行選擇。

安全性樣式	考量
UNIX	- Windows 用戶端只能透過對應至 UNIX 屬性的 SMB 來設定 UNIX 權限屬性 (僅限讀取/寫入/執行；沒有特殊權限)。 - NFSv4.x ACL 沒有 GUI 管理。管理只能透過 CLI 使用 nfs4_getfacl 和 nfs4_setfacl 命令來完成。 - 如果檔案或資料夾有 NFSv4.x ACL，則 Windows 安全性屬性索引標籤無法顯示這些 ACL。
NTFS	- UNIX 用戶端無法透過 NFS 使用 `chown/chmod` 這類的命令來設定屬性。 - 使用 `ls` 命令時，NFS 用戶端只會顯示近似的 NTFS 權限。假如使用者在 Windows NTFS ACL 中具有無法完全轉譯為 POSIX 模式位元的權限 (例如周遊目錄)，則會將其轉譯為最接近的 POSIX 模式位元值 (例如，適用於執行作業的 `1`)。

磁碟區安全性樣式的選取會決定如何執行使用者的名稱對應。不論使用中的通訊協定為何，此作業都是雙重通訊協定磁碟區如何維護可預測權限的核心部分。

使用下表作為決策矩陣，以選取適當的磁碟區安全性樣式。

安全性樣式	大部分是 NFS	大部分是 SMB	需要細微安全性
UNIX	X	-	X (使用 NFSv4.x ACL)
NTFS	-	X	X

名稱對應在 Azure NetApp Files 中的運作方式

在 Azure NetApp Files 中，只會驗證和對應使用者。未對應群組。相反地，群組成員資格是使用使用者身分識別所決定。

使用者嘗試存取 Azure NetApp Files 磁碟區時，該嘗試會將身分識別傳遞至服務。該身分識別包括使用者名稱和唯一數值識別碼 (NFSv3 為 UID 號碼、NFSv4.1 為名稱字串、SMB 為 SID)。 Azure NetApp Files 會使用該身分識別來驗證已設定的名稱服務，以驗證使用者的身分識別。

LDAP 搜尋數值識別碼用來在 Active Directory 中查閱使用者名稱。
名稱字串會使用 LDAP 搜尋來查閱使用者名稱，用戶端和伺服器則會查閱 NFSv4.1 的已設定識別碼網域，以確保相符。
會使用對 Active Directory 的標準 Windows RPC 呼叫來查詢 Windows 使用者。
也會查詢群組成員資格，而且所有項目都會新增至認證快取，以更快速地處理後續對磁碟區的要求。
目前，不支援自訂本機使用者與 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 且具有數值識別碼 1001 的使用者嘗試存取 NFSv3 掛接，則驗證要求會以數值識別碼 1001 的形式送達。 Azure NetApp Files 接著會採用數值識別碼 1001，並嘗試將 1001 解析為使用者名稱。需要此使用者名稱，才能對應至有效的 Windows 使用者，因為磁碟區上的 NTFS 權限將會包含 Windows 使用者名稱，而不是數值識別碼。 Azure NetApp Files 將會使用已設定的名稱服務伺服器 (LDAP) 來搜尋使用者名稱。如果找不到使用者名稱，則驗證會失敗，並拒絕存取。此作業是設計來防止不想要的檔案和資料夾存取。

根據安全性樣式的名稱對應

Azure NetApp Files 中名稱對應的發生方向 (Windows 到 UNIX 或 UNIX 到 Windows) 不只取決於所使用的通訊協定，也取決於磁碟區的安全性樣式。 Windows 用戶端一律需要 Windows 對 UNIX 名稱對應，才能允許存取，但不一定需要相符的 UNIX 使用者名稱。如果已設定的名稱服務伺服器中沒有有效的 UNIX 使用者名稱，則 Azure NetApp Files 會提供具有數值 UID 65534 的後援預設 UNIX 使用者，以允許 SMB 連線的初始驗證。之後，檔案和資料夾權限將會控制存取權。因為 65534 通常會與 nfsnobody 使用者對應，所以在大部分情況下，存取會受到限制。相反地，如果正在使用的是 NTFS 安全性樣式，則 NFS 用戶端只需要使用 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 使用者名稱的數值識別碼	UNIX (模式位元或 NFSv4.x ACL)
NFS3/4.x	NTFS	UNIX 到 Windows	NTFS ACL (根據對應的 Windows 使用者 SID)

注意

Azure NetApp Files 中的名稱對應規則目前只能使用 LDAP 進行控制。沒有任何選項可在服務內建立明確名稱對應規則。

具有雙重通訊協定磁碟區的名稱服務

不論使用哪種 NAS 通訊協定，雙重通訊協定磁碟區都會使用名稱對應概念來正確處理權限。因此，在維護使用 SMB 和 NFS 來存取磁碟區之環境中的功能中，名稱服務扮演重要角色。

名稱服務可作為存取 NAS 磁碟區之使用者和群組的身分識別來源。此作業包括 Active Directory，其可作為使用標準網域服務和 LDAP 功能的 Windows 和 UNIX 使用者和群組的來源。

名稱服務並非硬式需求，但強烈建議用於 Azure NetApp Files 雙重通訊協定磁碟區。沒有在服務內建立自訂本機使用者和群組的概念。因此，若要具有跨通訊協定的適當驗證和精確使用者和群組擁有者資訊，需要 LDAP。若只有少數使用者，而且不需要填入精確的使用者和群組身分識別資訊，則請考慮使用允許具有 LDAP 的本機 NFS 使用者存取雙重通訊協定磁碟區功能。請記住，啟用此功能會停用擴充群組功能。

用戶端、名稱服務和儲存體位於不同區域時

在某些情況下，NAS 用戶端所存在的分段網路可能會有儲存體和名稱服務隔離連線的多個介面。

例如，若儲存體位於 Azure NetApp Files 中，而您的 NAS 用戶端和網域服務全都位於內部部署環境 (例如 Azure 中的中樞輪輻架構)。在這些情節中，您需要提供對 NAS 用戶端和名稱服務的網路存取權。

下圖顯示該設定類型的範例。

共用方式為