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 l’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 localement 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 en local avec Azure File Sync, consultez Présentation d’Azure File Sync.

Avant de parcourir ce guide, nous vous recommandons de lire Planification d’un déploiement Azure Files.

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 Internet sortant. Cette pratique résulte des recommandations de sécurité héritées concernant les versions déconseillées et non sécurisées pour Internet du protocole SMB. Bien que SMB 3.x soit un protocole sécurisé pour Internet, les stratégies organisationnelles ou ISP peuvent ne pas être modifiables. Par conséquent, le montage d’un partage de fichiers SMB nécessite souvent une configuration réseau supplémentaire 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 des 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, c’est-à-dire le compte de stockage Azure. Le 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 d’autres ressources de stockage Azure, telles 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	SMB	NFS
Partages de fichiers Standard (GPv2), LRS/ZRS
Partages de fichiers Standard (GPv2), GRS/GZRS
Partages de fichiers Premium (FileStorage), LRS/ZRS

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 de protocole aux données stockées sur les partages de fichiers Azure, notamment SMB, NFS et FileREST. Vous pouvez désactiver le paramètre Exiger un transfert sécurisé pour autoriser le trafic non chiffré. Dans le Portail Azure, vous pouvez également voir ce paramètre intitulé Exiger un transfert sécurisé pour les opérations de l’API REST.

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 les algorithmes de chiffrement AES-128-CCM, AES-128-GCM ou 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 NFS ne prennent pas en charge de mécanisme de chiffrement. Par conséquent, afin d’utiliser le protocole NFS pour accéder à un partage de fichiers Azure, vous devez désactiver le transfert sécurisé requis pour le compte de stockage.

• Lorsque le transfert sécurisé est requis, le protocole FileREST peut uniquement être utilisé avec HTTPS. FileREST est pris en charge uniquement sur les partages de fichiers SMB actuellement.

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 suit 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 SMB 3.x avec chiffrement. Ainsi, les demandes authentifiées, comme celles qui sont autorisées par l’identité d’ouverture de session d’un utilisateur, peuvent provenir de manière sécurisée, de l’intérieur comme de 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 venir de l’intérieur de la région Azure. Comme mentionné précédemment, les requêtes SMB chiffrées sont autorisées depuis 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é à certains réseaux virtuels à 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 des points de terminaison publics.

• 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 indépendamment de l’origine.

Paramètres de pare-feu de point de terminaison

Le pare-feu du compte de stockage restreint 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 ou plages d’adresses IP, à des réseaux virtuels donnés 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 de Azure Files sont toujours envoyées à 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 façon de configurer le pare-feu de compte de stockage, consultez Configurer des pare-feux et des réseaux virtuels dans Stockage Azure.

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 ni Azure File Sync.

Instances Private Endpoint

En plus du point de terminaison public par défaut du compte de stockage, Azure Files permet de disposer d’un ou plusieurs points de terminaison privés. Un point de terminaison privé est un point de terminaison qui n’est accessible qu’à l’intérieur d’un réseau virtuel Azure. Quand vous créez un point de terminaison privé pour votre compte de stockage, celui-ci obtient une adresse IP privée en provenance de l’espace d’adressage de votre réseau virtuel, de la même manière qu’un serveur de fichiers local ou un périphérique NAS reçoit une adresse IP de 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é n’a pas pour effet de bloquer 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 des 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 VNet, est similaire à un réseau classique local. À l’instar d’un compte de stockage Azure ou d’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 SMB/NFS 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 aux côtés d’un compte de stockage ou d’autres ressources Azure. Les passerelles VPN exposent deux types de connexion :
  • Des connexions de passerelle VPN point à site (P2S) , qui sont des connexions VPN entre Azure et un client individuel. Cette solution est principalement utile pour les appareils qui ne font pas partie du réseau local de votre organisation. Un case d’usage courant est pour les télétravailleurs qui souhaitent monter leur partage de fichiers Azure à la maison, dans un café ou dans un hôtel. Pour utiliser une connexion VPN P2S avec Azure Files, vous devez configurer une connexion VPN P2S pour chaque client qui souhaite se connecter. Pour simplifier le déploiement d’une connexion VPN P2S, consultez Configurer un VPN point à site (P2S) sur Windows pour une utilisation avec Azure Files et Configurer un VPN point à site (P2S) sur Linux pour une utilisation avec Azure Files.
  • Des connexions VPN site à site (S2S) entre Azure et le réseau de votre organisation. Une connexion VPN S2S vous permet de configurer une connexion VPN une seule fois pour un serveur VPN ou un appareil hébergé sur le réseau de votre entreprise, au lieu de le faire que pour chaque appareil client devant accéder à votre partage de fichiers Azure. Pour simplifier le déploiement d’une connexion VPN S2S, consultez Configurer un VPN site à site (S2S) pour une utilisation avec Azure Files.
