Cet article présente les éléments essentiels à contrôler en ce qui concerne la sécurité et la confidentialité.
Privacy

Configuration et renforcement de la confidentialité

Cliquez ici


icon_clef

Gestion des accès

Cliquez ici


Server

Configuration du serveur

Cliquez ici


Development

Instructions relatives aux scripts et à l’encodage

Cliquez ici


Network

Réseau, base de données et SSL/TLS

Cliquez ici


Web

Paramétrage du serveur Web

Cliquez ici


Confidentialité

Privacy

La configuration et le renforcement de la confidentialité sont des éléments clés de l’optimisation de la sécurité. Lisez cette section pour découvrir les bonnes pratiques en matière de confidentialité :

  • Protégez les PII de votre client en utilisant HTTPS au lieu de HTTP.
  • Utilisez la limitation de l’affichage des PII pour protéger la confidentialité et empêcher toute utilisation abusive des données.
  • Vérifiez que les mots de passe cryptés sont restreints.
  • Protégez les pages pouvant contenir des informations personnelles, telles que les pages miroir, les applications web, etc.

Demandes d’accès à des informations personnelles

Adobe Campaign offre un ensemble d’outils pour vous aider à respecter le RGPD et le CCPA en ce qui concerne la protection des données.

Pour obtenir des informations générales sur la gestion de la protection des données et les étapes de mise en œuvre dans Adobe Campaign, reportez-vous à cette page. Vous trouverez également des bonnes pratiques, ainsi qu’une vue d’ensemble du processus utilisateur et des acteurs impliqués.  

Personnalisation des URL

Lorsque vous ajoutez des liens personnalisés à votre contenu, évitez toujours toute personnalisation dans la partie nom d’hôte de l’URL afin d’éviter des failles de sécurité potentielles. Les exemples suivants ne doivent jamais être utilisés dans tous les attributs d’URL <a href=""> ou <img src=""> :

  • <%= url >
  • https://<%= url >
  • https://<%= domaine >/chemin
  • https://<%= sous-domaine >.domaine.tld/chemin
  • https://sous.domaine<%= domaine principal %>/chemin

Recommandation

Pour valider et vérifier que vous n’utilisez pas les éléments ci-dessus, exécutez une requête sur la table des URL de tracking à l’aide du requêteur générique de Campaign ou créez un workflow avec des critères de filtre dans l’activité de requête.

Exemple :

  1. Créez un workflow et ajoutez une activité Requête. En savoir plus.
  2. Ouvrez l’activité Requête et créez un filtre sur la table nmsTrackingUrl comme suit : l’URL source commence par http://<% ou l’URL source commence par https://<%.
  3. Exécutez le workflow et vérifiez s’il y a des résultats.
  4. Si c’est le cas, ouvrez la transition sortante pour afficher la liste des URL.
Requête sur les URL dynamiques

Mécanisme de signature

Pour améliorer la sécurité, un nouveau mécanisme de signature pour les liens de tracking dans les emails a été ajouté dans le build 19.1.4 (9032@3a9dc9c) et est disponible dans le build 19.1.4 (9032@3a9dc9c) et Campaign 20.2. Cette option est activée par défaut pour tous les clients.

Remarque :

Lorsqu’un utilisateur clique sur une URL signée incorrecte, l’erreur suivante est renvoyée : « L’URL "..." demandée est introuvable. »

En outre, les clients hébergés et hybrides du build 19.1.4 (9032@3a9dc9c et 9032@800be2e) et de Campaign 20.2 peuvent utiliser une amélioration pour désactiver les URL générées à partir des builds précédents. Cette option est désactivée par défaut. Vous pouvez contacter l’Assistance clientèle pour activer cette fonctionnalité.

Pour activer ce nouveau mécanisme, les clients on-premise doivent suivre la procédure suivante sur tous les serveurs Campaign :

  1. Dans le fichier de configuration du serveur (serverConf.xml), définissez blockRedirectForUnsignedTrackingLink sur true.
  2. Redémarrez le service nlserver .
  3. Sur le serveur de tracking, redémarrez le serveur web (apache2 sur Debian ; httpd sur CentOS/RedHat ; IIS sous Windows).

Attention :

Les clients qui utilisent le build 19.1.4 (9032@3a9dc9c) peuvent rencontrer des problèmes avec les diffusions de notification push qui se servent d’un lien de tracking ou les diffusions avec des balises d’ancrage. Si tel est le cas, Adobe recommande de désactiver le nouveau mécanisme de signature pour les liens de tracking. 

Les clients hébergés et hybrides doivent contacter l’Assistance clientèle pour que ce mécanisme soit désactivé.

