Prise en charge du protocole SFTP SSH pour Stockage Blob Azure

Article
04/12/2024

Stockage Blob prend désormais en charge le protocole SFTP. Cette prise en charge vous permet de vous connecter de manière sécurisée au stockage Blob via un point de terminaison SFTP, ce qui vous permet d’utiliser SFTP pour l’accès aux fichiers, le transfert de fichiers et la gestion des fichiers.

Voici une vidéo qui vous en dit plus.

Azure permet le transfert sécurisé de données vers des comptes Stockage Blob à l’aide de l’API REST du service BLOB d’Azure, des Kits de développement logiciel (SDK) Azure et d’outils tels qu’AzCopy. Toutefois, les charges de travail héritées utilisent souvent des protocoles de transfert de fichiers traditionnels tels que SFTP. Vous pouvez mettre à jour des applications personnalisées pour utiliser l’API REST et les Kits de développement logiciel (SDK) Azure, mais uniquement en apportant des modifications importantes au code.

Avant la publication de cette fonctionnalité, si vous vouliez utiliser SFTP pour transférer des données vers Stockage Blob Azure, vous deviez soit acheter un produit tiers, soit orchestrer votre propre solution. Pour les solutions personnalisées, vous devez créer des machines virtuelles (VM) dans Azure pour héberger un serveur SFTP, puis mettre à jour, corriger, gérer, mettre à l’échelle et maintenir une architecture complexe.

Désormais, grâce à la prise en charge de SFTP pour Stockage Blob Azure, vous pouvez activer un point de terminaison SFTP pour les comptes Stockage Blob avec un seul clic. Vous pouvez ensuite configurer des identités d’utilisateur locales pour l’authentification afin de vous connecter à votre compte de stockage avec le SFTP via le port 22.

Cet article décrit la prise en charge de SFTP pour Stockage Blob Azure. Pour savoir comment activer SFTP pour votre compte de stockage, consultez Se connecter à Stockage Blob Azure à l’aide du protocole SFTP (SSH File Transfer Protocol).

Notes

SFTP est un service au niveau de la plateforme. Le port 22 est donc ouvert même si l’option de compte est désactivée. Si l’accès SFTP n’est pas configuré, toutes les demandes reçoivent une déconnexion du service.

SFTP et l’espace de noms hiérarchique

La prise en charge de SFTP nécessite l’activation de l’espace de noms hiérarchique. L’espace de noms hiérarchique organise les objets (fichiers) selon une hiérarchie de répertoires et sous-répertoires, de la même façon que le système de fichiers sur votre ordinateur. L’espace de noms hiérarchique est mis à l’échelle de façon linéaire, et ne dégrade pas la capacité ou les performances des données.

Différents protocoles sont pris en charge par l’espace de noms hiérarchique. Le SFTP est l’un de ces protocoles disponibles. L’image suivante montre l’accès au stockage avec plusieurs protocoles et l’API REST. Par souci de clarté, cette image utilise le terme REST Gen2 pour faire référence à l’API REST Azure Data Lake Storage Gen2.

espace de noms hiérarchique

Modèle d’autorisation SFTP

Le Stockage Blob Azure ne prend pas en charge l’authentification ou l’autorisation Microsoft Entra via SFTP. Au lieu de cela, SFTP utilise une nouvelle forme de gestion des identités appelée utilisateurs locaux.

Les utilisateurs locaux doivent utiliser un mot de passe ou une clé privée Secure Shell (SSH) pour s’identifier. Vous pouvez avoir un maximum de 2000 utilisateurs locaux pour un compte de stockage.

Pour configurer les autorisations d’accès, vous allez créer un utilisateur local et choisir des méthodes d’authentification. Ensuite, pour chaque conteneur dans votre compte, vous pouvez spécifier le niveau d’accès que vous souhaitez accorder à cet utilisateur.

Attention

Les utilisateurs locaux n’interagissent pas avec d’autres modèles d’autorisation stockage Azure tels que RBAC (contrôle d’accès en fonction du rôle) et ABAC (contrôle d’accès basé sur des attributs). Les listes de contrôle d’accès (listes de contrôle d’accès) sont prises en charge pour les utilisateurs locaux au niveau de la préversion.

