Sicherheitsaspekte

Auf dieser Seite finden Sie einen Überblick über die Sicherheitsaspekte für Google Cloud NetApp Volumes. Dazu gehören Netzwerkschutz, Zugriffssteuerung und Datenverschlüsselung.

Sicherheitsaspekte für die Vernetzung

Google Cloud NetApp Volumes bietet ein geschütztes Architektur-Framework mit den folgenden isolierten Sicherheitsebenen:

• Sicherheit auf Projektebene: Die administrative Sicherheitsebene, mit der Administratoren NetApp Volumes-Ressourcen wie Speicherpools oder Volumes über die Google Cloud -Konsole, das Google Cloud SDK oder APIs verwalten. IAM-Rollen und ‑Berechtigungen schützen diese Ebene. Weitere Informationen zur Sicherheit auf Projektebene finden Sie unter IAM-Berechtigungen einrichten.

• Sicherheit auf Netzwerkebene: Die Netzwerkschicht, die für den Zugriff auf Datenvolumen mit NAS-Protokollen (Network Attached Storage, Server Message Block (SMB) und Network File System (NFS)) verwendet wird.

  Sie können über ein VPC-Netzwerk (Virtual Private Cloud) mit NAS-Protokollen auf Daten in Volumes zugreifen. Der gesamte Datenzugriff auf NetApp-Volumes ist nur über Ihre VPC möglich, sofern Sie nicht explizit eine Drittanbieterlösung verwenden, um das VPC-Peering-Routing zu Ihren VPCs zu ersetzen.

  Innerhalb der VPC können Sie den Zugriff mit Firewalls und durch die Einrichtung protokollspezifischer Zugriffssteuerungsmechanismen weiter einschränken.

Firewallregeln für den Zugriff auf Volumes

Firewallregeln schützen die Google Cloud VPC. Damit Clients auf NetApp Volumes zugreifen können, müssen Sie bestimmten Netzwerkverkehr zulassen.

Weitere Informationen zu Firewallregeln für den Zugriff auf NFS-, SMB- und iSCSI-Volumes finden Sie in den folgenden Abschnitten:

• Firewallregeln für den Zugriff auf NFS-Volumes

• Firewallregeln für den Zugriff auf SMB-Volumes

• Firewallregeln für den Zugriff auf iSCSI-Volumes

Firewallregeln für den Active Directory-Zugriff

NetApp Volumes benötigt Zugriff auf die folgenden Ports auf den DNS-Servern, die in Ihrer Active Directory-Richtlinie konfiguriert sind, um Active Directory-Domaincontroller zu identifizieren. NetApp Volumes verwendet DNS-Lookups für die Suche nach Active Directory-Domaincontrollern.

• ICMPV4

• DNS 53 TCP

• DNS 53 UDP

Öffnen Sie die folgenden Ports auf allen Ihren Active Directory-Domaincontrollern für Traffic, der aus dem CIDR-Bereich für NetApp Volumes stammt:

• ICMPV4

• LDAP 389 TCP

• SMB over IP 445 TCP

• Secure LDAP 636 TCP

• Kerberos 464 TCP

• Kerberos 464 UDP

• Kerberos 88 TCP

• Kerberos 88 UDP

Wenn Sie einen Quellbereich für Ihre Firewalls angeben möchten, verwenden Sie den vollständigen CIDR-Bereich, den Sie beim Konfigurieren des privaten Dienstzugriffs angegeben haben. Weitere Informationen finden Sie unter Zugriff auf private Dienste konfigurieren.

Hinweis :Active Directory-DNS-Server dienen auch als Domaincontroller, für die zwei Regelsätze angewendet werden müssen.

Firewall-Tag an Active Directory-Server anhängen

Folgen Sie der Anleitung unten, um das Firewall-Tag an Ihre Active Directory-Server anzuhängen.

1. Hängen Sie die Firewallregel an Ihre Active Directory-DNS-Server an:

   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

2. Hängen Sie die Firewallregel an Ihre Active Directory-Domaincontroller an:

   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

   Ersetzen Sie die folgenden Informationen:

   • NETAPP_VOLUMES_CIDR: Der CIDR-Bereich für NetApp Volumes

   • VPC_NAME: Der Name der VPC

