Netzwerk-Monitoring- und Telemetriefunktionen in Google Cloud bereitstellen

Last reviewed 2024-02-13 UTC

Netzwerktelemetrie erfasst Netzwerk-Traffic-Daten von Geräten in Ihrem Netzwerk, damit die Daten analysiert werden können. Mit Netzwerktelemetrie können Security-Operations-Teams netzwerkbasierte Bedrohungen erkennen und nach Hackern suchen, was für autonome Sicherheitsvorgänge wichtig ist. Zum Abrufen von Netzwerktelemetrie müssen Sie Netzwerkdaten erheben und speichern. Dieser Blueprint beschreibt, wie Sie mit Paketspiegelung und Zeek Netzwerkdaten in Google Cloud erheben können.

Dieser Entwurf ist für Sicherheitsanalysten und Netzwerkadministratoren gedacht, die Netzwerktraffic spiegeln sowie diese Daten speichern und zur Analyse weiterleiten möchten. Dabei wird vorausgesetzt, dass Sie mit Netzwerken und Netzwerkmonitoring vertraut sind.

Dieser Blueprint ist Teil eines Sicherheits-Blueprints, das sich aus folgenden Komponenten zusammensetzt:

  • Einem GitHub-Repository, das eine Reihe von Terraform-Konfigurationen und -Skripts enthält.
  • Einer Anleitung zu den Architektur-, Design- und Sicherheitskontrollen, die Sie mit diesem Blueprint implementieren (dieses Dokument).

Mit diesem Blueprint erfassen Sie Netzwerkpakete (einschließlich Netzwerkmetadaten) mithilfe der Paketspiegelung, transformieren die Netzwerkpakete in Zeek-Logs und speichern sie dann in Cloud Logging. Der Blueprint extrahiert Metadaten wie IP-Adressen, Ports, Protokolle sowie Layer-7-Header und -Anfragen. Da beim Speichern von Netzwerkmetadaten als Zeek-Logs ein geringeres Datenvolumen als beim Speichern von Rohpaketdaten verbraucht wird, ist der Kostenaufwand geringer.

In diesem Dokument wird davon ausgegangen, dass Sie bereits einen grundlegenden Satz von Sicherheitskontrollen konfiguriert haben, wie im Leitfaden zu Google Cloud-Unternehmensgrundlagen beschrieben.

Unterstützte Anwendungsfälle

Dieser Blueprint unterstützt die folgenden Anwendungsfälle:

  • Ihr Security Operations Center (SOC) benötigt Zugriff auf Google Cloud-Netzwerklogdaten an einem zentralen Ort, damit Sicherheitsvorfälle untersucht werden können. Dieser Blueprint übersetzt Netzwerkpaketdaten in Logs, die Sie an Ihre Analyse- und Prüftools weiterleiten können. Zu den Analyse- und Prüftools gehören BigQuery, Google Security Operations, Flowmon und ExtraHop oder Security Information and Event Management (SIEM).
  • Ihre Sicherheitsteams benötigen Einblick in Google Cloud-Netzwerke, um Bedrohungen mithilfe von Tools wie Google SecOps aufdecken zu können. Mit diesem Blueprint können Sie eine Pipeline für Google Cloud-Netzwerktraffic erstellen.
  • Sie möchten zeigen, wie Ihre Organisation die Compliance-Anforderungen für die Netzwerkerkennung und -abwehr erfüllt. Beispielsweise muss Ihre Organisation die Einhaltung des Memorandum M-21-31 der US-Bundesbehörde "Office of Management and Budget (OMB)" nachweisen.
  • Ihre Netzwerksicherheitsanalysten benötigen langzeit-Netzwerklogdaten. Dieser Blueprint unterstützt sowohl das langfristige Monitoring als auch das On-Demand-Monitoring.

Wenn Sie auch Paketerfassungsdaten (pcap) benötigen, müssen Sie Netzwerkprotokoll-Analysetools verwenden (z. B. Wireshark oder tcpdump). Die Verwendung von Netzwerkprotokoll-Analysetools wird in diesem Blueprint nicht behandelt.

