Skip to main content
NetApp public and hybrid cloud solutions
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Cifrado de datos en tránsito

Colaboradores kevin-hoke
PDF

Los datos en tránsito se pueden cifrar en la capa de protocolo NAS, y la propia red de Google Cloud está cifrada, como se describe en las siguientes secciones.

Red de Google Cloud

Google Cloud cifra el tráfico a nivel de red como se describe en "Cifrado en tránsito" en la documentación de Google. Como se menciona en la sección "Arquitectura de Google Cloud NetApp Volumes ", Google Cloud NetApp Volumes se entrega desde un proyecto de producción de PSA controlado por NetApp.

En el caso de NetApp Volumes-SW, el inquilino productor ejecuta máquinas virtuales de Google para brindar el servicio. Google cifra automáticamente el tráfico entre las máquinas virtuales de los usuarios y las máquinas virtuales de Google Cloud NetApp Volumes .

Aunque la ruta de datos de NetApp Volumes-Performance no está completamente cifrada en la capa de red, NetApp y Google utilizan una combinación "de cifrado IEEE 802.1AE (MACSec)" , "encapsulación" (cifrado de datos) y redes físicamente restringidas para proteger los datos en tránsito entre el tipo de servicio NetApp Google Cloud NetApp Volumes NetApp Volumes y Google Cloud.

Protocolos NAS

Los protocolos NAS NFS y SMB proporcionan cifrado de transporte opcional en la capa de protocolo.

Cifrado SMB

"Cifrado SMB"Proporciona cifrado de extremo a extremo de datos SMB y protege los datos contra escuchas clandestinas en redes no confiables. Puede habilitar el cifrado tanto para la conexión de datos del cliente/servidor (solo disponible para clientes compatibles con SMB3.x) como para la autenticación del controlador de servidor/dominio.

Cuando el cifrado SMB está habilitado, los clientes que no admiten el cifrado no pueden acceder al recurso compartido.

Google Cloud NetApp Volumes admite los cifrados de seguridad RC4-HMAC, AES-128-CTS-HMAC-SHA1 y AES-256-CTS-HMAC-SHA1 para el cifrado SMB. SMB negocia el tipo de cifrado más alto admitido por el servidor.

NFSv4.1 Kerberos

Para NFSv4.1, NetApp Volumes-Performance ofrece autenticación Kerberos como se describe en "RFC7530" Puede habilitar Kerberos por volumen.

El tipo de cifrado más fuerte disponible actualmente para Kerberos es AES-256-CTS-HMAC-SHA1. Google Cloud NetApp Volumes admite AES-256-CTS-HMAC-SHA1, AES-128-CTS-HMAC-SHA1, DES3 y DES para NFS. También admite ARCFOUR-HMAC (RC4) para tráfico CIFS/SMB, pero no para NFS.

Kerberos proporciona tres niveles de seguridad diferentes para montajes NFS que ofrecen opciones sobre qué tan fuerte debe ser la seguridad de Kerberos.

Según Red Hat "Opciones de montaje comunes" documentación:

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.

Como regla general, cuanto más interviene el nivel de seguridad de Kerberos, peor es el rendimiento, ya que el cliente y el servidor dedican tiempo a cifrar y descifrar operaciones NFS para cada paquete enviado. Muchos clientes y servidores NFS brindan soporte para la descarga de AES-NI a las CPU para una mejor experiencia general, pero el impacto en el rendimiento de Kerberos 5p (cifrado completo de extremo a extremo) es significativamente mayor que el impacto de Kerberos 5 (autenticación de usuario).

La siguiente tabla muestra las diferencias en lo que hace cada nivel por la seguridad y el rendimiento.

Nivel de seguridad Seguridad Actuación

NFSv3—sys

  • Menos seguro; texto simple con identificadores de usuario/grupo numéricos

  • Capaz de ver UID, GID, direcciones IP de cliente, rutas de exportación, nombres de archivos, permisos en capturas de paquetes

  • Mejor para la mayoría de los casos

