Vous consultez actuellement l'aide de la version:

Cette section traite des différentes étapes à suivre pour s’assurer que votre installation AEM est sécurisée une fois déployée. La liste de contrôle doit être appliquée de haut en bas.

Remarque :

D’autres considérations relatives à la sécurité s’appliquent à la phase de développement.

Principales mesures de sécurité

Exécution d’AEM en mode prêt pour la production

Pour plus d’informations, voir Exécution d’AEM en mode prêt pour la production.

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

Pour une instance sécurisée, il est obligatoire d’activer la couche de transfert HTTPS sur les instances de création et de publication.

Remarque :

Pour plus d’informations, voir la section Activation de HTTP Over SSL.

Installation des correctifs de sécurité

Assurez-vous d’avoir installé les derniers correctifs de sécurité fournis par Adobe.

Modification des mots de passe par défaut pour les comptes administrateur d’AEM et de la console OSGi

Adobe recommande vivement, après l’installation, de modifier le mot de passe pour les comptes administrateur dotés d’autorisations AEM (sur toutes les instances).

Ces comptes sont les suivants :

  • Compte administrateur d’AEM
    Une fois que vous avez modifié le mot de passe du compte administrateur d’AEM, vous devez utiliser le nouveau mot de passe lors de l’accès à CRX.
  • Mot de passe administrateur de la console web OSGi
    Cette modification sera également appliquée au compte administrateur utilisé pour accéder à la console web. Vous devez donc utiliser le même mot de passe lorsque vous y accédez.

Ces deux comptes utilisent des informations d’identification distinctes. Il est essentiel d’utiliser des mots de passe sécurisés distincts pour un déploiement sécurisé.

Modification du mot de passe administrateur d’AEM

Le mot de passe du compte administrateur d’AEM peut être modifié par le biais de la console Opérations Granite – Users.

Vous pouvez modifier le compte administrateur et modifier le mot de passe.

Remarque :

La modification du compte administrateur modifie également le compte de la console web OSGi. Après avoir modifié le compte administrateur, vous devez remplacer le compte OSGi par une autre valeur. 

Importance la modification du mot de passe de la console web OSGi

Outre le compte administrateur d’AEM, si vous ne modifiez pas le mot de passe par défaut du mot de passe de la console web OSGi, cela peut entraîner :

  • l’affichage du serveur avec un mot de passe par défaut au démarrage et à l’arrêt (opération qui peut prendre quelques minutes sur les serveurs importants) ;
  • l’exposition du serveur lorsque le référentiel est en panne/redémarre un lot (et qu’OSGI est en cours d’exécution).

Pour plus d’informations sur la modification du mot de passe de la console web, voir Modification du mot de passe administrateur de la console web OSGi ci-dessous.

Modification du mot de passe administrateur de la console web OSGi

Vous devez également modifier le mot de passe utilisé pour accéder à la console web. À cet effet, configurez les propriétés de la console de gestion OSGi Apache Felix suivantes :

Nom d’utilisateur et Mot de passe, informations d’identification pour accéder à la console de gestion web Apache Felix.
Le mot de passe doit être modifié après l’installation initiale pour s’assurer de la sécurité de votre instance.

Pour ce faire :

  1. Accédez à la console web à l’adresse <serveur>:<port>/system/console/configMgr.

  2. Accédez à la console de gestion OSGi Apache Felix et remplacez le nom d’utilisateur et le mot de passe.

    chlimage_1
  3. Cliquez sur Enregistrer.

Mise en œuvre d’un gestionnaire d’erreur personnalisé

Adobe recommande de définir des pages de gestionnaire d’erreur personnalisé, en particulier pour les codes de réponse HTTP 404 et 500, afin d’empêcher la divulgation d’informations.

Remarque :

Pour plus d’informations, voir l’article de la base de connaissances Comment créer des scripts ou des gestionnaires d’erreur personnalisés.

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

AEM Dispatcher est un élément essentiel de votre infrastructure. Adobe recommande vivement de compléter la liste de contrôle de sécurité de Dispatcher.

Attention :

