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 a nivel de red como se describe en la "Cifrado en tránsito" documentación de Google. Como se mencionó en la sección «Arquitectura de NetApp Volumes de Google Cloud», Google Cloud NetApp Volumes se entrega a partir de un proyecto de productor de PSA controlado por NetApp.

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

Aunque la ruta de datos de NetApp Volumes-Performance no está totalmente cifrada en la capa de red, NetApp y Google usan una combinación de "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 Volumes NetApp Volumes-Performance 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.

NetApp Volumes de Google Cloud admite los 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, NetApp Volumes-Performance ofrece autenticación Kerberos como se describe en "RFC7530". Puede habilitar Kerberos por volumen.

El tipo de cifrado disponible más actual para Kerberos es AES-256-CTS-HMAC-SHA1. NetApp Volumes 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 los volúmenes de NetApp de Google Cloud, se utiliza un servidor de Active Directory configurado como servidor Kerberos y servidor LDAP (para buscar identidades de usuario de un esquema compatible con RFC2307). No se admiten otros servidores Kerberos o LDAP. NetApp recomienda utilizar LDAP para la gestión de identidades en Google Cloud NetApp Volumes. Para obtener información sobre cómo se muestra el Kerberos de NFS en las capturas de paquetes, consulte la sección link:ncvs-gc-cloud-volumes-service-architecture.html#consideraciones sobre el sniffing/trace de paquetes[«consideraciones sobre el sniffing/trace de paquetes»].