Comprendre le chiffrement des données dans Azure NetApp Files
Azure NetApp Files chiffre les données en utilisant deux méthodes différentes :
- Chiffrement au repos: Les données sont chiffrées sur place à l’aide de normes conformes FIPS 140-2.
- Chiffrement en transit: Les données sont chiffrées en transit, ou sur le fil, lorsqu’elles sont transférées entre le client et le serveur.
Comprendre le chiffrement au repos
Les données au repos dans Azure NetApp Files peuvent être chiffrées de deux manière :
- Le chiffrement simple utilise un chiffrement logiciel pour les volumes Azure NetApp Files.
- Le double chiffrement ajoute un chiffrement au niveau du matériel à la couche d’appareil de stockage physique.
Azure NetApp Files utilise CryptoMod standard pour générer des clés de chiffrement AES-256. Le CryptoMod figure sur la liste des modules validés FIPS 140-2 CMVP. Pour plus d’informations, consultez FIPS 140-2 Cert #4144. Les clés de chiffrement sont associées aux volumes et peuvent être des clés gérées par la plateforme Microsoft ou des clés gérées par le client.
Comprendre le chiffrement des données en transit
En plus de sécuriser les données au repos, Azure NetApp Files peut sécuriser les données lorsqu’elles sont en transit entre les points de terminaison. La méthode de chiffrement utilisée dépend du protocole ou de la fonctionnalité. Le DNS n’est pas chiffré en transit dans les fichiers Azure NetApp. Poursuivez votre lecture pour en savoir plus sur le chiffrement SMB et NFS, LDAP et la réplication des données dans Azure NetApp Files.
Chiffrement SMB
Les clients SMB de Windows qui utilisent la version du protocole SMB3.x supportent le chiffrement SMB en natif. Le chiffrement SMB est effectué de bout en bout et chiffre l’intégralité de la conversation SMB à l’aide des suites de chiffrement AES-256-GCM/AES-128-GCM et AES-256-CCM/AES-128-CCM.
Le chiffrement SMB n’est pas nécessaire pour les volumes Azure NetApp Files, mais il peut être utilisé pour plus de sécurité. Le chiffrement SMB entraîne une surcharge des performances. Pour en savoir plus sur les considérations relatives aux performances avec le chiffrement SMB, consultez Meilleures pratiques en matière de performances SMB pour Azure NetApp Files.
Exiger le chiffrement pour les connexions SMB
Azure NetApp Files propose une option permettant d’appliquer le chiffrement à toutes les connexions SMB. L’application du chiffrement interdit les communications SMB non chiffrées et utilise SMB3 et les versions ultérieures pour les connexions SMB. Le chiffrement est effectué à l’aide du chiffrement AES et chiffre tous les paquets SMB. Pour assurer le bon fonctionnement de cette fonctionnalité, les clients SMB doivent prendre en charge le chiffrement SMB. Si le client SMB ne prend pas en charge le chiffrement et SMB3, les connexions SMB ne sont pas autorisées. Si cette option est activée, tous les partages qui ont la même adresse IP doivent être chiffrés, ce qui annule le paramètre de chiffrement de la propriété de partage SMB.
Chiffrement au niveau du partage SMB
Vous pouvez également définir le chiffrement au niveau du partage individuel d’un volume Azure NetApp Files.
Renforcement de l’UNC
En 2015, Microsoft a introduit le renforcement UNC (MS15-011 et MS15-014) pour résoudre les vulnérabilités de chemin d’accès réseau distant qui pourraient permettre l’exécution de code à distance sur les partages SMB. Pour plus d’informations, consultez MS15-011 et MS15-014 : Renforcement de la stratégie de groupe.
Le renforcement UNC offre trois options pour sécuriser les chemins d’accès UNC :
RequireMutualAuthentication– Authentification de l’identité requise/non requise pour bloquer les attaques par usurpation d’identité.RequireIntegrity– Vérification de l’intégrité requise/non requise pour bloquer les attaques par falsification.RequirePrivacy– Confidentialité (chiffrement total des paquets SMB) activée/désactivée pour empêcher l’espionnage du trafic.
Azure NetApp Files prend en charge les trois formes de renforcement UNC.
NFS Kerberos
Azure NetApp Files permet également de chiffrer les conversations NFSv4.1 via l’authentification Kerberos à l’aide des suites de chiffrement AES-256-GCM/AES-128-GCM et AES-256-CCM/AES-128-CCM.
Avec NFS Kerberos, Azure NetApp Files prend en charge trois types de sécurité différents :
- Kerberos 5 (
krb5) – Uniquement l’authentification initiale ; nécessite un échange de tickets Kerberos/une connexion de l’utilisateur pour accéder à l’exportation NFS. Les paquets NFS ne sont pas chiffrés. - Kerberos 5i (
krb5i) – Authentification initiale et vérification de l’intégrité ; nécessite un échange de tickets Kerberos/une ouverture de session de l’utilisateur pour accéder à l’exportation NFS et ajoute des vérifications d’intégrité à chaque paquet NFS pour empêcher les attaques de type « attaque de l’intercepteur» (MITM). - Kerberos 5p (
krb5p) – Authentification initiale, vérification de l’intégrité et confidentialité ; nécessite un échange de tickets Kerberos/une ouverture de session de l’utilisateur pour accéder à l’exportation NFS, effectue des vérifications d’intégrité et applique une enveloppe GSS à chaque paquet NFS pour en chiffrer le contenu.
Chaque niveau de chiffrement Kerberos a un effet sur les performances. Au fur et à mesure que les types de chiffrement et les types de sécurité intègrent des méthodes plus sûres, l’effet sur les performances est plus important. Par exemple, krb5 est plus performant que krb5i, krb5i est plus performant que krb5p, AES-128 est plus performant que AES-256, et ainsi de suite. Pour plus d’informations sur l’effet de performances de NFS Kerberos dans Azure NetApp Files, consultez impact sur les performances de Kerberos sur les volumes NFSv4.1 d’Azure NetApp Files.
Remarque
NFS Kerberos est pris en charge uniquement avec NFSv4.1 dans Azure NetApp Files.
Dans l’image suivante, Kerberos 5 (krb5) est utilisé ; seule la demande d’authentification initiale (l’acquisition de connexion/ticket) est chiffrée. Tout le reste du trafic NFS arrive en texte brut.
Lors de l’utilisation de Kerberos 5i (krb5i; vérification de l’intégrité), une trace montre que les paquets NFS ne sont pas chiffrés, mais qu’il y a une enveloppe GSS/Kerberos ajoutée au paquet qui requiert que le client et le serveur garantissent l’intégrité des données transférées à l’aide d’une somme de contrôle.
Kerberos 5p (confidentialité ; krb5p) assure le chiffrement de bout en bout de tout le trafic NFS, comme indiqué dans l’image de trace, à l’aide d’un wrapper GSS/Kerberos. Cette méthode génère le plus de surcharge de performance en raison de la nécessité de traiter le chiffrement de chaque paquet NFS.
Réplication des données
Dans Azure NetApp Files, vous pouvez répliquer des volumes entiers entre les zones ou les régions d’Azure pour assurer la protection des donnée. Étant donné que le trafic de réplication réside dans le cloud Azure, les transferts se produisent dans l’infrastructure réseau Azure sécurisée, dont l’accès est limité afin d’empêcher l’espionnage de paquets et les attaques de l’intercepteur (écoute ou usurpation d’identité entre les points de terminaison de communication). En outre, le trafic de réplication est chiffré à l’aide des normes TLS 1.2 conformes à la norme FIPS 140-2. Pour plus d’informations, consultez FAQ sur la sécurité.
Chiffrement LDAP
Normalement, la recherche LDAP et le trafic de liaison passent par le réseau en texte brut, ce qui signifie que toute personne qui a accès aux paquets du réseau peut intercepter des informations du serveur LDAP, telles que les noms d’utilisateur, les identifiants numériques, l’appartenance à un groupe, etc. Ces informations peuvent ensuite être utilisées pour usurper l’identité des utilisateurs, envoyer des e-mails dans le cadre d’attaques par hameçonnage, etc.
Pour protéger les communications LDAP contre l’interception et la lecture, le trafic LDAP peut bénéficier d’un chiffrement sur le fil utilisant AES et TLS 1.2 via la signature LDAP et LDAP sur TLS, respectivement. Pour plus d’informations sur la configuration de ces options, consultez Créer et gérer des connexions Active Directory.
Signature LDAP
La signature LDAP est spécifique aux connexions sur les serveurs Microsoft Active Directory qui hébergent des identités UNIX pour les utilisateurs et les groupes. Cette fonctionnalité permet de vérifier l’intégrité des liaisons LDAP SASL (Simple Authentication and Security Layer) avec les serveurs AD hébergeant des connexions LDAP. La signature ne nécessite pas la configuration de certificats de sécurité car elle utilise la communication GSS-API avec les services Kerberos Key Distribution Center (KDC) d’Active Directory. La signature LDAP vérifie uniquement l’intégrité d’un paquet LDAP ; elle ne chiffre pas la charge utile du paquet.
La signature LDAP peut également être configurée du côté serveur Windows via la stratégie de groupe pour être opportuniste avec la signature LDAP (aucune – prise en charge si demandée par le client) ou pour appliquer la signature LDAP (obligatoire). La signature LDAP peut ajouter une surcharge de performances au trafic LDAP qui n’est généralement pas visible pour les utilisateurs finaux.
Windows Active Directory vous permet également d’utiliser la signature ET le scellement LDAP (chiffrement de bout en bout des paquets LDAP). Azure NetApp Files ne prend pas en charge cette fonctionnalité.
Liaison du canal LDAP
Un paramètre par défaut a été modifié pour les serveurs Windows en raison d’une vulnérabilité de sécurité découverte dans les contrôleurs de domaine Windows Active Directory. Pour plus de détails, consultez Avis de sécurité de Microsoft ADV190023.
Microsoft recommande essentiellement aux administrateurs d’activer la signature LDAP en même temps que la liaison de canal. Si le client LDAP prend en charge les jetons de liaison de canal et la signature LDAP, la liaison de canal et la signature sont nécessaires, et les options de registre sont définies par le nouveau correctif de Microsoft.
Par défaut, Azure NetApp Files prend en charge la liaison de canal LDAP de manière opportuniste, ce qui signifie que la liaison de canal LDAP est utilisée lorsque le client est compatible. S’il ne prend pas en charge ou n’envoie pas de liaison de canal, la communication est toujours autorisée et la liaison de canal n’est pas appliquée.
LDAP sur SSL (port 636)
Dans tous les cas, le trafic LDAP dans Azure NetApp Files passe par le port 389. Il n’est pas possible de modifier ce port. LDAP sur SSL (LDAPS) n’est pas pris en charge et est considéré comme hérité par la plupart des fournisseurs de serveurs LDAP (RFC 1777 a été publié en 1995). Si vous souhaitez utiliser le chiffrement LDAP avec Azure NetApp Files, utilisez LDAP sur TLS.
LDAP sur StartTLS
LDAP sur StartTLS a été introduit avec RFC 2830 en 2000 et a été intégré dans la norme LDAPv3 avec RFC 4511 en 2006. Après que StartTLS est devenu une norme, les fournisseurs LDA ont commencé à considérer que LDAPS était obsolète.
LDAP sur StartTLS utilise le port 389 pour la connexion LDAP. Une fois la connexion LDAP initiale établie, un OID StartTLS est échangé et les certificats sont comparés ; ensuite, tout le trafic LDAP est chiffré à l’aide de TLS. La capture de paquets illustrée ci-dessous montre la liaison LDAP, l’établissement d’une liaison StartTLS et le trafic LDAP chiffré par TLS qui s’ensuit.
Il existe deux différences principales entre LDAPS et StartTLS :
- StartTLS est une composante de la norme LDAP ; LDAPS ne l’est pas. Par conséquent, la prise en charge de la bibliothèque LDAP par les serveurs ou les clients LDAP peut varier, et la fonctionnalité peut ne pas fonctionner dans certains cas.
- En cas d’échec du chiffrement, StartTLS permet à la configuration de revenir au protocole LDAP normal. Ce n’est pas le cas pour LDAPS. Par conséquent, StartTLS offre une certaine flexibilité et résilience, mais présente également des risques de sécurité s’il est mal configuré.
Considérations de sécurité avec LDAP sur StartTLS
StartTLS permet aux administrateurs de revenir au trafic LDAP normal s’ils le souhaitent. Pour des raisons de sécurité, la plupart des administrateurs LDAP ne l’autorisent pas. Les suggestions suivantes pour StartTLS peuvent contribuer à sécuriser la communication LDAP :
- Assurez-vous que StartTLS est activé et que les certificats sont configurés.
- Pour les environnements internes, vous pouvez utiliser des certificats auto-signés, mais pour le LDAP externe, vous devez utiliser une autorité de certification. Pour plus d’informations sur les certificats, consultez Différence entre SSL autosigné et l’autorité de certification.
- Empêcher les requêtes LDAP et les liaisons qui n’utilisent pas StartTLS. Par défaut, Active Directory désactive les liaisons anonymes.
Connexion de sécurité Active Directory
Les connexions Active Directory avec des volumes Azure NetApp Files peuvent être configurées pour commencer par essayer d’utiliser le type de chiffrement Kerberos disponible le plus fort : AES-256. Lorsque le chiffrement AES est activé, les communications des contrôleurs de domaine (telles que les réinitialisations planifiées des mots de passe des serveurs SMB) utilisent le type de chiffrement disponible le plus fort pris en charge par les contrôleurs de domaine. Pour les communications avec les contrôleurs de domaine, Azure NetApp Files prend en charge les types de chiffrement suivants, dans l’ordre des tentatives d’authentification : AES-256, AES-128, RC4-HMAC, DES
Remarque
Il n’est pas possible de désactiver les types d’authentification plus faibles dans Azure NetApp Files (tels que RC4-HMAC et DES). Au lieu de cela, si vous le souhaitez, ils doivent être désactivés à partir du contrôleur de domaine afin que les demandes d’authentification ne tentent pas de les utiliser. Si RC4-HMAC est désactivé sur les contrôleurs de domaine, le chiffrement AES doit être activé dans Azure NetApp Files pour fonctionner correctement.