Skip to main content
NetApp Solutions
本繁體中文版使用機器翻譯，譯文僅供參考，若與英文版本牴觸，應以英文版本為準。

傳輸中的資料加密

貢獻者
PDF

傳輸中的資料可在NAS傳輸協定層加密、Google Cloud網路本身也會加密、如下列各節所述。

Google Cloud網路

Google Cloud 會依照 Google 文件中所述，加密網路層級的流量 "傳輸中加密"。如「 Google Cloud NetApp Volumes 架構」一節所述， Google Cloud NetApp Volumes 是由 NetApp 控制的 PSA 製作人員專案所提供。

如果是 NetApp Volume-SW ，則製作租戶會執行 Google VM 以提供服務。Google 會自動加密使用者 VM 與 Google Cloud NetApp Volumes VM 之間的流量。

雖然 NetApp Volumes 效能的資料路徑在網路層上並未完全加密，但 NetApp 和 Google 會使用組合， "封裝"（資料加密）和 "IEEE 802.1AE加密（MAC安全）"實體受限的網路來保護在 Google Cloud NetApp Volumes NetApp Volumes - Performance 服務類型和 Google Cloud 之間傳輸的資料。

NAS傳輸協定

NFS和SMB NAS傳輸協定可在傳輸協定層提供選用的傳輸加密。

SMB加密

"SMB加密" 提供SMB資料的端點對端點加密、並保護資料免於在不受信任的網路上遭人竊取。您可以啟用用戶端/伺服器資料連線（僅適用於支援SMB3.x的用戶端）和伺服器/網域控制器驗證的加密。

啟用SMB加密時、不支援加密的用戶端將無法存取共用區。

Google Cloud NetApp Volumes 支援用於 SMB 加密的 RC4-HMAC ， AES-124-CTS-HMAC-SHA1 和 AES-256-CTS-HMAC-SHA1 安全密碼。SMB會交涉至伺服器支援的最高加密類型。

NFSv4.1 Kerberos

對於 NFSv4.1 ， NetApp Volume-Performance 提供 Kerberos 驗證，如中所述。您可以根據 "RFC7530"每個磁碟區來啟用 Kerberos 。

Kerberos目前最強大的加密類型是AES-256-CTS-HMA-SHA1。Google Cloud NetApp Volumes 支援 AES-256-CTS-HMAC-SHA1 ， AES-126-CTS-HMAC-SHA1 ， DES3 和 NFS 的 DES 。它也支援CIFS/SMB流量的ARCFOUR-HMAC（RC4）、但不支援NFS。

Kerberos為NFS裝載提供三種不同的安全性層級、可讓您選擇Kerberos安全性的強度。

根據RedHat "通用掛載選項" 文件：

sec=krb5 uses Kerberos V5 instead of local UNIX UIDs and GIDs to authenticate users.
sec=krb5i uses Kerberos V5 for user authentication and performs integrity checking of NFS operations using secure checksums to prevent data tampering.
sec=krb5p uses Kerberos V5 for user authentication, integrity checking, and encrypts NFS traffic to prevent traffic sniffing. This is the most secure setting, but it also involves the most performance overhead.

一般而言、Kerberos安全性層級越高、效能就越差、因為用戶端和伺服器花費時間來加密和解密所傳送的每個封包的NFS作業。許多用戶端和NFS伺服器都支援AES-NI卸載至CPU、以獲得更好的整體體驗、但Kerberos 5p（完整端對端加密）的效能影響遠高於Kerberos 5（使用者驗證）的影響。

下表顯示每個層級在安全性和效能方面的差異。

安全性層級 安全性 效能

NFSv3—系統

  • 最不安全；純文字、含數字使用者ID /群組ID

  • 能夠檢視UID、GID、用戶端IP位址、匯出路徑、檔案名稱、 封包擷取的權限

  • 最適合大多數情況

NFSv4.x—系統

  • 比NFSv3（用戶端ID、名稱字串/網域字串比對）更安全、但仍是純文字

  • 能夠檢視UID、GID、用戶端IP位址、名稱字串、網域ID、 在封包擷取中匯出路徑、檔案名稱、權限

  • 適合連續工作負載（例如VM、資料庫、大型檔案）

  • 高檔案數/高中繼資料的不良（差30-50%）

NFS—KRB5

  • 每個NFS封包中的認證Kerberos加密：在GSS包裝程式的RPC呼叫中、將使用者/群組的UID/GID封包起來

  • 要求存取掛載的使用者需要有效的Kerberos票證（透過使用者名稱/密碼或手動金鑰索引標籤交換）；票證會在指定的時間段後過期、使用者必須重新驗證才能存取

  • 不加密NFS作業或掛載/連接埠對應器/ NLM等輔助通訊協定（可參閱匯出路徑、IP位址、檔案處理、權限、檔案名稱、 封包擷取的時間/時間）

  • 在大多數情況下最佳的Kerberos；比AUTH_SYS更糟

NFS：krb5i

  • 每個NFS封包中的認證Kerberos加密：在GSS包裝程式的RPC呼叫中、將使用者/群組的UID/GID封包起來

  • 要求存取掛載的使用者需要有效的Kerberos票證（透過使用者名稱/密碼或手動金鑰索引標籤交換）；票證會在指定的時間段後過期、使用者必須重新驗證才能存取

  • 不加密NFS作業或掛載/連接埠對應器/ NLM等輔助通訊協定（可參閱匯出路徑、IP位址、檔案處理、權限、檔案名稱、 封包擷取的時間/時間）

  • 每個封包都會新增Kerberos GSS Checksum、以確保不會攔截封包。如果校驗和相符、則允許對話。

  • 優於krb5p、因為NFS有效負載未加密；只有與krb5相比、新增的額外負荷才是完整性Checksum。krb5i的效能不會比krb5差很多、但會有一些降低。

NFS–krb5p

  • 每個NFS封包中的認證Kerberos加密：在GSS包裝程式的RPC呼叫中、將使用者/群組的UID/GID封包起來

  • 要求存取掛載的使用者需要有效的Kerberos票證（透過使用者名稱/密碼或手動Keytab交換）；票證會在指定的時間段後過期、而且使用者必須重新驗證才能存取

  • 所有NFS封包有效負載都會使用GSS包裝進行加密（無法在封包擷取中看到檔案處理代碼、權限、檔案名稱、atime/mtime）。

  • 包括完整性檢查。

  • NFS作業類型可見（Fsinfo, access, GetAttr等）。

  • 輔助通訊協定（掛載、連接埠對應、NLM等）未加密-（請參閱匯出路徑、IP位址）

  • 安全性層級效能最差；krb5p必須加密/解密更多資料。

  • 使用NFSv4.x的效能優於krb5p、適用於高檔案數工作負載。

在 Google Cloud NetApp Volumes 中，已設定的 Active Directory 伺服器會用作 Kerberos 伺服器和 LDAP 伺服器（以從與 RFC2307 相容的架構中查詢使用者身分識別）。不支援其他Kerberos或LDAP伺服器。NetApp 強烈建議您在 Google Cloud NetApp Volumes 中使用 LDAP 進行身分識別管理。如需有關 NFS Kerberos 在封包擷取中的顯示方式資訊、請參閱連結： ncvs-GC 雲端 - Volume-service-architecture 。 html#Packet sniffing/trace 考量 [ 「封包探查 / 追蹤考量」 ] 一節。