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

Datenschutzkonfiguration und entsprechende Härtungsmaßnahmen

Hier klicken


icon_clef

Zugriffsverwaltung

Hier klicken


Server

Serverkonfiguration

Hier klicken


Development

Skripterstellung und Kodierung

Hier klicken


Network

Netzwerk, Datenbank und SSL/TLS

Hier klicken


Web

Konfiguration des Webservers

Hier klicken


Datenschutz

Privacy

Die Datenschutzkonfiguration und entsprechende Härtungsmaßnahmen sind zentrale Bestandteile der Optimierung der Sicherheit. Lesen Sie diesen Abschnitt durch, um mehr über Best Practices für den Datenschutz zu erfahren:

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

Datenschutzanfragen

Adobe Campaign bietet eine Reihe von Werkzeugen, die Ihnen bei der Einhaltung der Datenschutzbestimmungen gemäß DSGVO und CCPA helfen.

Auf dieser Seite finden Sie allgemeine Informationen zum Thema „Datenschutzverwaltung“ und zu den Implementierungsschritten in Adobe Campaign. Außerdem finden Sie hier Best Practices sowie eine Übersicht über die Verwendung und die damit verbundenen Rollen.

URL-Personalisierung

Wenn Sie personalisierte Links zu Ihrem Inhalt hinzufügen, achten Sie darauf, dass im Hostname-Teil der URL keine Personalisierung vorhanden ist. So lassen sich mögliche Sicherheitslücken verhindern. 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

Empfehlung

Um zu überprüfen und sicherzustellen, dass Sie die oben genannten Beispiele nicht verwenden, führen Sie mit dem generischen Abfragetool in Campaign eine Abfrage der Tracking-URL-Tabelle aus oder erstellen Sie einen Workflow mit Filterkriterien in der Abfrageaktivität.

Beispiel:

  1. Erstellen Sie einen Workflow und fügen Sie eine Abfrageaktivität hinzu. Weitere Informationen.
  2. Öffnen Sie die Abfrageaktivität und erstellen Sie wie folgt einen Filter für die nmsTrackingUrl-Tabelle: Quell-URL beginnt mit http://<% oder Quell-URL beginnt mit https://<%.
  3. Führen Sie den Workflow aus und prüfen Sie, ob Ergebnisse vorliegen.
  4. Sollte dies der Fall sein, öffnen Sie die ausgehende Transition, um die Liste der URLs anzuzeigen.
Abfrage für dynamische URLs

Signaturmechanismus

Um die Sicherheit zu verbessern, wurde in Build 19.1.4 (9032@3a9dc9c) ein neuer Signaturmechanismus zum Tracking von Links in E-Mails eingeführt. Diese Option ist standardmäßig für alle Kunden aktiviert.

Hinweis:

Wenn auf eine fehlerhafte signierte URL geklickt wird, wird der folgende Fehler zurückgegeben: „Angeforderte URL '... ' wurde nicht gefunden.“

Außerdem können gehostete Kunden mit  Build 19.1.4 (9032@3a9dc9c) eine Verbesserung verwenden, um fehlerhafte URLs zu deaktivieren, die von früheren Builds generiert wurden. Diese Option ist standardmäßig deaktiviert. Wenden Sie sich an die Kundenunterstützung, um diese Funktion zu aktivieren.

Um diesen neuen Mechanismus zu aktivieren, müssen nicht gehostete Kunden auf allen Campaign-Servern die folgenden Schritte ausführen:

  1. Ändern Sie in der Server-Konfigurationsdatei (serverConf.xml) blockRedirectForUnsignedTrackingLink in true.
  2. Starten Sie den nlserver-Dienst neu.
  3. Starten Sie den Webserver (apache2 unter Debian; httpd unter CentOS/RedHat; IIS unter Windows) auf dem Trackingserver neu.

Dateneinschränkung

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