Sie können diesen Blueprint nicht mit dem Cloud Intrusion Detection System bereitstellen. Sowohl diese Lösung als auch das Cloud Intrusion Detection System verwenden Richtlinien für die Paketspiegelung. Diese Richtlinien können nur von einem Dienst auf einmal verwendet werden.

Kosten

Dieser Blueprint kann Ihre Kosten beeinflussen, da Sie in Cloud Logging Rechenressourcen hinzufügen und große Datenmengen speichern. Beachten Sie beim Bereitstellen des Blueprints Folgendes:

  • Jede Collector-VM (virtuelle Maschine) in Compute Engine wird als e2-medium-Instanz ausgeführt.
  • Sie können die Speicherkosten so steuern:
    • Paketspiegelungsfilter verwenden.
    • Keine zonenübergreifende Spiegelung, um Gebühren für ausgehenden interzonalen Traffic zu vermeiden.
    • Daten nur so lange speichern, wie sie von Ihrer Organisation benötigt werden.

Mit dem Preisrechner können Sie eine Schätzung Ihrer Computing-, Logging- und Speicherkosten abrufen.

Architektur

Das folgende Architekturdiagramm zeigt die Infrastruktur, mit der Sie diesen Blueprint implementieren:

Die Architektur der Netzwerktelemetrie.

Die in der vorherigen Abbildung gezeigten Architektur verwendet eine Kombination aus den folgenden Google Cloud-Diensten und -Funktionen:

  • Zwei VPC-Netzwerke (Virtual Private Cloud):

    • Ein VPC-Netzwerk (Virtual Private Cloud) für die gespiegelten Quellen.
    • Ein VPC-Netzwerk für die Collector-Instanzen.

    Diese VPC-Netzwerke müssen sich im selben Projekt befinden.

  • Compute Engine- oder GKE (Google Kubernetes Engine)-Instanzen (sogenannte gespiegelte Quellen) in bestimmten Regionen und Subnetze, die die Quelle für die Netzwerkpakete sind. Mit einer der folgenden Methoden ermitteln Sie, welche Instanzen gespiegelt werden sollen:

  • Compute Engine-Instanzen, die als Collector-Instanzen hinter einem internen Passthrough-Network Load Balancer in derselben Region wie die gespiegelten Quellen fungieren. Auf diesen Instanzen wird das Zeek-Fluentd Golden Image oder Ihr benutzerdefiniertes zeek-fluentd-Image ausgeführt. Die VMs sind e2-medium und der unterstützte Durchsatz beträgt 4 Gbit/s.

  • Ein interner Passthrough-Network Load Balancer, der Pakete von den gespiegelten Quellen empfängt und zur Verarbeitung an die Collector-Instanzen weiterleitet. Die Weiterleitungsregel für den Load-Balancer verwendet das Flag --is-mirroring-collector.

  • VPC-Firewallregeln, die Folgendes zulassen:

    • Ausgehender Traffic von gespiegelten Quellen zum internen Passthrough-Network Load Balancer.
    • Eingehender Traffic von den Collector-Instanzen zu den gespiegelten Instanzen.

  • Eine Paketspiegelungsrichtlinie, die die Region, das Subnetz, die gespiegelten Instanzen, Protokolle, Richtung und Weiterleitungsregel definiert. Für jede Region ist eine eigene Paketspiegelungsrichtlinie erforderlich.

  • VPC-Netzwerk-Peering, um Verbindungen über interne IP-Adressen zwischen hochverfügbaren Compute Engine-VMs in mehreren Regionen zu ermöglichen. Mit VPC-Netzwerk-Peering können die gespiegelten Quellen mit dem internen Passthrough-Network Load Balancer kommunizieren.

  • Eine Cloud Logging-Instanz, die alle Pakete zum Speichern und Abrufen durch ein Analyse- und Prüftool erfasst.

Erforderliche Sicherheitseinstellungen

In diesem Abschnitt werden die Sicherheitskontrollen in Google Cloud erläutert, mit denen Sie die verschiedenen Komponenten der Netzwerk-Monitoring-Architektur schützen können.

