简体中文版经机器翻译而成,仅供参考。如与英语版出现任何冲突,应以英语版为准。

传输中的数据加密

传输中的数据可以在NAS协议层进行加密、Google Cloud网络本身也会进行加密、如以下各节所述。

Google Cloud网络

Google Cloud按中所述在网络级别对流量进行加密 "传输中加密" 在Google文档中。如"云卷服务架构"一节所述、Cloud Volumes Service 是通过NetApp控制的PSA生产商项目交付的。

对于CVS-SW、生产者租户运行Google VM来提供服务。Google会自动对用户VM和Cloud Volumes Service VM之间的流量进行加密。

虽然在网络层上、CVS-Performance的数据路径未完全加密、但NetApp和Google会结合使用 "IEEE 802.1AE加密(MAC秒)""封装" (数据加密)和受物理限制的网络、用于保护Cloud Volumes Service CVS-Performance服务类型与Google Cloud之间传输的数据。

NAS协议

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

SMB加密

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

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

Cloud Volumes Service 支持使用RC4 HMAC、AES-128-CTS-HMAC-SHA1和AES-256-CTS-HMAC-SHA1安全密码进行SMB加密。SMB协商到服务器支持的最高加密类型。

NFSv4.1 Kerberos

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

当前最强的Kerberos加密类型为AES-256-CTS-HMAC-SHA1。NetApp Cloud Volumes Service 支持适用于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。

在Cloud Volumes Service 中、配置的Active Directory服务器用作Kerberos服务器和LDAP服务器(从RFC2307兼容模式查找用户身份)。不支持其他Kerberos或LDAP服务器。NetApp强烈建议您在Cloud Volumes Service 中使用LDAP进行身份管理。有关NFS Kerberos在数据包捕获中的显示方式的信息、请参见一节 "《数据包嗅探/跟踪注意事项》。"