Supporto di SSH File Transfer Protocol (SFTP) per Archivio BLOB di Azure

  • Articolo

L'Archivio BLOB supporta ora il protocollo SFTP (SSH File Transfer Protocol). Questo supporto consente di connettersi in modo sicuro ai Archiviazione BLOB usando un client SFTP, consentendo di usare SFTP per l'accesso ai file, il trasferimento di file e la gestione dei file.

Ecco un video che ti dice di più su di esso.

Azure consente il trasferimento sicuro dei dati negli account di Archivio BLOB usando l'API REST del servizio BLOB di Azure, gli SDK di Azure e strumenti come AzCopy. Tuttavia, i carichi di lavoro legacy spesso usano protocolli di trasferimento file tradizionali, ad esempio SFTP. È possibile aggiornare le applicazioni personalizzate per usare l'API REST e gli SDK di Azure, ma solo apportando modifiche significative al codice.

Prima del rilascio di questa funzionalità, se si vuole usare SFTP per trasferire i dati in Archivio BLOB di Azure, è necessario acquistare un prodotto di terze parti o orchestrare la propria soluzione. Per le soluzioni personalizzate, è necessario creare macchine virtuali in Azure per ospitare un server SFTP e quindi aggiornare, applicare patch, gestire, dimensionare e gestire un'architettura complessa.

Ora, con il supporto SFTP per Archiviazione BLOB di Azure, è possibile abilitare il supporto SFTP per gli account BLOB Archiviazione con un solo clic. È quindi possibile configurare le identità utente locali per l'autenticazione per connettersi all'account di archiviazione con SFTP tramite la porta 22.

Questo articolo descrive il supporto SFTP per l'Archivio BLOB di Azure. Per indicazioni su come abilitare e disabilitare il supporto SFTP, vedere Connettersi all'archivio BLOB di Azure usando il protocollo SFTP (SSH File Transfer Protocol).

Nota

SFTP è un servizio a livello di piattaforma, quindi la porta 22 verrà aperta anche se l'opzione dell'account è disabilitata. Se l'accesso SFTP non è configurato, tutte le richieste riceveranno una disconnessione dal servizio.

SFTP e lo spazio dei nomi gerarchico

Il supporto SFTP richiede l'abilitazione dello spazio dei nomi gerarchico. Lo spazio dei nomi gerarchico organizza gli oggetti (file) in una gerarchia di directory e sottodirectory nello stesso modo in cui il file system nel computer è organizzato. Lo spazio dei nomi gerarchico viene dimensionato in modo lineare e non riduce la capacità o le prestazioni dei dati.

I diversi protocolli sono supportati dallo spazio dei nomi gerarchico. SFTP è uno di questi protocolli disponibili. L'immagine seguente mostra l'accesso alle risorse di archiviazione tramite più protocolli e API REST. Per una lettura più semplice, questa immagine usa il termine REST Gen2 per fare riferimento all'API REST di Azure Data Lake Storage Gen2.

spazio dei nomi gerarchico

Modello di autorizzazione SFTP

I client SFTP non possono essere autorizzati usando le identità di Microsoft Entra. SFTP usa invece una nuova forma di gestione delle identità denominata utenti locali.

Gli utenti locali devono usare una password o una credenziale della chiave privata SSH (Secure Shell) per l'autenticazione. È possibile avere un massimo di 2.000 utenti locali per un account di archiviazione.

Per configurare le autorizzazioni di accesso, creare un utente locale e scegliere i metodi di autenticazione. Quindi, per ogni contenitore nell'account, è possibile specificare il livello di accesso che si vuole assegnare all'utente.

Attenzione

Gli utenti locali non interagiscono con altri modelli di autorizzazione Archiviazione di Azure, ad esempio il controllo degli accessi in base al ruolo (controllo degli accessi in base al ruolo) e il controllo degli accessi in base all'attributo. Gli elenchi di controllo di accesso (ACL) sono supportati per gli utenti locali a livello di anteprima.

Ad esempio, Jeff ha l'autorizzazione di sola lettura (può essere controllata tramite controllo degli accessi in base al ruolo o controllo degli accessi in base al ruolo) tramite l'identità Microsoft Entra per il file foo.txt archiviato nel contenitore con1. Se Jeff accede all'account di archiviazione tramite NFS (se non montato come root/superuser), REST BLOB o Data Lake Storage Gen2 REST, queste autorizzazioni verranno applicate. Tuttavia, se Jeff ha anche un'identità utente locale con autorizzazione di eliminazione per i dati nel contenitore con1, può eliminare foo.txt tramite SFTP usando l'identità utente locale.

