Sicherheitsrichtlinien konfigurieren

Media CDN verwendet Google Cloud Armor-Sicherheitsrichtlinien, um unerwünschten Traffic von seinen Diensten fernzuhalten. Sie können Anfragen basierend auf den folgenden Kriterien zulassen oder ablehnen:

  • IPv4- und IPv6-Adressen und ‑Bereiche (CIDRs)
  • Ländercode (Geografie)
  • Layer 7-Filterung

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.

Sie können Anfragen, die von Google Cloud Armor zugelassen sind, durch Einfügen benutzerdefinierter Header mit konfigurierbaren Namen und Werten anpassen.

Die Sicherheitsrichtlinien von Google Cloud Armor gelten für alle Inhalte, die von Media CDN bereitgestellt werden, einschließlich Cache-Inhalten und Cache-Fehlern.

Google Cloud Armor-Sicherheitsrichtlinien werden pro Media CDN-Dienst 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.

Der referer-Header wird von Media CDN bei der Regelauswertung von Edge-Sicherheitsrichtlinien für die Layer 7-Headerfilterung nicht berücksichtigt, wenn er auf einen der folgenden Werte festgelegt ist:

  • Mehrere URLs
  • Eine relative URL
  • Gültige absolute URLs, die Nutzerinformationen oder eine Fragmentkomponente enthalten

Sicherheitsrichtlinien konfigurieren

Gehen Sie so vor, um eine Sicherheitsrichtlinie zu konfigurieren.

Hinweise

Wenn du eine Google Cloud Armor-Sicherheitsrichtlinie an einen Media-CDN-Dienst anhängen möchtest, musst du Folgendes beachten:

  • Machen Sie sich mit Google Cloud Armor vertraut.
  • Achten Sie darauf, dass ein vorhandener Media CDN-Dienst vorhanden ist, auf den Sie die Richtlinie anwenden möchten.
  • Optional, aber empfohlen: Aktiviere das Logging für deinen Media CDN-Dienst, damit du blockierte Anfragen identifizieren kannst.

Sie benötigen außerdem die folgenden IAM-Berechtigungen (Identity and Access Management), um Sicherheitsrichtlinien zu autorisieren, zu erstellen und an einen Media CDN-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 Media-CDN-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, wertet Google Cloud Armor die nächste Regel so lange aus, 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

Verwenden Sie den Befehl gcloud compute security-policies create, 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 

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

Regeln zu einer Sicherheitsrichtlinie hinzufügen

Google Cloud Armor-Sicherheitsrichtlinien sind Regeln, die Attribute der Schicht 7 abgleichen, um externe Anwendungen oder Dienste zu schützen. Jede Regel wird im Hinblick auf den eingehenden Traffic ausgewertet.

Diese Attribute können für HTTP-Anfragen in Sicherheitsrichtlinien verwendet werden: request.headers, request.method, request.path, request.scheme und request.query. Weitere Informationen zum Erstellen von Ausdrücken für Sicherheitsrichtlinienregeln finden Sie in der Referenz zur Sprache der benutzerdefinierten Regeln für Google Cloud Armor.

Eine Google Cloud Armor-Sicherheitsrichtlinienregel besteht aus einer Abgleichsbedingung und einer Aktion, die ausgeführt werden muss, wenn diese Bedingung erfüllt ist.

gcloud

Verwenden Sie den Befehl gcloud compute security-policies rules create PRIORITY, um eine Regel für eine Sicherheitsrichtlinie zu erstellen. Ersetzen Sie PRIORITY durch die Priorität der Regel in der Richtlinie:

gcloud compute security-policies rules create PRIORITY \
    --security-policy POLICY_NAME \
    --description DESCRIPTION \
    --src-ip-ranges IP_RANGES | --expression EXPRESSION \
    --action=[ allow | deny-403 | deny-404 | deny-502 ] \
    --preview

Richtlinie an einen Dienst anhängen

gcloud

Verwenden Sie den Befehl gcloud edge-cache services update, um eine vorhandene Google Cloud Armor-Richtlinie an einen Media CDN-Dienst anzuhängen:

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

Regel in einer Sicherheitsrichtlinie aktualisieren

Folgen Sie dieser Anleitung, um eine einzelne Regel in einer Google Cloud Armor-Sicherheitsrichtlinie zu aktualisieren. Alternativ können Sie mehrere Regeln in einer Sicherheitsrichtlinie atomar aktualisieren.

gcloud

Führen Sie den Befehl gcloud compute security-policies rules update aus:

gcloud compute security-policies rules update PRIORITY [ \
    --security-policy POLICY_NAME  \
    --description DESCRIPTION  \
    --src-ip-ranges IP_RANGES  | --expression EXPRESSION \
    --action=[ allow | deny-403 | deny-404 | deny-502 ]  \
    --preview
  ]

Mit dem folgenden Befehl wird beispielsweise eine Regel mit der Priorität 1111 aktualisiert, um Traffic aus dem IP-Adressbereich 192.0.2.0/24 zuzulassen:

gcloud compute security-policies rules update 1111 \
    --security-policy my-policy \
    --description "allow traffic from 192.0.2.0/24" \
    --src-ip-ranges "192.0.2.0/24" \
    --action "allow"

Um die Priorität einer Regel zu aktualisieren, müssen Sie die REST API verwenden. Weitere Informationen finden Sie im Artikel zur Methode securityPolicies.patchRule.

Richtlinienanhang aufrufen

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

gcloud

Verwenden Sie den Befehl gcloud edge-cache services describe, um die Google Cloud Armor-Richtlinie aufzurufen, die an einen Media CDN-Dienst angehängt ist:

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

Führen Sie den Befehl gcloud edge-cache services update aus: 

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.

Beispiele

Betrachten Sie die folgenden detaillierten Beispielanwendungsfälle.

Beispiel: 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"

Beispiel: 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:

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.

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 IP-Adressen auf der Zulassungsliste, einschließlich der von Contentpartnern und Ihren eigenen Mitarbeitern, 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 kombinieren.

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

Wenn Sie sich die Details der Richtlinie ansehen, sieht die Ausgabe in etwa so aus:

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

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 kombiniert 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 mehrere Teilausdrücke kombinieren 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.

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

Beispiel: Anfragen für im Cache gespeicherte Inhalte mit bestimmten Headern ablehnen

Eine Edge-Sicherheitsrichtlinie gilt für alle Anfragen, die auf einen Media CDN-Dienst ausgerichtet sind, mit dem die Richtlinie verknüpft ist. Diese Richtliniendurchsetzung erfolgt vor jeder Cacheabfrage. Anfragen, die von der Edge-Sicherheitsrichtlinie nicht zugelassen werden, werden mit dem konfigurierten Statuscode abgelehnt.

Der folgende Ausdruck stimmt mit Anfragen von der IP-Adresse 1.2.3.4 überein, die den String user1 im user-agent-Header enthalten:

inIpRange(origin.ip, '1.2.3.4/32') && request.headers['user-agent'].contains('user1')

Mit dem folgenden Befehl wird die Filterregel 105 der Edge-Sicherheitsrichtlinie my-edge-policy hinzugefügt, die an einen Media CDN-Dienst angehängt ist:

gcloud compute security-policies rules create 105 \
    --security-policy my-edge-policy \
    --expression = "inIpRange(origin.ip, '1.2.3.4/32') && request.headers['user-agent'].contains('charlie')" \
    --action= deny-403 \
    --description="block requests from IP addresses in which the user-agent header contains the string charlie"

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, Provinz oder 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