Campaign Classic – Checkliste für Sicherheit und Datenschutz

In diesem Dokument erfahren Sie, welche Schlüsselelemente geprüft werden müssen, um Sicherheit und Datenschutz zu gewährleisten.

Weiterführende Informationen dazu finden Sie auch in den Abschnitten Adobe Marketing Cloud Compliance Overview und Adobe Campaign Security Overview.

Letzte Aktualisierung: 18.07.2019

Datenschutz

Die Datenschutzkonfiguration und entsprechende Härtungsmaßnahmen sind zentrale Bestandteile der Optimierung der Sicherheit.

Unter Mehr erfahren erhalten Sie nähere Informationen zu Best Practices beim Datenschutz:

  • Schützen Sie die personenbezogenen Daten Ihrer Kunden, indem Sie HTTPS anstelle von HTTP verwenden.
  • Verwenden Sie die eingeschränkte Anzeige personenbezogener Daten, um die Daten zu schützen und ihren Missbrauch zu verhindern.
  • Stellen Sie sicher, dass der Zugriff auf verschlüsselte Passwörter beschränkt ist.
  • Schützen Sie Seiten, die möglicherweise personenbezogene Daten enthalten (z. B. Mirrorseiten, Webanwendungen usw.).
Mehr erfahren

Zugriffsverwaltung

Die Zugriffsverwaltung ist ein wichtiger Bestandteil des Sicherheitsmanagements. Im Folgenden finden Sie die wichtigsten Best Practices:

  • Erstellen Sie eine ausreichende Anzahl von Sicherheitsgruppen.
  • Stellen Sie sicher, dass jeder Benutzer über geeignete Zugriffsberechtigungen verfügt.
  • Vermeiden Sie möglichst die Vergabe der Administrator-Funktion, und achten Sie darauf, dass sich nicht zu viele Benutzer in der Administrator-Gruppe befinden.

Weiterführende Informationen finden Sie unter Zugriffsrechte und Ordnerzugriffseigenschaften.

Mehr erfahren

Entwicklung

Folgen Sie bei Entwicklungsaufgaben in Adobe Campaign (Workflows, Javascript, JSSP etc.) immer dieser Anleitung:

  • Scripts: Vermeiden Sie SQL-Anweisungen, verwenden Sie parametrierte Funktionen anstelle von String-Konkatenation, und vermeiden Sie SQL-Injection, indem Sie die zu verwendenden SQL-Funktionen auf die Whitelist setzen.
  • Schutz des Datenmodells: Verwenden Sie spezifische Berechtigungen, um Benutzeraktionen einzuschränken, und fügen Sie Systemfilter hinzu (sysFilter).
  • Hinzufügen von Captchas in Webanwendungen: Hier erfahren Sie, wie Sie Captchas in Ihren öffentlichen Landingpages und Anmeldeseiten hinzufügen können.
Mehr erfahren

Netzwerk, Datenbank und SSL/TLS

Bei der Einrichtung einer On-Premise-Architektur muss unbedingt die Netzwerkkonfiguration geprüft werden.

Stellen Sie sicher, dass der Tomcat-Server NICHT direkt von außerhalb des Servers zugänglich ist:

  • Schließen Sie den Tomcat-Port (8080) auf externen IP-Adressen (muss auf localhost ausgeführt werden).
  • Ordnen Sie den Standard-HTTP-Port (80) nicht dem Tomcat-Port (8080) zu.

Verwenden Sie möglichst eine sichere Verbindung: POP3S statt POP3 (oder POP3 über TLS).

Um Details über die Konfiguration der Datenbank und SSL/TLS zu erfahren, klicken Sie auf die Schaltfläche Mehr erfahren.

Mehr erfahren

Serverkonfiguration

Alle Server müssen konfiguriert werden. Die Konfigurationsdateien sind vom Typ serverConf.xml und config-<instance>.xml. Die folgenden Schlüsselelemente müssen überprüft werden:

  • Sicherheitszonen: Konfigurieren Sie Sicherheitszonen, damit die IP-Adressen von Clients eines Proxys automatisch berücksichtigt werden.
  • Schutz vor Datei-Upload: Grenzen Sie mit einem neuen uploadWhiteList-Attribut die Dateitypen ein, die zum Adobe Campaign-Server hochgeladen werden können. Dieses Attribut kann in der Serverkonfigurationsdatei verwendet werden.
  • Relais: Optimieren Sie die Relais-Konfiguration, indem Sie die Relais-Regeln für nicht verwendete Module/Anwendungen deaktivieren.
  • Schutz vor ausgehenden Verbindungen und Einschränkung der Befehle (serverseitig)
  • Sie können auch zusätzliche HTTP-Header hinzufügen und checkIPConsistent, enableTLS, sessionTimeOutSec aktivieren etc.

