Google Cloud Armor Adaptive Protection – Übersicht

Mit dem Google Cloud Armor Adaptive Protection können Sie Ihre Google Cloud-Anwendungen, -Websites und -Dienste vor L7-Angriffen (Distributed Denial-of-Service, DDoS) wie HTTP-Floods und anderen hochfrequenten Schichten der Ebene 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

Vollständige Benachrichtigungen zu Adaptive Protection sind nur verfügbar, wenn Sie Google Cloud Armor Enterprise abonnieren. Andernfalls erhalten Sie nur eine einfache Benachrichtigung ohne Angriffssignatur oder die Möglichkeit, eine vorgeschlagene Regel bereitzustellen.

Wenn Ihre Projekte noch nicht für Cloud Armor Enterprise registriert sind, finden Sie unter Cloud Armor Enterprise verwenden Informationen zur Registrierung.

Cloud Logging und Cloud Monitoring

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

Benachrichtigungen konfigurieren und optimieren

Sie können Adaptive Protection in Projekten aktivieren, in denen Ihre Anwendungen bereits durch die Sicherheitsrichtlinien von Google 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 eingehende Traffic- und Nutzungsmuster für jeden Back-End-Dienst, sodass eine Baseline für jeden Back-End-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 Back-End-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.

Ziel von Adaptive Protection ist, Backend-Dienste vor Layer-7-DDoS-Angriffen mit hohem Volumen zu schützen. In den folgenden Szenarien werden Anfragen bei Adaptive Protection nicht gezählt:

  • Direkt von Cloud CDN bereitgestellte Anfragen
  • Anfragen, die von einer Google Cloud Armor-Sicherheitsrichtlinie abgelehnt wurden

Detaillierte Modelle

Standardmäßig erkennt Adaptive Protection einen Angriff und schlägt auf Grundlage des typischen Traffics, der an jeden Back-End-Dienst weitergeleitet wird, Maßnahmen vor. Das bedeutet, dass ein Back-End hinter einem Back-End-Dienst überlastet werden kann, Adaptive Protection jedoch keine Maßnahmen ergreift, da der Angriffstraffic nicht anomal für den Back-End-Dienst ist.

Mit dem Feature 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, filtern die von Adaptive Protection vorgeschlagenen Abhilfemaßnahmen den Traffic anhand übereinstimmender Host- oder URL-Pfadpräfixe, um falsch positive Ergebnisse zu reduzieren. Jeder dieser Hosts oder Pfade wird als detaillierte Trafficeinheit bezeichnet.

Die identifizierten Angriffssignaturen zielen nur auf den Angriffstraffic ab, der in die detaillierte Trafficeinheit eingeht. Die Filter gelten jedoch weiterhin für alle Anfragen, die von der bereitgestellten Regel übereinstimmen, genau wie ohne die detaillierten Konfigurationen. Wenn beispielsweise eine automatisch bereitgestellte Regel nur einer bestimmten Einheit für die Traffic-Details entsprechen soll, können Sie eine Abgleichsbedingung wie evaluateAdaptiveProtectionAutoDeploy() && request.headers['host'] == ... && request.path == ... verwenden.

Neben Host- und URL-Pfadpräfixen können Sie Benachrichtigungsgrenzwerte basierend auf einigen oder allen der folgenden Optionen konfigurieren. Sie können diese Schwellenwerte auf die detaillierten Traffic-Einheiten oder auf den Back-End-Dienst als Ganzes anwenden, mit Ausnahme des Lastschwellenwerts, der nur auf den Back-End-Dienst angewendet werden kann:

  • Last: Die maximale Last für den Back-End-Dienst gemäß dem konfigurierten Application Load Balancer. Diese Option ist nicht für detaillierte Trafficeinheiten und serverlose Back-Ends wie Cloud Run, Cloud Functions oder Back-Ends mit externem Ursprung verfügbar.
  • Absolute Abfragen pro Sekunde: Die maximale Trafficmenge in Abfragen pro Sekunde, die der Back-End-Dienst oder die Traffic-Einheit empfängt.
  • Relativ zur Baseline für die Abfragen pro Sekunde: ein Vielfaches des durchschnittlichen langfristigen Referenz-Traffic-Volumens. Beispielsweise steht ein Wert von 2 für eine Abfrage pro Sekunde, die doppelt so hoch wie das Ausgangsvolumen des Traffics ist.