Les clients on-premise peuvent procéder comme suit :

  1. Dans le fichier de configuration du serveur (serverConf.xml), remplacez signEmailLinks par false.
  2. Redémarrez le service nlserver.
  3. Sur le serveur de tracking, redémarrez le serveur web (apache2 sur Debian ; httpd sur CentOS/RedHat ; IIS sous Windows).

Restriction des données

Vous devez vous assurer que les mots de passe cryptés ne sont pas accessibles par un utilisateur authentifié avec de faibles privilèges. Pour cela, il existe deux méthodes : restreindre l’accès aux champs de mots de passe uniquement ou à l’entité entière (un build >= 8770 est requis).

Cette restriction vous permet de supprimer les champs de mots de passe. Le compte externe reste toutefois accessible par tous les utilisateurs dans l’interface. Reportez-vous à la documentation.

  1. Accédez à Administration > Paramétrage > Schémas de données.

  2. Créez une Extension d’un schéma.

    Mot de passe
  3. Sélectionnez Compte externe (extAccount).

  4. Dans le dernier écran de l’assistant, vous pouvez éditer le nouveau srcSchema afin de restreindre l’accès à tous les champs de mot de passe :

    Vous pouvez remplacer l’élément principal (<element name="extAccount" ... >) par :

    <element name="extAccount">
        <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
        <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
      
        <element name="s3Account">
          <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="awsSecret"/>
        </element>
        <element name="wapPush">
          <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
          <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
        </element>
        <element name="mms">
          <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
          <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
        </element>
      </element>

    Le srcSchema étendu peut ressembler à ceci :

    <srcSchema _cs="External Accounts (cus)" created="2017-05-12 07:53:49.691Z" createdBy-id="0"
               desc="Definition of external accounts (Email, SMS...) used by the modules"
               entitySchema="xtk:srcSchema" extendedSchema="nms:extAccount" img="" label="External Accounts"
               labelSingular="External account" lastModified="2017-05-12 08:33:49.365Z"
               mappingType="sql" md5="E9BB0CD6A4375F500027C86EA854E101" modifiedBy-id="0"
               name="extAccount" namespace="cus" xtkschema="xtk:srcSchema">
      <createdBy _cs="Administrator (admin)"/>
      <modifiedBy _cs="Administrator (admin)"/>
      <element name="extAccount">
        <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
        <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
     
        <element name="s3Account">
          <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="awsSecret"/>
        </element>
        <element name="wapPush">
          <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
          <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
        </element>
        <element name="mms">
          <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
          <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
        </element>
      </element>
    </srcSchema>

    Remarque :

    Vous pouvez remplacer $(loginId) = 0 ou $(login) = ’admin’  par hasNamedRight(’admin’) afin d’autoriser tous les utilisateurs ayant le droit admin de visualiser ces mots de passe.

Protection des pages contenant des PII

Nous conseillons fortement aux utilisateurs on-premise de protéger les pages pouvant contenir des informations personnelles, telles que les pages miroir, les applications web, etc.

Cette procédure est destinée à empêcher l’indexation de ces pages et ainsi à éviter un risque de sécurité potentiel. Voici quelques articles utiles :

Pour protéger vos pages, suivez ces étapes :

  1. Ajoutez un fichier robots.txt à la racine de votre serveur web (Apache ou IIS). Voici le contenu du fichier :

    # Make changes for all web spiders
    User-agent: 
    *Disallow: /
              

    Pour IIS, consultez cette page.

    Pour Apache, vous pouvez placer le fichier dans /var/www/robots.txt (Debian).

  2. Il arrive que l’ajout d’un fichier robots.txt ne soit pas suffisant en termes de sécurité. Par exemple, si un autre site web contient un lien vers votre page, il peut apparaître dans un résultat de recherche.

    Outre le fichier robots.txt, il est conseillé d’ajouter un en-tête X-Robots-Tag. Vous pouvez le faire dans Apache ou IIS, ainsi que dans le fichier de configuration serverConf.xml.

    Pour plus d’informations, consultez cet article.

Gestion de l’accès

Access

La gestion des accès joue un rôle important dans le renforcement de la sécurité. Vous trouverez ci-dessous quelques-unes des principales bonnes pratiques à appliquer.

  • Créez suffisamment de groupes de sécurité.
  • Vérifiez que chaque opérateur dispose des droits d’accès adéquats.
  • Évitez d’utiliser l’opérateur admin et d’ajouter trop d’opérateurs au groupe admin.

Pour plus d’informations, reportez-vous à la documentation : Droits d’accès et Propriétés d’accès des dossiers.


