Sicherheitsaspekte

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

Sicherheitsaspekte für Netzwerke

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 Console, das Google Cloud SDK oder APIs verwalten. IAM-Rollen und -Berechtigungen schützen diese Schicht. Weitere Informationen zur Sicherheit auf Projektebene finden Sie unter IAM-Berechtigungen einrichten.

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

    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 Ihr VPC möglich, es sei denn, Sie verwenden ausdrücklich eine Drittanbieterlösung, 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 Volumezugriff

Firewallregeln schützen die VPC von Google Cloud . Wenn Sie den Zugriff von Clients auf NetApp Volumes ermöglichen möchten, müssen Sie bestimmten Netzwerkverkehr zulassen.

Firewallregeln für den Zugriff auf NFS-Volumes

NFS verwendet verschiedene Ports, um zwischen dem Client und einem Server zu kommunizieren. Damit die Kommunikation ordnungsgemäß funktioniert und Volumes erfolgreich bereitgestellt werden können, müssen Sie Ports auf Ihren Firewalls aktivieren.

NetApp Volumes fungiert als NFS-Server und stellt die für NFS erforderlichen Netzwerkports bereit. Ihre NFS-Clients müssen 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 beim Netzwerk-Peering zugewiesen haben. Weitere Informationen finden Sie unter CIDR-Bereich auswählen.

Verwendung von richtlinienbasierten Sperren mit NFSv3

Wenn Sie beratende Sperren mit NFSv3 verwenden, müssen Sie den rpc.statd-Daemon auf Ihrem Client ausführen, um Network Lock Manager zu unterstützen. Diese Funktion arbeitet in Zusammenarbeit mit NFS, um eine System V-Sperrung von Dateien und Einträgen über das Netzwerk bereitzustellen. Ihr NFS-Client muss einen Eingangsport öffnen, damit rpc.statd Network Lock Manager-Callbacks empfangen kann. 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. Um rpc.statd sicherer für Firewalls zu machen, konfigurieren Sie es so, dass es einen statischen Port verwendet.

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

Wenn Sie keine NFSv3-beratenden Sperren oder 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 stellt die für SMB erforderlichen Netzwerkports bereit. Achten Sie darauf, dass Ihr SMB-Client mit den folgenden NetApp Volumes-Ports kommunizieren darf:

  • 445 TCP SMB2/3

  • 135 TCP msrpc und 40001 TCP SMB CA: Nur für SMB 3.x-freigaben, die kontinuierlich verfügbar sind. Diese Ports sind für nicht kontinuierlich verfügbare Freigaben nicht erforderlich.

Der Dienst gibt Port 139/TCP frei, verwendet ihn aber nicht.

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

Ihre SMB-Clients müssen keine Eingangsport-Ports freigeben, damit SMB funktioniert.

Firewallregeln für den Active Directory-Zugriff

Öffnen Sie die folgenden Ports auf allen Ihren Active Directory-Domaincontrollern für Traffic aus dem CIDR-Bereich für 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

Firewall-Tag an Active Directory-Server anhängen

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

  1. Hängen Sie das Firewall-Tag an Ihre Active Directory-Server an:

    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

    Ersetzen Sie die folgenden Informationen:

    • NETAPP_VOLUMES_CIDR: Das CIDR-Netzwerk von NetApp Volumes

    • VPC_NAME: Der Name der VPC

  2. 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 einzigen Exportrichtlinie mit bis zu 20 Exportregeln. Exportregeln sind kommagetrennte Listen von IPv4-Adressen und IPv4-CIDRs, die angeben, welche Clients Volumes bereitstellen dürfen. NetApp Volumes wertet Exportregeln in sequenzieller Reihenfolge aus und beendet die Auswertung nach der ersten Übereinstimmung. Wir empfehlen, Exportregeln von den spezifischen bis zu den generischen zu sortieren, um die besten Ergebnisse zu erzielen.

Auf den folgenden Tabs finden Sie Richtlinien nach NFS-Versionen:

NFS ohne Kerberos

