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.
È possibile accedere alle condivisioni file di Azure tramite l'endpoint accessibile a Internet pubblico, su uno o più endpoint privati nella rete o memorizzando nella cache la condivisione file di Azure in locale con Sincronizzazione file di Azure (solo condivisioni file SMB). Questo articolo è incentrato su come configurare File di Azure per l'accesso diretto tramite endpoint pubblici e/o privati. Per informazioni su come memorizzare nella cache la condivisione file di Azure in locale con Sincronizzazione file di Azure, vedere Introduzione a Sincronizzazione file di Azure.
È consigliabile leggere Pianificazione per una distribuzione di File di Azure prima di leggere questa guida.
L'accesso diretto a una condivisione file di Azure richiede spesso considerazioni aggiuntive rispetto alla rete:
Le condivisioni file SMB comunicano sulla porta 445, che molte organizzazioni e provider di servizi Internet bloccano per il traffico verso l'esterno (internet). Questa pratica ha origine da indicazioni sulla sicurezza legacy relative alle versioni deprecate e non sicure per Internet del protocollo SMB. Anche se SMB 3.x è un protocollo sicuro da Internet, i criteri aziendali o ISP potrebbero non essere possibili da modificare. Pertanto, il montaggio di una condivisione file SMB spesso richiede una configurazione di rete aggiuntiva da usare all'esterno di Azure.
Le condivisioni file NFS si basano sull'autenticazione a livello di rete e sono quindi accessibili solo tramite reti con restrizioni. L'uso di una condivisione file NFS richiede sempre un livello di configurazione di rete.
La configurazione di endpoint pubblici e privati per File di Azure viene eseguita nell'oggetto di gestione di primo livello per File di Azure, l'account di archiviazione di Azure. Un account di archiviazione è un costrutto di gestione che rappresenta un pool condiviso di archiviazione in cui è possibile distribuire più condivisioni file di Azure, nonché le risorse di archiviazione per altri servizi di archiviazione di Azure, ad esempio contenitori BLOB o code.
Questo video è una guida e una demo su come esporre in modo sicuro le condivisioni file di Azure direttamente agli information worker e alle app in cinque semplici passaggi. Le sezioni seguenti forniscono collegamenti e contesto aggiuntivo alla documentazione a cui si fa riferimento nel video. Tenere presente che Azure Active Directory è ora Microsoft Entra ID. Per altre informazioni, vedere Nuovo nome di Azure AD.
Si applica a
Tipo di condivisione file | Piccole e Medie Imprese (PMI) | NFS |
---|---|---|
Condivisioni di file Standard (GPv2), LRS/ZRS | ![]() |
![]() |
Condivisioni file Standard (GPv2), archiviazione con ridondanza geografica/archiviazione con ridondanza geografica della zona | ![]() |
![]() |
Condivisioni file Premium (FileStorage), archiviazione con ridondanza locale/archiviazione con ridondanza della zona | ![]() |
![]() |
Trasferimento sicuro
Per impostazione predefinita, gli account di archiviazione di Azure richiedono il trasferimento sicuro, indipendentemente dal fatto che i dati siano accessibili tramite l'endpoint pubblico o privato. Per File di Azure, l'impostazione Trasferimento sicuro obbligatorio viene applicata per tutti gli accessi al protocollo ai dati archiviati nelle condivisioni file di Azure, tra cui SMB, NFS e FileREST. È possibile disabilitare l'impostazione Trasferimento sicuro necessario per consentire il traffico non crittografato.
I protocolli SMB, NFS e FileREST hanno un comportamento leggermente diverso rispetto all'impostazione Trasferimento sicuro richiesto :
Quando il trasferimento sicuro necessario è abilitato in un account di archiviazione, tutte le condivisioni file SMB in tale account di archiviazione richiederanno il protocollo SMB 3.x con AES-128-CCM, AES-128-GCM o AES-256-GCM, a seconda della negoziazione di crittografia disponibile/richiesta tra il client SMB e File di Azure. È possibile attivare o disattivare gli algoritmi di crittografia SMB consentiti tramite le impostazioni di sicurezza SMB. La disabilitazione dell'impostazione Trasferimento sicuro richiesto abilita i montaggi SMB 2.1 e SMB 3.x senza crittografia.
Le condivisioni file di Azure NFS usano il pacchetto di utilità AZNFS per semplificare i montaggi crittografati installando e configurando Stunnel (un wrapper TLS open source) nel client. Vedere Crittografia in transito per le condivisioni file di Azure NFS.
Quando è necessario il trasferimento sicuro, il protocollo FileREST può essere usato solo con HTTPS.
Annotazioni
La comunicazione tra un client e un account di archiviazione di Azure viene crittografata tramite Transport Layer Security (TLS). File di Azure si basa su un'implementazione di Windows di SSL non basata su OpenSSL e pertanto non è esposta alle vulnerabilità correlate a OpenSSL. Gli utenti che preferiscono mantenere la flessibilità tra le connessioni TLS e non TLS nello stesso account di archiviazione devono disabilitare il trasferimento sicuro necessario.
Endpoint pubblico
L'endpoint pubblico per le condivisioni file di Azure all'interno di un account di archiviazione è un endpoint esposto a Internet. L'endpoint pubblico è l'endpoint predefinito per un account di archiviazione, ma può essere disabilitato se necessario.
I protocolli SMB, NFS e FileREST possono usare tutti l'endpoint pubblico. Tuttavia, ognuna ha regole leggermente diverse per l'accesso:
Le condivisioni file SMB sono accessibili da qualsiasi parte del mondo tramite l'endpoint pubblico dell'account di archiviazione con SMB 3.x con crittografia. Ciò significa che le richieste autenticate, ad esempio le richieste autorizzate dall'identità di accesso di un utente, possono provenire in modo sicuro dall'interno o dall'esterno dell'area di Azure. Se si desidera SMB 2.1 o SMB 3.x senza crittografia, è necessario soddisfare due condizioni:
- L'impostazione Trasferimento sicuro dell'account di archiviazione obbligatoria deve essere disabilitata.
- La richiesta deve provenire dall'interno dell'area di Azure. Come accennato in precedenza, le richieste SMB crittografate sono consentite ovunque, all'interno o all'esterno dell'area di Azure.
Le condivisioni file NFS sono accessibili dall'endpoint pubblico dell'account di archiviazione se e solo se l'endpoint pubblico dell'account di archiviazione è limitato a reti virtuali specifiche che usano endpoint di servizio. Per altre informazioni sugli endpoint di servizio, vedere Impostazioni del firewall dell'endpoint pubblico.
FileREST è accessibile tramite l'endpoint pubblico. Se è necessario il trasferimento sicuro, vengono accettate solo le richieste HTTPS. Se il trasferimento sicuro è disabilitato, le richieste HTTP vengono accettate dall'endpoint pubblico indipendentemente dall'origine.
Impostazioni del firewall dell'endpoint pubblico
Il firewall dell'account di archiviazione limita l'accesso all'endpoint pubblico per un account di archiviazione. Usando il firewall dell'account di archiviazione, è possibile limitare l'accesso a determinati indirizzi IP/intervalli di indirizzi IP, a reti virtuali specifiche o disabilitare completamente l'endpoint pubblico.
Quando si limita il traffico dell'endpoint pubblico a una o più reti virtuali, si usa una funzionalità della rete virtuale denominata endpoint servizio. Le richieste indirizzate all'endpoint di servizio di File di Azure continueranno a raggiungere l'indirizzo IP pubblico dell'account di archiviazione; Tuttavia, il livello di rete esegue una verifica aggiuntiva della richiesta per verificare che proveni da una rete virtuale autorizzata. Tutti i protocolli SMB, NFS e FileREST supportano tutti gli endpoint di servizio. A differenza di SMB e FileREST, tuttavia, le condivisioni file NFS possono essere accessibili solo con l'endpoint pubblico tramite l'uso di un endpoint di servizio.
Per altre informazioni su come configurare il firewall dell'account di archiviazione, vedere Configurare firewall e reti virtuali di archiviazione di Azure.
Routing di rete degli endpoint pubblici
File di Azure supporta più opzioni di routing di rete. L'opzione predefinita, routing Microsoft, funziona con tutte le configurazioni di File di Azure. L'opzione di routing Internet non supporta scenari di aggiunta a un dominio di Active Directory o Sincronizzazione file di Azure.
Endpoint privati
Oltre all'endpoint pubblico predefinito per un account di archiviazione, File di Azure offre la possibilità di avere uno o più endpoint privati. Un endpoint privato è un endpoint accessibile solo all'interno di una rete virtuale di Azure. Quando si crea un endpoint privato per l'account di archiviazione, l'account di archiviazione ottiene un indirizzo IP privato dallo spazio di indirizzi della rete virtuale, in modo analogo a quanto un file server locale o un dispositivo NAS riceve un indirizzo IP all'interno dello spazio di indirizzi dedicato della rete locale.
Un singolo endpoint privato è associato a una specifica subnet di rete virtuale di Azure. Un account di archiviazione può avere endpoint privati in più reti virtuali.
L'uso di endpoint privati con File di Azure consente di:
- Connettersi in modo sicuro alle condivisioni file di Azure dalle reti locali usando una connessione VPN o ExpressRoute con peering privato.
- Proteggere le condivisioni file di Azure configurando il firewall dell'account di archiviazione in modo da bloccare tutte le connessioni all'endpoint pubblico. Per impostazione predefinita, la creazione di un endpoint privato non blocca le connessioni all'endpoint pubblico.
- Aumentare la sicurezza per la rete virtuale consentendo di bloccare l'esfiltrazione dei dati dalla rete virtuale e dai limiti di peering.
Per creare un endpoint privato, vedere Configurazione di endpoint privati per File di Azure.
Tunneling del traffico su una rete privata virtuale o ExpressRoute
Per usare gli endpoint privati per accedere alle condivisioni file SMB o NFS dall'ambiente locale, è necessario stabilire un tunnel di rete tra la rete locale e Azure. Una rete virtuale, o VNet, è simile a una rete locale tradizionale. Come un account di archiviazione di Azure o una macchina virtuale di Azure, una rete virtuale è una risorsa di Azure distribuita in un gruppo di risorse.
File di Azure supporta i meccanismi seguenti per eseguire il tunneling del traffico tra le workstation e i server locali e le condivisioni file SMB/NFS di Azure:
- Gateway VPN di Azure: un gateway VPN è un tipo specifico di gateway di rete virtuale, usato per inviare traffico crittografato tra una rete virtuale di Azure e una posizione alternativa, ad esempio l'ambiente locale, attraverso Internet. Un gateway VPN di Azure è una risorsa di Azure che può essere distribuita in un gruppo di risorse insieme a un account di archiviazione o ad altre risorse di Azure. I gateway VPN espongono due tipi diversi di connessioni:
- Connessioni gateway VPN da punto a sito (P2S), ovvero connessioni VPN tra Azure e un singolo client. Questa soluzione è particolarmente utile per i dispositivi che non fanno parte della rete locale dell'organizzazione. Un caso d'uso comune è per i lavoratori a distanza che vogliono poter montare la condivisione file di Azure da casa, da un bar o da un hotel mentre sono in viaggio. Per usare una connessione VPN da punto a sito con File di Azure, è necessario configurare una connessione VPN da punto a sito per ogni client che vuole connettersi. Vedere Configurare una VPN da punto a sito (P2S) in Windows per l'uso con File di Azure e Configurare una VPN da punto a sito (P2S) in Linux per l'uso con File di Azure.
- VPN da sito a sito (S2S), ovvero connessioni VPN tra Azure e la rete dell'organizzazione. Una connessione VPN da sito a sito consente di configurare una connessione VPN una sola volta per un server VPN o un dispositivo ospitato nella rete dell'organizzazione, anziché configurare una connessione per ogni dispositivo client che deve accedere alla condivisione file di Azure. Vedere Configurare una VPN da sito a sito (S2S) da usare con File di Azure.
- ExpressRoute, che consente di creare una route definita tra Azure e la rete locale che non attraversa Internet. Poiché ExpressRoute fornisce un percorso dedicato tra il data center locale e Azure, ExpressRoute può essere utile quando si considerano le prestazioni di rete. ExpressRoute è un'opzione valida anche laddove i criteri dell'organizzazione o i requisiti ambientali impongono un percorso deterministico verso le risorse nel cloud.
Annotazioni
Sebbene sia consigliabile usare endpoint privati per facilitare l'estensione della rete locale in Azure, è tecnicamente possibile indirizzare all'endpoint pubblico tramite la connessione VPN. Tuttavia, è necessario impostare come hardcoded l'indirizzo IP per l'endpoint pubblico per il cluster di archiviazione di Azure che serve l'account di archiviazione. Poiché gli account di archiviazione possono essere spostati tra cluster di archiviazione in qualsiasi momento e i nuovi cluster vengono aggiunti e rimossi di frequente, è necessario impostare regolarmente come hardcoded tutti i possibili indirizzi IP di archiviazione di Azure nelle regole di routing.
Configurazione del DNS
Quando si crea un endpoint privato, per impostazione predefinita viene creata anche una zona DNS privata (o aggiornare una zona DNS esistente) corrispondente al privatelink
sottodominio. In senso stretto, la creazione di una zona DNS privata non è necessaria per usare un endpoint privato per l'account di archiviazione. Tuttavia, è consigliabile in generale ed è necessario in modo esplicito quando si monta la condivisione file di Azure con un'entità utente di Active Directory o si accede dall'API FileREST.
Annotazioni
Questo articolo usa il suffisso DNS dell'account di archiviazione per le aree pubbliche di Azure, core.windows.net
. Questo commento si applica anche ai cloud sovrani di Azure, ad esempio il cloud di Azure US Government e il cloud di Microsoft Azure gestito da 21Vianet, semplicemente sostituire i suffissi appropriati per l'ambiente in uso.
Nella zona DNS privata viene creato un record A per storageaccount.privatelink.file.core.windows.net
e un record CNAME per il nome regolare dell'account di archiviazione, che segue il modello storageaccount.file.core.windows.net
. Poiché la zona DNS privata di Azure è connessa alla rete virtuale contenente l'endpoint privato, è possibile osservare la configurazione DNS chiamando il Resolve-DnsName
cmdlet da PowerShell in una macchina virtuale di Azure (in alternativa nslookup
in Windows e Linux):
Resolve-DnsName -Name "storageaccount.file.core.windows.net"
In questo esempio l'account di archiviazione storageaccount.file.core.windows.net
viene risolto nell'indirizzo IP privato dell'endpoint privato, che si verifica come 192.168.0.4
.
Name Type TTL Section NameHost
---- ---- --- ------- --------
storageaccount.file.core.windows. CNAME 29 Answer csostoracct.privatelink.file.core.windows.net
net
Name : storageaccount.privatelink.file.core.windows.net
QueryType : A
TTL : 1769
Section : Answer
IP4Address : 192.168.0.4
Name : privatelink.file.core.windows.net
QueryType : SOA
TTL : 269
Section : Authority
NameAdministrator : azureprivatedns-host.microsoft.com
SerialNumber : 1
TimeToZoneRefresh : 3600
TimeToZoneFailureRetry : 300
TimeToExpiration : 2419200
DefaultTTL : 300
Se si esegue lo stesso comando dall'ambiente locale, si noterà che lo stesso nome dell'account di archiviazione viene risolto nell'indirizzo IP pubblico dell'account di archiviazione. Ad esempio, storageaccount.file.core.windows.net
è un record CNAME per storageaccount.privatelink.file.core.windows.net
, che a sua volta è un record CNAME per il cluster di archiviazione di Azure che ospita l'account di archiviazione:
Name Type TTL Section NameHost
---- ---- --- ------- --------
storageaccount.file.core.windows. CNAME 60 Answer storageaccount.privatelink.file.core.windows.net
net
storageaccount.privatelink.file.c CNAME 60 Answer file.par20prdstr01a.store.core.windows.net
ore.windows.net
Name : file.par20prdstr01a.store.core.windows.net
QueryType : A
TTL : 60
Section : Answer
IP4Address : 52.239.194.40
Ciò riflette il fatto che l'account di archiviazione può esporre sia l'endpoint pubblico che uno o più endpoint privati. Per assicurarsi che il nome dell'account di archiviazione venga risolto nell'indirizzo IP privato dell'endpoint privato, è necessario cambiare la configurazione nei server DNS locali. A questo scopo è possibile procedere in vari modi:
- Modificare il file hosts nei client per fare in modo che
storageaccount.file.core.windows.net
risolva all'indirizzo IP privato dell'endpoint privato desiderato. Questo è fortemente sconsigliato per gli ambienti di produzione, perché sarà necessario apportare queste modifiche a ogni client che vuole montare le condivisioni file di Azure e le modifiche apportate all'account di archiviazione o all'endpoint privato non verranno gestite automaticamente. - Creazione di un record A per
storageaccount.file.core.windows.net
nei server DNS locali. Questo ha il vantaggio che i client nell'ambiente locale saranno in grado di risolvere automaticamente l'account di archiviazione senza dover configurare ogni client. Tuttavia, questa soluzione è analogamente fragile per modificare il file hosts perché le modifiche non vengono riflesse. Anche se questa soluzione è fragile, potrebbe essere la scelta migliore per alcuni ambienti. - Inoltrare la
core.windows.net
zona dai server DNS locali alla zona DNS privato di Azure. L'host DNS privato di Azure è raggiungibile tramite un indirizzo IP speciale (168.63.129.16
) accessibile solo all'interno delle reti virtuali collegate alla zona DNS privato di Azure. Per ovviare a questa limitazione, è possibile eseguire altri server DNS all'interno della rete virtuale che verranno inoltraticore.windows.net
alla zona DNS privato di Azure. Per semplificare questa configurazione, sono stati forniti i cmdlet di PowerShell che distribuiranno automaticamente i server DNS nella rete virtuale di Azure e li configureranno in base alle esigenze. Per informazioni su come configurare l'inoltro DNS, vedere Configurazione di DNS con File di Azure.
SMB su QUIC
Windows Server 2022 Azure Edition supporta un nuovo protocollo di trasporto denominato QUIC per il server SMB fornito dal ruolo File Server. QUIC è una sostituzione di TCP basata su UDP, che offre numerosi vantaggi rispetto a TCP, fornendo comunque un meccanismo di trasporto affidabile. Un vantaggio fondamentale per il protocollo SMB è che invece di usare la porta 445, tutto il trasporto viene eseguito sulla porta 443, che è ampiamente aperto per supportare HTTPS. Ciò significa che SMB su QUIC offre una "VPN SMB" per la condivisione di file tramite Internet pubblico. Windows 11 viene fornito con un client in grado di supportare SMB su QUIC.
Al momento, File di Azure non supporta direttamente SMB tramite QUIC. Tuttavia, è possibile accedere alle condivisioni file di Azure tramite Sincronizzazione file di Azure in esecuzione in Windows Server come illustrato nel diagramma seguente. In questo modo è anche possibile avere cache di Sincronizzazione file di Azure sia in locale che in data center di Azure diversi per fornire cache locali per una forza lavoro distribuita. Per altre informazioni su questa opzione, vedere Distribuzione di Azure File Sync e SMB tramite QUIC.