Adaptive Protection – Übersicht

Mit Google Cloud Armor Adaptive Protection können Sie Ihre Google Cloud Anwendungen, Websites und Dienste vor L7-DDoS-Angriffen (Distributed Denial-of-Service) wie HTTP-Floods und anderen hochfrequenten schädlichen Aktivitäten auf Layer 7 (Anwendungsebene) schützen. Adaptive Protection erstellt Modelle für maschinelles Lernen, die:

  1. Ungewöhnliche Aktivitäten erkennen und melden
  2. Eine Signatur für den potenziellen Angriff generieren
  3. Eine benutzerdefinierte Google Cloud Armor-WAF-Regel erstellen, um die Signatur zu blockieren

Sie aktivieren oder deaktivieren Adaptive Protection auf Basis einzelner Sicherheitsrichtlinien.

Benachrichtigungen über ungewöhnliche Zugriffe (potenzielle Angriffe), einschließlich der Signaturen der Angriffe, werden im Dashboard des Adaptive Protection-Ereignisses mit Ereignislogs angezeigt, die an Cloud Logging gesendet werden. Dort können sie direkt analysiert werden oder an einen nachgelagerten Monitoring-Workflow für Logs oder Sicherheitsereignisse weitergeleitet werden. Benachrichtigungen über potenzielle Angriffe werden auch als Ergebnisse im Security Command Center generiert.

Verfügbarkeit von Adaptive Protection

Benachrichtigungen vom Typ „Full Adaptive Protection“ sind nur verfügbar, wenn Sie Google Cloud Armor Enterprise abonnieren. Andernfalls erhalten Sie nur eine einfache Benachrichtigung. Eine einfache Benachrichtigung enthält nur minimale Informationen, z. B. einen Konfidenzwert für die Erkennung und die Größe des Angriffs. Eine einfache Benachrichtigung enthält keine Angriffssignatur oder vorgeschlagene Regel, die Nutzer bereitstellen können.

Wenn Ihre Projekte noch nicht für Cloud Armor Enterprise registriert sind, lesen Sie die Informationen unter Cloud Armor Enterprise verwenden.

Cloud Logging und Cloud Monitoring

Wenn Sie Adaptive Protection verwenden, müssen Sie genau wissen, wie Logging und Benachrichtigungen in Google Cloudfunktionieren. Sie sollten sich daher mit Cloud Logging, Benachrichtigungen und Benachrichtigungsrichtlinien vertraut machen.

Damit die Protokollierung und Berichterstellung ordnungsgemäß funktionieren, benötigt Cloud Armor Zugriff auf die folgenden Logs. Diese müssen in Cloud Logging gespeichert oder an einen Logging-Bucket weitergeleitet werden, auf den Cloud Armor zugreifen kann.

  • networksecurity.googleapis.com/dos_attack
  • networksecurity.googleapis.com/network_dos_attack
  • networksecurity.googleapis.com/network_dos_attack_mitigations

Benachrichtigungen konfigurieren und optimieren

Sie können Adaptive Protection in Projekten aktivieren, in denen Ihre Anwendungen bereits durch die Sicherheitsrichtlinien von Cloud Armor geschützt sind. Wenn Sie Adaptive Protection für eine bestimmte Sicherheitsrichtlinie aktivieren, ist Adaptive Protection für alle Back-End-Dienste wirksam, mit denen die Sicherheitsrichtlinie verknüpft ist.

Nach der Aktivierung von Adaptive Protection besteht ein Trainingszeitraum von mindestens einer Stunde, bevor Adaptive Protection eine zuverlässige Baseline erstellt und mit der Überwachung des Traffics und dem Generieren von Benachrichtigungen beginnt. Während des Trainingszeitraums modelliert Adaptive Protection eingehenden Traffic und Nutzungsmuster für jeden Backend-Dienst, sodass eine Baseline für jeden Backend-Dienst entwickelt wird. Wenn der Trainingszeitraum abgelaufen ist, erhalten Sie Benachrichtigungen in Echtzeit, wenn Adaptive Protection im Traffic für potenzielle Back-End-Dienste, die mit dieser Sicherheitsrichtlinie verknüpft sind, Anomalien in großen Mengen oder hohe Zugriffszahlen erkennt.

