Partager via

Considérations relatives à la mise en réseau Azure Files

Vous pouvez accéder à vos partages de fichiers Azure via le point de terminaison accessible par Internet public, sur un ou plusieurs points de terminaison privés sur votre ou vos réseaux, ou en mettant en cache votre partage de fichiers Azure local avec Azure File Sync (partages de fichiers SMB uniquement). Cet article se concentre sur la configuration d’Azure Files pour un accès direct via des points de terminaison publics et/ou privés. Pour savoir comment mettre en cache votre partage de fichiers Azure local avec Azure File Sync, consultez Présentation d’Azure File Sync.

Nous vous recommandons de lire la planification d’un déploiement Azure Files avant de lire ce guide.

L’accès direct à un partage de fichiers Azure nécessite souvent une réflexion supplémentaire en ce qui concerne la mise en réseau :

  • Les partages de fichiers SMB communiquent sur le port 445, que de nombreuses organisations et fournisseurs de services Internet (ISP) bloquent pour le trafic sortant (Internet). Cette pratique provient d’instructions de sécurité héritées sur les versions déconseillées et non internet sécurisées du protocole SMB. Bien que SMB 3.x soit un protocole internet sécurisé, les stratégies organisationnelles ou ISP ne peuvent pas être modifiées. Par conséquent, le montage d’un partage de fichiers SMB nécessite souvent une configuration réseau supplémentaire à utiliser en dehors d’Azure.

  • Les partages de fichiers NFS s’appuient sur l’authentification au niveau du réseau et sont dès lors uniquement accessibles via des réseaux restreints. L’utilisation d’un partage de fichiers NFS nécessite systématiquement un certain niveau de configuration réseau.

La configuration de points de terminaison publics et privés pour Azure Files est effectuée sur l’objet de gestion de niveau supérieur pour Azure Files, le compte de stockage Azure. Un compte de stockage est une construction de gestion qui représente un pool de stockage partagé dans lequel vous pouvez déployer plusieurs partages de fichiers Azure, ainsi que les ressources de stockage pour d’autres services de stockage Azure, tels que des conteneurs d’objets blob ou des files d’attente.

Cette vidéo montre comment exposer directement et de façon sécurisée les partages de fichiers Azure aux travailleurs de l’information et aux applications, en cinq étapes simples. Les sections ci-dessous fournissent des liens et un contexte supplémentaire à la documentation référencée dans la vidéo. Notez qu'Azure Active Directory est désormais Microsoft Entra ID. Si vous souhaitez obtenir d’autres informations, consultez Nouveau nom pour Azure AD.

S’applique à

Type de partage de fichiers PME Système de fichiers en réseau (NFS)
Partages de fichiers Standard (GPv2), LRS/ZRS Oui Non
Partages de fichiers Standard (GPv2), GRS/GZRS Oui Non
Partages de fichiers Premium (FileStorage), LRS/ZRS Oui Oui

Transfert sécurisé

Par défaut, les comptes de stockage Azure nécessitent un transfert sécurisé, que les données soient accessibles via le point de terminaison public ou privé. Pour Azure Files, le paramètre de transfert sécurisé requis est appliqué pour tous les accès au protocole aux données stockées sur des partages de fichiers Azure, notamment SMB, NFS et FileREST. Vous pouvez désactiver le paramètre de transfert sécurisé requis pour autoriser le trafic non chiffré.

Les protocoles SMB, NFS et FileREST ont un comportement légèrement différent en ce qui concerne le paramètre de transfert sécurisé requis :

  • Lorsque le transfert sécurisé requis est activé sur un compte de stockage, tous les partages de fichiers SMB de ce compte de stockage nécessitent le protocole SMB 3.x avec AES-128-CCM, AES-128-GCM ou les algorithmes de chiffrement AES-256-GCM, en fonction de la négociation de chiffrement disponible/requise entre le client SMB et Azure Files. Vous pouvez activer/désactiver les algorithmes de chiffrement SMB autorisés via les paramètres de sécurité SMB. La désactivation du paramètre de transfert sécurisé requis active les montages SMB 2.1 et SMB 3.x sans chiffrement.

  • Les partages de fichiers Azure NFS utilisent le package utilitaire AZNFS pour simplifier les montages chiffrés en installant et en configurant Stunnel (wrapper TLS open source) sur le client. Consultez Chiffrement en transit pour les partages de fichiers Azure NFS.

  • Lorsque le transfert sécurisé est nécessaire, le protocole FileREST peut uniquement être utilisé avec HTTPS.

Remarque