Weiterführende Informationen finden Sie im entsprechenden Handbuch.

Mehr erfahren

Konfiguration des Webservers

Dies sind die wichtigsten Best Practices in Bezug auf die Webserver-Konfiguration:

  • Ändern Sie Standard-Fehlerseiten.
  • Deaktivieren Sie die alte SSL-Version und -Ziffern.
  • Entfernen Sie TRACE-Methode

Mehr erfahren

Fragen? Die Community hat die Antworten!

Folgen Sie der Experience Cloud in den sozialen Netzwerken

Copyright © Adobe 2019

Härtungsmaßnahmen für den Datenschutz

Close

Härtungsmaßnahmen für den Datenschutz

URL-Personalisierung

Wenn Sie personalisierte Links zu Ihrem Content hinzufügen, achten Sie darauf, dass im DNS-Teil der URL keine Personalisierung vorhanden ist. Folgende Beispiele sollten niemals in den URL-Attributen <a href=""> oder <img src="">) verwendet werden:

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

Eine spezielle Funktion kann verwendet werden, um diese Links zu schützen, z. B.:

                  function protectPhishing(givenUrl) {
  if( givenUrl.startsWith("https://example.com/ExternalLinks/AutoLoginSecure.ashx") )
return givenUrl
  else 
     logError("Phishing attempt")
}
               

Grundlagen des Datenschutzes

Zunächst sollten Sie sichergehen, dass möglichst überall HTTPS verwendet wird (Mirrorseiten, Webanwendungen usw.).

Links auf diesen Seiten werden im Werber-Header gesendet, wenn eine verlinkte Ressource angefragt wird (Bilder, CSS, JS). Beachten Sie deshalb Folgendes, damit Ihre Kundendaten geschützt bleiben:

  • Verwenden Sie HTTPS in Ihrer verlinkten Seite.
  • Fügen Sie Ihrem Link keine personenbezogenen Daten hinzu (bei der Verwendung einer Webanwendung oder einer Landingpage). Verwenden Sie den Standard-Abstimmmodus (nicht E-Mail).
  • Verwenden Sie keine Trackingsysteme Dritter, auch nicht für Ressourcen (Bilder, JS etc.), die auf einer Domain von Drittanbietern gehostet werden.

Eingeschränkte Anzeige personenbezogener Daten

Manche Kunden verlangen, dass Campaign-Benutzer auf Datensätze zugreifen können, ohne personenbezogene Daten (PII) zu sehen, wie zum Beispiel Vornamen, Nachnamen und E-Mail-Adresse. Adobe Campaign bietet eine Möglichkeit, Daten zu schützen und deren Missbrauch durch reguläre Campaign-Benutzer zu verhindern.

Der Passwortschutz ist ein zentraler Bestandteil des Sicherheitsmanagements. Er ermöglicht die Einschränkung des Zugriffs auf verschlüsselte Passwörter in Campaign. Mit dieser eingeschränkte Anzeige personenbezogener Daten können alle Felder, die Passwörter enthalten, vor Benutzern ohne Administratorberechtigung verborgen werden.

Lesen Sie für weiterführende Informationen das entsprechende Handbuch.

Dateneinschränkung

Wir müssen sicherstellen, dass keine authentifizierten Benutzer mit unzureichender Berechtigung auf die verschlüsselten Passwörter zugreifen können. Dazu gibt es zwei Möglichkeiten: Beschränkung des Zugriffs nur auf die Passwortfelder oder auf die gesamte Entität (erfordert Build 8770 oder höher).

Durch diese Beschränkung können Sie Passwortfelder entfernen, während alle Benutzer über die Benutzerschnittstelle auf das externe Konto zugreifen können. Weiterführende Informationen dazu finden Sie im entsprechenden Handbuch.

  1. Gehen Sie zu Administration > Konfigurieren > Datenschemata.
  2. Erstellen Sie eine neue Schemaerweiterung.

  3. Wählen Sie Externes Konto aus (extAccount).
  4. Bearbeiten Sie im letzten Fenster des Assistenten Ihr neues srcSchema, um den Zugriff auf alle Passwortfelder einzuschränken:

Das Hauptelement (<element name="extAccount" ... >) können Sie ersetzen durch:

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

