Freigeben über

Unterstützung von SSH File Transfer Protocol (SFTP) für Azure Blob Storage

  • Artikel

Der Blob-Speicher unterstützt jetzt das SSH File Transfer Protocol (SFTP). Diese Unterstützung bietet die Möglichkeit, über einen SFTP-Client eine sichere Verbindung mit Blob Storage herzustellen, sodass Sie SFTP für den Dateizugriff, die Dateiübertragung und die Dateiverwaltung nutzen können.

Hier ist ein Video, in dem Sie mehr darüber erfahren.

Azure ermöglicht eine sichere Datenübertragung an Blob-Storage-Konten mithilfe der Azure Blob Service-REST-API, Azure SDKs und Tools wie AzCopy. Ältere Workloads verwenden jedoch häufig herkömmliche Dateiübertragungsprotokolle wie SFTP. Sie können benutzerdefinierte Anwendungen so aktualisieren, dass sie die REST-API und Azure SDKs verwenden, aber nur, indem Sie wichtige Codeänderungen vornehmen.

Wenn Sie SFTP zum Übertragen von Daten an Azure Blob Storage verwenden möchten, müssen Sie vor der Veröffentlichung dieser Funktion entweder ein Drittanbieterprodukt erwerben oder Ihre eigene Lösung orchestrieren. Für benutzerdefinierte Lösungen müssten Sie in Azure virtuelle Computer (VMs) zum Hosten eines SFTP-Servers erstellen und dann eine komplexe Architektur aktualisieren, patchen, verwalten, skalieren und warten.

Mit SFTP-Unterstützung für Azure Blob Storage können Sie jetzt SFTP-Unterstützung für Blob Storage-Konten mit einem einzigen Klick aktivieren. Anschließend können Sie lokale Benutzeridentitäten für die Authentifizierung einrichten, um eine Verbindung mit Ihrem Speicherkonto mit SFTP über Port 22 herzustellen.

In diesem Artikel wird die SFTP-Unterstützung für Azure Blob Storage beschrieben. Informationen zum Aktivieren von SFTP für Ihr Speicherkonto finden Sie unter Verbinden zu Azure Blob Storage mithilfe des SSH File Transfer Protocol (SFTP).

Hinweis

SFTP ist ein Dienst auf Plattformebene, sodass Port 22 geöffnet wird, auch wenn die Kontooption deaktiviert ist. Wenn der SFTP-Zugriff nicht konfiguriert ist, erhalten alle Anforderungen eine Verbindungstrennung vom Dienst.

SFTP und der hierarchische Namespace

DIE SFTP-Unterstützung erfordert es, dass der hierarchische Namespace aktiviert wird. Der hierarchische Namespace organisiert Objekte (Dateien) genauso in eine Hierarchie von Verzeichnissen und Unterverzeichnissen, wie das Dateisystem auf Ihrem Computer organisiert ist. Der hierarchische Namespace wird linear skaliert und beeinträchtigt weder die Datenkapazität noch die Leistung.

Er unterstützt verschiedene Protokolle. SFTP ist eines dieser verfügbaren Protokolle. Die folgende Abbildung zeigt den Speicherzugriff über mehrere Protokolle und REST-APIs. Für eine einfachere Lesbarkeit wird in der Abbildung der Begriff „REST“ verwendet, um auf die REST-API von Azure Data Lake Storage zu verweisen.

Hierarchischer Namespace

SFTP-Berechtigungsmodell

SFTP-Clients können nicht mithilfe von Microsoft Entra-Identitäten autorisiert werden. Stattdessen verwendet SFTP eine neue Form der Identitätsverwaltung, die als lokale Benutzer bezeichnet wird.

Lokale Benutzer müssen für die Authentifizierung entweder ein Kennwort oder Anmeldeinformationen für einen privaten SSH-Schlüssel (Secure Shell) verwenden. Sie können maximal 8.000 lokale Benutzer für ein Speicherkonto verwenden.