Opérateur webApp

L’opérateur webApp par défaut est un administrateur. Pour renforcer la sécurité, suivez les instructions suivantes :

  • Remplacez le droit nommé admin de cet opérateur par un autre (que vous pouvez appeler "webapp"). Pour plus d’informations, consultez cette documentation.
  • Ajoutez l’opérateur webApp à des dossiers (principalement des dossiers de destinataires) afin d’accorder un accès en lecture/écriture aux destinataires. Pour plus d’informations à ce propos, consultez cette documentation.
  • Si vous utilisez une instance multimarque (ou multizone), vous souhaiterez peut-être répartir l’accès aux applications web entre différents dossiers de destinataires. Pour ce faire :
    1. Dupliquez l’opérateur webApp.
    2. Entrez un nom pour chaque doublon. Par exemple, webapp_marque, webapp_marque2, etc.
    3. Dupliquez un modèle d’application web pour disposer d’un modèle par marque et éditez les propriétés pour changer l’opérateur en sélectionnant l’option Utiliser un compte spécifique.  Pour en savoir plus, consultez cette documentation.

Groupes de sécurité et opérateurs administrateurs

Créez suffisamment de groupes de sécurité afin de donner aux opérateurs des droits suffisants pour qu’ils puissent effectuer les opérations nécessaires (et pas davantage).

N’utilisez pas l’opérateur admin (ou ne le partagez pas). Créez un opérateur par utilisateur physique (pour des logs et un suivi précis). Ajoutez les admirateurs nouvellement nommés au groupe admin. Si vous n’utilisez pas l’opérateur admin, ne le supprimez pas et ne le désactivez pas (cet opérateur est utilisé en interne pour exécuter le traitement). Vous pouvez toutefois interdire son accès à la console cliente et restreindre sa zone de sécurité (à localhost).

Evitez d’ajouter trop d’opérateurs au groupe admin (ou avec des droits nommés admin). Il s’agit d’opérateurs très puissants (ils peuvent effectuer toutes les instructions SQL, exécuter des commandes sur le serveur, etc.).

Adobe Campaign propose trois privilèges de niveau supérieur (droits nommés) :

  • ADMINISTRATION (admin) : donne accès à tout et permet d’effectuer toutes les tâches (contourne les contrôles des droits nommés). Il comprend donc les droits nommés EXECUTION DE PROGRAMMES (createProcess) et SQL.
  • EXECUTION DE PROGRAMMES (createProcess) : permet d’exécuter des programmes externes (sur le serveur).
  • SQL : permet d’exécuter des scripts SQL sur la base de données (ce privilège peut donc contourner le modèle de sécurité). Remarque : si vous devez effectuer des calculs complexes (des filtrages, par exemple), vous pouvez demander à l’administrateur de la base de données de créer une fonction SQL et de l’ajouter à la liste autorisée. Consultez cette section pour en savoir plus.
  • Accordez ces privilèges à un nombre très limité d’opérateurs (de confiance).

Instructions relatives aux scripts et à l’encodage

Dev

Lorsque vous effectuez des tâches de développement dans Adobe Campaign (workflows, Javascript, JSSP, etc.), suivez toujours ces instructions :

  • Scripts : évitez si possible d’utiliser des instructions SQL. Utilisez des fonctions paramétrables plutôt que la concaténation de chaîne et évitez toute injection SQL en ajoutant les fonctions SQL à utiliser à la liste autorisée.
  • Sécuriser le modèle de données : utilisez des droits nommés pour limiter les actions des opérateurs et ajoutez des filtres système (sysFilter).
  • Ajouter des captchas dans les applications web : découvrez comment ajouter des captchas dans vos pages d’inscription et landing pages publiques.

Scripts

Pour plus d’informations, reportez-vous à la documentation JSAPI Campaign.

Si vous écrivez un script à l’aide d’un workflow, d’applications web ou de jssp, suivez ces bonnes pratiques :

  • Evitez autant que possible d’utiliser des instructions SQL.
  • Utilisez des fonctions (instruction prepare) paramétrables au lieu de la concaténation de chaîne.

Mauvaise pratique :

sqlGetInt( "select iRecipientId from NmsRecipient where sEmail ='" + request.getParameter('email') +  "'  limit 1" )

Bonne pratique :

sqlGetInt( "select iRecipientId from NmsRecipient where sEmail = $(sz) limit 1", request.getParameter('email'));

Avertissement : sqlSelect ne prend pas en charge cette fonctionnalité. Vous devez donc utiliser la fonction de requête de la classe DBEngine :