Ihr erweitertes srcSchema sieht dann folgendermaßen aus:

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

Hinweis: Sie können $(loginId) = 0 or $(login) = 'admin' durch hasNamedRight('admin') ersetzen, wenn Sie möchten, dass alle Benutzer mit Admininstratorrechten diese Passwörter sehen können.

Schutz von Seiten mit personenbezogenen Daten

Wir empfehlen On-Premise-Kunden dringend, Seiten zu schützen, die möglicherweise personenbezogene Daten enthalten (z. B. Mirrorseiten, Webanwendungen usw.).

Ziel dieses Verfahrens ist es, dass diese Seiten nicht indexiert werden, um ein mögliches Sicherheitsrisiko zu verhindern. Hier finden Sie einige hilfreiche Artikel:

Führen Sie die folgenden Schritte aus, um Ihre Seiten zu schützen:

  1. Fügen Sie eine robots.txt-Datei zur Wurzel Ihres Webservers hinzu (Apache oder IIS). Hier der Dateiinhalt:

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

    Rufen Sie für IIS diese Seite auf: https://docs.microsoft.com/en-us/iis/extensions/iis-search-engine-optimization-toolkit/managing-robotstxt-and-sitemap-files

    Für Apache können Sie die Datei in /var/www/robots.txt (Debian) platzieren.

  2. In manchen Fällen ist das Hinzufügen einer robots.txt-Datei unter Sicherheitsaspekten nicht ausreichend. Wenn beispielsweise eine andere Website einen Link zu Ihrer Seite enthält, kann diese in einem Suchergebnis angezeigt werden.

    Es ist deshalb empfehlenswert, neben der robots.txt-Datei einen X-Robots-Tag-Header hinzuzufügen. Dies ist sowohl in Apache als auch in IIS sowie in der Konfigurationsdatei serverConf.xml möglich.

    Weiterführende Informationen finden Sie in diesem Artikel: https://developers.google.com/search/reference/robots_meta_tag

Zugriffsverwaltung

Close

Zugriffsverwaltung

Standardmäßig ist ein WebApp-Benutzer ein Administrator. Um dennoch ausreichend Sicherheit zu gewährleisten, folgen Sie diesen Anweisungen:

  • Ersetzen Sie die spezifische Berechtigung dieses Benutzers (bisher Administrator) durch eine neue Berechtigung (kann 'webapp' genannt werden). Weiterführende Informationen finden Sie im entsprechenden Handbuch.
  • Speichern Sie den WebApp-Benutzer in Ordnern (hauptsächlich Empfängerordner), um auf Empfänger Lese- und Schreibzugriff zu gewähren (siehe das entsprechende Handbuch).
  • Wenn Sie in einer Instanz mehrere Marken (oder mehrere regionale Standorte) verwalten, ist es empfehlenswert, die WebApp-Zugriffsberechtigung auf verschiedene Empfängerordner aufzuteilen:
    • Duplizieren Sie den WebApp-Benutzer, und benennen Sie die Duplikate (z. B. 'webapp_brand1' und 'webapp_brand2').
    • Duplizieren Sie eine Webanwendungsvorlage, sodass Sie für jede Marke eine Vorlage haben, und ändern Sie in den Eigenschaften den Benutzer, indem Sie "Spezifisches Konto nutzen" auswählen (siehe das entsprechende Handbuch).

Erstellen Sie eine ausreichende Anzahl von Sicherheitsgruppen, sodass Ihre Benutzer gerade genügend Rechte besitzen, um ihre Aufgaben zu erledigen (und keine darüber hinausgehenden).

Vergeben Sie nicht die Rolle des Administrators (und teilen Sie sie auch nicht). Erstellen Sie für jeden physischen Benutzer einen Benutzer (um Aktionen genau verfolgen bzw. protokollieren zu können). Fügen Sie Ihre zuvor ernannten Administratoren zur Administrator-Gruppe hinzu. Selbst wenn Sie keinen Administrator verwenden, sollten Sie diese Funktion weder löschen noch deaktivieren (diese Funktion wird für interne Prozesse verwendet). Sie können aber seinen Zugriff auf die Clientkonsole sperren (siehe das entsprechende Handbuch) und seine Sicherheitszone beschränken (auf localhost).

Nehmen Sie nicht zu viele Benutzer in die Administrator-Gruppe auf (bzw. Benutzer mit spezifischen Administratorberechtigungen). Diese Benutzer verfügen über umfassende Rechte (sie können alle SQL-Anweisungen und Befehle auf dem Server ausführen etc.).

