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.

Leggi Pianificazione per una distribuzione di 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.

Si configurano endpoint pubblici e privati per File di Azure sull'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:

Crittografia dei dati in transito per SMB

L'impostazione Richiedere la 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.

Crittografia in transito per NFS

L'impostazione Richiedere la Crittografia in Transit per NFS determina 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.

Crittografia dei dati in transito per FileREST

L'impostazione Secure transfer required 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. Puoi limitare l'accesso a certi indirizzi IP o intervalli di indirizzi IP, a specifiche reti virtuali, oppure disabilitare completamente l'endpoint pubblico.

Quando limiti l'endpoint pubblico a una o più reti, stai usando una capacità della rete virtuale chiamata service endpoint. Le richieste indirizzate all'endpoint di servizio di File di Azure vanno comunque all'indirizzo IP pubblico dell'account di storage. Tuttavia, il livello di rete esegue una verifica aggiuntiva della richiesta per verificare che proviene 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 utilizzando l'endpoint pubblico tramite l'uso di un endpoint di servizio.

Accesso al portale di Azure e firewall dell'account di archiviazione

Quando si accede alle condivisioni file di Azure tramite il portale di Azure, si verificano due richieste separate:

1. Richiesta dal browser all'interfaccia utente del portale di Azure (https://portal.azure.com).
2. Una richiesta proveniente direttamente dal browser verso l'endpoint del piano dati di File di Azure (ad esempio, https://<storage-account-name>.file.core.windows.net), in genere utilizzando un SAS token emesso per l'esperienza del portale.

Il firewall dell'account di archiviazione valuta solo la richiesta diretta all'endpoint del piano dati di File di Azure, non la richiesta a portal.azure.com. Pertanto, anche se è possibile accedere al portale di Azure senza problemi, è possibile che venga visualizzato un errore 403 (Accesso negato) durante l'esplorazione dei dati della condivisione file se l'indirizzo IP in uscita pubblico nella richiesta da browser a archiviazione non è consentito dal firewall. Questa restrizione si applica solo al traffico FileREST/HTTPS, non SMB o NFS. Per ulteriori informazioni, consulta Autorizzare l'accesso ai dati dei file nel portale Azure.

Routing di rete degli endpoint pubblici

File di Azure supporta due opzioni di routing di rete:

• Routing Microsoft (predefinito): Il traffico tra il client e l'account di archiviazione viaggia attraverso la backbone globale di Microsoft il più a lungo possibile prima di uscire verso internet. Questa opzione funziona con tutte le configurazioni di File di Azure, inclusi gli scenari di join di dominio Active Directory (AD) e Sincronizzazione file di Azure.
• Instradamento di Internet: Il traffico viene instradato tramite internet pubblico il prima possibile. Questa opzione non supporta scenari di join di dominio Active Directory (AD) né 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 è simile a una rete tradizionale on-premise. Come un account di storage Azure o una VM Azure, una rete virtuale è una risorsa Azure che distribuisci 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.

VPN da punto a sito

Gateway VPN di Azure supporta le connessioni VPN point-to-site, 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 utilizzare una connessione VPN point-to-site con File di Azure, devi configurare una connessione VPN Point-to-Site per ogni client che desidera connettersi. Vedi Configura una VPN Point-to-Site su Windows per l'uso con File di Azure e Configura una VPN Point-to-Site su Linux per l'uso con File di Azure.

VPN da sito a sito

Gateway VPN di Azure supporta anche le connessioni VPN site-to-site, ovvero connessioni VPN tra Azure e la rete della tua organizzazione. Una connessione VPN site-to-site ti permette di configurare una connessione VPN una sola volta per un server o dispositivo VPN ospitato sulla rete della tua organizzazione, invece di configurare una connessione per ogni dispositivo client che deve accedere alla tua condivisione file Azure. Vedi Configura una VPN Site-to-Site per l'uso con File di Azure.

ExpressRoute

ExpressRoute ti permette di creare un percorso definito tra Azure e la tua rete on-premises 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 crei un endpoint privato, Azure crea o aggiorna anche una zona DNS privata 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, è altamente consigliato ed è esplicitamente necessario quando si monta la condivisione file Azure con un user principal Active Directory o si accede dall'API FileREST.

Nella tua zona DNS privata, Azure crea 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 pattern 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     storageaccount.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

Questa configurazione riflette che l'account di storage può esporre sia l'endpoint pubblico sia 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. È possibile farlo in diversi 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 aggirare questa limitazione, puoi eseguire server DNS aggiuntivi all'interno della tua rete virtuale che inoltrano core.windows.net nella zona DNS privata di Azure. Per semplificare questa configurazione, Microsoft fornisce cmdlet PowerShell che implementano automaticamente i server DNS nella tua rete virtuale Azure e li configurano secondo desiderio. 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 protocollo di trasporto chiamato QUIC per il server SMB fornito dal ruolo File Server. QUIC è un sostituto del TCP costruito sopra l'UDP, offrendo numerosi vantaggi rispetto al TCP pur fornendo 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. Questa configurazione significa di fatto 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.

Attualmente, File di Azure non supporta SMB tramite QUIC. Tuttavia, puoi accedere alle condivisioni file di Azure tramite Sincronizzazione file di Azure che gira su Windows Server come nel diagramma seguente. Questa configurazione offre anche la possibilità di avere Sincronizzazione file di Azure cache sia on-premises che in diversi datacenter Azure per fornire cache locali a una forza lavoro distribuita. Per saperne di più su questa opzione, consulta la documentazione di Windows Server. Per dettagli specifici di rete di Sincronizzazione file di Azure, vedi SMB over QUIC.

Vedere anche

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