File di Azure considerazioni sulla rete

✔️ Applica a: Tutte le condivisioni file di Azure

Le condivisioni file Azure hanno endpoint pubblici e possono avere uno o più endpoint privati. I percorsi di rete disponibili ai client dipendono dal protocollo e dalle regole di rete. Questo articolo tratta sia le condivisioni file classiche (Microsoft.Storage) sia le condivisioni file create con Microsoft.FileShares. Sincronizzazione file di Azure offre un'opzione di cache per le classiche condivisioni file SMB. Per altre informazioni, vedere Introduzione a Sincronizzazione file di Azure.

Per considerazioni più ampie sulla distribuzione, vedi Pianifica una distribuzione File di Azure. Per i passaggi di configurazione, vedi Configura endpoint di rete per le condivisioni file Azure.

Due differenze nei protocolli influenzano la progettazione della rete:

• SMB utilizza la porta TCP 445, che alcune organizzazioni e fornitori di servizi internet bloccano per il traffico in uscita. La connettività privata tramite VPN o ExpressRoute offre un percorso alternativo.

• NFS utilizza l'autenticazione basata su rete. I client si collegano tramite endpoint privati o tramite endpoint di servizio dalle subnet consentite della rete virtuale.

Le condivisioni file classiche supportano SMB e NFS. Microsoft. FileShares attualmente supporta NFS. Entrambi i fornitori di risorse supportano endpoint pubblici e privati. Per le differenze nella proprietà e nella gestione delle risorse, vedi File di Azure management concepts.

Crittografia dei dati in transito

La crittografia in transito protegge la riservatezza e l'integrità dei dati tra client e File di Azure, inclusa la protezione contro intercettazioni o modifiche da parte di un attaccante man-in-the-middle. Questa protezione si applica sia agli endpoint pubblici che privati. La crittografia e le regole di accesso alla rete hanno scopi separati: la crittografia protegge la connessione, mentre le regole di rete determinano quali client possono raggiungere il servizio.

Crittografia in transito per SMB

SMB 3.x protegge i dati tramite la crittografia dei canali SMB. File di Azure supporta AES-128-CCM con SMB 3.0 e AES-128-GCM e AES-256-GCM con SMB 3.1.1. L'algoritmo di crittografia dipende dalle capacità del client e dagli algoritmi consentiti dal servizio. SMB 2.1 non supporta la crittografia dei canali.

Limitare gli algoritmi consentiti può influire sulla compatibilità dei clienti. Ad esempio, i client Windows più vecchi non supportano AES-256-GCM. La crittografia dei canali protegge i dati dei file sulla connessione; la crittografia dei ticket Kerberos protegge i ticket di autenticazione. Questi sono controlli separati. Per il supporto client e la configurazione, consulta le impostazioni di sicurezza SMB.

Crittografia in transito per NFS

Le condivisioni di file NFS con uno o l'altro provider di risorse supportano la crittografia tramite tunneling TLS. L'helper di montaggio AZNFS utilizza stunnel per trasportare il traffico NFS attraverso una connessione criptata tra il client e File di Azure. AZNFS supporta TLS 1.2 e TLS 1.3 e valida il certificato del server. Le applicazioni continuano a utilizzare il protocollo NFS senza implementare TLS a loro volta.

TLS protegge i dati in transito ma non aggiunge l'autenticazione basata sull'utente a NFS. Le regole di accesso alla rete e i permessi dei file regolano ancora l'accesso. Per istruzioni per il montaggio crittografato, vedi Crittografare dati in transito per le condivisioni NFS.

Crittografia in transito per FileREST

FileREST protegge i dati in transito tramite HTTPS. File di Azure supporta TLS 1.2 e TLS 1.3 per le connessioni HTTPS. Richiedere HTTPS rifiuta le richieste HTTP non criptate; un requisito minimo di versione TLS controlla quali versioni TLS i client possono utilizzare.

L'accesso ai dati FileREST è disponibile per le condivisioni file classiche. Microsoft. FileShares attualmente non supporta l'accesso ai dati FileREST.

Guide alla configurazione della crittografia

I requisiti e i valori predefiniti di crittografia dipendono dal fornitore della risorsa e dal protocollo. Le seguenti guide descrivono come visualizzarli e modificarli:

• Microsoft. FileShares: Requisiti di crittografia quando si crea una condivisione file e si aggiornano le proprietà di condivisione file con PowerShell o interfaccia della riga di comando di Azure.
• Condivisioni file classiche: crittografia SMB, crittografia NFS e requisiti HTTPS per FileREST.

Endpoint pubblico