Weitere Informationen zum Konfigurieren detaillierter Modelle finden Sie unter Google Cloud Armor Adaptive Protection konfigurieren.

Benachrichtigungen lesen 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. Die Log-Nachricht enthält auch eine Angriffssignatur, die die Eigenschaften des Angriffstraffics und die vorgeschlagenen Google 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 Google Cloud Armor, die Sie in der entsprechenden Sicherheitsrichtlinie bereitstellen können. Wenn Sie Cloud Armor Enterprise nicht abonniert haben, ist in der einfachen Benachrichtigung keine Angriffssignatur enthalten.

Die Signatur besteht aus einer Reihe von Attributen wie Quell-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 Back-End-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" Genaue Übereinstimmung 0,6 0,7 0,4
Quell-IP "a.b.c.d" Genaue Übereinstimmung 0,95 0,1 0,01
Quell-IP a.b.c.e Genaue Übereinstimmung 0,95 0,1 0,01
Quell-IP a.b.c.f Genaue Übereinstimmung 0,05 0,1 0,1
RegionCode Vereinigtes Königreich Genaue Übereinstimmung 0,64 0,3 0,1
RegionCode IN Genaue Übereinstimmung 0,25 0,2 0.3
RequestUri /urlpart Substring 0,7 0,85 0,12

Eine Adaptive Protection-Benachrichtigung und das relevante Cloud Logging-Ereignislog enthalten Folgendes:

  • Eine eindeutige Benachrichtigungs-ID oder alertID, die verwendet wird, um auf eine bestimmte Benachrichtigung zu verweisen, die Nutzerfeedback meldet (siehe unten).
  • Der angegriffene Back-End-Dienst oder backendService.
  • Der Konfidenzwert oder confidence, eine Zahl zwischen 0 und 1, die angibt, wie stark das Adaptive Protection-System das erkannte Ereignis als böswilligen Angriff bewertet.

Sie erhalten außerdem eine Reihe von Signaturen und Regeln zur Charakterisierung des erkannten Angriffs. Genauer gesagt stellt das Set eine Liste von headerSignatures bereit, die jeweils einem HTTP-Header entsprechen und eine Liste von significantValues für den spezifischen Header enthalten. Jeder signifikante Wert ist entweder ein beobachteter Headerwert oder ein Teilstring davon.

Hier eine Beispielsignatur:

...
headerSignatures: [
  0: {
   name: "Referer"
   significantValues: [
    0: {
     attackLikelihood: 0.95
     matchType: "MATCH_TYPE_EQUALS"
     proportionInAttack: 0.6
     proportionInBaseline: 0.01
     value: "foo.attacker.com"
    }
   ]
  }
...

Die Benachrichtigung besagt, dass der Wert foo.attacker.com im Header Referer wichtig ist, um den Angriff zu charakterisieren. Genauer gesagt: 60% des Angriffstraffics (proportionInAttack) hat den Referer-Wert und nur 1% des Baseline-Traffics unter dem gesamten Traffic (proportionInBaseline) hat den gleichen Referer-Wert. Darüber hinaus ist unter dem gesamten Traffic, der mit diesem Referer-Wert übereinstimmt, 95% ein Angriffstraffic (attackLikelihood).

Diese Werte schlagen vor, dass Sie bei einem Blockieren aller Anfragen mit foo.attacker.com im Headerfeld Referer 60 % des Angriffs und 1 % des Basistraffics blockieren würden.

Das Attribut matchType gibt die Beziehung zwischen dem Attribut im Angriffstraffic und dem signifikanten Wert an. Die Beziehung kann entweder MATCH_TYPE_CONTAINS oder MATCH_TYPE_EQUALS sein.

Mit der nächsten Signatur wird der Traffic mit einem Teilstring /api? im Anfrage-URI abgeglichen:

...
headerSignatures: [
  0: {
   name: "RequestUri"
   significantValues: [
    0: {
     attackLikelihood: 0.95
     matchType: "MATCH_TYPE_CONTAINS"
     proportionInAttack: 0.9
     proportionInBaseline: 0.01
     value: "/api?"
    }
   ]
  }
...

Vorgeschlagene Regeln bereitstellen

Adaptive Protection-Benachrichtigungen bieten auch eine vorgeschlagene Google Cloud Armor-Regel in der Sprache der benutzerdefinierten Regeln. Diese Regel kann zum Erstellen einer Regel in einer Google Cloud Armor-Sicherheitsrichtlinie verwendet werden, um den Angriff zu minimieren. Neben der Signatur enthält die Benachrichtigung auch eine Rate des beeinflussten Baseline-Traffics, damit Sie die Auswirkungen der Bereitstellung der Regel besser einschätzen können. Die Geschwindigkeit des betroffenen Baseline-Traffics ist ein prognostizierter Anteil des Baseline-Traffics, der der von Adaptive Protection ermittelten Angriffssignatur entspricht. Wenn Sie Cloud Armor Enterprise nicht abonniert haben, enthalten die von Adaptive Protection gesendeten grundlegenden Benachrichtigungen keine vorgeschlagene Google Cloud Armor-Regel, die Sie anwenden können.

Einige der Benachrichtigungssignaturen sowie die betroffene Baseline-Rate finden Sie in der Lognachricht, die an Cloud Logging gesendet wird. Das folgende Beispiel zeigt die JSON-Nutzlast einer Beispielbenachrichtigung zusammen mit den Ressourcenlabels, nach denen Sie die Logs filtern können.

...
 jsonPayload: {
   alertId: "11275630857957031521"
   backendService: "test-service"
   confidence: 0.71828485
   headerSignatures: [

    0: {
     name: "RequestUri"
     significantValues: [
      0: {
       attackLikelihood: 0.88
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.85
       proportionInBaseline: 0.01
       value: "/"
      }
     ]
    }
    1: {
     name: "RegionCode"
     significantValues: [
      0: {
       attackLikelihood: 0.08
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.17
       proportionInBaseline: 0.28
       value: "US"
      }
      1: {
       attackLikelihood: 0.68
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.09
       proportionInBaseline: 0.01
       value: "DE"
      }
      2: {
       attackLikelihood: 0.74
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.05
       proportionInBaseline: 0
       value: "MD"
      }
     ]
    }
     2: {
     name: "UserAgent"
     significantValues: [
      0: {
       attackLikelihood: 0.92
       matchType: "MATCH_TYPE_EQUALS"
       proportionInAttack: 0.85
       proportionInBaseline: 0
       value: "Unusual browser"
      }
      1: {
       attackLikelihood: 0.87
       proportionInAttack: 0.7
       proportionInBaseline: 0.1
       missing: true
      }
     ]
    }
   ]
   suggestedRule: [
    0: {
     action: "DENY"
     evaluation: {
       impactedAttackProportion: 0.95
       impactedBaselineProportion: 0.001
       impactedBaselinePolicyProportion: 0.001
     }
     expression: "evaluateAdaptiveProtection('11275630857957031521')"
    }
   ]
   ruleStatus: RULE_GENERATED
   attackSize: 5000
 }
 resource: {
    type: "network_security_policy",
    labels: {
      project_id: "your-project",
      policy_name: "your-security-policy-name"
    }
 },
}
}
...

Zum Bereitstellen vorgeschlagener Regeln können Sie den CEL-Ausdruck aus der Regelsignatur kopieren und in die Übereinstimmungsbedingung einer neu erstellten Regel einfügen oder auf die Schaltfläche Übernehmen im Adaptive Protection-Dashboard in der Google Cloud Armor-UI klicken.

Erstellen Sie zum Bereitstellen der Regel eine neue Regel in der Google Cloud Armor-Sicherheitsrichtlinie, die die durch die Benachrichtigung identifizierten ausgewählten Back-End-Dienste schützt. Kopieren Sie anschließend während der Regelkonfiguration den CEL-Ausdruck aus der Benachrichtigung in das Feld Übereinstimmungsbedingung der Regel und setzen Sie die Regelaktion auf deny. Im obigen Beispiel kopieren Sie den Ausdruck evaluateAdaptiveProtection('11275630857957031521') aus dem Abschnitt suggestedRule der Benachrichtigung.

Wir empfehlen dringend, die Regel zuerst im Vorschaumodus bereitzustellen, damit Sie die Auswirkungen der Regel auf den Produktionstraffic bewerten können. In diesem Fall protokolliert Google Cloud Armor die Aktion und den zugehörigen Traffic, wenn die Regel ausgelöst wird. Für den übereinstimmenden Traffic wird jedoch keine Aktion ausgeführt.

