Planifier un déploiement d’Azure Files

Planifier un déploiement Azure Files implique quelques décisions clés. Utilisez cet article pour choisir les options adaptées à votre charge de travail.

Vous devez décider des points suivants :

1. Comment les clients accéderont-ils à la part ? Monter directement à partir de clients dans le cloud ou locaux, ou mettre en cache localement avec Azure File Sync ?
2. Quel modèle de gestion ? Partages de fichiers classiques (comptes de stockage) ou le nouveau fournisseur de ressources Microsoft.FileShares ?
3. Quel protocole ?SMB (Windows/Linux/macOS) ou NFS (Linux uniquement) ?
4. Comment les utilisateurs vont-ils s’authentifier ?Authentification basée sur l’identité ou clé de compte de stockage ?
5. Quelle configuration réseau ? Points publics, terminaux de service ou terminaux privés ?
6. Quelle est la catégorie de performance et l’option de redondance ?SSD ou HDD, et quelle option de redondance ?

Les sections suivantes couvrent chaque décision en détail.

Concepts de gestion

Azure Files propose deux modèles de gestion pour le déploiement des partages de fichiers :

• Partages de fichiers classiques (Microsoft. Fournisseur de ressources de stockage) : déployer des partages de fichiers au sein d’un compte de stockage. Prend en charge les SMB et NFS, les SSD et les HDD, tous les types de redondance et toutes les régions.
• Partages de fichiers (Microsoft. Fournisseur de ressources FileShares) : Déploie les partages de fichiers comme ressources Azure de premier niveau sans compte de stockage. Simplifiez la gestion avec la mise en réseau, la facturation et la sécurité par partage. Actuellement uniquement disponible pour les partages de fichiers NFS.

Pour plus de détails sur les fournisseurs de ressources, la comparaison de fonctionnalités et la disponibilité régionale, voir Azure Files management concepts.

Protocoles disponibles

Azure Files propose deux protocoles de système de fichiers standard pour le montage Azure partages de fichiers : le protocole SMB (Server Message Block) et le protocole NFS (Network File System). Choisissez le protocole qui convient le mieux à votre charge de travail. Azure partages de fichiers ne prennent pas en charge les protocoles SMB et NFS sur le même partage de fichiers, même si vous pouvez créer des partages de fichiers SMB et NFS Azure dans le même compte de stockage.

Avec les partages de fichiers SMB et NFS, Azure Files offre des partages de fichiers de niveau entreprise qui peuvent être mis à l’échelle pour répondre à vos besoins de stockage, et des milliers de clients peuvent y accéder simultanément.

Identité

Pour accéder à un partage de fichiers Azure, vous devez être authentifié et autorisé à accéder au partage. Dans presque tous les cas, utilisez l’authentification basée sur l’identité au lieu de la clé de compte de stockage pour accéder aux partages de fichiers SMB Azure.

Azure Files prend en charge les méthodes d’authentification suivantes pour les partages SMB :

