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 可以在端點之間傳輸時保護數據。 所使用的加密方法取決於通訊協定或功能。 DNS 不會在 Azure NetApp 檔案中加密傳輸中。 繼續閱讀以瞭解 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-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 效能影響的詳細資訊，請參閱 Kerberos 對 Azure NetApp Files NFSv4.1 磁碟區的效能影響。
備註
只有 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 封包的有效性；它不會加密封包的載荷。
LDAP 簽署也可以讓 Windows 伺服器端透過組策略設定為隨機使用 LDAP 簽署（無 – 若用戶端要求則支援），或強制執行 LDAP 簽署（必須）。 LDAP 簽署可以將一些效能負擔新增至 LDAP 流量，通常終端使用者不會注意到。
Windows Active Directory 也可讓您使用 LDAP 簽署和密封（LDAP 封包的端對端加密）。 Azure NetApp Files 不支援此功能。
LDAP 通道繫結
由於 Windows Active Directory 域控制器中發現的安全性弱點，因此 Windows 伺服器的預設設定已變更。 如需詳細資訊，請參閱 Microsoft Security Advisory ADV190023。
基本上，Microsoft建議系統管理員啟用 LDAP 簽署以及通道系結。 如果LDAP用戶端支援通道系結令牌和LDAP簽署，則需要通道系結和簽署，而新的Microsoft修補程式會設定登錄選項。
根據預設，Azure NetApp Files 支援 LDAP 通道系結的機會性連結，意即只有當客戶端支援 LDAP 通道系結時才會使用。 如果不支援/傳送通道系結，仍允許通訊，而且不會強制執行通道系結。
透過 SSL 的 LDAP （連接埠 636）
在所有情況下，Azure NetApp Files 中的LDAP流量都會通過埠389。 無法修改此埠。 不支援LDAP over SSL （LDAPS），而且大部分LDAP伺服器廠商都認為是舊版 （RFC 1777 於1995年發行）。 如果您想要搭配 Azure NetApp Files 使用 LDAP 加密，請使用 LDAP over TLS。
透過 StartTLS 的 LDAP
LDAP over StartTLS 於 2000 年以 RFC 2830 引進，2006 年結合為 LDAPv3 標準與 RFC 4511 。 在 StartTLS 成為標準之後，LDAP 廠商開始將 LDAPS 稱為已被取代。
LDAP over StartTLS 使用埠 389 進行 LDAP 連線。 建立初始LDAP連線之後，會交換 StartTLS OID 並比較憑證;然後使用 TLS 來加密所有 LDAP 流量。 下面顯示的封包擷取會顯示 LDAP 繫結、StartTLS 交握和後續 TLS 加密的 LDAP 流量。
LDAPS 和 StartTLS 之間有兩個主要差異：
- StartTLS 是LDAP標準的一部分;LDAPS 不是。 因此，LDAP 伺服器或用戶端上的LDAP連結庫支援可能會有所不同，而且功能在所有情況下都可能或可能無法運作。
- 如果加密失敗，StartTLS 可讓設定回復為一般 LDAP。 LDAPS 不會。 因此，StartTLS 提供一些彈性和復原能力，但如果設定錯誤，也會帶來安全性風險。
透過 StartTLS 使用 LDAP 的安全性考慮
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 加密，才能正常運作。