Zum Einrichten von Zugriffsberechtigungen erstellen Sie einen lokalen Benutzer und wählen Authentifizierungsmethoden aus. Anschließend können Sie für jeden Container in Ihrem Konto die Zugriffsebene angeben, die Sie diesem Benutzer gewähren möchten.

Achtung

Lokale Benutzer*innen arbeiten nicht mit anderen Azure Storage-Berechtigungsmodellen wie RBAC (rollenbasierte Zugriffssteuerung) und ABAC (attributbasierte Zugriffssteuerung) zusammen. ACLs (Access Control Lists, Zugriffssteuerungslisten) werden für lokale Benutzer auf Vorschauebene unterstützt.

So hat beispielsweise Jan Leseberechtigung (kann über RBAC oder ABAC gesteuert werden) über seine Microsoft Entra-Identität für die Datei foo.txt, die im Container con1 gespeichert ist. Wenn Jeff über NFS (wenn er nicht als root/Superuser eingebunden wurde), Blob-REST oder Data Lake Storage-REST auf das Speicherkonto zugreift, werden diese Berechtigungen erzwungen. Wenn Jan jedoch auch eine lokale Benutzeridentität mit Löschberechtigung für Daten im Container con1 hat, können sie foo.txt über SFTP mithilfe der lokalen Benutzeridentität löschen.

Das Aktivieren der SFTP-Unterstützung verhindert nicht, dass andere Arten von Clients Microsoft Entra ID verwenden. Bei Benutzern, die über das Azure-Portal, die Azure CLI, mithilfe von Azure PowerShell-Befehlen, AzCopy sowie über Azure SDKs und Azure REST-APIs auf Blob Storage zugreifen, können Sie weiterhin die gesamte Breite der Azure Blob Storage-Sicherheitseinstellungen nutzen, um den Zugriff zu autorisieren. Weitere Informationen finden Sie unter Zugriffssteuerungsmodell in Azure Data Lake Storage.

Authentifizierungsmethoden

Sie können lokale Benutzer, die eine Verbindung über SFTP herstellen, mit einem Kennwort oder einem SSH-Schlüsselpaar aus einem öffentlichen und einem privaten Schlüssel authentifizieren. Sie können beide Formen der Authentifizierung konfigurieren und den verbundenen lokalen Benutzern die Wahl lassen, welche davon sie verwenden möchten. Die MFA, bei der sowohl ein gültiges Kennwort als auch ein gültiges Paar aus öffentlichem und privatem Schlüssel für eine erfolgreiche Authentifizierung erforderlich sind, wird jedoch nicht unterstützt.

Kennwörter

Sie können keine benutzerdefinierten Kennwörter festlegen. Stattdessen generiert Azure eins für Sie. Wenn Sie die Kennwortauthentifizierung auswählen, wird Ihr Kennwort bereitgestellt, nachdem Sie die Konfiguration eines lokalen Benutzers abgeschlossen haben. Kopieren Sie dieses Kennwort, und speichern Sie es an einem Speicherort, an dem Sie es später finden können. Sie können dieses Kennwort nicht erneut aus Azure abrufen. Wenn Sie das Kennwort verlieren, müssen Sie ein neues generieren. Aus Sicherheitsgründen können Sie das Kennwort nicht selbst festlegen.

SSH-Schlüsselpaare

Ein Paar aus öffentlichem und privatem Schlüssel ist die gängigste Form der Authentifizierung für Secure Shell (SSH). Der private Schlüssel ist geheim und darf nur dem lokalen Benutzer bekannt sein. Der öffentliche Schlüssel wird auf Azure gespeichert. Wenn ein SSH-Client unter Verwendung einer lokalen Benutzeridentität eine Verbindung mit dem Speicherkonto herstellt, sendet er eine Nachricht mit dem öffentlichen Schlüssel und der Signatur. Azure überprüft die Nachricht und überprüft, ob der Benutzer und der Schlüssel vom Speicherkonto erkannt werden. Weitere Informationen finden Sie in der Übersicht über SSH und Schlüssel.

