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

✔️ S'applique à : Tous les partages de fichiers Azure

Vous pouvez accéder à vos partages de fichiers Azure sur 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 localement avec Azure File Sync (partages de fichiers SMB uniquement). Cet article se concentre sur la configuration de 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 Introduction dans Azure File Sync.

Lisez Planifier un déploiement d’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 de 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.

Vous configurez les terminaux publics et privés pour Azure Files sur l’objet de gestion de premier niveau 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.

Transfert sécurisé

Par défaut, Azure comptes de stockage nécessitent un transfert sécurisé, que les données soient accessibles via le point de terminaison public ou privé. Pour Azure Files, le chiffrement en transit est contrôlé au niveau du protocole :

Chiffrement des données en transit pour SMB

Le paramètre Exiger le chiffrement en transit pour PME détermine si le chiffrement est requis pour l’accès aux PME. Pour les nouveaux comptes de stockage créés à l’aide du portail Azure, ce paramètre est activé par défaut. Les comptes de stockage créés à l’aide de Azure PowerShell, de Azure CLI ou de l’API FileREST définissent cette valeur comme Not sélectionné pour garantir la compatibilité descendante. Pour les comptes de stockage existants, le paramètre de transfert sécurisé requis continue de régir le comportement de chiffrement SMB jusqu’à ce que vous configuriez explicitement le paramètre SMB par protocole. Lorsque le chiffrement SMB en transit est requis, 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 AES-256-GCM. Vous pouvez activer/désactiver les algorithmes autorisés via les paramètres de sécurité SMB. La désactivation de ce paramètre active les montages SMB 2.1 et SMB 3.x sans chiffrement.

Chiffrement en transit pour NFS

Le paramètre Exiger du chiffrement en transit pour NFS détermine si le chiffrement est nécessaire pour l’accès NFS. NFS Azure partages de fichiers 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 Encryption en transit pour les partages de fichiers NFS Azure. Pour les nouveaux comptes de stockage créés à l’aide du portail Azure, ce paramètre est activé par défaut. Les comptes de stockage créés à l’aide de Azure PowerShell, de Azure CLI ou de l’API FileREST définissent cette valeur comme Not sélectionné pour garantir la compatibilité descendante. Pour les comptes de stockage existants, le paramètre de transfert sécurisé requis continue de régir le comportement de chiffrement NFS jusqu’à ce que vous configuriez explicitement le paramètre NFS par protocole.

Chiffrement en transit pour FileREST

Le paramètre Secure transfer required s’applique au trafic REST/HTTPS. Lorsqu’il est activé, le protocole FileREST peut uniquement être utilisé avec HTTPS.

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 Exiger le chiffrement en transit pour SMB doit être désactivé (ou, pour les comptes existants où ce paramètre n’a pas été configuré explicitement, le paramètre de transfert sécurisé requis 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. Vous pouvez restreindre l’accès à certaines adresses IP ou plages d’adresses IP, à des réseaux virtuels spécifiques, ou désactiver complètement le point public de terminaison.

Lorsque vous restreignez le point public à un ou plusieurs réseaux, vous utilisez une capacité du réseau virtuel appelée terminaux de service. Les requêtes dirigées vers le point de terminaison du service d’Azure Files vont toujours vers l’adresse IP publique du compte de stockage. Cependant, la couche réseau effectue une vérification supplémentaire de la requête pour valider 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, cependant, les partages de fichiers NFS ne peuvent être accessibles qu’en utilisant le point de terminaison public via un point de terminaison de service.

Accès au portail Azure et pare-feu du compte de stockage

Lorsque vous accédez aux partages de fichiers Azure via le portail Azure, deux requêtes distinctes se produisent :

1. Demande de votre navigateur à l’interface utilisateur du portail Azure (https://portal.azure.com).
2. Une requête de votre navigateur directement vers le point de terminaison du plan de données Azure Files (par exemple, https://<storage-account-name>.file.core.windows.net), généralement en utilisant un jeton SAS émis pour l’expérience du portail.

Le pare-feu du compte de stockage évalue uniquement la requête directe au point de terminaison du plan de données Azure Files, et non la demande à portal.azure.com. Par conséquent, même si vous pouvez accéder au portail Azure sans problème, vous pouvez recevoir une erreur 403 (Interdit) lors de la navigation dans les données de partage de fichiers si l’adresse IP de sortie publique sur la demande de navigateur à stockage n’est pas autorisée par le pare-feu. Cette restriction s’applique uniquement au trafic FileREST/HTTPS, pas SMB ou NFS. Pour plus d’informations, consultez Autoriser l’accès aux données de fichiers dans le portail Azure.

Routage réseau de point de terminaison public

Azure Files prend en charge deux options de routage réseau :

• Routage Microsoft (par défaut) : Le trafic entre le client et le compte de stockage circule aussi longtemps que possible sur le réseau global Microsoft avant de rejoindre Internet. Cette option fonctionne avec toutes les configurations Azure Files, y compris les scénarios de jointure de domaine Active Directory (AD) et Azure File Sync.
• Routage Internet : Le trafic est acheminé via l’internet public le plus tôt possible. Cette option ne prend pas en charge les scénarios de jonction de domaine Active Directory (AD) ni 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 spécifique Azure. 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 :

• Connectez-vous en toute sécurité à vos partages de fichiers Azure à partir de réseaux locaux à l’aide d’une connexion VPN ou ExpressRoute avec peering privé.
• Sécurisez vos partages de fichiers Azure en configurant le pare-feu du compte de stockage pour 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 Configuring private endpoints for 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 est similaire à un réseau traditionnel sur site. Comme un compte de stockage Azure ou une VM Azure, un réseau virtuel est une ressource Azure que vous déployez 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 Azure partages de fichiers SMB/NFS :

VPN de point à site

Passerelle VPN Azure prend en charge les connexions VPN point-à-site, c’est-à-dire 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 cas d’usage courant est destiné aux télémutateurs qui veulent pouvoir monter leur partage de fichiers Azure à partir de la maison, d’un café ou d’un hôtel pendant la route. Pour utiliser une connexion VPN point-à-site avec Azure Files, vous devez configurer une connexion VPN point à site pour chaque client souhaitant se connecter. Voir Configurer un VPN point-à-site sur Windows pour une utilisation avec Azure Files et Configurer un VPN point-to-site sur Linux pour une utilisation avec Azure Files.

VPN de site à site

Passerelle VPN Azure prend également en charge les connexions VPN site-à-site, qui sont des connexions VPN entre Azure et le réseau de votre organisation. Une connexion VPN site-à-site 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 organisation, plutôt que de configurer une connexion pour chaque appareil client qui doit accéder à votre partage de fichiers Azure. Voir Configurer un VPN Site-à-Site pour une utilisation avec Azure Files.

ExpressRoute

ExpressRoute vous permet de créer un itinéraire défini entre Azure et votre réseau sur site qui ne traverse pas Internet. Étant donné qu’ExpressRoute fournit un chemin d’accès dédié entre votre centre de données local et Azure, ExpressRoute peut être utile lorsque les performances du réseau sont un facteur à 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.

Configuration de DNS

Lorsque vous créez un point de terminaison privé, Azure crée ou met à jour une zone DNS privée 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. Cependant, c'est fortement recommandé, et c'est explicitement obligatoire lors du montage de votre partage de fichiers Azure avec un principal utilisateur Active Directory ou de l'accès depuis l'API FileREST.

Dans votre zone DNS privée, Azure crée 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 schéma 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 de commande Resolve-DnsName à partir de PowerShell dans une machine virtuelle Azure (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     storageaccount.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 est à son tour 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

Cette configuration reflète que le compte de stockage peut exposer à la fois le point 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. Pour ce faire, vous disposez de plusieurs méthodes :

• 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 zone core.windows.net de vos serveurs DNS locaux vers votre zone DNS privée Azure. L’hôte DNS privé Azure peut être accessible via une adresse IP spéciale (168.63.129.16) accessible uniquement à l’intérieur de réseaux virtuels liés à la zone DNS privée Azure. Pour contourner cette limitation, vous pouvez faire fonctionner des serveurs DNS supplémentaires dans votre réseau virtuel qui sont transférés core.windows.net vers la zone DNS privée Azure. Pour simplifier cette configuration, Microsoft propose des cmdlets PowerShell qui déploient automatiquement les serveurs DNS dans votre réseau virtuel Azure et les configurent selon les souhaits. Pour savoir comment configurer le transfert DNS, consultez Configuring DNS avec Azure Files.

SMB sur QUIC

Windows Server 2022 Azure Edition prend en compte un protocole de transport appelé QUIC pour le serveur SMB fourni par le rôle de serveur de fichiers. QUIC remplace TCP construit 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 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. Cette configuration signifie en fait que SMB sur QUIC propose un « VPN SMB » pour le partage de fichiers sur Internet public. Windows 11 est fourni avec un client compatible SMB sur QUIC.

Actuellement, Azure Files ne prend pas en charge SMB via QUIC. Cependant, vous pouvez accéder aux partages de fichiers Azure via Azure File Sync fonctionnant sur Windows Server comme indiqué dans le schéma suivant. Cette configuration vous permet également d’avoir Azure File Sync en cache, à la fois sur site ou dans différents centres de données Azure pour fournir des caches locaux à une main-d’œuvre distribuée. Pour en savoir plus sur cette option, consultez la documentation de Windows Server. Pour les détails réseau spécifiques à Azure File Sync, voir SMB over QUIC.

Voir aussi

• vue d’ensemble Azure Files
• Planifier un déploiement Azure Files