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 si intende per gestione della privacy 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 verificare di non utilizzare quanto sopra, esegui una query sulla tabella URL di tracciamento tramite Editor query generico di Campaign o creare un flusso di lavoro con i criteri di filtro nella 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.

Firma URL

Per migliorare la sicurezza, è stato introdotto un meccanismo di firma per il tracciamento dei collegamenti nelle e-mail. È disponibile nelle Build 19.1.4 (9032@3a9dc9c) e Campaign 20.2. Questa funzione è abilitata per impostazione predefinita.

NOTA

Quando si fa clic su un URL firmato non valido, viene restituito questo errore: "Impossibile trovare l'URL richiesto '…'."

Inoltre, a partire da Campaign 20.2 e dal Gold Standard Puoi utilizzare un miglioramento per disabilitare gli URL generati nelle build precedenti. Questa funzione è disabilitata per impostazione predefinita. Puoi rivolgerti a Assistenza clienti per abilitare questa funzione.

Se siete in esecuzione Gold Standard 19.1.4, potrebbero verificarsi problemi con le consegne di notifiche push che utilizzano collegamenti di tracciamento o con le consegne che utilizzano tag di ancoraggio. In tal caso, si consiglia di disabilitare la firma URL.

Se esegui Campaign in locale o in un’architettura ibrida, devi contattare Assistenza clienti per disattivare la firma URL.

Se esegui Campaign in un’architettura ibrida, prima di abilitare la firma URL, assicurati che l’istanza di mid-sourcing in hosting sia stata aggiornata come segue:

  • Prima dell’istanza di marketing locale
  • Alla stessa versione dell’istanza di marketing locale o a una versione leggermente superiore

In caso contrario, potrebbero sorgere alcuni dei seguenti problemi:

  • Prima dell’aggiornamento dell’istanza di mid-sourcing , gli URL vengono inviati senza firma tramite questa istanza.
  • Dopo l’aggiornamento dell’istanza di mid-sourcing e l’abilitazione della firma URL in entrambe le istanze, gli URL precedentemente inviati senza firma vengono rifiutati. Il motivo è che i file di tracciamento forniti dall’istanza di marketing richiedono una firma.

Per disabilitare gli URL generati nelle build precedenti, segui questi passaggi su tutti i server Campaign allo stesso tempo:

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

Per abilitare la firma URL, segui questi passaggi su tutti i server Campaign contemporaneamente:

  1. Nel file di configurazione del server (serverConf.xml), modifica signEmailLinks a false.
  2. Riavvia nlserver servizio.
  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. Accedi 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" ... >) da:

    <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, consulta questa pagina.

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

  2. A volte è possibile aggiungere un robots.txt file 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 robots.txt è consigliabile aggiungere un X-Robots-Tag intestazione. Puoi farlo in Apache o IIS e nella serverConf.xml file di configurazione.

Per ulteriori informazioni, consulta articolo.

In questa pagina