La communication entre un client et un compte de stockage Azure est chiffrée à l’aide du protocole TLS (Transport Layer Security). Azure Files s’appuie sur une implémentation Windows de SSL qui n’est pas basée sur OpenSSL et n’est donc pas exposée aux vulnérabilités liées à OpenSSL. Les utilisateurs qui préfèrent maintenir la flexibilité entre les connexions TLS et non TLS sur le même compte de stockage doivent désactiver le transfert sécurisé requis.

Point de terminaison public

Le point de terminaison public pour les partages de fichiers Azure au sein d’un compte de stockage est un point de terminaison exposé sur Internet. Le point de terminaison public est le point de terminaison par défaut d’un compte de stockage, mais il peut être désactivé si vous le souhaitez.

Les protocoles SMB, NFS et FileREST peuvent tous utiliser le point de terminaison public. Toutefois, chacun a des règles légèrement différentes pour l’accès :

  • Les partages de fichiers SMB sont accessibles partout dans le monde via le point de terminaison public du compte de stockage avec SMB 3.x avec chiffrement. Cela signifie que les demandes authentifiées, telles que les demandes autorisées par l’identité d’ouverture de session d’un utilisateur, peuvent provenir en toute sécurité à l’intérieur ou à l’extérieur de la région Azure. Si SMB 2.1 ou SMB 3.x sans chiffrement est souhaité, deux conditions doivent être remplies :

    1. Le paramètre de transfert sécurisé requis du compte de stockage doit être désactivé.
    2. La demande doit provenir de l’intérieur de la région Azure. Comme mentionné précédemment, les requêtes SMB chiffrées sont autorisées n’importe où, à l’intérieur ou à l’extérieur de la région Azure.

  • Les partages de fichiers NFS sont accessibles à partir du point de terminaison public du compte de stockage si et uniquement si le point de terminaison public du compte de stockage est limité à des réseaux virtuels spécifiques à l’aide de points de terminaison de service. Pour plus d’informations sur les points de terminaison de service, consultez les paramètres de pare-feu de point de terminaison public.

  • FileREST est accessible via le point de terminaison public. Si le transfert sécurisé est requis, seules les requêtes HTTPS sont acceptées. Si le transfert sécurisé est désactivé, les requêtes HTTP sont acceptées par le point de terminaison public, quelle que soit l’origine.

Paramètres de pare-feu de point de terminaison public

Le pare-feu du compte de stockage limite l’accès au point de terminaison public d’un compte de stockage. À l’aide du pare-feu du compte de stockage, vous pouvez restreindre l’accès à certaines adresses IP/plages d’adresses IP, à des réseaux virtuels spécifiques ou désactiver entièrement le point de terminaison public.

Lorsque vous limitez le trafic du point de terminaison public à un ou plusieurs réseaux virtuels, vous utilisez une fonctionnalité du réseau virtuel appelé points de terminaison de service. Les demandes dirigées vers le point de terminaison de service d’Azure Files vont toujours à l’adresse IP publique du compte de stockage ; Toutefois, la couche réseau effectue une vérification supplémentaire de la demande pour vérifier qu’elle provient d’un réseau virtuel autorisé. Les protocoles SMB, NFS et FileREST prennent tous en charge les points de terminaison de service. Contrairement à SMB et FileREST, toutefois, les partages de fichiers NFS sont accessibles uniquement avec le point de terminaison public via l’utilisation d’un point de terminaison de service.

Pour en savoir plus sur la configuration du pare-feu de compte de stockage, consultez configurer des pare-feu de stockage Azure et des réseaux virtuels.

Routage réseau de point de terminaison public

Azure Files prend en charge plusieurs options de routage réseau. L’option par défaut, routage Microsoft, fonctionne avec toutes les configurations d’Azure Files. L’option de routage Internet ne prend pas en charge les scénarios de jonction de domaine AD ou Azure File Sync.

Points de terminaison privés

Outre le point de terminaison public par défaut d’un compte de stockage, Azure Files offre la possibilité d’avoir un ou plusieurs points de terminaison privés. Un point de terminaison privé est un point de terminaison accessible uniquement au sein d’un réseau virtuel Azure. Lorsque vous créez un point de terminaison privé pour votre compte de stockage, votre compte de stockage obtient une adresse IP privée à partir de l’espace d’adressage de votre réseau virtuel, comme la façon dont un serveur de fichiers local ou un appareil NAS reçoit une adresse IP dans l’espace d’adressage dédié de votre réseau local.

Un point de terminaison privé individuel est associé à un sous-réseau de réseau virtuel Azure spécifique. Un compte de stockage peut avoir des points de terminaison privés dans plusieurs réseaux virtuels.