Sicherheitskontrollen für VM-Netzwerke

Sie erstellen VPC-Netzwerke um Ihre gespiegelten Quellen und Collectors. Wenn Sie das VPC-Netzwerk für die Collectors erstellen, löschen Sie die vom System generierte Standardroute. Das bedeutet, dass alle Standardrouten des Internetgateways deaktiviert sind. Das Deaktivieren von Standard-Internetgateways hilft, die Angriffsfläche Ihres Netzwerks für externe Bedrohungsangriffe zu reduzieren.

Sie erstellen in jedem VPC-Netzwerk Subnetze für jede Region. Mit Subnetzen können Sie den Traffic-Fluss zwischen Ihren Arbeitslasten in Google Cloud und auch von externen Quellen steuern. Für die Subnetze ist der private Google-Zugriff aktiviert. Durch den privaten Google-Zugriff kann außerdem die Angriffsfläche Ihres Netzwerks reduziert werden, während VMs mit Google APIs und Google-Diensten kommunizieren können.

Um die Kommunikation zwischen den VPC-Netzwerken zuzulassen, aktivieren Sie VPC-Netzwerk-Peering. VPC-Netzwerk-Peering verwendet Subnetzrouten für die Verbindungen interner IP-Adressen. Sie importieren und exportieren benutzerdefinierte Routen, um eine direkte Verbindung zwischen den gespiegelten Quellen und den Collectors zu ermöglichen. Sie müssen die gesamte Kommunikation auf regionale Routen beschränken, da der interne Passthrough-Network Load Balancer für die Collectors keine globalen Routen unterstützt.

Firewallregeln

Mithilfe von Firewallregeln definieren Sie die Verbindungen, die die gespiegelten Quellen und Collectors erstellen können. Sie richten eine Regel für eingehenden Traffic ein, um regelmäßige Verfügbarkeitsdiagnosen, eine Regel für ausgehenden Traffic für alle Protokolle in den gespiegelten Quellen und eine Regel für eingehenden Traffic für alle Protokolle auf den Collectors zu ermöglichen.

Sicherheitskontrollen für Collector-VMs

Die Collector-VMs sind für den Empfang der Paketdaten zuständig. Die Collector-VMs sind identische VMs, die als verwaltete Instanzgruppen (Managed Instance Groups, MIGs) arbeiten. Sie aktivieren Systemdiagnosen, um die automatische Wiederherstellung einer nicht reagierenden VM zuzulassen. Darüber hinaus ermöglichen Sie den Collectors das Autoscaling basierend auf Ihren Nutzungsanforderungen.

Jede Collector-VM führt das zeek-fluentd-Packer-Image aus. Dieses Image besteht aus Zeeek, das die Logs generiert, und Fluentd, die die Logs an Cloud Logging weiterleitet. Nachdem Sie das Terraform-Modul bereitgestellt haben, können Sie die VM-Betriebssystem- und Zeek-Pakete aktualisieren und die Sicherheitseinstellungen anwenden, die für Ihre Organisation erforderlich sind.

Sicherheitseinstellungen für interne Load-Balancer

Der interne Passthrough-Network Load Balancer leitet den Netzwerkpaket-Traffic von den gespiegelten Quellen zur Verarbeitung an die Collector-VMs weiter. Alle Collector-VMs müssen in derselben Region ausgeführt werden wie der interne Passthrough-Network Load Balancer.

Die Weiterleitungsregel für den internen Passthrough-Network Load Balancer definiert, dass der Zugriff über alle Ports möglich ist, der globale Zugriff jedoch nicht erlaubt ist. Darüber hinaus definiert die Weiterleitungsregel diesen Load-Balancer als Collector für Spiegelungen, mithilfe des Flag --is-mirroring-collector.

Sie müssen keinen Load-Balancer zum Speichern einrichten, da jede Collector-VM Logs direkt in Cloud Logging hochlädt.

Paketspiegelung