Un endpoint pubblico ha un indirizzo IP pubblico. Un indirizzo pubblico non implica accesso illimitato: i requisiti del protocollo, le regole di rete e l'autorizzazione determinano se una richiesta è consentita.

I protocolli hanno regole diverse per l'accesso agli endpoint pubblici. SMB e FileREST si applicano alle condivisioni file classiche. NFS si applica a entrambi i fornitori di risorse:

• SMB: Le connessioni SMB 3.x criptate possono avere origine all'interno o all'esterno di Azure, soggette a regole di rete e autorizzazioni. Le connessioni SMB non criptate sono limitate ai client nella stessa regione Azure e richiedono una configurazione che consenta l'accesso non criptato.

• NFS: I client possono accedere all'endpoint pubblico solo tramite un service endpoint da una subnet consentita. NFS non supporta l'accesso diretto da client Internet.

• FileREST: I client accedono ai dati dei file tramite richieste REST. HTTPS protegge queste richieste durante il transito. Le regole di rete e l'autorizzazione si applicano indipendentemente dal fatto che HTTPS sia richiesto o meno.

Accesso alla rete in ingresso

Le regole di rete controllano l'accesso in entrata all'endpoint pubblico. Entrambi i provider di risorse supportano l'accesso da sottoreti virtuali selezionate. Anche l'accesso classico SMB e FileREST può utilizzare regole sugli indirizzi IP. L'accesso NFS richiede endpoint di servizio e subnet consentite.

Un endpoint di servizio trasporta il traffico da una subnet di rete virtuale a File di Azure tramite la backbone di Azure. Il traffico utilizza ancora l'indirizzo IP dell'endpoint pubblico. Il livello di rete identifica la subnet sorgente affinché il servizio possa confrontarla con le reti consentite.

Disabilitare l'accesso pubblico alla rete impedisce anche l'accesso dei client tramite gli endpoint dei servizi. L'accesso agli endpoint privati è indipendente da questa impostazione. Per le condivisioni file classiche, le eccezioni per i servizi attendibili esistenti possono rimanere in vigore.

Per i passaggi di configurazione di entrambi i provider di risorse, vedi Limita l'accesso pubblico all'endpoint.

Limita l'accesso in uscita con le policy degli endpoint di servizio

Le regole di rete per una condivisione file controllano l'accesso in entrata. Non limitano le destinazioni in uscita dei clienti. Ad esempio, un client che può leggere una condivisione file potrebbe copiare dati su un'altra risorsa su cui ha il permesso di scrivere.

Per le condivisioni file classiche, puoi opzionalmente usare una policy di endpoint di servizio per limitare a quali account di archiviazione possono accedere i client in una subnet tramite endpoint di servizio. La politica si applica a tutti i clienti in quella subrete. Le regole di rete e i requisiti di autorizzazione della destinazione sono ancora validi.

Le policy degli endpoint di servizio funzionano insieme ad altri controlli di rete:

• Le rotte endpoint di servizio sovrascrivono le rotte definite dall'utente (UDR) per i prefissi corrispondenti agli indirizzi di servizio. Il traffico instradato attraverso un endpoint di servizio non passa attraverso Firewall di Azure o un appliance virtuale di rete (NVA), quindi questi dispositivi non possono ispezionarlo o logarlo. Per ulteriori informazioni, vedere Endpoint di servizio della rete virtuale.
• Le regole dei gruppi di sicurezza di rete (NSG) possono utilizzare tag di servizio come Storage.WestUS per limitare il traffico in uscita verso una regione. I tag di servizio non possono limitare il traffico a un account di archiviazione specifico.

L'elenco elementi consentiti della policy può contenere account di archiviazione individuali, gruppi di risorse o abbonamenti. La policy blocca i clienti nella subnet associata dall'accesso ad altri account di storage tramite gli endpoint di servizio. Non limita altri percorsi in uscita dalla subrete.

Le policy degli endpoint di servizio non si applicano al traffico degli endpoint privati.

Per configurare una policy di endpoint di servizio, vedi Restringi l'accesso in uscita a account di archiviazione specifici.

Accesso al portale di Azure

L'apertura di una risorsa nel portale Azure e l'accesso ai relativi dati di file sono operazioni separate. Per le condivisioni file classiche, navigare i dati invia richieste FileREST dal browser all'endpoint del servizio file. Queste richieste sono soggette alle regole di rete dell'account di archiviazione. Il solo accesso al portale non garantisce l'accesso alla rete per i dati dei file.

Microsoft. FileShares attualmente non supporta l'accesso ai dati FileREST. Per i classici requisiti di esplorazione delle condivisioni file e risoluzione dei problemi, vedi Autorizzare l'accesso ai dati dei file nel portale Azure.

