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

Artikel
04/11/2024

Der Blob-Speicher unterstützt jetzt das SSH File Transfer Protocol (SFTP). Diese Unterstützung bietet die Möglichkeit, über einen SFTP-Endpunkt 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 einen SFTP-Endpunkt 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 „Gen2 REST“ verwendet, um auf die REST-API von Azure Data Lake Storage Gen2 zu verweisen.

Hierarchischer Namespace

SFTP-Berechtigungsmodell

Azure Blob Storage unterstützt keine Microsoft Entra-Authentifizierung oder -Autorisierung über SFTP. 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 2000 lokale Benutzer*innen für ein Speicherkonto verwenden.

Um Zugriffsberechtigungen einzurichten, 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 (Zugriffssteuerungslisten) werden für lokale Benutzer*innen 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 Jan über NFS (wenn er nicht als Stamm-/Superuser eingebunden wurde), Blob REST oder Data Lake Storage Gen2 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.

Bei SFTP-fähigen Speicherkonten können Sie die gesamte Breite der Azure Blob Storage-Sicherheitseinstellungen nutzen, um Benutzer zu authentifizieren und zu autorisieren, 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. Weitere Informationen finden Sie unter Zugriffssteuerungsmodell in Azure Data Lake Storage Gen2.

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 Kennwort 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 die Datei/ das Verzeichnis
Berechtigungen ändern	p	Ändern von Berechtigungen für Datei/Verzeichnis

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

ACLs

Für Berechtigungen auf Verzeichnis- oder Blobebene können Sie zuständige Benutzer, zuständige Gruppen und Modus ändern, die von ADLS Gen2 ACLs verwendet werden. Die meisten SFTP-Clients machen Befehle zum Ändern dieser Eigenschaften verfügbar. In der folgenden Tabelle werden häufig verwendete Befehle ausführlicher beschrieben.

Get-Help	Erforderliche Containerberechtigung	Beschreibung
chown	o	Ändern des zuständigen Benutzers für die Datei/ das Verzeichnis Benötigt numerische ID
chgrp	o	Ändern der zuständigen Gruppe für die Datei/ das Verzeichnis Benötigt numerische ID
chmod	p	Ändern von Berechtigungen/Modus für Datei/Verzeichnis Benötigt Berechtigung im oktalen POSIX-Stil

Die zum Ändern zuständigen Benutzers oder der zuständigen Gruppe erforderlichen IDs sind Teil neuer Eigenschaften für lokale Benutzer*innen. In der folgenden Tabelle werden die einzelnen neuen lokalen Benutzereigenschaften ausführlicher beschrieben.

Eigenschaft	Beschreibung
Benutzer-ID	Eindeutiger Bezeichner für lokale Benutzerinnen innerhalb des Speicherkontos Wird standardmäßig generiert, wenn lokale Benutzerinnen erstellt werden Wird zum Festlegen des zuständigen Benutzers in der Datei/ dem Verzeichnis verwendet
GroupId	Identifer für eine Gruppe lokaler Benutzer*innen 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

Sobald die gewünschten ACLs konfiguriert wurden und der lokale Benutzer bzw. die lokale Benutzerin AllowAclAuthorization aktiviert hat, kann er oder sie ACLs verwenden, um Anforderungen zu autorisieren. Ähnlich wie bei RBAC können Containerberechtigungen mit ACLs zusammenarbeiten. Nur wenn lokale Benutzer*innen nicht über ausreichende Containerberechtigungen verfügen, werden ACLs ausgewertet. Weitere Informationen finden Sie unter Zugriffssteuerungsmodell in Azure Data Lake Storage Gen2.

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 ¹	rsa-sha2-256 ² rsa-sha2-512 ² 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 ² rsa-sha2-256 rsa-sha2-512 ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521

¹ Hostschlüssel werden hier veröffentlicht. ² RSA-Schlüssel müssen eine Mindestlänge von 2048 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).

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.

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+
Ab 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 oder höher
AIX¹
MobaXterm v21.3

¹ 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

Das Aktivieren des SFTP-Endpunkts verursacht stündliche Kosten. 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.