File di Azure considerazioni sulla rete

✔️ Applica a: Tutte le condivisioni file di Azure

È possibile accedere alle condivisioni file Azure tramite l'endpoint accessibile a Internet pubblico, su uno o più endpoint privati nella rete o memorizzando nella cache la condivisione file Azure 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 Azure locale con Sincronizzazione file di Azure, vedere Introduzione a Sincronizzazione file di Azure.

È consigliabile leggere Planning per una distribuzione File di Azure prima di leggere questa guida.

L'accesso diretto a una condivisione file Azure spesso richiede 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 Azure. Un account di archiviazione è un costrutto di gestione che rappresenta un pool di archiviazione condiviso in cui è possibile distribuire più condivisioni file di Azure, oltre ad altre risorse di archiviazione per altri servizi di archiviazione Azure, come contenitori BLOB o code.

Trasferimento sicuro

Per impostazione predefinita, Azure account di archiviazione richiedono il trasferimento sicuro, indipendentemente dal fatto che i dati siano accessibili tramite l'endpoint pubblico o privato. Per File di Azure, la crittografia in transito viene controllata a livello di protocollo:

• SMB: l'impostazione Richiedi crittografia in transito per SMB controlla se la crittografia è necessaria per l'accesso SMB. Per i nuovi account di archiviazione creati usando il portale di Azure, questa impostazione è abilitata per impostazione predefinita. Gli account di archiviazione creati usando Azure PowerShell, interfaccia della riga di comando di Azure o l'API FileREST impostano questo valore come Non selezionato per garantire la compatibilità con le versioni precedenti. Per gli account di archiviazione esistenti, l'impostazione Trasferimento sicuro obbligatorio continua a gestire il comportamento di crittografia SMB fino a quando non si configura in modo esplicito l'impostazione SMB per protocollo. Quando è necessaria la crittografia SMB in transito, tutte le condivisioni file SMB in tale account di archiviazione richiedono il protocollo SMB 3.x con algoritmi di crittografia AES-128-CCM, AES-128-GCM o AES-256-GCM. È possibile attivare/disattivare gli algoritmi consentiti tramite le impostazioni di sicurezza SMB. La disabilitazione di questa impostazione abilita i montaggi SMB 2.1 e SMB 3.x senza crittografia.

• NFS: l'impostazione Richiedi crittografia in transito per NFS controlla se la crittografia è necessaria per l'accesso NFS. NFS Azure condivisioni file usano il pacchetto di utilità AZNFS per semplificare i montaggi crittografati installando e configurando Stunnel (un wrapper TLS open source) nel client. Vedere Encryption in transito per le condivisioni file Azure NFS. Per i nuovi account di archiviazione creati usando il portale di Azure, questa impostazione è abilitata per impostazione predefinita. Gli account di archiviazione creati usando Azure PowerShell, interfaccia della riga di comando di Azure o l'API FileREST impostano questo valore come Non selezionato per garantire la compatibilità con le versioni precedenti. Per gli account di archiviazione esistenti, l'impostazione Trasferimento sicuro obbligatorio continua a gestire il comportamento di crittografia NFS fino a quando non si configura in modo esplicito l'impostazione NFS per protocollo.

• FileREST: l'impostazione Trasferimento sicuro obbligatorio si applica al traffico REST/HTTPS. Se abilitato, il protocollo FileREST può essere usato solo con HTTPS.

Endpoint pubblico

L'endpoint pubblico per le condivisioni file 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 Azure. Se si desidera SMB 2.1 o SMB 3.x senza crittografia, è necessario soddisfare due condizioni:

  1. L'impostazione Richiedi crittografia in transito per SMB deve essere disabilitata oppure, per gli account esistenti in cui questa impostazione non è stata configurata in modo esplicito, l'impostazione Trasferimento sicuro obbligatorio deve essere disabilitata.
  2. La richiesta deve provenire dall'interno dell'area Azure. Come accennato in precedenza, le richieste SMB crittografate sono consentite ovunque, all'interno o all'esterno dell'area 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 Azure firewall di archiviazione e reti virtuali.

Routing di rete degli endpoint pubblici

File di Azure supporta più opzioni di routing di rete. L'opzione predefinita, Microsoft routing, 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 è un endpoint accessibile solo all'interno di una rete virtuale 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 subnet di rete virtuale Azure specifica. 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 Azure da reti locali usando una connessione VPN o ExpressRoute con peering privato.
• Proteggere le condivisioni file Azure configurando il firewall dell'account di archiviazione per bloccare tutte le connessioni nell'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 Azure o una macchina virtuale Azure, una rete virtuale è una risorsa Azure distribuita in un gruppo di risorse.

File di Azure supporta i seguenti meccanismi per eseguire il tunneling del traffico tra workstation e 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 Azure e un percorso alternativo (ad esempio in locale) su Internet. Un Gateway VPN di Azure è una risorsa Azure che può essere distribuita in un gruppo di risorse insieme a un account di archiviazione o ad altre risorse 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 telelavoratori che desiderano essere in grado di montare la condivisione file Azure da casa, un bar o 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 da usare 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, che sono connessioni VPN tra Azure e la rete dell'organizzazione. Una connessione VPN da sito a sito consente di configurare una sola volta una connessione VPN 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 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.

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, è generalmente consigliato ed è esplicitamente necessario quando si monta la condivisione file Azure con un principale utente di Active Directory o quando si accede ad essa dall'API FileREST.

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 Azure è connessa alla rete virtuale contenente l'endpoint privato, è possibile osservare la configurazione DNS chiamando il cmdlet Resolve-DnsName da PowerShell in una macchina virtuale 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 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é è necessario apportare queste modifiche a ogni client che vuole montare le condivisioni file 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 zona core.windows.net dai server DNS locali alla zona DNS Azure privata. Il Azure host DNS privato può essere raggiunto tramite un indirizzo IP speciale (168.63.129.16) accessibile solo all'interno di reti virtuali collegate alla zona DNS privata Azure. Per ovviare a questa limitazione, è possibile eseguire altri server DNS all'interno della rete virtuale che inoltrano core.windows.net alla zona DNS privata Azure. Per semplificare questa configurazione, sono stati forniti i cmdlet di PowerShell che distribuiranno automaticamente i server DNS nella rete virtuale 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 con supporto 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 su Windows Server come illustrato nel diagramma seguente. In questo modo è anche possibile avere Sincronizzazione file di Azure cahare sia nel sito locale che in diversi datacenter Azure per offrire cache locali a una forza lavoro distribuita. Per altre informazioni su questa opzione, vedere Deploy Sincronizzazione file di Azure e SMB su QUIC.

Vedere anche

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