var cnx = application.getConnection() 
var stmt = cnx.query("SELECT sFirstName, sLastName FROM NmsRecipient where sEmail = $(sz)", request.getParameter('email'))
for each(var row in stmt) logInfo(row[0] + " : " + row[1]) 
cnx.dispose()

Pour éviter les injections SQL, les fonctions SQL doivent être ajoutées à la liste autorisée à utiliser dans Adobe Campaign. Une fois ajoutées à la liste autorisée, vos opérateurs peuvent les voir dans l’éditeur d’expression. Reportez-vous à la documentationAvertissement : Si vous utilisez un build antérieur au build 8140, l’option XtkPassUnknownSQLFunctionsToRDBMS peut être définie sur ’1’. Si vous souhaitez protéger votre base de données, supprimez cette option (ou définissez-la sur ’0’).

Si vous utilisez des saisies utilisateur pour créer des filtres dans des requêtes ou des instructions SQL, vous devez toujours les placer dans une séquence d’échappement (reportez-vous à la documentation JSAPI Campaign - Protection des données : fonctions d’échappement). Ces fonctions sont les suivantes :

  • NL.XML.escape(data)
  • NL.SQL.escape(data)
  • NL.JS.escape(data)
  • NL.XML.escapeAttribute(data)

Sécuriser votre nouveau modèle de données

Basé sur les dossiers

Reportez-vous aux sections suivantes de la documentation produit :

Droits nommés

En plus du modèle de sécurité basé sur les dossiers, vous pouvez utiliser des droits nommés pour limiter les actions des opérateurs :

  • Vous pouvez ajouter des filtres système (sysFilter) pour empêcher tout accès en lecture/écriture à vos données. Voir la documentation.
<sysFilter name="writeAccess">     
    <condition enabledIf="hasNamedRight('myNewRole')=false" expr="FALSE"/>   
</sysFilter>
  • Vous pouvez également protéger certaines actions (méthode SOAP) définies dans les schémas. Il suffit de définir l’attribut access avec le droit nommé correspondant comme valeur.
<method name="grantVIPAccess" access="myNewRole">
      <parameters>
...
      </parameters>
    </method>

         

Voir à ce propos cette section.

Attention :

Vous pouvez utiliser des droits nommés dans le nœud command d’un navtree. Cela offre une meilleure expérience utilisateur, mais ne fournit aucune protection (utilisez uniquement le côté client pour les masquer/les activer). Vous devez utiliser l’attribut access.

Table d’Overflow

Si vous devez protéger des données confidentielles (partie d’un schéma) en fonction du niveau d’accès des opérateurs, ne les masquez pas dans la définition du formulaire (conditions enabledIf/visibleIf). L’entité entière est chargée par l’écran. Vous pouvez également les afficher dans la définition de colonne. Pour ce faire, vous devez créer une table d’Overflow. Reportez-vous à cette documentation.

Ajouter des captchas dans les applications web

Il est recommandé d’ajouter un captcha dans les landing pages/pages d’inscription publiques. Il est cependant relativement difficile de le faire dans les pages du DCE (Digital Content Editor). Nous allons vous expliquer dans cette section comment ajouter un captcha v5 ou un reCAPTCHA Google.

La méthode générale pour ajouter un captcha dans le DCE consiste à créer un bloc de personnalisation pour l’inclure facilement dans le contenu de la page. Vous devrez ajouter une activité Script et une activité Test.

Bloc de personnalisation

  1. Accédez à Ressources > Gestion de campagne > Blocs de personnalisation et créez un bloc de personnalisation.

  2. Utilisez le type de contenu Application web et cochez l’option Afficher dans les menus de personnalisation.

    Pour plus d’informations, consultez la documentation.

    Voici un exemple de captcha Campaign :

    <%
    var captchaID = CaptchaIDGen();
    %>
    <img src="/nms/jsp/captcha.jsp?captchaID=<%=captchaID%>&width=200&height=50&minWordSize=8&maxWordSize=8"/>
    <input id="captchaValue" name="captchaValue" <%= String(ctx.vars.captchaValid) === "false" ? class="ui-state-error" : "" %>>
    <input type="hidden" name="captchaID" value="<%=captchaID%>"/>
    <%
    if( serverForm.isInputErroneous("captchaValue") ) {
    %>
    <script type="text/javascript">  
    $("#captchaValue").addClass("ui-state-error")
    </script>
    <%
    }
    %>
    • Les lignes 1 à 6 génèrent toutes les entrées requises.
    • La ligne 7 et les lignes suivantes jusqu’à la dernière gèrent les erreurs.
    • La ligne 4 permet de changer la taille du cadre gris du captcha (width/height) et la longueur du mot généré (minWordSize/maxWordSize).
    • Avant d’utiliser un reCAPTCHA Google, vous devez vous enregistrer sur Google et créer un site reCAPTCHA.
    <div class="g-recaptcha" data-sitekey="YOUR_SITE_KEY"></div>

    Vous devriez être en mesure de désactiver le bouton de validation, mais comme il n’existe pas de bouton/lien standard, il est préférable de le faire dans le code HTML. Pour en savoir plus, consultez cette page.