Wenn Ihre Sicherheitsrichtlinie mit mehreren Backend-Diensten verknüpft ist, prüfen Sie außerdem, ob die Auswirkungen der neuen Regel unerwünschte Auswirkungen in einem der Backend-Dienste haben. Konfigurieren Sie in diesem Fall neue Sicherheitsrichtlinien, um die unerwünschten Auswirkungen zu verhindern, und fügen Sie sie den richtigen Back-End-Diensten hinzu.

Wir empfehlen, die Priorität der neuen Regel höher als die Regeln für die entsprechende Aktion festzulegen. Der Grund dafür ist, dass die Regel in der höchsten logischen Prioritätsposition bereitgestellt werden muss, damit der gesamte übereinstimmende Traffic von der Regel blockiert wird. Regeln in einer Google Cloud Armor-Sicherheitsrichtlinie werden in der Prioritätsreihenfolge ausgewertet und die Auswertung wird beendet, nachdem die erste übereinstimmende Regel ausgelöst und die zugehörige Regelaktion ausgeführt wurde. Wenn Sie für einige Zugriffe oder bestimmte Clients eine Ausnahme von dieser Regel gewähren müssen, können Sie eine Zulassungsregel mit höherer Priorität erstellen, d. h. mit einem niedrigeren numerischen Wert. Weitere Informationen zur Regelpriorität finden Sie unter Regelauswertungsreihenfolge.

Vorgeschlagene Regeln automatisch bereitstellen

Sie können Adaptive Protection auch so konfigurieren, dass vorgeschlagene Regeln automatisch bereitgestellt werden. Um die automatische Regelbereitstellung zu aktivieren, erstellen Sie eine Platzhalterregel mit Ihrer bevorzugten Priorität und Aktion. Verwenden Sie dazu den Ausdruck evaluateAdaptiveProtectionAutoDeploy() in der Abgleichsbedingung. Diese Regel wird für Anfragen, die von Adaptive Protection als Angriffstraffic identifiziert werden, als true ausgewertet. Google Cloud Armor wendet die Aktion auf die angreifende Anfrage an. Alle Google Cloud Armor-Aktionstypen wie allow, deny, throttle und redirect werden unterstützt. Darüber hinaus können Sie im Vorschaumodus protokollieren, ob die Regel ausgelöst wurde, ohne die konfigurierte Aktion auszuführen.

Wenn Sie einen Upstream-Proxy vor Ihrem externen Application Load Balancer verwenden, z. B. das CDN eines Drittanbieters, empfehlen wir, das Feld userIpRequestHeaders so zu konfigurieren, dass die IP-Adresse (oder IP-Adressbereiche) Ihres Anbieters auf die Zulassungsliste gesetzt wird. Dadurch wird verhindert, dass Adaptive Protection die Quell-IP-Adresse des Proxys fälschlicherweise als Teil eines Angriffs identifiziert. Stattdessen prüft er das vom Nutzer konfigurierte Feld für die Quell-IP-Adresse des Traffics, bevor er den Proxy erreicht.

Weitere Informationen zum Konfigurieren der automatischen Regelbereitstellung finden Sie unter Vorgeschlagene Regeln für Adaptive Protection automatisch bereitstellen.

Regelstatus

Wenn bei dem Versuch, eine vorgeschlagene Regel bereitzustellen, keine Regel angezeigt wird, können Sie das Feld ruleStatus verwenden, um die Ursache zu ermitteln.

 ]
ruleStatus: RULE_GENERATED
attackSize: 5000
}

In der folgenden Tabelle werden die möglichen Werte des Felds und deren Bedeutung beschrieben.

Regelstatus Beschreibung
RULE_GENERATED Es wurde eine nutzbare Regel normal generiert.
BASELINE_TOO_RECENT Nicht genug Zeit, zuverlässigen Baseline-Traffic zu erzeugen. Für die Erstellung von Regeln wird bis zu einer Stunde benötigt.
NO_SIGNIFICANT_VALUE_DETECTED Es wurden keinen Headern signifikante Werte im Zusammenhang mit Angriffstraffic zugeordnet. Daher konnte keine Regel generiert werden.
NO_USABLE_RULE_FOUND Es konnte keine verwendbare Regel erstellt werden.
FEHLER Beim Erstellen der Regel ist ein unbekannter Fehler aufgetreten.

Monitoring, Feedback und Meldung von Ereignisfehlern

