[Nur On-Premise/Hybrid]{class="badge yellow" title="Gilt nur für Hybrid- und On-Premise-Bereitstellungen"}

Sicherheitszonen definieren (On-Premise) defining-security-zones

Jeder Operator muss mit einer Zone verknüpft sein, um sich bei einer Instanz anmelden zu können, und die IP des Operators muss in die Adressen oder Adresssätze aufgenommen werden, die in der Sicherheitszone definiert sind. Die Konfiguration der Sicherheitszone erfolgt in der Konfigurationsdatei des Adobe Campaign-Servers.

Benutzer werden über ihr Profil in der Konsole mit einer Sicherheitszone verknüpft, auf die über die Administration > Zugriffe > Benutzer Knoten. Weitere Informationen.

NOTE
Dieses Verfahren beschränkt sich auf On-Premise -Implementierungen.
Als gehostet -Kunde, wenn Sie auf Campaign Control Panel, können Sie die Sicherheitszonen-Benutzeroberfläche verwenden. Weitere Informationen
Sonstiges hybrid/gehostet Kunden müssen sich an das Adobe-Supportteam wenden, um IP zur Zulassungsliste hinzuzufügen.

Sicherheitszonen erstellen creating-security-zones

Eine Zone wird wie folgt definiert:

  • einen oder mehrere IP-Adressbereiche (IPv4 und IPv6)
  • einen technischen Namen für jeden IP-Adressbereich

Sicherheitszonen sind miteinander verbunden. Das bedeutet, dass die Definition einer neuen Zone innerhalb einer anderen Zone die Anzahl der Benutzer verringert, die sich bei ihr anmelden können, während die den einzelnen Benutzern zugewiesenen Rechte erhöht werden.

Bereiche müssen während der Server-Konfiguration im serverConf.xml -Datei. Alle in der serverConf.xml aufgelistet in diesem Abschnitt.

In jedem Bereich werden Berechtigungen definiert, wie beispielsweise:

  • HTTP-Verbindung anstelle von HTTPS
  • Fehleranzeige (Java-Fehler, JavaScript, C++ usw.)
  • Vorschau für Bericht und WebApp
  • Authentifizierung über Anmeldung/Kennwort
  • Nicht sicherer Verbindungsmodus
NOTE
Jeder Benutzer muss einer Zone zugeordnet werden. Wenn die IP-Adresse des Benutzers zu dem durch die Zone definierten Bereich gehört, kann sich der Benutzer bei der Instanz anmelden.
Die IP-Adresse des Benutzers kann in mehreren Bereichen definiert werden. In diesem Fall erhält der Benutzer die set der für jedes Gebiet verfügbaren Rechte.

Die vordefinierten serverConf.xml -Datei umfasst drei Bereiche: public, VPN und LAN.

NOTE
Die vordefinierte Konfiguration ist sicher. Vor der Migration von einer früheren Version von Adobe Campaign kann es jedoch erforderlich sein, die Sicherheit vorübergehend zu verringern, um die neuen Regeln zu migrieren und zu genehmigen.

Beispiel für die Definition eines Bereichs im serverConf.xml Datei:

<securityZone allowDebug="false" allowHTTP="false" label="Public Network" name="public">
<subNetwork label="All addresses" mask="*" name="all"/>

<securityZone allowDebug="true" allowHTTP="false" label="Private Network (VPN)"
              name="vpn" showErrors="true">

  <securityZone allowDebug="true" allowEmptyPassword="true" allowHTTP="true"
                allowUserPassword="false" label="Private Network (LAN)" name="lan"
                sessionTokenOnly="true" showErrors="true">
    <subNetwork label="Lan 1" mask="192.168.0.0/16" name="lan1"/>
    <subNetwork label="Lan 2" mask="172.16.0.0/12" name="lan2"/>
    <subNetwork label="Lan 3" mask="10.0.0.0/8" name="lan3"/>
    <subNetwork label="Localhost" mask="127.0.0.1/16" name="locahost"/>
    <subNetwork label="Lan (IPv6)" mask="fc00::/7" name="lan6"/>
    <subNetwork label="Localhost (IPv6)" mask="::1/128" name="localhost6"/>
  </securityZone>

</securityZone>
</securityZone>

Die Berechtigungen, die eine Zone definieren, lauten wie folgt:

  • allowDebug: aktiviert die Ausführung einer WebApp im Debug-Modus.
  • allowEmptyPassword: autorisiert eine Verbindung zu einer Instanz ohne Kennwort
  • allowHTTP: Eine Sitzung kann ohne HTTPS-Protokoll erstellt werden.
  • allowUserPassword: Das Sitzungstoken kann das folgende Formular enthalten: "<login>/<password>"
  • sessionTokenOnly: Das Sicherheitstoken ist in der Verbindungs-URL nicht erforderlich.
  • showErrors: Fehler auf der Serverseite werden weitergeleitet und angezeigt.
