Informazioni sulla crittografia dei dati in Azure NetApp Files

Articolo
02/23/2024

Azure NetApp Files crittografa i dati tramite due metodi diversi:

Crittografia dei dati inattivi: i dati vengono crittografati sul posto usando standard conformi a FIPS 140-2.
Crittografia in transito: i dati vengono crittografati in transito o in transito mentre vengono trasferiti tra client e server.

Informazioni sulla crittografia dei dati inattivi

I dati inattivi in Azure NetApp Files possono essere crittografati in due modi:

La crittografia singola usa la crittografia basata su software per i volumi di Azure NetApp Files.
La doppia crittografia aggiunge la crittografia a livello di hardware a livello di dispositivo di archiviazione fisica.

Azure NetApp Files usa CryptoMod standard per generare chiavi di crittografia AES-256. CryptoMod è elencato nell'elenco dei moduli convalidati FIPS 140-2 CMVP. Per altre informazioni, vedere FIPS 140-2 Cert #4144. Le chiavi di crittografia sono associate ai volumi e possono essere chiavi gestite dalla piattaforma Microsoft o chiavi gestite dal cliente.

Informazioni sulla crittografia dei dati in transito

Oltre a proteggere i dati inattivi, Azure NetApp Files può proteggere i dati quando è in transito tra endpoint. Il metodo di crittografia usato dipende dal protocollo o dalla funzionalità. IL DNS non è crittografato in transito in Azure NetApp Files. Continuare a leggere per informazioni sulla crittografia SMB e NFS, LDAP e sulla replica dei dati in Azure NetApp Files.

Crittografia SMB

I client SMB Windows che usano la versione del protocollo SMB3.x supportano in modo nativo la crittografia SMB. La crittografia SMB viene eseguita end-to-end e crittografa l'intera conversazione SMB usando suite di crittografia AES-256-GCM/AES-128-GCM e AES-256-CCM/AES-128-CCM.

La crittografia SMB non è necessaria per i volumi di Azure NetApp Files, ma può essere usata per una maggiore sicurezza. La crittografia SMB comporta un sovraccarico delle prestazioni. Per altre informazioni sulle considerazioni sulle prestazioni con la crittografia SMB, vedere Procedure consigliate per le prestazioni SMB per Azure NetApp Files.

Richiesta di crittografia per le connessioni SMB

Azure NetApp Files offre un'opzione per applicare la crittografia a tutte le connessioni SMB. L'applicazione della crittografia non consente la comunicazione SMB non crittografata e usa SMB3 e versioni successive per le connessioni SMB. La crittografia viene eseguita usando la crittografia AES e crittografa tutti i pacchetti SMB. Per il corretto funzionamento di questa funzionalità, i client SMB devono supportare la crittografia SMB. Se il client SMB non supporta la crittografia e SMB3, le connessioni SMB non sono consentite. Se questa opzione è abilitata, tutte le condivisioni con lo stesso indirizzo IP richiedono la crittografia, ignorando quindi l'impostazione della proprietà di condivisione SMB per la crittografia.

In alternativa, la crittografia può essere impostata a livello di singola condivisione di un volume di Azure NetApp Files.

Protezione avanzata UNC

Nel 2015 Microsoft ha introdotto la protezione avanzata UNC (MS15-011 e MS15-014) per risolvere le vulnerabilità del percorso di rete remoto che potrebbero consentire l'esecuzione remota del codice tra condivisioni SMB. Per altre informazioni, vedere MS15-011 & MS15-014: Criteri di gruppo di protezione avanzata.

La protezione avanzata UNC offre tre opzioni per la protezione dei percorsi UNC:

RequireMutualAuthentication : autenticazione di identità obbligatoria/non necessaria per bloccare gli attacchi di spoofing.
RequireIntegrity : controllo dell'integrità obbligatorio/non necessario per bloccare gli attacchi di manomissione.
RequirePrivacy – Privacy (crittografia totale dei pacchetti SMB) abilitata/disabilitata per impedire l'analisi del traffico.

Azure NetApp Files supporta tutte e tre le forme di protezione avanzata UNC.

NFS Kerberos

Azure NetApp Files offre anche la possibilità di crittografare le conversazioni NFSv4.1 tramite l'autenticazione Kerberos usando suite di crittografia AES-256-GCM/AES-128-GCM e AES-256-CCM/AES-128-CCM.

Con Kerberos NFS, Azure NetApp Files supporta tre diversi tipi di sicurezza:

Kerberos 5 (krb5): solo autenticazione iniziale. Richiede un accesso kerberos per lo scambio di ticket/l'utente per accedere all'esportazione NFS. I pacchetti NFS non sono crittografati.
Kerberos 5i (krb5i): verifica iniziale dell'autenticazione e dell'integrità. Richiede un accesso Kerberos per lo scambio di ticket/l'utente per accedere all'esportazione NFS e aggiunge controlli di integrità a ogni pacchetto NFS per impedire attacchi MAN-in-the-middle (MITM).
Kerberos 5p (krb5p): autenticazione iniziale, controllo dell'integrità e privacy. Richiede l'accesso di uno scambio di ticket/utente Kerberos per accedere all'esportazione NFS, esegue controlli di integrità e applica un wrapper GSS a ogni pacchetto NFS per crittografarne il contenuto.

Ogni livello di crittografia Kerberos ha un effetto sulle prestazioni. Man mano che i tipi di crittografia e i tipi di sicurezza incorporano metodi più sicuri, l'effetto sulle prestazioni aumenta. Ad esempio, krb5 offre prestazioni migliori rispetto krb5ia , krb5i offre prestazioni migliori rispetto krb5pa , AES-128 prestazioni migliori rispetto a AES-256 e così via. Per altre informazioni sull'effetto delle prestazioni di Kerberos NFS in Azure NetApp Files, vedere Impatto sulle prestazioni di Kerberos nei volumi NFSv4.1 di Azure NetApp Files.

Nota

Kerberos NFS è supportato solo con NFSv4.1 in Azure NetApp Files.

Nell'immagine seguente viene usato Kerberos 5 (krb5). Viene crittografata solo la richiesta di autenticazione iniziale (acquisizione del ticket di accesso). Tutto l'altro traffico NFS arriva in testo normale.