• services de domaine Active Directory en local (AD DS ou AD DS en local) : vous pouvez joindre des comptes de stockage Azure à un service services de domaine Active Directory appartenant au client, tout comme un serveur de fichiers Windows Server ou un périphérique NAS. Vous pouvez déployer un contrôleur de domaine local, dans une machine virtuelle Azure ou même en tant que machine virtuelle dans un autre fournisseur de cloud. Azure Files est indépendant de l’emplacement où votre contrôleur de domaine est hébergé. Après avoir rejoint un compte de stockage dans votre domaine, l’utilisateur final peut créer un partage de fichiers avec le compte utilisateur avec lequel il s’est connecté à son PC. L’authentification basée sur Active Directory utilise le protocole d’authentification Kerberos.
• Microsoft Entra Domain Services : Microsoft Entra Domain Services fournit un contrôleur de domaine géré Microsoft que vous pouvez utiliser pour les ressources Azure. La jonction de domaine de votre compte de stockage avec Microsoft Entra Domain Services offre des avantages similaires à ceux de la jonction avec un AD DS appartenant au client. Cette option de déploiement est particulièrement utile pour les scénarios lift-and-shift d’application qui nécessitent des autorisations basées sur AD. Étant donné que Domain Services fournit une authentification basée sur AD, cette option utilise également le protocole d’authentification Kerberos.
• Microsoft Entra Kerberos : Microsoft Entra Kerberos vous permet d’utiliser Microsoft Entra ID pour authentifier hybrid ou les identités cloud uniquement. Cette configuration utilise Microsoft Entra ID pour émettre des tickets Kerberos pour accéder au partage de fichiers avec le protocole SMB. Cela signifie que vos utilisateurs finaux peuvent accéder aux partages de fichiers Azure sur l'Internet à partir de machines virtuelles jointes et hybrides de Microsoft Entra et de machines virtuelles jointes de Microsoft Entra.
• Authentification Active Directory via SMB pour les clients Linux : Azure Files prend en charge l’authentification basée sur l’identité via SMB pour les clients Linux à l’aide du protocole d’authentification Kerberos par le biais d’AD DS ou de Microsoft Entra Domain Services.
• Azure clé de compte de stockage : bien qu'il ne soit pas recommandé pour des raisons de sécurité, vous pouvez également monter Azure partages de fichiers à l'aide d'une clé de compte de stockage Azure au lieu d'utiliser une identité. Pour monter un partage de fichiers à l’aide de la clé de compte de stockage, utilisez le nom du compte de stockage comme nom d’utilisateur et la clé de compte de stockage comme mot de passe. L’utilisation de la clé de compte de stockage pour monter le partage de fichiers Azure est effectivement une opération d’administrateur, car le partage de fichiers monté dispose d’autorisations complètes pour tous les fichiers et dossiers sur le partage, même s’ils ont des listes de contrôle d’accès. Lorsque vous utilisez la clé de compte de stockage pour monter sur SMB, le protocole d’authentification NTLMv2 est utilisé. Si vous devez utiliser la clé de compte de stockage, utilisez des points de terminaison privés ou des points de terminaison de service, comme décrit dans la section Mise en réseau .

Pour les clients migrant depuis des serveurs de fichiers locaux ou créant de nouveaux partages de fichiers dans Azure Files destinés à se comporter comme des serveurs de fichiers Windows Server ou des systèmes NAS, joignez votre compte de stockage au domaine AD DS du client. Pour plus d’informations, consultez Overview - Authentification AD DS locale sur SMB pour Azure partages de fichiers.

Mise en réseau

Le montage direct de votre partage de fichiers Azure nécessite souvent une certaine réflexion sur la configuration réseau, car :

• De nombreuses organisations et fournisseurs de services Internet bloquent le port 445, que les partages de fichiers SMB utilisent pour la communication, pour le trafic sortant (Internet).
• 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.

Pour configurer la mise en réseau, Azure Files fournit un point de terminaison public accessible par Internet et une intégration avec Azure fonctionnalités réseau telles que les points de terminaison de service, qui permettent de restreindre le point de terminaison public aux réseaux virtuels spécifiés et aux points de terminaison privés, ce qui donne à votre compte de stockage une adresse IP privée à partir d’un espace d’adressage IP de réseau virtuel. Bien qu’il n’y ait aucuns frais supplémentaires pour l’utilisation de points de terminaison publics ou de service, des taux de traitement des données standard s’appliquent pour les points de terminaison privés.

Tenez compte des configurations réseau suivantes :

• Si le protocole requis est SMB et que tout l’accès via SMB provient de clients dans Azure, aucune configuration réseau spéciale n’est requise.
• Si le protocole requis est SMB et que l’accès provient de clients locaux, un VPN ou une connexion Azure ExpressRoute localement à votre réseau de Azure est nécessaire, avec Azure Files exposés sur votre réseau interne à l’aide de points de terminaison privés.
• Si le protocole requis est NFS, vous pouvez utiliser des points de terminaison de service ou des points de terminaison privés pour restreindre le réseau aux réseaux virtuels spécifiés. Si vous avez besoin d’une adresse IP statique et/ou si votre charge de travail nécessite une haute disponibilité, utilisez un point de terminaison privé. Avec les points de terminaison de service, un événement rare tel qu’une panne de zone peut entraîner la modification de l’adresse IP sous-jacente du compte de stockage. Les données sont toujours disponibles sur le partage de fichiers, mais le client aura besoin d’un nouveau montage du partage.