À l’aide de Dispatcher, vous devez désactiver le sélecteur « .form ».

Étapes de vérification

Configuration des utilisateurs de réplication et de transfert

L’installation AEM standard spécifie admin comme utilisateur des informations d’identifications de transfert dans les agents de réplication par défaut. De même, l’administrateur est utilisé pour déterminer la source de la réplication sur le système de création.

Pour les aspects liés à la sécurité, les deux doivent être modifiés de manière à refléter le cas d’utilisation particulier en question, avec les deux aspects ci-dessous à l’esprit :

  • L’utilisateur du transfert ne doit pas être administrateur. Au lieu de cela, configurez un utilisateur sur le système de publication, qui ne dispose de droits d’accès que sur les parties pertinentes du système de publication et utilise ces informations d’identification pour le transfert.

    Vous pouvez partir de l’utilisateur de réception de la réplication en lot et configurer les droits d’accès de cet utilisateur afin qu’ils correspondent à votre situation

  • L’utilisateur de la réplication ou l’ID utilisateur de l’agent ne doit pas être non plus un administrateur, mais un utilisateur qui ne peut afficher que le contenu qui est censé être répliqué. L’utilisateur de la réplication permet de collecter le contenu à répliquer sur le système de création avant de l’envoyer au système de publication.

Vérification des contrôles d’intégrité de la sécurité du tableau de bord des opérations

AEM 6 introduit un nouveau tableau de bord des opérations, visant à aider les opérateurs système à résoudre les incidents et à contrôler l’intégrité d’une instance.

Le tableau de bord est accompagné également d’une série de contrôles de l’intégrité de la sécurité. Il est recommandé de contrôler le statut de tous les contrôles d’intégrité de la sécurité avant de les publier grâce à votre instance de production. Pour plus d’informations, consultez la documentation du tableau de bord des opérations.

Contrôle de la présence des exemples de contenu

Tous les exemples de contenu et d’utilisateurs (par exemple, le projet Geometrixx et ses composants) doivent être désinstallés et totalement supprimés sur le système en production avant de les rendre accessibles publiquement.

Remarque :

Les exemples d’applications Geometrixx sont supprimés si cette instance est en cours d’exécution en mode prêt pour la production. Si, pour une raison quelconque, ce n’est pas le cas, vous pouvez désinstaller le module cq-geometrixx-all-pkg, comme indiqué à la section Désinstallation des modules. Vous pouvez ensuite supprimer tous les modules geometrixx à l’aide de la même interface utilisateur.

Contrôle de la présence des lots de développement CRX

Ces lots OSGi de développement doivent être désinstallés sur les systèmes de création et de publication en production avant de les rendre accessibles.

  • Prise en charge d’Adobe CRXDE (com.adobe.granite.crxde-support)
  • Adobe Granite CRX Explorer (com.adobe.granite.crx-explorer)
  • Adobe Granite CRXDE Lite (com.adobe.granite.crxde-lite)

Contrôle de la présence des lots de développement Sling

AEM Developer Tools for Eclipse déploie l’installation de la prise en charge des outils Apache Sling (org.apache.sling.tooling.support.install).

Ce lot OSGi doit être désinstallé sur les systèmes de création et de publication en production avant de les rendre accessibles.

Protection contre les attaques CSRF

Infrastructure de protection CSRF

AEM 6.1 est fourni avec un mécanisme qui offre une protection contre les attaques par usurpation des demandes intersites, appelé « Infrastructure de protection CSRF Framework ». Pour plus d’informations sur l’utilisation, consulter la documentation.

Filtre de référents Sling

Pour prendre en compte les problèmes de sécurité connus concernant Cross-Site Request Forgery (CSRF) dans CRX WebDAV et Apache Sling, vous devez ajouter des configurations pour le filtre de référent pour pouvoir l’utiliser.

Le service de filtre de référent est un service OSGi qui permet de configurer :

  • les méthodes HTTP à filtrer ;
  • si un en-tête de référent vide est permis
     ;
  • et une liste des serveurs autorisés, en plus de l’hôte de serveur.