Quando si usa Kerberos 5i (krb5i; controllo dell'integrità), una traccia mostra che i pacchetti NFS non sono crittografati, ma è presente un wrapper GSS/Kerberos aggiunto al pacchetto che richiede il client e il server garantiscono l'integrità dei dati trasferiti usando un checksum.

Kerberos 5p (privacy; krb5p) fornisce la crittografia end-to-end di tutto il traffico NFS, come illustrato nell'immagine di traccia usando un wrapper GSS/Kerberos. Questo metodo crea il sovraccarico delle prestazioni maggiore a causa della necessità di elaborare la crittografia di ogni pacchetto NFS.

Replica dei dati

In Azure NetApp Files è possibile replicare interi volumi tra zone o aree in Azure per garantire la protezione dei dati. Poiché il traffico di replica risiede nel cloud di Azure, i trasferimenti avvengono nell'infrastruttura di rete di Azure sicura, che è limitata nell'accesso per impedire l'analisi dei pacchetti e gli attacchi man-in-the-middle (intercettazione o rappresentazione tra endpoint di comunicazione). Inoltre, il traffico di replica viene crittografato usando gli standard TLS 1.2 conformi a FIPS 140-2. Per informazioni dettagliate, vedere Domande frequenti sulla sicurezza.

Crittografia LDAP

In genere, la ricerca LDAP e l'associazione del traffico passano attraverso la rete in testo normale, ovvero chiunque abbia accesso ai pacchetti di rete sniff può ottenere informazioni dal server LDAP, ad esempio nomi utente, ID numerici, appartenenze ai gruppi e così via. Queste informazioni possono quindi essere usate per spoofare gli utenti, inviare messaggi di posta elettronica per attacchi di phishing e così via.

Per proteggere le comunicazioni LDAP dall'intercettazione e dalla lettura, il traffico LDAP può sfruttare rispettivamente la crittografia over-the-wire sfruttando AES e TLS 1.2 tramite la firma LDAP e LDAP su TLS. Per informazioni dettagliate sulla configurazione di queste opzioni, vedere Creare e gestire le connessioni di Active Directory.

Accesso LDAP

La firma LDAP è specifica per le connessioni nei server Microsoft Active Directory che ospitano identità UNIX per utenti e gruppi. Questa funzionalità abilita la verifica dell'integrità per le associazioni LDAP SASL (Simple Authentication and Security Layer) ai server AD che ospitano connessioni LDAP. La firma non richiede la configurazione dei certificati di sicurezza perché usa la comunicazione dell'API GSS con i servizi Kerberos Key Distribution Center (KDC) di Active Directory. La firma LDAP controlla solo l'integrità di un pacchetto LDAP; non crittografa il payload del pacchetto.

La firma LDAP può essere configurata anche dal lato server Windows tramite Criteri di gruppo per essere opportunistica con la firma LDAP (nessuna: supporto se richiesto dal client) o per applicare la firma LDAP (richiesta). La firma LDAP può aggiungere un sovraccarico delle prestazioni al traffico LDAP che in genere non è evidente per gli utenti finali.

Windows Active Directory consente anche di usare la firma LDAP e la chiusura (crittografia end-to-end dei pacchetti LDAP). Azure NetApp Files non supporta questa funzionalità.

Associazione di canali LDAP

A causa di una vulnerabilità di sicurezza individuata nei controller di dominio di Windows Active Directory, è stata modificata un'impostazione predefinita per i server Windows. Per informazioni dettagliate, vedere Microsoft Security Advisory ADV190023.For details, see Microsoft Security Advisory ADV190023.

In pratica, Microsoft consiglia agli amministratori di abilitare la firma LDAP insieme all'associazione di canali. Se il client LDAP supporta token di associazione del canale e firma LDAP, sono necessarie l'associazione e la firma del canale e le opzioni del Registro di sistema vengono impostate dalla nuova patch Microsoft.

Azure NetApp Files, per impostazione predefinita, supporta l'associazione di canali LDAP in modo opportunistico, ovvero l'associazione di canali LDAP viene usata quando il client lo supporta. Se non supporta/invia l'associazione di canali, la comunicazione è ancora consentita e l'associazione di canale non viene applicata.

LDAP su SSL (porta 636)

Il traffico LDAP in Azure NetApp Files passa sulla porta 389 in tutti i casi. Impossibile modificare questa porta. LDAP su SSL (LD piattaforma di strumenti analitici) non è supportato ed è considerato legacy dalla maggior parte dei fornitori di server LDAP (RFC 1777 è stato pubblicato nel 1995). Se si vuole usare la crittografia LDAP con Azure NetApp Files, usare LDAP su TLS.

LDAP over StartTLS

LDAP over StartTLS è stato introdotto con RFC 2830 nel 2000 ed è stato combinato nello standard LDAPv3 con RFC 4511 nel 2006. Dopo che StartTLS è stato reso standard, i fornitori LDAP iniziarono a fare riferimento a LD piattaforma di strumenti analitici come deprecato.

LDAP su StartTLS usa la porta 389 per la connessione LDAP. Dopo aver effettuato la connessione LDAP iniziale, viene scambiato un OID StartTLS e vengono confrontati i certificati; quindi tutto il traffico LDAP viene crittografato tramite TLS. L'acquisizione di pacchetti mostra l'associazione LDAP, l'handshake StartTLS e il traffico LDAP crittografato TLS successivo.

Esistono due differenze principali tra LD piattaforma di strumenti analitici e StartTLS:

StartTLS fa parte dello standard LDAP; LD piattaforma di strumenti analitici no. Di conseguenza, il supporto della libreria LDAP nei server o nei client LDAP può variare e la funzionalità potrebbe o meno funzionare in tutti i casi.
Se la crittografia non riesce, StartTLS consente alla configurazione di eseguire il fallback a LDAP normale. LD piattaforma di strumenti analitici non lo fa. Di conseguenza, StartTLS offre flessibilità e resilienza, ma presenta anche rischi per la sicurezza se non è configurato correttamente.

Considerazioni sulla sicurezza con LDAP over StartTLS

StartTLS consente agli amministratori di eseguire il fallback al normale traffico LDAP, se necessario. Per motivi di sicurezza, la maggior parte degli amministratori LDAP non lo consente. I consigli seguenti per StartTLS consentono di proteggere la comunicazione LDAP:

Assicurarsi che StartTLS sia abilitato e che i certificati siano configurati.
Per gli ambienti interni, è possibile usare certificati autofirmato, ma per LDAP esterno, usare un'autorità di certificazione. Per altre informazioni sui certificati, vedere differenza tra ssl autofirmato e autorità di certificazione.
Impedire query LDAP e associazioni che non usano StartTLS. Per impostazione predefinita, Active Directory disabilita le associazioni anonime.

Connessione di sicurezza di Active Directory

Le connessioni Di Active Directory con i volumi di Azure NetApp Files possono essere configurate per provare prima il tipo di crittografia Kerberos più sicuro disponibile: AES-256. Quando la crittografia AES è abilitata, le comunicazioni del controller di dominio (ad esempio le reimpostazioni pianificate della password del server SMB) usano il tipo di crittografia più alto disponibile supportato nei controller di dominio. Azure NetApp Files supporta i tipi di crittografia seguenti per le comunicazioni del controller di dominio, in ordine di tentativo di autenticazione: AES-256, AES-128, RC4-HMAC, DES

Nota

Non è possibile disabilitare i tipi di autenticazione più deboli in Azure NetApp Files (ad esempio RC4-HMAC e DES). Se necessario, questi devono invece essere disabilitati dal controller di dominio in modo che le richieste di autenticazione non tentino di usarle. Se RC4-HMAC è disabilitato nei controller di dominio, la crittografia AES deve essere abilitata in Azure NetApp Files per una funzionalità appropriata.

Condividi tramite

Informazioni sulla crittografia dei dati in Azure NetApp Files

Informazioni sulla crittografia dei dati inattivi