Pour plus d’informations, consultez Azure Files considérations relatives à la mise en réseau.

En plus de se connecter directement au partage de fichiers à l’aide du point de terminaison public ou d’une connexion VPN/ExpressRoute avec un point de terminaison privé, SMB fournit une stratégie d’accès client supplémentaire : SMB sur QUIC. SMB sur QUIC offre un « VPN SMB » sans configuration pour l’accès SMB via le protocole de transport QUIC. Bien que Azure Files ne prenne pas directement en charge SMB via QUIC, vous pouvez créer un cache léger de vos partages de fichiers Azure sur une VM Windows Server 2022 Azure Edition en utilisant Azure File Sync. Pour en savoir plus sur cette option, consultez SMB sur QUIC avec Azure File Sync.

Chiffrement pour Azure Files

Azure Files prend en charge deux types de chiffrement différents :

• Chiffrement en transit, qui concerne le chiffrement utilisé lors du montage ou de l’accès au partage de fichiers Azure
• Chiffrement au repos, qui concerne la façon dont les données sont chiffrées lorsqu’elles sont stockées sur le disque

Chiffrement en transit

Par défaut, tous les comptes de stockage Azure ont activé le chiffrement en transit. Cette fonctionnalité signifie que lorsque vous montez un partage de fichiers sur SMB ou accédez-le via le protocole FileREST (par exemple, via le portail Azure, PowerShell/CLI ou SDK Azure), Azure Files autorise uniquement la connexion si elle est établie avec SMB 3.x avec chiffrement ou HTTPS. Les clients qui ne prennent pas en charge SMB 3.x ou les clients qui prennent en charge SMB 3.x, mais pas le chiffrement SMB ne peut pas monter le partage de fichiers Azure si le chiffrement en transit est activé. Pour plus d’informations sur les systèmes d’exploitation prenant en charge SMB 3.x avec chiffrement, consultez la documentation relative à Windows, macOS et Linux. Toutes les versions actuelles de PowerShell, de CLI et des SDK prennent en charge le protocole HTTPS.

Vous pouvez désactiver le chiffrement en transit pour un compte de stockage Azure. Lorsque vous désactivez le chiffrement, Azure Files autorise également SMB 2.1 et SMB 3.x sans chiffrement, et les appels d’API FileREST non chiffrés via HTTP. La principale raison de désactiver le chiffrement en transit consiste à prendre en charge une application héritée qui doit s’exécuter sur un système d’exploitation plus ancien, tel que Windows Server 2008 R2 ou une distribution Linux plus ancienne. Azure Files autorise uniquement les connexions SMB 2.1 dans la même région Azure que le partage de fichiers Azure. Un client SMB 2.1 en dehors de la région Azure du partage de fichiers Azure, tel que local ou dans une autre région Azure, ne peut pas accéder au partage de fichiers.

Vérifiez que le chiffrement des données en transit est activé.

Pour plus d’informations sur le chiffrement en transit, consultez requiring secure transfer in Azure storage et Encryption en transit pour les partages de fichiers NFS Azure.

Chiffrement au repos

Azure Files utilise le même schéma de chiffrement que les autres services de stockage Azure, tels que Stockage Blob Azure. Toutes les données stockées dans Azure Files sont chiffrées au repos via chiffrement côté service (SSE), qui fonctionne de la même façon que BitLocker sur Windows.

Étant donné que les données sont chiffrées sous le système de fichiers du partage de fichiers Azure, car elles sont encodées sur disque, vous n'avez pas besoin d'accéder à la clé sous-jacente sur le client pour lire ou écrire dans le partage de fichiers Azure. Le chiffrement au repos s’applique aux protocoles SMB et NFS.

Par défaut, les données stockées dans Azure Files sont chiffrées avec des clés gérées par Microsoft. Avec les clés gérées par Microsoft, Microsoft contient les clés pour chiffrer et déchiffrer les données. Microsoft est responsable de la rotation régulière de ces clés.

