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来提供服务。用户VM与Google Cloud NetApp Volumes VM之间的流量由Google自动加密。

尽管NetApp卷性能的数据路径未在网络层完全加密、但NetApp和Google使用组合、 "封装"(数据加密)和物理受限网络来保护Google "IEEE 802.1AE加密(MAC秒)" Cloud NetApp卷NetApp卷性能服务类型与Google Cloud之间传输的数据。

NAS协议

NFS和SMB NAS协议可在协议层提供可选的传输加密。

SMB加密

"SMB加密" 为SMB数据提供端到端加密、并防止数据在不可信的网络上被窃听。您可以同时为客户端/服务器数据连接(仅适用于具有SMB3.x功能的客户端)和服务器/域控制器身份验证启用加密。

启用SMB加密后、不支持加密的客户端将无法访问共享。

Google Cloud NetApp卷支持RC4-HMAC、AES-128-CTS-HMAC-SHA1和AES-256-CTS-HMAC-SHA1安全密码、用于SMB加密。SMB协商到服务器支持的最高加密类型。

NFSv4.1 Kerberos

对于NFSv4.1、NetApp Volume-Performance提供了Kerberos身份验证、如中所述 "RFC7530"。您可以按卷启用Kerberos。

当前最强的Kerberos加密类型为AES-256-CTS-HMAC-SHA1。Google Cloud NetApp卷支持适用于NFS的AES-256-CTS-HMAC-SHA1、AES-128-CTS-HMAC-SHA1、DES3和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地址、文件句柄、权限、文件名、 数据包捕获中的atime/mtime)

  • 大多数情况下最适合使用Kerberos；比AUTH_SYS更差

NFS—krb5i

  • 对每个NFS数据包中的凭据进行Kerberos加密—在GSS包装程序中的RPC调用中封装用户/组的UID/GID

  • 请求访问挂载的用户需要有效的Kerberos票证(通过用户名/密码或手动密钥选项卡交换)；票证将在指定时间段后过期、用户必须重新进行身份验证才能访问

  • 对于NFS操作或挂载/端口映射程序/NLM等辅助协议、不进行加密(可以查看导出路径、IP地址、文件句柄、权限、文件名、 数据包捕获中的atime/mtime)

  • 每个数据包都会添加Kerberos GSS校验和、以确保不会截获任何数据包。如果校验和匹配、则允许对话。

  • 优于krb5p、因为NFS有效负载未加密；与krb5相比、唯一增加的开销是完整性校验和。krb5i的性能不会比krb5差得多、但会有所下降。

NFS—krb5p

  • 对每个NFS数据包中的凭据进行Kerberos加密—在GSS包装程序中的RPC调用中封装用户/组的UID/GID

  • 请求访问挂载的用户需要有效的Kerberos票证(通过用户名/密码或手动密钥表交换)；票证将在指定时间段后过期、用户必须重新进行身份验证才能进行访问

  • 所有NFS数据包有效负载都使用GSS包装程序进行加密(在数据包捕获中看不到文件句柄、权限、文件名、atime/mtime)。

  • 包括完整性检查。

  • NFS操作类型是可见的(fsINFO、access、getattr等)。

  • 辅助协议(挂载、端口映射、NLM等)未加密-(可以查看导出路径、IP地址)

  • 安全级别的性能最差；krb5p必须对更多内容进行加密/解密。

  • 对于文件数量较多的工作负载、性能优于使用NFSv4.x时的krb5p。

在Google Cloud NetApp卷中、已配置的Active Directory服务器用作Kerberos服务器和LDAP服务器(用于从兼容RFC2307的架构中查找用户身份)。不支持其他Kerberos或LDAP服务器。NetApp强烈建议您在Google Cloud NetApp卷中使用LDAP进行身份管理。有关NFS Kerberos在数据包捕获中的显示方式的信息、请参见链接：ncs-gcCloud volume-service-architution.html#Packet nosing/trace注意事项["数据包探查/跟踪注意事项"]