Par exemple, Jeff dispose d’une autorisation en lecture seule (peut être contrôlée via RBAC ou ABAC) via son identité Microsoft Entra pour le fichier foo.txt stocké dans le conteneur con1. Si Jeff accède au compte de stockage via NFS (lorsqu’il n’est pas monté en tant que racine/superutilisateur), REST d’objet blob ou Data Lake Storage Gen2 REST, ces autorisations sont appliquées. Toutefois, si Jeff a également une identité d’utilisateur locale avec l’autorisation de suppression pour les données dans le conteneur con1, ils peuvent supprimer foo.txt via SFTP à l’aide de l’identité utilisateur locale.

Pour les comptes de stockage prenant en charge SFTP, vous pouvez utiliser la gamme complète de paramètres de sécurité Azure blob Stockage pour authentifier et autoriser les utilisateurs qui accèdent à Stockage blob via le Portail Azure, Azure CLI, des commandes Azure PowerShell, AzCopy, ainsi que des kits de développement logiciel Azure et des API REST Azure. Pour en savoir plus, voir Modèle de contrôle d’accès dans Azure Data Lake Storage Gen2.

Méthodes d’authentification

Vous pouvez authentifier des utilisateurs locaux se connectant via FTP à l’aide d’un mot de passe ou d’une paire de clés publique-privée Secure Shell (SSH). Vous pouvez configurer les deux formes d’authentification et laisser les utilisateurs locaux qui se connectent choisir celle à utiliser. Toutefois, l’authentification multifacteur, qui requiert à la fois un mot de passe valide et une paire de clés publique-privée valide pour une authentification réussie, n’est pas prise en charge.

Mots de passe

Vous ne pouvez pas définir de mots de passe personnalisés, c’est Azure qui en génère un pour vous. Si vous choisissez l’authentification par mot de passe, votre mot de passe est fourni une fois que vous avez terminé la configuration d’un utilisateur local. Veillez à copier ce mot de passe et à l’enregistrer à un emplacement où vous pourrez le retrouver ultérieurement. Vous ne pourrez pas récupérer ce mot de passe à partir d’Azure. Si vous perdez le mot de passe, vous devrez en générer un nouveau. Pour des raisons de sécurité, vous ne pouvez pas définir vous-même le mot de passe.

Paires de clés SSH

Une paire de clés publique-privée est la forme la plus courante d’authentification pour Secure Shell (SSH). La clé privée est secrète et ne doit être connue que de l’utilisateur local. La clé publique est stockée dans Azure. Lorsqu’un client SSH se connecte au compte de stockage à l’aide d’une identité d’utilisateur local, il envoie un message contenant la clé publique et la signature. Azure valide le message et vérifie que l’utilisateur et la clé sont reconnus par le compte de stockage. Pour en savoir plus, consultez Vue d’ensemble de SSH et des clés.

Si vous choisissez de vous authentifier avec une paire de clés publique-privée, vous pouvez en générer une, en utiliser une déjà stockée dans Azure ou fournir à Azure la clé publique d’une paire de clés publique-privée existante. Vous pouvez avoir un maximum de 10 clés publiques par utilisateur local.

Autorisations du conteneur

Pour les autorisations au niveau du conteneur, vous pouvez choisir les conteneurs auxquels vous souhaitez accorder l’accès et le niveau d’accès à fournir (lecture, écriture, liste, suppression, créer, modifier la propriété et modifier les autorisations). Ces autorisations s’appliquent à tous les répertoires et sous-répertoires du conteneur. Vous pouvez accorder à chaque utilisateur local un accès à un maximum de 100 conteneurs. Les autorisations de conteneur peuvent également être mises à jour après la création d’un utilisateur local. Le tableau suivant décrit chaque autorisation plus en détail.

Autorisation	Symbole	Description
Lire	r	Lire le contenu du fichier
Write	w	Charger le fichier Créer un répertoire Répertoire du téléchargement
List	l	Répertorier le contenu dans le conteneur Répertorier le contenu dans le répertoire
Supprimer	d	Supprimer un fichier/répertoire
Créer	c	Charger le fichier s’il n’existe pas Créer le répertoire s’il n’existe pas
Modifier la propriété	o	Modifier l’utilisateur ou le groupe propriétaire d’un fichier/répertoire
Modifier les autorisations	p	Modifier les autorisations pour le fichier/répertoire