NFSv4.x—sys

  • Más seguro que NFSv3 (ID de cliente, coincidencia de cadena de nombre/cadena de dominio) pero aún texto simple

  • Capaz de ver UID, GID, direcciones IP de cliente, cadenas de nombres, ID de dominio, rutas de exportación, nombres de archivos y permisos en capturas de paquetes

  • Ideal para cargas de trabajo secuenciales (como máquinas virtuales, bases de datos y archivos grandes).

  • Malo con gran cantidad de archivos/altos metadatos (30-50 % peor)

NFS—krb5

  • Cifrado Kerberos para credenciales en cada paquete NFS: envuelve UID/GID de usuarios/grupos en llamadas RPC en el contenedor GSS

  • El usuario que solicita acceso al montaje necesita un ticket Kerberos válido (ya sea a través de nombre de usuario/contraseña o intercambio manual de pestañas de claves); el ticket vence después de un período de tiempo específico y el usuario debe volver a autenticarse para acceder.

  • Sin cifrado para operaciones NFS o protocolos auxiliares como mount/portmapper/nlm (se pueden ver rutas de exportación, direcciones IP, controladores de archivos, permisos, nombres de archivos, atime/mtime en capturas de paquetes)

  • Mejor en la mayoría de los casos para Kerberos; peor que AUTH_SYS

NFS—krb5i

  • Cifrado Kerberos para credenciales en cada paquete NFS: envuelve UID/GID de usuarios/grupos en llamadas RPC en el contenedor GSS

  • El usuario que solicita acceso al montaje necesita un ticket Kerberos válido (ya sea mediante nombre de usuario/contraseña o intercambio manual de pestañas de claves); el ticket vence después de un período de tiempo específico y el usuario debe volver a autenticarse para acceder.

  • Sin cifrado para operaciones NFS o protocolos auxiliares como mount/portmapper/nlm (se pueden ver rutas de exportación, direcciones IP, controladores de archivos, permisos, nombres de archivos, atime/mtime en capturas de paquetes)

  • Se agrega la suma de comprobación GSS de Kerberos a cada paquete para garantizar que nada intercepte los paquetes. Si las sumas de comprobación coinciden, se permite la conversación.

  • Mejor que krb5p porque la carga útil NFS no está cifrada; la única sobrecarga adicional en comparación con krb5 es la suma de comprobación de integridad. El rendimiento de krb5i no será mucho peor que el de krb5, pero experimentará cierta degradación.

NFS – krb5p

  • Cifrado Kerberos para credenciales en cada paquete NFS: envuelve UID/GID de usuarios/grupos en llamadas RPC en el contenedor GSS

  • El usuario que solicita acceso al montaje necesita un ticket Kerberos válido (ya sea mediante nombre de usuario/contraseña o intercambio manual de claves); el ticket vence después de un período de tiempo específico y el usuario debe volver a autenticarse para acceder.

  • Todas las cargas útiles de paquetes NFS están cifradas con el contenedor GSS (no se pueden ver los controladores de archivos, permisos, nombres de archivos ni atime/mtime en las capturas de paquetes).

  • Incluye verificación de integridad.

  • El tipo de operación NFS es visible (FSINFO, ACCESS, GETATTR, etc.).

  • Los protocolos auxiliares (mount, portmap, nlm, etc.) no están cifrados (se pueden ver rutas de exportación y direcciones IP).

  • Peor rendimiento de los niveles de seguridad; krb5p tiene que cifrar/descifrar más.

  • Mejor rendimiento que krb5p con NFSv4.x para cargas de trabajo con gran cantidad de archivos.

En Google Cloud NetApp Volumes, se utiliza un servidor Active Directory configurado como servidor Kerberos y servidor LDAP (para buscar identidades de usuario a partir de un esquema compatible con RFC2307). No se admiten otros servidores Kerberos o LDAP. NetApp recomienda encarecidamente que utilice LDAP para la gestión de identidades en Google Cloud NetApp Volumes. Para obtener información sobre cómo se muestra NFS Kerberos en las capturas de paquetes, consulte la sección enlace:gcp-gcnv-arch-detail.html#Consideraciones sobre rastreo/detección de paquetes["Consideraciones sobre rastreo/detección de paquetes."]