L’utilisation de points de terminaison privés avec Azure Files vous permet de :

  • Établir une connexion sécurisée avec vos partages de fichiers Azure à partir de réseaux locaux en utilisant une connexion VPN ou ExpressRoute avec un peering privé.
  • Sécuriser vos partages de fichiers Azure en configurant le pare-feu du compte de stockage de façon à bloquer toutes les connexions sur le point de terminaison public. Par défaut, la création d’un point de terminaison privé ne bloque pas les connexions au point de terminaison public.
  • Renforcer la sécurité du réseau virtuel en bloquant l’exfiltration des données du réseau virtuel (et des limites du peering).

Pour créer un point de terminaison privé, consultez Configuration de points de terminaison privés pour Azure Files.

Tunneling du trafic sur un réseau privé virtuel ou ExpressRoute

Pour utiliser des points de terminaison privés pour accéder aux partages de fichiers SMB ou NFS à partir d’un emplacement local, vous devez établir un tunnel réseau entre votre réseau local et Azure. Un réseau virtuel ou un réseau virtuel est similaire à un réseau local traditionnel. Comme un compte de stockage Azure ou une machine virtuelle Azure, un réseau virtuel est une ressource Azure déployée dans un groupe de ressources.

Azure Files prend en charge les mécanismes suivants pour tunneliser le trafic entre vos stations de travail et serveurs locaux et les partages de fichiers Azure SMB/NFS :

  • Passerelle VPN Azure : une passerelle VPN est un type spécifique de passerelle de réseau virtuel utilisé pour envoyer du trafic chiffré d’un réseau virtuel Azure vers un autre emplacement (par exemple local) via Internet. Une passerelle VPN Azure est une ressource Azure qui peut être déployée dans un groupe de ressources en même temps qu’un compte de stockage ou d’autres ressources Azure. Les passerelles VPN exposent deux types de connexions différents :
  • ExpressRoute, qui vous permet de créer un itinéraire défini entre Azure et votre réseau local qui ne traverse pas Internet. Étant donné qu’ExpressRoute fournit un chemin dédié entre votre centre de données local et Azure, ExpressRoute peut être utile lorsque les performances réseau sont à prendre en compte. ExpressRoute est également une bonne option quand une stratégie ou des exigences réglementaires de votre organisation exigent un chemin d’accès déterministe à vos ressources dans le cloud.

Remarque

Bien que nous vous recommandons d’utiliser des points de terminaison privés pour faciliter l’extension de votre réseau local dans Azure, il est techniquement possible d’acheminer vers le point de terminaison public via la connexion VPN. Toutefois, cela nécessite un codage en dur de l’adresse IP pour le point de terminaison public du cluster de stockage Azure qui sert votre compte de stockage. Étant donné que les comptes de stockage peuvent être déplacés entre des clusters de stockage à tout moment et que de nouveaux clusters sont fréquemment ajoutés et supprimés, cela nécessite régulièrement de coder en dur toutes les adresses IP de stockage Azure possibles dans vos règles de routage.

Configuration de DNS

Lorsque vous créez un point de terminaison privé, par défaut, nous créons également une zone DNS privée (ou mettez à jour une zone DNS existante) correspondant au privatelink sous-domaine. Strictement, la création d’une zone DNS privée n’est pas nécessaire pour utiliser un point de terminaison privé pour votre compte de stockage. Toutefois, il est vivement recommandé en général, et il est explicitement nécessaire lors du montage de votre partage de fichiers Azure avec un utilisateur principal Active Directory ou pour y accéder depuis l'API FileREST.

Remarque

Cet article utilise le suffixe DNS de compte de stockage pour les régions publiques Azure, core.windows.net. Ce commentaire s’applique également aux clouds souverains Azure tels que le cloud Azure US Government et le cloud Microsoft Azure géré par le cloud 21Vianet. Il suffit de remplacer les suffixes appropriés pour votre environnement.

Dans votre zone DNS privée, nous créons un enregistrement A pour storageaccount.privatelink.file.core.windows.net et un enregistrement CNAME pour le nom normal du compte de stockage, qui suit le modèle storageaccount.file.core.windows.net. Étant donné que votre zone DNS privée Azure est connectée au réseau virtuel contenant le point de terminaison privé, vous pouvez observer la configuration DNS en appelant l’applet Resolve-DnsName de commande à partir de PowerShell dans une machine virtuelle Azure (alternativement nslookup dans Windows et Linux) :

Resolve-DnsName -Name "storageaccount.file.core.windows.net"

Dans cet exemple, le compte de stockage storageaccount.file.core.windows.net est résolu en adresse IP privée du point de terminaison privé, à savoir 192.168.0.4.

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  29    Answer     csostoracct.privatelink.file.core.windows.net
net

Name       : storageaccount.privatelink.file.core.windows.net
QueryType  : A
TTL        : 1769
Section    : Answer
IP4Address : 192.168.0.4