Mit dieser Einschränkung können Sie Passwortfelder entfernen, das externe Konto jedoch für alle Benutzer über die Benutzeroberfläche zugänglich machen. Weitere Informationen finden Sie in der Dokumentation.

  1. Gehen Sie zu Administration > Konfiguration > Datenschemata.

  2. Erstellen Sie eine neue Schemaerweiterung.

    Passwort
  3. Wählen Sie Externes Konto (extAccount) aus.

  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 oder $(login) = 'admin' durch hasNamedRight('admin') ersetzen, wenn Sie möchten, dass alle Benutzer mit Administratorrechten 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.

    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.

    Weitere Informationen finden Sie in diesem Artikel.

Zugriffsverwaltung

Access

Die Verwaltung der Zugriffsberechtigungen 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.

Weitere Informationen finden Sie unter Zugriffsberechtigungen and Ordnerzugriffseigenschaften.


WebApp-Benutzer

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). Weitere Informationen finden Sie in dieser Dokumentation.
  • Speichern Sie den WebApp-Benutzer in Ordnern (hauptsächlich Empfängerordner), um auf Empfänger Lese- und Schreibzugriff zu gewähren. Weitere Informationen finden Sie in dieser Dokumentation.
  • Wenn Sie in einer Instanz mehrere Marken (oder mehrere regionale Standorte) verwalten, ist es empfehlenswert, die WebApp-Zugriffsberechtigung auf verschiedene Empfängerordner aufzuteilen. Führen Sie hierzu die folgenden Schritte aus:
    1. Duplizieren Sie den WebApp-Benutzer.
    2. Geben Sie für jedes Duplikat einen Namen ein. Beispiele: webapp_brand, webapp_brand2 usw.
    3. 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.  Weitere Informationen finden Sie in dieser Dokumentation.

Sicherheitsgruppen und Administratoren

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

Adobe Campaign bietet drei umfangreiche Privilegien über spezifische Berechtigungen:

  • ADMINISTRATION (admin): bietet uneingeschränkten Zugriff und erlaubt alle Aktionen (umgeht alle Prüfungen spezifischer Berechtigungen). Enthalten sind demnach auch die spezifischen Berechtigungen für die AUSFÜHRUNG VON PROGRAMMEN (createProcess) und SQL.
  • AUSFÜHRUNG VON PROGRAMMEN (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. Weitere Informationen finden Sie in diesem Abschnitt.
  • Gewähren Sie diese Privilegien nur sehr wenigen (und vertrauenswürdigen) Benutzern.

Skripterstellung und Kodierung

Dev

Folgen Sie bei Entwicklungsaufgaben in Adobe Campaign (Workflows, Javascript, JSSP usw.) immer diesen Richtlinien:

  • Skripterstellung: 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.

Skripterstellung

Weitere 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 diese Funktion nicht. 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. Weitere Informationen finden Sie in der DokumentationAchtung: 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

Weitere Informationen finden Sie in diesen Abschnitten der Produktdokumentation:

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. Weitere Informationen finden Sie in der Dokumentation.
<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.
<method name="grantVIPAccess" access="myNewRole">
      <parameters>
...
      </parameters>
    </method>

         

Weitere Informationen finden Sie in diesem Abschnitt.

Vorsicht:

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.

Überlauftabelle

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 gesamte Entität im Bildschirm geladen werden und in Spaltendefinition dargestellt werden können. Verwenden Sie stattdessen eine Überlauftabelle. Weitere Informationen finden Sie in dieser Dokumentation.

Captchas in Webanwendungen hinzufügen

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.

    Weitere Informationen finden Sie in dieser Dokumentation.

    Dies ist ein Beispiel für ein Campaign-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.
    <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 auf dieser Seite.

Aktualisieren der Webanwendung

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

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

    Captcha – Schritt 2
  3. Bearbeiten Sie die Bedingung der True-Verzweigung mit "[vars/captchaValid]" gleich True.

    Captcha – Schritt 3
  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 Seite hinzufügen. Weitere Information finden Sie in der Dokumentation

    Captcha – Schritt 5
    Captcha – Schritt 6

    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>

Campaign-Captcha

var captchaID = request.getParameter("captchaID");
var captchaValue = request.getParameter("captchaValue");
 
if( !CaptchaValidate(captchaID, captchaValue) ) {
  serverForm.logInputError("captchaValue",
                           "The characters you typed for the captcha must match the image ones.",
                           "captchaValue")
  ctx.vars.captchaValid = false
}
else
  ctx.vars.captchaValid = true

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

Google reCAPTCHA

Weitere Informationen finden Sie in der offiziellen Dokumentation.

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:

Captcha – Schritt 7

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

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

Netzwerk, Datenbank und SSL/TLS

Network

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


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

Serverkonfiguration

Server

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.

Weitere Informationen finden Sie in der Dokumentation zur Konfiguration von Campaign-Servern und in der Beschreibung der Serverkonfigurationsdatei.


Konfigurieren von Sicherheitszonen

Vorsicht:

Ab Build 8977 ist die Self-Service-Benutzeroberfläche für Sicherheitszonen nicht mehr verfügbar.

  • Wenn Sie auf AWS gehostet werden, müssen Sie IPs im Control Panel auf die Whitelist setzen. Weitere Informationen finden Sie in der entsprechenden Dokumentation.
  • Wenn Sie nicht auf AWS gehostet werden, kontaktieren Sie das Adobe-Supportteam, um IPs auf die Whitelist zu setzen.

 Um zu überprüfen, ob Ihre Instanz auf AWS gehostet wird, führen Sie die in diesem Abschnitt beschriebenen Schritte aus.

Weitere 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 in der entsprechenden Dokumentation 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, ...)
  • usw.

