Partage via

Prise en charge du protocole SFTP SSH pour Stockage Blob Azure

  • Article

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.

espace de noms hiérarchique

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
  • 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 ou répertoire
    		•
    Modifier les autorisations p
  • Modifier la liste de contrôle d’accès d’un fichier ou d’un 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 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
  • 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
  • Identificateur 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
    		•

    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.

    • AsyncSSH 2.1.0+
    • Axway
    • Cyberduck 7.8.2+
    • edtFTPjPRO 7.0.0+
    • FileZilla 3.53.0+
    • Five9
    • libssh 0.9.5+
    • 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+
    • 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+
    • AIX1
    • MobaXterm v21.3

    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