Descripción del cifrado de datos en Azure NetApp Files

Artículo
02/21/2024

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

Cifrado en reposo: los datos se cifran directamente 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.

Descripción del cifrado en reposo

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

El cifrado único usa el 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, consulte 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. El DNS no se cifra en tránsito en los archivos Azure NetApp. 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 utilizan la versión de 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 obtener más información sobre las consideraciones de rendimiento con el cifrado SMB, consulte Procedimientos recomendados de rendimiento 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 soporta cifrado y SMB3, entonces las conexiones SMB no están permitidas. 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 acceso de red remota que podrían permitir la ejecución remota de código entre 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) habilitada o deshabilitada para evitar el examen del tráfico.

Azure NetApp Files admite las tres formas de protección 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 sobre el rendimiento. Por ejemplo, krb5 funciona mejor que krb5i, krb5i funciona mejor que krb5p, AES-128 funciona mejor que AES-256, etc. Para obtener más información sobre el efecto en el rendimiento de NFS Kerberos en Azure NetApp Files, consulte Impacto en el rendimiento de Kerberos en volúmenes NFSv4.1 de Azure NetApp Files.

Nota:

NFS Kerberos solo se admite con NFSv4.1 en Azure NetApp Files.

En la siguiente imagen, 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 usa Kerberos 5i (krb5i; comprobación de integridad), un seguimiento muestra que los paquetes NFS no están cifrados, pero hay un contenedor GSS/Kerberos agregada al paquete que requiere que el cliente y el servidor aseguren la integridad de los datos transferidos usando 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 de seguimiento mediante un contenedor 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 obtener 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 de conexión mediante AES y TLS 1.2 a través de la firma LDAP y LDAP a través de 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 para conexiones en servidores Microsoft Active Directory que hospedan identidades UNIX para usuarios y grupos. Esta función permite verificar la integridad de los enlaces LDAP de la capa de autenticación y seguridad simple (SASL) a servidores AD que hospedan conexiones LDAP. La firma no requiere la configuración de certificados de seguridad porque usa la comunicación de 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 descubierta en los controladores de dominio de Active Directory de Windows, 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 la vinculación de canales. Si el cliente LDAP admite tokens de vinculación de canal y firma LDAP, se requieren la vinculación de canal y la firma, y las opciones de registro se establecen mediante el nuevo parche de Microsoft.

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 sobre 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. LDAP sobre SSL (LDAPS) no está admitido y la mayoría de los proveedores de servidores LDAP lo consideran heredado (el 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 convirtiera en un estándar, los proveedores de LDAP comenzaron a referirse a LDAPS como obsoleto.

LDAP sobre StartTLS usa el puerto 389 para la conexión LDAP. Una vez establecida la conexión LDAP inicial, se intercambia un OID StartTLS y se comparan los certificados; a continuación, 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 de la biblioteca LDAP en los servidores o clientes LDAP puede variar, y la funcionalidad puede o no funcionar en todos los casos.
Si se produce un error en el cifrado, StartTLS permite que la configuración vuelva a LDAP normal. LDAPS no. 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 a volver al tráfico LDAP normal si así 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 utilizar certificados autofirmados, pero para LDAP externo, utilice una autoridad de certificación. Para obtener más información sobre los certificados, vea la Diferencia entre SSL autofirmado y Autoridad 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 archivos Azure NetApp pueden configurarse para probar primero el tipo de cifrado Kerberos más potente 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, por orden de intento de autenticación: AES-256, AES-128, RC4-HMAC, DES

Nota:

No es posible deshabilitar los tipos de autenticación más débiles en Azure NetApp Files (como RC4-HMAC y DES). En su lugar, si lo desea, estos deben deshabilitarse desde el controlador de dominio para que las solicitudes de autenticación no intenten usarlas. Si RC4-HMAC está deshabilitado en los controladores de dominio, el cifrado AES debe estar habilitado en Azure NetApp Files para una funcionalidad adecuada.

Compartir a través de

Descripción del cifrado de datos en Azure NetApp Files

Descripción del cifrado en reposo