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

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 via en SFTP-slutpunkt, 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.

Med SFTP-stöd för Azure Blob Storage kan du nu aktivera en SFTP-slutpunkt 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

Azure Blob Storage stöder inte Microsoft Entra-autentisering eller auktorisering via SFTP. 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). ACL:er (åtkomstkontrollistor) 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.

För SFTP-aktiverade lagringskonton kan du använda hela bredden av Säkerhetsinställningar för Azure Blob Storage för att autentisera och auktorisera användare som har åtkomst till Blob Storage via Azure-portalen, Azure CLI, Azure PowerShell-kommandon, AzCopy samt Azure SDK:er och Azure REST-API:er. 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äsa 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 fil/katalog
  • Ändra behörigheter p
  • Ändra behörigheter för fil/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.

    ACL:er

    För behörigheter på katalog- eller blobnivå kan du ändra ägande användare, ägande grupp och läge som används av ADLS Gen2-ACL:er. De flesta SFTP-klienter exponerar kommandon för att ändra dessa egenskaper. I följande tabell beskrivs vanliga kommandon i detalj.

    Command Nödvändig containerbehörighet beskrivning
    Chown o
  • Ändra ägande användare för fil/katalog
  • Måste ange numeriskt ID
  • chgrp o
  • Ändra ägande grupp för fil/katalog
  • Måste ange numeriskt ID
  • Chmod p
  • Ändra behörigheter/läge för fil/katalog
  • Måste ange octal-behörigheter för POSIX-format
  • De ID:n som krävs för att ändra ägande användare och ägande grupp är en del av nya egenskaper för lokala användare. I följande tabell beskrivs varje ny lokal användaregenskap i detalj.

    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
  • När de önskade ACL:erna har konfigurerats och den lokala användaren aktiverar AllowAclAuthorizationkan de använda ACL:er för att auktorisera sina begäranden. På samma sätt som RBAC kan containerbehörigheter samverka med ACL:er. Endast om den lokala användaren inte har tillräcklig containerbehörighet utvärderas ACL:er. Mer information finns i Åtkomstkontrollmodell i Azure Data Lake Storage Gen2.

    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 2048 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).

    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

    Att aktivera SFTP-slutpunkten 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.

    Se även