Configura la crittografia in transito per File di Azure

Questo articolo spiega come richiedere e utilizzare la crittografia durante il trasporto per File di Azure. Ogni protocollo ha il proprio meccanismo di crittografia e le proprie impostazioni:

• SMB: crittografia del canale SMB 3.x. Vedi SMB.
• NFS: crittografia TLS tramite l'helper di montaggio AzNFS. Vedi NFS.
• FileREST: HTTPS con TLS. Vedi FileREST.

Per una panoramica della crittografia in transito per ciascun protocollo, vedi File di Azure networking considerations. Per le condivisioni file Microsoft.FileShares, si imposta il requisito di crittografia in transito per ogni condivisione file. Vedi Crea una condivisione file e Modifica una condivisione file. Microsoft.FileShares non supporta FileREST.

Impostazioni della crittografia dei dati in transito

Le condivisioni file classiche hanno un'impostazione separata di crittografia in transito per ogni protocollo. Il trasferimento sicuro richiesto era l'impostazione originale per tutti e tre i protocolli. Per compatibilità retroattiva, controlla comunque la crittografia SMB e NFS finché non configuri l'impostazione per quel protocollo.

Le impostazioni SMB e NFS iniziano come Non selezionate per:

• Account di archiviazione esistenti.
• Account di storage creati utilizzando Azure PowerShell, interfaccia della riga di comando di Azure o l'API REST del provider di risorse Archiviazione di Azure.

Per gli account di archiviazione creati utilizzando il portale Azure, entrambe le impostazioni sono abilitate di default.

Dopo aver configurato l'impostazione SMB o NFS, essa ha la precedenza sul trasferimento sicuro richiesto per quel protocollo. Puoi cambiare l'impostazione tra Abilitato e Disabilitato, ma non puoi reimpostarla su Non selezionato.

SMB

File di Azure cifra il traffico SMB utilizzando la crittografia del canale SMB 3.x. L'impostazione Richiedere la crittografia in Transit per SMB determina se File di Azure richiede la crittografia per l'accesso SMB alle condivisioni file in un account di storage. Quando questa impostazione è abilitata, File di Azure consente solo montaggi SMB 3.x che utilizzano la crittografia del canale. File di Azure rifiuta i montaggi dai client che non supportano SMB 3.x con crittografia dei canali. SMB 2.1 non supporta la crittografia, quindi File di Azure rifiuta tutti i montaggi SMB 2.1. Per il valore predefinito e come funziona questa impostazione con Trasferimento sicuro obbligatorio, vedi Impostazioni della crittografia in transito.

Per gli algoritmi di crittografia dei canali SMB supportati e le altre impostazioni di sicurezza SMB, vedi impostazioni di sicurezza SMB.

$params = @{
    ResourceGroupName = "<resource-group>"
    StorageAccountName = "<storage-account-name>"
    SmbEncryptionInTransitRequired = $true
}
Update-AzStorageFileServiceProperty @params

az storage account file-service-properties update \
    --resource-group <resource-group> \
    --account-name <storage-account-name> \
    --require-smb-encryption-in-transit true

NFS

Le condivisioni file NFSv4.1 di File di Azure supportano la crittografia durante il transito attraverso un tunnel TLS. TLS protegge i dati in transito dall'intercettazione, inclusi gli attacchi man-in-the-middle. Per installare l'helper di montaggio AzNFS e montare una condivisione file con crittografia in transito, vedi Montare condivisioni file NFS di Azure in Linux.

Come funziona la crittografia durante il transito

File di Azure utilizza stunnel, un wrapper TLS open-source, per criptare la connessione TCP tra il client NFS e File di Azure. Con l'helper di montaggio AzNFS, la connessione utilizza TLS 1.2 o TLS 1.3 con crittografia AES-256-GCM. Non serve Kerberos né un sistema di autenticazione esterno come Active Directory.

Il pacchetto helper di montaggio AzNFS installa e configura lo stunnel sul client. AzNFS è disponibile da packages.microsoft.com. Crea un endpoint locale che inoltra le richieste del client NFS tramite una connessione criptata. AzNFS ha questi componenti:

• helper di montaggio AzNFS: Monta le condivisioni file NFSv4.1 tramite un tunnel TLS.

• Processo Stunnel: Un processo per ogni account di storage. Ascolta il traffico client NFS su una porta locale e inoltra il traffico tramite TLS ad File di Azure.

• AzNFS watchdog: Un servizio in background che mantiene in esecuzione i processi stunnel, riavvia i tunnel terminati e rimuove i processi inutilizzati dopo che tutti i mount NFS associati sono stati smontati.

Applicare la crittografia durante il transito

L'impostazione Richiedere la crittografia in Transit per NFS determina se File di Azure richiede la crittografia per l'accesso NFS alle condivisioni file in un account di archiviazione. Per permettere sia montature TLS che non TLS sullo stesso account di storage, disabilita questa impostazione. Per il valore predefinito e per il funzionamento di questa impostazione con Secure transfer required, vedere Impostazioni di crittografia durante il transito.

$params = @{
    ResourceGroupName = "<resource-group>"
    StorageAccountName = "<storage-account-name>"
    NfsEncryptionInTransitRequired = $true
}
Update-AzStorageFileServiceProperty @params

az storage account file-service-properties update \
    --resource-group <resource-group> \
    --account-name <storage-account-name> \
    --require-nfs-encryption-in-transit true

FileREST

Le richieste FileREST utilizzano HTTPS per criptare i dati in transito. Due impostazioni di account di archiviazione controllano la crittografia FileREST per le condivisioni file classiche:

• Trasferimento sicuro richiesto: Quando questa impostazione è abilitata, l'account di archiviazione rifiuta le richieste FileREST effettuate tramite HTTP. I nuovi account di archiviazione hanno questa impostazione attivata di default. Tienilo attivato. L'opzione per disabilitarlo esiste per compatibilità retroattiva con applicazioni più vecchie che usano HTTP per accedere ad altri dati nell'account di archiviazione. Prima dell'esistenza delle impostazioni SMB e NFS, disabilitare Trasferimento sicuro obbligatorio era anche l'unico modo per consentire l'accesso SMB o NFS non crittografato. Per consentire ora l'accesso SMB o NFS non criptato, disabilita invece l'impostazione per il protocollo interessato. Vedi Impostazioni della crittografia in transito.
• Versione minima TLS: File di Azure accetta TLS 1.2 e TLS 1.3 per HTTPS. Archiviazione di Azure non accetta più TLS 1.0 o TLS 1.1 per le richieste HTTPS, quindi TLS 1.2 è la versione minima più bassa che puoi impostare. Non puoi impostare TLS 1.3 come minimo. Una richiesta FileREST che utilizza una versione TLS precedente rispetto al minimo non riesce e restituisce il codice di stato HTTP 400 (Bad Request). I clienti negoziano TLS 1.3 quando lo supportano.

Criteri di Azure ha definizioni di policy integrate che controllano o richiedono queste impostazioni per gli account di archiviazione. Consulta la sezione Storage nelle definizioni di policy integrate di Criteri di Azure.

Le versioni attuali delle librerie client di Archiviazione di Azure, Azure PowerShell e interfaccia della riga di comando di Azure utilizzano TLS 1.2 o successiva. Se un'applicazione che prende di mira una versione più vecchia di .NET Framework non riesce a connettersi, consulta le migliori pratiche di Transport Layer Security (TLS) con .NET Framework.

Configura le impostazioni di crittografia FileREST

I passaggi seguenti richiedono di abilitare il trasferimento sicuro e di impostare la versione minima di TLS su TLS 1.2 per un account di archiviazione.

$params = @{
    ResourceGroupName = "<resource-group>"
    Name = "<storage-account-name>"
    EnableHttpsTrafficOnly = $true
    MinimumTlsVersion = "TLS1_2"
}
Set-AzStorageAccount @params

az storage account update \
    --resource-group <resource-group> \
    --name <storage-account-name> \
    --https-only true \
    --min-tls-version TLS1_2

Contenuti correlati

• Considerazioni sulla rete di File di Azure
• Crittografia di Archiviazione di Azure per dati a riposo