Routing di rete degli endpoint pubblici

La preferenza di routing è disponibile solo per le classiche condivisioni file HDD che utilizzano il modello pay-as-you-go negli account di archiviazione StorageV2. Non è supportata per le condivisioni file provisionate negli account di archiviazione FileStorage né per Microsoft.FileShares.

Per questi account pay-as-you-go, la preferenza di routing determina come il traffico internet raggiunge l'endpoint pubblico:

• 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 supporta 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.

Per i passaggi di configurazione, vedi Configura la preferenza di instradamento della rete.

Endpoint privati

Un endpoint privato fornisce un indirizzo IP privato nella tua rete virtuale per l'accesso a una condivisione file.

Ogni endpoint privato è associato a una subnet di rete virtuale. Più endpoint privati possono fornire accesso alla stessa condivisione file da diverse reti virtuali.

I client possono raggiungere un endpoint privato dalla sua rete virtuale, dalle reti virtuali peered o dalle reti on-premises connesse.

I endpoint privati e pubblici possono coesistere. Creare un endpoint privato non disabilita l'accesso pubblico né limita altri percorsi in uscita dai client.

Per creare un endpoint privato, vedere Configurazione di endpoint privati per File di Azure.

Connettività privata da on-premises

VPN ed ExpressRoute forniscono connettività tra client on-premises e endpoint privati in una rete virtuale Azure. Questo approccio vale sia per SMB che per NFS.

Le opzioni di connessione differiscono per ambito e trasporto:

VPN da punto a sito

Una VPN point-to-site collega un singolo client a una rete virtuale Azure. Supporta utenti e dispositivi remoti che non sono collegati tramite la rete del sito di un'organizzazione. Per protocolli supportati e guide di configurazione, vedi Informazioni sulla VPN punto-to-sito.

VPN da sito a sito

Una VPN site-to-site collega la rete di un'organizzazione a una rete virtuale Azure tramite un gateway VPN. I clienti sulla rete connessa condividono quella connessione. Per guide ad architettura e configurazione, vedi VPN Site-to-site.

ExpressRoute

Il peering privato ExpressRoute collega una rete on-premises a reti virtuali Azure senza attraversare internet pubblico. Fornisce un'opzione di connettività privata per carichi di lavoro con requisiti di prestazioni di rete o organizzativi. La crittografia a livello applicativo rimane una considerazione separata. Per le opzioni di connettività e le guide di configurazione, vedi panoramica di ExpressRoute.

Risoluzione DNS

Il DNS determina se il nome host di una condivisione file si risolve in un indirizzo IP pubblico o privato. I clienti usano lo stesso nome host per entrambi i percorsi. All'interno di una rete che utilizza DNS privato per la condivisione, il nome si risolve all'indirizzo IP dell'endpoint privato. I client che usano DNS pubblico lo risolvono invece verso l'endpoint pubblico.

Le condivisioni file classiche utilizzano il nome host del servizio file dell'account di archiviazione. Microsoft. FileShares assegna un nome host generato a ogni condivisione file. Quel nome generato è separato dal nome della risorsa della condivisione file.

In Azure public cloud, entrambi i provider di risorse utilizzano la zona privatelink.file.core.windows.netDNS privata . I client on-premises necessitano di accedere ai record DNS privati nonché a una route di rete verso l'endpoint privato. Una connessione VPN o ExpressRoute da sola non fornisce una risoluzione DNS privata. Il DNS forwarding o DNS di Azure Private Resolver possono fornire questa soluzione.

Per configurazione e verifica, vedi:

• Crea un endpoint privato con integrazione DNS e verifica la connettività, per entrambi i provider di risorse.
• Integrazione DNS Azure Private Endpoint, per progetti DNS on-premises.
• Configura l'inoltro DNS per le condivisioni file classiche, per esempi specifici di File di Azure.

SMB su QUIC

SMB su QUIC trasporta traffico SMB sulla porta UDP 443, offrendo un'alternativa quando la porta TCP 445 non è disponibile. Un file server compatibile di Windows Server fornisce l'endpoint QUIC e i client necessitano del supporto per SMB over QUIC.

Attualmente, File di Azure non supporta direttamente SMB su QUIC. Puoi accedere a una cache di Windows Server di una classica condivisione file SMB tramite Sincronizzazione file di Azure, come mostrato nel diagramma seguente. Questa opzione non si applica né a NFS né a Microsoft.FileShares. Puoi distribuire cache di Sincronizzazione file di Azure in sede o nei datacenter Azure. Per saperne di più, 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