Sie können Benachrichtigungen von Adaptive Protection anhand verschiedener Messwerte optimieren. Die an Cloud Logging gesendeten Benachrichtigungen enthalten einen Konfidenzgrad, eine Angriffssignatur, eine vorgeschlagene Regel und eine geschätzte betroffene Baseline-Rate die mit der vorgeschlagenen Regel verknüpft ist.

  • Das Konfidenzniveau gibt an, mit welcher Zuverlässigkeit Adaptive Protection-Modelle vorhersagen, dass die beobachtete Änderung des Trafficmusters ungewöhnlich ist.
  • Die mit der vorgeschlagenen Regel verknüpften Raten der betroffenen Baseline geben den Prozentsatz des vorhandenen Baseline-Traffics an, der von der Regel erfasst wird. Es werden zwei Raten berechnet. Die erste ist der Prozentsatz des Traffics zu dem spezifischen Backend-Dienst, der angegriffen wird. Die zweite ist der Prozentsatz bezogen auf den gesamten Traffic, der über die Sicherheitsrichtlinie geleitet wird, einschließlich aller konfigurierten Backend-Dienstziele, nicht nur das, auf das angegriffen wird.

Sie können Benachrichtigungen in Cloud Logging nach dem Konfidenzniveau, den betroffenen Basispreisen oder beidem filtern. Weitere Informationen zum Optimieren von Benachrichtigungen finden Sie unter Benachrichtigungsrichtlinien verwalten.

Adaptive Protection soll Backend-Dienste vor volumetrischen Layer‑7-DDoS-Angriffen schützen. In den folgenden Szenarien werden Anfragen nicht in Adaptive Protection berücksichtigt:

  • Direkt von Cloud CDN bereitgestellte Anfragen
  • Von einer Cloud Armor-Sicherheitsrichtlinie abgelehnte Anfragen

Detaillierte Modelle

Standardmäßig erkennt Adaptive Protection einen Angriff und schlägt Schutzmaßnahmen basierend auf dem typischen Traffic vor, der an jeden Backend-Dienst gerichtet ist. Das bedeutet, dass ein Backend hinter einem Backend-Dienst überlastet werden kann, Adaptive Protection aber keine Maßnahmen ergreift, da der Angriffs-Traffic für den Backend-Dienst nicht anomal ist.

Mit der Funktion für detaillierte Modelle können Sie bestimmte Hosts oder Pfade als detaillierte Einheiten konfigurieren, die von Adaptive Protection analysiert werden. Wenn Sie detaillierte Modelle verwenden, filtert Adaptive Protection vorgeschlagene Maßnahmen zur Risikominderung anhand von übereinstimmenden Host- oder URL-Pfadpräfixen. So lassen sich Fehlalarme reduzieren. Jeder dieser Hosts oder Pfade wird als granulare Trafficeinheit bezeichnet.

Die erkannten Angriffssignaturen zielen nur auf den Angriffs-Traffic, der in die granulare Trafficeinheit gelangt. Die Filterung gilt jedoch weiterhin für alle Anfragen, die mit der bereitgestellten Regel übereinstimmen, wie ohne die granularen Konfigurationen. Wenn eine automatisch bereitgestellte Regel beispielsweise nur auf eine bestimmte Traffic-Granularitätseinheit angewendet werden soll, können Sie eine Abgleichsbedingung wie evaluateAdaptiveProtectionAutoDeploy() && request.headers['host'] == ... && request.path == ... verwenden.

