Questa pagina fornisce una panoramica delle considerazioni sulla sicurezza per Google Cloud NetApp Volumes. Queste considerazioni includono la protezione della rete, il controllo dell'accesso e la crittografia dei dati.
Considerazioni sulla sicurezza per il networking
Google Cloud NetApp Volumes fornisce un framework architetturale protetto con i seguenti livelli di sicurezza isolati:
Sicurezza a livello di progetto: il livello di sicurezza amministrativa che gli amministratori utilizzano per gestire le risorse NetApp Volumes come i pool di archiviazione o i volumi utilizzando la console Google Cloud , Google Cloud SDK o le API. Questo livello è protetto da ruoli e autorizzazioni IAM. Per saperne di più sulla sicurezza a livello di progetto, consulta Configurare le autorizzazioni IAM.
Sicurezza a livello di rete: il livello di rete utilizzato per accedere ai volumi di dati con i protocolli di Network Attached Storage (NAS) (Server Message Block (SMB) e Network File System (NFS)).
Puoi accedere ai dati all'interno dei volumi utilizzando i protocolli NAS tramite una rete Virtual Private Cloud. L'accesso a tutti i dati di NetApp Volumes è possibile solo tramite il VPC, a meno che tu non utilizzi esplicitamente una soluzione di terze parti per sostituire il routing del peering VPC ai tuoi VPC.
All'interno del VPC, puoi limitare ulteriormente l'accesso con i firewall e tramite la configurazione di meccanismicontrollo dell'accessoo dell'accesso specifici per il protocollo.
Regole firewall per l'accesso ai volumi
Le regole firewall proteggono Google Cloud VPC. Per consentire l'accesso dei client a NetApp Volumes, devi consentire un traffico di rete specifico.
Regole firewall per l'accesso ai volumi NFS
NFS utilizza varie porte per comunicare tra il client e un server. Per garantire una comunicazione corretta e il montaggio dei volumi, devi attivare le porte sui firewall.
NetApp Volumes funge da server NFS ed espone le porte di rete necessarie per NFS. Assicurati che i tuoi client NFS abbiano l'autorizzazione a comunicare con le seguenti porte NetApp Volumes:
111 TCP/UDP portmapper635 TCP/UDP mountd2049 TCP/UDP nfsd4045 TCP/UDP nlockmgr(solo per NFSv3)4046 TCP/UDP status(solo per NFSv3)3260 TCP iSCSI
Gli indirizzi IP per i NetApp Volumes vengono assegnati automaticamente dall'intervallo CIDR assegnato al servizio durante il peering di rete. Per maggiori informazioni, consulta Scegliere un CIDR.
Utilizzo del blocco consultivo con NFSv3
Se utilizzi blocchi di tipo advisory con NFSv3, devi eseguire il daemon rpc.statd
sul client per supportare Network Lock Manager, che è una funzionalità
che funziona in collaborazione con NFS per fornire un blocco di tipo advisory
di file e record di stile System V sulla rete. Il client NFS deve aprire una
porta di ingresso per rpc.statd per ricevere i callback di Network Lock Manager. Nella maggior parte delle distribuzioni Linux, rpc.statd viene avviato quando monti la prima condivisione NFS. Utilizza una porta casuale che puoi identificare utilizzando il comando rpcinfo -p. Per
rendere rpc.statd più compatibile con il firewall, configuralo in modo che utilizzi una porta statica.
Per impostare le porte statiche per rpc.statd, consulta le seguenti risorse:
Se non utilizzi i blocchi di avviso NFSv3 o Network Lock Manager, ti consigliamo di montare le condivisioni NFSv3 con l'opzione di montaggio nolock.
NFSv4.1 implementa la funzione di blocco all'interno del protocollo NFSv4.1 stesso, che viene eseguito sulla connessione TCP avviata dal client al server NFSv4.1 sulla porta 2049. Il cliente non deve aprire le porte del firewall per il traffico in entrata.
Regole firewall per l'accesso ai volumi SMB
SMB utilizza varie porte per comunicare tra il client e un server. Per garantire una comunicazione corretta, devi abilitare le porte sui firewall.
NetApp Volumes funge da server SMB ed espone le porte di rete richieste da SMB. Assicurati che il client SMB sia autorizzato a comunicare con le seguenti porte NetApp Volumes:
445 TCP SMB2/3135 TCP msrpce40001 TCP SMB CA: utilizzati solo per le condivisioni SMB 3.x disponibili in modo continuo. Queste porte non sono necessarie per le condivisioni non disponibili in modo continuo.
Il servizio espone, ma non utilizza, la porta 139/TCP.
Gli indirizzi IP per i NetApp Volumes vengono assegnati automaticamente dall'intervallo CIDR assegnato al servizio durante il peering di rete. Per maggiori informazioni, consulta Scegliere un CIDR.
I tuoi clienti PMI non devono esporre le porte di ingresso per il funzionamento di SMB.
Regole firewall per l'accesso ad Active Directory
NetApp Volumes ha bisogno dell'accesso alle seguenti porte sui server DNS configurati nelle norme di Active Directory per identificare i controller di dominio Active Directory. NetApp Volumes utilizza le ricerche DNS per il rilevamento del domain controller del dominio Active Directory.
ICMPV4DNS 53 TCPDNS 53 UDP
Apri le seguenti porte su tutti i controller di dominio Active Directory per il traffico proveniente dall'intervallo CIDR per NetApp Volumes:
ICMPV4LDAP 389 TCPSMB over IP 445 TCPSecure LDAP 636 TCPKerberos 464 TCPKerberos 464 UDPKerberos 88 TCPKerberos 88 UDP
Allegare il tag firewall ai server Active Directory
Segui queste istruzioni per collegare il tag firewall ai server Active Directory.
Collega la regola firewall ai server DNS di Active Directory:
gcloud compute firewall-rules create netappvolumes-to-dns \ --allow=icmp,TCP:53,UDP:53 \ --direction=ingress \ --target-tags=allow-netappvolumes-to-dns \ --source-ranges=NETAPP_VOLUMES_CIDR \ --network=VPC_NAME
Collega la regola firewall ai controller di dominio Active Directory:
gcloud compute firewall-rules create netappvolumes-to-activedirectory \ --allow=icmp,TCP:88,UDP:88,TCP:389,TCP:445,TCP:464,UDP:464,TCP:636 \ --direction=ingress \ --target-tags=allow-netappvolumes-to-activedirectory \ --source-ranges=NETAPP_VOLUMES_CIDR \ --network=VPC_NAME
Sostituisci le seguenti informazioni:
NETAPP_VOLUMES_CIDR: Il CIDR di NetApp VolumesVPC_NAME: Il nome del VPC
Aggiungi il seguente tag ai tuoi server DNS:
allow-netappvolumes-to-dns
Aggiungi il seguente tag ai tuoi controller di dominio:
allow-netappvolumes-to-activedirectory
Regole firewall per l'accesso ai volumi iSCSI
Per l'accesso iSCSI, NetApp Volumes utilizza porte di rete specifiche per abilitare la comunicazione tra initiator (client) e target (volumi di archiviazione). Per una connettività corretta e un accesso riuscito ai volumi di archiviazione a blocchi, devi configurare i firewall in modo da consentire le porte necessarie.
Assicurati che gli iniziatori iSCSI possano comunicare con la seguente porta di NetApp Volumes:
- 3260 TCP - Porta di destinazione iSCSI
Gli indirizzi IP per i NetApp Volumes vengono assegnati automaticamente dall'intervallo CIDR che hai assegnato al servizio durante il peering di rete. Per saperne di più, vedi Scegliere un CIDR.
Controlli di accesso al volume per i protocolli NFS
NetApp Volumes protegge l'accesso tramite protocolli NFS con una singola policy di esportazione con un massimo di 20 regole di esportazione. Le regole di esportazione sono elenchi separati da virgole di indirizzi IPv4 e CIDR IPv4 che specificano quali client hanno l'autorizzazione per montare i volumi. NetApp Volumes valuta le regole di esportazione in ordine sequenziale e si arresta dopo la prima corrispondenza. Per ottenere risultati ottimali, ti consigliamo di ordinare le regole di esportazione dalla più specifica alla più generica. Per saperne di più sulle regole di esportazione, consulta Controllo dell'controllo dell'accesso mediante le policy di esportazione.
Controlli dell'accesso al volume per il protocollo SMB
SMB utilizza le autorizzazioni a livello di condivisione per proteggere l'accesso al volume e richiede l'autenticazione in Active Directory. Queste autorizzazioni ti consentono di controllare chi ha accesso alle condivisioni sulla rete.
I volumi vengono creati con le autorizzazioni a livello di condivisione Tutti e Controllo completo. Puoi modificare le autorizzazioni a livello di condivisione utilizzando la console Windows o l'interfaccia a riga di comando di Windows.
Segui le istruzioni riportate di seguito per modificare le autorizzazioni a livello di condivisione SMB utilizzando la console Windows o Windows CLI:
Console Windows
Fai clic con il tasto destro del mouse sull'icona Start di Windows e seleziona Gestione computer.
Dopo l'apertura della console Gestione computer, fai clic su Azione > Connetti a un altro computer.
Nella finestra di dialogo Seleziona computer, inserisci il nome NetBIOS della condivisione SMB e fai clic su Ok.
Una volta connesso alla condivisione file, vai a Utilità di sistema > Cartelle condivise > Condivisioni per cercare la tua condivisione.
Fai doppio clic su Nome condivisione e seleziona la scheda Autorizzazioni di condivisione per controllare le autorizzazioni della condivisione.
Interfaccia a riga di comando Windows
Apri una riga di comando di Windows.
Connettiti alla condivisione file.
fsmgmt.msc /computer=<netbios_name_of_share>
Una volta connesso alla condivisione file, vai a Utilità di sistema > Cartelle condivise > Condivisioni per cercare la tua condivisione.
Fai doppio clic su Nome condivisione e seleziona la scheda Autorizzazioni di condivisione per controllare le autorizzazioni della condivisione.
Controlli di accesso al volume per il protocollo iSCSI
L'accesso ai volumi iSCSI NetApp viene gestito utilizzando i gruppi di host, che sono oggetti regionali che contengono uno o più IQN dell'iniziatore iSCSI. Un iniziatore iSCSI è in genere un sistema client o un server che si connette a destinazioni di archiviazione su una rete utilizzando il protocollo iSCSI.
Quando viene creato un volume iSCSI, questo viene collegato a un gruppo di host. Questa relazione concede l'accesso al volume iSCSI ai client iSCSI (iniziatori) all'interno di quel gruppo di host, consentendo loro di individuare la LUN e utilizzare la risorsa di archiviazione. Solo gli iniziatori che sono membri del gruppo host possono visualizzare e connettersi al volume iSCSI assegnato.
Di seguito sono riportate le caratteristiche principali dei gruppi di host e dell'accesso iSCSI:
Controllo della visibilità: i gruppi di host limitano i client iSCSI che possono visualizzare e accedere a volumi specifici. Se un iniziatore non fa parte di un gruppo host, non può rilevare o connettersi alla LUN.
Ambito regionale: i gruppi di host sono oggetti regionali, con configurazione e appartenenza limitate a una regione specifica all'interno del tuo ambienteGoogle Cloud .
Sicurezza lato client: mentre i gruppi di host controllano la visibilità dei volumi, l'amministratore del client iSCSI è responsabile dell'implementazione dei controlli di accesso a livello utente sul sistema client. Ciò include la gestione di chi può montare il volume iSCSI e chi può accedere al file system creato al suo interno.
Autorizzazioni del file system basate sull'host
Una volta mappata una LUN a un host, il sistema operativo dell'host è responsabile della gestione delle autorizzazioni del file system e dei controlli dell'accesso. Ad esempio, gli host Windows utilizzano autorizzazioni e ACL NTFS, mentre gli host Linux e UNIX utilizzano autorizzazioni di file UNIX standard e, facoltativamente, ACL per proteggere file e directory.
Questo approccio alla sicurezza a due livelli contribuisce a garantire che solo gli host autorizzati possano accedere allo spazio di archiviazione a livello di blocco, mentre il sistema operativo host gestisce la sicurezza a livello di file in base ai criteri dell'organizzazione.
Controllo dell'accesso ai file
Le sezioni seguenti forniscono dettagli sul controllo dell'accesso a livello di file di NetApp Volumes.
Stile di sicurezza del volume
NetApp Volumes offre due stili di sicurezza per i volumi, UNIX e NTFS, per adattarsi ai diversi set di autorizzazioni delle piattaforme Linux e Windows.
UNIX: i volumi configurati con lo stile di sicurezza UNIX utilizzano i bit di modalità UNIX e gli ACL NFSv4 per controllare l'accesso ai file.
NTFS: i volumi configurati con lo stile di sicurezza NTFS utilizzano gli ACL NTFS per controllare l'accesso ai file.
Lo stile di sicurezza del volume dipende dalla scelta del protocollo per il volume:
| Tipo di protocollo | Stile di sicurezza del volume |
|---|---|
| NFSv3 | UNIX |
| NFSv4.1 | UNIX |
| Entrambi (NFSv3 e NFSv4.1) | UNIX |
| SMB | NTFS |
| Doppio (SMB e NFSv3) | UNIX o NTFS |
| Doppio (SMB e NFSv4.1) | UNIX o NTFS |
Per i doppi protocolli, puoi scegliere lo stile di sicurezza solo durante la creazione del volume.
Controllo dell'accesso a livello di file NFS per i volumi in stile UNIX
Dopo che un client ha montato correttamente un volume, NetApp Volumes
controlla le autorizzazioni di accesso a file e directory utilizzando il modello di autorizzazioni UNIX
standard chiamato bit di modalità. Puoi impostare e modificare le autorizzazioni utilizzando
chmod.
I volumi NFSv4.1 possono utilizzare anche gli elenchi di controllo dell'accesso (ACL) NFSv4. Se un file o una directory ha sia bit di modalità che un ACL NFSv4, l'ACL viene utilizzato per il controllo delle autorizzazioni. Lo stesso vale per i volumi che utilizzano entrambi i tipi di protocollo NFSv3 e NFSv4.1. Puoi impostare e modificare le ACL NFSv4 utilizzando nfs4_getfacl e
nfs4_setfacl.
Quando crei un nuovo volume in stile UNIX, root:root è proprietario
dell'inode root e delle autorizzazioni 0770. A causa di questa impostazione di proprietà e autorizzazione,
un utente non root riceve un errore permission denied durante l'accesso al volume
dopo il montaggio. Per consentire l'accesso al volume agli utenti non root, un utente root
deve modificare la proprietà dell'inode root utilizzando chown e modificare le autorizzazioni
del file utilizzando chmod.
Controllo dell'accesso ai file SMB per volumi in stile NTFS
Per i volumi in stile NTFS, ti consigliamo di utilizzare un modello di autorizzazioni NTFS.
Ogni file e directory ha un ACL NTFS che puoi modificare utilizzando Esplora
file, lo strumento a riga di comando icacls o PowerShell. Nel modello di autorizzazione NTFS, i nuovi file e le nuove cartelle ereditano le autorizzazioni dalla cartella principale.
Mappatura degli utenti multiprotocollo
Per i volumi a doppio protocollo, i client possono utilizzare NFS e SMB per accedere agli stessi dati. Un volume viene configurato impostando lo stile di sicurezza del volume in modo che disponga di autorizzazioni UNIX o NTFS.
Quando crei un volume SMB e NFS a doppio protocollo, ti consigliamo vivamente di
inserire un utente predefinito in Active Directory. L'utente predefinito viene utilizzato quando un client NFS invia una chiamata NFS con un ID utente non disponibile in Active Directory.
NetApp Volumes tenta quindi di cercare un utente chiamato pcuser,
che funge da utente UNIX predefinito. Se l'utente non viene trovato, l'accesso alla chiamata NFS viene negato.
Ti consigliamo di creare un utente predefinito in Active Directory con i seguenti attributi:
uid=pcuseruidnumber=65534cn=pcusergidNumber=65534objectClass=user
A seconda del protocollo utilizzato dal client (NFS o SMB) e dello stile di sicurezza del volume (UNIX o NTFS), i NetApp Volumes possono controllare direttamente le autorizzazioni di accesso dell'utente o richiedono prima il mapping dell'utente all'identità dell'altra piattaforma.
| Protocollo di accesso | Stile di sicurezza | Identità utilizzata dal protocollo | Mappatura obbligatoria |
|---|---|---|---|
| NFSv3 | UNIX | ID utente e ID gruppo | N/D |
| NFSv3 | NTFS | ID utente e ID gruppo | ID utente a nome utente a identificatore di sicurezza |
| SMB | UNIX | Identificatore di sicurezza | Identificatore di sicurezza per il nome utente e l'ID utente |
| SMB | NTFS | Identificatore di sicurezza | N/D |
Quando è necessario il mapping, NetApp Volumes si basa sui dati archiviati in Active Directory LDAP. Per saperne di più, consulta Casi d'uso di Active Directory.
Scenario di mappatura degli utenti multi-protocollo: accesso SMB a un volume UNIX
Lo scienziato Charlie E. (charliee) vuole accedere a un volume NetApp Volumes utilizzando SMB da un client Windows. Poiché il volume contiene risultati generati dalla macchina forniti da un cluster di calcolo Linux, il volume è configurato per archiviare le autorizzazioni UNIX.
Il client Windows invia una chiamata SMB al volume. La chiamata SMB contiene l'identità dell'utente come identificatore di sicurezza. L'identificatore di sicurezza non è confrontabile con le autorizzazioni dei file ID utente e ID gruppo e richiede il mapping.
Per completare il mapping richiesto, NetApp Volumes esegue i seguenti passaggi:
NetApp Volumes chiede ad Active Directory di risolvere l'identificatore di sicurezza in un nome utente, ad esempio, da
S-1-5-21-2761044393-2226150802-3019316526-1224acharliee.NetApp Volumes chiede ad Active Directory di restituire l'ID utente e l'ID gruppo per
charliee.NetApp Volumes verifica l'accesso in base all'ID utente proprietario e all'ID gruppo del file utilizzando l'ID utente e l'ID gruppo restituiti.
Scenario di mappatura degli utenti multi-protocollo: accesso NFS a un volume NTFS
L'ingegnere Amal L. deve accedere ad alcuni dati su un volume da un client Linux utilizzando NFS. Poiché il volume viene utilizzato principalmente per archiviare dati Windows, è configurato con lo stile di sicurezza NTFS.
Il client Linux invia una chiamata NFS a NetApp Volumes. La chiamata NFS contiene identificatori di ID utente e ID gruppo che non possono essere associati a un identificatore di sicurezza senza mappatura.
Per completare il mapping richiesto, NetApp Volumes chiede ad Active Directory il nome utente dell'ID utente e di restituire l'identificatore di sicurezza per il nome utente, quindi controlla l'accesso rispetto all'identificatore di sicurezza del proprietario del file a cui è stato eseguito l'accesso utilizzando l'identificatore di sicurezza restituito.
Crittografia dei dati in transito
La crittografia in transito protegge i dati dall'intercettazione su una rete. Il traffico per la replica dei volumi, il backup integrato e la migrazione dei volumi viene criptato per impostazione predefinita utilizzando TLS 1.2. Per il traffico NFS e SMB, puoi configurare impostazioni di crittografia specifiche del protocollo per una maggiore protezione.
NFS
Per i volumi NFS, utilizza NFSv4.1 con la crittografia Kerberos krb5p abilitata per la massima sicurezza.
SMB
Per i volumi SMB, abilita la crittografia AES nel criterio Active Directory e la crittografia SMB sul volume per la massima sicurezza.
Replica volume
NetApp Volumes può replicare i volumi in più Google Cloud regioni per fornire protezione dei dati. Poiché il traffico si trova in Google Cloud, l'infrastruttura di rete di Google protegge il processo di trasferimento, che ha accesso limitato per impedire intercettazioni non autorizzate. Inoltre, il traffico di replica viene criptato utilizzando gli standard TLS 1.2 conformi a FIPS 140-2.
Backup integrato
Un backup integrato crea backup di NetApp Volumes all'interno del servizio. Il traffico di backup rimane all'interno dell'infrastruttura di rete di Google ed è criptato utilizzando lo standard TLS 1.2 conforme a FIPS 140-2. I vault di backup possono archiviare questi backup utilizzando Google-managed encryption key per impostazione predefinita o la chiave di crittografia gestita dal cliente (CMEK) per una maggiore sicurezza.
Migrazione del volume
La migrazione dei volumi invia i dati dal sistema ONTAP o Cloud Volumes ONTAP di origine a NetApp Volumes. La comunicazione tra il sistema di origine e NetApp Volumes è criptata utilizzando gli standard TLS 1.2 conformi a FIPS 140-2.
NetApp Volumes avvia la migrazione e utilizza i seguenti protocolli e porte:
ICMP
10000/TCP
11104/TCP
11105/TCP
Assicurati che qualsiasi firewall tra l'interfaccia logica intercluster (LIF) del sistema ONTAP e l'indirizzo IP di migrazione di NetApp Volumes consenta queste porte.
Passaggi successivi
Proteggi i volumi NetApp con un perimetro di servizio.