Lors de l’exécution d’opérations d’écriture sur des objets blob dans des sous-répertoires, l’autorisation lecture est nécessaire pour ouvrir le répertoire et accéder aux propriétés d’objet blob.

listes de contrôle d'accès

Pour les autorisations au niveau du répertoire ou de l’objet blob, vous pouvez modifier l’utilisateur propriétaire, le groupe propriétaire et le mode utilisés par les ACL ADLS Gen2. La plupart des clients SFTP exposent des commandes pour modifier ces propriétés. Le tableau suivant décrit plus en détail les commandes courantes.

Commande	Autorisation de conteneur requise	Description
Chown	o	Modifier l’utilisateur propriétaire du fichier/répertoire Doit spécifier l’ID numérique
chgrp	o	Modifier le groupe propriétaire du fichier/répertoire Doit spécifier l’ID numérique
chmod	p	Modifier les autorisations/le mode pour le fichier/répertoire Doit spécifier des autorisations octal de style POSIX

Les ID requis pour modifier l’utilisateur propriétaire et le groupe propriétaire font partie de nouvelles propriétés pour les utilisateurs locaux. Le tableau suivant décrit plus en détail chaque nouvelle propriété Utilisateur local.

Propriété	Description
ID utilisateur	Identificateur unique de l’utilisateur local dans le compte de stockage Généré par défaut lorsque l’utilisateur local est créé Utilisé pour définir l’utilisateur propriétaire sur le fichier/répertoire
GroupId	Identifer pour un groupe d’utilisateurs locaux Utilisé pour définir le groupe propriétaire sur le fichier/répertoire
AllowAclAuthorization	Autoriser les demandes de cet utilisateur local avec des listes de contrôle d’accès

Une fois que les listes de contrôle d’accès souhaitées ont été configurées et que l’utilisateur local active AllowAclAuthorization, ils peuvent utiliser des listes de contrôle d’accès pour autoriser leurs demandes. Comme pour RBAC, les autorisations de conteneur peuvent interagir avec les listes de contrôle d’accès. Uniquement si l’utilisateur local n’a pas suffisamment d’autorisations de conteneur, les listes de contrôle d’accès sont évaluées. Pour en savoir plus, voir Modèle de contrôle d’accès dans Azure Data Lake Storage Gen2.

Répertoire de base

Quand vous configurez des autorisations, vous avez la possibilité de définir un répertoire de base pour l’utilisateur local. Si aucun autre conteneur n’est spécifié dans une demande de connexion SFTP, le répertoire d’accueil est le répertoire auquel l’utilisateur se connecte par défaut. Par exemple, considérez la requête suivante effectuée en utilisant Open SSH. Cette requête ne spécifie pas de nom de conteneur ou de répertoire dans le cadre de la commande sftp.

sftp myaccount.myusername@myaccount.blob.core.windows.net
put logfile.txt

Si vous définissez le répertoire de base d’un utilisateur sur mycontainer/mydirectory, le client se connecte alors à ce répertoire. Ensuite, le fichier logfile.txt sera chargé dans mycontainer/mydirectory. Si vous n’avez pas défini le répertoire de base, la tentative de connexion échoue. Au lieu de cela, les utilisateurs qui se connectent doivent spécifier un conteneur avec la demande, puis utiliser les commandes SFTP pour accéder au répertoire cible avant de charger un fichier. L’exemple suivant illustre cela :

sftp myaccount.mycontainer.myusername@myaccount.blob.core.windows.net
cd mydirectory
put logfile.txt

Notes

Le répertoire de départ est uniquement le répertoire initial dans lequel est placé l’utilisateur local qui se connecte. Les utilisateurs locaux peuvent accéder à n’importe quel chemin d’accès dans le conteneur auquel ils sont connectés s’ils disposent des autorisations de conteneur appropriées.

Algorithmes pris en charge

Vous pouvez utiliser de nombreux clients SFTP différents pour vous connecter et transférer des fichiers en toute sécurité. Les clients qui se connectent doivent utiliser des algorithmes spécifiés dans le tableau ci-dessous.

