Stöd för SSH File Transfer Protocol (SFTP) för Azure Blob Storage

  • Artikel

Blob Storage stöder nu SSH File Transfer Protocol (SFTP). Med det här stödet kan du på ett säkert sätt ansluta till Blob Storage med hjälp av en SFTP-klient, så att du kan använda SFTP för filåtkomst, filöverföring och filhantering.

Här är en video som berättar mer om det.

Azure tillåter säker dataöverföring till Blob Storage-konton med hjälp av REST API för Azure Blob-tjänsten, Azure SDK:er och verktyg som AzCopy. Äldre arbetsbelastningar använder dock ofta traditionella filöverföringsprotokoll som SFTP. Du kan uppdatera anpassade program för att använda REST API och Azure SDK:er, men bara genom att göra betydande kodändringar.

Om du vill använda SFTP för att överföra data till Azure Blob Storage innan du släpper den här funktionen måste du antingen köpa en produkt från tredje part eller samordna din egen lösning. För anpassade lösningar måste du skapa virtuella datorer i Azure för att vara värd för en SFTP-server och sedan uppdatera, korrigera, hantera, skala och underhålla en komplex arkitektur.

Nu med SFTP-stöd för Azure Blob Storage kan du aktivera SFTP-stöd för Blob Storage-konton med ett enda klick. Sedan kan du konfigurera lokala användaridentiteter för autentisering för att ansluta till ditt lagringskonto med SFTP via port 22.

I den här artikeln beskrivs SFTP-stöd för Azure Blob Storage. Information om hur du aktiverar SFTP för ditt lagringskonto finns i Anslut till Azure Blob Storage med hjälp av SSH File Transfer Protocol (SFTP).

Kommentar

SFTP är en tjänst på plattformsnivå, så port 22 är öppen även om kontoalternativet är inaktiverat. Om SFTP-åtkomst inte har konfigurerats får alla begäranden en frånkoppling från tjänsten.

SFTP och det hierarkiska namnområdet

SFTP-stöd kräver att hierarkisk namnrymd aktiveras. Hierarkisk namnrymd organiserar objekt (filer) i en hierarki med kataloger och underkataloger på samma sätt som filsystemet på datorn organiseras. Det hierarkiska namnområdet skalas linjärt och försämrar inte datakapaciteten eller prestandan.

Olika protokoll stöds av det hierarkiska namnområdet. SFTP är ett av dessa tillgängliga protokoll. Följande bild visar lagringsåtkomst via flera protokoll och REST-API:er. För enklare läsning använder den här avbildningen termen Gen2 REST för att referera till REST-API:et för Azure Data Lake Storage Gen2.

hierarkiskt namnområde

SFTP-behörighetsmodell

SFTP-klienter kan inte auktoriseras med hjälp av Microsoft Entra-identiteter. I stället använder SFTP en ny form av identitetshantering som kallas lokala användare.

Lokala användare måste använda antingen ett lösenord eller en SSH-autentiseringsuppgift (Secure Shell) för autentisering. Du kan ha högst 2 000 lokala användare för ett lagringskonto.

Om du vill konfigurera åtkomstbehörigheter skapar du en lokal användare och väljer autentiseringsmetoder. För varje container i ditt konto kan du sedan ange den åtkomstnivå som du vill ge användaren.

Varning

Lokala användare samverkar inte med andra Azure Storage-behörighetsmodeller som RBAC (rollbaserad åtkomstkontroll) och ABAC (attributbaserad åtkomstkontroll). Åtkomstkontrollistor (ACL: er) stöds för lokala användare på förhandsgranskningsnivå.

Jeff har till exempel skrivskyddad behörighet (kan styras via RBAC eller ABAC) via sin Microsoft Entra-identitet för fil foo.txt lagras i container con1. Om Jeff kommer åt lagringskontot via NFS (när det inte är monterat som rot/superanvändare), Blob REST eller Data Lake Storage Gen2 REST, tillämpas dessa behörigheter. Men om Jeff också har en lokal användaridentitet med borttagningsbehörighet för data i container con1 kan de ta bort foo.txt via SFTP med hjälp av den lokala användaridentiteten.

Att aktivera SFTP-stöd hindrar inte andra typer av klienter från att använda Microsoft Entra-ID. För användare som har åtkomst till Blob Storage med hjälp av Azure-portalen, Azure CLI, Azure PowerShell-kommandon, AzCopy samt Azure SDK:er och Azure REST-API:er kan du fortsätta att använda den fullständiga bredden i säkerhetsinställningen för Azure Blob Storage för att auktorisera åtkomst. Mer information finns i Åtkomstkontrollmodell i Azure Data Lake Storage Gen2.