Name                   : privatelink.file.core.windows.net
QueryType              : SOA
TTL                    : 269
Section                : Authority
NameAdministrator      : azureprivatedns-host.microsoft.com
SerialNumber           : 1
TimeToZoneRefresh      : 3600
TimeToZoneFailureRetry : 300
TimeToExpiration       : 2419200
DefaultTTL             : 300

Si vous exécutez la même commande à partir d’un emplacement local, vous verrez que le même nom de compte de stockage est résolu en adresse IP publique du compte de stockage à la place. Par exemple, storageaccount.file.core.windows.net est un enregistrement CNAME pour storageaccount.privatelink.file.core.windows.net, qui à son tour est un enregistrement CNAME pour le cluster de stockage Azure hébergeant le compte de stockage :

Name                              Type   TTL   Section    NameHost
----                              ----   ---   -------    --------
storageaccount.file.core.windows. CNAME  60    Answer     storageaccount.privatelink.file.core.windows.net
net
storageaccount.privatelink.file.c CNAME  60    Answer     file.par20prdstr01a.store.core.windows.net
ore.windows.net

Name       : file.par20prdstr01a.store.core.windows.net
QueryType  : A
TTL        : 60
Section    : Answer
IP4Address : 52.239.194.40

Cela reflète le fait que le compte de stockage peut exposer à la fois le point de terminaison public et un ou plusieurs points de terminaison privés. Pour être certain que le nom du compte de stockage est résolu en adresse IP privée du point de terminaison privé, vous devez modifier la configuration sur vos serveurs DNS locaux. Il existe plusieurs façons de procéder :

  • Modification du fichier hosts sur vos clients pour faire correspondre storageaccount.file.core.windows.net à l'adresse IP privée du point de terminaison privé souhaité. Cela est fortement déconseillé pour les environnements de production, car vous devez apporter ces modifications à chaque client qui souhaite monter vos partages de fichiers Azure, et les modifications apportées au compte de stockage ou au point de terminaison privé ne seront pas gérées automatiquement.
  • Créez un enregistrement A pour storageaccount.file.core.windows.net sur vos serveurs DNS locaux. Cela présente l’avantage que les clients de votre environnement local puissent résoudre automatiquement le compte de stockage sans avoir à configurer chaque client. Toutefois, cette solution est aussi fragile que la modification du fichier hosts , car les modifications ne sont pas reflétées. Bien que fragile, cette solution peut s’avérer être le meilleur choix pour certains environnements.
  • Transférez la core.windows.net zone de vos serveurs DNS locaux vers votre zone DNS privée Azure. Il est possible d’atteindre l’hôte DNS privé Azure via une adresse IP spéciale (168.63.129.16) qui est uniquement accessible à l’intérieur des réseaux virtuels qui sont liés à la zone DNS privée Azure. Pour contourner cette limitation, vous pouvez exécuter des serveurs DNS supplémentaires au sein de votre réseau virtuel qui seront transférés core.windows.net vers la zone DNS privée Azure. Pour simplifier cette configuration, nous avons fourni des applets de commande PowerShell qui déploieront automatiquement des serveurs DNS dans votre réseau virtuel Azure et les configurent comme vous le souhaitez. Pour savoir comment configurer le transfert DNS, consultez Configuration du DNS avec Azure Files.

SMB sur QUIC

Windows Server 2022 Azure Edition prend en charge un nouveau protocole de transport appelé QUIC pour le serveur SMB fourni par le rôle Serveur de fichiers. QUIC est un remplacement de TCP basé sur UDP, offrant de nombreux avantages sur TCP tout en fournissant un mécanisme de transport fiable. L’un des principaux avantages du protocole SMB est qu’au lieu d’utiliser le port 445, tout le transport est effectué sur le port 443, qui est largement ouvert sortant pour prendre en charge HTTPS. Cela signifie efficacement que SMB sur QUIC offre un « VPN SMB » pour le partage de fichiers sur l’Internet public. Windows 11 est fourni avec un client compatible SMB sur QUIC.

À ce stade, Azure Files ne prend pas directement en charge SMB sur QUIC. Toutefois, vous pouvez accéder aux partages de fichiers Azure via Azure File Sync s’exécutant sur Windows Server comme dans le diagramme ci-dessous. Cela vous donne également la possibilité de mettre en cache Azure File Sync localement ou dans différents centres de données Azure afin de fournir des caches locaux pour une main-d’œuvre distribuée. Pour en savoir plus sur cette option, consultez Déployer Azure File Sync et SMB sur QUIC.

Diagramme de création d’un cache léger de vos partages de fichiers Azure sur un serveur Windows Server 2022 Azure Edition V M à l’aide d’Azure File Sync.

Voir aussi

  • Last updated on