Par défaut, toutes les variantes de localhost et les noms d’hôtes actuels auxquels le serveur est lié figurent sur la liste blanche.

Pour configurer le service de filtrage de référent :

  1. Ouvrez la console Apache Felix (Configurations) à l’adresse :
       http://<serveur>:<numéro_port>/system/console/configMgr

  2. Connectez-vous en tant qu’administrateur.

  3. Dans le menu Configurations, sélectionnez :

        Filtre de référents Apache Sling

  4. Dans le champ Autoriser les hôtes, saisissez tous les hôtes autorisés comme référents. Chaque entrée doit être au format
       <protocole>://<serveur>:<port> 
    Par exemple :

    • http://allowed.server:80 autorise toutes les demandes émanant de ce serveur avec le port indiqué.
    • Si vous souhaitez également autoriser les demandes https, vous devez saisir une seconde ligne.
    • Si vous autorisez tous les ports de ce serveur, vous pouvez utiliser 0 comme numéro de port.

  5. Contrôlez le champ Autoriser une valeur vide si vous souhaitez autoriser les en-têtes de référent vides/manquants.

    Attention :

    Il est recommandé de fournir un référent lors de l’utilisation des outils de ligne de commande, comme cURL au lieu d’autoriser une valeur vide, car cela peut exposer votre système à des attaques CSRF.

  6. Modifiez les méthodes que ce filtre doit utiliser pour les contrôles avec le champ Méthodes de filtrage.

  7. Cliquez sur Enregistrer pour enregistrer les modifications.

Paramètres OSGi

Certains paramètres OSGI sont définis par défaut de manière à faciliter le débogage de l’application. Ils doivent être modifiés sur vos instances de publication et de création en production afin d’éviter des fuites d’informations internes vers le public.

Remarque :

Tous les paramètres ci-dessous, à l’exception de Filtre de débogage WCM Day CQ sont couverts automatiquement par le mode prêt pour la production. Ainsi, il est recommandé de vérifier tous les paramètres avant de déployer votre instance dans un environnement de production.

Pour chacun des services ci-dessous, les paramètres spécifiés doivent être modifiés :

Pour plus d’informations, voir Paramètres de configuration d’OSGi.

Lorsque vous utilisez AEM, plusieurs méthodes permettent de gérer les paramètres de configuration pour ces services. Voir Configuration d’OSGi pour plus de détails et connaître les pratiques recommandées.

Autres ressources à lire

Atténuation 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 pour les utilisateurs ciblés. Ce type d’attaque prend souvent la forme d’une ressource surchargée, par exemple :

  • Multitude de demandes provenant d’une source externe
  • Demande de plus d’informations que le système n’est capable de traiter
    Par exemple, une représentation JSON de l’intégralité du référentiel.
  • Lors de la demande d’une page de contenu avec un nombre illimité d’adresses URL, l’adresse URL peut inclure un nom en ligne, certains sélecteurs, une extension et un suffixe, qui peuvent tous être modifiés.
    Par exemple, .../en.html peut également être demandé comme suit :
    • .../en.ExtensionDosAttack
    • .../en.SelectorDosAttack.html
    • .../en.html/SuffixDosAttack
    Toutes les variantes possibles (par exemple, renvoi d’une réponse 200, configurée pour être mise en cache) seront mises en cache par Dispatcher, ce qui entraîne la saturation du système de fichiers et l’indisponibilité du service pour d’autres demandes.

De nombreux points de configuration permettent de prévenir ce type d’attaque. Nous n’abordons que ceux liés directement à AEM.

Configuration de Sling pour prévenir les attaques par déni de service

Sling est centré sur le contenu. Cela signifie que le traitement est centré sur le contenu, car chaque demande (HTTP) est mise en correspondance avec le contenu sous forme de ressource JCR (un nœud du référentiel) :

  • La première cible est la ressource (nœud JCR) qui contient le contenu.
  • Deuxièmement, l’outil de rendu, ou le script, se trouve dans les propriétés des ressources en combinaison avec certaines parties de la demande (sélecteurs et/ou extension, par exemple).