Adobe Campaign bietet drei umfangreiche Privilegien (spezifische Berechtigungen):

  • admin: bietet uneingeschränkten Zugriff und erlaubt alle Aktionen (umgeht alle Prüfungen spezifischer Berechtigungen). Enthalten sind demnach auch die spezifischen Berechtigungen für createProcess und SQL.
  • createProcess: ermöglicht die Ausführung externer Programme (auf dem Server).
  • sql: ermöglicht die Ausführung von SQL-Scripts auf der Datenbank (sodass das Sicherheitsmodell umgangen wird). Hinweis: Wenn Sie komplexe Berechnungen durchführen müssen (z. B. Filtern), können Sie Ihren Datenbankadministrator ersuchen, eine SQL-Funktion zu erstellen und sie auf die Whitelist zu setzen (siehe den Abschnitt "Entwicklung").
  • Gewähren Sie diese Privilegien nur sehr wenigen (und vertrauenswürdigen) Benutzern.

Entwicklung

Close

Entwicklung

Scripts

Weiterführende Informationen finden Sie in der JSAPI-Dokumentation für Campaign.

Wenn Sie Scripts mit Workflows, Webanwendungen und JSSP verwenden, folgen Sie diesen Best Practices:

  • Vermeiden Sie möglichst SQL-Anweisungen.
  • Verwenden Sie bei Bedarf parametrierte Funktionen (prepare-Anweisung) anstelle von String-Konkatenation.
    • Nicht empfohlen:
                                    
      sqlGetInt( "select iRecipientId from NmsRecipient where sEmail ='" + request.getParameter('email') +  "'  limit 1" )
      
                                 
    • Empfohlen:

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

Achtung: sqlSelect unterstützt nicht diese Funktion. Verwenden Sie stattdessen die Abfragefunktion der DBEngine-Klasse:

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

               

Um SQL-Injections zu vermeiden, müssen SQL-Funktionen auf die Whitelist gesetzt werden, damit sie in Adobe Campaign verwendet werden können. Sobald sie auf der Whitelist stehen, werden sie für Ihre Benutzer im Ausdrucks-Editor sichtbar. Weiterführende Informationen dazu finden Sie im entsprechenden Handbuch. Achtung: Wenn Sie einen älteren Build als 8140 verwenden, könnte die Option XtkPassUnknownSQLFunctionsToRDBMS auf '1' gesetzt sein. Löschen Sie zum Schutz Ihrer Datenbank diese Option (oder setzen Sie sie auf '0').

Wenn Sie Benutzereingaben zur Erstellung von Filtern in Abfragen oder SQL-Anweisungen verwenden, müssen Sie sie immer escapen (siehe die JSAPI-Dokumentation für Campaign - Schutz von Daten: Escape-Funktionen). Diese Funktionen sind:

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

Schutz Ihres neuen Datenmodells

Auf Ordnerbasis

Weiterführende Hinweise finden Sie in den Handbüchern:

Spezifische Berechtigungen

Zusätzlich zum ordnerbasierten Sicherheitsmodell können Sie Benutzeraktionen auch mit spezifischen Berechtigungen einschränken:

Sie können durch das Hinzufügen von Systemfiltern (sysFilter) das Lesen und Schreiben Ihrer Daten verhindern. Weiterführende Informationen finden Sie im entsprechenden Handbuch.

                  
<sysFilter name="writeAccess">     
    <condition enabledIf="hasNamedRight('myNewRole')=false" expr="FALSE"/>   
</sysFilter>

               

Sie können auch in Schemata definierte Aktionen schützen (SOAP-Methode). Weisen Sie dazu dem Zugriffsattribut als Wert die entsprechende spezifische Berechtigung zu (siehe das entsprechende Handbuch):

                  
<method name="grantVIPAccess" access="myNewRole">
      <parameters>
...
      </parameters>
    </method>

               

Achtung: Sie können spezifische Berechtigungen im Befehlsknoten in einem Navigationsbaum verwenden. Dies ist zwar benutzerfreundlicher, gewährt aber keinen Schutz. Verwenden Sie sie daher nur Client-seitig unter Verwendung des Zugriffsattributs.

Sonstige

Wenn Sie entsprechend der Zugriffsebene des Benutzers vertrauliche Informationen (in einem Schema) schützen müssen, verbergen Sie sie nicht über die Bedingungen enabledIf/visibleIf im Formular, da die gesamten Daten im Bildschirm geladen werden und in Spaltendefinition dargestellt werden können. Verwenden Sie stattdessen eine Overflow-Tabelle. Weiterführende Informationen finden Sie im entsprechenden Handbuch.