Autentiseringsmetoder

Du kan autentisera lokala användare som ansluter via SFTP med hjälp av ett lösenord eller en offentlig-privat keypair för Secure Shell (SSH). Du kan konfigurera båda formerna av autentisering och låta anslutna lokala användare välja vilken som ska användas. Multifaktorautentisering, där både ett giltigt lösenord och ett giltigt offentligt-privat nyckelpar krävs för lyckad autentisering, stöds dock inte.

Lösenord

Du kan inte ange anpassade lösenord, utan Azure genererar ett åt dig. Om du väljer lösenordsautentisering anges lösenordet när du har konfigurerat en lokal användare. Se till att kopiera lösenordet och spara det på en plats där du kan hitta det senare. Du kommer inte att kunna hämta lösenordet från Azure igen. Om du förlorar lösenordet måste du generera ett nytt. Av säkerhetsskäl kan du inte ange lösenordet själv.

SSH-nyckelpar

Ett offentligt-privat nyckelpar är den vanligaste formen av autentisering för Secure Shell (SSH). Den privata nyckeln är hemlig och bör endast vara känd för den lokala användaren. Den offentliga nyckeln lagras i Azure. När en SSH-klient ansluter till lagringskontot med hjälp av en lokal användaridentitet skickar den ett meddelande med den offentliga nyckeln och signaturen. Azure validerar meddelandet och kontrollerar att användaren och nyckeln identifieras av lagringskontot. Mer information finns i Översikt över SSH och nycklar.

Om du väljer att autentisera med privat-offentligt nyckelpar kan du antingen generera ett, använda ett som redan har lagrats i Azure eller ge Azure den offentliga nyckeln för ett befintligt offentligt-privat nyckelpar. Du kan ha högst 10 offentliga nycklar per lokal användare.

Containerbehörigheter

För behörigheter på containernivå kan du välja vilka containrar som du vill bevilja åtkomst till och vilken åtkomstnivå du vill ange (Läs, Skriv, Lista, Ta bort, Skapa, Ändra ägarskap och Ändra behörigheter). Dessa behörigheter gäller för alla kataloger och underkataloger i containern. Du kan ge varje lokal användare åtkomst till så många som 100 containrar. Containerbehörigheter kan också uppdateras när du har skapat en lokal användare. I följande tabell beskrivs varje behörighet mer detaljerat.