Type	Algorithm
Clé hôte ¹	rsa-sha2-256 ² rsa-sha2-512 ² ecdsa-sha2-nistp256 ecdsa-sha2-nistp384
Échange de clés	ecdh-sha2-nistp384 ecdh-sha2-nistp256 diffie-hellman-group14-sha256 diffie-hellman-group16-sha512 diffie-hellman-group-exchange-sha256
Chiffrements/chiffrement	aes128-gcm@openssh.com aes256-gcm@openssh.com aes128-ctr aes192-ctr aes256-ctr
Intégrité/MAC	hmac-sha2-256 hmac-sha2-512 hmac-sha2-256-etm@openssh.com hmac-sha2-512-etm@openssh.com
Clé publique	ssh-rsa ² rsa-sha2-256 rsa-sha2-512 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521

¹ Les clés d’hôte sont publiées ici. ² Les clés RSA doivent avoir une longueur minimale de 2048 bits.

La prise en charge de SFTP pour Azure Blob Stockage limite actuellement la prise en charge de son algorithme de chiffrement en fonction des considérations de sécurité. Nous recommandons vivement aux clients d’utiliser des algorithmes approuvés par Microsoft Security Development Lifecycle (SDL) pour accéder en toute sécurité à leurs données.

À ce jour et conformément au Microsoft Security SDL, nous ne prévoyons pas de prendre en charge les éléments suivants : ssh-dss, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1, hmac-sha1, hmac-sha1-96. La prise en charge des algorithmes est susceptible d’être modifiée à l’avenir.

Connexion avec SFTP

Pour commencer, activez la prise en charge de SFTP, créez un utilisateur local et attribuez des autorisations à cet utilisateur local. Vous pouvez dès lors utiliser n’importe quel client SFTP pour vous connecter et transférer des fichiers en toute sécurité. Pour obtenir des instructions pas à pas, consultez Se connecter au Stockage Blob Azure à l’aide du protocole SFTP SSH (préversion).

Clients connus pris en charge

Les clients suivants offrent une prise en charge de l’algorithme compatible avec SFTP pour Stockage Blob Azure. Consultez Limitations et problèmes connus avec la prise en charge du protocole SSH SFTP (Secure File Transfer Protocol) dans le service Stockage Blob Azure si vous rencontrez des problèmes de connexion. Cette liste n’est pas exhaustive et peut être amenée à évoluer.

AsyncSSH 2.1.0+
Axway
Cyberduck 7.8.2+
edtFTPjPRO 7.0.0+
FileZilla 3.53.0+
libssh 0.9.5+
Maverick Legacy 1.7.15+
Moveit 12.7
OpenSSH 7.4+
paramiko 2.8.1+
phpseclib 1.0.13+
PuTTY 0.74+
QualysML 12.3.41.1+
RebexSSH 5.0.7119.0+
Salesforce
ssh2js 0.1.20+
sshj 0.27.0+
SSH.NET 2020.0.0+
WinSCP 5.10+
Workday
XFB.Gateway
JSCH 0.1.54+
curl 7.85.0+
AIX¹
MobaXterm v21.3

¹ L’option AllowPKCS12KeystoreAutoOpen doit être définie sur no.

Limitations et problèmes connus

Consultez l’article Limitations et problèmes connus pour obtenir la liste complète des limitations et problèmes liés à la prise en charge de SFTP pour Stockage Blob Azure.

Tarification et facturation

L’activation du point de terminaison SFTP a un coût horaire. Pour obtenir les informations les plus récentes sur la tarification, consultez la Tarification Stockage Blob Azure.

Conseil

Pour éviter les frais passifs, songez à activer le protocole SFTP uniquement lorsque vous l’utilisez activement pour transférer des données. Pour obtenir des conseils sur l’activation et la désactivation de la prise en charge du protocole SFTP, consultez Se connecter au Stockage Blob Azure à l’aide du protocole SFTP (SSH File Transfer Protocol).

Les prix des transactions, du stockage et du réseau pour le compte de stockage sous-jacent s’appliquent. Toutes les transactions SFTP sont converties en transactions de lecture, d'écriture ou autres sur vos comptes de stockage. Cela inclut toutes les commandes SFTP et les appels d'API. Pour en savoir plus, consultez Comprendre le modèle de facturation complet pour Stockage Blob Azure.