Questa pagina fornisce una panoramica delle considerazioni sulla sicurezza di Google Cloud NetApp Volumes.
Considerazioni sulla sicurezza per il networking
Google Cloud NetApp Volumes fornisce un framework di architettura sicuro con i seguenti livelli di sicurezza isolati:
Sicurezza a livello di progetto: il livello di sicurezza amministrativo utilizzato dagli amministratori per gestire le risorse di NetApp Volumes, come pool di archiviazione o volumi, utilizzando la console Google Cloud , l'Google Cloud SDK o le API. I ruoli e le autorizzazioni IAM proteggono questo livello. Per ulteriori informazioni 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 protocolli NAS (Network Attached Storage) (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 dei NetApp Volumes è possibile solo tramite il VPC, a meno che non utilizzi esplicitamente una soluzione di terze parti per sostituire il routing del peering VPC per i VPC.
All'interno del VPC, puoi limitare ulteriormente l'accesso con i firewall e tramite la configurazione di meccanismi di controllo dell'accesso dell'accesso specifici per protocollo.
Regole firewall per l'accesso ai volumi
Le regole firewall proteggono la VPC Google Cloud . Per consentire l'accesso da parte 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 la comunicazione tra il client e un server. Per assicurarti una comunicazione corretta e il montaggio dei volumi, devi attivare le porte sui firewall.
NetApp Volumes agisce come server NFS ed espone le porte di rete necessarie per NFS. Assicurati che i tuoi client NFS abbiano l'autorizzazione per comunicare con le seguenti porte NetApp Volumes:
111 TCP/UDP portmapper
635 TCP/UDP mountd
2049 TCP/UDP nfsd
4045 TCP/UDP nlockmgr
(solo per NFSv3)4046 TCP/UDP status
(solo per NFSv3)
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 di consulenza con NFSv3
Se utilizzi i blocchi di consulenza con NFSv3, devi eseguire il daemon rpc.statd
sul client per supportare Network Lock Manager, un'utilità che collabora con NFS per fornire un blocco di consulenza di tipo System V
per file e record sulla rete. Il client NFS deve aprire una porta di ingresso per consentire a rpc.statd
di ricevere i callback di Network Lock Manager. Nella maggior parte delle distribuzioni Linux, rpc.statd
si avvia quando viene montata 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 da utilizzare una porta statica.
Per impostare porte statiche per rpc.statd
, consulta le seguenti risorse:
Se non utilizzi i blocchi di consulenza 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 tramite la 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 la comunicazione tra il client e un server. Per garantire una comunicazione corretta, devi attivare le porte sui firewall.
NetApp Volumes agiscono come server SMB ed espongono 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/3
135 TCP msrpc
e40001 TCP SMB CA
: utilizzati solo per le condivisioni disponibili continuamente di SMB 3.x. 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 client SMB non devono esporre le porte di ingresso per il funzionamento di SMB.
Regole firewall per l'accesso ad Active Directory
Apri le seguenti porte su tutti i controller di dominio Active Directory per il traffico proveniente dall'intervallo CIDR per i NetApp Volumes:
ICMPV4
DNS 53 TCP
DNS 53 UDP
LDAP 389 TCP
LDAP 389 UDP
LDAP (GC) 3268 TCP
SAM/LSA 445 TCP
SAM/LSA 445 UDP
Secure LDAP 636 TCP
Secure LDAP 3269 TCP
W32Time 123 UDP
AD Web Svc 9389 TCP
Kerberos 464 TCP
Kerberos 464 UDP
Kerberos 88 TCP
Kerberos 88 UDP
Associa il tag firewall ai server Active Directory
Segui le istruzioni riportate di seguito per collegare il tag del firewall ai server Active Directory.
Collega il tag firewall ai server Active Directory:
gcloud compute firewall-rules create netappvolumes-to-activedirectory \ --allow=icmp,TCP:53,UDP:53,TCP:88,UDP:88,UDP:123,TCP:389,UDP:389,TCP:445,UDP:445,TCP:464,UDP:464,TCP:636,TCP:3268,TCP:3269,TCP:9389 \ --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 della VPC
Collega il seguente tag ai controller di dominio:
allow-netappvolumes-to-activedirectory
Controlli di accesso ai volumi per i protocolli NFS
NetApp Volumes protegge l'accesso tramite i protocolli NFS con un singolo criterio di esportazione con un massimo di 20 regole di esportazione. Le regole di esportazione sono elenchi di indirizzi IPv4 e CIDR IPv4 separati da virgole che specificano i client che hanno l'autorizzazione a montare i volumi. NetApp Volumes valuta le regole di esportazione in ordine sequenziale e si arresta dopo la prima corrispondenza. Per ottenere risultati ottimali, consigliamo di ordinare le regole di esportazione dalla più specifica alla più generica.
Utilizza le seguenti schede per esaminare i criteri in base alle versioni NFS:
NFS senza Kerberos
Tutte le versioni NFS senza Kerberos utilizzano il tipo di sicurezza AUTH_SYS
. In questa modalità, devi gestire in modo rigoroso le regole di esportazione per consentire solo i client di tua attendibilità e che possono garantire l'integrità dell'ID utente e dell'ID gruppo.
Come misura di sicurezza, i server NFS mappano automaticamente le chiamate NFS con UID=0
(root) a UID=65535
(anonimo), che ha autorizzazioni limitate sul sistema
di file. Durante la creazione del volume, puoi attivare l'opzione di accesso come utente root per controllare questo comportamento. Se attivi l'accesso root, l'ID utente 0
rimane 0
. Come miglior prassi, crea una regola di esportazione dedicata che abiliti l'accesso root per i tuoi host di amministrazione noti e disattivi l'accesso root per tutti gli altri client.
NFSv4.1 con Kerberos
NFSv4.1 con Kerberos utilizza i criteri di esportazione e un'autenticazione aggiuntiva con Kerberos per accedere ai volumi. Puoi configurare le regole di esportazione da applicare per quanto segue:
Solo Kerberos (
krb5
)Firma Kerberos (
krb5i
)Privacy Kerberos (
krb5p
)
Controlli di accesso ai volumi per il protocollo SMB
SMB utilizza le autorizzazioni a livello di condivisione per proteggere l'accesso al volume e richiedere 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 la CLI Windows.
Segui le istruzioni riportate di seguito per modificare le autorizzazioni a livello di condivisione SMB utilizzando la console Windows o l'interfaccia a riga di comando Windows:
Console Windows
Fai clic con il tasto destro del mouse sull'icona Start di Windows e seleziona Gestione computer.
Dopo aver aperto la 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 Strumenti di sistema > Cartelle condivise > Condivisioni per cercare la condivisione.
Fai doppio clic su Nome condivisione e seleziona la scheda Autorizzazioni 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 Strumenti di sistema > Cartelle condivise > Condivisioni per cercare la condivisione.
Fai doppio clic su Nome condivisione e seleziona la scheda Autorizzazioni condivisione per controllare le autorizzazioni della condivisione.
Controllo dell'accesso ai file
Le sezioni che seguono 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 supportare i 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 le ACL NTFS per controllare l'accesso ai file.
Lo stile di sicurezza del volume dipende dal protocollo scelto per il volume:
Tipo di protocollo | Stile di sicurezza del volume |
---|---|
NFSv3 | UNIX |
NFSv4.1 | UNIX |
Entrambi (NFSv3 e NFSv4.1) | UNIX |
PMI | NTFS |
Doppio (SMB e NFSv3) | UNIX o NTFS |
Doppio (SMB e NFSv4.1) | UNIX o NTFS |
Per i protocolli doppi, 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 un volume correttamente, NetApp Volumes controlla le autorizzazioni di accesso a file e directory utilizzando il modello di autorizzazione 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 i bit di modalità sia 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
è il proprietario dell'inode principale 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 principale utilizzando chown
e modificare le autorizzazioni dei file utilizzando chmod
.
Controllo dell'accesso ai file SMB per i volumi in stile NTFS
Per i volumi in stile NTFS, ti consigliamo di utilizzare un modello di autorizzazioni NTFS.
Ogni file e ogni directory ha un ACL NTFS che puoi modificare utilizzando File Explorer, lo strumento a riga di comando icacls
o PowerShell. Nel modello di autorizzazioni NTFS, i nuovi file e le nuove cartelle ereditano le autorizzazioni dalla cartella principale.
Mappatura utenti multiprotocollo
Per i volumi con 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 abbia autorizzazioni UNIX o NTFS.
Quando crei un volume SMB e NFS con doppio protocollo, ti consigliamo vivamente di verificare che Active Directory contenga un utente predefinito. 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 denominato pcuser
,
che funge da utente UNIX predefinito. Se l'utente non viene trovato, l'accesso viene negato alla chiamata NFS.
Ti consigliamo di creare un utente predefinito in Active Directory con i seguenti attributi:
uid
=pcuser
uidnumber
=65534
cn
=pcuser
gidNumber
=65534
objectClass
=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 richiedere prima di mappare l'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 | Da ID utente a nome utente a identificatore di sicurezza |
PMI | UNIX | Identificatore di sicurezza | Identificatore di sicurezza a nome utente a ID utente |
PMI | NTFS | Identificatore di sicurezza | N/D |
Quando è necessaria la mappatura, NetApp Volumes si basa sui dati archiviati in Active Directory LDAP. Per ulteriori informazioni, consulta i casi d'uso di Active Directory.
Scenario di mappatura degli utenti multiprotocollo: accesso SMB a un volume UNIX
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, è configurato per memorizzare le autorizzazioni UNIX.
Il client Windows invia una chiamata SMB al volume. La chiamata SMB contiene l'identità utente come identificatore di sicurezza. L'identificatore di sicurezza non è paragonabile alle autorizzazioni dei file per ID utente e ID gruppo e richiede il mapping.
Per completare la mappatura richiesta, NetApp Volumes esegue i seguenti passaggi:
NetApp Volumes chiede ad Active Directory di risolvere l'identificatore di sicurezza in un nome utente, ad esempio
S-1-5-21-2761044393-2226150802-3019316526-1224
incharliee
.NetApp Volumes chiede ad Active Directory di restituire l'ID utente e l'ID gruppo per
charliee
.NetApp Volumes controlla l'accesso in base all'ID utente e all'ID gruppo di proprietà del file utilizzando l'ID utente e l'ID gruppo restituiti.
Scenario di mappatura degli utenti multiprotocollo: 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 i dati di 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 gruppo che non possono essere associati a un identificatore di sicurezza senza mappatura.
Per completare la mappatura richiesta, 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
NFS
Per i volumi NFS, utilizza NFSv4.1 con la crittografia Kerberos krb5p abilitata per la massima sicurezza.
PMI
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 possono replicare i volumi nelle regioni Google Cloud per fornire protezione dei dati. Poiché il traffico si trova in Google Cloud, il processo di trasferimento è sicuro in quanto utilizza l'infrastruttura di rete di Google, che ha accesso limitato per impedire l'intercettazione non autorizzata. 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 dei NetApp Volumes all'interno del servizio. Il traffico di backup rimane all'interno dell'infrastruttura di rete sicura di Google utilizzando la crittografia standard TLS 1.2 conforme a FIPS 140-2. Inoltre, le cassette di sicurezza archiviano questi backup utilizzando una chiave di crittografia di proprietà di Google e gestita da Google per una maggiore sicurezza.
Passaggi successivi
Proteggi i volumi NetApp con un perimetro di servizio.