Pour Azure partages de fichiers classiques, vous pouvez choisir de chiffrer vos données à l’aide de clés gérées par customer. Si vous choisissez des clés gérées par le client, Azure Files est autorisé à accéder à vos clés pour répondre aux demandes de lecture et d’écriture de vos clients. Avec les clés gérées par le client, vous pouvez révoquer cette autorisation à tout moment. Mais sans cette autorisation, votre partage de fichiers Azure n’est plus accessible via SMB ou l’API FileREST.

Vous ne pouvez pas utiliser de clés gérées par le client pour le chiffrement au repos avec des partages de fichiers Azure créés à l’aide du fournisseur de ressources Microsoft.FileShares. Vous devez utiliser des clés gérées par Microsoft.

Protection de données

Azure Files utilise une approche multicouche pour vous assurer que vos données sont sauvegardées, récupérables et protégées contre les menaces de sécurité. Consultez Azure Files vue d’ensemble de la protection des données.

Suppression réversible

La suppression réversible est un paramètre de niveau compte de stockage que vous pouvez utiliser pour récupérer votre partage de fichiers lorsqu’il est supprimé accidentellement. Lorsque vous supprimez un partage de fichiers, il passe à un état supprimé de manière réversible au lieu d’être effacé définitivement. Vous pouvez configurer la durée pendant laquelle les partages supprimés de manière réversible sont récupérables avant leur suppression définitive, et annuler la suppression du partage à tout moment lors de cette période de rétention.

La suppression réversible est activée par défaut pour les nouveaux comptes de stockage. Si vous disposez d’un flux de travail où la suppression de partage est courante et attendue, vous pouvez décider de définir une période de rétention courte ou de ne pas activer la suppression réversible.

Pour plus d’informations sur la suppression réversible, consultez Prévenir les suppressions de données accidentelles.

Sauvegarde

Sauvegardez vos partages de fichiers Azure à l’aide de captures instantanées de partage, qui sont des copies ponctuelles et en lecture seule de votre partage. Les instantanés sont incrémentiels. Ils incluent donc uniquement les données modifiées depuis l’instantané précédent. Chaque partage de fichiers prend en charge jusqu’à 200 instantanés et vous pouvez les conserver pendant 10 ans. Vous pouvez créer manuellement des instantanés dans le portail Azure, ou utiliser PowerShell ou l’interface de ligne de commande (CLI). Vous pouvez également utiliser Sauvegarde Azure.

Sauvegarde Azure pour les partages de fichiers SMB Azure gère la planification et la rétention des instantanés. Ses fonctionnalités grand-père-père-fils vous permettent de prendre des captures instantanées quotidiennes, hebdomadaires, mensuelles et annuelles, dont les périodes de rétention diffèrent. Sauvegarde Azure orchestre également l’activation de la suppression réversible et prend un verrou de suppression sur un compte de stockage dès qu’un partage de fichiers au sein de celui-ci est configuré pour la sauvegarde. Sauvegarde Azure fournit certaines fonctionnalités de surveillance et d’alerte clés qui permettent aux clients d’avoir une vue consolidée de leur patrimoine de sauvegarde.

Vous pouvez effectuer des restaurations au niveau de l’élément et au niveau du partage dans le portail Azure à l’aide de Sauvegarde Azure. Choisissez le point de restauration (un instantané particulier), le fichier ou répertoire si pertinent, puis l’emplacement (original ou alternatif) où vous souhaitez restaurer. Le service de sauvegarde gère la copie des données de captures instantanées et affiche la progression de la restauration dans le portail.

Protéger Azure Files avec Microsoft Defender pour le stockage

Microsoft Defender pour le stockage est une couche native Azure d’intelligence de sécurité qui détecte les menaces potentielles pour vos comptes de stockage. Il fournit une sécurité complète en analysant le plan de données et les données de télémétrie du plan de contrôle générées par Azure Files. Il utilise des fonctionnalités avancées de détection des menaces optimisées par Microsoft Threat Intelligence pour fournir des alertes de sécurité contextuelles, notamment les étapes permettant d’atténuer les menaces détectées et d’empêcher les attaques futures.

