Google Cloud Armor: IP-Adresse und Geofilterung

Media CDN verwendet Google Cloud Armor, um Unterstützung für IP-Adressenzulassungs- und -sperrlisten sowie Filterkontrollen auf der Grundlage von Länder- und Regionalcodes (geografischer Standort) zu bieten. Sie können:

• Anfragen basierend auf IPv4- und IPv6-Adressen und Bereichen ablehnen.
• Anfragen basierend auf dem Ländercode (Geografie) zulassen oder verweigern.
• Anfragen basierend auf IPv4- und IPv6-Adressen und Bereichen zulassen.

Mit diesen Funktionen können Sie das Herunterladen von Inhalten auf Nutzer an bestimmten Standorten beschränken, an denen Sie Beschränkungen für die Lizenzierung von Inhalten haben, nur IP-Adressen des Unternehmens den Zugriff auf Test- oder Staging-Endpunkte erlauben und eine Liste bekannter bösartiger Client-IP-Adressen ablehnen.

Hinweis: Google Cloud Armor-Sicherheitsrichtlinien erfordern während der aktuellen Version von Media CDN eine zusätzliche Zulassungsliste. Wenden Sie sich an Ihr Account-Management-Team, um diese Funktion zu aktivieren.

Google Cloud Armor-Richtlinien gelten für alle Inhalte von Media CDN, einschließlich Cache-Inhalte und Cache-Fehler.

IP-Adresse und geografische Richtlinien werden pro Edge-Cache-Dienst (EdgeCacheService) konfiguriert. Bei allen Anfragen, die für die IP-Adresse (oder Hostnamen) dieses Dienstes bestimmt sind, wird die Sicherheitsrichtlinie konsistent erzwungen. Auf unterschiedliche Dienste können unterschiedliche Sicherheitsrichtlinien angewendet werden und Sie können bei Bedarf mehrere Dienste für verschiedene Regionen erstellen.

Für einen detaillierteren Schutz von Inhalten auf Nutzerebene empfehlen wir die Verwendung signierter URLs und signierter Cookies in Verbindung mit einer Google Cloud Armor-Richtlinie.

Sicherheitsrichtlinien konfigurieren

Gehen Sie so vor, um eine Sicherheitsrichtlinie zu konfigurieren.

Hinweis

So hängen Sie eine Google Cloud Armor-Sicherheitsrichtlinie an einen Edge-Cache-Dienst an:

• Machen Sie sich mit Google Cloud Armor vertraut.
• Achten Sie darauf, dass ein vorhandener Edge-Cache-Dienst vorhanden ist, auf den Sie die Richtlinie anwenden möchten.
• Optional, aber empfohlen: Aktivieren Sie das Logging für Ihren Edge-Cache-Dienst, damit Sie blockierte Anfragen identifizieren können.

Sie benötigen außerdem die folgenden IAM-Berechtigungen (Identity and Access Management), um Sicherheitsrichtlinien zu autorisieren, zu erstellen und an einen Edge-Cache-Dienst anzuhängen:

• compute.securityPolicies.addAssociation
• compute.securityPolicies.create
• compute.securityPolicies.delete
• compute.securityPolicies.get
• compute.securityPolicies.list
• compute.securityPolicies.update
• compute.securityPolicies.use

Nutzer, die ein vorhandenes Zertifikat an einen Edge-Cache-Dienst anhängen müssen, benötigen nur diese IAM-Berechtigungen:

• compute.securityPolicies.get
• compute.securityPolicies.list
• compute.securityPolicies.use

Die Rolle roles/networkservices.edgeCacheUser enthält alle diese Berechtigungen.

Sicherheitsrichtlinie erstellen

Die Sicherheitsrichtlinien von Google Cloud Armor bestehen aus mehreren Regeln, wobei jede Regel eine Reihe übereinstimmender Kriterien (einen Ausdruck) für eine Anfrage und eine Aktion definiert. Ein Ausdruck kann zum Beispiel eine Anpassungslogik für Clients enthalten, die sich in Indien befinden, wobei die zugehörige Aktion „allow“ lautet. Wenn eine Anfrage nicht mit der Regel übereinstimmt, wird die Auswertung mit der nächsten Regel fortgesetzt, bis alle Regeln versucht wurden.