Remarque :

La section Traitement des demandes Sling en parle plus en détail.

Cette approche rend Sling très puissant et très flexible, mais, comme toujours, c’est la flexibilité qui doit être gérée attentivement.

Pour vous aider à prévenir toute utilisation abusive en raison d’une attaque par déni de service, vous pouvez prendre les mesures suivantes :

  1. Incorporer des contrôles au niveau de l’application. En raison du nombre de variantes possibles, une configuration par défaut n’est pas envisageable.

    Dans votre application, vous devez :

    • Contrôler les sélecteurs dans votre application afin de ne proposer que les sélecteurs explicites nécessaires et de renvoyer un message 404 pour tous les autres.
    • Empêcher la sortie d’un nombre illimité de nœuds de contenu.
  2. Contrôlez la configuration des outils de rendu par défaut, ce qui peut poser un problème.

    • Notamment, l’outil de rendu JSON, qui peut traverser l’arborescence sur plusieurs des niveaux.
      Par exemple, la demande :
          http://localhost:4502/.json
      peut vider le référentiel entier dans une représentation JSON. Cela entraînerait des problèmes importants au niveau du serveur. Ainsi, Sling définit une limite de nombre maximal de résultats. Pour limiter la profondeur du rendu JSON, vous pouvez définir la valeur pour :
          Nombre maximal de résultats JSON (json.maximumresults)
      dans la configuration pour le servlet GET d’Apache Sling. Lorsque cette limite est dépassée, le rendu est réduit. La valeur par défaut pour Sling dans AEM est 200.
    • À titre de mesure préventive, désactivez les autres outils de rendu par défaut (HTML, texte brut, XML). Là encore, en configurant le servlet Sling GET d’Apache.

    Attention :

    Ne désactivez pas l’outil de rendu JSON. Il est nécessaire au fonctionnement normal d’AEM.

  3. Utilisez un pare-feu pour filtrer l’accès à votre instance.

    • L’utilisation d’un pare-feu au niveau du système d’exploitation est nécessaire pour filtrer l’accès aux points de votre instance susceptibles de subir des attaques par déni de service si elle n’est pas protégée.

Désactivation de WebDAV

WebDAV doit être désactivé dans l’environnement de publication. Vous pouvez le faire en arrêtant les lots OSGi appropriés.

  1. Connectez-vous à la console de gestion Felix, exécutée sur :

    http://<hôte>:<port>/system/console

    Par exemple, http://localhost:4503/system/console/bundles.

  2. Dans la liste des lots, recherchez le lot nommé :

        Apache Sling Simple WebDAV Access to repositories (org.apache.sling.jcr.webdav)

  3. Cliquez sur le bouton Arrêter (colonne Actions) pour arrêter ce lot.

  4. Là encore, dans la liste des lots, recherchez le lot nommé :

        Apache Sling DavEx Access to repositories (org.apache.sling.jcr.davex)

  5. Cliquez sur le bouton Arrêter pour arrêter ce lot.

    Remarque :

    Il n’est pas nécessaire de redémarrer AEM.

Vérification de toute absence de divulgation d’informations d’identification personnelles dans le chemin d’accès au répertoire principal des utilisateurs

Il est important de protéger vos utilisateurs en veillant à ne pas exposer d’informations d’identification personnelles dans le chemin d’accès au répertoire principal des utilisateurs du référentiel.

Depuis AEM 6.1, la façon dont les noms de nœud d’ID utilisateur (également appelé « ID autorisable ») sont modifiés par une nouvelle mise en œuvre de l’interface AuthorizableNodeName. La nouvelle interface n’expose plus l’ID utilisateur dans le nom du nœud, mais génère un nom aléatoire à la place.

Aucune configuration ne doit être effectuée pour l’activer, car il s’agit désormais de la méthode par défaut pour générer des ID autorisables dans AEM.