3. Fügen Sie Ihren DNS-Servern das folgende Tag hinzu:

   allow-netappvolumes-to-dns

4. Fügen Sie Ihren Domaincontrollern das folgende Tag hinzu:

   allow-netappvolumes-to-activedirectory

Zugriffssteuerung für Volumes für NFS-Protokolle

NetApp Volumes schützt den Zugriff über NFS-Protokolle mit einer einzelnen Exportrichtlinie mit bis zu 20 Exportregeln. Exportregeln sind durch Kommas getrennte Listen von IPv4-Adressen und IPv4-CIDRs, die angeben, welche Clients die Berechtigung zum Mounten von Volumes haben. NetApp Volumes wertet Exportregeln in sequenzieller Reihenfolge aus und stoppt nach der ersten Übereinstimmung. Für optimale Ergebnisse empfehlen wir, die Exportregeln von der spezifischsten zur allgemeinsten zu sortieren. Weitere Informationen zu Exportregeln finden Sie unter Volume-Zugriffssteuerung mit Exportrichtlinien.

Zugriffssteuerung für Volumes für das SMB-Protokoll

SMB verwendet Berechtigungen auf Freigabeebene, um den Volume-Zugriff zu schützen und die Authentifizierung gegenüber Active Directory zu erzwingen. Mit diesen Berechtigungen können Sie festlegen, wer über das Netzwerk auf Freigaben zugreifen kann.

Volumes werden mit den Berechtigungen Jeder und Vollzugriff auf Freigabeebene erstellt. Sie können Berechtigungen auf Freigabeebene über die Windows-Konsole oder die Windows-Befehlszeile ändern.

Gehen Sie so vor, um Berechtigungen auf SMB-Freigabeebene über die Windows-Konsole oder die Windows-Befehlszeile zu ändern:

Windows-Konsole

1. Klicken Sie mit der rechten Maustaste auf das Windows-Startmenü und wählen Sie Computerverwaltung aus.

2. Klicken Sie nach dem Öffnen der Konsole Computerverwaltung auf Aktion > Mit anderem Computer verbinden.

3. Geben Sie im Dialogfeld Computer auswählen den NetBIOS-Namen der SMB-Freigabe ein und klicken Sie auf OK.

4. Sobald Sie mit der Dateifreigabe verbunden sind, rufen Sie System Tools > Shared Folders > Shares auf, um Ihre Freigabe zu suchen.

5. Doppelklicken Sie auf Freigabename und wählen Sie den Tab Freigabeberechtigungen aus, um die Berechtigungen der Freigabe zu verwalten.

Windows-Befehlszeile

1. Öffnen Sie eine Windows-Befehlszeile.

2. Stellen Sie eine Verbindung zur Dateifreigabe her.

   fsmgmt.msc /computer=<netbios_name_of_share>

3. Sobald Sie mit der Dateifreigabe verbunden sind, rufen Sie System Tools > Shared Folders > Shares auf, um Ihre Freigabe zu suchen.

4. Doppelklicken Sie auf Freigabename und wählen Sie den Tab Freigabeberechtigungen aus, um die Berechtigungen der Freigabe zu verwalten.

Zugriffssteuerung für Volumes für das iSCSI-Protokoll

Der Zugriff auf iSCSI NetApp Volumes wird über Hostgruppen verwaltet. Das sind regionale Objekte, die ein oder mehrere iSCSI-Initiator-IQNs enthalten. Ein iSCSI-Initiator ist in der Regel ein Clientsystem oder Server, der über ein Netzwerk mit dem iSCSI-Protokoll eine Verbindung zu Speicherzielen herstellt.

Wenn ein iSCSI-Volume erstellt wird, wird es an eine Hostgruppe angehängt. Durch diese Beziehung erhalten die iSCSI-Clients (Initiatoren) in dieser Hostgruppe Zugriff auf das iSCSI-Volume, sodass sie die LUN erkennen und die Speicherressource nutzen können. Nur Initiatoren, die Mitglieder der Hostgruppe sind, können das zugewiesene iSCSI-Volume aufrufen und eine Verbindung dazu herstellen.

Im Folgenden sind die wichtigsten Merkmale von Hostgruppen und iSCSI-Zugriff aufgeführt:

• Sichtbarkeitssteuerung: Mit den Hostgruppen wird eingeschränkt, welche iSCSI-Clients bestimmte Volumes ansehen und darauf zugreifen können. Wenn ein Initiator nicht Teil einer Hostgruppe ist, kann er die LUN nicht erkennen oder eine Verbindung dazu herstellen.

• Regionaler Umfang: Die Hostgruppen sind regionale Objekte. Ihre Konfiguration und Mitgliedschaft sind auf eine bestimmte Region in IhrerGoogle Cloud -Umgebung beschränkt.

• Clientseitige Sicherheit: Hostgruppen steuern zwar die Sichtbarkeit von Volumes, der iSCSI-Clientadministrator ist jedoch für die Implementierung von Zugriffssteuerungen auf Nutzerebene auf dem Clientsystem verantwortlich. Dazu gehört auch die Verwaltung der Berechtigungen für das Mounten des iSCSI-Volumes und den Zugriff auf das darauf erstellte Dateisystem.

Hostbasierte Dateisystemberechtigungen

Sobald eine LUN einem Host zugeordnet ist, ist das Betriebssystem des Hosts für die Verwaltung von Dateisystemberechtigungen und Zugriffssteuerungen verantwortlich. Windows-Hosts verwenden beispielsweise NTFS-Berechtigungen und ‑ACLs, während Linux- und UNIX-Hosts standardmäßige UNIX-Dateiberechtigungen und optional ACLs zum Schutz von Dateien und Verzeichnissen verwenden.

Dieser zweischichtige Sicherheitsansatz trägt dazu bei, dass nur autorisierte Hosts auf Speicher auf Blockebene zugreifen können, während das Hostbetriebssystem die Sicherheit auf Dateiebene gemäß den Organisationsrichtlinien verwaltet.

Dateizugriffssteuerung

In den folgenden Abschnitten finden Sie Details zur Dateiebene-Zugriffssteuerung für NetApp Volumes.

Sicherheitsstil für Volumes

NetApp Volumes bietet zwei Sicherheitsstile für Volumes: UNIX und NTFS. So können die unterschiedlichen Berechtigungssätze von Linux- und Windows-Plattformen berücksichtigt werden.

• UNIX: Für Volumes, die mit dem UNIX-Sicherheitsstil konfiguriert sind, werden UNIX-Modusbits und NFSv4-ACLs verwendet, um den Dateizugriff zu steuern.

• NTFS: Für Volumes, die mit dem NTFS-Sicherheitsstil konfiguriert sind, werden NTFS-ACLs verwendet, um den Dateizugriff zu steuern.

Der Sicherheitsstil des Volumes hängt von der Protokollauswahl für das Volume ab:

Protokolltyp	Sicherheitsstil für Volumes
NFSv3	UNIX
NFSv4.1	UNIX
Beide (NFSv3 und NFSv4.1)	UNIX
KMU	NTFS
Dual (SMB und NFSv3)	UNIX oder NTFS
Dual (SMB und NFSv4.1)	UNIX oder NTFS

Bei Dual-Protokollen können Sie den Sicherheitsstil nur bei der Volume-Erstellung auswählen.

NFS-Zugriffssteuerung auf Dateiebene für UNIX-Volumes

Nachdem ein Client ein Volume erfolgreich bereitgestellt hat, prüft NetApp Volumes die Zugriffsberechtigungen für Dateien und Verzeichnisse anhand des standardmäßigen UNIX-Berechtigungsmodells, das als Modusbits bezeichnet wird. Sie können Berechtigungen mit chmod festlegen und ändern.

NFSv4.1-Volumes können auch NFSv4-Zugriffssteuerungslisten (Access Control Lists, ACLs) verwenden. Wenn für eine Datei oder ein Verzeichnis sowohl Modusbits als auch eine NFSv4-ACL vorhanden sind, wird die ACL für die Berechtigungsprüfung verwendet. Das gilt auch für Volumes, die sowohl NFSv3- als auch NFSv4.1-Protokolltypen verwenden. Sie können NFSv4-ACLs mit nfs4_getfacl und nfs4_setfacl festlegen und ändern.

