Configurez le chiffrement en transit pour Azure Files

Cet article explique comment exiger et utiliser le chiffrement lors du transit pour Azure Files. Chaque protocole possède son propre mécanisme de chiffrement et ses propres paramètres :

• SMB : Chiffrement des canaux SMB 3.x. Voir SMB.
• NFS : Chiffrement TLS grâce à l’assistant de montage AzNFS. Voir NFS.
• FileREST : HTTPS avec TLS. Voir FileREST.

Pour un aperçu du chiffrement en transit pour chaque protocole, voir Considérations relatives à la mise en réseau Azure Files. Pour Microsoft. FileShares, vous définissez l’exigence de chiffrement en transit pour chaque partage de fichiers. Voir Créer un partage de fichiers et Modifier un partage de fichiers. Microsoft. FileShares ne prend pas en charge FileREST.

Paramètres du chiffrement en transit

Les partages de fichiers classiques disposent d’un paramètre de chiffrement séparé en transit pour chaque protocole. Le transfert sécurisé requis était le réglage initial des trois protocoles. Pour la rétrocompatibilité, il contrôle toujours le chiffrement SMB et NFS tant que vous n’avez pas configuré le paramètre correspondant.

Les paramètres SMB et NFS commencent comme Non sélectionnés pour :

• Comptes de stockage existants.
• Comptes de stockage créés en utilisant Azure PowerShell, Azure CLI ou l’API REST du fournisseur de ressources stockage Azure.

Pour les comptes de stockage créés via le portail Azure, les deux paramètres sont activés par défaut.

Après avoir configuré le paramètre SMB ou NFS, il a priorité sur le transfert sécurisé requis pour le protocole concerné. Vous pouvez changer le paramètre entre Activé et Désactivé, mais vous ne pouvez pas le remettre sur Non sélectionné.

SMB

Azure Files chiffre le trafic SMB en utilisant le chiffrement du canal SMB 3.x. Le paramètre Exiger le chiffrement en transit pour SMB détermine si Azure Files nécessite le chiffrement en transit pour l’accès SMB aux partages de fichiers dans un compte de stockage. Lorsque ce paramètre est activé, Azure Files n’autorise que les montages SMB 3.x utilisant le chiffrement des canaux. Azure Files rejette les montages des clients qui ne prennent pas en charge SMB 3.x avec le chiffrement des canaux. SMB 2.1 ne prend pas en charge le chiffrement, donc Azure Files rejette tous les montages SMB 2.1. Pour la valeur par défaut et le fonctionnement de ce paramètre avec Transfert sécurisé requis, voir Paramètres de chiffrement en transit.

Pour les algorithmes de chiffrement des canaux SMB pris en charge et les autres paramètres de sécurité SMB, voir Paramètres de sécurité SMB.

$params = @{
    ResourceGroupName = "<resource-group>"
    StorageAccountName = "<storage-account-name>"
    SmbEncryptionInTransitRequired = $true
}
Update-AzStorageFileServiceProperty @params

az storage account file-service-properties update \
    --resource-group <resource-group> \
    --account-name <storage-account-name> \
    --require-smb-encryption-in-transit true

NFS

Les partages de fichiers NFSv4.1 d’Azure Files prennent en charge le chiffrement lors du transit via un tunnel TLS. TLS protège les données en transit contre toute interception, y compris les attaques man-in-the-middle. Pour installer l’assistant de montage AzNFS et monter un partage de fichiers avec chiffrement en transit, voir Monter des partages de fichiers Azure NFS sur Linux.

Comment fonctionne le chiffrement en transit

Azure Files utilise stunnel, un wrapper TLS open source, pour chiffrer la connexion TCP entre le client NFS et Azure Files. Avec l’assistant de montage AzNFS, la connexion utilise TLS 1.2 ou TLS 1.3 avec un chiffrement AES-256-GCM. Vous n'avez pas besoin de Kerberos ni d'un système d'authentification externe comme Active Directory.

Le package d’assistant de montage AzNFS installe et configure stunnel sur le client. AzNFS est disponible sur packages.microsoft.com. Il crée un point de terminaison local qui transmet les requêtes client NFS via une connexion chiffrée. AzNFS a ces composants :

