Sicherheitsrichtlinien konfigurieren

Media CDN nutzt Google Cloud Armor-Sicherheitsrichtlinien, um unerwünschte Aktivitäten zu verhindern. von Traffic, der auf seine Dienste stößt. Sie können Anfragen basierend auf den Folgendes:

  • IPv4- und IPv6-Adressen und -Bereiche (CIDRs)
  • Ländercode (Region)
  • 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 Google Cloud Armor zulässt, mit benutzerdefinierten mit konfigurierbaren Namen und Werten.

Google Cloud Armor-Sicherheitsrichtlinien gelten für alle Inhalte, die von Media CDN, einschließlich im Cache gespeicherter Inhalte und Cache-Fehler

Google Cloud Armor-Sicherheitsrichtlinien werden nach Media CDN-Dienst: alle Anfragen für den jeweiligen Dienst Für IP-Adressen (oder Hostnamen) wird die Sicherheitsrichtlinie konsistent durchgesetzt. Unterschiedliche Dienste können unterschiedliche Sicherheitsrichtlinien haben und Sie können Erstellen Sie nach Bedarf mehrere Dienste für verschiedene Regionen.

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.

Media CDN berücksichtigt den referer-Header während Regelauswertung von Edge-Sicherheitsrichtlinien zum Filtern von Layer-7-Headern, wenn es auf einen der folgenden Werte festgelegt:

  • 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

So hängen Sie eine Google Cloud Armor-Sicherheitsrichtlinie an ein Media CDN an: achten Sie auf Folgendes:

  • Machen Sie sich mit Google Cloud Armor vertraut.
  • Sie haben einen Media CDN-Dienst. auf das Sie die Richtlinie anwenden möchten.
  • Optional, aber empfohlen: Aktivieren Sie die Protokollierung in Ihrem Media CDN. damit Sie blockierte Anfragen identifizieren können.

Sie benötigen außerdem die folgenden Berechtigungen für Identity and Access Management zum Autorisieren, Erstellen und Sicherheitsrichtlinien an einen Media CDN-Dienst anhä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 ein Media CDN anhängen müssen Dienst 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 z. B. eine Abgleichslogik für Kunden in Indien mit der verknüpften Aktion „allow“ Wenn eine Anfrage nicht mit der Regel übereinstimmt, wertet Google Cloud Armor bis alle Regeln angewendet wurden.

Sicherheitsrichtlinien haben eine Standardregel mit der Aktion allow. Standardeinstellung lässt Anfragen zu, die nicht mit vorhergehenden Regeln übereinstimmen. Dies kann in Wenn Sie nur Anfragen allow, die mit vorhergehenden Regeln übereinstimmen, mit der Regel deny allow 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 zum Erstellen einer neuen Richtlinie vom Typ CLOUD_ARMOR_EDGE die Methode gcloud compute security-policies create-Befehl:

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 Gruppen von Regeln, Layer-7-Attribute für den Schutz extern zugänglicher Anwendungen oder . 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 Schreiben von Ausdrücken für die Sicherheit finden Sie in der Referenz zur Sprache für benutzerdefinierte Regeln in 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 zum Erstellen einer Regel für eine Sicherheitsrichtlinie die Methode gcloud compute security-policies rules create PRIORITY . 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

So hängen Sie eine vorhandene Google Cloud Armor-Richtlinie an eine Media CDN-Dienst verwenden, verwenden Sie gcloud edge-cache services update-Befehl:

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 einem Sicherheitsrichtlinie

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 in der securityPolicies.patchRule-Methode.

Richtlinienanhang aufrufen

Untersuchen (beschreiben) können Sie prüfen, welche Richtlinie an einen vorhandenen Dienst angehängt ist. für diesen Dienst.

gcloud

Um die Google Cloud Armor-Richtlinie anzuzeigen, die mit einem Media CDN-Dienst verwenden, verwenden Sie gcloud edge-cache services describe-Befehl:

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 möchten, aktualisieren Sie den verknüpften Dienst und übergeben Sie ein leeres Feld als Richtlinie verwenden.

gcloud

Verwenden Sie die Methode gcloud edge-cache services update-Befehl: 

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

Sie müssen für einen bestimmten Edge Logging aktiviert haben Cache-Dienst für blockierte Anfragen, die protokolliert werden sollen.

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.

Wenn Sie beispielsweise nur Kunden in Indien zulassen möchten, alle IP-Adressen, die auf der Zulassungsliste stehen, einschließlich der IP-Adressen von Contentpartnern und Ihre eigenen Mitarbeiter im Bereich 192.0.2.0/24 und lehnen Sie alle anderen ab.

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.
  • Sie können mehrere Regeln kombinieren, indem Sie Boolesche Operatoren verwendet werden.

Die Richtlinie ermöglicht Traffic von Kunden in Indien, aus einem definierten IP-Bereich aus und lehnt den gesamten 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 mithilfe von JavaScript-Code und wird dem Client angezeigt.

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

Dieser kann zusätzlich mit origin.ip- oder inIpRange(origin.ip, '...')-Ausdrücken kombiniert werden, um Testern, Partnern und den IP-Bereichen Ihres Unternehmens 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 eine Kombination aus mehr Unterausdrücken, definieren Sie mehrere Regeln in einer einzigen 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

Edge-Sicherheitsrichtlinie gilt für alle Anfragen an Media CDN-Dienste, die von der Richtlinie zugeordnet ist. Diese Richtlinienerzwingung findet vor jedem Cache statt Lookup-Vorgang. Anfragen, die von der Edge-Sicherheitsrichtlinie nicht zugelassen sind, werden abgelehnt durch den konfigurierten Statuscode.

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 der Edge-Sicherheitsrichtlinie die Filterregel 105 hinzugefügt my-edge-policy, das 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 interne IP-Klassifizierung von Google Datenquellen, um einen Standort (Region, Bundesland, Provinz oder Stadt) aus einer IP-Adresse abzuleiten Adresse. 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