Considerazioni sulla rete per File di Azure

È 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 su 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 alle Sincronizzazione file di Azure.

È consigliabile leggere Pianificazione per una distribuzione 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 il traffico in uscita (Internet). Questa procedura ha origine da materiale sussidiario sulla sicurezza legacy sulle versioni deprecate e non internet sicure 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 per 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. Si noti che Azure Active Directory è ora Microsoft Entra ID. Per altre informazioni, vedere Nuovo nome per Azure AD.

Si applica a

Tipo di condivisione file	SMB	NFS
Condivisioni file Standard (GPv2), archiviazione con ridondanza locale/archiviazione con ridondanza della zona
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 richiedi trasferimento sicuro viene applicata per tutti i protocolli di accesso ai dati archiviati nelle condivisioni file di Azure, tra cui SMB, NFS e FileREST. È possibile disabilitare l'impostazione richiedi trasferimento sicuro per consentire il traffico non crittografato. Nella portale di Azure, è anche possibile che questa impostazione sia etichettata come trasferimento sicuro per le operazioni dell'API REST.

I protocolli SMB, NFS e FileREST hanno un comportamento leggermente diverso rispetto all'impostazione di trasferimento sicuro necessario:

• Quando è necessario abilitare il trasferimento sicuro 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 di trasferimento sicuro richiesto abilita i montaggi SMB 2.1 e SMB 3.x senza crittografia.

• Le condivisioni file NFS non supportano un meccanismo di crittografia, quindi per usare il protocollo NFS per accedere a una condivisione file di Azure, è necessario disabilitare richiedere il trasferimento sicuro per l'account di archiviazione.

• Quando è necessario il trasferimento sicuro, il protocollo FileREST può essere usato solo con HTTPS. FileREST è attualmente supportato solo nelle condivisioni file SMB.

Nota

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.

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:

  1. L'impostazione di trasferimento sicuro dell'account di archiviazione deve essere disabilitata.
  2. 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 continuano 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 i firewall e le 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 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 è accessibile solo all'interno di una rete virtuale di Azure. Quando si crea un endpoint privato per l'account di archiviazione, quest'ultimo ottiene un indirizzo IP privato dallo spazio di indirizzi della rete virtuale, in modo simile a un dispositivo file server o NAS locale che 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 una rete virtuale è simile a una rete locale tradizionale. Analogamente a un account di archiviazione o a una VM 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:

• Azure Gateway VPN: un gateway VPN è un tipo specifico di gateway di rete virtuale usato per inviare traffico crittografato tra una rete virtuale di Azure e un percorso alternativo (ad esempio in locale) tramite 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:
  • VPN da punto a sito, 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 telelavoratori che vogliono poter montare la condivisione file di Azure da casa, un bar o un hotel durante la strada. 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 da usare con File di Azure.
  • VPN da sito a sito, 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 per l'uso 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.

Nota

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 si crea anche una zona DNS privato (o se ne aggiorna una esistente) corrispondente al sottodominio privatelink. 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.

Nota

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 privato 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 storageaccount.file.core.windows.net di archiviazione 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

Il motivo è 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:

• Modifica del file hosts nei client per risolvere storageaccount.file.core.windows.net l'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.
• Creare 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 zona core.windows.net 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 inoltrati core.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.

Server Message Block (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 compatibile con SMB su QUIC.

Al momento, File di Azure non supporta direttamente SMB su 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 Sincronizzazione file di Azure memorizzare nella cache 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 Distribuire Sincronizzazione file di Azure e SMB tramite QUIC.

Vedi anche

• Panoramica di File di Azure
• Pianificazione per la distribuzione di File di Azure