Informazioni sui comportamenti di sicurezza e autorizzazione con doppio protocollo in Azure NetApp Files
SMB e NFS usano modelli di autorizzazione diversi per l'accesso a utenti e gruppi. Di conseguenza, un volume di Azure NetApp File deve essere configurato per rispettare il modello di autorizzazione desiderato per l'accesso al protocollo. Per gli ambienti solo NFS, la decisione è semplice: usare gli stili di sicurezza UNIX. Per gli ambienti solo SMB, usare gli stili di sicurezza NTFS.
Se sono necessari NFS e SMB sugli stessi set di dati (dual-protocol), la decisione deve essere presa in base a due domande:
- Quale protocollo gestirà al massimo le autorizzazioni degli utenti?
- Qual è l'endpoint di gestione delle autorizzazioni desiderato? In altre parole, gli utenti richiedono la possibilità di gestire le autorizzazioni da client NFS o client Windows? O entrambe?
Gli stili di sicurezza del volume possono essere effettivamente considerati stili di autorizzazione, in cui lo stile desiderato di gestione ACL è il fattore di scelta.
Nota
Gli stili di sicurezza vengono scelti durante la creazione del volume. Dopo aver scelto lo stile di sicurezza, non può essere modificato.
Informazioni sugli stili di sicurezza dei volumi di Azure NetApp Files
Esistono due opzioni principali per gli stili di sicurezza dei volumi in Azure NetApp Files:
UNIX : lo stile di sicurezza UNIX fornisce autorizzazioni di tipo UNIX, ad esempio bit in modalità POSIX di base (proprietario/gruppo/tutti gli accessi con autorizzazioni di lettura/scrittura/esecuzione standard, ad esempio 0755) e ACL NFSv4.x. Gli ACL POSIX non sono supportati.
NTFS: lo stile di sicurezza NTFS offre funzionalità identiche alle autorizzazioni NTFS standard di Windows, con utenti e gruppi granulari negli elenchi di controllo di accesso e autorizzazioni dettagliate di sicurezza/controllo.
In un ambiente NAS a doppio protocollo può essere attivo un solo stile di autorizzazione di sicurezza. È consigliabile valutare le considerazioni per ogni stile di sicurezza prima di sceglierne uno.
| Stile di sicurezza | Considerazioni |
|---|---|
| UNIX | - I client Windows possono impostare solo gli attributi di autorizzazione UNIX tramite SMB che eseguono il mapping agli attributi UNIX (sola lettura/scrittura/esecuzione; nessuna autorizzazione speciale). - Gli ACL NFSv4.x non dispongono della gestione dell'interfaccia utente grafica. La gestione viene eseguita solo tramite l'interfaccia della riga di comando usando i comandi nfs4_getfacl e nfs4_setfacl. - Se un file o una cartella dispone di ACL NFSv4.x, la scheda delle proprietà di sicurezza di Windows non può visualizzarle. |
| NTFS | - I client UNIX non possono impostare attributi tramite NFS tramite comandi come chown/chmod. - I client NFS mostrano solo autorizzazioni NTFS approssimative quando si usano ls comandi. Ad esempio, se un utente dispone di un'autorizzazione in un ACL NTFS di Windows che non può essere convertito in modo pulito in un bit in modalità POSIX (ad esempio attraversa la directory), viene convertito nel valore di bit della modalità POSIX più vicino (ad esempio 1 per l'esecuzione). |
La selezione dello stile di sicurezza del volume determina la modalità di esecuzione del mapping dei nomi per un utente. Questa operazione è la parte principale del modo in cui i volumi a doppio protocollo mantengono le autorizzazioni prevedibili indipendentemente dal protocollo in uso.
Usare la tabella seguente come matrice decisionale per selezionare gli stili di sicurezza del volume appropriati.
| Stile di sicurezza | Principalmente NFS | Principalmente SMB | Necessità di una sicurezza granulare |
|---|---|---|---|
| UNIX | X | - | X (uso di ACL NFSv4.x) |
| NTFS | - | X | X |
Funzionamento del mapping dei nomi in Azure NetApp Files
In Azure NetApp Files solo gli utenti vengono autenticati e mappati. I gruppi non vengono mappati. Le appartenenze ai gruppi vengono invece determinate usando l'identità utente.
Quando un utente tenta di accedere a un volume di Azure NetApp Files, questo tentativo passa un'identità al servizio. Tale identità include un nome utente e un identificatore numerico univoco (numero UID per NFSv3, stringa di nome per NFSv4.1, SID per SMB). Azure NetApp Files usa tale identità per eseguire l'autenticazione con un servizio dei nomi configurato per verificare l'identità dell'utente.
- La ricerca LDAP per gli ID numerici viene usata per cercare un nome utente in Active Directory.
- Le stringhe dei nomi usano la ricerca LDAP per cercare un nome utente e il client e il server consultano il dominio ID configurato per NFSv4.1 per garantire la corrispondenza.
- Gli utenti di Windows vengono sottoposti a query usando chiamate RPC di Windows standard ad Active Directory.
- Vengono inoltre eseguite query sulle appartenenze ai gruppi e tutto viene aggiunto a una cache delle credenziali per un'elaborazione più rapida nelle richieste successive al volume.
- Attualmente, gli utenti locali personalizzati non sono supportati per l'uso con Azure NetApp Files. Solo gli utenti in Active Directory possono essere usati con protocolli duali.
- Attualmente, gli unici utenti locali che possono essere usati con volumi a doppio protocollo sono radice e l'utente
nfsnobody.
Dopo che un nome utente viene autenticato e convalidato da Azure NetApp Files, il passaggio successivo per l'autenticazione del volume a doppio protocollo è il mapping dei nomi utente per l'interoperabilità UNIX e Windows.
Lo stile di sicurezza di un volume determina il modo in cui viene eseguito un mapping dei nomi in Azure NetApp Files. La semantica delle autorizzazioni windows e UNIX è diversa. Se non è possibile eseguire un mapping dei nomi, l'autenticazione non riesce e l'accesso a un volume da un client viene negato. Uno scenario comune in cui si verifica questa situazione è il tentativo di accesso NFSv3 a un volume con stile di sicurezza NTFS. La richiesta di accesso iniziale da NFSv3 viene fornita ad Azure NetApp Files come UID numerico. Se un utente denominato user1 con ID numerico tenta di 1001 accedere al montaggio NFSv3, la richiesta di autenticazione arriva come ID 1001numerico. Azure NetApp Files accetta quindi l'ID 1001 numerico e tenta di risolvere 1001 un nome utente. Questo nome utente è necessario per eseguire il mapping a un utente di Windows valido, perché le autorizzazioni NTFS per il volume conterranno i nomi utente di Windows anziché un ID numerico. Azure NetApp Files userà il server del servizio dei nomi configurato (LDAP) per cercare il nome utente. Se non è possibile trovare il nome utente, l'autenticazione non riesce e l'accesso viene negato. Questa operazione è progettata per impedire l'accesso indesiderato a file e cartelle.
Mapping dei nomi basato sullo stile di sicurezza
La direzione in cui si verifica il mapping dei nomi in Azure NetApp Files (da Windows a UNIX o UNIX a Windows) dipende non solo dal protocollo in uso, ma anche dallo stile di sicurezza di un volume. Un client Windows richiede sempre un mapping dei nomi da Windows a UNIX per consentire l'accesso, ma non ha sempre bisogno di un nome utente UNIX corrispondente. Se non esiste alcun nome utente UNIX valido nel server del servizio nomi configurato, Azure NetApp Files fornisce un utente UNIX predefinito di fallback con l'UID numerico di 65534 per consentire l'autenticazione iniziale per le connessioni SMB. Successivamente, le autorizzazioni per file e cartelle controllano l'accesso. Poiché 65534 in genere corrisponde all'utente, l'accesso nfsnobody è limitato nella maggior parte dei casi. Al contrario, un client NFS deve usare solo un mapping dei nomi DA UNIX a Windows se lo stile di sicurezza NTFS è in uso. Non esiste un utente Windows predefinito in Azure NetApp Files. Di conseguenza, se non è possibile trovare un utente di Windows valido che corrisponde al nome richiedente, l'accesso verrà negato.
La tabella seguente suddivide i diversi mapping dei nomi permutazioni e il comportamento in base al protocollo in uso.
| Protocollo | Stile di sicurezza | Direzione mapping dei nomi | Autorizzazioni applicate |
|---|---|---|---|
| SMB | UNIX | Da Windows a UNIX | UNIX (ACL mode-bit o NFSv4.x) |
| SMB | NTFS | Da Windows a UNIX | ACL NTFS (in base al SID di Windows che accede alla condivisione) |
| NFSv3 | UNIX | None | UNIX (ACL mode-bit o NFSv4.x) |
| NFSv4.x | UNIX | ID numerico per il nome utente UNIX | UNIX (ACL mode-bit o NFSv4.x) |
| NFS3/4.x | NTFS | Da UNIX a Windows | ACL NTFS (in base al SID utente di Windows mappato) |
Nota
Le regole di mapping dei nomi in Azure NetApp Files possono attualmente essere controllate solo tramite LDAP. Non è possibile creare regole esplicite per il mapping dei nomi all'interno del servizio.
Servizi dei nomi con volumi a doppio protocollo
Indipendentemente dal protocollo NAS usato, i volumi a doppio protocollo usano concetti di mapping dei nomi per gestire correttamente le autorizzazioni. Di conseguenza, i servizi dei nomi svolgono un ruolo fondamentale nella gestione delle funzionalità negli ambienti che usano sia SMB che NFS per l'accesso ai volumi.
I servizi dei nomi fungono da origini di identità per utenti e gruppi che accedono ai volumi NAS. Questa operazione include Active Directory, che può fungere da origine per utenti e gruppi Windows e UNIX usando sia i servizi di dominio standard che la funzionalità LDAP.
I servizi dei nomi non sono un requisito rigido, ma sono altamente consigliati per i volumi a doppio protocollo di Azure NetApp Files. Non esiste alcun concetto di creazione di utenti e gruppi locali personalizzati all'interno del servizio. Di conseguenza, per avere un'autenticazione corretta e informazioni accurate sul proprietario di utenti e gruppi tra protocolli, LDAP è una necessità. Se si hanno solo pochi utenti e non è necessario popolare informazioni accurate sull'identità di utenti e gruppi, prendere in considerazione l'uso di Consenti agli utenti NFS locali con LDAP di accedere a una funzionalità del volume a doppio protocollo. Tenere presente che l'abilitazione di questa funzionalità disabilita la funzionalità del gruppo esteso.
Quando i client, i servizi dei nomi e l'archiviazione si trovano in aree diverse
In alcuni casi, i client NAS potrebbero vivere in una rete segmentata con più interfacce con connessioni isolate ai servizi di archiviazione e nome.
Un esempio è se l'archiviazione risiede in Azure NetApp Files, mentre i client NAS e i servizi di dominio risiedono tutti in locale , ad esempio un'architettura hub-spoke in Azure. In questi scenari, è necessario fornire l'accesso di rete sia ai client NAS che ai servizi dei nomi.
La figura seguente mostra un esempio di questo tipo di configurazione.
