Sicherheitsaspekte

Auf dieser Seite finden Sie einen Überblick über die Sicherheitsaspekte von Google Cloud NetApp Volumes.

Sicherheitsaspekte für die Vernetzung

Google Cloud NetApp Volumes bietet ein sicheres 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) verwendet wird, z. B. Server Message Block (SMB) und Network File System (NFS).

    Sie können über ein Virtual Private Cloud-Netzwerk 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 Zugriffskontrollmechanismen 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.

Firewallregeln für den Zugriff auf NFS-Volumes

NFS verwendet verschiedene Ports für die Kommunikation zwischen dem Client und einem Server. Damit die Kommunikation ordnungsgemäß funktioniert und die Volume-Einbindung erfolgreich ist, müssen Sie Ports in Ihren Firewalls aktivieren.

NetApp Volumes fungiert als NFS-Server und macht die für NFS erforderlichen Netzwerkports verfügbar. Achten Sie darauf, dass Ihre NFS-Clients die Berechtigung haben, mit den folgenden NetApp Volumes-Ports zu kommunizieren:

  • 111 TCP/UDP portmapper

  • 635 TCP/UDP mountd

  • 2049 TCP/UDP nfsd

  • 4045 TCP/UDP nlockmgr (nur für NFSv3)

  • 4046 TCP/UDP status (nur für NFSv3)

Die IP-Adressen für NetApp-Volumes werden automatisch aus dem CIDR-Bereich zugewiesen, den Sie dem Dienst während des Netzwerk-Peerings zugewiesen haben. Weitere Informationen finden Sie unter CIDR auswählen.

Verwendung von Advisory Locks mit NFSv3

Wenn Sie mit NFSv3 Empfehlungssperren verwenden, müssen Sie den rpc.statd-Daemon auf Ihrem Client ausführen, um den Network Lock Manager zu unterstützen. Dieser arbeitet mit dem NFS zusammen, um eine Empfehlungssperre für Dateien und Datensätze im System V-Stil über das Netzwerk bereitzustellen. Ihr NFS-Client muss einen Ingress-Port für rpc.statd öffnen, um Network Lock Manager-Callbacks zu empfangen. In den meisten Linux-Distributionen wird rpc.statd gestartet, wenn Sie die erste NFS-Freigabe bereitstellen. Es wird ein zufälliger Port verwendet, den Sie mit dem Befehl rpcinfo -p ermitteln können. Damit rpc.statd besser mit Firewalls funktioniert, konfigurieren Sie es so, dass ein statischer Port verwendet wird.

Informationen zum Festlegen statischer Ports für rpc.statd finden Sie in den folgenden Ressourcen:

Wenn Sie keine NFSv3-Empfehlungssperren oder keinen Network Lock Manager verwenden, empfehlen wir, Ihre NFSv3-Freigaben mit der Bereitstellungsoption nolock bereitzustellen.

NFSv4.1 implementiert die Sperrfunktion im NFSv4.1-Protokoll selbst, das über die vom Client initiierte TCP-Verbindung zum NFSv4.1-Server auf Port 2049 ausgeführt wird. Der Kunde muss keine Firewallports für eingehenden Traffic öffnen.

Firewallregeln für den Zugriff auf SMB-Volumes

SMB verwendet verschiedene Ports für die Kommunikation zwischen dem Client und einem Server. Damit die Kommunikation ordnungsgemäß funktioniert, müssen Sie Ports in Ihren Firewalls aktivieren.

NetApp Volumes fungiert als SMB-Server und macht die für SMB erforderlichen Netzwerkports verfügbar. Prüfen Sie, ob Ihr SMB-Client mit den folgenden NetApp Volumes-Ports kommunizieren darf:

  • 445 TCP SMB2/3

  • 135 TCP msrpc und 40001 TCP SMB CA: Werden nur für kontinuierlich verfügbare SMB 3.x-Freigaben verwendet. Diese Ports sind für nicht kontinuierlich verfügbare Freigaben nicht erforderlich.

Der Dienst macht Port 139/TCP verfügbar, verwendet ihn aber nicht.

Die IP-Adressen für NetApp-Volumes werden automatisch aus dem CIDR-Bereich zugewiesen, den Sie dem Dienst während des Netzwerk-Peerings zugewiesen haben. Weitere Informationen finden Sie unter CIDR auswählen.

Ihre KMU-Kunden müssen keine Ingress-Ports öffnen, damit SMB funktioniert.

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

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

Lautstärkeregler 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 vom spezifischsten zum allgemeinsten zu sortieren.

Auf den folgenden Tabs finden Sie Richtlinien basierend auf NFS-Versionen:

NFS ohne Kerberos

Alle NFS-Versionen ohne Kerberos verwenden den Sicherheits-Flavor AUTH_SYS. In diesem Modus müssen Sie die Exportregeln genau verwalten, damit nur Clients, denen Sie vertrauen und die die Integrität von Nutzer- und Gruppen-IDs gewährleisten können, Daten exportieren dürfen.

Aus Sicherheitsgründen werden NFS-Aufrufe mit UID=0 (root) auf NFS-Servern automatisch UID=65535 (anonym) zugeordnet. Diese haben nur eingeschränkte Berechtigungen für das Dateisystem. Beim Erstellen des Volumes können Sie die Option „Root-Zugriff“ aktivieren, um dieses Verhalten zu steuern. Wenn Sie den Root-Zugriff aktivieren, bleibt die Nutzer-ID 0.0 Als Best Practice sollten Sie eine spezielle Exportregel erstellen, die Root-Zugriff für Ihre bekannten Administratorhosts ermöglicht und Root-Zugriff für alle anderen Clients deaktiviert.

NFSv4.1 mit Kerberos

NFSv4.1 mit Kerberos verwendet Exportrichtlinien und zusätzliche Authentifizierung mit Kerberos für den Zugriff auf Volumes. Sie können Exportregeln für Folgendes konfigurieren:

  • Nur Kerberos (krb5)

  • Kerberos-Signierung (krb5i)

  • Kerberos-Datenschutz (krb5p)

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

SMB verwendet Berechtigungen auf Freigabeebene, um den Volumezugriff 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 Freigabeberechtigungen für Alle und Vollzugriff 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.

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-Inode 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 einen permission denied-Fehler. 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 von einem Windows-Client aus über SMB 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

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 Active Directory nach dem Nutzernamen der User-ID und nach der Sicherheits-ID für den Nutzernamen. Anschließend wird der Zugriff anhand der Sicherheits-ID des Inhabers der aufgerufenen Datei mit der zurückgegebenen Sicherheits-ID geprüft.

Verschlüsselung während der Übertragung

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, ist der Übertragungsvorgang sicher, da er die Netzwerkinfrastruktur von Google nutzt, die nur eingeschränkten Zugriff bietet, um unbefugtes Abfangen zu verhindern. Außerdem wird der Replikations-Traffic mit FIPS 140‑2-konformen TLS 1.2-Standards verschlüsselt.

Integrierte Sicherung

Bei einer integrierten Sicherung werden Sicherungen von NetApp-Volumes im Dienst erstellt. Der Sicherungstraffic verbleibt in der sicheren Netzwerkinfrastruktur von Google und wird mit dem FIPS 140‑2-konformen TLS 1.2-Standard verschlüsselt. Außerdem werden diese Sicherungen in den Backup Vaults mit Google-owned and Google-managed encryption key gespeichert, um die Sicherheit zu erhöhen.

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