La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Sincronizza i dati NFS utilizzando la crittografia dei dati in-flight

08/12/2024 Collaboratori

PDF

Se la tua azienda ha policy di sicurezza rigorose, puoi sincronizzare i dati NFS utilizzando la crittografia data-in-flight. Questa funzionalità è supportata da un server NFS a un altro server NFS e da Azure NetApp Files a Azure NetApp Files.

Ad esempio, è possibile sincronizzare i dati tra due server NFS che si trovano in reti diverse. In alternativa, potrebbe essere necessario trasferire in modo sicuro i dati su Azure NetApp Files tra sottoreti o regioni.

Come funziona la crittografia dei dati in volo

La crittografia Data-in-flight crittografa i dati NFS quando vengono inviati in rete tra due broker di dati. La seguente immagine mostra una relazione tra due server NFS e due broker di dati:

Diagramma che mostra due server NFS e due broker di dati. I dati vengono trasmessi dal server NFS di origine a un broker di dati di origine, in cui i dati vengono crittografati. I dati vengono quindi inviati al data broker di destinazione e quindi al server NFS di destinazione.

Un data broker funziona come initiator. Quando è il momento di sincronizzare i dati, invia una richiesta di connessione all'altro data broker, che è il listener. Il data broker ascolta le richieste sulla porta 443. Se necessario, è possibile utilizzare un'altra porta, ma assicurarsi che la porta non sia utilizzata da un altro servizio.

Ad esempio, se si sincronizzano i dati da un server NFS on-premise a un server NFS basato sul cloud, è possibile scegliere quale broker di dati ascoltare le richieste di connessione e quale inviarle.

Ecco come funziona la crittografia in-flight:

Dopo aver creato la relazione di sincronizzazione, l'iniziatore avvia una connessione crittografata con l'altro data broker.
Il broker dei dati di origine crittografa i dati dall'origine utilizzando TLS 1.3.
Quindi, invia i dati in rete al data broker di destinazione.
Il broker di dati di destinazione decrta i dati prima di inviarli alla destinazione.
Dopo la copia iniziale, il servizio sincronizza tutti i dati modificati ogni 24 ore. Se sono presenti dati da sincronizzare, il processo inizia con l'iniziatore che apre una connessione crittografata con l'altro data broker.

Se si preferisce sincronizzare i dati con maggiore frequenza, "è possibile modificare la pianificazione dopo aver creato la relazione".

Versioni NFS supportate

Per i server NFS, la crittografia data-in-flight è supportata con le versioni NFS 3, 4.0, 4.1 e 4.2.
Per Azure NetApp Files, la crittografia data-in-flight è supportata con NFS versioni 3 e 4.1.

Limitazione del server proxy

Se si crea una relazione di sincronizzazione crittografata, i dati crittografati vengono inviati tramite HTTPS e non possono essere instradati attraverso un server proxy.

Cosa ti serve per iniziare

Assicurarsi di disporre di quanto segue:

Due server NFS che si incontrano "requisiti di origine e destinazione" O Azure NetApp Files in due sottoreti o regioni.
Gli indirizzi IP o i nomi di dominio completi dei server.
Posizioni di rete per due broker di dati.

È possibile selezionare un data broker esistente, ma deve funzionare come iniziatore. Il data broker listener deve essere un new data broker.

Se si desidera utilizzare un gruppo di broker di dati esistente, il gruppo deve disporre di un solo broker di dati. I broker di dati multipli in un gruppo non sono supportati con relazioni di sincronizzazione crittografate.

Se non hai ancora implementato un data broker, esamina i requisiti del data broker. Poiché si dispone di policy di sicurezza rigorose, assicurarsi di esaminare i requisiti di rete, che includono il traffico in uscita dalla porta 443 e da "endpoint internet" che il data broker contatta.