Definieren von Sicherheitszonen (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.
Operatoren werden über ihr Profil in der Konsole mit einer Sicherheitszone verknüpft, auf die über den Knoten Administration > Zugriffsverwaltung > Operatoren zugegriffen werden kann. Weitere Informationen.
Sicherheitszonen erstellen creating-security-zones
Eine Zone wird definiert durch:
- ein oder mehrere IP-Adressbereiche (IPv4 und IPv6)
- Ein technischer Name, der mit jedem IP-Adressbereich verknüpft ist
Sicherheitszonen sind verkabelt, was bedeutet, dass die Definition einer neuen Zone innerhalb einer anderen Zone die Anzahl der Benutzer reduziert, die sich dort anmelden können, während die jedem Benutzer zugewiesenen Rechte erhöht werden.
Zonen müssen während der Server-Konfiguration in der Datei serverConf.xml definiert werden. Alle in der Datei serverConf.xml verfügbaren Parameter sind in diesem Abschnitt aufgeführt.
Jede Zone definiert Rechte, z. B.:
- HTTP-Verbindung statt HTTPS
- Fehleranzeige (Java-Fehler, JavaScript, C++ usw.)
- Vorschau von Berichten und WebApps
- Authentifizierung über Login / Passwort
- Nicht sicherer Verbindungsmodus
Die IP-Adresse des Betreibers kann in mehreren Zonen definiert werden. In diesem Fall erhält der Benutzer für jede Zone Satz der verfügbaren Rechte.
Die vorkonfigurierte Datei serverConf.xml umfasst drei Zonen: public, VPN und LAN.
Beispiel für die Definition einer Zone in der Datei serverConf.xml:
<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>
Alle Rechte, die eine Zone definieren, lauten wie folgt:
- allowDebug: Ermöglicht die Ausführung einer WebApp im „Debug“-Modus
- allowEmptyPassword: Autorisiert eine Verbindung zu einer Instanz ohne Kennwort
- allowHTTP: Eine Sitzung kann ohne Verwendung des HTTPS-Protokolls erstellt werden
- allowUserPassword: Das Sitzungs-Token kann die folgende Form haben: "
<login>/<password>" - sessionTokenOnly: Das Security-Token ist in der Verbindungs-URL nicht erforderlich
- showErrors: Server-seitige Fehler werden weitergeleitet und angezeigt
Wenn Sie Message Center verwenden und mehrere Ausführungsinstanzen vorhanden sind, müssen Sie eine zusätzliche Sicherheitszone mit dem Attribut sessionTokenOnly erstellen, das als true definiert ist, wobei nur die erforderlichen IP-Adressen hinzugefügt werden sollen. Weiterführende Informationen zum Konfigurieren von Instanzen finden Sie diesem Dokument.
Best Practices für Sicherheitszonen best-practices-for-security-zones
Bei der Definition der LAN-Sicherheitszone ist es möglich, eine IP-Adressmaske hinzuzufügen, die den technischen Zugriff definiert. Durch diese Hinzufügung wird der Zugriff auf alle auf dem Server gehosteten Instanzen ermöglicht.
<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 der Instanz für Benutzer zu definieren, die nur auf eine bestimmte Instanz zugreifen.
In der config-<instance>.xml:
<securityZone name="public">
...
<securityZone name="vpn">
<subNetwork id="cus1" mask="a.b.c.d/xx"/>
Subnetzwerke und Proxys in einer Sicherheitszone sub-networks-and-proxies-in-a-security-zone
Der proxy-Parameter kann in einem subNetwork-Element verwendet werden, um die Verwendung von Proxys in einer Sicherheitszone anzugeben.
Wenn ein Proxy referenziert wird und eine Verbindung über diesen Proxy eintritt (sichtbar über den HTTP-Header „X-Forwarded-For„), ist die verifizierte Zone die der Clients des Proxys und nicht die des Proxys.
<subnetwork label="Lan 1" mask="192.168.0.0/16" name="lan1" proxy="127.0.0.1,10.100.2.135" />”.Es können verschiedene Fälle auftreten:
-
Ein Subnetzwerk wird direkt in der Sicherheitszone referenziert und es ist kein Proxy konfiguriert: Benutzer des Subnetzwerks können direkt eine Verbindung mit dem Adobe Campaign-Server herstellen.
-
In der Sicherheitszone ist ein Proxy für ein Subnetzwerk angegeben: Benutzer dieses Subnetzwerks können über diesen Proxy auf den Adobe Campaign-Server zugreifen.
-
Ein Proxy ist in einem Sicherheitszonen-Unternetzwerk enthalten: Benutzer, die unabhängig von ihrer Herkunft über diesen Proxy Zugriff haben, können auf den Adobe Campaign-Server zugreifen.
Die IP-Adressen von Proxys, die wahrscheinlich auf den Adobe Campaign-Server zugreifen werden, müssen sowohl in der betreffenden <subnetwork> als auch in der Subnetzwerk-<subnetwork name="all"/> der ersten Ebene eingegeben werden. Hier finden Sie beispielsweise einen Proxy mit der IP-Adresse 10.131.146.102:
<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>
Verknüpfen einer Sicherheitszone mit einem Benutzer linking-a-security-zone-to-an-operator
Sobald Zonen definiert sind, muss jeder Benutzer mit einem von ihnen verknüpft sein, um sich bei einer Instanz anmelden zu können, und die IP-Adresse des Benutzers muss in die Adressen oder den Adressenbereich aufgenommen werden, auf die in der Zone verwiesen wird.
Die technische Konfiguration der Zonen erfolgt in der Konfigurationsdatei des Campaign-Servers: ".xml.
Zuvor müssen Sie die vordefinierte Auflistung Sicherheitszone konfigurieren, um eine Bezeichnung mit dem internen Namen der in der Datei serverConf.xml definierten Zone zu verknüpfen.
Diese Konfiguration erfolgt im Campaign-Explorer:
-
Klicken Sie auf Knoten Administration > Plattform Auflistungen .
-
Wählen Sie die Auflistung Sicherheitszone (securityZone aus.
-
Klicken Sie für jede Sicherheitszone, die in der Konfigurationsdatei des Servers definiert ist, auf die Schaltfläche Hinzufügen.
-
Geben Sie im Feld Interner Name den Namen der Zone ein, die in der Datei serverConf.xml definiert ist. Er entspricht dem Attribut {0@name des
<securityzone>. Geben Sie den Titel, der mit dem internen Namen verknüpft ist, im Feld label ein.
-
Klicken Sie auf OK und speichern Sie die Änderungen.
Sobald die Zonen definiert und die Auflistung Sicherheitszone konfiguriert ist, müssen Sie jeden Benutzer mit einer Sicherheitszone verknüpfen:
-
Klicken Sie auf Knoten Administration > Zugriffsverwaltung > Benutzer.
-
Wählen Sie den Benutzer aus, mit dem Sie eine Sicherheitszone verknüpfen möchten, und klicken Sie auf die Registerkarte Bearbeiten.
-
Wechseln Sie zur Registerkarte Zugriffsberechtigungen und klicken Sie auf den Link Zugriffsparameter bearbeiten… .
-
Wählen Sie eine Zone aus Dropdown-Liste Zulässige Verbindungszone“ aus
-
Klicken Sie OK und speichern Sie die Änderungen, um diese Änderungen anzuwenden.
Empfehlungen
-
Stellen Sie sicher, dass der Reverse-Proxy im Sub-Netzwerk nicht zulässig ist. Wenn dies der Fall ist wird Traffic als von dieser lokalen IP kommend erkannt und wird daher als vertrauenswürdig eingestuft.
-
Minimieren Sie die Verwendung von sessionTokenOnly=„true“:
- Warnung: Wenn dieses Attribut auf „true“ gesetzt ist, kann der Benutzer einem „CRSF Angriff ausgesetzt.
- 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.
-
Legen Sie nach Möglichkeit alle „allowHTTP“, „showErrors“ auf „false“ fest (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, die von Marketing-Benutzern/Administratoren verwendet werden und Umfragen, WebApps und Berichte erstellen (in der Vorschau anzeigen), auf „true“. Mit diesem Flag können diese IPs Relay-Regeln anzeigen und debuggen.
-
Wenn allowDebug auf false festgelegt ist, wird Folgendes ausgegeben:
code language-none <redir status='OK' date='...' sourceIP='...'/> -
Wenn allowDebug auf true festgelegt ist, wird Folgendes ausgegeben:
code language-none <redir status='OK' date='...' build='...' OR version='...' sha1='...' instance='...' sourceIP='...' host='...' localHost='...'/>
-
-
Legen Sie nie allowEmptyPassword, allowUserPassword, allowSQLInjection auf „true“ fest.
-
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 Benutzern das Durchführen von SQL-Injektionen 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 von IPs, die der Zulassungsliste hinzugefügt werden: Standardmäßig wurden in Sicherheitszonen die drei Bereiche für private Netzwerke hinzugefügt. Es ist unwahrscheinlich, dass Sie alle diese IP-Adressen verwenden werden. Behalte nur die, die du brauchst.
-
Aktualisieren Sie den WebApp-/internen Benutzer, damit er nur über localhost zugänglich sind.