Documentation AEM Tutoriels AEM Tutoriels d’AEM as a Cloud Service

Protection des sites web AEM à l’aide de règles de filtrage du trafic standard

Last update: Tue Aug 19 2025 00:00:00 GMT+0000 (Coordinated Universal Time)

S'applique à :
Experience Manager as a Cloud Service

Rubriques :

Créé pour :

Intermédiaire
Administration
Développeur

Découvrez comment protéger les sites web AEM contre les attaques de déni de service (DoS), de déni de service distribué (DDoS) et les abus de robots à l’aide des règles de filtrage de trafic standard recommandées par Adobe dans AEM as a Cloud Service.

https://video.tv.adobe.com/v/3469396/?quality=12&learn=on

Objectifs d’apprentissage

Examinez les règles de filtrage de trafic standard recommandées par Adobe.
Définissez, déployez, testez et analysez les résultats des règles.
Découvrez à quel moment et de quelle façon affiner les règles en fonction des modèles de trafic.
Découvrez comment utiliser le Centre d’actions AEM pour passer en revue les alertes générées par les règles.

Vue d’ensemble de l’implémentation

Les étapes de mise en œuvre sont les suivantes :

Ajout des règles de filtrage de trafic standard au fichier /config/cdn.yaml du projet WKND d’AEM.
Validation et envoi des modifications au référentiel Git de Cloud Manager.
Déploiement des modifications dans l’environnement AEM à l’aide du pipeline de configuration de Cloud Manager.
Test des règles en simulant une attaque DoS à l’aide de Vegeta.
Analyse des résultats à l’aide des journaux du réseau CDN AEMCS et de l’outil de tableau de bord ELK.

Prérequis

Avant de poursuivre, assurez-vous d’avoir terminé le travail préparatoire requis, comme décrit dans le tutoriel Configuration du filtre de trafic et des règles WAF. En outre, vous avez cloné et déployé le projet AEM WKND Sites dans votre environnement AEM.

Actions clés des règles

Avant d’examiner en détail les règles de filtrage de trafic standard, décrivons les actions clés qu’elles effectuent. L’attribut action dans chaque règle définit la manière dont le filtre de trafic doit répondre lorsque les conditions sont remplies. Les actions sont les suivantes :

Journal : les règles consignent les événements pour la surveillance et l’analyse, ce qui vous permet de consulter les modèles de trafic et d’ajuster les seuils si nécessaire. Ceci est spécifié par l’attribut type: log.
Alerte : les règles déclenchent des alertes lorsque les conditions sont remplies, ce qui vous aide à identifier les problèmes potentiels. Ceci est spécifié par l’attribut alert: true.
Bloquer : les règles bloquent le trafic lorsque les conditions sont remplies, empêchant ainsi l’accès à votre site AEM. Ceci est spécifié par l’attribut action: block.

Vérifier et définir les règles

Les règles de filtrage de trafic standard recommandées par Adobe constituent une couche fondamentale pour identifier les modèles de trafic potentiellement malveillants en consignant les événements tels que le dépassement des limites de débit basées sur les adresses IP et en bloquant le trafic provenant de pays spécifiques. Ces journaux aident les équipes à valider les seuils et à prendre des décisions éclairées pour la transition finale des règles vers le mode bloc sans interrompre le trafic légitime.

Examinons les trois règles de filtrage de trafic standard que vous devez ajouter au fichier /config/cdn.yaml du projet WKND d’AEM :

Empêcher les attaques DoS au niveau du serveur Edge: cette règle détecte d’éventuelles attaques par déni de service (DoS) au niveau du serveur Edge du réseau CDN en surveillant les requêtes par seconde (RPS) provenant des adresses IP client.
Empêcher les attaques DoS à l’origine: cette règle détecte les éventuelles attaques par déni de service (DoS) à l’origine en surveillant les requêtes de récupération provenant des adresses IP clientes.
Bloquer les pays de l’OFAC : cette règle bloque l’accès à des pays spécifiques qui relèvent des restrictions de l’OFAC (Office of Foreign Assets Control, Bureau du contrôle des avoirs étrangers) américain.

1. Empêcher les attaques DoS sur le serveur Edge

Cette règle envoie une alerte lorsqu’elle détecte une attaque par déni de service (DoS) potentielle sur le réseau CDN. Le critère de déclenchement de cette règle est le suivant : lorsqu’un client dépasse 500 requêtes par seconde (en moyenne sur 10 secondes) par POP (point de présence) de réseau CDN au niveau du serveur Edge.

Elle comptabilise toutes les requêtes et les regroupe par adresse IP du client.

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev", "stage", "prod"]
data:
  trafficFilters:
    rules:
    - name: prevent-dos-attacks-edge
      when:
        reqProperty: tier
        equals: 'publish'
      rateLimit:
        limit: 500
        window: 10
        penalty: 300
        count: all
        groupBy:
          - reqProperty: clientIp
      action:
        type: log
        alert: true

L’attribut action spécifie que la règle doit consigner les événements et déclencher une alerte lorsque les conditions sont remplies. Il vous permet donc de surveiller les attaques par déni de service potentielles sans bloquer le trafic légitime. Cependant, votre objectif est de passer finalement cette règle en mode bloc une fois que vous avez validé les modèles de trafic et ajusté les seuils.

2. Empêcher les attaques par déni de service à l’origine

Cette règle envoie une alerte lorsqu’elle détecte une attaque par déni de service (DoS) potentielle à l’origine. Le critère de déclenchement de cette règle est le suivant : lorsqu’un client dépasse 100 requêtes par seconde (en moyenne sur 10 secondes) par adresse IP du client à l’origine.

Il compte les récupérations (requêtes de contournement du cache) et les regroupe par adresse IP du client.

...
    - name: prevent-dos-attacks-origin
      when:
        reqProperty: tier
        equals: 'publish'
      rateLimit:
        limit: 100
        window: 10
        penalty: 300
        count: fetches
        groupBy:
          - reqProperty: clientIp
      action:
        type: log
        alert: true

3. Bloquer les pays OFAC

Cette règle bloque l’accès de pays spécifiques soumis à des restrictions OFAC.
Vous pouvez consulter et modifier la liste des pays selon vos besoins.

...
    - name: block-ofac-countries
      when:
        allOf:
          - { reqProperty: tier, in: ["author", "publish"] }
          - reqProperty: clientCountry
            in:
              - SY
              - BY
              - MM
              - KP
              - IQ
              - CD
              - SD
              - IR
              - LR
              - ZW
              - CU
              - CI
      action: block

L’attribut action indique que la règle doit bloquer l’accès à partir des pays spécifiés. Cela vous permet d’empêcher l’accès à votre site AEM à partir de régions pouvant présenter des risques de sécurité.

Le fichier cdn.yaml complet avec les règles ci-dessus ressemble à ceci :

Règles YAML du CDN WKND

Déployer les règles

Pour déployer les règles ci-dessus, procédez comme suit :

Validez et envoyez les modifications au référentiel Git de Cloud Manager.
Déployez les modifications dans l’environnement AEM à l’aide du pipeline de configuration Cloud Manager créé précédemment.

Tester les règles

Pour vérifier l’efficacité des règles de filtrage du trafic standard, au niveau de la périphérie du réseau CDN et du réseau d’origine, simulez un trafic élevé de requêtes à l’aide de Vegeta, un outil de test de charge HTTP polyvalent.

Testez la règle DoS au niveau de la périphérie (limite de 500 rps). La commande suivante simule 200 requêtes par seconde pendant 15 secondes, ce qui dépasse le seuil de la périphérie (500 rps).

code language-shell
`$echo "GET https://publish-p63947-e1249010.adobeaemcloud.com/us/en.html" \| vegeta attack -rate=200 -duration=15s \| vegeta report`

Attaque DoS Vegeta Edge

note important
IMPORTANT
Notez les codes de succès 100 % et de statut 200 dans le rapport ci-dessus. Comme les règles sont définies sur `log` et `alert`, les requêtes ne sont pas bloquées mais elles sont consignées à des fins de surveillance, d’analyse et d’alerte.

Testez la règle DoS à l’origine (limite de 100 rps). La commande suivante simule 110 requêtes de récupération par seconde pendant 1 seconde, ce qui dépasse le seuil de l’origine (100 rps). Pour simuler les requêtes de contournement du cache, le fichier targets.txt est créé avec des paramètres de requête uniques afin de s’assurer que chaque requête est traitée comme une requête de récupération.

code language-shell

code language-shell
`# Create targets.txt with unique query parameters $for i in {1..110}; do echo "GET https://publish-p63947-e1249010.adobeaemcloud.com/us/en.html?ts=$(date +%s)$i" done > targets.txt # Use the targets.txt file to simulate fetch requests $vegeta attack -rate=110 -duration=1s -targets=targets.txt \| vegeta report`

# Create targets.txt with unique query parameters
$for i in {1..110}; do
  echo "GET https://publish-p63947-e1249010.adobeaemcloud.com/us/en.html?ts=$(date +%s)$i"
done > targets.txt

# Use the targets.txt file to simulate fetch requests
$vegeta attack -rate=110 -duration=1s -targets=targets.txt | vegeta report

Attaque DoS Vegeta de l’origine

note important
IMPORTANT
Notez les codes de succès 100 % et de statut 200 dans le rapport ci-dessus. Comme les règles sont définies sur `log` et `alert`, les requêtes ne sont pas bloquées mais elles sont consignées à des fins de surveillance, d’analyse et d’alerte.

Pour des raisons de simplicité, la règle OFAC n’est pas testée ici.

Vérifier les alertes

Des alertes sont générées lorsque les règles de filtrage du trafic sont déclenchées. Vous pouvez consulter ces alertes dans le Centre d’actions AEM.

Centre d’actions WKND AEM

Analyser les résultats

Pour analyser les résultats des règles de filtrage du trafic, vous pouvez utiliser les journaux du réseau CDN AEMCS et l’outil de tableau de bord ELK. Suivez les instructions de la section de configuration de l’ingestion des journaux CDN pour ingérer les journaux CDN dans la pile ELK.

Dans la capture d’écran suivante, vous pouvez voir les journaux CDN de l’environnement de développement AEM ingérés dans la pile ELK.

Journaux CDN WKND ELK

Dans l’application ELK, le tableau de bord de trafic CDN doit afficher le pic au niveau de la périphérie et de l’origine lors des attaques par déni de service simulées.

Les deux panneaux, RPS de la périphérie par IP client et POP et RPS de l’origine par IP client et POP, affichent les requêtes par seconde (RPS) au niveau du serveur à la périphérie et d’origine, respectivement, regroupées par adresse IP client et par point de présence (POP).

Tableau de bord du trafic de la périphérie du réseau CDN WKND

Vous pouvez également utiliser d’autres panneaux dans le tableau de bord du trafic CDN pour analyser les modèles de trafic, tels que Principales adresses IP client, Principaux pays et Principaux agents utilisateur. Ces panneaux vous aident à identifier les menaces potentielles et à ajuster vos règles de filtrage du trafic en conséquence.

Intégration Splunk

Les clientes et clients qui ont activé le transfert de journal Splunk peuvent créer un tableau de bord pour analyser les modèles de trafic.

Pour créer des tableaux de bord dans Splunk, suivez les étapes Tableau de bord Splunk pour l’analyse de journaux de réseau CDN AEMCS.

La capture d’écran suivante présente un exemple de tableau de bord Splunk qui affiche le nombre maximal de requêtes d’origine et de la périphérie par adresse IP, ce qui peut vous aider à identifier les attaques par déni de service potentielles.

Tableau de bord Splunk - Nombre maximal de requêtes d’origine et de périphérie par adresse IP

Quand et comment affiner les règles

Votre objectif est d’éviter de bloquer le trafic légitime tout en protégeant votre site AEM des menaces potentielles. Les règles de filtrage du trafic standard sont conçues pour alerter et consigner (et finalement bloquer lorsque le mode est changé) les menaces sans bloquer le trafic légitime.

Pour affiner les règles, prenez en compte les étapes suivantes :

Surveiller les modèles de trafic : utilisez les journaux du réseau CDN et le tableau de bord ELK pour surveiller les modèles de trafic et identifier les anomalies ou les pics de trafic.

Ajuster les seuils : en fonction des modèles de trafic, ajustez les seuils (augmentez ou réduisez les limites de taux) dans les règles pour mieux répondre à vos besoins spécifiques. Par exemple, si vous constatez que le trafic légitime a déclenché les alertes, vous pouvez augmenter les limites de taux ou ajuster les regroupements.
Le tableau suivant fournit des recommandations pour choisir les valeurs de seuil :

table 0-row-2 1-row-2 2-row-2 1-align-left 2-align-left 4-align-left 5-align-left 7-align-left 8-align-left
Variante	Valeur
Origine	Prenez la valeur la plus élevée du nombre maximum de requêtes à l’origine par adresse IP/PoP dans des conditions normales de trafic (c’est-à-dire, pas lors d’un DDoS) et multipliez-la.
Edge	Prenez la valeur la plus élevée du nombre maximum de requêtes Edge par adresse IP/PoP dans des conditions normales de trafic (c’est-à-dire, pas lors d’un DDoS) et multipliez-la.

Consultez également la section Choix des valeurs de seuil pour plus d’informations.

Passer aux règles de blocage : une fois que vous avez validé les modèles de trafic et ajusté les seuils, vous devez passer les règles en mode bloc.

Résumé

Dans ce tutoriel, vous avez appris à protéger les sites web AEM contre les attaques de déni de service (DoS), de déni de service distribué (DDoS) et les abus de robots à l’aide des règles de filtrage de trafic standard recommandées par Adobe dans AEM as a Cloud Service.

Règles WAF recommandées

Découvrez comment mettre en œuvre les règles WAF recommandées par Adobe pour protéger vos sites web AEM contre les menaces sophistiquées qui utilisent des techniques avancées pour contourner les mesures de sécurité traditionnelles.

Protection des sites web AEM à l’aide des règles de filtrage du trafic WAF

Découvrez comment protéger les sites web AEM contre les menaces sophistiquées, y compris les attaques Dos, DDoS et les abus de robots, à l’aide des règles de filtrage du trafic WAF (Web Application Firewall) recommandées par Adobe dans AEM as a Cloud Service.

Activer le pare-feu WAF

Cas d’utilisation : au-delà des règles standard

Pour des scénarios plus avancés, vous pouvez explorer les cas d’utilisation suivants, qui montrent comment implémenter des règles de filtrage de trafic personnalisées en fonction d’exigences commerciales spécifiques :