septembre 11, 2025

Sécuriser l’AEM en tant que service cloud avec le filtre de trafic et les règles WAF

Ces derniers temps, les menaces pour les applications Web sont devenues de plus en plus courantes, notamment le déni de service (DOS), le déni de service distribué (DDOS), le trafic malveillant, comme les robots, les attaques d’injection et l’utilisation abusive des ressources système. Ces menaces, en cas de succès, peuvent entraîner des temps d’arrêt, des violations de données et une expérience utilisateur dégradée. Et c’est là que l’AEM en tant que service cloud intervient, avec des règles de filtrage de trafic intégré et de WAF, pour sécuriser les applications tout en garantissant des performances optimales.

Dans ce blog, nous couvrirons les règles des filtres de trafic et une sous-catégorie de ces règles connues sous le nom de règles de filtre de trafic WAF (application Web), ou simplement des règles WAF. Nous discuterons également de la syntaxe pour rédiger ces règles et partager quelques exemples.

Avant de plonger dans la syntaxe et des exemples, explorons d’abord où nous écrivons ces règles et comment et où nous les déploiez.

Configuration et déploiement des règles

Ainsi, en utilisant les pipelines de configuration de Cloud Manager, ces règles de trafic sont déployées dans le CDN géré par Adobe. Ils peuvent être déployés dans les environnements de développement, de stade et de production. Nous devons créer un pipeline de configuration qui déploiera les règles de trafic.

Dans le Cloud Manager, allez dans la section Pipelines.
Menu Piplines
Dans le coin droit, vous verrez Ajouter un pipeline.
Ajouter un pipeline
Sélectionnez Ajouter un pipeline de non-production.
Pipeline de non-production
Maintenant, configurez les détails comme mentionné dans la capture d’écran
Pipeline Config Section 1
Pipeline Config Section 2

Syntaxe

La syntaxe des règles de trafic se déroule comme ceci,

  kind: "CDN"
  version: "1"
  metadata:
  envTypes: ["dev"]
  Data: <traffic-filter-rules>

Ces règles de trafic sont généralement écrites cdn.yaml fichier dans le configurer Dossier dans la base de code, c’est au niveau racine. Si la configuration de tous les environnements est même, un seul fichier devrait être suffisant. Sinon, un dossier spécifique à l’environnement ou des fichiers CDN.YAML (pour Eg. CDN-STG.YAML) peuvent être créés.

CDN.yaml commun pour tous les environnements

Dossiers spécifiques à l’environnement

Un fichier YAML des règles de trafic est composé de quatre champs principaux,

gentil: identifie le type de configuration; Pour les règles de trafic, cela est toujours défini sur CDN.
version: Spécifie la version du format de configuration; AEM ne prend actuellement en charge que 1.
métadonnées: fournit un contexte supplémentaire, tel que l’environnement pour lequel les règles sont écrites, aidant à maintenir les configurations organisées.
données: La section principale où les règles du filtre de trafic sont définies, couvrant les règles standard et WAF.

Définition des règles dans le données Section

Comme mentionné ci-dessus, le champ de données maintient toutes les règles de filtre de trafic, qui peuvent être basées sur l’URL, le nom d’hôte, la géolocalisation, les IPS, les en-têtes de demande, etc. Dans l’exemple ci-dessous, l’utilisateur a essayé d’accéder à FAQs.html, mais il est retourné Erreur 406 non acceptable, qui est attendu après avoir écrit la règle du trafic.
Exemple pour les règles de filtre de trafic standard,

  kind: "CDN"
  version: "1"
  metadata:
    envTypes: ["dev"]
  data:
    trafficFilters:
      rules:
        - name: "block-path"
          when:
            allOf:
  - reqProperty: tier 
    equals: “author|publish” 
              - reqProperty: path
    equals: “/content/wknd/us/en/faqs.html”
          action:
            type: block

Message d’erreur

(Remarque: nous examinerons chaque champ dans la dernière section de ce blog.)