IMPORTANT
In einer Zonendefinition enthält jedes Attribut die Variable true -Wert verringert die Sicherheit.

Bei Verwendung von Message Center müssen Sie bei mehreren Ausführungsinstanzen eine zusätzliche Sicherheitszone mit der sessionTokenOnly Attribut definiert als true, wobei nur die erforderlichen IP-Adressen hinzugefügt werden sollen. Weitere Informationen zum Konfigurieren von Instanzen finden Sie unter dieses Dokuments.

Best Practices für Sicherheitszonen best-practices-for-security-zones

In der Definition der lan Sicherheitszone ist es möglich, eine IP-Adressenmaske hinzuzufügen, die den technischen Zugriff definiert. Durch diesen Zusatz wird der Zugriff auf alle Instanzen ermöglicht, die auf dem Server gehostet werden.

<securityZone allowDebug="true" allowEmptyPassword="false" allowHTTP="true"
                    allowUserPassword="false" label="Private Network (LAN)" name="lan"
                    sessionTokenOnly="true" showErrors="true">
        <subNetwork label="Lan 1" mask="192.168.0.0/16" name="lan1"/>
        <subNetwork label="Lan 2" mask="172.16.0.0/12" name="lan2"/>
        <subNetwork label="Lan 3" mask="10.0.0.0/8" name="lan3"/>
        <subNetwork label="Localhost" mask="127.0.0.1/16" name="locahost"/>
        <subNetwork label="Lan (IPv6)" mask="fc00::/7" name="lan6"/>
        <subNetwork label="Localhost (IPv6)" mask="::1/128" name="localhost6"/>

        <!-- Customer internal IPs -->
        <subNetwork id="internalNetwork" mask="a.b.c.d/xx"/>

      </securityZone>

Es wird empfohlen, IP-Adressbereiche direkt in der Konfigurationsdatei für die Instanz zu definieren, damit Benutzer, die nur auf eine bestimmte Instanz zugreifen, darauf zugreifen können.

Im config-<instance>.xml Datei:

  <securityZone name="public">
   ...
    <securityZone name="vpn">
      <subNetwork id="cus1" mask="a.b.c.d/xx"/>

Subnetze und Proxys in einer Sicherheitszone sub-networks-and-proxies-in-a-security-zone

Die Proxy -Parameter können in einer subNetwork -Element zur Angabe der Proxy-Verwendung in einer Sicherheitszone.

Wenn ein Proxy referenziert wird und eine Verbindung über diesen Proxy erfolgt (sichtbar über den HTTP-Header X-Forwarded-For ), ist der verifizierte Bereich der Clients des Proxys und nicht der des Proxys.

IMPORTANT
Wenn ein Proxy konfiguriert ist und es möglich ist, ihn zu überschreiben (oder wenn er nicht vorhanden ist), kann die zu testende IP-Adresse gefälscht werden.
Außerdem werden Relais jetzt wie Proxys generiert. Sie können daher die IP-Adresse 127.0.0.1 zur Liste der Proxys in Ihrer Sicherheitszonenkonfiguration hinzufügen.
Beispiel: " <subnetwork label="Lan 1" mask="192.168.0.0/16" name="lan1" proxy="127.0.0.1,10.100.2.135" />".

Verschiedene Fälle können auftreten:

  • Ein Unternetzwerk wird direkt in der Sicherheitszone referenziert und es wird kein Proxy konfiguriert: Benutzer des Unternetzes können direkt eine Verbindung zum Adobe Campaign-Server herstellen.

  • Ein Proxy wird für ein Unternetzwerk in der Sicherheitszone angegeben: Benutzer dieses Unternetzwerks können über diesen Proxy auf den Adobe Campaign-Server zugreifen.

  • Ein Proxy ist in einem Sicherheitszonen-Unternetzwerk enthalten: Benutzer, die über diesen Proxy Zugriff haben, können unabhängig von ihrer Herkunft auf den Adobe Campaign-Server zugreifen.

Die IP-Adressen der Proxys, die wahrscheinlich auf den Adobe Campaign-Server zugreifen, müssen in beiden <subnetwork> und dem Teilnetz der ersten Ebene <subnetwork name="all"/>. Hier für einen Proxy, dessen IP-Adresse beispielsweise 10.131.146.102 lautet:

<securityZone allowDebug="false" allowHTTP="false" label="Public Network"
                      name="public">
    <subNetwork label="All addresses" mask="*" name="all"
                      proxy="10.131.146.102,127.0.0.1, ::1"/>

    <securityZone allowDebug="true" allowHTTP="false" label="Private Network (VPN)"
                      name="vpn" showErrors="true">
        <securityZone allowDebug="true" allowEmptyPassword="false" allowHTTP="true"
                      allowUserPassword="false" label="Private Network (LAN)"
                      name="lan" sessionTokenOnly="true" showErrors="true">
            <subNetwork label="Lan proxy" mask="10.131.193.182" name="lan3"
                      proxy="10.131.146.102,127.0.0.1, ::1"/>
            <subNetwork label="Lan 1" mask="192.168.0.0/16" name="lan1"
                      proxy="127.0.0.1, ::1"/>

        </securityZone>
    </securityZone>