L'abilitazione del supporto SFTP non impedisce ad altri tipi di client di usare Microsoft Entra ID. Per gli utenti che accedono alle Archiviazione BLOB usando le portale di Azure, l'interfaccia della riga di comando di Azure, i comandi di Azure PowerShell, AzCopy e gli SDK di Azure e le API REST di Azure, è possibile continuare a usare l'intera gamma di impostazioni di sicurezza Archiviazione BLOB di Azure per autorizzare l'accesso. Per altre informazioni, vedere Modello di controllo di accesso in Azure Data Lake Storage Gen2.

Metodi di autenticazione

È possibile autenticare gli utenti locali che si connettono tramite SFTP usando una password o una coppia di chiavi pubblica-privata Secure Shell (SSH). È possibile configurare entrambe le forme di autenticazione e consentire la connessione degli utenti locali a scegliere quale usare. Tuttavia, l'autenticazione a più fattori, in cui non è supportata sia una password valida che una coppia di chiavi pubblica-privata valida per l'autenticazione corretta.

Password

Non è possibile impostare password personalizzate, ma Azure ne genera uno automaticamente. Se si sceglie l'autenticazione della password, la password verrà fornita dopo aver completato la configurazione di un utente locale. Assicurarsi di copiare la password e salvarla in una posizione in cui è possibile trovarla in un secondo momento. Non sarà più possibile recuperare la password da Azure. Se si perde la password, è necessario generarne una nuova. Per motivi di sicurezza, non è possibile impostare manualmente la password.

Coppie di chiavi SSH

Una coppia di chiavi pubblica-privata è la forma più comune di autenticazione per Secure Shell (SSH). La chiave privata è segreta e deve essere nota solo all'utente locale. La chiave pubblica viene archiviata in Azure. Quando un client SSH si connette all'account di archiviazione usando un'identità utente locale, invia un messaggio con la chiave pubblica e la firma. Azure convalida il messaggio e verifica che l'utente e la chiave siano riconosciuti dall'account di archiviazione. Per altre informazioni, vedere Panoramica di SSH e delle chiavi.

Se si sceglie di eseguire l'autenticazione con una coppia di chiavi pubblica privata, è possibile generarne una, usarne una già archiviata in Azure o fornire ad Azure la chiave pubblica di una coppia di chiavi pubblica-privata esistente. È possibile avere un massimo di 10 chiavi pubbliche per utente locale.

Autorizzazioni contenitori

Per le autorizzazioni a livello di contenitore, è possibile scegliere i contenitori a cui si vuole concedere l'accesso e a quale livello di accesso si vuole fornire (lettura, scrittura, elenco, eliminazione, creazione, modifica proprietà e modifica autorizzazioni). Queste autorizzazioni si applicano a tutte le directory e le sottodirectory nel contenitore. È possibile concedere a ogni utente locale l'accesso a un numero di contenitori pari a 100. Le autorizzazioni del contenitore possono essere aggiornate anche dopo la creazione di un utente locale. Nella tabella seguente vengono descritte in modo più dettagliato ogni autorizzazione.