Si vous avez autorisé la sécurité améliorée ou la sécurité de protection WAF-DDOS, vous pouvez configurer une sous-catégorie de règles de filtre de trafic nommées Règles WAF, qui consomme un ou plusieurs indicateurs WAF.
Exemple pour les règles WAF,

  kind: "CDN"
  version: "1"
  metadata:
    envTypes: ["dev"]
  data:
    trafficFilters:
      rules:
        - name: "WAF-rule-for-XSS-and-SQL-Injection"
          when: 
  - reqProperty: path 
    like: "*"
          action:
            type: block
            wafFlags: [ XSS, SQLI]

Décomposer le données Section

À l’intérieur du champ de données du cdn.yaml, vous trouverez circulationqui contient le règles section. C’est là que toutes les règles de filtre de trafic sont écrites. Chaque règle est composée de quelques champs clés:

nom – un identifiant unique pour la règle. Il doit être alphanumérique, peut inclure des traits de tireurs et ne doit pas dépasser 64 caractères.
quand – Définit la ou les conditions sous laquelle la règle est appliquée.
- Utiliser allof Si toutes les conditions doivent être vraies.
- Utiliser anyof Si une seule condition devait être vraie.
- Pour une seule condition, vous pouvez sauter les deux.

Conditions d’écriture avec quand

Une condition a deux parties: un Getter (quoi vérifier) et un prédicat (comment l’évaluer).
Syntaxe pour un seul état:

  when:
    - <getter>: <value>
      <predicate>: <value>

Conditions multiples:

  when:
    allOf:
      - <getter>: <value>
        <predicate>: <value>
      - <getter>: <value>
        <predicate>: <value>

Getters et prédicats

Getters dit à la règle quelle partie de la demande d’inspecter, telle que:
- reqproperty => chemin, URL, chaîne de requête, méthode, IP client, région, pays
- reqheader, queryparam, reqcookie, postparam => requête en-têtes, paramètres de requête, cookies ou données post
Les prédicats définissent comment la valeur doit être vérifiée:
- équivaut, ne fait pas lequal => comparaison directe
- comme, correspond à un motif ou à la correspondance regex
- dans, notin => lister l’adhésion
- existe => présence de propriété

Le action Champ

Le action Le champ définit ce qui se passe lorsqu’une condition est remplie. Les options incluent:

Permettre – Permet à la demande de passer si elle correspond à la règle.
Bloc – refuse complètement la demande. Ceci est couramment utilisé lorsqu’il s’agit de trafic malveillant, de motifs suspects ou de gauflags spécifiques.
Enregistrer – Il enregistre les détails de la demande de surveillance sans blocage ni autorisation.
Ou une combinaison de ceux-ci avec des wafflags pour le filtrage avancé.

En utilisant gauflags

Si vous avez une protection améliorée de sécurité ou de WAF-DDOS activée, vous pouvez utiliser des wafflags pour bloquer des menaces spécifiques, telles que:

XSS (script inter-sites)
SQLI (injection SQL)
Bad-ip, porte dérobée, exploits CVE
Data malformed, json-error, xml-error

Ce ne sont que quelques exemples; Il y en a plus dans la liste.

Exemple: règle WAF

  kind: "CDN"
  version: "1"
  metadata:
    envTypes: ["dev"]
  data:
    trafficFilters:
      rules:
        - name: "WAF-rule-for-XSS-and-SQL-Injection"
          when: 
            - reqProperty: path 
              like: "*"
          action:
            type: block
            wafFlags: [XSS, SQLI]

Avec les règles du filtre du trafic et les règles de WAF, AEM en tant que service cloud Vous permet de cesser de demander des demandes nuisibles avant d’atteindre votre demande. Un CDN.YAML bien structuré renforce non seulement la sécurité, mais assure également une expérience fluide et ininterrompue pour vos utilisateurs. Commencez à appliquer ces règles aujourd’hui pour renforcer votre sécurité Cloud AEM.

Vous avez trouvé cela utile? PARTAGEZ-LE

Blog ARC Optimizer