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.
Des informations supplémentaires sur les menaces de sécurité les plus dangereuses sont également disponibles, comme publié par Open Web Application Security Project (OWASP).
D’autres considérations relatives à la sécurité s’appliquent à la phase de développement.
Pour plus d’informations, voir Exécution d’AEM en mode prêt pour la production.
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.
Pour plus d’informations, voir la section Activation de HTTP Over SSL.
Assurez-vous d’avoir installé les derniers correctifs de sécurité fournis par Adobe.
Adobe recommande vivement, après l’installation, de modifier le mot de passe des comptes AEM admin
privilégiés (sur toutes les instances).
Ces comptes sont les suivants :
Compte admin
AEM
Une fois que vous avez modifié le mot de passe du compte administrateur AEM, vous devez utiliser le nouveau mot de passe lors de l’accès à CRX.
Mot de passe admin
de la console web OSGi
Cette modification sera également appliquée au compte administrateur utilisé pour accéder à la console web. Vous devrez donc utiliser le même mot de passe lors de l’accès à ce compte.
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é.
Le mot de passe du compte administrateur d’AEM peut être modifié par le biais de la console Opérations Granite – Users.
Ici, vous pouvez modifier le compte admin
et modifier le mot de passe.
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.
Outre le compte admin
AEM, le fait de ne pas modifier le mot de passe par défaut du mot de passe de la console web OSGi peut entraîner :
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.
Vous devez également modifier le mot de passe utilisé pour accéder à la console web. Pour ce faire, configurez les propriétés suivantes de la console de gestion OSGi Apache Felix :
Nom d’utilisateur et mot de passe, les 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 garantir la sécurité de votre instance.
Pour ce faire :
Accédez à la console web à l’adresse <server>:<port>/system/console/configMgr
.
Accédez à la console de gestion OSGi Apache Felix et remplacez le nom d’utilisateur et le mot de passe.
Cliquez sur Enregistrer.
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.
Pour plus d’informations, voir l’article de la base de connaissances Comment créer des scripts ou des gestionnaires d’erreur personnalisés.
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.
À l’aide de Dispatcher, vous devez désactiver le sélecteur « .form ».
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.
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.
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.
Les exemples d’applications We.Retail 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 l’exemple de contenu en accédant à Package Manager, puis en recherchant et désinstallant tous les packages We.Retail. Pour plus d’informations, voir Utilisation de modules.
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.
La section AEM Outils de développement pour Eclipse déploie l’installation de 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.
AEM version 6.1 est fournie avec un mécanisme qui aide à la protection contre les attaques par falsification de requête intersites, appelé CSRF Protection Framework. Pour plus d’informations sur l’utilisation, consulter la documentation.
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 à autoriser en plus de l’hôte du serveur.
Par défaut, toutes les variantes de localhost et les noms d’hôte actuels auxquels le serveur est lié figurent dans la liste.
Pour configurer le service de filtrage de référent :
Ouvrez la console Apache Felix (Configurations) à l’adresse :
https://<server>:<port_number>/system/console/configMgr
Connectez-vous en tant que admin
.
Dans le menu Configurations, sélectionnez :
Apache Sling Referrer Filter
Dans le champ Allow Hosts
, saisissez tous les hôtes autorisés en tant que référent. Chaque entrée doit se trouver dans le formulaire.
<protocol>://<server> :<port>
Par exemple :
https://allowed.server:80
autorise toutes les demandes émanant de ce serveur avec le port indiqué.0
comme numéro de port.Cochez le champ Allow Empty
si vous souhaitez autoriser les en-têtes de référent vides/manquants.
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.
Editez les méthodes que ce filtre doit utiliser pour les contrôles avec le champ Filter Methods
.
Cliquez sur Enregistrer pour enregistrer vos modifications.
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.
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 :
Gestionnaire de bibliothèque HTML Adobe Granite:
Filtre de débogage WCM Day CQ :
Gestionnaire de scripts Sling Java Apache:
Gestionnaire de scripts Apache Sling JSP:
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.
Une attaque par déni de service (DoS) est une tentative de rendre une ressource informatique indisponible à ses 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 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 :
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 :
404
pour tous les autres.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 requête :
http://localhost:4502/.json
peut vider l’ensemble du référentiel 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 de :
Résultats JSON max ( json.maximumresults
)
dans la configuration du servlet de GET Apache Sling. Lorsque cette limite est dépassée, le rendu est réduit. La valeur par défaut pour Sling dans AEM est 1000
.
À 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.
Ne désactivez pas l’outil de rendu JSON. Il est nécessaire au fonctionnement normal d’AEM.
Utilisez un pare-feu pour filtrer l’accès à votre instance.
Atténuer les attaques par déni de service (DoS) provoquées par l’utilisation des sélecteurs de formulaire
Cette réduction ne doit être effectuée que sur les environnements AEM qui n’utilisent pas Forms.
Comme AEM ne fournit pas d’index prêts à l’emploi pour FormChooserServlet
, l’utilisation de sélecteurs de formulaire dans les requêtes déclenche une traversée coûteuse du référentiel, ce qui entraîne généralement l’arrêt de l’instance AEM. Les sélecteurs de formulaire peuvent être détectés par la présence de *.form.Chaîne * dans les requêtes.
Pour atténuer ce problème, veuillez procéder comme suit :
Accédez à la console web en pointant votre navigateur vers https://<serveraddress>:<serverport>/system/console/configMgr
Recherchez Day CQ WCM Form Chooser Servlet
Après avoir cliqué sur l’entrée, désactivez la Recherche avancée requise dans la fenêtre suivante.
Cliquez sur Enregistrer.
Atténuer les attaques par déni de service (DoS) provoquées par l’utilisation du servlet de téléchargement de ressources
Le servlet de téléchargement de ressources par défaut permet aux utilisateurs authentifiés d’émettre des demandes de téléchargement simultanées de grande taille et de taille arbitraire afin de créer des fichiers ZIP de ressources. La création d’archives ZIP volumineuses peut surcharger le serveur et le réseau. Pour atténuer un risque potentiel de déni de service (DoS) provoqué par ce comportement, le composant OSGi AssetDownloadServlet
est désactivé par défaut sur l’instance de publication Experience Manager. Elle est activée par défaut sur l’instance d’auteur Experience Manager.
Si vous n’avez pas besoin de la fonctionnalité de téléchargement, désactivez le servlet sur les déploiements de création et de publication. Si votre configuration requiert l’activation de la fonctionnalité de téléchargement des ressources, reportez-vous à cet article pour plus d’informations. En outre, vous pouvez définir une limite de téléchargement maximale que votre déploiement peut prendre en charge.
WebDAV doit être désactivé dans les environnements de création et de publication. Vous pouvez le faire en arrêtant les lots OSGi appropriés.
Connectez-vous à la console de gestion Felix, exécutée sur :
https://<*host*>:<*port*>/system/console
Par exemple, http://localhost:4503/system/console/bundles
.
Dans la liste des lots, recherchez le lot nommé :
Apache Sling Simple WebDAV Access to repositories (org.apache.sling.jcr.webdav)
Cliquez sur le bouton Arrêter (colonne Actions) pour arrêter ce lot.
Là encore, dans la liste des lots, recherchez le lot nommé :
Apache Sling DavEx Access to repositories (org.apache.sling.jcr.davex)
Cliquez sur le bouton Arrêter pour arrêter ce lot.
Il n’est pas nécessaire de redémarrer AEM.
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 stockés est modifiée 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 :
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.
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.
Pour plus d’informations, voir la documentation Oak dans la section Génération de noms de nœud autorisables.
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.
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.
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 :
Accédez à l’instance AEM, généralement une instance de création, et qui contient le matériel des clés à copier.
Cherchez le lot com.adobe.granite.crypto.file dans le système de fichiers local. Par exemple, sous ce chemin d’accès :
<author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21
Le fichier bundle.info
à l’intérieur de chaque dossier identifie le nom du lot.
Accédez au dossier des données. Par exemple :
<author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
Copiez les fichiers HMAC et les fichiers principaux.
Ensuite, accédez à l’instance cible sur laquelle vous souhaitez dupliquer la clé HMAC, puis accédez au dossier des données. Par exemple :
<publish-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
Collez les deux fichiers copiés précédemment.
Actualisez le lot de chiffrement si l’instance cible est déjà en cours d’exécution.
Répétez les étapes ci-dessus pour toutes les instances sur lesquelles vous souhaitez répliquer la clé.
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
Dans AEM version 6.2 et antérieure, les clés sont stockées dans le référentiel sous le noeud /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 :
/etc/key
.Adobe recommande vivement d’effectuer un test de pénétration de l’infrastructure AEM avant la mise en production.
Il est essentiel que les nouveaux développements respectent les bonnes pratiques de sécurité pour garantir la sécurité de votre environnement AEM.