Sicherheitsrichtlinien haben eine Standardregel mit der Aktion „allow“. Die Standardregel lässt Anfragen zu, die nicht mit obigen Regeln übereinstimmen. Dies kann in eine deny-Regel geändert werden, wenn Sie für allow nur Anfragen ausführen möchten, die mit vorherigen Regeln übereinstimmen und alle anderen ablehnen.

Das folgende Beispiel zeigt, wie eine Regel erstellt wird, die alle Clients mit dem Standort Australien mit einer HTTP 403 blockiert und alle anderen Anfragen zulässt.

gcloud

Führen Sie den folgenden Befehl aus, um eine neue Richtlinie vom Typ CLOUD_ARMOR_EDGE zu erstellen:

gcloud compute security-policies create block-australia \
    --type="CLOUD_ARMOR_EDGE" --project="PROJECT_ID"

Dadurch wird eine Richtlinie mit einer Standardregel zum Zulassen mit der niedrigsten Priorität (priority: 2147483647) erstellt:

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/securityPolicies/block-australia].

Anschließend können Sie eine Regel mit einer höheren Priorität hinzufügen:

gcloud compute security-policies rules create 1000 \
    --security-policy=block-australia --description "block AU" \
    --expression="origin.region_code == 'AU'" --action="deny-403"

Die Ausgabe sieht so aus:

Updated [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/securityPolicies/block-australia].

Terraform

media_cdn/security_policies/main.tf

Auf GitHub ansehen Feedback

resource "google_compute_security_policy" "default" {
  name        = "block-australia"
  type        = "CLOUD_ARMOR_EDGE"
  description = "block AU"

  rule {
    action      = "deny(403)"
    description = "block AU"
    priority    = "1000"
    match {
      expr {
        expression = "origin.region_code == 'AU'"
      }
    }
  }
  rule {
    action   = "allow"
    priority = "2147483647"
    match {
      versioned_expr = "SRC_IPS_V1"
      config {
        src_ip_ranges = ["*"]
      }
    }
    description = "default rule"
  }
}

Wenn Sie sich die Richtlinie ansehen, erkennen Sie die beiden Regeln: Die erste Regel blockiert Anfragen aus Australien (origin.region_code == 'AU'), und die zweite, niedrigste Prioritätsregel lässt den gesamten Traffic zu, der nicht der (oder den) Regel(n) mit der höheren Priorität entspricht.

kind: compute#securityPolicy
name: block-australia
rules:
- action: deny(403)
  description: block AU
  kind: compute#securityPolicyRule
  match:
    expr:
      expression: origin.region_code == 'AU'
  preview: false
  priority: 1000
- action: allow
  description: default rule
  kind: compute#securityPolicyRule
  match:
    config:
      srcIpRanges:
      - '*'
    versionedExpr: SRC_IPS_V1
  preview: false
  priority: 2147483647
  ruleNumber: '1'
type: CLOUD_ARMOR_EDGE

Informationen zum Anhängen dieser Richtlinie an Ihr Media CDN finden Sie im nächsten Abschnitt.

Richtlinie an einen Dienst anhängen

Wichtig: Nur Sicherheitsrichtlinien vom Typ CLOUD_ARMOR_EDGE können mit einem EdgeCacheService verknüpft werden.

So hängen Sie eine vorhandene Google Cloud Armor-Richtlinie namens us-only-delivery-policy an einen Edge-Cache-Dienst namens prod-media-service an:

gcloud

gcloud edge-cache services update prod-media-service \
    --edge-security-policy=us-only-delivery-policy

Richtlinienanhang aufrufen

Untersuchen Sie den Dienst, um zu prüfen, welche Richtlinie an einen vorhandenen Dienst angehängt ist:

gcloud

gcloud edge-cache services describe MY_SERVICE

Im Feld edgeSecurityPolicy des Dienstes wird die angehängte Richtlinie beschrieben:

name: "MY_SERVICE"
edgeSecurityPolicy: "SECURITY_POLICY

Richtlinie entfernen

Wenn Sie eine vorhandene Richtlinie entfernen, aktualisieren Sie den zugehörigen Dienst und übergeben Sie einen leeren String als Richtlinie:

gcloud

gcloud edge-cache services update MY_SERVICE \
  --edge-security-policy=""

Das Feld edgeSecurityPolicy wird jetzt in der Ausgabe des Befehls gcloud edge-cache services describe MY_SERVICE ausgelassen.

Blockierte Anfragen identifizieren

Für den angegebenen Edge-Cache-Dienst muss das Logging aktiviert sein, damit blockierte Anfragen protokolliert werden.

Anfragen, die von einer Filterrichtlinie zugelassen oder abgelehnt werden, werden in Logging protokolliert. Um nach abgelehnten Anfragen zu filtern, würde die folgende Logging-Abfrage für die prod-video-service-Konfiguration so aussehen:

resource.type="edge_cache_service"
jsonPayload.statusDetails="denied_by_security_policy"

Antwortcodes anpassen

Google Cloud Armor-Regeln können so konfiguriert werden, dass sie einen bestimmten Statuscode als die mit einer bestimmten Regel verbundene Aktion zurückgeben. In den meisten Fällen ist es am besten, wenn Sie einen HTTP 403-Code (deny-403) zurückgeben, um deutlich zu machen, dass der Client von der Regel blockiert wurde.

Die folgenden Statuscodes werden unterstützt:

• HTTP 403 (Unzulässig)
• HTTP 404 (Nicht gefunden)
• HTTP 502 (Falsches Gateway)

Das folgende Beispiel zeigt, wie der zurückgegebene Statuscode konfiguriert wird:

gcloud

Um eine der Optionen [allow | deny-403 | deny-404 | deny-502] als mit der Regel verknüpfte Aktion anzugeben, führen Sie den folgenden Befehl aus. In diesem Beispiel wird die Regel so konfiguriert, dass HTTP 502 zurückgegeben wird.

gcloud compute security-policies rules create 1000 \
    --security-policy=block-australia --description "block AU" \
    --expression="origin.region_code == 'AU'" --action="deny-502"

Jede Regel in einer Sicherheitsrichtlinie kann eine andere Statuscodeantwort definieren.

Beispiele

Betrachten Sie die folgenden detaillierten Beispielanwendungsfälle.

Beispiel: Clients außerhalb eines Landes ablehnen, mit Ausnahme der zulässigen IP-Adressen

Ein häufiger Fall bei der Medienbereitstellung ist die Ablehnung von Verbindungen von Clients, die sich außerhalb der Region befinden, für die Sie Lizenzen oder Zahlungsmechanismen haben.

Beispiel: Sie möchten nur Clients in Indien sowie alle zulässigen IP-Adressen (Content-Partner und Ihre eigenen Mitarbeiter) im Bereich 192.0.2.0/24 zulassen und alle anderen ablehnen.

Unter Verwendung der benutzerdefinierten Regelsprache von Google Cloud Armor wird dies mit dem folgenden Ausdruck erreicht:

origin.region_code == "IN" || inIpRange(origin.ip, '192.0.2.0/24')

Dieser Ausdruck wird als allow-Regel konfiguriert, mit einer deny-Standardregel, die für alle anderen Clients gilt. Sicherheitsrichtlinien haben immer eine Standardregel. Normalerweise konfigurieren Sie dies so, dass auf Traffic, den Sie nicht ausdrücklich zulassen, standardmäßig default deny angewendet wird. In anderen Fällen können Sie einen ausgewählten Teil des Traffics blockieren und auf den restlichen Traffic default allow anwenden.

Beachten Sie in der Ausgabe der Sicherheitsrichtlinie Folgendes:

• Die Regel mit der höchsten Priorität (priority: 0) lässt Traffic von Indien ODER aus der definierten Liste von IP-Adressen zu.
• Die Regel mit der niedrigsten Priorität stellt ein default deny dar. Die Regel-Engine lehnt alle Clients ab, deren Regeln mit höherer Priorität nicht als „true“ bewertet werden.
• Mit booleschen Operatoren können Sie mehrere Regeln verketten.

Die folgende Richtlinie lässt den Traffic von Clients in Indien sowie Clients aus einem bestimmten IP-Bereich zu und lehnt allen anderen Traffic ab:

gcloud

Führen Sie folgenden Befehl security-policies describe aus:

gcloud compute security-policies describe allow-india-only

Dadurch wird eine Google Cloud Armor-Richtlinie ausgegeben, die in etwa so aussieht:

kind: compute#securityPolicy
name: allow-india-only
type: "CLOUD_ARMOR_EDGE"
rules:
- action: allow
  description: ''
  kind: compute#securityPolicyRule
  match:
    expr:
      expression: origin.region_code == "IN" || inIpRange(origin.ip, '192.0.2.0/24')
  preview: false
  priority: 0
- action: deny(403)
  description: Default rule, higher priority overrides it
  kind: compute#securityPolicyRule
  match:
    config:
      srcIpRanges:
      - '*'
    versionedExpr: SRC_IPS_V1
  preview: false
  priority: 2147483647

Sie können auch einen benutzerdefinierten Antwortheader mit der Headervariable {region_code} festlegen. Dieser Header kann mit JavaScript untersucht und dem Client angezeigt werden.

Beispiel: Schädliche Clients anhand von IP-Adresse und IP-Bereichen blockieren

Unter Verwendung der benutzerdefinierten Regelsprache von Google Cloud Armor wird dies mit dem folgenden Ausdruck erreicht:

inIpRange(origin.ip, '192.0.2.2/32') || inIpRange(origin.ip, '192.0.2.170/32')

Sie können IP-Bereiche bis zu einer /8-Maske in IPv4 und einer /32 in IPv6 blockieren. Ein häufiger Fall für Streamingplattformen besteht darin, die IP-Bereiche von Proxys oder VPN-Anbietern für ausgehenden Traffic zu blockieren, um die Umgehung von Inhaltslizenzen zu minimieren:

inIpRange(origin.ip, '192.0.2.0/24') || inIpRange(origin.ip, '198.51.100.0/24') || inIpRange(origin.ip, '203.0.113.0/24') || inIpRange(origin.ip, '2001:DB8::B33F:2002/64')

Sowohl IPv4- als auch IPv6-Adressbereiche werden unterstützt.

Beispiel: Nur eine feste Liste von Regionen zulassen

Wenn Sie eine Liste mit Ländercodes haben, können Sie den booleschen ODER-Operator || verwenden, um Übereinstimmungsbedingungen zu verketten.

Warnung: Verwenden Sie nicht den logischen UND-Operator &&, um origin.region_code-Bedingungen zu verketten. Ein Kunde kann nicht in zwei Regionen gleichzeitig geografisch verortet sein, wodurch kein Kunde die Bedingung erfüllt. Dies führt dazu, dass alle Clients blockiert werden.

Unter Verwendung der benutzerdefinierten Regelsprache von Google Cloud Armor erlaubt der folgende Ausdruck Nutzer, die als aus Australien oder Neuseeland stammend identifiziert werden:

origin.region_code == "AU" || origin.region_code == "NZ"

Diese können außerdem mit origin.ip- oder inIpRange(origin.ip, '...')-Ausdrücken verkettet werden, um Testern, Partnern und Unternehmens-IP-Bereichen zu ermöglichen, auch wenn sie nicht aus einer der angegebenen Regionen stammen.

Es gibt die dokumentierte Anzahl von Unterausdrücken für jede Regel mit einem benutzerdefinierten Ausdruck. Wenn Sie weitere Teilausdrücke verketten möchten, definieren Sie mehrere Regeln innerhalb einer einzelnen Richtlinie.

Beispiel: Clients aus einer bestimmten Gruppe von Ländern blockieren

Ein weniger gebräuchliches Beispiel könnte darin bestehen, Clients aus einer bestimmten Gruppe von Ländern zu blockieren, aber ansonsten Anfragen aus allen anderen Ländern zuzulassen.

Erstellen Sie dazu eine Richtlinie, die sowohl das Land als auch alle Clients, für die die Region nicht ermittelt werden kann, blockiert und dann für alle anderen Anfragen eine Standard-Zulassungsregel durchläuft.

Hinweis: Clients, deren Standort nicht ermittelt werden kann, haben einen region_code von ZZ.

