Media CDN utilise les stratégies de sécurité Google Cloud Armor pour empêcher les d'atteindre ses services. Vous pouvez autoriser ou refuser les requêtes en fonction suivantes:
- Adresses et plages d'adresses IPv4 et IPv6 (CIDR)
- Code pays (zone géographique)
- Filtrage de couche 7
Ces fonctionnalités vous permettent de limiter les téléchargements de contenu aux utilisateurs situés dans des emplacements spécifiques où des restrictions de licence de contenu sont appliquées, de n'autoriser que les adresses IP d'entreprise à accéder aux points de terminaison de test ou de préproduction, et de refuser une liste d'adresses connues associées à des clients malveillants.
Vous pouvez décorer les requêtes autorisées par Google Cloud Armor en insérant des en-têtes personnalisés avec des noms et des valeurs configurables.
Les règles de sécurité Google Cloud Armor s'appliquent à tout le contenu diffusé à partir de Media CDN, y compris les contenus mis en cache et les défauts de cache (miss).
Les stratégies de sécurité Google Cloud Armor sont configurées Service Media CDN : toutes les requêtes destinées au service Les règles de sécurité sont appliquées de manière cohérente sur les adresses IP ou les noms d'hôte. Différentes stratégies de sécurité peuvent être appliquées à différents services, et vous pouvez créer plusieurs services pour différentes zones géographiques si nécessaire.
Pour une protection plus précise du contenu au niveau de l'utilisateur, nous vous recommandons d'utiliser des URL signées et des cookies signés conjointement avec une stratégie Google Cloud Armor.
Media CDN ne tient pas compte de l'en-tête referer
pendant
l'évaluation des règles de sécurité périphériques avec filtrage d'en-tête de couche 7
définie sur l'une des valeurs suivantes:
- URL multiples
- Une URL relative
- URL absolues valides contenant des informations utilisateur ou un composant de fragment
Configurer les règles de sécurité
Utilisez les instructions suivantes pour configurer une stratégie de sécurité.
Avant de commencer
Pour associer une stratégie de sécurité Google Cloud Armor à un service Media CDN, assurez-vous que les conditions suivantes sont remplies :
- Vous familiariser avec Google Cloud Armor.
- Vous disposez déjà d'un service Media CDN. auxquelles vous souhaitez appliquer la stratégie.
- Activer la journalisation sur Media CDN (facultatif, mais recommandé) pour identifier les requêtes bloquées.
Vous devez également disposer des autorisations IAM (Identity and Access Management) suivantes pour autoriser, créer et associer des stratégies de sécurité à un service Media CDN :
compute.securityPolicies.addAssociation
compute.securityPolicies.create
compute.securityPolicies.delete
compute.securityPolicies.get
compute.securityPolicies.list
compute.securityPolicies.update
compute.securityPolicies.use
Les utilisateurs qui doivent associer un certificat existant à un service Media CDN ne nécessitent que les autorisations IAM suivantes :
compute.securityPolicies.get
compute.securityPolicies.list
compute.securityPolicies.use
Le rôle roles/networkservices.edgeCacheUser
inclut toutes ces autorisations.
Créer une stratégie de sécurité
Les stratégies de sécurité Google Cloud Armor sont composées de plusieurs règles, chaque règle définissant un ensemble de critères de correspondance de requête (une expression) ainsi qu'une action. Par exemple, une expression peut contenir une logique de correspondance pour les clients situés en Inde avec une action associée consistant à allow
. Si
ne correspond pas à la règle, Google Cloud Armor continue d'évaluer
la règle suivante, tant que toutes les règles n'ont pas été tentées.
Les règles de sécurité disposent d'une règle par défaut ayant une action allow
. La valeur par défaut
autorise les requêtes qui ne correspondent pas aux règles précédentes. Il peut être remplacé par
Règle deny
lorsque vous souhaitez ne allow
que les requêtes correspondant aux règles précédentes
et rejetter tous les autres.
L'exemple suivant montre comment créer une règle qui bloque tous les clients géolocalisés en Australie avec un code HTTP 403 et autorise toutes les autres requêtes.
gcloud
Pour créer une règle de type CLOUD_ARMOR_EDGE
, utilisez la
Commande gcloud compute security-policies create
:
gcloud compute security-policies create block-australia \ --type="CLOUD_ARMOR_EDGE" --project="PROJECT_ID"
Cela crée une stratégie avec une règle d'autorisation par défaut associée à la priorité la plus basse (priority: 2147483647
) :
Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/securityPolicies/block-australia].
Vous pouvez ensuite ajouter une règle avec une priorité plus élevée :
gcloud compute security-policies rules create 1000 \ --security-policy=block-australia --description "block AU" \ --expression="origin.region_code == 'AU'" --action="deny-403"
Le résultat est le suivant :
Updated [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/securityPolicies/block-australia].
Terraform
Si vous inspectez la stratégie, vous pouvez voir deux règles : la première règle bloque les requêtes provenant d'Australie (origin.region_code == 'AU'
) et la deuxième règle, dont la priorité est plus faible, autorise tout le trafic ne correspondant pas à la ou aux règles de priorité supérieure.
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
Ajouter des règles à une stratégie de sécurité
Les stratégies de sécurité Google Cloud Armor sont des ensembles de règles des attributs de couche 7 pour protéger les applications externes ou services. Chaque règle est évaluée en fonction du trafic entrant.
Ces attributs peuvent être utilisés pour les requêtes HTTP dans les règles de sécurité:
request.headers
, request.method
, request.path
, request.scheme
et
request.query
Pour en savoir plus sur l'écriture d'expressions pour les règles de stratégie de sécurité, consultez la documentation de référence sur le langage des règles personnalisées Google Cloud Armor.
Une règle de stratégie de sécurité Google Cloud Armor consiste en une condition de correspondance et une action à entreprendre lorsque cette condition est remplie.
gcloud
Pour créer une règle pour une stratégie de sécurité, utilisez la commande gcloud compute security-policies rules create PRIORITY
.
Remplacez PRIORITY
par la priorité de la règle dans la stratégie :
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
Associer une stratégie à un service
gcloud
Pour associer une stratégie Google Cloud Armor existante à un
service Media CDN, utilisez le
Commande gcloud edge-cache services update
:
gcloud edge-cache services update MY_SERVICE \ --edge-security-policy=SECURITY_POLICY
Mettre à jour une règle dans une stratégie de sécurité
Suivez ces instructions pour mettre à jour une seule règle dans une stratégie de sécurité Google Cloud Armor. Vous pouvez également mettre à jour de manière atomique plusieurs règles dans une stratégie de sécurité.
gcloud
Exécutez la commande gcloud compute security-policies rules update
:
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 ]
Par exemple, la commande suivante met à jour une règle ayant la priorité 1111 pour autoriser le trafic provenant de la plage d'adresses IP 192.0.2.0/24 :
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"
Pour mettre à jour la priorité d'une règle, vous devez utiliser l'API REST. Pour plus
consultez les
Méthode securityPolicies.patchRule
.
Afficher une association de stratégie
Pour examiner quelle stratégie est associée à un service existant, inspectez (description) pour ce service.
gcloud
Pour afficher la stratégie Google Cloud Armor associée à un
service Media CDN, utilisez le
Commande gcloud edge-cache services describe
:
gcloud edge-cache services describe MY_SERVICE
Le champ edgeSecurityPolicy
du service décrit la stratégie associée :
name: "MY_SERVICE" edgeSecurityPolicy: "SECURITY_POLICY
Supprimer une stratégie
Pour supprimer une règle existante, mettez à jour le service associé et transmettez une valeur comme stratégie.
gcloud
Exécutez la commande gcloud edge-cache services update
:
gcloud edge-cache services update MY_SERVICE
--edge-security-policy=""
Le champ edgeSecurityPolicy
est désormais omis dans le résultat de la commande gcloud edge-cache services describe MY_SERVICE
.
Examples
Voici plusieurs cas d'utilisation détaillés fournis à titre d'exemple.
Exemple: Identifier les requêtes bloquées
Vous devez avoir la journalisation activée pour un Edge donné Service de cache permettant de consigner les requêtes bloquées.
Les requêtes autorisées ou refusées par une stratégie de filtrage sont consignées dans Logging. Pour filtrer les requêtes refusées, la requête Logging suivante pour la configuration prod-video-service
ressemblerait à ceci :
resource.type="edge_cache_service" jsonPayload.statusDetails="denied_by_security_policy"
Exemple: Personnaliser les codes de réponse
Les règles Google Cloud Armor peuvent être configurées pour que leur action associée consiste à renvoyer un code d'état spécifique. Dans la plupart des cas, il est préférable de renvoyer un code HTTP 403 (deny-403
) pour indiquer clairement que le client a été bloqué par la règle.
Les codes d'état compatibles sont les suivants :
- HTTP 403 (interdit)
- HTTP 404 (introuvable)
- HTTP 502 (passerelle incorrecte)
L'exemple suivant montre comment configurer le code d'état renvoyé :
Pour spécifier l'une des valeurs [allow | deny-403 | deny-404 | deny-502]
comme action associée à la règle, exécutez la commande suivante. Cet exemple configure la règle pour qu'elle renvoie une réponse HTTP 502.
gcloud compute security-policies rules create 1000 \ --security-policy=block-australia --description "block AU" \ --expression="origin.region_code == 'AU'" --action="deny-502"
Chaque règle d'une stratégie de sécurité peut définir une réponse de code d'état différente.
Exemple : Refuser les clients situés en dehors d'un pays, à l'exception des adresses IP autorisées
Un cas d'utilisation courant de diffusion de contenus multimédias consiste à refuser les connexions de clients situés en dehors de la région pour laquelle vous disposez de licences de contenu ou de mécanismes de paiement.
Par exemple, vous pouvez autoriser uniquement les clients situés en Inde, ainsi que
Toutes les adresses IP figurant dans la liste d'autorisation, y compris celles des partenaires de contenu
et vos propres employés, dans la plage 192.0.2.0/24
, et refuser tous les autres.
L'expression suivante permet d'obtenir ce résultat en utilisant le langage de règles personnalisées de Google Cloud Armor :
origin.region_code == "IN" || inIpRange(origin.ip, '192.0.2.0/24')
Cette expression est configurée en tant que règle allow
, avec une règle deny
par défaut configurée pour être mise en correspondance avec tous les autres clients. Les stratégies de sécurité ont toujours une règle par défaut.
Vous configurez généralement cette option pour refuser par défaut (default deny
) tout trafic que vous n'autorisez pas explicitement. Dans d'autres cas, vous pouvez choisir de bloquer une partie du trafic et d'autoriser par défaut (default allow
) tout le trafic restant.
Dans la sortie de stratégie de sécurité, notez les points suivants :
- La règle ayant la priorité la plus élevée (
priority: 0
) autorise le trafic provenant de l'Inde OU de la liste d'adresses IP définie. - La règle de priorité la plus basse refuse par défaut (
default deny
) tout le trafic. Le moteur de règles refuse tous les clients que les règles de priorité supérieure n'évaluent pas comme "true". - Vous pouvez combiner plusieurs règles en utilisant opérateurs booléens.
La règle autorise le trafic provenant de clients en Inde, d'une plage d'adresses IP définie, et refuse tout autre trafic.
Lorsque vous affichez les détails de la stratégie, le résultat se présente comme suit:
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
Vous pouvez également définir un en-tête de réponse personnalisé avec la variable d'en-tête {region_code}
. Cet en-tête peut être inspecté à l'aide de
JavaScript et reflétées dans le client.
Exemple : Bloquer les clients malveillants en utilisant des adresses IP et des plages d'adresses IP
L'expression suivante permet d'obtenir ce résultat en utilisant le langage de règles personnalisées de Google Cloud Armor :
inIpRange(origin.ip, '192.0.2.2/32') || inIpRange(origin.ip, '192.0.2.170/32')
Vous pouvez bloquer les plages d'adresses IP jusqu'à un masque /8
en IPv4 et /32
en IPv6. Un cas d'utilisation courant pour les plates-formes de streaming consiste à bloquer les plages d'adresses IP de sortie des proxys ou des fournisseurs VPN afin de minimiser le contournement des licences de contenu :
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')
Les plages d'adresses IPv4 et IPv6 sont toutes deux acceptées.
Exemple : N'autoriser qu'une liste fixe de zones géographiques
Si vous disposez d'une liste de codes pays, vous pouvez utiliser l'opérateur booléen OR ||
pour
combiner les conditions de correspondance.
L'expression suivante permet d'autoriser les utilisateurs identifiés comme provenant d'Australie ou de Nouvelle-Zélande en utilisant le langage de règles personnalisées de Google Cloud Armor :
origin.region_code == "AU" || origin.region_code == "NZ"
Vous pouvez également l'associer à des expressions origin.ip
ou inIpRange(origin.ip,
'...')
pour autoriser les testeurs, les partenaires et vos plages d'adresses IP d'entreprise.
même s'ils ne proviennent pas de l'une des zones géographiques spécifiées.
Il existe un nombre documenté de sous-expressions pour chaque règle avec une expression personnalisée. Si vous devez combiner plus de sous-expressions, définissez plusieurs règles au sein d'une même stratégie.
Exemple : Bloquer les clients d'un ensemble spécifique de pays
Un exemple moins courant peut consister à bloquer les clients d'un certain ensemble de pays, mais à autoriser par ailleurs les requêtes provenant de tous les autres pays.
Pour ce faire, vous devez créer une règle qui bloque à la fois le pays et les clients dont la région ne peut pas être déterminée, puis basculer sur une règle d'autorisation par défaut pour toutes les autres requêtes.
L'exemple suivant décrit une stratégie qui bloque les clients provenant du Canada ainsi que tous les clients dont l'emplacement est inconnu, mais qui autorise tout le trafic restant :
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
Exemple: Refuser les requêtes de contenu mis en cache avec des en-têtes spécifiques
Une règle de sécurité périphérique s'applique à toutes les requêtes ciblant un service Media CDN auquel à laquelle la stratégie est associée. Cette application de la règle a lieu avant toute recherche dans le cache. Les requêtes non autorisées par la stratégie de sécurité périphérique sont refusées avec le code d'état configuré.
L'expression suivante met en correspondance les requêtes provenant de l'adresse IP 1.2.3.4
contenant la chaîne user1
dans l'en-tête user-agent
:
inIpRange(origin.ip, '1.2.3.4/32') && request.headers['user-agent'].contains('user1')
La commande suivante ajoute la règle de filtrage 105
à la stratégie de sécurité périphérique
my-edge-policy
, qui est associé à un service Media CDN:
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"
Journaliser les actions d'application
Chaque journal de requêtes fournit des détails sur la stratégie de sécurité appliquée et sur l'autorisation (ALLOW
) ou le refus (DENY
) de la requête.
Pour activer la journalisation, assurez-vous que logConfig.enable
est défini sur true
sur votre service. Les services sans journaux ne consignent pas les événements liés aux stratégies de sécurité.
Lorsqu'un client se trouve en dehors des États-Unis et qu'une stratégie de sécurité appelée deny-non-us-clients
qui refuse les requêtes provenant de l'extérieur des États-Unis est appliquée, voici à quoi ressemble l'entrée de journal d'une requête refusée :
enforcedSecurityPolicy: name: deny-non-us-clients outcome: DENY
Les services sans stratégie Google Cloud Armor ont un enforcedSecurityPolicy.name
défini sur no_policy
et un outcome
défini sur ALLOW
. Par exemple, une entrée de journal de requêtes pour un service sans stratégie a les valeurs suivantes :
enforcedSecurityPolicy: name: no_policy outcome: ALLOW
Comprendre les classifications GeoIP
Media CDN s'appuie sur la classification des adresses IP internes de Google sources de données permettant de déterminer une zone géographique (région, État, province ou ville) à partir d'une adresse IP adresse e-mail. Si vous migrez ou répartissez le trafic entre plusieurs fournisseurs, un petit nombre d'adresses IP peut parfois être associé à des emplacements différents.
- Google Cloud Armor utilise les codes de région ISO 3166-1 alpha 2 pour associer un client à un emplacement géographique.
- Par exemple,
US
pour les États-Unis ouAU
pour l'Australie. - Dans certains cas, une région correspond à un pays, mais ce n'est pas toujours le cas. Par exemple, le code
US
comprend tous les États des États-Unis, un district et six zones périphériques. - Pour plus d'informations, consultez la section unicode_region_subtag de la spécification Unicode Technical Standard.
- Pour les clients pour lesquels l'emplacement ne peut pas être dérivé,
origin.region_code
est défini surZZ
.
Vous pouvez ajouter des données géographiques aux en-têtes de réponse envoyés à un point de terminaison Media CDN (avec routing.routeRules[].headerActions[].responseHeadersToAdd[]
) ou refléter les données géographiques fournies dans une fonction Cloud Function afin de valider les éventuelles différences entre les sources de données geoIP lors de l'intégration initiale et des tests.
En outre, les journaux de requêtes Media CDN incluent le clientRegion
ainsi que d'autres données spécifiques au client que vous pouvez valider par rapport à vos sources de données existantes.
Étapes suivantes
- Découvrez comment utiliser les requêtes signées pour autoriser le contenu en fonction de l'utilisateur.
- Consultez la documentation de référence sur les règles Google Cloud Armor. pour comprendre comment les règles de correspondance IP et géographique peuvent être exprimées, réunis.
- Consultez la documentation de Logging pour savoir comment interroger les journaux de requêtes et vérifier quelles requêtes ont été bloquées.