Architettura
Suggerisci modifiche
PDF
NFS over TLS è una funzionalità di sicurezza del trasporto per LIF del server NFS ONTAP. Applica la protezione TLS al traffico NFS tra il client e il server NFS ONTAP. La configurazione viene gestita tramite la famiglia di comandi vserver nfs tls interface e la corrispondente risorsa REST /api/protocols/nfs/tls/interfaces.
La configurazione ha ambito SVM, viene applicata per LIF e replicata a livello di cluster. Qualsiasi nodo che ospita attualmente il LIF applica le stesse impostazioni TLS. Non esiste un'opzione di attivazione/disattivazione a livello di cluster. L'abilitazione e la disabilitazione sono operazioni per singolo LIF.
Dipendenze esterne
Nella versione 9.19.1, dal percorso di stretta di mano TLS NFS non vengono effettuate chiamate outbound verso un'Autorità di Certificazione (CA) esterna o un responder OCSP. La convalida della chain e del Subject Alternative Name (SAN) viene eseguita localmente rispetto al materiale del certificato installato sull'SVM.
Flusso di dati
Sia NFSv3 che NFSv4 crittografano l'intero payload NFS dopo la prima coppia di chiamata/risposta NULL sulla porta TCP 2049. La chiamata NULL ha il nuovo AUTH_TLS credential flavor definito nella RFC 9289 che segnala l'intenzione del client di usare TLS. Il server risponde con una risposta NULL che accetta o rifiuta l'upgrade TLS. Se il client riceve l'accettazione, procede con la stretta di mano TLS 1.3 sulla stessa connessione TCP. Se la stretta di mano si completa con successo, tutte le successive RPC NFS vengono incapsulate in record TLS e crittografate durante la trasmissione.
Esiste una differenza tra NFSv3 e NFSv4.x: NFSv3 si basa su protocolli ausiliari -rpcbind (portmapper), mountd, NLM (Network Lock Manager) e NSM (Network Status Monitor) che non vengono trasmessi sulla connessione protetta da TLS e sono inviati in chiaro. Le organizzazioni con requisiti di conformità che impongono la crittografia completa del traffico di archiviazione dovrebbero tenerne conto quando scelgono tra NFSv3 e NFSv4.x. NFSv4.x elimina questi protocolli side-channel; tutto il traffico NFSv4.x viene consolidato sulla porta 2049 e crittografato dopo la stretta di mano TLS.
NFSv4.x non utilizza protocolli ausiliari, quindi tutte le chiamate RPC NFSv4.x vengono crittografate dopo la stretta di mano TLS.
ONTAP termina la connessione TLS sul server NFS sul nodo che attualmente ospita il LIF. Al di sopra del livello di trasporto, il server NFS elabora le chiamate RPC in modo identico a una connessione NFS non TLS.
Comportamento di takeover HA
Le sessioni NFS-over-TLS esistenti non sopravvivono a un takeover HA o a un arresto anomalo imprevisto di un nodo. TLS è un trasporto a livello di sessione basato su TCP. Quando le connessioni TCP cadono con il nodo, anche le sessioni TLS cadono con esse.
Dopo takeover, i client si riconnettono e completano una nuova stretta di mano TLS 1.3. Il nodo partner utilizza la stessa configurazione TLS replicata—associazione del certificato, impostazione di autenticazione host e impostazione di convalida SAN—perché il record di configurazione è replicato a livello di cluster.
I ticket di sessione TLS e le chiavi precondivise (PSK) sono locali al nodo e non vengono trasferiti al partner. Aspettati un'ondata di riconnessioni con strette di mano TLS complete durante il takeover.
MetroCluster e comportamento SVM-DR
Il certificato e la configurazione dell'interfaccia TLS vengono replicati con la SVM tramite il percorso di replica standard SVM-DR e a livello di SVM MetroCluster. Dopo uno switchover con conservazione dell'identità, la SVM di destinazione mantiene la stessa configurazione TLS per-LIF.
Il -allow-nfs-tls-only campo nella regola export-policy viene replicato insieme al resto della regola export-policy attraverso il percorso di replica standard export-policy. In SVM-DR, la regola viene replicata insieme alla policy quando la policy viene replicata con la SVM.