Hinzufügen von Captchas in Webanwendungen

Es ist empfehlenswert, öffentlichen Landingpages und Anmeldeseiten ein Captcha hinzuzufügen. Leider ist dies in DCE-Seiten (Digital Content Editor) nicht einfach. Wir zeigen Ihnen, wie Sie ein v5 Captcha oder ein Google reCAPTCHA hinzufügen.

Im Allgemeinen wird ein Captcha im DCE hinzugefügt, indem ein Gestaltungsbaustein erstellt wird, mit dem es in den Seiteninhalt integriert werden kann. Sie müssen außerdem eine Script-Aktivität und einen Test hinzufügen.

Gestaltungsbaustein

  1. Gehen Sie zu Ressourcen > Kampagnenverwaltung > Gestaltungsbausteine und erstellen Sie einen neuen Gestaltungsbaustein.
  2. Verwenden Sie den Inhaltstyp Webanwendung und aktivieren Sie die Option Im Personalisierungsmenü anzeigen.

Weiterführende Informationen dazu finden Sie im entsprechenden Handbuch.

Dies ist ein Beispiel für ein Kampagnen-Captcha:

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

Mit den Zeilen 1 bis 6 werden alle erforderlichen Eingaben erzeugt.

Mit den Zeilen 7 bis zum Ende werden Fehler gehandhabt.

Mit Zeile 4 können Sie die Größe des grauen Captcha-Feldes (Breite/Höhe) sowie die Länge des erzeugten Worts ändern (minWordSize/maxWordSize).

Um Google reCAPTCHA zu nutzen, müssen Sie sich bei Google registrieren und eine neue reCAPTCHA-Website erstellen: https://www.google.com/recaptcha/admin

                  
<div class="g-recaptcha" data-sitekey="YOUR_SITE_KEY"></div>
               

Die Validierungsschaltfläche sollte deaktivierbar sein, doch da wir keine Standard-Schaltfläche bzw. keinen Standard-Link haben, sollte dies besser in HTML erfolgen. Eine Anleitung dazu erhalten Sie unter: https://developers.google.com/recaptcha/

Webanwendung aktualisieren

  1. Öffnen Sie die Eigenschaften Ihrer Webanwendung, um die Boolesche Variable captchaValid hinzuzufügen.

  2. Fügen Sie zwischen der letzten Seite und der Datensatz-Aktivität ein Script und einen Test hinzu. Verbinden Sie den True-Zweig mit dem Datensatz und den anderen Zweig mit der Seite, die das Captcha enthalten wird.

  3. Bearbeiten Sie die Bedingung des True-Zweigs mit "[vars/captchaValid]" gleich True.

  4. Bearbeiten Sie dann die Script-Aktivität (der Inhalt hängt von der verwendeten Captcha Engine ab).
  5. Abschließend können Sie Ihren Gestaltungsbaustein auf der DCE-Seite hinzufügen. Eine Anleitung dazu finden Sie im entsprechenden Handbuch.

    ACHTUNG: Zur Integration von reCAPTCHA müssen Sie clientseitiges JavaScript in den HTML-Inhalt einfügen (in <head>...</head>):

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

Kampagnen-Captcha

                  
var captchaID = request.getParameter("captchaID");
var captchaValue = request.getParameter("captchaValue");
 
if( !CaptchaValidate(captchaID, captchaValue) ) {
  serverForm.logInputError("captchaValue",
                           "Die für das Captcha eingegebenen Zeichen müssen mit denen des Bildes übereinstimmen.",
                           "captchaValue")
  ctx.vars.captchaValid = false
}
else
  ctx.vars.captchaValid = true
               

Zeile 6: Sie können eine beliebige Fehlermeldung eingeben.

Google reCAPTCHA

Lesen Sie bitte die offizielle Anleitung.

                  
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")
}

               

Um JSON.parse zu verwenden, müssen Sie "shared/json2.js" in Ihre Webapp integrieren:

Seit Build 8797 müssen Sie zur Verwendung der Verifizierungs-API-URL diese auf die Whitelist in serverConf setzen, indem Sie sie im Knoten urlPermission hinzufügen:

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

Datenbank und SSL/TLS

Close

Datenbank und SSL/TLS

Datenbank

Beachten Sie unbedingt die Sicherheitsvorschriften für Ihre Datenbank-Engine.

