Show Menu
TOPICS×

Liste de contrôle de sécurité de Dispatcher

Dispatcher comme système frontal offre une couche supplémentaire de sécurité à l’infrastructure Adobe Experience Manager. Adobe vous recommande vivement de suivre la liste de contrôle suivante avant de passer en production.
Vous devez également suivre la liste de contrôle de sécurité de votre version d’AEM avant de passer en production. Reportez-vous à la documentation d’Adobe Experience Manager correspondante.

Utilisation de la version la plus récente de Dispatcher

Il est conseillé d’installer la dernière version disponible pour votre plate-forme. Vous devez mettre à niveau votre instance de Dispatcher afin d’utiliser la version la plus récente. Cela vous permet de tirer parti des améliorations du produit et de la sécurité. Voir Installation de Dispatcher .
Vous pouvez vérifier la version actuelle de votre installation de Dispatcher en consultant le fichier journal de ce dernier.
[Thu Apr 30 17:30:49 2015] [I] [23171(140735307338496)] Dispatcher initialized (build 4.1.9)
Pour trouver le fichier journal, consultez la configuration de Dispatcher de
httpd.conf
.

Limitation des clients qui peuvent vider le cache

Activation du protocole HTTPS pour la sécurité des couches de transfert

Adobe conseille d’activer la couche de transfert HTTPS sur les instances de création et de publication.

Limitation de l’accès

Lors de la configuration de Dispatcher, vous devez limiter l’accès externe autant que possible. Voir Exemple de section /filter dans la documentation de Dispatcher.

S’assurer que l’accès aux URL d’administration est refusé

Assurez-vous d’utiliser des filtres pour bloquer l’accès externe aux URL d’administration, par exemple la console web.
Voir Test de la sécurité de Dispatcher pour obtenir une liste des URL qui doivent être bloquées.

Utilisation des listes blanches au lieu des listes noires

Les listes blanches sont le meilleur moyen de fournir un contrôle d’accès puisque, par nature, elles partent du principe que toutes les demandes d’accès doivent être refusées, à moins qu’elles ne se trouvent explicitement sur la liste blanche. Ce modèle fournit un contrôle plus restrictif des nouvelles demandes qui peuvent ne pas avoir encore été testées ou prises en compte lors d’une étape spécifique de la configuration.

Exécution de Dispatcher avec un utilisateur système dédié

Lors de la configuration de Dispatcher, assurez-vous que le serveur web est exécuté par un utilisateur dédié, doté de privilèges limités. Il est conseillé d’octroyer uniquement l’accès en écriture au dossier du cache de Dispatcher.
En outre, les utilisateurs IIS doivent configurer leur site web comme suit :
  1. Dans le paramètre de chemin d’accès physique du site web, sélectionnez
    Se connecter comme utilisateur spécifique
    .
  2. Définissez l’utilisateur.

Prévention des attaques par déni de service (DoS)

Une attaque par déni de service (DoS) est une tentative de rendre une ressource informatique indisponible à ses utilisateurs ciblés.
Au niveau de Dispatcher, il existe deux méthodes de configuration afin d’empêcher les attaques DoS : filter
  • Utilisez le module mod_rewrite (par exemple Apache 2.4 ) pour effectuer des validations d’URL (si les règles de modèle d’URL ne sont pas trop complexes).
  • Empêchez Dispatcher de mettre en cache les URL dotées d’extensions parasites à l’aide de filtres . Par exemple, modifiez les règles de mise en cache afin de limiter la mise en cache des types MIME prévus, par exemple :
    • .html
    • .jpg
    • .gif
    • .swf
    • .js
    • .doc
    • .pdf
    • .ppt
      Un exemple de fichier de configuration peut être consulté pour limiter l’accès externe . Il comprend les limitations pour les types MIME.
Pour activer la fonctionnalité complète sur les instances de publication en toute sécurité, configurez les filtres pour empêcher l’accès aux nœuds suivants :
  • /etc/
  • /libs/
Ensuite, configurez les filtres pour accorder l’accès aux chemins d’accès des nœuds suivants :
  • /etc/designs/*
  • /etc/clientlibs/*
  • /etc/segmentation.segment.js
  • /libs/cq/personalization/components/clickstreamcloud/content/config.json
  • /libs/wcm/stats/tracker.js
  • /libs/cq/personalization/*
    (JS, CSS et JSON)
  • /libs/cq/security/userinfo.json
    (Informations sur les utilisateurs CQ)
  • /libs/granite/security/currentuser.json
    (
    les données ne doivent pas être mises en cache
    )
  • /libs/cq/i18n/*
    (Internalisation)

Configuration de Dispatcher pour empêcher les attaques par falsification de requête intersites (CSRF, Cross Site Request Forgery)

AEM fournit une infrastructure visant à empêcher les attaques par falsification de requête intersites. Pour utiliser correctement cette structure, vous devez mettre en liste blanche la prise en charge du jeton CSRF dans Dispatcher. Vous pouvez le faire en procédant comme suit :
  1. Créez un filtre pour autoriser le chemin d’accès
    /libs/granite/csrf/token.json
     ;
  2. Ajoutez l’en-tête
    CSRF-Token
    à la section
    clientheaders
    de la configuration Dispatcher.

Prévention du détournement de clic

Pour empêcher le détournement de clic, il est conseillé de configurer le serveur web afin que l’en-tête HTTP
X-FRAME-OPTIONS
soit défini sur
SAMEORIGIN
.

Test de pénétration

Adobe recommande vivement d’effectuer un test de pénétration de l’infrastructure AEM avant la mise en production.