Personalisering och sekretess privacy
URL PERSONALIZATION url-personalization
När du lägger till anpassade länkar till ditt innehåll bör du alltid undvika att ha en personalisering i värdnamnsdelen av webbadressen för att undvika eventuella säkerhetsbrister. Följande exempel får aldrig användas i alla URL-attribut <a href="">
eller <img src="">
:
<%= url >
https://<%= url >
https://<%= domain >/path
https://<%= sub-domain >.domain.tld/path
https://sub.domain<%= main domain %>/path
Rekommendation
Om du vill validera och kontrollera att du inte använder ovanstående kör du en fråga om spårning av URL-tabell via Kampanjredigeraren för allmän fråga eller skapar ett arbetsflöde med filtervillkor i frågeaktiviteten.
Exempel:
-
Skapa ett arbetsflöde och lägg till en Query-aktivitet. Läs mer.
-
Öppna aktiviteten Fråga och skapa ett filter för tabellen
nmsTrackingUrl
enligt följande:source URL starts with http://<% or source URL starts with https://<%
-
Kör arbetsflödet och kontrollera om det finns några resultat.
-
I så fall öppnar du utdataövergången för att visa en lista med URL-adresser.
URL-signatur
För att förbättra säkerheten har en signaturmekanism införts för att spåra länkar i e-postmeddelanden. Den är tillgänglig från och med byggena 19.1.4 (9032@3a9dc9c) och 20.2. Den här funktionen är aktiverad som standard.
Requested URL '…' was not found.
Dessutom kan du använda en förbättring för att inaktivera URL:er som genererats i tidigare versioner. Den här funktionen är inaktiverad som standard. Du kan kontakta kundtjänst om du vill aktivera den här funktionen.
Om du kör i version 19.1.4 kan du få problem med push-meddelandeleveranser med hjälp av spårningslänkar eller leveranser med ankartaggar. I så fall rekommenderar vi att du inaktiverar URL-signatur.
Om du är en Campaign-värd, hanterad Cloud Service eller hybridkund måste du kontakta kundtjänst för att inaktivera URL-signaturen.
Om du kör Campaign i en hybridarkitektur måste du se till att den värdbaserade mellankällinstansen har uppgraderats enligt följande innan du aktiverar URL-signatur:
- Först den lokala marknadsinstansen
- Uppgradera sedan till samma version som den lokala marknadsinstansen eller till en något högre version
I annat fall kan följande problem uppstå:
- Innan mellankällinstansen uppgraderas skickas URL:er utan signatur via den här instansen.
- När mellankällinstansen har uppgraderats och URL-signatur har aktiverats för båda instanserna, avvisas de URL:er som tidigare har skickats utan signatur. Orsaken är att en signatur begärs av de spårningsfiler som har tillhandahållits av marknadsinstansen.
Om du vill inaktivera URL:er som har skapats i tidigare versioner följer du de här stegen på alla Campaign-servrar samtidigt:
- Ändra alternativet blockRedirectForUnsignedTrackingLink till true i serverkonfigurationsfilen (
serverConf.xml
). - Starta om tjänsten
nlserver
. - Starta om servern
web
på serverntracking
(apache2 på Debian, httpd på CentOS/RedHat, IIS på Windows).
Om du vill aktivera URL-signering följer du de här stegen på alla Campaign-servrar samtidigt:
- Ändra alternativet signEmailLinks till true i serverkonfigurationsfilen (
serverConf.xml
). - Starta om tjänsten nlserver.
- Starta om servern
web
på serverntracking
(apache2 på Debian, httpd på CentOS/RedHat, IIS på Windows).
Databegränsning
Du måste se till att de krypterade lösenorden inte är tillgängliga för en autentiserad användare med låg behörighet. Det gör du genom att begränsa åtkomsten till endast lösenordsfält eller till hela entiteten (behöver ett build >= 8770).
Med den här begränsningen kan du ta bort lösenordsfält men låta det externa kontot vara tillgängligt från gränssnittet för alla användare. Läs mer.
Gör så här:
-
Bläddra till mappen Administration > Configuration > Data schemas i Campaign Explorer.
-
Skapa ett datarema, som en Extension of a schema.
-
Välj External Account (extAccount).
-
I den sista assistentskärmen redigerar du ditt nya srcSchema för att begränsa åtkomsten till alla lösenordsfält:
Du kan ersätta huvudelementet (
<element name="extAccount" ... >
) med:code language-sql <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>
Så din utökade srcSchema kan se ut så här:
code language-sql <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>
note note NOTE Du kan ersätta $(loginId) = 0 or $(login) = 'admin'
medhasNamedRight('admin')
så att alla användare med administratörsbehörighet kan se de här lösenorden.
Protect-sidor med PI
Vi rekommenderar starkt att kunder på plats skyddar sidor som kan innehålla personlig information (PI) som spegelsidor, webbapplikationer osv.
Målet med detta förfarande är att förhindra att dessa sidor indexeras, vilket förhindrar en potentiell säkerhetsrisk. Här är några användbara artiklar:
Följ de här stegen för att skydda sidorna:
-
Lägg till en
robots.txt
-fil i webbserverns rot (Apache eller IIS). Här är filens innehåll:code language-sql # Make changes for all web spiders User-agent: *Disallow: /
Information om IIS finns på sidan.
För Apache kan du placera filen i /var/www/robots.txt (Debian).
-
Ibland räcker det inte med att lägga till en robots.txt-fil när det gäller säkerhet. Om en annan webbplats till exempel innehåller en länk till sidan kan den visas i ett sökresultat.
Utöver filen robots.txt bör du lägga till en X-Robots-Tag -rubrik. Du kan göra det i Apache eller IIS och i konfigurationsfilen serverConf.xml .
Mer information finns i den här artikeln.
Sekretessförfrågningar
Se den här sidan för allmän information om vad sekretesshantering är och implementeringsstegen i Adobe Campaign. Du hittar även bästa praxis och en översikt över användarprocessen och personifierna.