SSL/TLS-Konfiguration

Das Zertifikat können Sie mit openssl überprüfen. Die aktive Cipher Suite können Sie mit nmap überprüfen:

                  
#!/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}

               

Sie können auch ein Phython-Script sslyze verwenden, das beide Aufgaben übernimmt.

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


               

Konfigurieren des Adobe Campaign-Servers

Close

Konfigurieren des Adobe Campaign-Servers

Im Folgenden finden Sie zusätzliche Informationen zur Konfiguration des Adobe Campaign-Servers.

Konfigurieren von Sicherheitszonen

Weiterführende Informationen über die Verwendung der Self-Service-Benutzeroberfläche zur Konfiguration der VPN-Sicherheitszone finden Sie in dieser Technote.

Stellen Sie sicher, dass Ihr Reverse-Proxy in subNetwork nicht erlaubt ist. Ist dies der Fall, wird der gesamte Datenverkehr als von dieser lokalen IP-Adresse kommend und daher als vertrauenswürdig eingestuft.

Minimieren Sie den Einsatz von sessionTokenOnly="true":

  • Achtung: Wenn dieses Attribut auf true gesetzt wird, ist der Benutzer durch CRSF-Attacken (Cross-Site Request Forgery) angreifbar.
  • Zusätzlich ist das sessionToken-Cookie nicht mit einem httpOnly-Flag versehen, weshalb es von einem Client-seitigen Javascript-Code gelesen werden kann.
  • Bei Verwendung von Message Center mit mehreren Ausführungsinstanzen ist jedoch der Einsatz von sessionTokenOnly unumgänglich: Erstellen Sie eine neue Sicherheitszone, setzen Sie sessionTokenOnly auf "true", und fügen Sie dieser Zone nur die benötigten IP-Adressen hinzu.

Setzen Sie möglichst alle allowHTTP, showErrors auf "false" (nicht für localhost), und prüfen Sie sie!

  • allowHTTP = "false": zwingt Benutzer, HTTPS zu verwenden.
  • showErrors = "false": verbirgt technische Fehler (einschließlich SQL-Fehler). Dies verhindert die Anzeige übermäßig vieler Informationen, schränkt aber auch die Fähigkeit des Benutzers ein, Probleme zu lösen (ohne vom Administrator zusätzliche Informationen einzuholen).

Setzen Sie allowDebug nur für IP-Adressen auf true, die von Benutzern/Administratoren verwendet werden, die Fragebögen, WebApps und Berichte erstellen müssen (diese aber nicht in der Vorschau ansehen können). Durch dieses Flag werden in diesen IP-Adressen Relais-Regeln dargestellt, was eine Fehlerbehebung ermöglicht.

Setzen Sie niemals allowEmptyPassword, allowUserPassword, allowSQLInjection auf true. Diese Attribute dienen nur der problemlosen Migration von v5 und v6.0:

  • allowEmptyPassword ermöglicht Benutzern, ein leeres Passwort zu haben. Ist dies bei Ihnen der Fall, weisen Sie alle Benutzer an, bis zu einer bestimmten Deadline ein Passwort zu erstellen. Sobald diese Frist abgelaufen ist, ändern Sie dieses Attribut auf "false".
  • allowUserPassword ermöglicht es Benutzern, ihre Zugangsdaten als Parameter zu senden (sodass sie via Apache/IIS/Proxy gespeichert werden). Diese Funktion diente in der Vergangenheit zur Vereinfachung der API-Nutzung. In Ihrem Cookbook (oder in der Spezifikation) können Sie nachsehen, ob die Funktion von Drittanwendungen genutzt wird. Ist dies der Fall, weisen Sie den Administrator dieser Drittanwendungen an, die Verwendung unserer API zu ändern und die Funktion nicht mehr zu nutzen.
  • allowSQLInjection ermöglicht es Benutzern, SQL-Injections mit einer alten Syntax durchzuführen. Nehmen Sie möglichst bald die im entsprechenden Handbuch beschriebenen Korrekturen vor, um dieses Attribut auf "false" zu setzen.

Mit /nl/jsp/ping.jsp?zones=true können Sie die Konfiguration Ihrer Sicherheitszone überprüfen. Auf dieser Seite wird der aktive Status von Sicherheitsmaßnahmen (mit diesen Sicherheits-Flags berechnet) für die aktuelle IP-Adresse angezeigt.

HttpOnly cookie/useSecurityToken: siehe Flag sessionTokenOnly.

