Liste de contrôle de sécurité security-checklist

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.

Principales mesures de sécurité main-security-measures

Exécuter AEM en mode Prêt pour la production run-aem-in-production-ready-mode

Pour plus d’informations, reportez-vous à la section Exécution d’AEM en mode Prêt pour la production.

Activation du protocole HTTPS pour la sécurité des couches de transfert enable-https-for-transport-layer-security

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.

Installation des correctifs de sécurité install-security-hotfixes

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

Modifier les mots de passe par défaut pour les comptes d’administration de console OSGi et AEM change-default-passwords-for-the-aem-and-osgi-console-admin-accounts

Après l’installation, Adobe recommande de modifier le mot de passe pour les comptes admin AEM dotés de privilèges (sur toutes les instances).

Ces comptes sont les suivants :

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 d’administrateur AEM changing-the-aem-admin-password

Le mot de passe du compte administrateur AEM peut être modifié via la console Opérations Granite - Utilisateurs.

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

Importance de la modification du mot de passe de la console web OSGi importance-of-changing-the-osgi-web-console-password

En plus du compte admin 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 :

Pour plus d’informations sur la modification du mot de passe de la console Web, reportez-vous à la section Modification du mot de passe d’administrateur de la console Web OSGi ci-dessous.

Modification du mot de passe d’administrateur de la console Web OSGi changing-the-osgi-web-console-admin-password

Modifiez le mot de passe utilisé pour accéder à la console web. Utilisez une configuration d’OSGi pour mettre à jour les propriétés suivantes de la console de gestion OSGi Apache Felix  :

Pour modifier le mot de passe d’administration de la console web OSGi  :

Mettre en oeuvre un gestionnaire d’erreurs personnalisé implement-custom-error-handler

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

Compléter la liste de contrôle de sécurité de Dispatcher complete-dispatcher-security-checklist

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

Étapes de vérification verification-steps

Configurer les utilisateurs et utilisatrices de réplication et de transfert configure-replication-and-transport-users

L’installation AEM standard spécifie admin comme utilisateur des informations d’identifications de transfert dans les agents de réplication par défaut. En outre, l’utilisateur administrateur ou l’utilisatrice administratrice est utilisé(e) pour obtenir la réplication sur le système de création.

Pour des raisons de sécurité, ces deux éléments doivent être modifiés afin de tenir compte du cas d’utilisation particulier en question, en prenant en considération les deux aspects suivants :

Vérifier les contrôles de l’intégrité de la sécurité du tableau de bord des opérations check-the-operations-dashboard-security-health-checks

AEM 6 présente le nouveau tableau de bord des opérations, destiné à aider les opérateurs système à résoudre les problèmes et à surveiller 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.

Vérifier si l’exemple de contenu est présent check-if-example-content-is-present

Tous les exemples de contenu et d’utilisateurs et d’utilisatrices, (par exemple, le projet de Geometrixx et ses composants) doivent être désinstallés et supprimés complètement sur un système productif avant de le rendre accessible au public.

Consultez Utilisation de packages.

Vérifier si les bundles de développement CRX sont présents check-if-the-crx-development-bundles-are-present

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

Vérifier si le bundle de développement Sling est présent check-if-the-sling-development-bundle-is-present

Les outils de développement AEM déploient l’installation de la prise en charge des outils Apache Sling (org.apache.sling.tooling.support.install).

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

Se protéger contre les attaques CRSF protect-against-cross-site-request-forgery

Le Framework de protection CSRF the-csrf-protection-framework

AEM 6.1 est fourni avec un mécanisme qui offre une protection contre les attaques CRSF, appelé «  Framework de protection CSRF  ». Pour plus d’informations sur son utilisation, consultez la documentation.

Filtre de référent Sling the-sling-referrer-filter

Pour résoudre les problèmes de sécurité connus avec les attaques CSRF dans CRX WebDAV et Apache Sling, ajoutez des configurations pour le filtre de référent afin de pouvoir l’utiliser.

Le service de filtrage des référents est un service OSGi qui vous permet de configurer :

Pour configurer le service de filtrage de référent, procédez comme suit :

Paramètres OSGI osgi-settings

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

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

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. Consultez la section Configuration d’OSGi pour plus de détails et connaître les pratiques recommandées.

Informations complémentaires further-readings

Prévenir les attaques par déni de service (DoS) mitigate-denial-of-service-dos-attacks