Defender stockage analyse en continu le flux de télémétrie généré par Azure Files. Quand des activités potentiellement malveillantes sont détectées, des alertes de sécurité sont générées. Ces alertes sont affichées dans Microsoft Defender for Cloud, ainsi que les détails de l’activité suspecte, des étapes d’investigation, des actions de correction et des recommandations de sécurité.

Defender pour Storage détecte les programmes malveillants connus, tels que les ransomware, les virus, les logiciels espions et d’autres programmes malveillants chargés sur un compte de stockage en fonction du hachage de fichier complet (pris en charge uniquement pour l’API REST). Cela permet d’empêcher les programmes malveillants d’entrer dans l’organisation et de se propager à davantage d’utilisateurs et de ressources. Consultez Compréhension des différences entre l’analyse des programmes malveillants et l’analyse de la réputation de hachage.

Defender pour le stockage n'accède pas aux données du compte de stockage et n'a pas d'impact sur ses performances. Vous pouvez enable Microsoft Defender pour le stockage au niveau de l’abonnement (recommandé) ou au niveau de la ressource.

Niveaux de stockage

Azure Files offre deux niveaux de stockage multimédia : disque SSD (SSD) et disque dur (HDD). Ces niveaux vous permettent d’adapter vos partages aux exigences de performances et de prix de votre scénario :

• SSD (Premium) : les partages de fichiers SSD fournissent des hautes performances et une faible latence cohérentes, en millisecondes à un chiffre pour la plupart des opérations d’E/S, pour les charges de travail gourmandes en E/S. Les partages de fichiers SSD conviennent à un large éventail de charges de travail, telles que les bases de données, l’hébergement de sites web et les environnements de développement.

  Vous pouvez utiliser des partages de fichiers SSD avec les protocoles SMB et NFS. Les partages de fichiers SSD sont disponibles dans les modèles de facturation v2 approvisionnés et v1 approvisionnés . Les partages de fichiers SSD offrent un SLA de disponibilité plus élevé que les partages de fichiers HDD.

• HDD (standard) : les partages de fichiers HDD fournissent une option de stockage économique pour les partages de fichiers à usage général. Les partages de fichiers HDD sont disponibles avec les modèles de facturation provisionnés v2 et paiement à l'utilisation, bien que nous recommandions le modèle provisionné v2 pour les nouveaux déploiements de partages de fichiers. Pour plus d’informations sur le contrat SLA, consultez la page Azure SLA pour services en ligne.

Lorsque vous sélectionnez un niveau multimédia pour votre charge de travail, tenez compte de vos besoins en matière de performances et d’utilisation. Si votre charge de travail nécessite une latence à un chiffre ou si vous utilisez un support de stockage SSD local, les partages de fichiers SSD sont probablement les mieux adaptés. Si la faible latence n’est pas autant problématique, les partages de fichiers HDD peuvent être mieux adaptés du point de vue des coûts. Par exemple, une faible latence peut être moins problématique avec les partages d’équipe montés localement à partir de Azure ou mis en cache localement via Azure File Sync.

Après avoir créé un partage de fichiers dans un compte de stockage, vous ne pouvez pas le déplacer directement vers un autre niveau multimédia. Par exemple, pour déplacer un partage de fichiers HDD vers le niveau multimédia SSD, vous devez créer un nouveau partage de fichiers SSD et copier les données de votre partage d'origine vers le nouveau partage de fichiers.

Vous trouverez plus d'informations sur les niveaux multimédias SSD et HDD dans Comprendre les modèles de facturation Azure Files et Comprendre et optimiser les performances du partage de fichiers Azure.

Redondance

Pour protéger les données de vos partages de fichiers Azure contre toute perte de données ou altération, Azure Files stocke plusieurs copies de chaque fichier lors de leur écriture. Selon vos besoins, vous pouvez sélectionner des degrés de redondance. Azure Files prend actuellement en charge les options suivantes pour la redondance des données :

• Stockage redondant local (LRS) : avec redondance locale, chaque fichier est stocké trois fois dans un cluster de stockage Azure. Cette approche permet de protéger contre la perte de données en raison d’erreurs matérielles, telles qu’un lecteur de disque incorrect. Toutefois, si une catastrophe telle que l’incendie ou l’inondation se produit dans le centre de données, tous les réplicas d’un compte de stockage qui utilise LRS peuvent être perdus ou irrécupérables.

