Descripción del cifrado de datos en Azure NetApp Files

2025-05-06

Azure NetApp Files cifra los datos a través de dos métodos diferentes:

Cifrado en reposo: Los datos se cifran en el lugar utilizando estándares compatibles con FIPS 140-2.
Cifrado en tránsito: los datos se cifran en tránsito o a través de la conexión, ya que se transfieren entre el cliente y el servidor.

Comprenda el cifrado en reposo

Los datos en reposo en Azure NetApp Files se pueden cifrar de dos maneras:

El cifrado único utiliza cifrado basado en software para volúmenes de Azure NetApp Files.
El cifrado doble agrega cifrado de nivel de hardware en la capa de dispositivo de almacenamiento físico.

Azure NetApp Files usa CryptoMod estándar para generar claves de cifrado AES-256. CryptoMod aparece en la lista de módulos validados de CMVP FIPS 140-2; para obtener más información, vea FIPS 140-2 Cert #4144. Las claves de cifrado están asociadas a los volúmenes y pueden ser claves administradas por la plataforma de Microsoft o claves administradas por el cliente.

Descripción del cifrado de datos en tránsito

Además de proteger los datos en reposo, Azure NetApp Files puede proteger los datos cuando están en tránsito entre puntos de conexión. El método de cifrado utilizado depende del protocolo o la característica. DNS no está cifrado durante su transmisión en Azure NetApp Files. Siga leyendo para obtener información sobre el cifrado SMB y NFS, LDAP y la replicación de datos en Azure NetApp Files.

Cifrado de SMB

Los clientes SMB de Windows que usan la versión del protocolo SMB3.x admiten de forma nativa el cifrado SMB. El cifrado SMB se realiza de un extremo a otro y cifra toda la conversación SMB mediante conjuntos criptográficos AES-256-GCM/AES-128-GCM y AES-256-CCM/AES-128-CCM.

El cifrado SMB no es necesario para volúmenes de Azure NetApp Files, pero se puede usar para mayor seguridad. El cifrado SMB agrega una sobrecarga de rendimiento. Para más información sobre las consideraciones de rendimiento con el cifrado SMB, consulte Procedimientos recomendados de rendimiento de SMB para Azure NetApp Files.

Requerir cifrado para conexiones SMB

Azure NetApp Files proporciona una opción para aplicar el cifrado en todas las conexiones SMB. Al aplicar el cifrado no se permite la comunicación SMB sin cifrar y se utiliza SMB3 y posteriores para las conexiones SMB. El cifrado se realiza mediante el cifrado AES y cifra todos los paquetes SMB. Para que esta característica funcione correctamente, los clientes SMB deben admitir el cifrado SMB. Si el cliente SMB no admite el cifrado y SMB3, no se permiten las conexiones SMB. Si esta opción está habilitada, todos los recursos compartidos que tienen la misma dirección IP requieren cifrado, lo que invalida la configuración de la propiedad del recurso compartido SMB para el cifrado.

Como alternativa, el cifrado se puede establecer en el nivel de recurso compartido individual de un volumen de Azure NetApp Files.

Protección UNC

En 2015, Microsoft introdujo la protección UNC (MS15-011 y MS15-014) para abordar las vulnerabilidades de la ruta de red remota que podrían permitir la ejecución remota de código a través de recursos compartidos SMB. Para obtener más información, consulte MS15-011 & MS15-014: Protección de la directiva de grupo.

La protección UNC ofrece tres opciones para proteger las rutas UNC:

RequireMutualAuthentication – Autenticación de identidad requerida/no necesaria para bloquear ataques de suplantación de identidad.
RequireIntegrity – Comprobación de integridad requerida/no necesaria para bloquear ataques de manipulación.
RequirePrivacy – Privacidad (cifrado total de paquetes SMB) activada/desactivada para evitar la intercepción del tráfico.

Azure NetApp Files admite las tres formas de endurecimiento de UNC.

NFS Kerberos

Azure NetApp Files también proporciona la capacidad de cifrar conversaciones NFSv4.1 a través de la autenticación Kerberos mediante conjuntos criptográficos AES-256-GCM/AES-128-GCM y AES-256-CCM/AES-128-CCM.

Con NFS Kerberos, Azure NetApp Files admite tres tipos de seguridad diferentes:

Kerberos 5 (krb5): solo autenticación inicial; requiere un intercambio de vales de Kerberos o inicio de sesión de usuario para acceder a la exportación NFS. Los paquetes NFS no están cifrados.
Kerberos 5i (krb5i): comprobación inicial de la autenticación e integridad; requiere un intercambio de vales kerberos/inicio de sesión de usuario para acceder a la exportación de NFS y agrega comprobaciones de integridad a cada paquete NFS para evitar ataques "man-in-the-middle" (MITM).
Kerberos 5p (krb5p): autenticación inicial, comprobación de integridad y privacidad; requiere un intercambio de vales de Kerberos/inicio de sesión de usuario para acceder a la exportación de NFS, realiza comprobaciones de integridad y aplica un contenedor GSS a cada paquete NFS para cifrar su contenido.

Cada nivel de cifrado kerberos tiene un efecto en el rendimiento. A medida que los tipos de cifrado y los tipos de seguridad incorporan métodos más seguros, aumenta el efecto de rendimiento. Por ejemplo, krb5 funciona mejor que krb5i, krb5i funciona mejor que krb5p, AES-128 funciona mejor que AES-256, etc. Para más información sobre el efecto de rendimiento de Kerberos NFS en Azure NetApp Files, consulte Impacto del rendimiento de Kerberos en volúmenes NFSv4.1 de Azure NetApp Files.

Nota:

En Azure NetApp Files, NFS Kerberos es compatible solo con NFSv4.1.

En la imagen siguiente, se usa Kerberos 5 (krb5); solo se cifra la solicitud de autenticación inicial (la adquisición de vales o de inicio de sesión). El resto del tráfico NFS llega en texto sin formato.

Cuando se utiliza Kerberos 5i (krb5i; comprobación de integridad), un seguimiento muestra que los paquetes NFS no están cifrados, pero se añade un contenedor GSS/Kerberos al paquete que requiere que el cliente y el servidor garanticen la integridad de los datos transferidos mediante una suma de comprobación.

Kerberos 5p (privacidad; krb5p) proporciona cifrado de un extremo a otro de todo el tráfico NFS, como se muestra en la imagen del rastreo mediante un envoltorio GSS/Kerberos. Este método crea la mayor sobrecarga de rendimiento debido a la necesidad de procesar cada cifrado del paquete NFS.

Replicación de datos

En Azure NetApp Files, puede replicar volúmenes completos entre zonas o regiones de Azure para proporcionar protección de datos. Dado que el tráfico de replicación reside en la nube de Azure, las transferencias tienen lugar en la infraestructura de red segura de Azure, que está limitada en el acceso para evitar ataques de detección de paquetes y ataques de tipo "man in the middle" (interceptación o suplantación entre puntos de conexión de comunicación). Además, el tráfico de replicación se cifra mediante estándares DE TLS 1.2 compatibles con FIPS 140-2. Para más información, consulte Preguntas más frecuentes sobre seguridad.

Cifrado LDAP

Normalmente, el tráfico de búsqueda y enlace LDAP pasa por el cable en texto plano, lo que significa que cualquiera con acceso para espiar paquetes de red puede obtener información del servidor LDAP, como nombres de usuario, Id. numéricos, pertenencia a grupos, etc. Esta información puede utilizarse para suplantar a usuarios, enviar correos electrónicos para ataques de suplantación de identidad, etc.

Para proteger las comunicaciones LDAP de ser interceptadas y leídas, el tráfico LDAP puede aprovechar el cifrado durante la transmisión utilizando AES y TLS 1.2, mediante la firma LDAP y LDAP sobre TLS, respectivamente. Para obtener más información sobre cómo configurar estas opciones, consulte Creación y administración de conexiones de Active Directory.

Firma LDAP

La firma LDAP es específica de las conexiones en servidores de Microsoft Active Directory que hospedan identidades UNIX para usuarios y grupos. Esta funcionalidad permite la comprobación de integridad para el Nivel de seguridad y autenticación simples (SASL) a servidores de AD que hospedan conexiones LDAP. La configuración de certificados de seguridad no es necesaria para la firma, porque utiliza comunicación GSS-API con los servicios del Centro de distribución de claves Kerberos (KDC) de Active Directory. La firma LDAP solo comprueba la integridad de un paquete LDAP; no cifra la carga del paquete.