Mettre à jour votre application web

  1. Accédez aux propriétés de votre application web pour ajouter une variable booléenne nommée captchaValid.

    captcha
  2. Entre la dernière page et l’activité Enregistrement, ajoutez une activité Script et une activité Test. Reliez la branche Vrai à l’activité Enregistrement et l’autre extrémité de la branche à la page qui contiendra le captcha.

    Captcha – étape 2
  3. Editez la condition de la branche Vrai avec "[vars/captchaValid]" égal à Vrai.

    Captcha – étape 3
  4. Ensuite, modifiez l’activité Script. Le contenu dépendra du moteur de captcha sélectionné.

  5. Enfin, vous pouvez ajouter votre bloc de personnalisation dans la page. Voir à ce propos la documentation.

    Captcha – étape 5
    Captcha – étape 6

    AVERTISSEMENT : Pour l’intégration de reCAPTCHA, vous devez ajouter un script JavaScript dans le code HTML (entre <head>...</head>) :

    <script src="https://www.google.com/recaptcha/api.js" async defer></script>

Captcha Campaign

var captchaID = request.getParameter("captchaID");
var captchaValue = request.getParameter("captchaValue");
 
if( !CaptchaValidate(captchaID, captchaValue) ) {
  serverForm.logInputError("captchaValue",
                           "The characters you typed for the captcha must match the image ones.",
                           "captchaValue")
  ctx.vars.captchaValid = false
}
else
  ctx.vars.captchaValid = true

Ligne 6 : vous pouvez mettre n’importe quel type de message d’erreur.

reCAPTCHA Google

Reportez-vous à la documentation officielle.

ctx.vars.captchaValid = false
var gReCaptchaResponse = request.getParameter("g-recaptcha-response");
 
// Call reCaptcha API to validate it
var req = new HttpClientRequest("https://www.google.com/recaptcha/api/siteverify")
req.method = "POST"
req.header["Content-Type"] = "application/x-www-form-urlencoded"
req.body = "secret=YOUR_SECRET_HERE&response=" + encodeURIComponent(gReCaptchaResponse)
req.execute()
var response = req.response
if( response.code == 200 ) {
  captchaRes = JSON.parse(response.body.toString(response.codePage));
  ctx.vars.captchaValid = captchaRes.success
}
 
if( ctx.vars.captchaValid == false ) {
  serverForm.logInputError("reCaptcha",
                           "Please validate the captcha",
                           "reCaptcha")
  logInfo("reCaptcha not validated")
}

Pour utiliser JSON.parse, vous devez inclure "shared/json2.js" dans votre webApp :

Captcha – étape 7

Depuis le build 8797, pour utiliser l’URL de l’API de vérification, vous devez l’ajouter à la liste autorisée dans le fichier serverConf en l’ajoutant dans le nœud urlPermission :

<url dnsSuffix="www.google.com" urlRegEx="https://www.google.com/recaptcha/api/siteverify"/>

Réseau, base de données et SSL/TLS

Network

Le paramétrage du réseau est un élément très important que vous devez vérifier lorsque vous déployez un type d’architecture on-premise. Vérifiez que le serveur Tomcat N’EST PAS directement accessible en dehors du serveur :

  • Fermez le port Tomcat (8080) sur les adresses IP externes (doit fonctionner sur localhost).
  • Ne mappez pas le port HTTP standard (80) sur le port Tomcat (8080).

Si possible, utilisez un canal sécurisé : POP3S au lieu de POP3 (ou POP3 sur TLS).


Base de données

Vous devez impérativement suivre les instructions de sécurité de votre moteur de base de données.

Configuration de SSL/TLS

Pour vérifier le certificat, vous pouvez utiliser openssl. Pour contrôler les chiffrements actifs, vous pouvez avoir recours à nmap :

#!/bin/sh
#
# usage: testSSL.sh remote.host.name [port]
#
REMHOST=$1
REMPORT=${2:-443}

echo |\
openssl s_client -connect ${REMHOST}:${REMPORT} -servername ${REMHOST} 2>&1 |\
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' |\
openssl x509 -noout -subject -dates
  
nmap --script ssl-enum-ciphers -p ${REMPORT} ${REMHOST}

Vous pouvez également utiliser un script Python sslyze qui effectue les deux vérifications.

python sslyze.py --sslv2 --sslv3 --tlsv1 --reneg --resum --certinfo=basic --hide_rejected_ciphers --sni=SNI myserver.com

Configuration du serveur

Server

Le paramétrage doit être effectué sur tous les serveurs. Les fichiers de configuration sont du type serverConf.xml et config-<instance>.xml. Voici les éléments essentiels qui doivent être vérifiés :

  • Zone de sécurité : configurez les zones de sécurité afin qu’elles prennent en compte directement les adresses IP des clients d’un proxy.
  • Protection des téléchargements de fichiers : limitez les types de fichiers pouvant être téléchargés sur le serveur Adobe Campaign grâce à un nouvel attribut uploadAllowList. Celui est utilisable dans le fichier de configuration du serveur.
  • Relais : affinez le paramétrage des relais en désactivant les règles de relais pour les modules/applications inutilisés.
  • Protection des connexions sortantes et restriction des commandes (côté serveur)
  • Vous pouvez également ajouter des en-têtes HTTP supplémentaires et activer les options checkIPConsistent, enableTLS, sessionTimeOutSec, etc.

Reportez-vous à la documentation relative au paramétrage du serveur Adobe Campaign et à la description du fichier de configuration du serveur pour obtenir de plus amples informations.


Configuration des zones de protection

Attention :

A partir du build 8977, l’interface Security Zones Self Service n’est plus disponible.

  • Si vous êtes hébergé sur AWS, l’ajout d’adresses IP à la liste autorisée doit être effectué dans le panneau de contrôle. Pour plus d’informations, consultez la documentation dédiée.
  • Si votre instance n’est pas hébergée sur AWS, contactez l’équipe de support Adobe pour ajouter les adresses IP à la liste autorisée.

 Pour vérifier si votre instance est hébergée sur AWS, suivez la procédure détaillée dans cette section.

Pour découvrir comment utiliser l’interface utilisateur de Security Zones Self Service pour gérer les entrées dans le paramétrage des zones de sécurité VPN, consultez cette technote.

Vérifiez que le proxy inverse n’est pas autorisé dans subNetwork. Si c’est le cas, l’ensemble du trafic est détecté comme provenant de cette adresse IP locale et est donc considéré comme digne de confiance.

Limitez l’utilisation de sessionTokenOnly="true" :

  • Avertissement : Si cet attribut est défini sur true, l’opérateur peut être exposé à une attaque CRSF.
  • De plus, le cookie sessionToken n’étant pas défini avec un flag httpOnly, certains codes JavaScript côté client peuvent le lire.
  • L’utilisation de Message Center avec plusieurs instances d’exécution requiert toutefois l’activation de l’option sessionTokenOnly : créez une nouvelle zone de sécurité avec l’option sessionTokenOnly définie sur "true" et ajoutez uniquement les adresses IP nécessaires à cette zone.

Si possible, définissez les attributs allowHTTP et showErrors sur la valeur false (pas pour localhost) et vérifiez-les.

  • allowHTTP = "false" : force les opérateurs à utiliser le protocole HTTPS.
  • showErrors = "false" : masque les erreurs techniques (y compris celles de SQL). Cet attribut empêche l’affichage d’un trop grand nombre d’informations, mais il limite la possibilité des marketeurs de corriger les erreurs (sans demander des informations supplémentaires à un administrateur).

Définissez allowDebug sur true uniquement sur les adresses IP utilisées par les utilisateurs marketing/administrateurs qui doivent créer (ou plutôt prévisualiser) des questionnaires, webApps et rapports. Ce flag permet d’afficher les règles de relais et de les déboguer pour ces adresses IP.

Ne définissez jamais les attributs allowEmptyPassword, allowUserPassword et allowSQLInjection sur true. Ils ne servent qu’à faciliter la migration depuis la v5 vers la v6.0 :

  • L’attribut allowEmptyPassword permet aux opérateurs de disposer d’un mot de passe vide. Si c’est votre cas, demandez à tous les opérateurs de définir un mot de passe avec un délai. Une fois ce délai passé, définissez cet attribut sur la valeur false.
  • L’attribut allowUserPassword permet aux opérateurs d’envoyer leurs identifiants en tant que paramètres (afin qu’ils puissent être connectés par Apache/IIS/un proxy). Cette fonctionnalité était auparavant utilisée pour simplifier l’utilisation de l’API. Vous pouvez vérifier dans votre « livre de recettes » (ou dans les spécifications) si des applications tierces utilisent cet attribut. Si c’est le cas, vous devez demander à ces tiers de changer la façon dont ils utilisent notre API et supprimer cette fonctionnalité dès que possible.
  • L’attribut allowSQLInjection permet à l’utilisateur d’effectuer des injections SQL en utilisant une ancienne syntaxe. Apportez dès que possible les corrections présentées dans la documentation pour pouvoir définir cet attribut sur false.