Wenn Sie ein neues UNIX-ähnliches Volume erstellen, ist root:root der Inhaber des Root-Inodes und hat die Berechtigungen 0770. Aufgrund dieser Einstellungen für Inhaberschaft und Berechtigungen erhält ein Nutzer ohne Root-Berechtigungen beim Zugriff auf das Volume nach dem Mounten den Fehler permission denied. Damit Nutzer ohne Root-Zugriff auf das Volume zugreifen können, muss ein Root-Nutzer die Eigentümerschaft des Root-Inodes mit chown ändern und die Dateiberechtigungen mit chmod ändern.

SMB-Dateizugriffssteuerung für NTFS-Volumes

Für Volumes im NTFS-Stil empfehlen wir die Verwendung eines NTFS-Berechtigungsmodells. Jede Datei und jedes Verzeichnis hat eine NTFS-ACL, die Sie mit dem Datei-Explorer, dem icacls-Befehlszeilentool oder PowerShell ändern können. Im NTFS-Berechtigungsmodell übernehmen neue Dateien und Ordner Berechtigungen von ihrem übergeordneten Ordner.

Nutzerzuordnung für mehrere Protokolle

Bei Dual-Protocol-Volumes können Clients mit NFS und SMB auf dieselben Daten zugreifen. Ein Volume wird konfiguriert, indem der Sicherheitsstil des Volumes auf UNIX- oder NTFS-Berechtigungen festgelegt wird.

Wenn Sie ein Dual-Protokoll-Volume für SMB und NFS erstellen, empfehlen wir dringend, dass Active Directory einen Standardnutzer enthält. Der Standardnutzer wird verwendet, wenn ein NFS-Client einen NFS-Aufruf mit einer Nutzer-ID sendet, die in Active Directory nicht verfügbar ist. NetApp Volumes versucht dann, einen Nutzer namens pcuser zu finden, der als Standard-UNIX-Nutzer fungiert. Wenn dieser Nutzer nicht gefunden wird, wird der Zugriff auf den NFS-Aufruf verweigert.

Wir empfehlen, in Active Directory einen Standardnutzer mit den folgenden Attributen zu erstellen:

• uid = pcuser

• uidnumber = 65534

• cn = pcuser

• gidNumber = 65534

• objectClass = user

Je nach Protokoll, das vom Client verwendet wird (NFS oder SMB), und dem Sicherheitsstil des Volumes (UNIX oder NTFS) können NetApp Volumes die Zugriffsberechtigungen des Nutzers direkt prüfen oder erfordern, dass der Nutzer zuerst der Identität der anderen Plattform zugeordnet wird.

Zugriffsprotokoll	Sicherheitsstil	Vom Protokoll verwendete Identität	Erforderliche Zuordnung
NFSv3	UNIX	Nutzer-ID und Gruppen-ID	–
NFSv3	NTFS	Nutzer-ID und Gruppen-ID	Nutzer-ID zu Nutzername zu Sicherheits-ID
KMU	UNIX	Sicherheits-ID	Sicherheits-ID zu Nutzername zu Nutzer-ID
KMU	NTFS	Sicherheits-ID	–

Wenn eine Zuordnung erforderlich ist, werden in NetApp Volumes Daten aus Active Directory LDAP verwendet. Weitere Informationen finden Sie unter Active Directory-Anwendungsfälle.

Szenario für die Zuordnung von Multi-Protokoll-Nutzern: SMB-Zugriff auf ein UNIX-Volume

Wissenschaftler Charlie E. charliee möchte über SMB von einem Windows-Client aus auf ein NetApp Volumes-Volume zugreifen. Da das Volume maschinell generierte Ergebnisse enthält, die von einem Linux-Rechencluster bereitgestellt werden, ist das Volume so konfiguriert, dass UNIX-Berechtigungen gespeichert werden.

Der Windows-Client sendet einen SMB-Aufruf an das Volume. Der SMB-Aufruf enthält die Nutzeridentität als Sicherheits-ID. Die Sicherheits-ID ist nicht mit den Dateiberechtigungen für Nutzer-ID und Gruppen-ID vergleichbar und muss zugeordnet werden.

Für die erforderliche Zuordnung führt NetApp Volumes die folgenden Schritte aus:

1. NetApp Volumes fordert Active Directory auf, die Sicherheits-ID in einen Nutzernamen aufzulösen, z. B. S-1-5-21-2761044393-2226150802-3019316526-1224 in charliee.

2. NetApp Volumes fordert Active Directory auf, die Nutzer-ID und Gruppen-ID für charliee zurückzugeben.

3. NetApp Volumes prüft den Zugriff anhand der Nutzer-ID und Gruppen-ID des Inhabers der Datei mit der zurückgegebenen Nutzer-ID und Gruppen-ID.

Szenario für die Multi-Protokoll-Nutzerzuordnung: NFS-Zugriff auf ein NTFS-Volume

Der Techniker Amal L. muss über einen Linux-Client mit NFS auf einige Daten auf einem Volume zugreifen. Da das Volume hauptsächlich zum Speichern von Windows-Daten verwendet wird, ist es mit dem NTFS-Sicherheitsstil konfiguriert.

Der Linux-Client sendet einen NFS-Aufruf an NetApp Volumes. Der NFS-Aufruf enthält Nutzer-ID- und Gruppen-ID-Kennungen, die ohne Zuordnung nicht mit einer Sicherheits-ID abgeglichen werden können.

Um die erforderliche Zuordnung abzuschließen, fragt NetApp Volumes den Nutzernamen der User-ID von Active Directory ab und gibt die Sicherheits-ID für den Nutzernamen zurück. Anschließend wird der Zugriff anhand der Sicherheits-ID des Eigentümers der aufgerufenen Datei mit der zurückgegebenen Sicherheits-ID geprüft.

Verschlüsselung während der Übertragung

Die Verschlüsselung bei der Übertragung schützt Daten vor dem Abfangen über ein Netzwerk. Der Traffic für die Volumereplikation, die integrierte Sicherung und die Volumemigration wird standardmäßig mit TLS 1.2 verschlüsselt. Für NFS- und SMB-Traffic können Sie protokollspezifische Verschlüsselungseinstellungen für zusätzlichen Schutz konfigurieren.

NFS

Verwenden Sie für NFS-Volumes NFSv4.1 mit aktivierter Kerberos-krb5p-Verschlüsselung, um maximale Sicherheit zu erzielen.

KMU

Aktivieren Sie für SMB-Volumes die AES-Verschlüsselung in Ihrer Active Directory-Richtlinie und die SMB-Verschlüsselung auf Ihrem Volume, um maximale Sicherheit zu erreichen.

Volume-Replikation

Mit NetApp Volumes können Volumes regionenübergreifend repliziert werden, um Daten zu schützen. Google Cloud Da sich der Traffic in der Google Cloudbefindet, schützt die Netzwerkinfrastruktur von Google den Übertragungsprozess. Der Zugriff ist eingeschränkt, um unbefugtes Abfangen zu verhindern. Außerdem wird der Replikationsverkehr mit FIPS 140-2-konformen TLS 1.2-Standards verschlüsselt.

Integrierte Sicherung

Bei einer integrierten Sicherung werden Sicherungen von NetApp Volumes innerhalb des Dienstes erstellt. Der Sicherungstraffic verbleibt in der Netzwerkinfrastruktur von Google und wird mit dem FIPS 140‑2-konformen TLS 1.2-Standard verschlüsselt. In den Backup Vaults können diese Sicherungen standardmäßig mit Google-managed encryption key oder mit einem kundenverwalteten Verschlüsselungsschlüssel (CMEK) für zusätzliche Sicherheit gespeichert werden.

Volume-Migration

Bei der Volume-Migration werden Daten vom Quellsystem ONTAP oder Cloud Volumes ONTAP an NetApp Volumes gesendet. Die Kommunikation zwischen dem Quellsystem und NetApp Volumes wird mit FIPS 140-2-konformen TLS 1.2-Standards verschlüsselt.

NetApp Volumes startet die Migration und verwendet die folgenden Protokolle und Ports:

• ICMP

• 10000/TCP

• 11104/TCP

• 11105/TCP

Achten Sie darauf, dass alle Firewalls zwischen der logischen Schnittstelle (LIF) Ihres ONTAP-Systems und der Migrations-IP-Adresse von NetApp Volumes diese Ports zulassen.

Nächste Schritte

NetApp-Volumes mit einem Dienstperimeter sichern