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

Benachrichtigungen vom Typ „Full 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, 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 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.

Adaptive Protection soll Backend-Dienste vor Layer-7-DDoS-Angriffen mit hoher Auslastung schützen. In den folgenden Szenarien werden Anfragen nicht Adaptiver Schutz:

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

Detaillierte Modelle

Standardmäßig erkennt Adaptive Protection einen Angriff und schlägt Maßnahmen zur Risikominderung vor, die auf dem typischen Traffic basieren, der an jeden Back-End-Dienst gerichtet ist. Das bedeutet, dass Back-End hinter einem Back-End-Dienst überlastet, Adaptive Protection ergreift keine Maßnahmen, da der Angriffstraffic nicht anomal ist.

Mit der Funktion für detaillierte Modelle können Sie bestimmte Hosts oder Pfade als detailliert konfigurierte Einheiten konfigurieren, die von Adaptive Protection analysiert werden. Wenn Sie detaillierte wird der Traffic mithilfe der von Adaptive Protection vorgeschlagenen Maßnahmen übereinstimmenden Host- oder URL-Pfadpräfixen, um falsch positive Ergebnisse zu reduzieren. Jeder dieser Hosts oder Pfade wird als granulare Traffic-Einheit bezeichnet.

Die identifizierten Angriffssignaturen zielen nur auf den kommenden Angriffstraffic ab in die detaillierte Traffic-Einheit, Die Filterung gilt jedoch alle Anfragen, die mit der bereitgestellten Regel übereinstimmen, so, als ob dies ohne das Attribut Konfigurationen vornehmen. Wenn Sie z. B. möchten, dass eine automatisch bereitgestellte Regel nur einer bestimmten Traffic-Detaileinheit entsprechen, sollten Sie eine Übereinstimmung wie evaluateAdaptiveProtectionAutoDeploy() && request.headers['host'] == ... && request.path == ....

Zusätzlich zu Host- und URL-Pfadpräfixen können Sie Schwellenwerte für Benachrichtigungen konfigurieren. basierend auf einigen oder allen der folgenden Optionen. Diese Grenzwerte können auf die detaillierten Traffic-Einheiten oder auf den Back-End-Dienst insgesamt, mit Ausnahme der Lastgrenzwert, der nur auf den Back-End-Dienst angewendet werden kann:

  • Last: Die maximale Last für den Back-End-Dienst gemäß dem konfigurierten Wert Application Load Balancer. Diese Option ist für detailliertes Targeting nicht verfügbar. Traffic-Einheiten und steht für serverlose Back-Ends wie Cloud Run, Cloud Run-Funktionen oder externe Ursprungs-Back-Ends.
  • Absolute Abfragen pro Sekunde: Die höchste Traffic-Menge in Abfragen pro Sekunde, die der Back-End-Dienst oder die Traffic-Einheit empfängt.
  • Relativ zur Basis-Abfragen pro Sekunde: ein Vielfaches der durchschnittlichen langfristigen Basislinie wie viele Zugriffe erfolgen. Beispielsweise steht der Wert 2 für eine Abfragen pro Sekunde im das grundlegende Traffic-Volumen.

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. 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 verstehen

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 kein Cloud Armor Enterprise-Abo haben, ist eine Angriffssignatur nicht die in der grundlegenden Benachrichtigung enthalten sind.

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 einfachen Benachrichtigungen, die von Adaptive Protection gesendet werden, keine zur Anwendung vorgeschlagenen Google Cloud Armor-Regeln.

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 Priorität und Aktion können Sie mithilfe des Ausdrucks evaluateAdaptiveProtectionAutoDeploy() in der Übereinstimmungsbedingung. Diese Regel ergibt für Anfragen, die von Adaptive Protection als Angriffs-Traffic erkannt werden, den Wert true. Google Cloud Armor wendet die Aktion dann auf die angreifende Anfrage an. Alle Google Cloud Armor-Aktiontypen wie allow, deny, throttle und redirect werden unterstützt. Außerdem können Sie im Vorschaumodus um zu protokollieren, dass die Regel ausgelöst wurde, ohne die konfigurierte Aktion auszuführen.

Wenn Sie einen vorgelagerten Proxy wie das CDN eines Drittanbieters vor Ihrem externen Application Load Balancer verwenden, sollten Sie das Feld userIpRequestHeaders konfigurieren, um die IP-Adresse (oder IP-Adressbereiche) Ihres Anbieters einer Zulassungsliste hinzuzufügen. So wird verhindert, dass Adaptive Protection fälschlicherweise die Quell-IP-Adresse des Proxys als an einem Angriff beteiligt identifiziert. Stattdessen werden die Daten Vom Nutzer konfiguriertes Feld für die Quell-IP-Adresse des Traffics vor dem Eingang im Stellvertreter.

Weitere Informationen zum Konfigurieren der automatischen Regelbereitstellung finden Sie unter Von Adaptive Protection vorgeschlagene Regeln 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. Die Der folgende Screenshot zeigt ein Beispiel für einen DDoS-Angriffsversuch einer Anwendung. Ergebnis:

Ergebnis: DDoS-Angriff auf die Anwendung Ergebnis für
DDoS-Angriff auf die Anwendung (klicken, um vergrößern)

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