Privacy

Richieste sulla privacy

Adobe Campaign offre una serie di strumenti per aiutarti con la conformità in materia di privacy in relazione a GDPR e CCPA.

Fai riferimento a questa pagina per informazioni generali su cosa è Privacy Management e sui passaggi di implementazione in Adobe Campaign. Troverai inoltre le best practice e una panoramica del processo utente e dei singoli utenti.

Personalizzazione URL

Quando aggiungi collegamenti personalizzati al contenuto, evita sempre di avere alcuna personalizzazione nella parte dell’URL relativa al nome host per evitare potenziali lacune nella sicurezza. Gli esempi seguenti non devono mai essere utilizzati in tutti gli attributi URL <a href=""> o <img src="">:

  • <%= url >
  • https://<%= url >
  • https://<%= domain >/path
  • https://<%= sub-domain >.domain.tld/path
  • https://sub.domain<%= main domain %>/path

Consiglio

Per convalidare e assicurarsi di non utilizzare quanto sopra, esegui una query sulla tabella URL di tracciamento tramite Editor query generico campagna o crea un flusso di lavoro con criteri di filtro nell' attività query.

Esempio:

  1. Crea un flusso di lavoro e aggiungi un’attività Query . Ulteriori informazioni.

  2. Apri l’attività Query e crea un filtro sulla tabella nmsTrackingUrl come segue: l’URL sorgente inizia con http://<% o l’URL sorgente inizia con https://<%.

  3. Esegui il flusso di lavoro e controlla se ci sono dei risultati.

  4. In tal caso, apri la transizione di output per visualizzare l’elenco degli URL.

Meccanismo di firma

Per migliorare la sicurezza, nella build 19.1.4 (9032@3a9dc9c) è stato introdotto un nuovo meccanismo di firma per il tracciamento dei collegamenti nelle e-mail ed è disponibile nelle Build 19.1.4 (9032@3a9dc9c) e Campaign 20.2. Questa opzione è abilitata per impostazione predefinita per tutti i clienti.

NOTA

Quando fai clic su un URL firmato non valido, viene restituito il seguente errore: "Impossibile trovare l'URL richiesto "…".

Inoltre, a partire dalla versione Campaign 20.2 e Gold Standard, i clienti in hosting e ibridi possono utilizzare un miglioramento per disabilitare gli URL generati dalle build precedenti. Questa opzione è disabilitata per impostazione predefinita. Per abilitare questa funzione, contatta l’ Assistenza clienti .

Per attivare questo nuovo meccanismo, i clienti on-premise devono seguire questi passaggi su tutti i server Campaign:

  1. Nel file di configurazione del server (serverConf.xml), cambia blockRedirectForUnsignedTrackingLink in true.
  2. Riavvia il servizio nlserver .
  3. Sul server di tracciamento, riavvia il server web (apache2 su Debian, httpd su CentOS/RedHat, IIS su Windows).

I clienti in esecuzione su Gold Standard 19.1.4 possono riscontrare problemi con le consegne di notifiche push utilizzando un collegamento di tracciamento o con le consegne che utilizzano tag di ancoraggio. In tal caso, Adobe consiglia di disabilitare il nuovo meccanismo di firma per i collegamenti di tracciamento:

I clienti in hosting e ibridi devono contattare Customer Careto per disattivare questo meccanismo.

I clienti on-premise possono eseguire la scansione seguendo il passaggio seguente:

  1. Nel file di configurazione del server (serverConf.xml), cambia signEmailLinks in false.
  2. Riavvia il servizio nlserver .
  3. Sul server di tracciamento, riavvia il server web (apache2 su Debian, httpd su CentOS/RedHat, IIS su Windows).

Restrizione dei dati

Devi accertarti che le password crittografate non siano accessibili da un utente autenticato con privilegi bassi. Per fare questo, ci sono due modi principali: limita l'accesso ai campi password solo o all'intera entità (è necessaria una build >= 8770).

Questa limitazione consente di rimuovere i campi password, ma consente all’account esterno di essere accessibile dall’interfaccia per tutti gli utenti. Consulta questa pagina.

  1. Vai in Administration > Configuration > Data schemas.

  2. Crea un nuovo Extension of a schema.

  3. Scegli External Account (extAccount).

  4. Nell’ultima schermata della procedura guidata, puoi modificare il nuovo srcSchema per limitare l’accesso a tutti i campi password:

    Puoi sostituire l’elemento principale (<element name="extAccount" ... >) con:

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

    Il tuo srcSchema esteso può avere un aspetto simile a:

    <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>    
    
    NOTA

    È possibile sostituire $(loginId) = 0 or $(login) = 'admin' con hasNamedRight('admin') per consentire a tutti gli utenti con diritti di amministratore di visualizzare queste password.

Protezione delle pagine contenenti PII

Consigliamo vivamente ai clienti on-premise di proteggere le pagine che potrebbero contenere informazioni personali come pagine mirror, applicazioni web, ecc.

L'obiettivo di questa procedura è evitare l'indicizzazione di queste pagine, evitando così un potenziale rischio per la sicurezza. Ecco alcuni articoli utili:

Per proteggere le pagine, effettua le seguenti operazioni:

  1. Aggiungi un file robots.txt nella directory principale del server web (Apache o IIS). Ecco il contenuto del file:

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

    Per IIS, fare riferimento a questa pagina.

    Per Apache, puoi inserire il file in /var/www/robots.txt (Debian).

  2. A volte l'aggiunta di un file robots.txt non è sufficiente in termini di sicurezza. Ad esempio, se un altro sito web contiene un collegamento alla pagina, potrebbe essere visualizzato in un risultato della ricerca.

Oltre al file robots.txt, è consigliabile aggiungere un'intestazione X-Robots-Tag. Puoi farlo in Apache o IIS e nel file di configurazione serverConf.xml.

Per ulteriori informazioni, consulta questo articolo.

In questa pagina