</securityZone>

Sicherheitszone mit einem Benutzer verknüpfen linking-a-security-zone-to-an-operator

Sobald Zonen definiert sind, muss jeder Benutzer mit einem dieser Benutzer verknüpft sein, um sich bei einer Instanz anmelden zu können, und die IP-Adresse des Benutzers muss in die Adressen oder Adressbereiche der Zone aufgenommen werden.

Die technische Konfiguration der Zonen erfolgt in der Konfigurationsdatei des Campaign-Servers: serverConf.xml.

Zuvor müssen Sie zunächst die vordefinierte Sicherheitszone Auflistung, um eine Bezeichnung mit dem internen Namen der in der serverConf.xml -Datei.

Diese Konfiguration erfolgt im Campaign-Explorer:

  1. Klicken Sie auf Administration > Plattform > Auflistungen Knoten.

  2. Wählen Sie die Sicherheitszone (securityZone) Systemauflistung.

  3. Klicken Sie für jede in der Konfigurationsdatei des Servers definierte Sicherheitszone auf die Hinzufügen Schaltfläche.

  4. Im Interner Name Geben Sie den Namen der im Feld serverConf.xml -Datei. Sie entspricht dem @name -Attribut <securityzone> -Element. Geben Sie den Titel ein, der mit dem internen Namen verknüpft ist. Titel-Feld.

  5. Klicken Sie auf OK und speichern Sie die Änderungen.

Sobald die Zonen definiert sind, wird die Sicherheitszone -Auflistung konfiguriert ist, müssen Sie jeden Benutzer mit einer Sicherheitszone verknüpfen:

  1. Klicken Sie auf Administration > Zugriffe > Benutzer Knoten.

  2. Wählen Sie den Benutzer aus, mit dem Sie eine Sicherheitszone verknüpfen möchten, und klicken Sie auf die Schaltfläche Bearbeiten Registerkarte.

  3. Navigieren Sie zu Zugriffsberechtigungen und klicken Sie auf Zugriffsparameter bearbeiten… -Link.

  4. Wählen Sie einen Bereich aus dem Zulässige Verbindungszone Dropdown-Liste

  5. Klicks OK und speichern Sie die Änderungen, um diese Änderungen anzuwenden.

Empfehlungen

  • Stellen Sie sicher, dass Ihr Reverse-Proxy in subNetwork nicht zulässig ist. Ist dies der Fall, all -Traffic wird als von dieser lokalen IP-Adresse kommend erkannt, sodass er als vertrauenswürdig eingestuft wird.

  • Minimieren Sie die Verwendung von sessionTokenOnly="true":

    • Warnung: Wenn dieses Attribut auf "true"gesetzt ist, kann der Operator einem CRSF-Angriff.
    • Darüber hinaus wird das sessionToken -Cookie nicht mit einem httpOnly -Flag gesetzt, sodass es von Client-seitigem 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.
  • Wenn möglich, setzen Sie alle allowHTTP-, showErrors auf false (nicht für localhost) und überprü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 IPs auf "true", die von Marketing-Benutzern/Administratoren verwendet werden, die Umfragen, WebApps und Berichte erstellen müssen (in der Vorschau). Diese Markierung ermöglicht es diesen IPs, Relais-Regeln anzuzeigen und zu debuggen.

    • Wenn allowDebug auf false gesetzt ist, lautet die Ausgabe:

      code language-none
      <redir status='OK' date='...' sourceIP='...'/>
      
    • Wenn allowDebug auf "true"gesetzt ist, lautet die Ausgabe:

      code language-none
      <redir status='OK' date='...' build='...' OR version='...' sha1='...' instance='...' sourceIP='...' host='...' localHost='...'/>
      
  • Setzen Sie niemals allowEmptyPassword, allowUserPassword, allowSQLInjection auf true.

    • 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 dem Benutzer die SQL-Injektion mithilfe einer alten Syntax. Dieses Attribut sollte auf "false"gesetzt werden. 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 IPs, die zur Zulassungsliste hinzugefügt wurden: Standardmäßig wurden in Sicherheitszonen die 3 Bereiche für private Netzwerke hinzugefügt. Es ist unwahrscheinlich, dass Sie alle diese IP-Adressen verwenden werden. Behalten Sie also nur die, die Sie brauchen.

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

recommendation-more-help
601d79c3-e613-4db3-889a-ae959cd9e3e1