Minimieren Sie die Anzahl der IP-Adressen in der Whitelist: Standardmäßig wurden für Sicherheitszonen drei Wertebereiche für private Netzwerke hinzugefügt. Es ist sehr unwahrscheinlich, dass Sie alle diese IP-Adressen benötigen. Behalten Sie also nur die wirklich notwendigen.

Aktualisieren Sie den WebApp-/internen Benutzer, damit er nur über localhost zugänglich sind.

Schutz vor Datei-Upload

Erkundigen Sie sich bei den Benutzern, welche Arten von Dateien sie über die Schnittstelle nlclient/web zum Server hochladen. In Unternehmen sind die folgenden Dateien gebräuchlich:

  • Bilder (jpg, gif, png, ...)
  • Inhalte (zip, html, css, ...)
  • Marketing-Assets (doc, xls, pdf, psd, tiff, ...)
  • E-Mail-Anhänge (doc, pdf, ...)
  • ETL (txt, csv, tab, ...)
  • etc.

Fügen Sie alle zu serverConf/shared/datastore/@uploadWhitelist hinzu (gültiger regulärer Java-Ausdruck): Weiterführende Informationen finden Sie im entsprechenden Handbuch.

Die Dateigröße ist in Adobe Campaign nicht beschränkt, sie kann aber durch die Konfiguration von IIS/Apache beschränkt werden (siehe entsprechenden Abschnitt).

Relais

Weiterführende Informationen finden Sie im entsprechenden Handbuch.

Standardmäßig werden alle dynamischen Seiten automatisch an den lokalen Tomcat-Server des Geräts weitergeleitet, dessen Web-Modul gestartet wird. Sie können aber auch nicht verwendete Adobe-Campaign-Module ausschließen (z. B. WebApp, Interaction, manche JSPs), indem Sie sie aus den Relais-Regeln entfernen.

Standardmäßig können die Ressourcen der Endkunden über http (httpAllowed="true") angezeigt werden. Da diese Seite personenbezogene Daten enthalten kann (E-Mail-Inhalt/Adresse, Gutscheine, Angebote etc.), sollten Sie für diese Pfade wieder HTTPS zwingend festlegen.

Wenn Sie unterschiedliche Host-Namen verwenden (einen öffentlichen und einen für Benutzer), können Sie die Verknüpfung gewisser Ressourcen, die von den Benutzern benötigt werden, auch über den öffentlichen DNS-Namen verhindern.

Schutz vor ausgehenden Verbindungen

Die Standardliste der URLs, die von JavaScript-Codes (Workflows etc.) aufgerufen werden können, wurde eingeschränkt. Damit eine neue URL zugelassen wird, muss sie der Administrator in der Datei serverConf.xml referenzieren.

Es gibt drei Modi für den Verbindungsschutz:

  • Blocking: Alle URLs, die nicht auf der Whitelist stehen werden blockiert und eine Fehlermeldung wird angezeigt. Dies ist der Standardmodus nach einem Postupgrade.
  • Permissive: Alle URLs, die nicht auf der Whitelist stehen, sind erlaubt.
  • Warnung: Alle URLs, die nicht auf der Whitelist stehen, sind erlaubt, doch der JS-Interpreter gibt eine Warnung aus, sodass sie der Administrator erfassen kann. In diesem Modus werden Warnhinweise vom Typ JST-310027 hinzugefügt.
                  
<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>
               

Neue Kunden verwenden den Blockiermodus. Wenn sie eine neue URL zulassen möchten, müssen sie ihren Administrator ersuchen, die URL auf die Whitelist zu setzen.

Bestehende, aus einer Migration stammende Kunden können einige Zeit den Warnmodus verwenden. In dieser Zeit müssen sie den ausgehenden Verkehr analysieren, bevor sie die URLs genehmigen.

Einschränkung der Befehle (serverseitig)

Mehrere Befehle stehen auf der Blacklist und können nicht mit der execCommand-Funktion ausgeführt werden. Zusätzliche Sicherheit bietet der Einsatz eines eigenen Unix-Benutzerkontos zur Ausführung externer Befehle. Für gehostete Installationen erfolgt diese Einschränkung automatisch. Für On-Premise-Installationen können Sie diese Beschränkung manuell einrichten, indem Sie der Anleitung im entsprechenden Handbuch folgen. Außerdem sind in neu installierten Instanzen nicht die Aktivitäten Script und Externe Aufgabe verfügbar.

Sonstige Konfigurationen