Behörighet Symbol beskrivning
Lästa r
  • Läsa filinnehåll
    		•
    Skriva a
  • Ladda upp fil
  • Skapa katalog
  • Ladda upp katalog
    		•
    List l
  • Visa en lista över innehåll i containern
  • Visa en lista över innehåll i katalogen
    		•
    Delete d
  • Ta bort fil/katalog
    		•
    Skapa c
  • Ladda upp fil om filen inte finns
  • Skapa katalog om katalogen inte finns
    		•
    Ändra ägarskap o
  • Ändra ägande användare eller ägande grupp för en fil eller katalog
    		•
    Ändra behörigheter p
  • Ändra ACL för en fil eller katalog
    		•

    När du utför skrivåtgärder på blobar i underkataloger krävs läsbehörighet för att öppna katalogen och få åtkomst till blobegenskaper.

    Åtkomstkontrollistor (ACL)

    Viktigt!

    Den här funktionen finns för närvarande i FÖRHANDSVERSION. Juridiska villkor för Azure-funktioner i betaversion, förhandsversion eller som av någon annan anledning inte har gjorts allmänt tillgängliga ännu finns i kompletterande användningsvillkor för Microsoft Azure-förhandsversioner.

    Med ACL:er kan du bevilja "finkornig" åtkomst, till exempel skrivåtkomst till en specifik katalog eller fil. Mer information om ACL:er finns i Åtkomstkontrollistor (ACL: er) i Azure Data Lake Storage Gen2.

    Om du vill auktorisera en lokal användare med hjälp av ACL:er måste du först aktivera ACL-auktorisering för den lokala användaren. Se Ge behörighet till containrar.

    Kommentar

    Även om en ACL kan definiera behörighetsnivån för många olika typer av identiteter kan endast den ägande användaren, ägande gruppen och alla andra användaridentiteter användas för att auktorisera en lokal användare. Namngivna användare och namngivna grupper stöds ännu inte för lokal användarauktorisering.

    I följande tabell beskrivs egenskaperna för en lokal användare som används för ACL-auktorisering.

    Property beskrivning
    AnvändarID
  • Unik identifierare för den lokala användaren i lagringskontot
  • Genereras som standard när den lokala användaren skapas
  • Används för att ställa in ägande användare i fil/katalog
    		•
    Groupid
  • Identifer för en grupp lokala användare
  • Används för att ange ägande grupp i fil/katalog
    		•
    AllowAclAuthorization
  • Tillåt auktorisering av den här lokala användarens begäranden med ACL:er
    		•

    Så utvärderas ACL-behörigheter

    ACL:er utvärderas endast om den lokala användaren inte har de containerbehörigheter som krävs för att utföra en åtgärd. På grund av hur åtkomstbehörigheter utvärderas av systemet kan du inte använda en ACL för att begränsa åtkomst som redan har beviljats av behörigheter på containernivå. Det beror på att systemet utvärderar containerbehörigheter först, och om dessa behörigheter ger tillräcklig åtkomstbehörighet ignoreras ACL:er.

    Viktigt!

    Om du vill ge en lokal användare läs- eller skrivåtkomst till en fil måste du ge den lokala användaren Kör behörighet till rotmappen i containern och till varje mapp i hierarkin med mappar som leder till filen. Om den lokala användaren är den ägande användaren eller ägande gruppen kan du använda Kör-behörigheter för antingen den ägande användaren eller ägande gruppen. Annars måste du tillämpa behörigheten Kör på alla andra användare.

    Ändra ACL:er med en SFTP-klient

    Även om ACL-behörigheter kan ändras med hjälp av valfritt Azure-verktyg eller SDK som stöds, kan lokala användare också ändra dem. Om du vill att en lokal användare ska kunna ändra ACL-behörigheter måste du först ge den lokala användaren Modify Permissions behörighet. Se Ge behörighet till containrar.

    Lokala användare kan bara ändra behörighetsnivån för den ägande användaren, ägande gruppen och alla andra användare av en ACL. Det finns ännu inte stöd för att lägga till eller ändra ACL-poster för namngivna användare, namngivna grupper och namngivna säkerhetsobjekt.

    Lokala användare kan också ändra ID:t för den ägande användaren och den ägande gruppen. Faktum är att endast lokala användare kan ändra ID:t för den ägande användaren eller ägande gruppen till ett lokalt användar-ID. Du kan ännu inte referera till ett lokalt användar-ID i en ACL med hjälp av ett Azure-verktyg eller SDK. Om du vill ändra ägande användare eller ägande grupp för en katalog eller blob måste den lokala användaren ges Modify Ownership behörighet.

    Information om hur du visar exempel finns i Ändra ACL för en fil eller katalog.

    Hemkatalog

    När du konfigurerar behörigheter har du möjlighet att ange en hemkatalog för den lokala användaren. Om ingen annan container anges i en SFTP-anslutningsbegäran är hemkatalogen den katalog som användaren ansluter till som standard. Tänk till exempel på följande begäran som görs med hjälp av Open SSH. Den här begäran anger inte ett container- eller katalognamn som en del av sftp kommandot.

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

    Om du anger hemkatalogen för en användare till mycontainer/mydirectoryansluter de till katalogen. logfile.txt Sedan skulle filen laddas upp till mycontainer/mydirectory. Om du inte har angett startkatalogen misslyckas anslutningsförsöket. I stället måste anslutande användare ange en container tillsammans med begäran och sedan använda SFTP-kommandon för att navigera till målkatalogen innan en fil laddas upp. Följande exempel visar detta:

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

    Kommentar

    Hemkatalogen är bara den första katalogen som den anslutna lokala användaren placeras i. Lokala användare kan navigera till valfri annan sökväg i containern som de är anslutna till om de har rätt containerbehörigheter.

    Algoritmer som stöds

    Du kan använda många olika SFTP-klienter för att ansluta på ett säkert sätt och sedan överföra filer. Anslutande klienter måste använda algoritmer som anges i tabellen nedan.

    Typ Algoritm
    Värdnyckel 1 rsa-sha2-256 2
    rsa-sha2-512 2
    ecdsa-sha2-nistp256
    ecdsa-sha2-nistp384
    Nyckelutbyte ecdh-sha2-nistp384
    ecdh-sha2-nistp256
    diffie-hellman-group14-sha256
    diffie-hellman-group16-sha512
    diffie-hellman-group-exchange-sha256
    Chiffer/kryptering aes128-gcm@openssh.com
    aes256-gcm@openssh.com
    aes128-ctr
    aes192-ctr
    aes256-ctr
    Integritet/MAC hmac-sha2-256
    hmac-sha2-512
    hmac-sha2-256-etm@openssh.com
    hmac-sha2-512-etm@openssh.com
    Offentlig nyckel ssh-rsa 2
    rsa-sha2-256
    rsa-sha2-512
    ecdsa-sha2-nistp256
    ecdsa-sha2-nistp384
    ecdsa-sha2-nistp521

    1 Värdnycklar publiceras här. 2 RSA-nycklar måste vara minst 2 048 bitar långa.

    SFTP-stödet för Azure Blob Storage begränsar för närvarande stödet för krypteringsalgoritmer av säkerhetsskäl. Vi rekommenderar starkt att kunder använder SDL-godkända algoritmer (Microsoft Security Development Lifecycle) för att få säker åtkomst till sina data.

    I enlighet med Microsoft Security SDL planerar vi för närvarande inte att stödja följande: ssh-dss, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1, hmac-sha1, hmac-sha1-96. Stödet för algoritmer kan komma att ändras i framtiden.

    Anslut med SFTP

    För att komma igång aktiverar du SFTP-stöd, skapar en lokal användare och tilldelar behörigheter för den lokala användaren. Sedan kan du använda valfri SFTP-klient för att ansluta på ett säkert sätt och sedan överföra filer. Stegvisa anvisningar finns i Anslut till Azure Blob Storage med hjälp av SSH File Transfer Protocol (SFTP).

    Nätverksöverväganden

    SFTP är en tjänst på plattformsnivå, så port 22 är öppen även om kontoalternativet är inaktiverat. Om SFTP-åtkomst inte har konfigurerats får alla begäranden en frånkoppling från tjänsten. När du använder SFTP kanske du vill begränsa den offentliga åtkomsten genom konfiguration av en brandvägg, ett virtuellt nätverk eller en privat slutpunkt. De här inställningarna tillämpas på programlagret, vilket innebär att de inte är specifika för SFTP och påverkar anslutningen till alla Azure Storage-slutpunkter. Mer information om brandväggar och nätverkskonfiguration finns i Konfigurera Azure Storage-brandväggar och virtuella nätverk.

    Kommentar

    Granskningsverktyg som försöker fastställa TLS-stöd på protokolllagret kan returnera TLS-versioner utöver den lägsta version som krävs när de körs direkt mot lagringskontots slutpunkt. Mer information finns i Framtvinga en lägsta nödvändig version av TLS (Transport Layer Security) för begäranden till ett lagringskonto.

    Kända klienter som stöds

    Följande klienter har kompatibelt algoritmstöd med SFTP för Azure Blob Storage. Se Begränsningar och kända problem med SSH File Transfer Protocol -stöd (SFTP) för Azure Blob Storage om du har problem med att ansluta. Den här listan är inte fullständig och kan ändras med tiden.

    • 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+
    • 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+
    • Arbetsdag
    • XFB. Gateway
    • JSCH 0.1.54+
    • curl 7.85.0+
    • AIX1
    • MobaXterm v21.3

    1 Måste ange AllowPKCS12KeystoreAutoOpen alternativet till no.

    Begränsningar och kända problem

    Se artikeln om begränsningar och kända problem för en fullständig lista över begränsningar och problem med SFTP-stöd för Azure Blob Storage.

    Prissättning och fakturering

    Aktivering av SFTP har en timkostnad. Den senaste prisinformationen finns i Priser för Azure Blob Storage.

    Dricks

    Om du vill undvika passiva avgifter bör du bara överväga att aktivera SFTP när du aktivt använder det för att överföra data. Information om hur du aktiverar och sedan inaktiverar SFTP-stöd finns i Anslut till Azure Blob Storage med SSH File Transfer Protocol (SFTP).

    Transaktions-, lagrings- och nätverkspriser för det underliggande lagringskontot gäller. Alla SFTP-transaktioner konverteras till läs-, skriv- eller andra transaktioner på dina lagringskonton. Detta omfattar alla SFTP-kommandon och API-anrop. Mer information finns i Förstå den fullständiga faktureringsmodellen för Azure Blob Storage.

    Relaterat innehåll