Même si cela n’est pas recommandé, vous pouvez la désactiver au cas où vous auriez besoin de l’ancienne mise en œuvre pour des raisons de rétrocompatibilité avec vos applications existantes. À cet effet, vous devez effectuer les opérations suivantes :

  1. Accédez à la console web et supprimez l’entrée org.apache.jackrabbit.oak.security.user.RandomAuthorizableNodeName de la propriété requiredServicePids dans Apache Jackrabbit Oak SecurityProvider.

    Vous pouvez également trouver Oak Security Provider en cherchant le PID org.apache.jackrabbit.oak.security.internal.SecurityProviderRegistration dans les configurations OSGi.

  2. Supprimez la configuration OSGi Apache Jackrabbit Oak Random Authorizable Node Name dans la console web.

    Pour faciliter la recherche, notez que le PID pour cette configuration est org.apache.jackrabbit.oak.security.user.RandomAuthorizableNodeName.

Remarque :

Pour plus d’informations, voir la documentation Oak dans la section Génération de noms de nœud autorisables.

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.

Pour plus d’informations sur le détournement de clic, voir le site OWASP.

Veillez à répliquer correctement les clés de chiffrement lorsque cela est nécessaire

Certaines fonctionnalités d’AEM et certains schémas d’authentification exigent que vous répliquiez vos clés de chiffrement sur toutes les instances AEM.

Avant d’effectuer cette opération, notez que la réplication des clés est effectuée différemment entre les versions, car le mode de stockage des clés diffère entre la version 6.3 et les versions antérieures.

Pour plus d’informations, voir ci-dessous.

Réplication des clés pour AEM 6.3

Alors que dans les anciennes versions, les clés de réplication étaient stockées dans le référentiel, à compter d’AEM 6.3, elles sont stockées dans le système de fichiers.

Par conséquent, pour reproduire les clés entre les instances, vous devez les copier de l’instance source vers l’emplacement des instances cibles dans le système de fichiers.

Plus spécifiquement, vous devez effectuer les opérations suivantes :

  1. Accédez à l’instance AEM, généralement une instance de création, et qui contient le matériel des clés à copier.

  2. Cherchez le lot com.adobe.granite.crypto.file dans le système de fichiers local. Par exemple, sous ce chemin d’accès :

    • <rép-install-aem-création>/crx-quickstart/launchpad/felix/bundle21

    Le fichier bundle.info à l’intérieur de chaque dossier identifie le nom du lot.

  3. Accédez au dossier des données. Par exemple :

    • <rép-install-aem-création>/crx-quickstart/launchpad/felix/bundle21/data
  4. Copiez les fichiers HMAC et les fichiers principaux.

  5. Ensuite, accédez à l’instance cible sur laquelle vous souhaitez dupliquer la clé HMAC, puis accédez au dossier des données. Par exemple :

    • <rép-install-aem-publication>/crx-quickstart/launchpad/felix/bundle21/data
  6. Collez les deux fichiers copiés précédemment.

  7. Actualisez le lot de chiffrement si l’instance cible est déjà en cours d’exécution.

  8. Répétez les étapes ci-dessus pour toutes les instances sur lesquelles vous souhaitez répliquer la clé.

Remarque :

Vous pouvez rétablir la méthode 6.3 de stockage des clés en ajoutant le paramètre ci-dessous lorsque vous installez AEM pour la première fois :

-Dcom.adobe.granite.crypto.file.disable=true

Réplication des clés pour AEM 6.2 et versions antérieures

Dans AEM 6.2 et versions antérieures, les clés sont stockées dans le référentiel, sous le nœud /etc/key.

La méthode recommandée pour répliquer en toute sécurité les clés sur toutes les instances est de ne répliquer que ce nœud. Vous pouvez répliquer les nœuds de façon sélective à l’aide de CRXDE Lite :

  1. Ouvrez CRXDE Lite en accédant à http://serrveraddress:4502/crx/de/index.jsp.

  2. Sélectionnez le nœud /etc/key.

  3. Cliquez sur l’onglet Réplication.

  4. Appuyez sur le bouton Réplication.

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.

Meilleures pratiques de développement

Il est essentiel que les nouveaux développements respectent les meilleures pratiques de sécurité afin de vous assurer de la sécurité de votre environnement AEM.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne