Skip to main content
NetApp 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
PDF

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

Red de Google Cloud

Google Cloud cifra el tráfico en el nivel de la red, tal y como se describe en "Cifrado en tránsito" En la documentación de Google. Como se mencionó en la sección "Arquitectura de Cloud Volumes Services", Cloud Volumes Service se ofrece desde un proyecto de productor de PSA controlado por NetApp.

En caso de CVS-SW, el inquilino productor ejecuta las VM de Google para ofrecer el servicio. Google cifra automáticamente el tráfico entre los equipos virtuales del usuario y los equipos virtuales de Cloud Volumes Service.

Aunque la ruta de datos para CVS-Performance no está completamente cifrada en la capa de red, NetApp y Google usan una combinación de ambos "De cifrado IEEE 802.1AE (MACSec)", "encapsulación" (Cifrado de datos) y redes con limitaciones físicas para proteger los datos en tránsito entre el tipo de servicio CVS-Performance de Cloud Volumes Service y Google Cloud.

Protocolos NAS

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

Cifrado SMB

"Cifrado SMB" Proporciona cifrado integral de datos SMB y protege los datos de espionaje en redes que no son de confianza. Puede habilitar el cifrado tanto para la conexión de datos de cliente/servidor (solo disponible para clientes compatibles con SMB3.x) como para la autenticación de la controladora de servidor/dominio.

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

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

NFSv4.1 Kerberos

Para NFSv4.1, CVS-Performance ofrece autenticación de Kerberos, tal como se describe en "RFC7530". Puede activar Kerberos por volumen.

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

Kerberos proporciona tres niveles de seguridad distintos para montajes NFS que ofrecen opciones para la solidez de la seguridad de Kerberos.

Según RedHat’s "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 mayor sea el nivel de seguridad de Kerberos, peor será el rendimiento, puesto que el cliente y el servidor pasan tiempo cifrando y descifrando las operaciones de NFS para cada paquete enviado. Muchos clientes y servidores NFS ofrecen 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 integral) es significativamente mayor que el impacto de Kerberos 5 (autenticación de usuario).

En la siguiente tabla se muestran las diferencias en el rendimiento y la seguridad de cada nivel.

Nivel de seguridad Seguridad Rendimiento

NFSv3: System

  • Menos seguro; texto sin formato con ID de usuario/ID de grupo numéricos

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

  • Lo mejor para la mayoría de los casos

NFSv4.x: Sys

  • Más seguro que NFSv3 (identificadores de cliente, coincidencia de cadena de nombre/cadena de dominio) pero texto sin formato

  • Se puede ver UID, GID, direcciones IP de cliente, cadenas de nombre, identificadores de dominio, rutas de exportación, nombres de archivo y permisos en capturas de paquetes

  • Bueno para cargas de trabajo secuenciales (como equipos virtuales, bases de datos, archivos de gran tamaño)

  • Malo con un número elevado de archivos/metadatos altos (un 30-50% peor)

NFS: Krb5

  • El 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 el acceso al montaje necesita un ticket Kerberos válido (ya sea mediante el nombre de usuario/contraseña o el cambio de tabulación manual); el ticket caduca después de un período de tiempo especificado y el usuario debe volver a autenticarse para el acceso

  • No existe cifrado para operaciones de NFS ni para protocolos auxiliares como Mount/portmapper/nlm (puede ver rutas de exportación, direcciones IP, identificadores 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

  • El 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 el acceso al montaje necesita un ticket Kerberos válido (ya sea mediante el nombre de usuario/contraseña o el cambio de tabulación manual); el ticket caduca después de un período de tiempo especificado y el usuario debe volver a autenticarse para el acceso

  • No existe cifrado para operaciones de NFS ni para protocolos auxiliares como Mount/portmapper/nlm (puede ver rutas de exportación, direcciones IP, identificadores de archivos, permisos, nombres de archivos, atime/mtime en capturas de paquetes)

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

  • Mejor que krb5p porque la carga útil NFS no está cifrada; solo la sobrecarga añadida en comparación con krb5 es la suma de comprobación de integridad. El rendimiento del krb5i no será mucho peor que el krb5, pero sí que se verá algo de degradación.

NFS: Krb5p

  • El 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 cambio manual de keytab); el ticket caduca después del período de tiempo especificado y el usuario debe volver a autenticarse para acceder

  • Todas las cargas de paquetes NFS se cifran con el contenedor GSS (no se pueden ver los identificadores de archivos, permisos, nombres de archivos, atime/mtime en capturas de paquetes).

  • Incluye comprobació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 (puede ver rutas de exportación, direcciones IP)

  • El peor rendimiento de los niveles de seguridad; krb5p debe cifrar/descifrar más.

  • Mejor rendimiento que krb5p con NFSv4.x para cargas de trabajo con un gran número de archivos.

En Cloud Volumes Service, un servidor de Active Directory configurado se utiliza como servidor Kerberos y servidor LDAP (para buscar identidades de usuario desde un esquema compatible con RFC2307). No se admiten otros servidores Kerberos o LDAP. NetApp recomienda encarecidamente utilizar LDAP para la gestión de identidades en Cloud Volumes Service. Para obtener más información acerca de cómo se muestra NFS Kerberos en capturas de paquetes, consulte la sección "“Consideraciones sobre rastreo y rastreo de paquetes”."