Autorizzazione Simbolo Descrizione
Lettura r
  • Leggere il contenuto del file
    		•
    Scrittura w
  • Carica file
  • Creare la directory
  • Caricare una directory
    		•
    List l
  • Elencare il contenuto all'interno del contenitore
  • Elencare il contenuto all'interno della directory
    		•
    Elimina d
  • Eliminare file/directory
    		•
    Creazione c
  • Caricare il file se il file non esiste
  • Crea directory se la directory non esiste
    		•
    Modifica proprietà o
  • Modificare l'utente proprietario o il gruppo proprietario di un file o di una directory
    		•
    Modifica autorizzazioni p
  • Modificare l'ACL di un file o di una directory
    		•

    Quando si eseguono operazioni di scrittura sui BLOB nelle sottodirectory, è necessaria l'autorizzazione lettura per aprire la directory e accedere alle proprietà del BLOB.

    Elenchi di controllo di accesso (ACL)

    Importante

    Questa funzionalità è attualmente in ANTEPRIMA. Vedere le condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure per termini legali aggiuntivi che si applicano a funzionalità di Azure in versione beta, in anteprima o in altro modo non ancora disponibili a livello generale.

    Gli ACL consentono di concedere l'accesso con granularità fine, ad esempio l'accesso in scrittura a una directory o a un file specifico. Per altre informazioni sugli elenchi di controllo di accesso, vedere Elenchi di controllo di accesso (ACL) in Azure Data Lake Archiviazione Gen2.

    Per autorizzare un utente locale tramite ACL, è prima necessario abilitare l'autorizzazione ACL per l'utente locale. Vedere Concedere l'autorizzazione ai contenitori.

    Nota

    Anche se un ACL può definire il livello di autorizzazione per molti tipi diversi di identità, è possibile usare solo l'utente proprietario, il gruppo proprietario e tutte le altre identità utente per autorizzare un utente locale. Gli utenti denominati e i gruppi denominati non sono ancora supportati per l'autorizzazione dell'utente locale.

    Nella tabella seguente vengono descritte le proprietà di un utente locale utilizzate per l'autorizzazione ACL.

    Proprietà Descrizione
    ID utente
  • Identificatore univoco per l'utente locale all'interno dell'account di archiviazione
  • Generato per impostazione predefinita quando viene creato l'utente locale
  • Usato per impostare l'utente proprietario su file/directory
    		•
    GroupId
  • Identificatore per un gruppo di utenti locali
  • Usato per l'impostazione del gruppo proprietario in file/directory
    		•
    AllowAclAuthorization
  • Consentire l'autorizzazione delle richieste dell'utente locale con ACL
    		•

    Come vengono valutate le autorizzazioni ACL

    Gli elenchi di controllo di accesso vengono valutati solo se l'utente locale non dispone delle autorizzazioni del contenitore necessarie per eseguire un'operazione. A causa del modo in cui le autorizzazioni di accesso vengono valutate dal sistema, non è possibile usare un elenco di controllo di accesso per limitare l'accesso già concesso dalle autorizzazioni a livello di contenitore. Questo perché il sistema valuta prima le autorizzazioni del contenitore e se tali autorizzazioni concedono autorizzazioni di accesso sufficienti, gli ACL vengono ignorati.

    Importante

    Per concedere a un utente locale l'accesso in lettura o scrittura a un file, è necessario concedere all'utente locale le autorizzazioni Execute per la cartella radice del contenitore e a ogni cartella nella gerarchia di cartelle che portano al file. Se l'utente locale è l'utente proprietario o il gruppo proprietario, è possibile applicare le autorizzazioni Esegui all'utente proprietario o al gruppo proprietario. In caso contrario, sarà necessario applicare l'autorizzazione Esegui a tutti gli altri utenti.

    Modifica degli elenchi di controllo di accesso con un client SFTP

    Anche se le autorizzazioni ACL possono essere modificate usando qualsiasi strumento o SDK di Azure supportato, gli utenti locali possono anche modificarle. Per consentire a un utente locale di modificare le autorizzazioni ACL, è prima necessario assegnare all'utente locale l'autorizzazione Modify Permissions . Vedere Concedere l'autorizzazione ai contenitori.

    Gli utenti locali possono modificare il livello di autorizzazione solo dell'utente proprietario, del gruppo proprietario e di tutti gli altri utenti di un elenco di controllo di accesso. L'aggiunta o la modifica di voci ACL per utenti denominati, gruppi denominati e entità di sicurezza denominate non sono ancora supportate.

    Gli utenti locali possono anche modificare l'ID dell'utente proprietario e del gruppo proprietario. Infatti, solo gli utenti locali possono modificare l'ID dell'utente proprietario o del gruppo proprietario in un ID utente locale. Non è ancora possibile fare riferimento a un ID utente locale in un ACL usando uno strumento di Azure o un SDK. Per modificare l'utente proprietario o il gruppo proprietario di una directory o di un BLOB, all'utente locale deve essere concessa Modify Ownership l'autorizzazione.

    Per visualizzare esempi, vedere Modificare l'elenco di controllo di accesso di un file o di una directory.

    Home directory

    Quando si configurano le autorizzazioni, è possibile impostare una home directory per l'utente locale. Se non viene specificato alcun altro contenitore in una richiesta di connessione SFTP, la home directory è la directory a cui l'utente si connette per impostazione predefinita. Si consideri ad esempio la richiesta seguente effettuata usando Open SSH. Questa richiesta non specifica un contenitore o un nome di directory come parte del comando sftp.

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

    Se si imposta la home directory di un utente su mycontainer/mydirectory, si connetterà a tale directory. Il file logfile.txt verrà quindi caricato in mycontainer/mydirectory. Se non è stata impostata la home directory, il tentativo di connessione avrà esito negativo. Al contrario, la connessione degli utenti deve specificare un contenitore insieme alla richiesta e quindi usare i comandi SFTP per passare alla directory di destinazione prima di caricare un file. Nell'esempio riportato di seguito viene illustrata questa situazione:

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

    Nota

    Home directory è solo la directory iniziale in cui viene inserito l'utente locale connesso. Gli utenti locali possono passare a qualsiasi altro percorso nel contenitore a cui sono connessi se dispongono delle autorizzazioni appropriate per il contenitore.

    Algoritmi supportati

    È possibile usare molti client SFTP diversi per connettersi in modo sicuro e quindi trasferire file. La connessione dei client deve usare algoritmi specificati nella tabella seguente.

    Type Algoritmo
    Chiave host 1 rsa-sha2-256 2
    rsa-sha2-512 2
    ecdsa-sha2-nistp256
    ecdsa-sha2-nistp384
    Scambio di chiave ecdh-sha2-nistp384
    ecdh-sha2-nistp256
    diffie-hellman-group14-sha256
    diffie-hellman-group16-sha512
    diffie-hellman-group-exchange-sha256
    Crittografie/crittografia aes128-gcm@openssh.com
    aes256-gcm@openssh.com
    aes128-ctr
    aes192-ctr
    aes256-ctr
    Integrità/MAC hmac-sha2-256
    hmac-sha2-512
    hmac-sha2-256-etm@openssh.com
    hmac-sha2-512-etm@openssh.com
    Chiave pubblica ssh-rsa 2
    rsa-sha2-256
    rsa-sha2-512
    ecdsa-sha2-nistp256
    ecdsa-sha2-nistp384
    ecdsa-sha2-nistp521

    1 Le chiavi host vengono pubblicate qui. 2 chiavi RSA devono avere una lunghezza minima di 2.048 bit.

    Il supporto SFTP per Archiviazione BLOB di Azure attualmente limita il supporto dell'algoritmo di crittografia in base alle considerazioni sulla sicurezza. Si consiglia fortemente ai clienti di usare algoritmi approvati da Microsoft Security Development Lifecycle (SDL) per accedere in modo sicuro ai dati.

    Attualmente, in conformità con Microsoft Security SDL, non si prevede di supportare quanto segue: ssh-dss, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha1, hmac-sha1, hmac-sha1-96. Il supporto degli algoritmi è soggetto a modifiche in futuro.

    Connessione con SFTP

    Per iniziare, abilitare il supporto SFTP, creare un utente locale e assegnare le autorizzazioni per l'utente locale. È quindi possibile usare qualsiasi client SFTP per connettersi in modo sicuro e quindi trasferire i file. Per istruzioni dettagliate, vedere Connettersi all'Archivio BLOB di Azure usando il protocollo SFTP (SSH File Transfer Protocol).

    Considerazioni sulla rete

    SFTP è un servizio a livello di piattaforma, quindi la porta 22 verrà aperta anche se l'opzione dell'account è disabilitata. Se l'accesso SFTP non è configurato, tutte le richieste ricevono una disconnessione dal servizio. Quando si usa SFTP, è possibile limitare l'accesso pubblico tramite la configurazione di un firewall, di una rete virtuale o di un endpoint privato. Queste impostazioni vengono applicate a livello di applicazione, il che significa che non sono specifiche di SFTP e influiranno sulla connettività a tutti gli endpoint Archiviazione di Azure. Per altre informazioni su firewall e configurazione di rete, vedere Configurare Archiviazione di Azure firewall e reti virtuali.

    Nota

    Gli strumenti di controllo che tentano di determinare il supporto TLS a livello di protocollo possono restituire versioni TLS oltre alla versione minima richiesta quando vengono eseguiti direttamente sull'endpoint dell'account di archiviazione. Per altre informazioni, vedere Applicare una versione minima obbligatoria di Transport Layer Security (TLS) per le richieste a un account di archiviazione.

    Client supportati noti

    I client seguenti supportano algoritmi compatibili con SFTP per Archivio BLOB di Azure. Vedere Limitazioni e problemi noti relativi al supporto SFTP (SSH File Transfer Protocol) per Archivio BLOB di Azure in caso di problemi di connessione. Questo elenco non è esaustivo e può cambiare nel tempo.

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

    1 occorre impostare l'opzione AllowPKCS12KeystoreAutoOpen su no.

    Limitazioni e problemi noti

    Vedere l'articolo Limitazioni e problemi noti per un elenco completo delle limitazioni e dei problemi relativi al supporto SFTP per Archivio BLOB di Azure.

    Determinazione dei prezzi e fatturazione

    L'abilitazione di SFTP ha un costo orario. Per informazioni sui prezzi più recenti, vedere Prezzi di Archivio BLOB di Azure.

    Suggerimento

    Per evitare addebiti passivi, è consigliabile abilitare SFTP solo quando si usa attivamente per trasferire i dati. Per indicazioni su come abilitare e disabilitare il supporto SFTP, vedere Connettersi all'Archivio BLOB di Azure usando il protocollo SFTP (SSH File Transfer Protocol).

    Si applicano i prezzi delle transazioni, dell'archiviazione e della rete per l'account di archiviazione sottostante. Tutte le transazioni SFTP vengono convertite in lettura, scrittura o altre transazioni negli account di archiviazione. Sono inclusi tutti i comandi SFTP e le chiamate API. Per altre informazioni, vedere Informazioni sul modello di fatturazione completo per Archivio BLOB di Azure.

    Contenuto correlato