Alle NFS-Versionen ohne Kerberos verwenden die Sicherheitsvariante AUTH_SYS. In diesem Modus müssen Sie die Exportregeln streng verwalten, damit nur vertrauenswürdige Clients zugelassen werden, die die Integrität der Nutzer- und Gruppen-IDs gewährleisten können.

Als Sicherheitsmaßnahme ordnen NFS-Server NFS-Aufrufe mit UID=0 (root) automatisch UID=65535 (anonym) zu, das nur eingeschränkte Berechtigungen für das Dateisystem hat. Sie können die Option „Root-Zugriff“ beim Erstellen des Volumes aktivieren, um dieses Verhalten zu steuern. Wenn Sie den Root-Zugriff aktivieren, bleibt die Nutzer-ID 0 gleich.0 Erstellen Sie als Best Practice eine spezielle Exportregel, die den Root-Zugriff für Ihre bekannten Administratorhosts aktiviert und den Root-Zugriff für alle anderen Clients deaktiviert.

NFSv4.1 mit Kerberos

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

  • Nur Kerberos (krb5)

  • Kerberos-Signatur (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 erfordert eine Authentifizierung bei Active Directory. Mit diesen Berechtigungen können Sie festlegen, wer über das Netzwerk auf Freigaben zugreifen kann.

Volumes werden mit den Berechtigungen Alle und Vollzugriff auf Freigabeebene erstellt. Sie können Berechtigungen auf Freigabeebene mit der Windows-Konsole oder der Windows-Befehlszeile ändern.

So ändern Sie die Berechtigungen auf SMB-Freigabeebene mit der Windows-Konsole oder der Windows-Befehlszeile:

Windows-Konsole

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

  2. Klicken Sie in der geöffneten Konsole Computerverwaltung auf Aktion > Mit einem anderen Computer verbinden.

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

  4. Sobald Sie mit der Dateifreigabe verbunden sind, rufen Sie Systemtools > Freigegebene Ordner > Freigaben auf, um die Freigabe aufzurufen.

  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 Systemtools > Freigegebene Ordner > Freigaben auf, um die Freigabe aufzurufen.

  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 Zugriffssteuerung auf Dateiebene für NetApp-Volumes.

Sicherheitsstil für Volume

NetApp Volumes bietet zwei Sicherheitsstile für Volumes, UNIX und NTFS, um den verschiedenen Berechtigungssätzen von Linux- und Windows-Plattformen gerecht zu werden.

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

  • NTFS: Bei Volumes, die mit dem NTFS-Sicherheitsstil konfiguriert sind, wird der Dateizugriff mit NTFS-ACLs gesteuert.

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

Protokolltyp Sicherheitsstil für Volume
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 dualen Protokollen können Sie den Sicherheitsstil nur bei der Volumeerstellung auswählen.

NFS-Zugriffssteuerung auf Dateiebene für Volumes im UNIX-Format

Nachdem ein Client ein Volume bereitgestellt hat, prüft NetApp Volumes die Zugriffsberechtigungen für Dateien und Verzeichnisse mit dem standardmäßigen UNIX-Berechtigungsmodell, den sogenannten Modebits. Sie können Berechtigungen mit chmod festlegen und ändern.

Für NFSv4.1-Volumes können auch NFSv4-Zugriffssteuerungslisten (ACLs) verwendet werden. Wenn eine Datei oder ein Verzeichnis sowohl Modusbits als auch eine NFSv4-ACL hat, wird die ACL für die Berechtigungsprüfung verwendet. Dasselbe gilt für Volumes, bei denen sowohl NFSv3- als auch NFSv4.1-Protokolltypen verwendet werden. Sie können NFSv4-ACLs mit nfs4_getfacl und nfs4_setfacl festlegen und ändern.

Wenn Sie ein neues Volume im UNIX-Format erstellen, hat root:root die Inhaberschaft des Root-Inodes und die Berechtigungen 0770. Aufgrund dieser Inhaber- und Berechtigungseinstellung erhält ein nicht als Root anmeldender Nutzer nach dem Bereitstellen beim Zugriff auf das Volume einen permission denied-Fehler. Wenn Sie Nutzern, die keinen Root-Zugriff haben, Zugriff auf das Volume gewähren möchten, muss ein Root-Nutzer die Eigentümerschaft des Root-Inodes mit chown und die Dateiberechtigungen mit chmod ändern.

SMB-Dateizugriffssteuerung für NTFS-Volumes

Für Volumes im NTFS-Format empfehlen wir die Verwendung eines NTFS-Berechtigungsmodells. Jede Datei und jedes Verzeichnis hat eine NTFS-ACL, die Sie über den Datei-Explorer, das icacls-Befehlszeilentool oder PowerShell ändern können. Im NTFS-Berechtigungsmodell übernehmen neue Dateien und Ordner die Berechtigungen des übergeordneten Ordners.

Nutzerzuordnung für mehrere Protokolle

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

Wenn Sie ein SMB- und NFS-Volume mit zwei Protokollen erstellen, wird dringend empfohlen, 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 dient. Wenn dieser Nutzer nicht gefunden wird, wird der Zugriff auf den NFS-Aufruf verweigert.

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

  • uid = pcuser

  • uidnumber = 65534

  • cn = pcuser

  • gidNumber = 65534

  • objectClass = user

Je nach dem vom Client verwendeten Protokoll (NFS oder SMB) und dem Sicherheitsstil des Volumes (UNIX oder NTFS) können NetApp-Volumes die Zugriffsberechtigungen des Nutzers direkt prüfen oder der Nutzer muss zuerst der Identität der anderen Plattform zugeordnet werden.

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 Nutzernamen zu Nutzer-ID
KMU NTFS Sicherheits-ID –

Wenn eine Zuordnung erforderlich ist, verwendet NetApp Volumes Daten, die in Active Directory LDAP gespeichert sind. Weitere Informationen finden Sie unter Anwendungsfälle für Active Directory.

Szenario für die Multiprotokoll-Nutzerzuordnung: SMB-Zugriff auf ein UNIX-Volume

Wissenschaftler Charlie E. (Charlie) möchte über SMB von einem Windows-Client auf ein NetApp-Volume zugreifen. Da das Volume von einem Linux-Rechencluster bereitgestellte maschinengenerierte Ergebnisse enthält, ist es für das Speichern von UNIX-Berechtigungen konfiguriert.

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 der Nutzer-ID und der Gruppen-ID vergleichbar und muss zugeordnet werden.

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

  1. NetApp Volumes bittet Active Directory, 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- und Gruppen-ID für charliee zurückzugeben.

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

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

Der Entwickler 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-IDs und Gruppen-IDs, die ohne Zuordnung nicht mit einer Sicherheits-ID abgeglichen werden können.

Um die erforderliche Zuordnung vorzunehmen, fragt NetApp Volumes Active Directory nach dem Nutzernamen der User-ID und der Rückgabe der Sicherheits-ID für den Nutzernamen. Anschließend wird der Zugriff anhand der zurückgegebenen Sicherheits-ID mit der Sicherheits-ID des Eigentümers der zugegriffenen Datei verglichen.

Verschlüsselung während der Übertragung

NFS

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

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 für maximale Sicherheit zu sorgen.

Volume-Replikation

NetApp-Volumes können Volumes in Google Cloud -Regionen replizieren, um den Datenschutz zu verbessern. Da sich der Traffic in der Google Cloudbefindet, ist der Übertragungsprozess sicher, da die Netzwerkinfrastruktur von Google verwendet wird, die nur eingeschränkten Zugriff hat, um unbefugtes Abfangen zu verhindern. Außerdem wird der Replikationstraffic mit FIPS 140-2-konformen TLS 1.2-Standards verschlüsselt.

Integrierte Sicherung

Bei einer integrierten Sicherung werden NetApp-Volumes im Rahmen des Dienstes gesichert. Der Sicherungstraffic bleibt mithilfe der FIPS 140-2-konformen TLS 1.2-Standardverschlüsselung innerhalb der sicheren Netzwerkinfrastruktur von Google. Außerdem werden diese Sicherungen in den Sicherungsspeichern mit einem Verschlüsselungsschlüssel gespeichert, der von Google verwaltet wird und auf Google Cloud basiert. So wird für zusätzliche Sicherheit gesorgt.

Nächste Schritte

NetApp-Volumes mit einem Dienstperimeter sichern