Das folgende Beispiel beschreibt eine Richtlinie, die Clients aus Kanada sowie alle Clients blockiert, bei denen der Standort unbekannt ist, aber den gesamten anderen Traffic zulässt:

  kind: compute#securityPolicy
  name: block-canada
  type: "CLOUD_ARMOR_EDGE"
  rules:
  - action: deny(403)
    description: ''
    kind: compute#securityPolicyRule
    match:
      expr:
        expression: origin.region_code == "CA" || origin.region_code == "ZZ"
    preview: false
    priority: 0
  - action: allow
    description: Default rule, higher priority overrides it
    kind: compute#securityPolicyRule
    match:
      config:
        srcIpRanges:
        - '*'
      versionedExpr: SRC_IPS_V1
    preview: false
    priority: 2147483647

Erzwingungsmaßnahmen für Logging

Jedes Anfragelog enthält Details dazu, welche Sicherheitsrichtlinie angewendet wurde und ob die Anfrage zulässig war (ALLOW) oder abgelehnt wurde (DENY).

Wenn Sie das Logging aktivieren möchten, muss logConfig.enable in Ihrem Dienst auf true gesetzt sein. Dienste ohne aktivierte Logs protokollieren keine Ereignisse für Sicherheitsrichtlinien.

Wenn sich ein Client außerhalb der Vereinigten Staaten befindet und eine Sicherheitsrichtlinie namens deny-non-us-clients in Kraft ist, die Anfragen von außerhalb der USA ablehnt ist dies der Logeintrag für eine abgelehnte Anfrage:

enforcedSecurityPolicy:
  name: deny-non-us-clients
  outcome: DENY

Dienste, denen keine Google Cloud Armor-Richtlinie zugeordnet ist, enthalten no_policy als Wert von enforcedSecurityPolicy.name und ein outcome von ALLOW. Ein Anfragelogeintrag für einen Dienst ohne angehängte Richtlinie hat beispielsweise folgende Werte:

enforcedSecurityPolicy:
  name: no_policy
  outcome: ALLOW

Informationen zu GeoIP-Klassifizierungen

Media CDN stützt sich auf die internen IP-Klassifizierungsdatenquellen von Google, um einen Standort (Region, Bundesstaat/Bundesland, Stadt) aus einer IP-Adresse abzuleiten. Wenn Sie von mehreren Anbietern migrieren oder den Traffic auf mehrere Anbieter aufteilen, kann es sein, dass eine kleine Anzahl von IP-Adressen mit verschiedenen Standorten verknüpft ist.

• Google Cloud Armor verwendet die Regionscodes nach ISO 3166-1 alpha 2, um einen Client einem geografischen Standort zuzuordnen.
• Zum Beispiel US für die USA oder AU für Australien.
• In einigen Fällen entspricht eine Region einem Land. Dies ist jedoch nicht immer der Fall. Beispielsweise enthält der Code US alle Bundesstaaten der USA, einen District und sechs Außengebiete.
• Weitere Informationen finden Sie im Unicode Technical Standard unter unicode_region_subtag.

• Bei Clients, bei denen der Standort nicht abgeleitet werden kann, wird origin.region_code auf ZZ gesetzt.

Sie können geografische Daten zu Antwortheadern eines Media CDN-Endpunkts hinzufügen (mit routing.routeRules[].headerActions[].responseHeadersToAdd[]) oder die einer Cloud Functions-Funktion bereitgestellten geografischen Daten widerspiegeln, um etwaige Unterschiede zwischen GeoIP-Datenquellen während der anfänglichen Integration und Tests zu validieren.

Darüber hinaus enthalten Media CDN-Anfragelogs die clientRegion und andere clientspezifische Daten, die Sie anhand Ihrer vorhandenen Datenquellen validieren können.

Nächste Schritte

• Erfahren Sie, wie Sie signierte Anfragen verwenden, um Inhalte auf Nutzerbasis zu autorisieren.
• In der Referenz zu Google Cloud Armor-Regeln erfahren Sie, wie IP- und geografische Übereinstimmungsregeln ausgedrückt und miteinander verkettet werden können.
• Informationen zum Abfragen von Anfragelogs und zum Prüfen, welche Anfragen blockiert wurden, finden Sie in der Dokumentation zu Logging.