Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Il supporto del SSH File Transfer Protocol (SFTP) per Archiviazione BLOB di Azure permette a un account di archiviazione di rispondere direttamente sulla porta 22, così ottieni lo stesso protocollo a cui i tuoi utenti sono già connessi senza far girare un server dietro di esso. Se oggi ospiti un server SFTP su una macchina virtuale (VM), significa niente sistema operativo da patchare, nessuna capacità da dimensionare e nessun lavoro di copia che sposta i file da un disco di atterraggio, perché i dati che carichi diventano automaticamente il blob.
Questo articolo confronta un server SFTP self-hosted con Archiviazione BLOB di Azure SFTP in termini di costi, prestazioni, operazioni e sicurezza. Spiega anche come verificare la compatibilità prima della migrazione e come validare la modifica con un singolo carico di lavoro.
Come i file raggiungono l'account di archiviazione
Con un server self-ospitato, un trasferimento passa attraverso diversi componenti che possiedi e gestisci. L'immagine seguente mostra il modello di un tipico trasferimento.
Il file arriva su un disco, e poi un processo che hai creato lo sposta dove serve. Sei responsabile di ogni livello: la VM, il sistema operativo, il demone SSH, il disco e la relativa conservazione, il processo di copia e il monitoraggio dell’intero sistema. Finché la copia non è completata, i dati si trovano in due posizioni e nessuna delle due è il record di sistema.
Con Archiviazione BLOB di Azure SFTP, l'account di archiviazione termina il protocollo stesso. L'immagine seguente mostra questo modello di trasferimento.
Il caricamento è il blob. Non c'è disco di atterraggio né lavoro di copia, perché non c'è nulla da copiare. Non appena il trasferimento si completa, il file è disponibile per l'API Blob REST, Azure Data Lake Storage, Network File System (NFS) 3.0, Griglia di eventi di Azure e qualsiasi elaborazione che già punti a quell'account.
Solo il nome host cambia. Per gli utenti che si connettono e trasferiscono dati, tutto il resto rimane uguale. Usano lo stesso protocollo, gli stessi strumenti client e lo stesso modello di credenziali se lo vuoi.
Se il tuo obiettivo è trasferire file nel cloud tenendo conto di costi e sicurezza, questo approccio è un punto di partenza pratico. Non stai adottando un nuovo modello di trasferimento; stai rimuovendo l'infrastruttura sotto quella che già gestisci.
Cost
Abilitare SFTP aggiunge un addebito orario che si applica ogni volta che SFTP è abilitato, indipendentemente dal fatto che qualcuno sia connesso o meno. Tutto il resto viene fatturato alle tariffe standard dell’account, inclusi la capacità archiviata, le transazioni e il traffico in uscita. Tutti i comandi SFTP vengono convertiti in transazioni di lettura, scrittura o di altro tipo nell'account. Non c'è un costo separato per gigabyte per i dati trasferiti tramite SFTP.
Se i tuoi trasferimenti vengono eseguiti in una finestra definita, puoi abilitare SFTP solo quando ne hai bisogno ed evitare il carico intermedio.
Note
Per trovare la tariffa oraria attuale, consulta la pagina Archiviazione BLOB di Azure Prezzi. L'addebito è visibile in quella pagina solo se selezioni Hierarchical Namespace (NFS v3.0, SFTP Protocol) nella lista a tendina File Structure .
La tabella seguente descrive il risultato che puoi aspettarti, in base a ciò che esegui oggi:
| Ciò che esegui oggi | SFTP di archiviazione BLOB probabilmente | Perché |
|---|---|---|
| Una singola VM con una o due vCPU | Più costoso | Il costo orario dell'endpoint supera il costo di calcolo di una piccola VM. Se quella è l'intera presenza operativa, il costo non è il motivo per trasferirsi. Tuttavia, l'efficienza operativa potrebbe essere un motivo per muoversi. Puoi saperne di più su queste efficienze nella sezione Operazioni di questo articolo. |
| Una VM dimensionata per una velocità di throughput sostenuto, con disco gestito e backup | Più o meno uguale | Il costo dell'endpoint compensa calcolo, dischi e backup. |
| Più istanze per garantire la disponibilità o una seconda area geografica per il disaster recovery | Materialmente meno | Smetti di pagare per il calcolo ridondante e la seconda regione. |
| Qualsiasi delle righe precedenti, considerando anche il tempo di ingegneria | Meno | L'applicazione di patch, la rotazione delle chiavi e il tempo di reperibilità non compaiono in nessuna delle due fatture. |
Per confrontare equamente ogni opzione, includi il costo di calcolo, il sistema operativo e i dischi di atterraggio, e il backup nelle tue stime. Includi un bilanciatore di carico, indirizzi IP pubblici o una seconda regione solo se li hai distribuiti, perché molti server SFTP funzionano come una singola VM senza nessuno di essi.
Due costi sono facili da trascurare. Innanzitutto, i dati di solito rimangono sul disco di atterraggio e nella sua destinazione per tutta la durata della finestra di conservazione, quindi paghi per entrambi. In secondo luogo, il tempo del team di ingegneria necessario per applicare le patch, ruotare le chiavi e gestire il processo di copia non compare affatto in fattura.
Usa l'analisi dei costi sul gruppo di risorse esistente invece di un calcolatore di prezzi, così lavori da ciò che viene effettivamente fatturato. Per le tariffe attuali, consulta Archiviazione BLOB di Azure pricing e pianifica e gestisci i costi per Archiviazione BLOB di Azure.
Performance
Il limite massimo di una VM è fissato dal proprio SKU: la larghezza di banda di rete, il throughput del disco e la CPU rimasta per la crittografia SSH. Il limite massimo di un conto di archiviazione è rappresentato dai limiti di ingresso e di tasso di richiesta, che sono considerevolmente più alti e non richiedono alcun lavoro da parte tua per essere raggiunti.
La velocità effettiva aumenta con il numero di connessioni simultanee e un account premium per BLOB in blocchi raggiunge una larghezza di banda pari a circa 2,3 volte quella di un account standard di utilizzo generico v2 con un singolo client. Per indicazioni sulla messa a punto, vedi considerazioni sulle prestazioni SFTP.
Operations
Archiviazione BLOB di Azure SFTP offre una maggiore efficienza operativa.
Poiché l'account di archiviazione termina SFTP, la VM, il disco di atterraggio e il lavoro di copia scompaiono tutti, insieme al lavoro di mantenerli in funzione. Non è più necessario patchare un sistema operativo, rafforzare un daemon SSH, pianificare la capacità, costruire e testare la propria alta disponibilità e disaster recovery, né supportare la pipeline che sposta i file in archiviazione.
La gestione delle chiavi host è un esempio. La ricostruzione di una VM cambia la chiave host SSH a meno che non la preservi deliberatamente, e gli strumenti client trattano un cambiamento inaspettato della chiave host come un possibile attacco machine-in-the-middle. La manutenzione di routine diventa quindi un esercizio di coordinamento con tutti coloro che si collegano. Al contrario, Azure pubblica le sue chiavi host SFTP, così gli strumenti client possono verificarle rispetto a una fonte documentata. Consulta Chiavi host per SFTP.
Security
Un server OpenSSH auto-ospitato supporta sia l'autenticazione con password che con chiave pubblica. Sei tu a possedere gli account, la sshd configurazione, la distribuzione e la rotazione delle chiavi.
Archiviazione BLOB di Azure SFTP supporta entrambi questi metodi e aggiunge Microsoft Entra ID. Puoi scegliere il metodo appropriato per ogni utente:
| metodo | Come funziona | Ideale per |
|---|---|---|
| Password | Azure genera la password e la mostra una sola volta. Non puoi impostare password personalizzate, quindi password deboli o riutilizzate non sono possibili. | Iniziare in fretta |
| Coppia di chiavi SSH | Fornisci o generi una chiave pubblica, fino a 10 per utente locale. | Trasferimenti automatizzati, senza supervisione |
| Microsoft Entra ID | Gli utenti si autenticano su Entra ID e ricevono un certificato valido per 65 minuti, autorizzato da Azure role-based access control (RBAC), Azure attribute-based access control (ABAC) e POSIX access control lists (ACL). | Consigliato laddove la governance delle identità è fondamentale |
Microsoft Entra ID è la differenza più significativa tra i due approcci. Con qualsiasi credenziale locale, sia su una VM che in un account di archiviazione, il segreto ha una lunga durata e rimane al di fuori dei controlli delle identità che applichi al resto del tuo ambiente.
Un certificato Entra ID scade dopo 65 minuti, quindi una credenziale mal gestita smette di funzionare da sola. L'autenticazione multifattore e l'Accesso Condizionale si applicano al trasferimento dei file allo stesso modo in cui si applicano a tutto il resto. Quando un account viene disabilitato, l'accesso SFTP termina nello stesso momento. Utilizzando le Identità Esterne, le organizzazioni con cui scambi file possono autenticarsi dal proprio tenant, così non emetti né memorizzi più credenziali per loro conto.
Gli utenti locali restano pienamente supportati, quindi puoi adottare Entra ID al ritmo che preferisci.
Oltre all'identità, un account di archiviazione offre controlli che altrimenti costruiresti e manterresti da solo:
Sono accettati solo algoritmi approvati nell'ambito del Microsoft Security Development Lifecycle, quindi opzioni deboli come
ssh-dssgli scambi di chiavi basati su SHA-1 non sono disponibili.Gli endpoint privati mantengono il traffico sulla tua rete virtuale.
Microsoft Defender for Storage scansiona i caricamenti per malware, senza uno scanner da installare o mantenere.
La crittografia a riposo, le chiavi gestite dal cliente, le politiche di immutabilità e la registrazione diagnostica si applicano ai file caricati tramite SFTP allo stesso modo in cui si applicano a qualsiasi altro blob.
Per maggiori informazioni, consulta il modello di permessi SFTP e Autorizza l'accesso a gestione rete virtuale di Azure tramite SFTP utilizzando Microsoft Entra ID.
Controlla la compatibilità prima di migrare
La maggior parte dei carichi di lavoro migra senza modifiche, e Archiviazione BLOB di Azure supporta un'ampia gamma di strumenti client SFTP. Per confermare il tuo scenario, consulta i client supportati noti e le limitazioni e i problemi noti con SFTP.
Controlla questi elementi in anticipo, perché sono le ragioni più comuni per cui un carico di lavoro non può spostarsi as-is:
Una configurazione ACL esistente nel percorso di accesso.
Un indirizzo IP statico in uscita inserito da un'altra organizzazione in un elenco di elementi consentiti.
Un requisito per un flusso di lavoro gestito per il trasferimento file o per AS2.
Provalo con un carico di lavoro
Abilita SFTP su un account di storage non produttivo e gestisci un feed a basso rischio insieme al tuo server esistente per due settimane. Ottieni cifre di throughput, compatibilità e costi dal tuo carico di lavoro, che sono più utili di una stima.