Zusätzlich zu Host- und URL-Pfadpräfixen können Sie Benachrichtigungsschwellenwerte basierend auf einigen oder allen der folgenden Optionen konfigurieren. Sie können diese Schwellenwerte auf die detaillierten Trafficeinheiten oder auf den Backend-Dienst als Ganzes anwenden. Die Lastschwelle kann jedoch nur auf den Backend-Dienst angewendet werden:

  • Last: Die maximale Last für den Backend-Dienst gemäß dem konfigurierten Application Load Balancer. Diese Option ist für granulare Trafficeinheiten und für serverlose Back-Ends wie Cloud Run, Cloud Run Functions oder Back-Ends mit externen Ursprüngen nicht verfügbar.
  • Absolute Abfragen pro Sekunde (QPS): Die Spitzentrafficmenge in Abfragen pro Sekunde, die der Backend-Dienst oder die Trafficeinheit empfängt.
  • Im Verhältnis zu den Basisabfragen pro Sekunde: ein Vielfaches des durchschnittlichen langfristigen Basistraffic-Aufkommens. Ein Wert von 2 entspricht beispielsweise einer QPS, die doppelt so hoch ist wie das Baseline-Trafficvolumen.

Weitere Informationen zum Konfigurieren von detaillierten Modellen finden Sie unter Google Cloud Armor Adaptive Protection konfigurieren.

Benachrichtigungen nutzen und interpretieren

Wenn von Adaptive Protection ein Verdacht auf einen Angriff erkannt wird, wird im Ereignis-Dashboard von Adaptive Protection ein Ereignis generiert und in Cloud Logging wird ein Logelement generiert. Die Benachrichtigung befindet sich in der JSON-Nutzlast des Logelements. Das Logelement wird in Cloud Logging unter der Ressource Netzwerksicherheitsrichtlinie generiert. Die Lognachricht identifiziert den Back-End-Dienst unter Angriff und enthält einen Konfidenzwert, der angibt, wie stark Adaptive Protection die Änderung des erkannten Trafficmusters als anomal bewertet. Der Logeintrag enthält auch eine Angriffssignatur, die die Eigenschaften des Angriffstraffics und die vorgeschlagenen Cloud Armor-Regeln veranschaulicht, die Sie möglicherweise für die Reduzierung des Angriffs anwenden können.

Angriffssignaturen

Eine Warnung von Adaptive Protection enthält eine Angriffssignatur. Sie beschreibt die Traffic-Attribute des potenziellen Angriffs. Sie verwenden die Signatur, um den Angriff zu identifizieren und potenziell zu sperren. Die Signatur hat zwei Formen: als für Nutzer lesbare Tabelle und als vorgefertigte WAF-Regel für Cloud Armor, die Sie in der entsprechenden Sicherheitsrichtlinie bereitstellen können. Wenn Sie Cloud Armor Enterprise nicht abonniert haben, ist keine Angriffssignatur in der einfachen Benachrichtigung enthalten.

Die Signatur besteht aus einer Reihe von Attributen wie Client-IP-Adresse, geografischen Regionen, Cookies, User-Agents, Verweis-URLs und anderen HTTP-Anfrageheadern sowie aus den Werten dieser verknüpften Attribute durch den potenziellen Angriffstraffic. Das Set der Attribute ist nicht vom Nutzer konfigurierbar. Die Attributwerte hängen von den Werten im eingehenden Traffic an Ihren Backend-Dienst ab.

Für jeden Attributwert, der von Adaptive Protection als möglicher Angriff eingestuft wird, wird Folgendes angezeigt:

  • Die Angriffswahrscheinlichkeit
  • Der Anteil des Attributs im Angriff, d. h. der Prozentsatz des potenziellen Angriffstraffics, der diesen Wert zum Zeitpunkt der Erkennung des Angriffs hatte.
  • Der Anteil des Attributs in der Baseline, d. h. der Prozentsatz des Baseline-Traffics, der diesen Attributwert zum Zeitpunkt der Erkennung des Angriffs hatte.

Die Cloud Logging-Eintragsspezifikation enthält Details zu den Informationen in jeder Benachrichtigung.

Das folgende Beispiel zeigt eine für Nutzer lesbare Tabelle, die die Signatur eines potenziellen Angriffs enthält:

Attributname Wert Art der Übereinstimmung Angriffswahrscheinlichkeit Anteil im Angriff Anteil in der Baseline
UserAgent "foo" Genaue Übereinstimmung 0,7 0,85 0,12
UserAgent "bar"