Sie benötigen die folgenden Berechtigungen, um das Adaptive Protection-Dashboard aufzurufen und damit zu interagieren.

  • compute.securityPolicies.list
  • compute.backendServices.list
  • logging.logEntries.list

Nachdem Sie Adaptive Protection in einer Google Cloud Armor-Sicherheitsrichtlinie aktiviert haben, wird die folgende Seite unter Netzwerksicherheit > Google Cloud Armor angezeigt. Das Trafficvolumen der ausgewählten Sicherheitsrichtlinie und des ausgewählten Back-End-Dienstes wird im Zeitverlauf angezeigt. Alle Instanzen potenzieller Angriffe, die von Adaptive Protection gemeldet werden, sind in der Grafik annotiert und unterhalb der Grafik aufgelistet. Wenn Sie auf ein bestimmtes Angriffsereignis klicken, wird ein Seitenfenster mit der Angriffssignatur und der vorgeschlagenen Regel im tabellarischen Format angezeigt. Dies sind dieselben Informationen wie in den Cloud Logging-Logeinträgen, die in der Cloud Logging-Eintragsspezifikation beschrieben werden. Klicken Sie auf Übernehmen, um die vorgeschlagene Regel in dieselbe Sicherheitsrichtlinie aufzunehmen.

Adaptive Protection-Dashboard
Adaptive Protection-Dashboard (zum Vergrößern klicken)
Benachrichtigungsdetails zu Adaptive Protection
Adaptive Protection-Dashboard (zum Vergrößern klicken)

Nicht jedes Ergebnis von Adaptive Protection wird aufgrund des individuellen Kontexts und der Umgebungsfaktoren des geschützten Back-End-Dienstes als Angriff betrachtet. Wenn Sie feststellen, dass der von der Benachrichtigung beschriebene potenzielle Angriff normal oder akzeptiert ist, können Sie einen Ereignisfehler melden, um die Adaptive Protection-Modelle zu trainieren. Neben jedem in der Grafik aufgeführten Angriffsereignis befindet sich eine Schaltfläche, die ein interaktives Fenster öffnet, mit dem Sie einen Ereignisfehler mit optionalem Kontext melden können. Wenn Sie einen Ereignisfehler melden, können Sie in Zukunft die Wahrscheinlichkeit ähnlicher Fehler reduzieren. Mit der Zeit wird so die Genauigkeit von Adaptive Protection erhöht.

Monitoring, Benachrichtigungen und Logging

Die Telemetrie von Adaptive Protection wird an Cloud Logging und an das Security Command Center gesendet. Die an Cloud Logging gesendete Adaptive Protection-Lognachricht wird in den vorherigen Abschnitten dieses Dokuments beschrieben. Jedes Mal, wenn Adaptive Protection einen potenziellen Angriff erkennt, wird ein Logeintrag generiert. Jeder Eintrag enthält einen Konfidenzwert, der angibt, wie hoch die Wahrscheinlichkeit ist, dass der beobachtete Traffic anomal ist. Für eine Benachrichtigung kann eine Benachrichtigungsrichtlinie in Cloud Logging so konfiguriert werden, dass eine Benachrichtigung nur dann ausgelöst wird, wenn der Konfidenzwert einer Adaptive Protection-Lognachricht einen benutzerdefinierten Schwellenwert überschreitet. Wir empfehlen Ihnen, mit einem niedrigen Schwellenwert mit einer Zuverlässigkeit von mehr als 0,5 zu beginnen, um möglichst alle Warnungen vor potenziellen Angriffen zu erhalten. Der Konfidenzschwellenwert in der Benachrichtigungsrichtlinie kann im Laufe der Zeit erhöht werden, wenn die Benachrichtigungen eine nicht akzeptable Baseline-Rate haben.

Das Security Command Center-Dashboard enthält auch Ergebnisse aus Adaptive Protection. Sie befinden sich auf der Google Cloud Armor-Karte unter der Kategorie Anwendungs-DDoS-Angriffe. Jedes Ergebnis enthält die Details zum Dienst, zur Zuverlässigkeit des Angriffs, zur mit dem Angriff verknüpfte Signatur und einen Link zur spezifischen Benachrichtigung im Adaptive Protection Dashboard.

Cloud Logging-Eintragsspezifikation