Sie können (allen Seiten) zusätzliche HTTP-Header hinzufügen (siehe das entsprechende Handbuch):

  • Sie können zusätzliche Header wie HSTS, X-FRAME-OPTIONS, CSP etc. hinzufügen.
  • Testen Sie die Header vor der Anwendung in der Produktion in einer Testumgebung. ACHTUNG: Durch das Hinzufügen gewisser Header kann Adobe Campaign beschädigt werden.

Sie können in Adobe Campaign im Element <dbcnx .../> ein Passwort festlegen. Verwenden Sie diese Funktion nicht.

Standardmäßig ist in Adobe Campaign eine Sitzung nicht an eine bestimmte IP-Adresse gebunden. Sie können diese Funktion jedoch aktivieren, um zu verhindern, dass die Sitzung unbefugtem Zugriff ausgesetzt wird. Setzen Sie dazu in serverConf.conf das Attribut checkIPConsistent (im Authentifizierungsknoten) auf "true".

Standardmäßig verwendet der MTA von Adobe Campaign für den Versand von Inhalten an den SMTP-Server keine gesicherte Verbindung. Sie müssen diese Funktion aktivieren (dies kann die Versandgeschwindigkeit verringern). Setzen Sie dazu enableTLS im Knoten <smtp ...> auf "true".

Sie können die Dauer einer Sitzung im Authentifizierungsknoten beschränken (Attribut sessionTimeOutSec).

Webserver-Konfiguration (Apache/IIS)

Close

Webserver-Konfiguration (Apache/IIS)

Ändern Sie Standard-Fehlerseiten.

Alte SSL-Version und -Ziffern deaktivieren:

  • Ändern Sie auf Apache /etc/apache2/mods-available/ssl.conf. Hier ist ein Beispiel:
    • SSLProtocol all -SSLv2 -SSLv3 -TLSv1
    • SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1
  • Nehmen Sie für IIS (siehe Microsoft KB245030) die folgende Konfiguration vor:
    • Fügen Sie einen Registrierungs-Unterschlüssel in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL hinzu.
    • Um dem System die Verwendung von Protokollen zu ermöglichen, die nicht standardmäßig ausgehandelt werden (z. B. TLS 1.1 und TLS 1.2), ändern Sie in den folgenden Registrierungsschlüsseln im Schlüssel Protokolle den DWORD-Wert des Wertes DisabledByDefault in 0x0:

      SCHANNEL\Protocols\TLS 1.1\Client

      SCHANNEL\Protocols\TLS 1.1\Server

      SCHANNEL\Protocols\TLS 1.2\Client

      SCHANNEL\Protocols\TLS 1.2\Server

    • Deaktivieren Sie SSL x.0:

      SCHANNEL\Protocols\SSL 3.0\Client: DisabledByDefault: DWORD (32-Bit) Wert zu 1

      SCHANNEL\Protocols\SSL 3.0\Server: Enabled: DWORD (32-Bit) Wert zu 0

Entfernen Sie die TRACE-Methode:

  • Ändern Sie auf Apache in /etc/apache2/conf.d/security: TraceEnable Off
  • Nehmen Sie für IIS (siehe das entsprechende Handbuch) die folgende Konfiguration vor:
    • Achten Sie darauf, dass der Request-Filtering-Rollendienst oder die entsprechende Funktion installiert ist.
    • Klicken Sie im Bereich Request Filtering auf den Tab HTTP verbs und dann im Bereich Aktionen auf Deny Verb und geben Sie im offenen Dialogfenster TRACE ein.

Entfernen Sie das Banner:

  • Ändern Sie auf Apache /etc/apache2/conf.d/security:
    • ServerSignature auf Off
    • ServerTokens auf Prod
  • Gehen Sie auf IIS folgendermaßen vor (siehe Microsoft KB317741):
    • Installieren Sie URLScan.
    • Ändern Sie die Datei Urlscan.ini in RemoveServerHeader=1.

Begrenzen Sie die Größe der Abfrage, um zu verhindern, dass wichtige Dateien hochgeladen werden.

  • Fügen Sie auf Apache das Verzeichnis LimitRequestBody (Größe in Bytes) im / Verzeichnis hinzu. Siehe das entsprechende Handbuch.

                            
    <Directory />
            Options FollowSymLinks
            AllowOverride None
            LimitRequestBody 10485760
    </Directory>
                         
  • Definieren Sie auf IIS in den Inhaltsfilteroptinen maxAllowedContentLength (maximal erlaubte Inhaltslänge). Siehe das entsprechende Handbuch).