Bei der Paketspiegelung müssen Sie die Instanzen bestimmen, die Sie spiegeln möchten. Die zu spiegelnden Instanzen können Sie anhand von Netzwerktags, Instanznamen oder dem Subnetz bestimmen, in dem sich die Instanzen befinden. Darüber hinaus können Sie den Traffic mit einer oder mehreren der folgenden Methoden weiter filtern:

  • Layer-4-Protokolle wie TCP, UDP oder ICMP.
  • IPv4-CIDR-Bereiche im IP-Header, z. B. 10.0.0.0/8.
  • Richtung des Traffics, den Sie spiegeln möchten, z. B. eingehend, ausgehend oder beides.

Dienstkonten und Zugriffssteuerung

Dienstkonten sind Identitäten, mit denen Google Cloud API-Anfragen in Ihrem Namen ausführen kann. Dienstkonten sorgen dafür, dass Nutzeridentitäten keinen direkten Zugriff auf Dienste haben.

Zum Bereitstellen des Terraform-Codes müssen Sie die Identität eines Dienstkontos übernehmen, das im Projekt die folgenden Rollen hat:

Die Collector-VMs benötigen ebenfalls dieses Dienstkonto, damit sie sich bei Google Cloud-Diensten authentifizieren sowie die Netzwerkpakete abrufen und an Cloud Logging weiterleiten können.

Empfehlungen zur Datenaufbewahrung

Sie können mit Aufbewahrungsregeln für Ihre Log-Buckets angeben, wie lange Ihre Netzwerklogs von Cloud Logging gespeichert werden sollen. Lesen Sie die regulatorischen Anforderungen Ihrer Organisation, um festzulegen, wie lange die Daten gespeichert werden sollen.

Logging und Prüfung

Mit Cloud Monitoring können Sie die Leistung der Collector-VMs analysieren und Benachrichtigungen für Verfügbarkeitsdiagnosen und Leistungsbedingungen wie CPU-Auslastung einrichten.

Mithilfe von Cloud-Audit-Logs können Sie den Administratorzugriff oder Änderungen an den Daten und Konfigurationen verfolgen. Audit-Logging wird von Compute Engine, Cloud Load Balancing und Cloud Logging unterstützt.

So exportieren Sie Monitoring-Informationen:

Zusammenfassung

So implementieren Sie die in diesem Dokument beschriebene Architektur:

  1. Stellen Sie eine sichere Referenz in Google Cloud bereit, wie im Leitfaden zu Google Cloud-Unternehmensgrundlagen beschrieben. Wenn Sie den Blueprint zu Unternehmensgrundlagen nicht bereitstellen möchten, muss Ihre Umgebung eine ähnliche Sicherheits-Baseline haben.
  2. Lesen Sie die Readme für den Blueprint und achten Sie darauf, dass Sie alle Voraussetzungen erfüllen.

  3. Stellen Sie in Ihrer Testumgebung eine der Beispielkonfigurationen für Netzwerktelemetrie bereit, um den Blueprint in Aktion zu sehen. Führen Sie im Rahmen des Testverfahrens die folgenden Schritte aus:

    1. Prüfen Sie, ob die Paketspiegelungsrichtlinien und Subnetze erstellt wurden.

    2. Prüfen Sie, ob Sie die Rolle Loganzeige (roles/logging.viewer) haben, und führen Sie einen curl-Befehl aus, um Ihre Logdaten aufzurufen. Beispiele:

      curl http://example.com/

      Sie sollten sehen, dass Logdaten in Cloud Logging gespeichert werden.

    3. Verwenden Sie Security Command Center, um die neu erstellten Ressourcen gemäß Ihren Compliance-Anforderungen zu scannen.

    4. Prüfen Sie, ob Ihr System die entsprechenden Netzwerkpakete erfasst und speichert, und optimieren Sie die Leistung je nach Bedarf.

  4. Stellen Sie den Blueprint in Ihrer Produktionsumgebung bereit.

  5. Verbinden Sie Cloud Logging mit SIEM oder Google SecOps, damit Ihre SOC- und Netzwerksicherheitsanalysten die neue Telemetrie in ihre Dashboards einbinden können.

Nächste Schritte