Wenn Sie sich für die Authentifizierung mit einem Schlüsselpaar aus privatem und öffentlichem Schlüssel entscheiden, können Sie entweder einen Schlüssel generieren, einen bereits in Azure gespeicherten Schlüssel verwenden oder Azure den öffentlichen Schlüssel eines bestehenden Schlüsselpaars aus öffentlichem und privatem Schlüssel zur Verfügung stellen. Sie können maximal 10 öffentliche Schlüssel pro lokalem Benutzer haben.

Containerberechtigungen

Für Berechtigungen auf Containerebene können Sie auswählen, auf welche Container Sie Zugriff gewähren möchten, und welche Zugriffsebene Sie bereitstellen möchten (Lese-, Schreib-, Listen-, Lösch-, Create-, Besitzänderungs- und Änderungsberechtigungen). Diese Berechtigungen gelten für alle Verzeichnisse und Unterverzeichnisse im Container. Sie können jedem lokalen Benutzer Zugriff auf bis zu 100 Container gewähren. Containerberechtigungen können auch nach dem Erstellen eines lokalen Benutzers aktualisiert werden. In der folgenden Tabelle werden die einzelnen Berechtigungen ausführlicher beschrieben.

Berechtigung Symbol BESCHREIBUNG
Lesen r
  • Lesen von Dateiinhalt
    		•
    Schreiben w
  • Hochladen der Datei
  • Erstellen eines Verzeichnisses
  • Verzeichnis für Uploads
    		•
    List l
  • Auflisten von Inhalt innerhalb des Containers
  • Auflisten von Inhalt im Verzeichnis
    		•
    Löschen T
  • Löschen von Datei/Verzeichnis
    		•
    Erstellen c
  • Hochladen der Datei, wenn die Datei nicht vorhanden ist
  • Erstellen eines Verzeichnisses, wenn es noch keins gibt
    		•
    Besitz ändern o
  • Ändern des zuständigen Benutzers oder der zuständigen Gruppe für eine Datei oder ein Verzeichnis
    		•
    Berechtigungen ändern p
  • Ändern der ACL einer Datei oder eines Verzeichnisses
    		•

    Beim Ausführen von Schreibvorgängen für Blobs in Unterverzeichnissen ist die Leseberechtigung erforderlich, um das Verzeichnis zu öffnen und auf Blobeigenschaften zuzugreifen.

    Zugriffssteuerungslisten (ACLs)

    Wichtig

    Diese Funktion befindet sich derzeit in der VORSCHAUPHASE. Die zusätzlichen Nutzungsbestimmungen für Microsoft Azure-Vorschauen enthalten rechtliche Bedingungen. Sie gelten für diejenigen Azure-Features, die sich in der Beta- oder Vorschauversion befinden oder aber anderweitig noch nicht zur allgemeinen Verfügbarkeit freigegeben sind.

    Mit ACLs können Sie „differenzierten“ Zugriff gewähren, z. B. Schreibzugriff auf ein bestimmtes Verzeichnis oder eine bestimmte Datei. Weitere Informationen zu ACLs finden Sie unter Zugriffssteuerungslisten (ACLs) in Azure Data Lake Storage.

    Um einen lokalen Benutzer mithilfe von ACLs zu autorisieren, müssen Sie zuerst die ACL-Autorisierung für diesen lokalen Benutzer aktivieren. Siehe Erteilen von Berechtigungen für Container.

    Hinweis

    Eine ACL kann zwar die Berechtigungsstufe für viele verschiedene Identitätstypen definieren, es können aber nur der zuständige Benutzer, die zuständige Gruppe und alle anderen Benutzeridentitäten zum Autorisieren eines lokalen Benutzers verwendet werden. Benannte Benutzer und benannte Gruppen werden für die Autorisierung lokaler Benutzer noch nicht unterstützt.

    In der folgenden Tabelle werden die Eigenschaften eines lokalen Benutzers beschrieben, die für die ACL-Autorisierung verwendet werden.

    Eigenschaft Beschreibung
    Benutzer-ID
  • Eindeutiger Bezeichner für lokale Benutzer innerhalb des Speicherkontos
  • Wird standardmäßig generiert, wenn lokale Benutzer*innen erstellt werden
  • Wird zum Festlegen des zuständigen Benutzers in der Datei/ dem Verzeichnis verwendet
    		•
    GroupId
  • Bezeichner für eine Gruppe lokaler Benutzender
  • Wird zum Festlegen einer zuständigen Gruppe in der Datei/ dem Verzeichnis verwendet
    		•
    AllowAclAuthorization
  • Autorisieren der Anforderungen dieses lokalen Benutzers bzw. dieser lokalen Benutzerin mit ACLs zulassen
    		•

    Auswerten von ACL-Berechtigungen

    ACLs werden nur ausgewertet, wenn der lokale Benutzer nicht über die erforderlichen Containerberechtigungen zum Ausführen eines Vorgangs verfügt. Aufgrund der Art und Weise, wie Zugriffsberechtigungen vom System ausgewertet werden, können Sie keine ACL verwenden, um den Zugriff einzuschränken, der bereits durch Berechtigungen auf Containerebene gewährt wurde. Der Grund hierfür ist, dass das System die Containerberechtigungen zuerst auswertet. Wenn diese Berechtigungen ausreichende Zugriffsberechtigungen gewähren, werden ACLs ignoriert.

    Wichtig

    Wenn Sie einem lokalen Benutzer Lese- oder Schreibzugriff auf eine Datei gewähren möchten, müssen Sie diesem lokalen Benutzer die Berechtigung Ausführen für den Stammordner des Containers und für jeden Ordner in der Ordnerhierarchie erteilen, der zu der betreffenden Datei führt. Wenn der lokale Benutzer der zuständige Besitzer oder die zuständige Gruppe ist, können Sie Berechtigungen vom Typ Ausführen entweder auf den zuständigen Benutzer oder die zuständige Gruppe anwenden. Andernfalls müssen Sie die Berechtigung Ausführen auf alle anderen Benutzer anwenden.

    Ändern von ACLs mit einem SFTP-Client

    ACL-Berechtigungen können mit jedem unterstützten Azure-Tool oder SDK und auch von lokalen Benutzern geändert werden. Damit ein lokaler Benutzer ACL-Berechtigungen ändern kann, müssen Sie dem lokalen Benutzer zuerst Berechtigungen vom Typ Modify Permissions erteilen. Siehe Erteilen von Berechtigungen für Container.

    Lokale Benutzer können die Berechtigungsstufe nur für den zuständigen Benutzers, die zuständige Gruppe und alle anderen Benutzer einer ACL ändern. Das Hinzufügen oder Ändern von ACL-Einträgen für benannte Benutzer, benannte Gruppen und benannte Sicherheitsprinzipale wird noch nicht unterstützt.

    Lokale Benutzer können auch die ID des zuständigen Benutzers und der zuständigen Gruppe ändern. Tatsächlich können nur lokale Benutzer die ID des zuständigen Benutzers oder der zuständigen Gruppe in eine lokale Benutzer-ID ändern. Sie können noch nicht über ein Azure-Tool oder SDK auf eine lokale Benutzer-ID in einer ACL verweisen. Um den zuständigen Benutzer oder die zuständige Gruppe eines Verzeichnisses oder Blobs zu ändern, muss dem lokalen Benutzer die Berechtigung Modify Ownership zugewiesen werden.

    Beispiele finden Sie unter Ändern der ACL einer Datei oder eines Verzeichnisses.

    Startverzeichnis

    Beim Konfigurieren von Berechtigungen haben Sie die Möglichkeit, ein Stammverzeichnis für den lokalen Benutzer festzulegen. Wenn in einer SFTP-Verbindungsanforderung kein anderer Container angegeben ist, ist Basisverzeichnis das Verzeichnis, mit dem der Benutzer standardmäßig eine Verbindung herstellt. Betrachten Sie beispielsweise die folgende Anforderung, die mit Open SSH erfolgt. Diese Anforderung gibt keinen Container- oder Verzeichnisnamen als Teil des Befehls sftp an.

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

    Wenn Sie das Basisverzeichnis eines Benutzers auf mycontainer/mydirectory festlegen, stellt der Client eine Verbindung mit diesem Verzeichnis her. Anschließend wird die Datei logfile.txt in mycontainer/mydirectory hochgeladen. Wenn Sie das Basisverzeichnis nicht festgelegt haben, schlägt der Verbindungsversuch fehl. Stattdessen müssten die Benutzer, die eine Verbindung herstellen, zusammen mit der Anforderung einen Container angeben und dann SFTP-Befehle verwenden, um vor dem Hochladen einer Datei zum Zielverzeichnis zu navigieren. Dies wird im folgenden Beispiel veranschaulicht:

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

    Hinweis

    Das Basisverzeichnis ist lediglich das anfängliche Verzeichnis für den lokalen Benutzer, der die Verbindung herstellt. Lokale Benutzer können in dem Container, mit dem sie verbunden sind, zu jedem anderen Pfad navigieren, sofern sie über die entsprechenden Containerberechtigungen verfügen.

    Unterstützte Algorithmen

    Sie können viele verschiedene SFTP-Clients verwenden, um eine sichere Verbindung herzustellen und dann Dateien zu übertragen. Clients, die eine Verbindung herstellen, müssen einen der in der nachstehenden Tabelle aufgeführten Algorithmen verwenden.

    type Algorithmus
    Hostschlüssel 1 rsa-sha2-256 2
    rsa-sha2-512 2
    ecdsa-sha2-nistp256
    ecdsa-sha2-nistp384
    Schlüsselaustausch ecdh-sha2-nistp384
    ecdh-sha2-nistp256
    diffie-hellman-group14-sha256
    diffie-hellman-group16-sha512
    diffie-hellman-group-exchange-sha256
    Verschlüsselungsverfahren/Verschlüsselung aes128-gcm@openssh.com
    aes256-gcm@openssh.com
    aes128-ctr
    aes192-ctr
    aes256-ctr
    Integrität/MAC hmac-sha2-256
    hmac-sha2-512
    hmac-sha2-256-etm@openssh.com
    hmac-sha2-512-etm@openssh.com
    Öffentlicher Schlüssel ssh-rsa 2
    rsa-sha2-256
    rsa-sha2-512
    ecdsa-sha2-nistp256
    ecdsa-sha2-nistp384
    ecdsa-sha2-nistp521

    1 Hostschlüssel werden hier veröffentlicht. 2 RSA-Schlüssel müssen eine Mindestlänge von 2.048 Bits haben.

    Die SFTP-Unterstützung für Azure Blob Storage schränkt die Unterstützung von Kryptografiealgorithmen derzeit aufgrund von Sicherheitsüberlegungen ein. Wir empfehlen unseren Kunden dringend, für den sicheren Zugriff auf ihre Daten die im Rahmen des Microsoft Security Development Lifecycle (SDL) genehmigten Algorithmen zu verwenden.

    Zu diesem Zeitpunkt planen wir in Übereinstimmung mit dem Microsoft Security SDL nicht, Folgendes zu unterstützen: ssh-dss, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1, hmac-sha1, hmac-sha1-96. Die Algorithmusunterstützung unterliegt künftigen Änderungen.

    Herstellen einer Verbindung mit SFTP

    Aktivieren Sie zunächst die SFTP-Unterstützung, erstellen Sie einen lokalen Benutzer, und weisen Sie diesem lokalen Benutzer Berechtigungen zu. Anschließend können Sie einen beliebigen SFTP-Client verwenden, um eine sichere Verbindung herzustellen und dann Dateien zu übertragen. Eine schrittweise Anleitung finden Sie unter Herstellen einer Verbindung mit Azure Blob Storage mithilfe des SSH-Dateiübertragungsprotokolls (SFTP).

    Überlegungen zum Netzwerkbetrieb

    SFTP ist ein Dienst auf Plattformebene, sodass Port 22 geöffnet wird, auch wenn die Kontooption deaktiviert ist. Wenn der SFTP-Zugriff nicht konfiguriert wurde, empfangen alle Anforderungen eine Verbindungstrennung vom Dienst. Wenn Sie SFTP verwenden, möchten Sie den öffentlichen Zugriff möglicherweise über die Konfiguration einer Firewall, eines virtuellen Netzwerks oder eines privaten Endpunkts einschränken. Diese Einstellungen werden auf der Anwendungsebene erzwungen, d. h., sie sind nicht spezifisch für SFTP und wirken sich auf die Konnektivität aller Azure Storage-Endpunkte aus. Weitere Informationen zum Konfigurieren von Firewallregeln finden Sie unter Konfigurieren von Azure Storage-Firewalls und virtuellen Netzwerken.

    Hinweis

    Überwachungstools, die versuchen, die TLS-Unterstützung auf der Protokollebene zu ermitteln, geben möglicherweise zusätzlich zur mindestens erforderlichen Version TLS-Versionen zurück, wenn sie direkt auf dem Endpunkt des Speicherkontos ausgeführt werden. Weitere Informationen finden Sie unter Erzwingen der erforderliche Mindestversion der Transport Layer Security (TLS) für Anforderungen an ein Speicherkonto.

    Bekannte unterstützte Clients

    Die folgenden Clients bieten für SFTP für Azure Blob Storage kompatible Algorithmusunterstützung. Wenn beim Herstellen einer Verbindung Probleme auftreten, lesen Sie die Informationen unter Einschränkungen und bekannte Probleme hinsichtlich der Unterstützung von SFTP (SSH File Transfer Protocol) für Azure Blob Storage. Diese Liste ist nicht vollständig und kann sich im Laufe der Zeit ändern.

    • AIX1
    • AsyncSSH 2.1.0+
    • Axway
    • cURL 7.85.0 oder höher
    • 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 und höher
    • OpenSSH 7.4+
    • paramiko 2.8.1+
    • Ab phpseclib 1.0.13
    • PuTTY 0.74+
    • QualysML 12.3.41.1+
    • RebexSSH 5.0.7119.0+
    • Ruckus 6.1.2 und höher
    • Salesforce
    • ssh2js 0.1.20+
    • sshj 0.27.0+
    • SSH.NET 2020.0.0+
    • WinSCP 5.10+
    • Workday
    • XFB.Gateway

    1 Die Option AllowPKCS12KeystoreAutoOpen muss auf no festgelegt werden.

    Einschränkungen und bekannte Probleme

    Im Artikel Einschränkungen und bekannte Probleme hinsichtlich der Unterstützung von SFTP (SSH File Transfer Protocol) in Azure Blob Storage finden Sie eine vollständige Liste der Einschränkungen und Probleme bei der SFTP-Unterstützung für Azure Blob Storage.

    Preise und Abrechnung

    Die Aktivierung von SFTP ist mit stündlichen Kosten verbunden. Die aktuellsten Preisinformationen finden Sie unter Azure Blob Storage – Preise.

    Tipp

    Zur Vermeidung von passiven Gebühren sollten Sie SFTP nur aktivieren, wenn Sie es aktiv zur Datenübertragung verwenden. Anleitungen zum Aktivieren und anschließenden Deaktivieren der SFTP-Unterstützung finden Sie unter Herstellen einer Verbindung mit Azure Blob Storage mithilfe des SSH File Transfer Protocol (SFTP).

    Es gelten die Transaktions-, Speicher- und Netzwerkpreise für das zugrunde liegende Speicherkonto. Alle SFTP-Transaktionen werden in Lese-, Schreib- oder sonstige Transaktionen auf Ihren Speicherkonten umgewandelt. Dazu gehören alle SFTP-Befehle und API-Aufrufe. Mehr Informationen finden Sie unter Grundlegende Informationen zum vollständigen Abrechnungsmodell für Azure Blob Storage.

    Zugehöriger Inhalt