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 folgenden Kriterien zulassen oder ablehnen:

  • 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 von Google Cloud Armor zugelassen sind, durch Einfügen benutzerdefinierter Header mit konfigurierbaren Namen und Werten anpassen.

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, die für den Dienst dieses Dienstes bestimmt sind 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

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.
  • Sie haben einen Media CDN-Dienst. auf das 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 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 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 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

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 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 zugehörigen Dienst und übergeben Sie ein leeres Feld als Richtlinie verwenden.

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

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 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 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 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 Cache-Suche. 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 zum Ableiten eines Standorts (Region, Bundesland, Provinz oder Stadt) aus einer IP-Adresse 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