Google Cloud NetApp Volumes Architektur
Änderungen vorschlagen
PDFs
In ähnlicher Weise wie andere native Google Cloud Services wie CloudSQL, Google Cloud VMware Engine (GCVE) und FileStore verwendet Google Cloud NetApp Volumes "Google PSA" für die Bereitstellung des Service. In PSA werden Services innerhalb eines Service-Producer-Projekts aufgebaut, das eine Verbindung zum Service-Verbraucher herstellt "VPC-Netzwerk-Peering". Der Serviceanbieter wird von NetApp bereitgestellt und betrieben, der Servicekunde ist eine VPC in einem Kundenprojekt, in dem die Clients, die auf die Dateifreigaben von Google Cloud NetApp Volumes zugreifen möchten, gehostet werden.
Die folgende Abbildung, die in der Dokumentation von Google Cloud NetApp Volumes referenziert "Abschnitt zur Architektur" wird, zeigt eine allgemeine Ansicht.
Der Teil über der gepunkteten Linie zeigt die Kontrollebene des Services an, der den Volumenlebenszyklus steuert. Der Teil unterhalb der gepunkteten Linie zeigt die Datenebene. Das linke blaue Feld zeigt die Benutzer-VPC (Service-Verbraucher), das rechte blaue Feld ist der von NetApp bereitgestellte Service-Hersteller. Beide sind über VPC-Peering verbunden.
Tenancy-Modell
In Google Cloud NetApp Volumes gelten einzelne Projekte als eindeutige Mandanten. Das bedeutet, dass Manipulationen von Volumes, Snapshot Kopien usw. pro Projekt durchgeführt werden. Das heißt, alle Volumes sind im Besitz des Projekts, in dem sie erstellt wurden. Nur das Projekt kann standardmäßig die darin enthaltenen Daten managen und darauf zugreifen. Dies wird als Ansicht der Kontrollebene des Services betrachtet.
Gemeinsam genutzte VPCs
In der Ansicht der Datenebene können sich Google Cloud NetApp Volumes mit einer gemeinsamen VPC verbinden. Sie können Volumes im Hosting-Projekt oder in einem der Service-Projekte erstellen, die mit der gemeinsam genutzten VPC verbunden sind. Alle mit dieser gemeinsamen VPC verbundenen Projekte (Host oder Service) sind in der Lage, die Volumes auf der Netzwerkebene (TCP/IP) zu erreichen. Da alle Clients mit Netzwerkkonnektivität auf der gemeinsam genutzten VPC potenziell über NAS-Protokolle auf die Daten zugreifen können, muss die Zugriffssteuerung für das individuelle Volume (z. B. User-/Group-Zugriffssteuerungslisten (ACLs) und Hostnamen/IP-Adressen für NFS-Exporte) verwendet werden, um zu kontrollieren, wer auf die Daten zugreifen kann.
Google Cloud NetApp Volumes können mit bis zu fünf VPCs pro Kundenprojekt verbunden werden. In der Kontrollebene können Sie mit dem Projekt alle erstellten Volumes managen – unabhängig von der VPC, mit der sie verbunden sind. Auf der Datenebene sind VPCs voneinander isoliert, wobei jedes Volume nur mit einer VPC verbunden werden kann.
Der Zugriff auf einzelne Volumes wird über protokollspezifische Zugriffskontrollmechanismen (NFS/SMB) gesteuert.
Das bedeutet, dass auf der Netzwerkebene alle mit der gemeinsam genutzten VPC verbundenen Projekte in der Lage sind, das Volume zu sehen, während auf der Managementseite nur die Kontrollebene es dem Owner-Projekt erlaubt, das Volume zu sehen.
VPC-Service-Kontrollen
VPC-Service-Kontrollen einrichten eine Zugriffskontrollumgebung um Google Cloud Services herum, die mit dem Internet verbunden sind und weltweit zugänglich sind. Diese Dienste bieten Zugriffskontrolle über Benutzeridentitäten, können aber nicht einschränken, aus welchen Netzwerkstandortanforderungen stammen. Die VPC-Service-Kontrollen schließen diese Lücke, indem sie Funktionen zur Einschränkung des Zugriffs auf definierte Netzwerke einführen.
Die Datenebene von Google Cloud NetApp Volumes ist nicht mit dem externen Internet verbunden, sondern mit privaten VPCs mit klar definierten Netzwerkgrenzen (Perimeter). Innerhalb dieses Netzwerks verwendet jedes Volume eine protokollspezifische Zugriffssteuerung. Jegliche externe Netzwerkverbindung wird explizit von Google Cloud-Projektadministratoren erstellt. Die Kontrollebene bietet jedoch nicht den gleichen Schutz wie die Datenebene und kann von überall aus mit gültigen Zugangsdaten aufgerufen werden ( "JWT-Token").
Kurz gesagt: Die Datenebene von Google Cloud NetApp Volumes ermöglicht die Netzwerkzugriffskontrolle – ohne die Unterstützung von VPC-Servicekontrollen und ohne ausdrückliche Nutzung der VPC-Servicekontrollen.
Überlegungen zu Packet Sniffing/Trace
Paketerfassungen können für die Behebung von Netzwerkproblemen oder anderen Problemen (z. B. NAS-Berechtigungen, LDAP-Konnektivität usw.) nützlich sein, können aber auch missverständlich verwendet werden, um Informationen über Netzwerk-IP-Adressen, MAC-Adressen, Benutzer- und Gruppennamen und die Sicherheitsstufe für Endpunkte zu erhalten. Aufgrund der Art und Weise, wie Google Cloud-Netzwerke, VPCs und Firewall-Regeln konfiguriert werden, sollte ein unerwünschter Zugriff auf Netzwerkpakete ohne Benutzeranmeldung oder nur schwer zu erhalten sein "JWT-Token" In Cloud-Instanzen integriert. Paketerfassungen sind nur auf Endpunkten (z. B. Virtual Machines (VMs) möglich und nur in Endpunkten innerhalb der VPC möglich, es sei denn, ein Shared VPC und/oder ein externer Netzwerktunnel/IP-Weiterleitung wird verwendet, um explizit externen Traffic zu Endpunkten zu erlauben. Es gibt keine Möglichkeit, den Verkehr außerhalb der Kunden zu schnuppern.
Bei der Verwendung gemeinsam genutzter VPCs kann die Verschlüsselung während des Fluges mit NFS Kerberos und/oder "SMB-Verschlüsselung"viele der von Traces gewonnenen Informationen maskieren. Allerdings wird ein Teil des Verkehrs immer noch in Klartext gesendet, wie "DNS" und "LDAP-Abfragen". Die folgende Abbildung zeigt die Paketerfassung einer LDAP-Abfrage im Klartext aus Google Cloud NetApp Volumes sowie die potenziellen identifizierenden offengelegten Informationen. LDAP-Abfragen in Google Cloud NetApp Volumes unterstützen derzeit keine Verschlüsselung bzw. LDAP über SSL. NetApp Volumes-Performance unterstützt LDAP-Signing, sofern von Active Directory angefordert. NetApp Volumes-SW unterstützt LDAP-Signing nicht.
|
UnixUserPassword wird von LDAP abgefragt und nicht im Klartext, sondern in einem gesalzenem Hash gesendet. Standardmäßig füllt Windows LDAP die Felder unixUserPassword nicht aus. Dieses Feld ist nur erforderlich, wenn Sie Windows LDAP für interaktive Anmeldungen über LDAP für Clients verwenden müssen. Google Cloud NetApp Volumes unterstützt keine interaktiven LDAP-Anmeldungen bei den Instanzen. |
Die folgende Abbildung zeigt eine Paketerfassung aus einem NFS-Kerberos-Gespräch neben einer NFS-Erfassung über AUTH_SYS. Beachten Sie, wie sich die Informationen in einer Kurve zwischen den beiden unterscheiden und wie die Aktivierung der Verschlüsselung während der Übertragung eine größere Gesamtsicherheit für den NAS-Datenverkehr bietet.
VM-Netzwerkschnittstellen
Angreifer können versuchen, eine neue Netzwerkschnittstellenkarte (NIC) zu einer VM in hinzuzufügen "Promiskuous Modus" (Port-Spiegelung) oder aktivieren Sie den Promiskuus-Modus auf einer vorhandenen NIC, um den gesamten Datenverkehr zu entschnüffeln. Beim Hinzufügen einer neuen NIC muss in Google Cloud eine VM vollständig heruntergefahren werden, was zu Warnmeldungen führt. So können Angreifer nicht unbemerkt das tun.
Darüber hinaus können NICs überhaupt nicht auf den promiskuitiven Modus eingestellt werden und erzeugen in Google Cloud Warnmeldungen.