Prise en charge du protocole SFTP SSH pour Stockage Blob Azure
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 client 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 la prise en charge 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. Pour faciliter la lecture, cette image utilise le terme REST pour faire référence à l’API REST d’Azure Data Lake Storage.
Modèle d’autorisation SFTP
Les clients SFTP ne peuvent pas être autorisés en utilisant les identités Microsoft Entra. 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 8 000 utilisateurs locaux pour un compte de stockage.
Pour configurer les autorisations d’accès, vous créez 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 (ACL) 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 REST Data Lake Storage, ces autorisations seront 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.
L’activation de la prise en charge de SFTP n’empêche pas d’autres types de clients d’utiliser Microsoft Entra ID. Pour les utilisateurs qui accèdent au Stockage Blob à l’aide du portail Azure, d’Azure CLI, des commandes Azure PowerShell, d’AzCopy, ainsi que des kits de développement logiciel (SDK) Azure et des API REST Azure, vous pouvez continuer à utiliser l’étendue complète du paramètre de sécurité Stockage Blob Azure pour autoriser l’accès. Pour en savoir plus, consultez Modèle de contrôle d’accès dans Azure Data Lake Storage.
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 devez 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 | |
Write | w | |
List | l | |
Supprimer | d | |
Créer | c | |
Modifier la propriété | o | |
Modifier les autorisations | p |
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 ACL
Important
Cette capacité est actuellement disponible en PRÉVERSION. Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.
Les ACL vous permettent d’accorder un accès « granulaire », tel qu’un accès en écriture à un répertoire ou un fichier spécifique. Pour en savoir plus sur les listes de contrôle d’accès, consultez Listes de contrôle d’accès (ACL) dans Azure Data Lake Storage.
Pour autoriser un utilisateur local à l’aide des ACL, vous devez d’abord activer l’autorisation ACL pour cet utilisateur local. Consultez Accorder l’autorisation aux conteneurs.
Remarque
Bien qu’une liste de contrôle d’accès puisse définir le niveau d’autorisation pour de nombreux types d’identités différents, seul l’utilisateur propriétaire, le groupe propriétaire et toutes les autres identités d’utilisateurs peuvent être utilisées pour autoriser un utilisateur local. Les utilisateurs et les groupes nommés ne sont pas encore pris en charge pour l’autorisation des utilisateurs locaux.
Le tableau suivant décrit les propriétés d’un utilisateur local utilisé pour l’autorisation ACL.
Propriété | Description |
---|---|
ID utilisateur | |
GroupId | |
AllowAclAuthorization |
Comment les autorisations de liste de contrôle d’accès sont évaluées
Les listes de contrôle d’accès sont évaluées uniquement si l’utilisateur local n’a pas les autorisations de conteneur nécessaires pour effectuer une opération. En raison de la façon dont les autorisations d’accès sont évaluées par le système, vous ne pouvez pas utiliser une liste de contrôle d’accès pour limiter l’accès qui a déjà été accordé par les autorisations au niveau du conteneur. Cela est dû au fait que le système évalue d’abord les autorisations de conteneur et si ces autorisations accordent une autorisation d’accès suffisante, les listes de contrôle d’accès sont ignorées.
Important
Pour accorder à un utilisateur local un accès en lecture ou en écriture à un fichier, vous devrez accorder à cet utilisateur local des autorisations d’exécution sur le dossier racine du conteneur, ainsi que sur chaque dossier dans la hiérarchie des dossiers qui mènent au fichier. Si l’utilisateur local est l’utilisateur propriétaire ou le groupe propriétaire, vous pouvez appliquer les autorisations d’exécution à l’utilisateur propriétaire ou au groupe propriétaire. Sinon, vous devez appliquer l’autorisation d’exécution à tous les autres utilisateurs.
Modification des listes de contrôle d’accès avec un client SFTP
Bien que les autorisations de liste de contrôle d’accès puissent être modifiées à l’aide de n’importe quel outil ou SDK Azure pris en charge, les utilisateurs locaux peuvent également les modifier. Pour permettre à un utilisateur local de modifier les autorisations de liste de contrôle d’accès, vous devez d’abord lui accorder une autorisation Modify Permissions
. Consultez Accorder l’autorisation aux conteneurs.
Les utilisateurs locaux peuvent modifier le niveau d’autorisation de l’utilisateur propriétaire, du groupe propriétaire et de tous les autres utilisateurs d’une liste de contrôle d’accès. L'ajout ou la modification d'entrées ACL pour les utilisateurs nommés, les groupes nommés et les entités de sécurité nommées n'est pas encore pris en charge.
Les utilisateurs locaux peuvent également modifier l’ID de l’utilisateur propriétaire et le groupe propriétaire. En fait, seuls les utilisateurs locaux peuvent modifier l’ID de l’utilisateur propriétaire ou du groupe propriétaire en identifiant utilisateur local. Vous ne pouvez pas encore référencer un identifiant utilisateur local dans une liste de contrôle d’accès à l’aide d’un outil ou d’un kit de développement logiciel (SDK) Azure. Pour modifier l’utilisateur propriétaire ou le groupe propriétaire d’un répertoire ou d’un objet blob, l’utilisateur local doit disposer d’une autorisation Modify Ownership
.
Pour afficher des exemples, consultez Modifier la liste de contrôle d’accès d’un fichier ou d’un répertoire.
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 1 | rsa-sha2-256 2 rsa-sha2-512 2 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 2 rsa-sha2-256 rsa-sha2-512 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521 |
1 Les clés d’hôte sont publiées ici. 2 Les clés RSA doivent avoir une longueur minimale de 2 048 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).
Mise en réseau - Éléments à prendre en compte
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. Lorsque vous utilisez SFTP, vous pouvez limiter l’accès public via la configuration d’un pare-feu, d’un réseau virtuel ou d’un point de terminaison privé. Ces paramètres sont appliqués au niveau de la couche application, ce qui signifie qu’ils ne sont pas spécifiques à SFTP et ont un impact sur la connectivité à tous les points de terminaison stockage Azure. Pour plus d’informations sur les pare-feu et la configuration du réseau, consultez Configurer des pare-feu Stockage Azure et des réseaux virtuels.
Remarque
Les outils d’audit qui tentent de déterminer la prise en charge du protocole TLS au niveau de la couche de protocole peuvent renvoyer les versions du protocole TLS en plus de la version minimale requise quand elles s’exécutent directement sur le point de terminaison du compte de stockage. Pour plus d’informations, consultez Appliquer une version minimale requise du protocole TLS (Transport Layer Security) pour des demandes adressées à un compte de stockage.
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.
- AIX1
- AsyncSSH 2.1.0+
- Axway
- curl 7.85.0+
- Cyberduck 7.8.2+
- edtFTPjPRO 7.0.0+
- FileZilla 3.53.0+
- Five9
- JSCH 0.1.54+
- libssh 0.9.5+
- MobaXterm v21.3
- Maverick Legacy 1.7.15+
- Moveit 12.7
- Mule 2.1.2+
- OpenSSH 7.4+
- paramiko 2.8.1+
- phpseclib 1.0.13+
- PuTTY 0.74+
- QualysML 12.3.41.1+
- RebexSSH 5.0.7119.0+
- Ruckus 6.1.2+
- Salesforce
- ssh2js 0.1.20+
- sshj 0.27.0+
- SSH.NET 2020.0.0+
- WinSCP 5.10+
- Workday
- XFB.Gateway
1 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 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.
Contenu connexe
- Prise en charge du protocole SFTP SSH pour Stockage Blob Azure
- Activer ou désactiver la prise en charge du prise en charge du protocole FTP Secure Shell (SFTP) dans le Stockage Blob Azure
- Autoriser l'accès au Stockage Blob Azure à partir d'un client SSH File Transfer Protocol (SFTP)
- Se connecter au Stockage Blob Azure à l’aide du protocole SFTP SSH
- Limitations et problèmes connus avec la prise en charge du protocole SSH SFTP (Secure File Transfer Protocol) dans le service Stockage Blob Azure
- Clés d’hôte pour la prise en charge du protocole SSH SFTP (Secure File Transfer Protocol) pour le Stockage Blob Azure
- Considérations relatives aux performances du protocole SFTP (SSH File Transfer Protocol) dans le Stockage Blob Azure