Confidentialité

Demandes d’accès à des informations personnelles

Adobe Campaign propose un ensemble d’outils pour vous aider à respecter la confidentialité dans le cadre du RGPD et de la CCPA.

Reportez-vous à cette page pour obtenir des informations générales sur la gestion de la protection des données et les étapes de son implémentation dans Adobe Campaign. 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 du 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://<%= domain >/path
  • https://<%= sub-domain >.domain.tld/path
  • https://sub.domain<%= main domain %>/path

Recommandation

Pour valider et vous assurer 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.

Signature d'URL

Pour améliorer la sécurité, un mécanisme de signature pour les liens de tracking dans les e-mails été ajouté. Il est disponible dans la build 19.1.4 (9032@3a9dc9c) et Campaign 20.2. Cette fonctionnalité est activée par défaut.

REMARQUE

Lorsqu'un utilisateur clique sur une URL signée incorrecte, cette erreur est renvoyée : "L'URL '…' demandée est introuvable."

De plus, depuis Campaign 20.2 et la version Gold Standard, vous pouvez utiliser une amélioration pour désactiver les URL générées dans les builds précédents. Cette fonctionnalité est désactivée par défaut. Vous pouvez contacter l'Assistance clientèle pour activer cette fonctionnalité.

Si vous exécutez Gold Standard 19.1.4, vous pouvez rencontrer des problèmes avec les diffusions de notification push utilisant des liens de tracking ou celles qui utilisent des balises d'ancrage. Si tel est le cas, nous vous recommandons de désactiver la signature d'URL.

Que vous exécutiez Campaign On-premise ou dans une architecture hybride, vous devez contacter l'Assistance clientèle pour que la signature d'URL soit désactivée.

Si vous exécutez Campaign dans une architecture hybride, avant d'activer la signature d'URL, vérifiez que l'instance de mid-sourcing hébergée a été mise à niveau comme suit :

  • Avant l’instance marketing On-premise
  • Vers la même version que l'instance marketing On-premise ou vers une version légèrement supérieure ;

Dans le cas contraire, certains des problèmes suivants peuvent se produire :

  • Avant la mise à niveau de l'instance de mid-sourcing, les URL sont envoyées sans signature via cette instance.
  • Une fois l'instance de mid-sourcing mise à niveau et la signature d'URL activée sur les deux instances, les URL précédemment envoyées sans signature sont rejetées. Cela est dû au fait qu'une signature est demandée par les fichiers de tracking fournis par l'instance marketing.

Pour désactiver les URL qui ont été générées dans les builds précédents, procédez comme suit sur tous les serveurs Campaign en même temps :

  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).

Pour activer la signature d'URL, procédez comme suit sur tous les serveurs Campaign en même temps :

  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 à cette page.

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

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

  3. Sélectionnez Compte externe (extAccount).

  4. Dans le dernier écran de l’assistant, vous pouvez modifier votre 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 or $(login) = 'admin' par hasNamedRight('admin') pour autoriser tous les utilisateurs disposant du droit admin à voir 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 à éviter ainsi un risque de sécurité potentiel. Voici quelques articles utiles :

Pour protéger vos pages, procédez comme suit :

  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, reportez-vous à 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, reportez-vous à cet article.

Sur cette page