Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article fournit des conseils de sécurité pour Azure Files, y compris les partages de fichiers classiques créés avec Microsoft.Storage et les partages de fichiers créés avec Microsoft.FileShares. Il couvre les ressources qui détiennent vos partages, l’accès des clients, la protection des données et les contrôles opérationnels.
Les contrôles de sécurité dépendent du fournisseur de ressources et du protocole. Pour une comparaison des fonctionnalités prises en charge, voir Azure Files Management Concepts.
Isolation des ressources
Considérez le compte de stockage comme une frontière de confiance : créer des partages de fichiers classiques séparés dans le même compte n’isole pas leurs règles réseau, la source d’identité SMB ou la configuration de la clé de chiffrement. Les modifications de ces paramètres au niveau du compte affectent tous les éléments partagés du compte. Regroupez les éléments partagés classiques ensemble uniquement lorsqu’ils peuvent partager ces commandes. Microsoft. FileShares évite cette frontière partagée au niveau du compte en fournissant une configuration indépendante du réseau et de la sécurité pour chaque partage.
Protéger les systèmes clients : Un client disposant d’un accès en écriture peut modifier ou supprimer les données des fichiers. Maintenez les systèmes d’exploitation clients à jour et restreignez l’accès administratif local. Utilisez une protection des points de terminaison adaptée à l’environnement client. L’isolement du réseau et le chiffrement n’empêchent pas un client autorisé d’apporter des modifications destructrices.
Sécurité du réseau
Accès entrant et filtrage sortant
Limitez l’accès entrant aux clients qui en ont besoin : Les deux fournisseurs de ressources prennent en charge les points de terminaison privés et les points de terminaison de service avec des restrictions sur le réseau virtuel. L’accès aux partages de fichiers NFS Azure nécessite l’un de ces chemins. Les clients SMB classiques et FileREST peuvent également utiliser des points de terminaison publics avec des règles d’adresse IP. Pour les partages de fichiers classiques, un point de terminaison de service standard permet à une seule règle d’adresse IP de permettre de nombreux sous-réseaux pour SMB, NFS et FileREST. Pour les étapes de configuration, voir Configurer les points de terminaison réseau pour les partages de fichiers Azure.
Désactivez l’accès public lorsqu’il n’est pas nécessaire : Les points de terminaison publics peuvent être utilisés de manière sécurisée grâce à des contrôles d’accès réseau, à l’authentification et au chiffrement adaptés au protocole. Gardez l’accès public activé lorsque vos charges de travail l’exigent et que votre modèle de sécurité le permet, y compris pour les connexions via les points de terminaison de service. Créer un point de terminaison privé ne désactive pas automatiquement l’accès public. Pour les partages classiques, examinez toutes les exceptions de service ou d’instance de ressource de confiance qui peuvent rester effectives après la désactivation de l’accès public. Pour plus d’informations, voir Restreindre l’accès au point de terminaison public.
Activez l'accès aux services de confiance uniquement lorsque cela est nécessaire : Disponible uniquement pour les partages de fichiers classiques, le paramètre des services de confiance permet aux services Azure pris en charge de contourner les règles réseau du compte de stockage. Activez-le uniquement lorsqu’une intégration nécessite cet accès. Ces services doivent toujours être autorisés à accéder à vos données de fichiers.
Filtrage optionnel pour le trafic des points de terminaison de service : Lorsque les clients utilisent des points de terminaison de service pour accéder à des partages de fichiers classiques, vous pouvez éventuellement appliquer une politique de point de terminaison de service à leur sous-réseau. La politique limite les comptes de stockage auxquels ces clients peuvent accéder via les points de terminaison de service, par lesquels le trafic contourne Pare-feu Azure et les appliances virtuelles réseau. Cela ne concerne que le trafic des points de terminaison de service et ne filtre pas le trafic des points de terminaison privés ni les autres chemins sortants. Les règles réseau et exigences d’autorisation de la destination restent en vigueur. Microsoft. FileShares ne prend pas actuellement en charge ces politiques. Les clients dans un sous-réseau avec une politique doivent utiliser un point de terminaison privé pour accéder aux partages Microsoft.FileShares. Pour plus d’informations, consultez Politiques de point de terminaison de service.
Vérifiez le support des protocoles avant d’utiliser un périmètre de sécurité réseau : les périmètres de sécurité réseau ne sont disponibles que pour les partages de fichiers classiques. Pour les partages classiques, le support périmétrique varie selon le protocole et la méthode d’authentification. En mode Enforce, les clients SMB et NFS dans les réseaux virtuels Azure doivent se connecter via un point de terminaison privé, ou via un point de terminaison de service standard avec une règle d’accès entrante pour leur adresse IP. Le périmètre refuse le trafic SMB et NFS via les points de terminaison de service qui n’ont pas d’adresse IP attribuée. SMB et NFS ne prennent pas en charge l’accès de ressource à ressource entre les membres du périmètre ni les règles d’accès basées sur l’abonnement. Le trafic du point de terminaison privé est en dehors de l’application du périmètre. Vérifiez les restrictions pour la sauvegarde Azure et Azure File Sync avant d'appliquer un périmètre. Pour plus d’informations, voir Périmètre de sécurité réseau.
Durcissement du protocole SMB
Ces recommandations s’appliquent aux partages de fichiers classiques SMB.
Exigez le chiffrement des canaux SMB : Utilisez des connexions SMB 3.x chiffrées. SMB 2.1 ne prend pas en charge le chiffrement des canaux. L’exigence HTTPS pour FileREST ne remplace pas la configuration de chiffrement SMB. Pour plus d’informations, consultez le chiffrement SMB et les paramètres de sécurité.
Restreignez les versions et algorithmes des protocoles à ceux dont vos clients ont besoin : Utilisez le profil SMB le plus sécurisé compatible avec vos charges de travail. Vérifiez la prise en charge des clients avant d’exiger SMB 3.1.1 ou AES-256-GCM, car les clients incompatibles ne peuvent pas se connecter. Le chiffrement des canaux SMB et le chiffrement des tickets Kerberos sont des contrôles distincts. Pour plus d’informations, consultez les paramètres de sécurité SMB.
Limiter les méthodes d’authentification SMB : Utilisez Kerberos pour l’accès basé sur l’identité. Si aucun client n’a besoin d’authentification par clé de compte de stockage via SMB, retirez NTLMv2 des méthodes d’authentification SMB autorisées après test. Ce contrôle s’applique à SMB ; il ne désactive pas l’accès FileREST basé sur des clés.
Maintenez les identifiants AD DS lorsque cela est applicable : Pour l’authentification AD DS, gérez le mot de passe du principal de répertoire qui représente le compte de stockage selon votre politique d’annuaire. Suivez la procédure de rotation documentée pour garder le mot de passe du répertoire et la clé Kerberos du compte de stockage synchronisés. Pour plus d’informations, voir Mettre à jour le mot de passe d’identité du compte de stockage dans AD DS.
Partages de fichiers NFS 4.1
Ces recommandations s’appliquent aux partages de fichiers NFS avec l’un ou l’autre fournisseur de ressources. NFS utilise une authentification basée sur le réseau et des permissions POSIX, et non une authentification basée sur l’identité SMB.
Limitez l’accès aux réseaux de confiance : N’autorisez que les sous-réseaux et connexions privées nécessaires à la charge de travail. Le NFS s’appuie sur les identités présentées par le client, alors contrôlez quels systèmes et administrateurs peuvent utiliser ces connexions.
Gérez les permissions POSIX et les identités clients : Utilisez des identifiants d’utilisateur et des identifiants de groupe cohérents entre les clients. Restreignez les permissions de fichiers et de répertoires aux utilisateurs et groupes qui ont besoin d’accès. Les permissions Azure RBAC pour la gestion de la ressource Azure n'accordent pas l'accès aux fichiers NFS. Pour plus d’informations, voir authentification NFS et accès réseau.
Configurez le root squash lorsqu’il est compatible avec la charge de travail : le root squash mappe les requêtes de UID/GID 0 vers une identité anonyme. Il ne restreint pas d’autres identités et ne rend pas un partage en lecture seule. Pour les paramètres et les étapes de configuration des deux fournisseurs de ressources, voir Root squashing pour les partages de fichiers NFS Azure.
Exiger le chiffrement en transit : les deux fournisseurs de ressources prennent en charge TLS via l’assistance au montage AZNFS. Microsoft. FileShares nécessite par défaut un chiffrement en transit. Les partages classiques ont des paramètres de chiffrement NFS au niveau du compte de stockage. Pour les paramètres par défaut et les liens de configuration, voir chiffrement NFS.
Gestion de l’identité et de l’accès
Gestion des ressources Azure
Utilisez le privilège le moins élevé pour l’accès à la gestion : Accordez les permissions RBAC à Azure à la plus petite portée nécessaire pour créer, configurer ou supprimer des ressources. Pour les partages de fichiers classiques, les autorisations au niveau du compte peuvent affecter chaque partage de fichiers du compte. Vous pouvez gérer les ressources Microsoft.FileShares de façon indépendante. Les rôles de gestion et les autorisations d’accès aux données ont des objectifs différents. Pour plus d’informations, consultez Azure plan de contrôle et plan de données.
Limiter l’accès administratif en permanence : Utilisez Microsoft Entra Privileged Identity Management lorsque cela est approprié pour des rôles Azure privilégiés. Exigez l’approbation et une authentification multifacteur pour l’activation administrative selon la politique de votre organisation. Pour plus d’informations, consultez Privileged Identity Management.
Authentification basée sur l’identité pour les partages de fichiers SMB
L’accès basé sur l’identité SMB est disponible pour les partages de fichiers classiques. Une clé de compte de stockage accorde un accès large aux données à travers les partages d’un compte et n’identifie pas un utilisateur individuel.
Utilisez une source d’identité prise en charge par vos clients : Azure Files prend en charge AD DS, Microsoft Entra Domain Services et Microsoft Entra Kerberos. Leurs exigences en matière de client et d’identité diffèrent. Pour les scénarios pris en charge et les guides de configuration, voir Authentification basée sur l’identité pour Azure Files.
Utilisez des identités gérées pour les charges de travail des applications prises en charge : Les identités gérées peuvent fournir un accès SMB sans distribuer les clés de compte de stockage. Vérifiez les prérequis de compute, de client et d’authentification pour votre déploiement. Pour plus d’informations, voir Accéder aux partages SMB en utilisant des identités gérées.
Protégez les clés de compte lorsque elles sont requises : Restreignez les autorisations pour récupérer ou régénérer des clés. Stockez les clés requises dans Azure Key Vault et faites-les pivoter après exposition ou selon votre politique relative aux informations d’identification. Planifiez la rotation des clés pour les clients et les intégrations qui utilisent encore les clés. Pour plus d’informations, consultez Gérer les clés d’accès au compte de stockage.
Permissions au niveau du partage et NTFS
Ces autorisations s’appliquent aux partages de fichiers SMB classiques.
Attribuer des rôles au niveau du partage à la portée requise : accorder un accès en lecture, en écriture ou administratif uniquement aux identités qui en ont besoin. Les attributions de rôles au niveau des partages évitent d’accorder l’accès à des partages non liés dans le même compte de stockage. Pour plus d’informations, consultez Affecter des autorisations au niveau du partage.
Appliquer les permissions de répertoire et de fichiers : Utilisez les ACL Windows, y compris dans le répertoire racine du partage si nécessaire, pour contrôler l'accès au sein du partage. Utilisez l’héritage pour garder les autorisations faciles à gérer. Les permissions au niveau du partage et les ACL Windows sont toutes deux appliquées. Pour plus d’informations, consultez Configurer les autorisations au niveau du répertoire et des fichiers.
Restreindre l’administration des autorisations : Limiter les rôles élevés et les droits de modification ACL aux identités responsables de la gestion des autorisations. Examinez à la fois les attributions de rôles et les ACL héritées lorsque les exigences d’accès changent.
Accès FileREST et SAS
L’accès aux données FileREST est disponible pour les partages classiques. Microsoft. FileShares ne prend pas actuellement en charge l'accès aux données FileREST.
Utilisez OAuth pour un accès aux données administratives pris en charge : les identités Microsoft Entra, y compris les identités gérées, peuvent accéder aux partages classiques via FileREST. Les rôles privilégiés utilisés par cette méthode d’accès peuvent contourner les permissions de fichiers et de répertoires, donc ne les accordez que lorsque cet accès est nécessaire. Pour plus d’informations, voir Azure Files OAuth over REST.
Limitez les permissions SAS et la durée de vie : lorsqu’un outil pris en charge nécessite une signature d’accès partagée (SAS), restreignez sa portée, ses permissions et sa période de validité, et exigez HTTPS. Protégez le SAS en tant qu’informations d’identification. Les jetons SAS ne sont pas utilisés pour monter des partages via SMB ou NFS. Pour plus d’informations, voir Signatures d’accès partagées.
Exiger HTTPS pour FileREST : HTTPS protège les requêtes REST en transit. Le chiffrement des canaux SMB et le tunneling TLS NFS sont distincts de l’exigence HTTPS. Pour les étapes de configuration, voir FileREST chiffrement en transit.
Protection de données
Comprendre le chiffrement au repos : Les deux fournisseurs de ressources chiffrent par défaut les données de fichiers au repos avec des clés gérées par Microsoft. Le chiffrement au repos protège les données stockées ; il n’empêche pas les clients autorisés de lire ou de modifier les fichiers.
Utilisez des clés gérées par le client lorsque nécessaire : Les partages classiques prennent en charge les clés gérées par le client dans Azure Key Vault ou HSM géré. Microsoft. FileShares ne prend pas actuellement en charge les clés gérées par le client. Protégez le stockage de clés, planifiez la rotation des clés, et comprenez que la perte d’accès aux clés peut rendre les données indisponibles. Pour plus d’informations, voir Clés gérées par le client pour Azure Files.
Évaluez le chiffrement de l’infrastructure pour les déploiements classiques applicables : Les comptes de stockage classiques peuvent disposer d’une couche de chiffrement supplémentaire lorsque votre politique de conformité l’exige. Cette option est sélectionnée lors de la création du compte et ne peut pas être modifiée par la suite. Pour plus d’informations, voir Chiffrement de l’infrastructure.
Utilisez des verrous de ressources pour protéger les opérations de gestion : Un verrou CanNotDelete sur la ressource Azure appropriée ou l’étendue parente peut empêcher la suppression via Azure Resource Manager. Les verrous n’empêchent pas les clients de modifier ou de supprimer les données des fichiers. Pour les partages classiques, ils n’empêchent pas non plus la suppression via les API de data-plane FileREST. Pour le comportement des verrous et les effets opérationnels, voir Verrouiller des ressources Azure.
Sauvegarde et récupération
Prenez des instantanés de partage selon les besoins de récupération : Les deux fournisseurs de ressources prennent en charge les instantanés de partage pour la récupération des versions antérieures de fichiers. Établissez un planning et une politique de rétention qui répondent à vos objectifs de rétablissement. Les instantanés de partage restent associés au partage source, ils ne fournissent donc pas de sauvegarde indépendante si ce partage est supprimé définitivement. Pour plus d’informations, voir Partager les instantanés pour Azure Files.
Activez la suppression réversible pour les partages classiques : La suppression réversible conserve les partages supprimés pendant une période configurée. Il ne récupère pas de fichiers individuels ni de snapshots supprimés individuellement. Microsoft.FileShares ne prend actuellement pas en charge la suppression réversible. Pour plus d’informations, consultez Prévenir la suppression accidentelle de partages de fichiers Azure.
Choisissez une solution de sauvegarde prise en charge par le protocole : Sauvegarde Azure prend en charge les partages classiques SMB, avec des options snapshot et sauvegarde voûtée. Il ne prend actuellement pas en charge les partages NFS avec aucun des deux fournisseurs de ressources. Pour NFS, choisissez une solution de sauvegarde qui prend en charge le protocole et répond à vos exigences de rétention et d’isolement. Pour la couverture Sauvegarde Azure, voir la prise en charge de la sauvegarde des partages de fichiers Azure Files.
Séparer l’administration des sauvegardes et les tests de récupération : limitez qui peut supprimer les points de récupération ou modifier la rétention. Testez les restaurations de fichiers, des autorisations et des charges de travail complètes. Vérifiez que la récupération reste possible si les identifiants de production ou le partage source sont compromis.
Prévoyez les défaillances d’infrastructure séparément de la récupération des données : la redondance améliore la résilience face aux défaillances d’infrastructure mais reproduit également les modifications des données. Il ne remplace pas les sauvegardes en cas de modifications ou de suppressions indésirables. Les options de redondance disponibles varient selon le niveau média et le fournisseur de ressources. Pour plus d’informations, consultez Redondance d’Azure Files.
Enregistrement et surveillance
Auditer les modifications de gestion pour les deux fournisseurs de ressources : Utilisez le journal d’activité Azure pour surveiller la suppression des ressources, les modifications de configuration et les attributions de rôles. Examinez les modifications concernant l’accès public, les règles réseau, les exigences de chiffrement et les contrôles de récupération. Pour plus d’informations, consultez le journal d’activité Azure.
Collectez les journaux d’accès aux données pris en charge : Pour les accès classiques SMB et FileREST, utilisez les journaux de ressources de service de fichiers pour examiner les appelants, les méthodes d’autorisation, les requêtes échouées et les activités de suppression. Collectez les journaux requis par votre politique de rétention dans Log Analytics ou une autre destination prise en charge. Ne supposez pas la même couverture de la journalisation des requêtes pour NFS ou Microsoft.FileShares. Pour les opérations et champs pris en charge, voir Azure Files Monitoring Data Reference.
Corréliez les alertes avec les journaux clients et d’identité : Enquêtez sur l’utilisation inattendue de clés, l’authentification ratée, la suppression des partages et les modifications de configuration de sécurité. Utilisez les journaux clients et de répertoire lorsqu’une défaillance d’authentification survient avant que la requête n’atteigne Azure Files. Acheminez les alertes vers l’équipe responsable de la charge de travail.
Évaluer Defender for Storage pour les déploiements classiques : Defender for Storage permet de détecter les menaces pour les comptes de stockage pris en charge. Vérifiez la couverture des fonctionnalités et des protocoles pour votre déploiement ; la protection du compte n’implique pas que chaque opération de fichier soit analysée pour détecter des malwares. Pour plus d’informations, voir Microsoft Defender for Storage.
Gouvernance et conformité
Appliquer des politiques correspondant au fournisseur de ressources : Utilisez Azure Policy pour auditer ou faire respecter les exigences de votre organisation lorsque le type de ressource et les propriétés sont pris en charge. Vérifiez la portée et les effets de chaque définition. Une politique ciblant les comptes de stockage Microsoft.Storage n’évalue pas automatiquement les ressources Microsoft.FileShares. Pour plus d’informations, consultez les Définitions Azure Policy.
Propriété des enregistrements et exigences en matière de données : Utilisez des balises de ressources pour identifier l’équipe responsable, l’environnement et la classification des données. Pour les partages classiques, les contrôles au niveau du compte affectent tous les partages du compte. Enregistrez les exceptions et révisez-les lorsque le responsable de la charge de travail change.
Validez la conformité du déploiement : Confirmez que les caractéristiques de service, région, protocole et protection sélectionnées répondent à vos exigences. Utilisez le benchmark de sécurité cloud de Microsoft pour organiser les revues de contrôle. Pour des informations sur la certification, consultez les offres de conformité stockage Azure.
Azure File Sync
Azure File Sync prend en charge les partages classiques SMB. Il ne prend pas en charge NFS ni Microsoft.FileShares. Sécurisez à la fois le partage cloud et les points de terminaison Windows Server.
Utilisez des identités gérées pour les déploiements de synchronisation de fichiers pris en charge : suivez la configuration de l’identité gérée pour le Storage Sync Service et les serveurs enregistrés afin de supprimer la dépendance aux clés partagées. Pour plus d’informations, voir Utiliser des identités gérées avec Azure File Sync.
Limitez l’accès administratif aux ressources de synchronisation et aux serveurs : Utilisez les rôles Storage Sync requis dans le cadre approprié. Protégez les permissions locales des fichiers et l’administration des serveurs car les modifications effectuées via un point de terminaison serveur peuvent être synchronisées avec le partage cloud. Pour plus d’informations, voir Planifier un déploiement Azure File Sync.