Vous pouvez utiliser /nl/jsp/ping.jsp?zones=true pour vérifier le paramétrage de votre zone de sécurité. Cette page affiche l’état actif des mesures de sécurité (calculé avec ces flags de sécurité) pour l’adresse IP actuelle.

Cookie HttpOnly/useSecurityToken : reportez-vous au flag sessionTokenOnly.

Limitez le nombre d’adresses IP ajoutées à la liste autorisée : dans les zones de sécurité, nous avons ajouté les 3 plages pour les réseaux privés. Il est peu probable que vous utiliserez toutes ces adresses IP. Ne conservez donc que celles dont vous avez besoin.

Mettez à jour l’opérateur interne/webApp pour qu’il soit accessible uniquement dans localhost.

Protection des téléchargements de fichiers

Demandez aux utilisateurs quels types de fichiers ils téléchargent sur le serveur à l’aide de l’interface web/nlclient. Pour rappel, les besoins de l’entreprise peuvent être les suivants :

  • des images (jpg, gif, png, etc.),
  • des contenus (zip, html, css, etc.),
  • des ressources marketing (doc, xls, pdf, psd, tiff, etc.),
  • des pièces jointes à des emails (doc, pdf, etc.),
  • des fichiers ETL (txt, csv, tab, etc.)
  • etc.

Ajoutez tous ces types de fichiers dans serverConf/shared/datastore/@uploadAllowlist (expression régulière Java valide). Reportez-vous à la documentation connexe.

Adobe Campaign ne limite pas la taille des fichiers, mais vous pouvez la limiter en configurant IIS/Apache. Consultez cette section pour en savoir plus.

Relais

Veuillez consulter la documentation pour plus d’informations.

Par défaut, toutes les pages dynamiques sont relayées automatiquement au serveur local Tomcat de la machine dont le module web est démarré. Vous pouvez choisir de ne pas relayer certaines d’entre elles. Si vous n’utilisez pas certains modules d’Adobe Campaign (tels que webapp, interaction, certaines pages jsp), vous pouvez les supprimer des règles de relais.

Nous avons forcé la possibilité d’afficher par défaut les ressources des utilisateurs finaux à l’aide de HTTP (httpAllowed="true"). Comme ces pages peuvent afficher certaines PII (contenu/adresse email), un bon d’échange ou une offre, vous devez forcer de nouveau HTTPS sur ces chemins.

Si vous utilisez des noms d’hôte différents (un nom d’hôte public et un nom d’hôte pour les opérateurs), vous pouvez également empêcher le relais de certaines ressources dont les opérateurs ont besoin sur le nom DNS public.

Protection des connexions sortantes

La liste par défaut des URL pouvant être appelées par des codes JavaScript (workflows, etc.) est limitée. Pour autoriser une nouvelle URL, l’administrateur doit la référencer dans le fichier serverConf.xml.

Il existe trois modes de protection des connexions :

  • Blocking : toutes les URL qui ne figurent pas sur la liste autorisée sont bloquées et un message d’erreur s’affiche. Il s’agit du mode par défaut après un postupgrade.
  • Permissive : toutes les URL qui ne figurent pas sur la liste autorisée sont autorisées.
  • Warning : toutes les URL qui ne figurent pas sur la liste autorisée sont autorisées, mais l’interpréteur JS émet un avertissement pour que l’administrateur puisse les collecter. Ce mode ajoute des messages d’avertissement JST-310027.
<urlPermission action="warn" debugTrace="true">
  <url dnsSuffix="abc.company1.com" urlRegEx=".*" />
  <url dnsSuffix="def.partnerA_company1.com" urlRegEx=".*" />
  <url dnsSuffix="xyz.partnerB_company1.com" urlRegEx=".*" />
</urlPermission>

Les nouveaux clients utiliseront le mode bloquant. S’ils souhaitent autoriser une nouvelle URL, ils doivent contacter leur administrateur pour l’ajouter à la liste autorisée.

Les clients existants provenant d’une migration peuvent utiliser le mode d’avertissement pendant un certain temps. En attendant, ils doivent analyser le trafic sortant avant d’autoriser les URL.