Une attaque par déni de service (DoS) est une tentative de rendre une ressource informatique indisponible à ses utilisateurs ciblés. Cette attaque est souvent perpétrée en surchargeant la ressource, par exemple :

Il existe de nombreux paramétrages pour prévenir de telles attaques, mais nous ne parlons ici que de ceux liés à AEM.

Configuration de Sling pour empêcher les attaques par déni de service

Sling est centré sur le contenu. Le traitement est axé sur le contenu, car chaque requête (HTTP) est mappée sur le contenu sous la forme d’une ressource JCR (un nœud de référentiel) :

Voir Traitement des requêtes Sling pour plus d’informations.

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

Pour empêcher toute utilisation abusive des dénis de service, vous pouvez effectuer les opérations suivantes :

Atténuer les attaques par déni de service (DoS) provoquées par l’utilisation des sélecteurs de formulaire

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 la chaîne *.form.* dans les requêtes.

Pour atténuer ce problème, procédez comme suit :

Atténuer les attaques par déni de service causées par le servlet de téléchargement de ressources

Le servlet de téléchargement de ressources par défaut permet aux utilisateurs et utilisatrices authentifiés d’émettre arbitrairement des requêtes de téléchargement simultanées de grande taille 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 le 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 d’Experience Manager. Elle est activée sur l’instance auteur par défaut d’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 nécessite l’activation du téléchargement de ressources, consultez Télécharger des ressources à partir d’Adobe Experience Manager 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.

Désactiver WebDAV disable-webdav

Désactivez WebDAV dans les environnements de création et de publication en arrêtant les lots OSGi appropriés.

Vérification de toute absence de divulgation d’informations d’identification personnelles dans le chemin d’accès au répertoire principal des utilisateurs verify-that-you-are-not-disclosing-personally-identifiable-information-in-the-users-home-path

Il est important de protéger vos utilisateurs et utilisatrices en veillant à ne pas exposer d’informations d’identification personnelle dans le chemin d’accès des utilisateurs et utilisatrices 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 identifiants 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. Pour ce faire, vous devez effectuer les opérations suivantes :

Package de renforcement des autorisations anonymes anonymous-permission-hardening-package

Par défaut, AEM stocke les métadonnées système, telles que jcr:createdBy ou jcr:lastModifiedBy en tant que propriétés de nœud, en regard du contenu normal, dans le référentiel. Selon la configuration et la définition du contrôle d’accès, cela peut dans certains cas entraîner l’exposition des informations d’identification personnelle (PII), par exemple lorsque ces nœuds sont rendus au format JSON ou XML brut.

Comme toutes les données de référentiel, ces propriétés sont arbitrées par la pile d’autorisations Oak. Leur accès doit être restreint conformément au principe du moindre privilège.

Pour ce faire, Adobe fournit un package de renforcement des autorisations afin que les clients et clientes puissent s’en servir. Il fonctionne en installant une entrée de contrôle d’accès « deny » à la racine du référentiel, ce qui limite l’accès anonyme aux propriétés système couramment utilisées. Le package peut être téléchargé et installé sur toutes les versions d’AEM prises en charge.

Pour illustrer les modifications, nous pouvons comparer les propriétés du nœud qui peuvent être affichées anonymement avant d’installer le package :

avec celles qui sont visibles après l’installation du package, où jcr:createdBy et jcr:lastModifiedBy ne sont pas visibles :

Pour plus d’informations, consultez les notes de mise à jour du package.

Prévention du détournement de clic prevent-clickjacking

Pour empêcher le détournement de clic, Adobe recommande de configurer votre 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, consultez le site de l’OWASP.

Répliquer correctement les clés de chiffrement si nécessaire make-sure-you-properly-replicate-encryption-keys-when-needed

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 cela, la réplication des clés s’effectue différemment entre les versions, car le mode de stockage des clés est différent entre les versions 6.3 et antérieures.

Voir ci-dessous pour plus d’informations.

Réplication des clés pour AEM 6.3 replicating-keys-for-aem

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

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

Plus précisément, vous devez effectuer les opérations suivantes :

Réplication des clés pour AEM 6.2 et les versions antérieures replicating-keys-for-aem-and-older-versions

Dans AEM 6.2 et les 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 manière sélective via CRXDE Lite :

Test de pénétration perform-a-penetration-test

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

Bonnes pratiques de développement development-best-practices

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