Fügen Sie alle zu serverConf/shared/datastore/@uploadWhitelist hinzu (gültiger regulärer Java-Ausdruck). Weitere Informationen finden Sie in der entsprechenden Dokumentation

Die Dateigröße ist in Adobe Campaign nicht beschränkt, sie kann aber durch die Konfiguration von IIS/Apache beschränkt werden. Weitere Informationen finden Sie in diesem Abschnitt.

Relais

Weitere Informationen finden Sie in der entsprechenden Dokumentation.

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 Seiten personenbezogene Daten (E-Mail-Inhalt/Adresse, Gutscheine, Angebote etc.) enthalten können, 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 der ausgehenden Verbindung

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 in der entsprechenden Dokumentation folgen. Außerdem sind in neu installierten Instanzen die Workflow-Aktivitäten Script und Externe Aufgabe nicht verfügbar.

Sonstige Konfigurationen

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

  • 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 der Datei serverConf.xml 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).

Konfiguration des Webservers

web

Im Folgenden finden die wichtigsten Best Practices in Bezug auf die Webserver-Konfiguration (Apache/IIS).


Ändern Sie Standard-Fehlerseiten.

Alte SSL-Version und -Ziffern deaktivieren:

  • Ändern Sie auf Apache /etc/apache2/mods-available/ssl.conf. Beispiel:
    • SSLProtocol all -SSLv2 -SSLv3 -TLSv1
    • SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1
  • Nehmen Sie für IIS (siehe die entsprechende Dokumentation) 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.2), ändern Sie in den folgenden Registrierungsschlüsseln im Schlüssel Protokolle den DWORD-Wert des Wertes DisabledByDefault in 0x0:

      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 die entsprechende Dokumentation) 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 auf Deny Verb. Geben Sie im Bereich Aktionen TRACE im offenen Dialogfenster ein.

Entfernen Sie das Banner:

  • Ändern Sie auf Apache /etc/apache2/conf.d/security:
    • ServerSignature auf Off
    • ServerTokens auf Prod
  • Nehmen Sie für IIS (siehe die entsprechende Dokumentation) die folgende Konfiguration vor:
    • 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 (siehe die entsprechende Dokumentation) die Anweisung LimitRequestBody (Größe in Bytes) in / directory hinzu.

<Directory />
        Options FollowSymLinks
        AllowOverride None
        LimitRequestBody 10485760
</Directory>
  • Definieren Sie auf IIS (siehe die entsprechende DokumentationmaxAllowedContentLength (maximal erlaubte Inhaltslänge) in den Inhaltsfilteroptionen.