La firma LDAP también se puede configurar desde el lado del servidor de Windows a través de la directiva de grupo para que sea oportunista con la firma LDAP (ninguna, se admite si la solicita el cliente) o para que sea obligatoria (obligatoria). La firma LDAP puede agregar cierta sobrecarga de rendimiento al tráfico LDAP que normalmente no es notable para los usuarios finales.

Windows Active Directory también permite usar la firma y el sellado LDAP (cifrado de un extremo a otro de paquetes LDAP). Azure NetApp Files no admite esta característica.

Enlace de canal LDAP

Debido a una vulnerabilidad de seguridad detectada en los controladores de dominio de Windows Active Directory, se cambió una configuración predeterminada para los servidores de Windows. Para obtener más información, consulte Microsoft Security Advisory ADV190023.

Básicamente, Microsoft recomienda que los administradores habiliten la firma LDAP junto con el enlace de canal. Si el cliente LDAP admite tokens de enlace de canal y firma LDAP, se requieren enlaces de canal y firma, y las nuevas revisiones de Microsoft establecen las opciones del Registro.

Azure NetApp Files, de forma predeterminada, admite el enlace de canal LDAP de forma oportunista, lo que significa que el enlace de canal LDAP se usa cuando el cliente lo admite. Si no admite/envía el enlace de canales, la comunicación sigue estando permitida y el enlace de canales no se aplica.

LDAP a través de SSL (puerto 636)

El tráfico LDAP en Azure NetApp Files pasa por el puerto 389 en todos los casos. Este puerto no se puede modificar. No se admite LDAP a través de SSL (LDAPS) y la mayoría de los proveedores de servidores LDAP lo consideran obsoleto (RFC 1777 se publicó en 1995). Si desea usar el cifrado LDAP con Azure NetApp Files, use LDAP a través de TLS.

LDAP sobre StartTLS

LDAP sobre StartTLS se introdujo con RFC 2830 en 2000 y se combinó en el estándar LDAPv3 con RFC 4511 en 2006. Después de que StartTLS se hizo un estándar, los proveedores LDAP comenzaron a hacer referencia a LDAPS como en desuso.

LDAP a través de StartTLS usa el puerto 389 para la conexión LDAP. Una vez realizada la conexión LDAP inicial, se intercambia un OID startTLS y se comparan los certificados; después, todo el tráfico LDAP se cifra mediante TLS. La captura de paquetes que se muestra a continuación muestra el enlace LDAP, el protocolo de enlace StartTLS y el tráfico LDAP cifrado por TLS posterior.

Hay dos diferencias principales entre LDAPS e StartTLS:

StartTLS forma parte del estándar LDAP; LDAPS no lo es. Como resultado, la compatibilidad con la biblioteca LDAP en los servidores o clientes LDAP puede variar y la funcionalidad podría funcionar o no en todos los casos.
Si se produce un error en el cifrado, StartTLS permite que la configuración vuelva a LDAP normal. LDAPS no lo hace. Como resultado, StartTLS ofrece cierta flexibilidad y resistencia, pero también presenta riesgos de seguridad si está mal configurado.

Consideraciones de seguridad con LDAP sobre StartTLS

StartTLS permite a los administradores revertir al tráfico LDAP normal si lo desean. Con fines de seguridad, la mayoría de los administradores LDAP no lo permiten. Las siguientes recomendaciones para StartTLS pueden ayudar a proteger la comunicación LDAP:

Asegúrese de que StartTLS está habilitado y de que los certificados están configurados.
Para entornos internos, puede usar certificados autofirmados, pero para LDAP externo, use una entidad de certificación. Para obtener más información sobre los certificados, vea la diferencia entre SSL autofirmado y entidad de certificación.
Evite consultas LDAP y enlaces que no usen StartTLS. De forma predeterminada, Active Directory deshabilita los enlaces anónimos.

Conexión de seguridad de Active Directory

Las conexiones de Active Directory con volúmenes de Azure NetApp Files se pueden configurar para probar primero el tipo de cifrado Kerberos más seguro disponible: AES-256. Cuando el cifrado AES está habilitado, las comunicaciones del controlador de dominio (como los restablecimientos de contraseña programados del servidor SMB) usan el tipo de cifrado más alto disponible admitido en los controladores de dominio. Azure NetApp Files admite los siguientes tipos de cifrado para las comunicaciones del controlador de dominio, en orden de intento de autenticación: AES-256, AES-128, RC4-HMAC, DES