Ein Partner benötigt SFTP-Uploads? Data Lake Gen2 erstellen und SFTP aktivieren

Veröffentlicht am:

CloudTrips muss eine Datei von einem Partner empfangen, der bereits SFTP nutzt. Azure Blob Storage kann einen SFTP-Endpunkt bereitstellen, ohne einen eigenen SFTP-Server oder eine VM zu betreiben.

SFTP benötigt einen hierarchischen Namespace. Seine Aktivierung gibt Blob Storage Verzeichnissemantik und Data-Lake-Storage-Gen2-Funktionen; Data Lake Gen2 ist somit eine Funktion dieses Storage Accounts und kein separater Server. Die Einstellung kann später nicht wieder deaktiviert werden.

Data-Lake-Gen2-Account erstellen

Suche nach Storage accounts, wähle Create und trage ein:

Subscription: CloudTrips TEST
Resource group: Create new → rg-cloudtrips-sftp-test-weu
Storage account name: stctsftpdmytrotestweu
Region: West Europe
Performance: Standard
Redundancy: Locally-redundant storage (LRS)

Aktiviere unter Advanced:

Enable hierarchical namespace: Enabled

Lasse SFTP während der Accounterstellung deaktiviert und wähle anschließend Review + create und Create. SFTP erst später zu aktivieren hält das kostenpflichtige Testfenster kurz.

Storage-Account-Übersicht mit aktiviertem hierarchischen Namespace für Data Lake Storage Gen2

Partner-Dateisystem erstellen

Öffne den Account und wähle Data storage > Containers > + Container:

Name: partner-drop
Anonymous access level: Private (no anonymous access)

In einem Account mit hierarchischem Namespace wird dieser Container auch Dateisystem genannt. Er bildet das Stammverzeichnis, auf das der Partner beschränkt wird.

SFTP aktivieren und lokalen Benutzer hinzufügen

Wähle Settings > SFTP, dann Enable SFTP und anschließend Add local user. Konfiguriere:

Local user name: partner1
Authentication method: SSH Password
Home directory: partner-drop
Container: partner-drop
Permissions: Read, Write, List, Create

Mit diesen Berechtigungen kann der Partner den Container öffnen, auflisten und Dateien hochladen oder lesen, jedoch nicht löschen. Schließe die Erstellung ab und kopiere das von Azure generierte Kennwort sofort an einen temporären, sicheren Ort. Azure zeigt es nur einmal; später kann es nur neu generiert, aber nicht erneut angezeigt werden.

Der lokale Benutzer ist eine SFTP-spezifische Identität. Seine Containerberechtigungen werden unabhängig von Microsoft-Entra-Rollen wie Storage Blob Data Contributor ausgewertet. Für Produktion sollte ein SSH-Key verwendet und der Zugriff per Storage Firewall oder Private Endpoint auf das Partnernetz beschränkt werden.

SFTP-Seite mit aktiviertem SFTP und auf partner-drop beschränktem Benutzer partner1 ohne sichtbares Kennwort

Über SFTP hochladen

Erstelle im lokalen Terminal eine kleine Testdatei:

printf 'CloudTrips partner upload\n' > partner-upload.txt

Verbinde dich über Port 22. Der SFTP-Benutzername kombiniert Storage-Account- und lokalen Benutzernamen:

sftp stctsftpdmytrotestweu.partner1@stctsftpdmytrotestweu.blob.core.windows.net

Akzeptiere den Host-Key erst, nachdem du den Hostnamen als erwarteten Azure-Storage-Endpunkt geprüft hast, und gib dann das generierte Kennwort ein. Führe am sftp>-Prompt aus:

pwd
put partner-upload.txt
ls
exit

pwd sollte /partner-drop zeigen und ls sollte partner-upload.txt enthalten.

Terminal mit erfolgreicher SFTP-Verbindung und Upload nach partner-drop

Prüfen und Kosten stoppen

Öffne im Portal Data storage > Containers > partner-drop und prüfe, dass partner-upload.txt vorhanden ist.

Privates Dateisystem partner-drop mit der über SFTP hochgeladenen Datei partner-upload.txt

Kehre zu Settings > SFTP zurück und deaktiviere SFTP direkt nach dem Test. SFTP verursacht für jede aktivierte Stunde Kosten, auch wenn niemand verbunden ist; normale Speicher-, Transaktions- und Netzwerkkosten fallen ebenfalls an. Das Deaktivieren beendet neue SFTP-Verbindungen, löscht aber weder den Container noch das hochgeladene Blob.

SFTP-Seite mit nach dem erfolgreichen Uploadtest deaktivierter Funktion

Falls die Verbindung fehlschlägt, prüfe, ob SFTP aktiviert ist, der Benutzername beide Namen mit einem Punkt verbindet, der lokale Benutzer Zugriff auf partner-drop besitzt und die Storage Firewall das Clientnetz erlaubt.

Bereinigen

Lösche die lokale Kopie und anschließend die eigenständige Ressourcengruppe:

rm partner-upload.txt

az group delete \
  --name rg-cloudtrips-sftp-test-weu \
  --yes

Bestätige, dass die Ressourcengruppe nicht mehr existiert:

az group exists --name rg-cloudtrips-sftp-test-weu

Erwartetes Ergebnis: false.