了解 Azure NetApp Files 中的資料加密
Azure NetApp Files 會透過兩種不同的方法加密資料：
- 待用加密：資料會使用符合 FIPS 140-2 的標準就地加密。
- 傳輸中加密：在用戶端和伺服器之間傳輸資料時，資料會在傳輸中加密，或透過連線加密。
了解待用加密
Azure NetApp Files 中的待用資料可透過兩種方式加密：
- 單一加密會針對 Azure NetApp Files 磁碟區使用軟體型加密。
- 雙重加密會在實體存放裝置層新增硬體層級加密。
Azure NetApp Files 會使用標準 CryptoMod 來產生 AES-256 加密金鑰。 CryptoMod 列在 CMVP FIPS 140-2 已驗證的模組清單中；如需詳細資訊，請參閱 FIPS 140-2 憑證 #4144。 加密金鑰與磁碟區相關聯，而且可以是 Microsoft 平台管理的金鑰或客戶自控金鑰。
了解傳輸中資料加密
除了保護待用資料之外，Azure NetApp Files 可以在端點之間保護傳輸中的資料。 所使用的加密方法取決於通訊協定或功能。 在 Azure NetApp Files 中，DNS 不會進行傳輸中加密。 繼續閱讀以了解 Azure NetApp Files 中的 SMB 和 NFS 加密、LDAP 和資料複寫。
SMB 加密
使用 SMB3.x 通訊協定版本的 Windows SMB 用戶端原生支援 SMB加密。 SMB 加密會以端對端方式進行，並使用 AES-256-GCM/AES-128-GCM 和 AES-256-CCM/AES-128-CCM 密碼編譯套件來加密整個 SMB 交談。
Azure NetApp Files 磁碟區不需要 SMB 加密，但其可用來提供額外的安全性。 SMB 加密確實會增加效能額外負荷。 若要深入了解 SMB 加密的效能考量，請參閱 Azure NetApp Files 的 SMB 效能最佳做法。
需要 SMB 連線的加密
Azure NetApp Files 提供 [在所有 SMB 連線上強制執行加密] 的選項。 強制執行加密不允許未加密的 SMB 通訊，並使用 SMB3 和更新版本進行 SMB 連線。 加密是使用 AES 加密來執行，並加密所有 SMB 封包。 若要讓這項功能正常運作，SMB 用戶端必須支援 SMB 加密。 如果 SMB 用戶端不支援加密和 SMB3，則不允許 SMB 連線。 如果啟用此選項，具有相同 IP 位址的所有共用都需要加密，因此會覆寫加密的 SMB 共用屬性設定。
SMB 共用層級加密
或者，加密可以在 Azure NetApp Files 磁碟區的個別共用層級設定。
UNC 強化
在 2015 年，Microsoft 引進了 UNC 強化功能 (MS15-011 和 MS15-014)，以解決遠端網路路徑漏洞，以允許跨 SMB 共用執行遠端程式碼。 如需詳細資訊，請參閱 MS15-011 和 MS15-014：強化群組原則。
UNC 強化提供三個選項來保護 UNC 路徑：
RequireMutualAuthentication：需要/不需要身分識別驗證來封鎖詐騙攻擊。RequireIntegrity：需要/不需要完整性檢查來封鎖竄改攻擊。RequirePrivacy：要啟用/停用隱私權 (SMB 封包的完全加密) 來防止流量探查。
Azure NetApp Files 支援所有三種形式的 UNC 強化。
NFS Kerberos
Azure NetApp Files 也可讓您使用 AES-256-GCM/AES-128-GCM 和 AES-256-CCM/AES-256-CCM/AES-128-CCM 密碼編譯套件，透過 Kerberos 驗證來加密 NFSv4.1 交談。
使用 NFS Kerberos，Azure NetApp Files 支援三種不同的安全性類別：
- Kerberos 5 (
krb5)：僅限初始驗證；需要 Kerberos 票證交換/使用者登入才能存取 NFS 匯出。 NFS 封包不會加密。 - Kerberos 5i (
krb5i)：初始驗證和完整性檢查；需要 Kerberos 票證交換/使用者登入才能存取 NFS 匯出，並將完整性檢查新增至每個 NFS 封包，以防止中間人攻擊 (MITM)。 - Kerberos 5p (
krb5p)：初始驗證、完整性檢查和隱私權；需要 Kerberos 票證交換/使用者登入才能存取 NFS 匯出、執行完整性檢查，並將 GSS 包裝函式套用至每個 NFS 封包以加密其內容。
每個 Kerberos 加密層級對效能都有影響。 隨著加密類型和安全性類別納入更安全的方法，效能效果也會增加。 例如，krb5 的效能優於 krb5i，krb5i 的效能優於 krb5p、AES-128 的效能優於 AES-256 等等。 如需 Azure NetApp Files 中 NFS Kerberos 效能影響的詳細資訊，請參閱 Azure NetApp Files NFSv4.1 磁碟區中 Kerberos 的效能影響。
注意
只有 Azure NetApp Files 中的 NFSv4.1 支援 NFS Kerberos。
在下圖中，會使用 Kerberos 5 (krb5)；只會加密初始驗證要求 (登入/票證取得)。 所有其他 NFS 流量都會以純文字送達。
使用 Kerberos 5i (krb5i；完整性檢查) 時，追蹤內顯示 NFS 封包未加密，但已將 GSS/Kerberos 包裝函式新增至此封包，該封包需要用戶端和伺服器使用總和檢查碼確保所傳輸資料的完整性。
Kerberos 5p (隱私權；krb5p) 提供所有 NFS 流量的端對端加密，如使用 GSS/Kerberos 包裝函式的追蹤影像所示。 由於需要處理每個 NFS 封包的加密，這個方法會產生最多的效能額外負荷。
資料複寫
在 Azure NetApp Files 中，您可以跨 Azure 中的區域或地區複寫整個磁碟區，以提供資料保護。 由於複寫流量位於 Azure 雲端中，因此傳輸會在安全的 Azure 網路基礎結構中進行，這在存取權有限，以防止封包探查和中間人攻擊 (通訊端點之間的竊聽或模擬)。 此外，複寫流量會使用符合 FIPS 140-2 的 TLS 1.2 標準進行加密。 如需詳細資訊，請參閱安全性常見問題。
LDAP 加密
一般而言，LDAP 搜尋和繫結流量會以純文字透過連線傳遞，這表示有權存取探查網路封包的任何人都可以從 LDAP 伺服器取得資訊，例如使用者名稱、數值識別碼、群組成員資格等。然後，可使用這項資訊來詐騙使用者、傳送電子郵件以進行網路釣魚攻擊等。
為了防止 LDAP 通訊遭到攔截和讀取，LDAP 流量可以透過連線加密 (利用 AES 和 TLS 1.2，分別透過 LDAP 簽署和 LDAP over TLS)。 如需設定這些選項的詳細資訊，請參閱建立和管理 Active Directory 連線。
LDAP 簽署
LDAP 簽署專屬於裝載使用者和群組 UNIX 身分識別的 Microsoft Active Directory 伺服器上的連線。 此功能可讓簡單驗證及安全性階層 (SASL) LDAP 的完整性驗證繫結至裝載 LDAP 連線的 AD 伺服器。 簽署不需要設定安全性憑證，因為其會使用 GSS-API 與 Active Directory 的 Kerberos 金鑰發佈中心 (KDC) 服務通訊。 LDAP 簽署只會檢查 LDAP 封包的完整性，並不會加密封包的承載。
也可以透過群組原則從 Windows Server 端設定 LDAP 簽署，以隨機使用 LDAP 簽署 (無：如果用戶端要求支援)，或強制執行 LDAP 簽署 (必要時)。 LDAP 簽署會將一些效能額外負荷加到通常對終端使用者來說並不明顯的 LDAP 流量。
Windows Active Directory 也可讓您使用 LDAP 簽署和密封 (LDAP 封包的端對端加密)。 Azure NetApp Files 不支援此功能。
LDAP 通道繫結
由於 Windows Active Directory 網域控制站中發現的資訊安全漏洞，因此 Windows Server 的預設設定已變更。 如需詳細資訊，請參閱 Microsoft Security Advisory ADV190023。
基本上，Microsoft 建議系統管理員啟用 LDAP 簽署以及通道繫結。 如果 LDAP 用戶端支援通道繫結權杖和 LDAP 簽署，則需要通道繫結和簽署，而且新的 Microsoft 修補程式會設定登錄選項。
根據預設，Azure NetApp Files 會隨機支援 LDAP 通道繫結，這表示用戶端支援 LDAP 通道繫結時會用到。 如果不支援/傳送通道繫結，仍允許通訊，而且不會強制執行通道繫結。
LDAP over SSL (連接埠 636)
在所有情況下，Azure NetApp Files 中的 LDAP 流量都會透過連接埠389 傳遞。 無法修改此連接埠。 不支援 LDAP over SSL (LDAPS)，而且大部分 LDAP 伺服器廠商都認為其是舊版 (RFC 1777 於 1995 年發佈)。 如果您想要搭配 Azure NetApp Files 使用 LDAP 加密，請使用 LDAP over TLS。
LDAP over StartTLS
LDAP over StartTLS 於 2000 年以 RFC 2830 引進，且於 2006 年以 RFC 4511 合併到 LDAPv3 標準中。 在 StartTLS 成為標準之後，LDAP 廠商開始將 LDAPS 視為已被取代。
LDAP over StartTLS 會針對 LDAP 連線使用連接埠 389。 建立初始 LDAP 連線之後，會交換 StartTLS OID 並比較憑證；然後使用 TLS 來加密所有 LDAP 流量。 下面顯示的封包擷取會顯示 LDAP 繫結、StartTLS 交握和後續 TLS 加密的 LDAP 流量。
LDAPS 和 StartTLS 之間有兩個主要差異：
- StartTLS 是 LDAP 標準的一部分；LDAPS 不是。 因此，LDAP 伺服器或用戶端上的 LDAP 程式庫支援可能會有所不同，而且功能在所有情況下可能可以運作，也可能無法運作。
- 如果加密失敗，StartTLS 可讓設定回復為一般 LDAP。 LDAPS 不會。 因此，StartTLS 提供一些彈性和復原能力，但如果設定錯誤，也會帶來安全性風險。
使用 LDAP over StartTLS 的安全性考量
StartTLS 可讓系統管理員在想要時回復為一般 LDAP 流量。 基於安全性考量，大部分的 LDAP 系統管理員都不允許。 StartTLS 的下列建議可協助保護 LDAP 通訊：
- 確定已啟用 StartTLS，並設定憑證。
- 針對內部環境，您可以使用自我簽署憑證，但針對外部 LDAP，請使用憑證授權單位。 如需憑證的詳細資訊，請參閱自我簽署 SSL 和憑證授權單位之間的差異。
- 防止未使用 StartTLS 的 LDAP 查詢和繫結。 Active Directory 預設會停用匿名繫結。
Active Directory 安全性連線
Azure NetApp Files 磁碟區的 Active Directory 連線可以設定為先嘗試最強可用的 Kerberos 加密類型：AES-256。 啟用 AES 加密時，網域控制站通訊 (例如排程的 SMB 伺服器密碼重設) 會使用網域控制站上支援的最高可用加密類型。 Azure NetApp Files 針對網域控制站通訊支援下列加密類型 (依嘗試驗證的順序排列)：AES-256、AES-128、RC4-HMAC、DES
注意
您無法停用 Azure NetApp Files 中較弱的驗證類型 (例如 RC4-HMAC 和 DES)。 相反地，如有需要，應該從網域控制站停用這些驗證類型，使驗證要求不會嘗試加以使用。 如果在網域控制站上停用 RC4-HMAC，則必須在 Azure NetApp Files 中啟用 AES 加密，才能正常運作。