• Assistant de montage AzNFS : monte les partages de fichiers NFSv4.1 via un tunnel TLS.

• Processus Stunnel : Un processus pour chaque compte de stockage. Il écoute le trafic client NFS sur un port local et transfère le trafic via TLS vers Azure Files.

• AzNFS watchdog : Un service en arrière-plan qui maintient les processus stunnel en fonctionnement, redémarre les tunnels terminés et supprime les processus inutilisés après que tous les montages NFS associés ont été démontés.

Appliquer le chiffrement en transit

Le paramètre Exiger le chiffrement en transit pour NFS détermine si Azure Files exige le chiffrement en transit pour l’accès NFS aux partages de fichiers dans un compte de stockage. Pour permettre à la fois des montages TLS et non-TLS sur le même compte de stockage, désactivez ce paramètre. Pour la valeur par défaut et le fonctionnement de ce paramètre avec Transfert sécurisé requis, voir Paramètres de chiffrement en transit.

$params = @{
    ResourceGroupName = "<resource-group>"
    StorageAccountName = "<storage-account-name>"
    NfsEncryptionInTransitRequired = $true
}
Update-AzStorageFileServiceProperty @params

az storage account file-service-properties update \
    --resource-group <resource-group> \
    --account-name <storage-account-name> \
    --require-nfs-encryption-in-transit true

FileREST

Les requêtes FileREST utilisent HTTPS pour chiffrer les données en transit. Deux paramètres de compte de stockage contrôlent le chiffrement FileREST pour les partages de fichiers classiques :

• Transfert sécurisé requis : Lorsque ce paramètre est activé, le compte de stockage rejette les requêtes FileREST effectuées via HTTP. Les nouveaux comptes de stockage ont ce réglage activé par défaut. Gardez-le activé. L’option de le désactiver existe pour la rétrocompatibilité avec les anciennes applications qui utilisent HTTP pour accéder à d’autres données du compte de stockage. Avant l’existence des paramètres SMB et NFS, désactiver Secure transfer required était également la seule façon d’autoriser un accès SMB ou NFS non chiffré. Pour permettre un accès SMB ou NFS non chiffré maintenant, désactivez plutôt le paramètre du protocole concerné. Voir les paramètres du chiffrement en transit.
• Version TLS minimale : Azure Files accepte TLS 1.2 et TLS 1.3 pour HTTPS. stockage Azure n’accepte plus TLS 1.0 ni TLS 1.1 pour les requêtes HTTPS, donc TLS 1.2 est la version minimale la plus basse que vous pouvez définir. Tu ne peux pas définir TLS 1.3 comme minimum. Une requête FileREST utilisant une version TLS antérieure au minimum échoue avec le code d’état HTTP 400 (mauvaise requête). Les clients négocient TLS 1.3 lorsqu’ils le supportent.

Azure Policy a des définitions de politique intégrées qui vérifient ou exigent ces paramètres pour les comptes de stockage. Voir la section Stockage dans les définitions intégrées de politique d’Azure Policy.

Les versions actuelles des bibliothèques clientes stockage Azure, d’Azure PowerShell et d’Azure CLI utilisent TLS 1.2 ou une version ultérieure. Si une application ciblant une version plus ancienne de .NET Framework ne peut pas se connecter, consultez les meilleures pratiques de sécurité de la couche de transport (TLS) avec .NET Framework.

Configurez les paramètres de chiffrement FileREST

Les étapes suivantes nécessitent un transfert sécurisé et définissent la version TLS minimale sur TLS 1.2 pour un compte de stockage.

$params = @{
    ResourceGroupName = "<resource-group>"
    Name = "<storage-account-name>"
    EnableHttpsTrafficOnly = $true
    MinimumTlsVersion = "TLS1_2"
}
Set-AzStorageAccount @params

az storage account update \
    --resource-group <resource-group> \
    --name <storage-account-name> \
    --https-only true \
    --min-tls-version TLS1_2

Contenu connexe

• Considérations relatives aux réseaux Azure Files
• Chiffrement au repos pour Azure Files