• ExpressRoute, qui vous permet de créer un itinéraire défini entre Azure et votre réseau local qui ne traverse pas Internet. ExpressRoute peut être utile quand les performances du réseau doivent être prises en compte, car il fournit un chemin dédié entre votre centre de données local et Azure. 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.

Notes

Bien que nous vous recommandions d’utiliser des points de terminaison privés pour faciliter l’extension de votre réseau local dans Azure, il est techniquement possible d’effectuer le routage vers le point de terminaison public via la connexion VPN. Toutefois, cela nécessite de coder en dur l’adresse IP du 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 un codage régulier en dur de toutes les adresses IP possibles du stockage Azure dans vos règles d’acheminement.

Configuration DNS

Quand vous créez un point de terminaison privé, par défaut, nous créons aussi une zone DNS privée (ou en mettons une existante à jour) correspondant au sous-domaine privatelink. Strictement parlant, il n’est pas nécessaire de créer une zone DNS privée pour utiliser un point de terminaison privé pour votre compte de stockage. Toutefois, cette opération est fortement conseillée en général et même tout à fait nécessaire si vous montez votre partage de fichiers Azure avec un principal de l’utilisateur Active Directory ou que vous y accédez via l’API FileREST.

Notes

Cet article utilise le suffixe DNS de compte de stockage pour les régions publiques Azure, core.windows.net. Ce commentaire vaut aussi pour les clouds souverains Azure, notamment le cloud Azure US Government et le cloud Microsoft Azure géré par 21Vianet (il vous 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 régulier du compte de stockage, qui suit le modèle storageaccount.file.core.windows.net. Comme 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 la cmdlet Resolve-DnsName à partir de PowerShell dans une machine virtuelle Azure (ou nslookup dans Windows et Linux) :

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

Pour 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 en local, vous constaterez que le même nom de compte de stockage est résolu en adresse IP publique du compte de stockage. storageaccount.file.core.windows.net est un enregistrement CNAME pour storageaccount.privatelink.file.core.windows.net qui, de son côté, 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 traduit 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 :

• Modifiez le fichier hosts sur vos clients pour faire en sorte que storageaccount.file.core.windows.net soit résolu en adresse IP privée du point de terminaison privé souhaité. Cela est fortement déconseillé pour les environnements de production, car vous devrez apporter ces modifications à chaque client désireux de 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. L’avantage de cette méthode est que les clients de votre environnement local pourront résoudre automatiquement le compte de stockage sans avoir à configurer chaque client. Cependant, cette solution s’avère tout aussi fragile pour ce qui est de la modification du fichier hosts, car les modifications n’apparaîtront pas. Bien que fragile, cette solution peut s’avérer être le meilleur choix pour certains environnements.
• Transférez la zone de core.windows.net 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 à l’intérieur de votre réseau virtuel, qui transféreront core.windows.net vers la zone DNS privée Azure. Pour simplifier cette configuration, nous avons prévu des applets de commande PowerShell qui assurent le déploiement automatique 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 remplace TCP et se base sur UDP, offrant de nombreux avantages par rapport à TCP tout en fournissant un mécanisme de transport fiable. L’un des principaux avantages du protocole SMB est que plutôt que d’utiliser le port 445, tout le transport est effectué sur le port 443, qui est souvent ouvert comme port sortant pour prendre en charge HTTPS. Cela signifie que SMB sur QUIC offre un « VPN SMB » pour le partage de fichiers via 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é qu’Azure File Sync effectue la mise en cache localement ou dans différents centres de données Azure pour fournir des caches locaux pour un personnel disséminé. Pour en savoir plus sur cette option, consultez Déployer Azure File Sync et SMB sur QUIC.

Voir aussi

• Vue d’ensemble d’Azure Files
• Planification d’un déploiement Azure Files