Delen via

Ondersteuning voor SSH File Transfer Protocol (SFTP) voor Azure Blob Storage

  • Artikel

Blob Storage ondersteunt nu het SSH File Transfer Protocol (SFTP). Met deze ondersteuning kunt u veilig verbinding maken met Blob Storage met behulp van een SFTP-client, zodat u SFTP kunt gebruiken voor bestandstoegang, bestandsoverdracht en bestandsbeheer.

Hier volgt een video met meer informatie.

Met Azure kunt u gegevensoverdracht naar Blob Storage-accounts beveiligen met behulp van de REST API van de Azure Blob-service, Azure SDK's en hulpprogramma's zoals AzCopy. Verouderde workloads maken echter vaak gebruik van traditionele protocollen voor bestandsoverdracht, zoals SFTP. U kunt aangepaste toepassingen bijwerken om de REST API en Azure SDK's te gebruiken, maar alleen door belangrijke codewijzigingen aan te brengen.

Voorafgaand aan de release van deze functie, als u SFTP wilt gebruiken om gegevens over te dragen naar Azure Blob Storage, moet u een product van derden kopen of uw eigen oplossing organiseren. Voor aangepaste oplossingen moet u virtuele machines (VM's) maken in Azure om een SFTP-server te hosten en vervolgens een complexe architectuur bij te werken, patchen, beheren, schalen en onderhouden.

Met SFTP-ondersteuning voor Azure Blob Storage kunt u nu SFTP-ondersteuning inschakelen voor Blob Storage-accounts met één klik. Vervolgens kunt u lokale gebruikersidentiteiten instellen voor verificatie om via poort 22 verbinding te maken met uw opslagaccount met SFTP.

In dit artikel wordt SFTP-ondersteuning voor Azure Blob Storage beschreven. Zie Verbinding maken met Azure Blob Storage met behulp van het SSH File Transfer Protocol (SFTP) voor informatie over het inschakelen van SFTP (SFTP) voor meer informatie over het inschakelen van SFTP (SFTP).

Notitie

SFTP is een service op platformniveau, dus poort 22 wordt geopend, zelfs als de accountoptie is uitgeschakeld. Als SFTP-toegang niet is geconfigureerd, ontvangen alle aanvragen een verbinding met de service.

SFTP en de hiërarchische naamruimte

SFTP-ondersteuning vereist dat hiërarchische naamruimte is ingeschakeld. Hiërarchische naamruimte ordent objecten (bestanden) in een hiërarchie van mappen en submappen op dezelfde manier als het bestandssysteem op uw computer is georganiseerd. De hiërarchische naamruimte wordt lineair geschaald en verslechtert de gegevenscapaciteit of prestaties niet.

Verschillende protocollen worden ondersteund door de hiërarchische naamruimte. SFTP is een van deze beschikbare protocollen. In de volgende afbeelding ziet u opslagtoegang via meerdere protocollen en REST API's. Voor eenvoudiger lezen gebruikt deze afbeelding de term REST om te verwijzen naar de REST API van Azure Data Lake Storage.

hiërarchische naamruimte

SFTP-machtigingsmodel

SFTP-clients kunnen niet worden geautoriseerd met behulp van Microsoft Entra-identiteiten. In plaats daarvan maakt SFTP gebruik van een nieuwe vorm van identiteitsbeheer genaamd lokale gebruikers.

Lokale gebruikers moeten een wachtwoord of een persoonlijke SSH-sleutelreferentie (Secure Shell) gebruiken voor verificatie. U kunt maximaal 8000 lokale gebruikers hebben voor een opslagaccount.

Als u toegangsmachtigingen wilt instellen, maakt u een lokale gebruiker en kiest u verificatiemethoden. Vervolgens kunt u voor elke container in uw account het toegangsniveau opgeven dat u die gebruiker wilt geven.

Belangrijk

Als u feedback hebt over scenario's waarvoor autorisatie op basis van Entra-identiteiten is vereist, neemt u contact met ons op via BlobSFTP@microsoft.com.

Let op

Lokale gebruikers werken niet samen met andere Azure Storage-machtigingsmodellen, zoals RBAC (op rollen gebaseerd toegangsbeheer) en ABAC (op kenmerken gebaseerd toegangsbeheer). Toegangsbeheerlijsten (ACL's) worden ondersteund voor lokale gebruikers op preview-niveau.

Jeff heeft bijvoorbeeld alleen-lezenmachtigingen (kan worden beheerd via RBAC of ABAC) via hun Microsoft Entra-identiteit voor bestand foo.txt opgeslagen in container con1. Als Jeff toegang heeft tot het opslagaccount via NFS (als deze niet is gekoppeld als root/superuser), Blob REST of Data Lake Storage REST, worden deze machtigingen afgedwongen. Als Jeff echter ook een lokale gebruikersidentiteit heeft met verwijdermachtigingen voor gegevens in container con1, kunnen ze foo.txt verwijderen via SFTP met behulp van de lokale gebruikersidentiteit.

Het inschakelen van SFTP-ondersteuning voorkomt niet dat andere typen clients Microsoft Entra-id gebruiken. Voor gebruikers die toegang hebben tot Blob Storage met behulp van Azure Portal, Azure CLI, Azure PowerShell-opdrachten, AzCopy en Azure SDK's en Azure REST API's, kunt u de volledige breedte van de beveiligingsinstelling van Azure Blob Storage blijven gebruiken om toegang te verlenen. Zie het Access Control-model in Azure Data Lake Storage voor meer informatie.

Verificatiemethoden

U kunt lokale gebruikers verifiëren die verbinding maken via SFTP met behulp van een wachtwoord of een openbare SSH-sleutelsleutel (SSH). U kunt beide vormen van verificatie configureren en lokale gebruikers laten kiezen welke moet worden gebruikt. Meervoudige verificatie, waarbij zowel een geldig wachtwoord als een geldig openbaar-persoonlijk sleutelpaar vereist zijn voor een geslaagde verificatie, wordt niet ondersteund.

Wachtwoords

U kunt geen aangepaste wachtwoorden instellen, maar Azure genereert er een voor u. Als u wachtwoordverificatie kiest, wordt uw wachtwoord opgegeven nadat u klaar bent met het configureren van een lokale gebruiker. Zorg ervoor dat u dat wachtwoord kopieert en opslaat op een locatie waar u het later kunt vinden. U kunt dat wachtwoord niet opnieuw ophalen uit Azure. Als u het wachtwoord kwijtraakt, moet u een nieuw wachtwoord genereren. Om veiligheidsredenen kunt u het wachtwoord niet zelf instellen.

SSH-sleutelparen

Een openbaar-persoonlijk sleutelpaar is de meest voorkomende vorm van verificatie voor Secure Shell (SSH). De persoonlijke sleutel is geheim en mag alleen bekend zijn bij de lokale gebruiker. De openbare sleutel wordt opgeslagen in Azure. Wanneer een SSH-client verbinding maakt met het opslagaccount met behulp van een lokale gebruikersidentiteit, wordt er een bericht met de openbare sleutel en handtekening verzonden. Azure valideert het bericht en controleert of de gebruiker en sleutel worden herkend door het opslagaccount. Zie Overzicht van SSH en sleutels voor meer informatie.

Als u ervoor kiest om te verifiëren met een persoonlijk openbaar sleutelpaar, kunt u er een genereren, er een gebruiken die al is opgeslagen in Azure of Azure de openbare sleutel van een bestaand openbaar-persoonlijk sleutelpaar opgeven. U kunt maximaal 10 openbare sleutels per lokale gebruiker hebben.

Containermachtigingen

Voor machtigingen op containerniveau kunt u kiezen welke containers u toegang wilt verlenen en welk toegangsniveau u wilt bieden (Lezen, Schrijven, Lijst, Verwijderen, Maken, Eigendom wijzigen en Machtigingen wijzigen). Deze machtigingen zijn van toepassing op alle mappen en submappen in de container. U kunt elke lokale gebruiker toegang verlenen tot maximaal 100 containers. Containermachtigingen kunnen ook worden bijgewerkt nadat een lokale gebruiker is gemaakt. In de volgende tabel wordt elke machtiging uitgebreider beschreven.

Machtiging Symbool Beschrijving
Read r
  • Bestandsinhoud lezen
    		•
    Schrijven w
  • Bestand uploaden
  • Map maken
  • Map uploaden
    		•
    List l
  • Inhoud binnen een container weergeven
  • Inhoud in map weergeven
    		•
    Delete d
  • Bestand/map verwijderen
    		•
    Maken c
  • Bestand uploaden als het bestand niet bestaat
  • Map maken als de map niet bestaat
    		•
    Eigendom wijzigen o
  • De gebruiker of groep die eigenaar is van een bestand of map wijzigen
    		•
    Machtigingen wijzigen nm
  • De ACL van een bestand of map wijzigen
    		•

    Wanneer u schrijfbewerkingen uitvoert op blobs in submappen, is leesmachtiging vereist om de map te openen en toegang te krijgen tot blobeigenschappen.

    ACL’s (toegangsbeheerlijsten)

    Belangrijk

    Deze mogelijkheid is momenteel beschikbaar in PREVIEW. Raadpleeg de Aanvullende voorwaarden voor Microsoft Azure-previews voor juridische voorwaarden die van toepassing zijn op Azure-functies die in bèta of preview zijn of die anders nog niet algemeen beschikbaar zijn.

    Met ACL's kunt u 'fijnmazige' toegang verlenen, zoals schrijftoegang tot een specifieke map of bestand. Een veelvoorkomend gebruiksvoorbeeld voor ACL is het beperken van de toegang van een gebruiker tot een specifieke map zonder dat die gebruiker toegang heeft tot andere mappen binnen dezelfde container. Dit kan worden herhaald voor meerdere gebruikers, zodat ze elk gedetailleerde toegang hebben tot hun eigen directory. Zonder ACL's is hiervoor een container per lokale gebruiker vereist. ACL's maken het ook eenvoudiger voor beheerders om toegang te beheren voor meerdere lokale gebruikers met behulp van groepen. Zie Toegangsbeheerlijsten (ACL's) in Azure Data Lake Storage voor meer informatie over ACL's.

    Als u een lokale gebruiker wilt autoriseren met ACL's, moet u eerst ACL-autorisatie voor die lokale gebruiker inschakelen. Zie Machtigingen verlenen aan containers.

    Notitie

    Hoewel een ACL het machtigingsniveau voor veel verschillende typen identiteiten kan definiëren, kunnen alleen de eigenaar van de gebruiker, de groep die eigenaar is en alle andere gebruikersidentiteiten worden gebruikt om een lokale gebruiker te autoriseren. Benoemde gebruikers en benoemde groepen worden nog niet ondersteund voor lokale gebruikersautorisatie.

    In de volgende tabel worden de eigenschappen beschreven van een lokale gebruiker die wordt gebruikt voor ACL-autorisatie.

    Eigenschappen Beschrijving
    Gebruikers-id
  • Unieke id voor de lokale gebruiker in het opslagaccount
  • Standaard gegenereerd wanneer de lokale gebruiker wordt gemaakt
  • Wordt gebruikt voor het instellen van de gebruiker die eigenaar is van een bestand/map
    		•
    GroupId
  • Id voor een groep lokale gebruikers
  • Wordt gebruikt voor het instellen van een groep die eigenaar is van een bestand/map
    		•
    AllowAclAuthorization
  • Autoriseren van aanvragen van deze lokale gebruiker met ACL's toestaan
    		•

    Hoe ACL-machtigingen worden geëvalueerd

    ACL's worden alleen geëvalueerd als de lokale gebruiker niet over de benodigde containermachtigingen beschikt om een bewerking uit te voeren. Vanwege de manier waarop toegangsmachtigingen door het systeem worden geëvalueerd, kunt u geen toegangsbeheerlijst gebruiken om de toegang te beperken die al is verleend door machtigingen op containerniveau. Dat komt doordat het systeem eerst containermachtigingen evalueert en als deze machtigingen voldoende toegangsmachtigingen verlenen, ACL's worden genegeerd.

    Belangrijk

    Als u een lokale gebruiker lees- of schrijftoegang wilt verlenen tot een bestand, moet u die lokale gebruiker machtigingen geven voor de hoofdmap van de container en aan elke map in de hiërarchie van mappen die naar het bestand leiden. Als de lokale gebruiker de eigenaar is van de gebruiker of de groep die eigenaar is, kunt u uitvoermachtigingen toepassen op de gebruiker die eigenaar is of de groep die eigenaar is. Anders moet u de machtiging Uitvoeren toepassen op alle andere gebruikers.

    ACL's wijzigen met een SFTP-client

    Hoewel ACL-machtigingen kunnen worden gewijzigd met behulp van elk ondersteund Azure-hulpprogramma of SDK, kunnen lokale gebruikers ze ook wijzigen. Als u wilt dat een lokale gebruiker ACL-machtigingen kan wijzigen, moet u eerst de lokale gebruiker Modify Permissions toestemming geven. Zie Machtigingen verlenen aan containers.

    Lokale gebruikers kunnen het machtigingsniveau wijzigen van alleen de eigenaar van de gebruiker, de groep die eigenaar is en alle andere gebruikers van een ACL. Het toevoegen of wijzigen van ACL-vermeldingen voor benoemde gebruikers, benoemde groepen en benoemde beveiligingsprinciplen worden nog niet ondersteund.

    Lokale gebruikers kunnen ook de id wijzigen van de gebruiker die eigenaar is en de groep die eigenaar is. In feite kunnen alleen lokale gebruikers de id van de eigenaar van de gebruiker of de groep die eigenaar is, wijzigen in een lokale gebruikers-id. U kunt nog niet verwijzen naar een lokale gebruikers-id in een ACL met behulp van een Azure-hulpprogramma of SDK. Als u de eigenaar van een gebruiker of groep van een map of blob wilt wijzigen, moet de lokale gebruiker toestemming krijgen Modify Ownership .

    Zie De ACL van een bestand of map wijzigen om voorbeelden weer te geven.

    Basismap

    Wanneer u machtigingen configureert, kunt u een basismap instellen voor de lokale gebruiker. Als er geen andere container is opgegeven in een SFTP-verbindingsaanvraag, is de basismap de map waarmee de gebruiker standaard verbinding maakt. Denk bijvoorbeeld aan de volgende aanvraag met behulp van Open SSH. Met deze aanvraag wordt geen container- of mapnaam opgegeven als onderdeel van de sftp opdracht.

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

    Als u de basismap van een gebruiker mycontainer/mydirectoryinstelt op, maakt deze verbinding met die map. Vervolgens wordt het logfile.txt bestand geüpload naar mycontainer/mydirectory. Als u de basismap niet hebt ingesteld, mislukt de verbindingspoging. In plaats daarvan moeten gebruikers die verbinding maken een container opgeven samen met de aanvraag en vervolgens SFTP-opdrachten gebruiken om naar de doelmap te navigeren voordat een bestand wordt geüpload. In het volgende voorbeeld ziet u dit:

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

    Notitie

    De basismap is alleen de eerste map waarin de lokale gebruiker verbinding maakt. Lokale gebruikers kunnen naar elk ander pad in de container navigeren waar ze mee zijn verbonden als ze over de juiste containermachtigingen beschikken.

    Ondersteunde algoritmen

    U kunt vele verschillende SFTP-clients gebruiken om veilig verbinding te maken en vervolgens bestanden over te dragen. Voor het verbinden van clients moeten algoritmen worden gebruikt die worden vermeld in de onderstaande tabel.

    Type Algoritme
    Hostsleutel 1 rsa-sha2-256 2
    rsa-sha2-512 2
    ecdsa-sha2-nistp256
    ecdsa-sha2-nistp384
    Sleuteluitwisseling ecdh-sha2-nistp384
    ecdh-sha2-nistp256
    diffie-hellman-group14-sha256
    diffie-hellman-group16-sha512
    diffie-hellman-group-exchange-sha256
    Coderingen/versleuteling aes128-gcm@openssh.com
    aes256-gcm@openssh.com
    aes128-ctr
    aes192-ctr
    aes256-ctr
    Integriteit/MAC hmac-sha2-256
    hmac-sha2-512
    hmac-sha2-256-etm@openssh.com
    hmac-sha2-512-etm@openssh.com
    Openbare sleutel ssh-rsa 2
    rsa-sha2-256
    rsa-sha2-512
    ecdsa-sha2-nistp256
    ecdsa-sha2-nistp384
    ecdsa-sha2-nistp521

    1 Hostsleutels worden hier gepubliceerd. 2 RSA-sleutels moeten minimaal 2048 bits lang zijn.

    SFTP-ondersteuning voor Azure Blob Storage beperkt momenteel de ondersteuning van cryptografische algoritmes op basis van beveiligingsoverwegingen. We raden klanten ten zeerste aan om Microsoft Security Development Lifecycle (SDL) goedgekeurde algoritmen te gebruiken om veilig toegang te krijgen tot hun gegevens.

    Op dit moment, in overeenstemming met de Microsoft Security SDL, zijn we niet van plan om het volgende te ondersteunen: ssh-dss, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1, , hmac-sha1. hmac-sha1-96 Ondersteuning voor algoritmen kan in de toekomst worden gewijzigd.

    Verbinding maken met SFTP

    Om aan de slag te gaan, schakelt u SFTP-ondersteuning in, maakt u een lokale gebruiker en wijst u machtigingen toe voor die lokale gebruiker. Vervolgens kunt u elke SFTP-client gebruiken om veilig verbinding te maken en vervolgens bestanden over te dragen. Zie Verbinding maken met Azure Blob Storage met behulp van het SSH File Transfer Protocol (SFTP) voor stapsgewijze instructies.

    Aandachtspunten voor netwerken

    SFTP is een service op platformniveau, dus poort 22 wordt geopend, zelfs als de accountoptie is uitgeschakeld. Als SFTP-toegang niet is geconfigureerd, ontvangen alle aanvragen een verbinding met de service. Wanneer u SFTP gebruikt, wilt u mogelijk openbare toegang beperken via de configuratie van een firewall, virtueel netwerk of privé-eindpunt. Deze instellingen worden afgedwongen op de toepassingslaag, wat betekent dat ze niet specifiek zijn voor SFTP en van invloed zijn op de connectiviteit met alle Azure Storage-eindpunten. Zie Azure Storage-firewalls en virtuele netwerken configureren voor meer informatie over firewalls en netwerkconfiguratie.

    Notitie

    Controleprogramma's die TLS-ondersteuning op de protocollaag proberen te bepalen, kunnen TLS-versies retourneren naast de minimaal vereiste versie wanneer deze rechtstreeks worden uitgevoerd op het eindpunt van het opslagaccount. Zie Een minimaal vereiste versie van Transport Layer Security (TLS) afdwingen voor aanvragen naar een opslagaccount voor meer informatie.

    Bekende ondersteunde clients

    De volgende clients hebben compatibele algoritmeondersteuning met SFTP voor Azure Blob Storage. Zie beperkingen en bekende problemen met SSH File Transfer Protocol (SFTP) voor Azure Blob Storage als u problemen ondervindt bij het maken van verbinding. Deze lijst is niet volledig en kan na verloop van tijd veranderen.

    • 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+
    • bibliothekensh 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+
    • Werkdag
    • XFB. Gateway

    1 Moet de optie instellen AllowPKCS12KeystoreAutoOpen op no.

    Beperkingen en bekende problemen

    Zie het artikel over beperkingen en bekende problemen voor een volledige lijst met beperkingen en problemen met SFTP-ondersteuning voor Azure Blob Storage.

    Prijzen en facturering

    Het inschakelen van SFTP heeft een uurkosten. Zie prijzen voor Azure Blob Storage voor de meest recente prijsinformatie.

    Tip

    U kunt passieve kosten voorkomen door SFTP alleen in te schakelen wanneer u deze actief gebruikt om gegevens over te dragen. Zie Verbinding maken met Azure Blob Storage met behulp van het SSH File Transfer Protocol (SFTP) voor hulp bij het in- en uitschakelen van SFTP-ondersteuning.

    Transactie-, opslag- en netwerkprijzen voor het onderliggende opslagaccount zijn van toepassing. Alle SFTP-transacties worden geconverteerd naar lees-, schrijf- of andere transacties in uw opslagaccounts. Dit omvat alle SFTP-opdrachten en API-aanroepen. Zie Meer informatie over het volledige factureringsmodel voor Azure Blob Storage.

    Gerelateerde inhoud