Restriction des commandes (côté serveur)

Plusieurs commandes sont blacklistées et ne peuvent pas être exécutées à l’aide de la fonction execCommand. Une sécurité supplémentaire est fournie par un nouvel utilisateur Unix dédié afin d’exécuter les commandes externes. Pour les installations hébergées, cette restriction est automatiquement appliquée. Pour les installations on-premise, vous pouvez configurer manuellement cette restriction en suivant les instructions de la documentation dédiée. De plus, les activités de workflow Script et Tâche externe ne sont pas disponibles dans les instances nouvellement installées.

Autres paramétrages

Vous pouvez ajouter des en-têtes HTTP supplémentaires (pour toutes les pages). Pour plus d’informations, reportez-vous à la documentation :

  • Vous pouvez ajouter d’autres en-têtes tels que HSTS, X-FRAME-OPTIONS, CSP, etc.
  • Vous devez les tester dans un environnement de test avant de les appliquer en production.  AVERTISSEMENT : L’ajout de certains en-têtes peut entraîner un dysfonctionnement d’Adobe Campaign.

Adobe Campaign permet de définir un mot de passe en clair dans l’élément <dbcnx .../>. N’utilisez pas cette fonctionnalité.

Par défaut, Adobe Campaign n’associe pas une session à une adresse IP spécifique, mais vous pouvez activer cette option pour empêcher tout vol de la session. Pour ce faire, dans le fichier serverConf.xml, définissez l’attribut checkIPConsistent (dans le nœud <authentication>) sur true.

Par défaut, le MTA d’Adobe Campaign n’utilise pas de connexion sécurisée pour envoyer du contenu au serveur SMTP. Vous devez activer cette fonctionnalité (ce qui peut réduire la vitesse de diffusion). Pour ce faire, définissez enableTLS sur true dans le nœud <smtp ...>.

Vous pouvez réduire la durée de vie d’une session dans le nœud d’authentification (attribut sessionTimeOutSec).

Paramétrage du serveur Web

web

Vous trouverez ci-dessous certaines des principales bonnes pratiques relatives au paramétrage du serveur web (Apache/IIS) :


Modifiez les pages d’erreur par défaut.

Désactivez l’ancienne version de SSL et les chiffrements :

  • sur Apache, éditez le fichier /etc/apache2/mods-available/ssl.conf. Exemple :
    • SSLProtocol all -SSLv2 -SSLv3 -TLSv1
    • SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1
  • sur IIS (voir la documentation), effectuez la configuration suivante :
    • Ajoutez la sous-clé de registre dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL
    • Pour que le système puisse utiliser les protocoles qui ne seront pas négociés par défaut (tels que TLS 1.2), remplacez les données de la valeur DWORD de la valeur DisabledByDefault par 0x0 dans les clés de registre suivantes sous la clé Protocols :

      SCHANNEL\Protocols\TLS 1.2\Client

      SCHANNEL\Protocols\TLS 1.2\Server

    • Désactivez SSL x.0 :

      SCHANNEL\Protocols\SSL 3.0\Client : DisabledByDefault : valeur DWORD (32 bits) sur 1

      SCHANNEL\Protocols\SSL 3.0\Server : Enabled : valeur DWORD (32 bits) sur 0

Supprimez la méthode TRACE :

  • sur Apache, éditez le fichier /etc/apache2/conf.d/security : TraceEnable Off
  • sur IIS (voir la documentation), effectuez la configuration suivante :
    • Vérifiez que la fonctionnalité ou le service de rôle Filtrage des demandes est installé.
    • Dans le volet Filtrage des demandes, cliquez sur l’onglet Verbes HTTP, puis sur Refuser un verbe. Dans le volet Actions, saisissez TRACE dans la boîte de dialogue ouverte.

Supprimez la bannière :

  • sur Apache, éditez le fichier /etc/apache2/conf.d/security :
    • ServerSignature Off
    • ServerTokens Prod
  • sur IIS (voir la documentation), effectuez la configuration suivante :
    • Installez URLScan.
    • Editez le fichier Urlscan.ini afin d’obtenir RemoveServerHeader=1.

Limitez la taille des requêtes pour empêcher le téléchargement de fichiers volumineux :

  • Sur Apache (voir la documentation), ajoutez la directive LimitRequestBody (taille en octets) dans le répertoire /.

<Directory />
        Options FollowSymLinks
        AllowOverride None
        LimitRequestBody 10485760
</Directory>
  • Sur IIS (voir la documentation), définissez maxAllowedContentLength (longueur maximale autorisée du contenu) dans les options de filtrage du contenu.