• Stockage redondant interzone (ZRS) : avec redondance de zone, trois copies de chaque fichier sont stockées. Toutefois, ces copies sont physiquement isolées dans trois clusters de stockage distincts dans des zones de disponibilité Azure . Les zones de disponibilité sont des emplacements physiques uniques dans une région Azure. Chaque zone est composée d’un ou de plusieurs centres de données équipés d’une alimentation, d’un système de refroidissement et d’un réseau indépendants. Une écriture sur le stockage n’est pas acceptée tant qu’elle n’est pas écrite sur les clusters de stockage dans les trois zones de disponibilité.

• Stockage géoredondant (GRS) : avec redondance géographique, vous disposez d’une région primaire et d’une région secondaire. Les fichiers sont stockés trois fois dans un cluster de stockage Azure dans la région primaire. Les écritures sont répliquées de manière asynchrone dans une région secondaire définie par Microsoft.

  La géoredondance fournit six copies de vos données réparties entre les deux régions Azure. Si une catastrophe majeure se produit, telle que la perte permanente d’une région Azure en raison d’une catastrophe naturelle ou d’un autre événement similaire, Microsoft effectue un basculement. Dans ce cas, le secondaire devient le principal et sert toutes les opérations.

  Étant donné que la réplication entre les régions primaires et secondaires est asynchrone, si une catastrophe majeure se produit, les données qui ne sont pas encore répliquées dans la région secondaire sont perdues. Vous pouvez également effectuer le basculement manuel d’un compte de stockage géoredondant.

• Stockage géoredondant interzone (GZRS) : avec la redondance géographique, les fichiers sont stockés trois fois sur trois clusters de stockage distincts dans la région primaire. Toutes les écritures sont ensuite répliquées de manière asynchrone dans une région secondaire Microsoft définie. Le processus de basculement pour la redondance de zone géographique fonctionne de la même façon que pour la géoredondance.

Les partages de fichiers HDD prennent en charge les quatre types de redondance. Les partages de fichiers SSD prennent uniquement en charge LRS et ZRS.

Les comptes de stockage pay-as-you-go offrent deux autres options de redondance que Azure Files ne prend pas en charge : le stockage géo-redondant en accès en lecture (RA-GRS) et le stockage redondant en zone géographique en accès en lecture (RA-GZRS). Vous pouvez approvisionner des partages de fichiers Azure dans des comptes de stockage avec ces options, mais Azure Files ne prend pas en charge la lecture à partir de la région secondaire. Les partages de fichiers Azure déployés dans des comptes de stockage RA-GRS ou RA-GZRS sont facturés en tant que géoredondants ou géozone redondants, respectivement.

Pour plus d’informations sur la redondance, consultez Azure Files redondance des données.

Disponibilité des partages de fichiers SSD redondants interzone

Les partages de fichiers SSD redondants interzone sont disponibles pour un subset de régions Azure.

Reprise d’activité après sinistre et basculement

Dans le cas d’une panne de service régional non planifiée, vous devez disposer d’un plan de récupération d’urgence (DR) en place pour vos partages de fichiers Azure. Pour comprendre les concepts et processus liés à la reprise de données et au basculement des comptes de stockage, voir Reprise après sinistre et basculement pour Azure Files.

Migration

Dans de nombreux cas, vous n'allez pas établir de nouveau partage de fichiers net pour votre organisation, mais plutôt migrer un partage de fichiers existant d'un serveur de fichiers local ou d'un appareil NAS vers Azure Files. La sélection de la stratégie et de l’outil de migration appropriés est importante pour la réussite de votre migration.

Pour les migrations SMB, consultez la vue d’ensemble de la migration SMB qui contient une table qui vous conduit à des guides de migration qui couvrent probablement votre scénario.

Pour les migrations NFS, consultez Migrate vers les partages de fichiers NFS Azure.

Étapes suivantes

• Plan pour un déploiement Azure File Sync
• Déployer Azure Files
• Déployer Azure File Sync