Die an Cloud Logging gesendete Adaptive Protection-Benachrichtigung besteht aus einem Logeintrag mit den folgenden Elementen:

  • Benachrichtigungssicherheit: Adaptive Protection-Konfidenz, dass das beobachtete Ereignis ein Angriff ist.
  • Automatisch bereitgestellt: Boolescher Wert, der angibt, ob eine automatische Verteidigung ausgelöst wurde.
  • Angriffssignatur
    • Attributname: Der Name des Attributs, das mit dem Value unten übereinstimmt, z. B. ein bestimmter Anfrageheadername oder ein geografischer Ursprung.
    • Wert: Der Wert, mit dem das Attribut in böswilligem Traffic übereinstimmt.
    • Art der Übereinstimmung: Die Beziehung zwischen Value und dem Attribut im Angriffstraffic. Der Wert ist entweder gleich oder ein Teilstring des Attributs im Angriffstraffic.
    • Angriffswahrscheinlichkeit: Die Wahrscheinlichkeit, dass eine bestimmte Anfrage schädlich ist, da das relevante Attribut dieser Anfrage mit Value übereinstimmt.
    • Anteil des Angriffs: Der Prozentsatz des potenziellen Angriffstraffics, der mit Value übereinstimmt.
    • Anteil im Basiswert: Der Prozentsatz des normalen Basistraffics, der mit Value übereinstimmt.
  • Vorgeschlagene Regel
    • Übereinstimmungsbedingung: Der in der Übereinstimmungsbedingung der Regeln zu verwendende Ausdruck, um böswilligen Traffic zu identifizieren.
    • Rate der betroffenen Baseline: der voraussichtliche Prozentsatz des guten Traffics zum spezifischen Back-End-Dienst unter Angriff, der von der vorgeschlagenen Regel erfasst wird.
    • Rate der Betroffenen Baseline für die Richtlinie: Der voraussichtliche Prozentsatz des guten Traffics an alle Back-End-Dienste in derselben Sicherheitsrichtlinie, der von der vorgeschlagenen Regel erfasst wird.
    • Rate des beeinflussten Angriffs: Der prognostizierte Prozentsatz des Angriffstraffics, der von der vorgeschlagenen Regel erfasst wird.
  • Regelstatus: Weitere Details zur Regelerstellung.

Überblick über maschinelles Lernen und Datenschutz

  • Trainingsdaten und Erkennungsdaten
    • Adaptive Protection erstellt mehrere Modelle, um potenzielle Angriffe zu erkennen und ihre Signaturen zu identifizieren. Die Signale, die von diesen Modellen verwendet werden, um festzustellen, ob ein Angriff aktiv ist, wird von den beobachteten Metadaten des eingehenden Anfrage-Traffics aus Ihren Projekten abgeleitet. Zu diesen Metadaten gehören: Quell-IP-Adresse, Quellregion und die Werte einiger HTTP-Anfrageheader.
    • Die tatsächlichen Features, die von den Modellen verwendet werden, sind statistische Attribute der oben genannten Signale. Das heißt, die Trainingsdaten für die Modelle enthalten nicht die tatsächlichen Werte von Metadaten, wie z. B. IP-Adressen und/oder Anfrageheaderwerte.
    • Eine allgemeines Set von Erkennungsmodellen, die nur mit künstlichen Daten trainiert wurden, wird von allen Kunden genutzt, um festzustellen, ob ein Angriff stattfindet, wenn der Adaptive Protection erstmals aktiviert wird. Wenn Sie ein falsches Angriffsereignis melden und die Modelle mit Traffic-Signalen aus Ihren Projekten aktualisiert werden, sind diese Modelle für Ihre Projekte lokal und werden nicht für andere Kunden verwendet.
  • Daten zum Generieren von Signaturen
    • Wenn Adaptive Protection einen möglichen Angriff feststellt, wird eine Angriffssignatur generiert, durch die das Ziel den Angriff schnell minimieren kann. Um dies zu erreichen, werden Traffic-Messwerte und Anfragemetadaten nach der Aktivierung von Adaptive Protection in einer Sicherheitsrichtlinie an einen (mit der Sicherheitsrichtlinie verknüpften) Backend-Dienst aufgezeichnet, um die Eigenschaften von Baseline-Traffic zu verstehen.
    • Da Adaptive Protection Informationen zum Baseline-Traffic benötigt, kann es bis zu einer Stunde dauern, bis Adaptive Protection Regeln zur Abwehr potenzieller Angriffe erstellt.

Nächste Schritte