Sicherheitscheckliste

Dieser Abschnitt behandelt die verschiedenen Schritte, mit denen Sie sicherstellen können, dass Ihre AEM-Installation bei der Bereitstellung sicher ist. Die Checkliste ist so konzipiert, dass sie von oben nach unten abgearbeitet werden sollte.

Hauptsicherheitsmaßnahmen

Ausführen von AEM im produktionsbereiten Modus

Weitere Informationen dazu finden Sie in Ausführen von AEM im produktionsbereiten Modus.

Aktivieren von HTTPS für Transport Layer Security

Die Aktivierung der HTTPS-Transportschicht (Transport Layer) in den Autoren- und Veröffentlichungsinstanzen ist obligatorisch, um eine sichere Instanz zu erhalten.

Installieren von Sicherheits-Hotfixes

Stellen Sie sicher, dass die neuesten, von Adobe bereitgestellten Sicherheits-Hotfixes installiert sind.

Änderung von Standardkennwörtern für die Admin-Konten von AEM und der OSGi-Konsole

Adobe empfiehlt dringend, dass Sie das Passwort für die mit allen Berechtigungen ausgestatteten admin-Konten von AEM nach der Installation ändern (in allen Instanzen).

Diese Konten beinhalten:

• Das admin-Konto von AEM

  Sobald Sie das Passwort für das Admin-Konto von AEM geändert haben, müssen Sie für den Zugriff auf CRX das neue Passwort verwenden.

• Das admin-Passwort für die OSGi-Web-Konsole

  Diese Änderung wird auch für das Admin-Konto übernommen, das für den Zugriff auf die Web-Konsole verwendet wird. Daher müssen Sie dafür dasselbe Passwort verwenden.

Diese beiden Konten nutzen separate Kontoanmeldeinformationen und die Verwendung von unterschiedlichen sicheren Passwörtern für jedes Konto ist für eine sichere Bereitstellung von entscheidender Bedeutung.

Ändern des Admin-Kennworts von AEM

Das Kennwort für das Admin-Konto von AEM kann über die Konsole Granite-Vorgänge – Benutzer geändert werden.

Dort können Sie das admin-Konto bearbeiten und das Kennwort ändern.

Bedeutung der Änderung des Kennworts für die OSGi-Web-Konsole

Unabhängig vom admin-Konto von AEM kann eine Nichtänderung des Standardkennworts für die OSGi-Web-Konsole dazu führen, dass:

• der Server aufgrund des Standardkennworts beim Starten und Herunterfahren einem Sicherheitsrisiko ausgesetzt ist (bei großen Servern kann dies einige Minuten dauern).
• der Server einem Sicherheitsrisiko ausgesetzt ist, wenn das Repository nicht aktiv ist oder ein Bundle neu startet und OSGi ausgeführt wird.

Weitere Informationen zum Ändern des Kennworts für die Web-Konsole finden Sie im nachfolgenden Abschnitt Ändern des Admin-Kennworts für die OSGi-Web-Konsole.

Ändern des Admin-Kennworts für die OSGi-Web-Konsole

Sie müssen auch das Kennwort ändern, das für den Zugriff auf die Web-Konsole verwendet wird. Dies geschieht mit einem OSGi-Konfiguration , um die folgenden Eigenschaften der Apache Felix OSGi Management Console:

• Benutzername und Kennwort: die Anmeldedaten für den Zugriff auf die Apache Felix Web Management Console.
  Das Kennwort muss geändert werden after die Erstinstallation, um die Sicherheit Ihrer Instanz sicherzustellen.

Gehen Sie hierfür wie folgt vor:

1. Verwenden der Instrumente, Aktivitäten öffnen Sie das Menü Web-Konsole und navigieren Sie zum Konfiguration Abschnitt.
   Beispiel: unter <server>:<port>/system/console/configMgr.

2. Navigieren Sie zum Eintrag für und öffnen Sie ihn. Apache Felix OSGi Management Console.

3. Ändern Sie die Benutzername und password.

   

4. Wählen Sie Speichern aus.

Implementieren von benutzerdefinierten Fehler-Handlern

Adobe empfiehlt die Definition von benutzerdefinierten Fehler-Handler-Seiten, insbesondere für 404- und 500-HTTP-Antwortcodes, um die Offenlegung von Informationen zu verhindern.

Durchgehen der Dispatcher-Sicherheitscheckliste

Der AEM-Dispatcher ist ein wichtiger Teil Ihrer Infrastruktur. Adobe empfiehlt dringend, dass Sie die Dispatcher-Sicherheitscheckliste durchgehen.

Überprüfungsschritte

Konfigurieren von Replikations- und Transportbenutzer

Bei einer Standardinstallation von AEM wird admin als Benutzer für die Transport-Anmeldedaten in den Standard-Replikationsagenten angegeben. Der Admin-Benutzer wird auch verwendet, um die Replikation auf dem Autorensystem zu beziehen.

Aus Sicherheitsgründen sollte beides unter Berücksichtigung der folgenden beiden Aspekte geändert werden, um den bestimmten vorliegenden Anwendungsfall widerzuspiegeln:

• Der Transport-Benutzer sollte nicht der Admin-Benutzer sein. Richten Sie stattdessen einen Benutzer auf dem Veröffentlichungssystem ein, der nur über Zugriffsrechte für die relevanten Abschnitte des Veröffentlichungssystems verfügt, und verwenden Sie die Anmeldedaten dieses Benutzers für den Transport.

  Sie können mit dem gebündelten Benutzer „Replikations-Empfänger“ beginnen und die Zugriffsrechte dieses Benutzenden so konfigurieren, dass sie Ihren Anforderungen entsprechen.

• Der Replikationsbenutzende oder die Agenten-Benutzer-ID sollte auch nicht der Admin-User sein, sondern eine Benutzerin oder ein Benutzer, die bzw. der nur die Inhalte sehen kann, die repliziert werden sollen. Der Replikationsbenutzende wird auch zum Erfassen von Inhalten verwendet, die auf dem Autorensystem repliziert werden sollen, bevor sie an den Publisher gesendet werden.

Kontrollieren der Sicherheits-Konsistenzprüfungen auf dem Vorgangs-Dashboard

In AEM 6 wird das neue Vorgangs-Dashboard eingeführt, das Systembedienern bei der Behebung von Problemen und der Überwachung des Zustands einer Instanz helfen soll.

Das Dashboard umfasst eine Reihe von Sicherheits-Konsistenzprüfungen. Es empfiehlt sich, den Status aller Sicherheits-Konsistenzprüfungen zu kontrollieren, bevor Sie Ihre Produktionsinstanz in Betrieb nehmen. Weitere Informationen dazu finden Sie in der Dokumentation zum Vorgangs-Dashboard.

Prüfen, ob Beispielinhalte vorhanden sind

Alle Beispielinhalte und -benutzer (z. B. das Geometrixx-Projekt und die zugehörigen Komponenten) sollten deinstalliert und vollständig von einem Produktionssystem gelöscht werden, bevor es öffentlich zugänglich gemacht wird.

Prüfen, ob die CRX-Entwicklungsbundles vorhanden sind

Die OSGi-Entwicklungsbundles sollten sowohl auf dem Autoren- als auch auf dem Veröffentlichungs-Produktionssystem deinstalliert werden, bevor sie zugänglich gemacht werden.

• Unterstützung von Adobe CRXDE (com.adobe.granite.crxde-support)
• Adobe Granite CRX Explorer (com.adobe.granite.crx-explorer)
• Adobe Granite CRXDE Lite (com.adobe.granite.crxde-lite)

Prüfen, ob das Sling-Entwicklungsbundle vorhanden ist

AEM Developer Tools for Eclipse stellt das Tool „Apache Sling Tooling Support Install“ (org.apache.sling.tooling.support.install) bereit.

Dieses OSGi-Bundle sollte sowohl auf dem Autoren- als auch auf dem Veröffentlichungs-Produktionssystem deinstalliert werden, bevor diese zugänglich gemacht werden.

Schutz vor Cross-Site Request Forgery-Angriffen

Das CSRF Protection Framework

AEM 6.1 verfügt über einen Mechanismus namens CSRF Protection Framework, der vor Cross-Site Request Forgery-Angriffen (Website-übergreifende Anfragenfälschung) schützt. Weitere Informationen zur Verwendungsweise finden Sie in der entsprechenden Dokumentation.

Der Sling Referrer Filter

Zur Behebung bekannter Sicherheitsprobleme hinsichtlich Cross-Site Request Forgery-(CSRF-)Angriffen in CRX WebDAV und Apache Sling müssen Sie Konfigurationen für den Referrer Filter hinzufügen, um diesen verwenden zu können.

Der Referrer-Filter-Dienst ist ein OSGi-Dienst, mit dem Sie Folgendes konfigurieren können:

• Welche HTTP-Methoden gefiltert werden sollen

• Ob eine leere Referrer-Kopfzeile zulässig ist

• Eine Whitelist von Servern, die zusätzlich zum Serverhost zugelassen werden sollen.

  Standardmäßig sind alle Varianten von „localhost“ und die aktuellen Host-Namen, mit denen der Server verknüpft ist, in der Whitelist enthalten.

So konfigurieren Sie den Referrer-Filterdienst:

1. Öffnen Sie die Apache Felix-Konsole (Konfigurationen) unter:

   https://<server>:<port_number>/system/console/configMgr

2. Melden Sie sich als admin an.

3. Wählen Sie im Menü Konfigurationen folgende Option aus:

   Apache Sling Referrer Filter

4. Geben Sie im Feld Allow Hosts alle Hosts ein, die als Referrer zugelassen werden sollen. Jeder Eintrag muss folgendes Format aufweisen:

   <Protokoll>://<Server>:<Port>

   Beispiel:

   • https://allowed.server:80: Alle Anfragen von diesem Server mit dem angegebenen Port sind zugelassen.
   • Wenn Sie auch HTTPS-Anfragen zulassen wollen, müssen Sie eine zweite Zeile eingeben.
   • Falls Sie alle Ports dieses Servers zulassen wollen, können Sie als Port-Nummer eine 0 eingeben.

5. Aktivieren Sie das Feld Allow Empty, wenn Sie leere/fehlende Referrer-Kopfzeilen zulassen möchten.

   VORSICHT

   Es wird empfohlen, einen Referrer bereitzustellen, wenn Sie Befehlszeilen-Tools wie cURL verwenden, anstatt einen leeren Wert zuzulassen, da andernfalls das Risiko besteht, dass Ihr System CSRF-Angriffen ausgesetzt ist.

6. Bearbeiten Sie die Methoden, die dieser Filter für Prüfungen verwenden soll, über das Feld Filter Methods.

7. Klicken Sie auf Speichern, um Ihre Änderungen zu speichern.

OSGi-Einstellungen

Einige OSGi-Einstellungen sind standardmäßig festgelegt, um ein einfacheres Debugging der Anwendung zu ermöglichen. Diese müssen in der Veröffentlichungs- und der Autoren-Produktionsinstanz geändert werden, um zu verhindern, dass interne Informationen offengelegt werden.

Sie müssen für jeden der folgenden Dienste die angegebenen Einstellungen ändern:

• Adobe Granite HTML-Bibliotheksmanager:

  • Aktivieren Sie Minify (um Neuzeilenzeichen [CRLF] und Leerzeichen zu löschen).
  • Aktivieren Sie Gzip (um Dateien als GZIP zu komprimieren und mit einer Anforderung darauf zuzugreifen).
  • Deaktivieren Sie Debug.
  • Deaktivieren Sie Timing.

• Day CQ WCM Debug Filter:

  • Heben Sie die Auswahl von Aktivieren auf.

• Day CQ WCM-Filter:

  • Legen Sie die Option WCM-Modus nur auf der Veröffentlichungsinstanz auf „Deaktiviert“ fest.

• Apache Sling Java Script Handler:

  • Deaktivieren Sie die Funktion zum Erzeugen von Debug-Informationen.

• Apache Sling JSP Script Handler:

  • Deaktivieren Sie Generate Debug Info.
  • Deaktivieren Sie Mapped Content.

Weitere Informationen finden Sie in OSGi-Konfigurationseinstellungen.

Bei der Verwendung von AEM gibt es mehrere Methoden zur Verwaltung der Konfigurationseinstellungen für solche Services. Weitere Informationen und empfohlene Praktiken finden Sie unter Konfigurieren von OSGi.

Weitere Informationen

Verringern von Denial-of-Service-(DoS-)Angriffen

Ein Denial-of-Service-Angriff (DoS) zielt darauf ab, eine Computer-Ressource für die vorgesehenen Benutzenden unzugänglich zu machen. Dies geschieht häufig, indem die Ressource überlastet wird, zum Beispiel:

• durch eine Flut von Anfragen von einer externen Quelle;

• durch eine Anforderung von mehr Informationen, als das System erfolgreich bereitstellen kann.

  Beispiel: Eine JSON-Darstellung des gesamten Repositorys.

• Wenn eine Seite mit einer unbegrenzten Anzahl an URLs angefordert wird, kann die URL einen Handler, einige Selektoren, eine Erweiterung und einen Suffix enthalten. Diese Elemente können alle geändert werden.

  So kann .../en.html angefordert werden als:

  • .../en.ExtensionDosAttack
  • .../en.SelectorDosAttack.html
  • .../en.html/SuffixDosAttack

  Alle gültigen Varianten (geben z. B. die Antwort 200 zurück und werden per Konfiguration zwischengespeichert) werden vom Dispatcher zwischengespeichert, was möglicherweise zu einem vollen Dateisystem führen kann, sodass kein Dienst für weitere Anfragen verfügbar ist.

Es gibt viele Konfigurationspunkte zum Verhindern solcher Angriffe. In diesem Dokument gehen wir jedoch nur auf die ein, die direkt für AEM relevant sind.

Konfigurieren von Sling zum Verhindern von DoS-Angriffen

Sling ist inhaltsorientiert. Dies bedeutet, dass sich die Verarbeitung auf den Inhalt konzentriert, da jede (HTTP-)Anfrage auf den Inhalt in Form einer JCR-Ressource (eines Repository-Knotens) abgebildet wird:

• Das erste Ziel ist die Ressource (JCR-Knoten), die die Inhalte enthält…
• Als Zweites wird der Renderer oder das Skript aus den Ressourceneigenschaften ausgelesen – zusammen mit bestimmten Teilen der Anfrage (z. B. Selektoren und/oder die Erweiterung).

Durch diesen Ansatz wird Sling zu einem leistungsstarken und sehr flexiblen Tool, aber wie immer ist es die Flexibilität, die sorgfältig verwaltet werden muss.

So verhindern Sie einen Missbrauch infolge von DoS-Angriffen:

1. Steuerungen auf Anwendungsebene implementieren. Aufgrund der Anzahl an möglichen Varianten ist eine Standardkonfiguration nicht praktikabel.

   In Ihrer Anwendung sollten Sie:

   • die Selektoren in der Anwendung steuern, sodass Sie nur die erforderlichen expliziten Selektoren verwenden und für alle anderen den Wert 404 zurückgeben.
   • die Ausgabe einer unbegrenzten Anzahl an Inhaltsknoten vermeiden.

2. die Konfiguration der Standard-Renderer überprüfen, die eine Problemquelle darstellen können.

   • Dies gilt insbesondere für den JSON-Renderer, der sich über mehrere Ebenen der hierarchischen Struktur erstrecken kann.

     Beispiel: Die Anfrage

     http://localhost:4502/.json

     könnte das gesamte Repository in einer JSON-Darstellung ablegen. Dies würde zu erheblichen Serverproblemen führen. Aus diesem Grund beschränkt Sling die Anzahl an maximalen Ergebnissen. Um die Tiefe des JSON-Renderings zu begrenzen, können Sie den Wert für

     Max. JSON-Ergebnisse (json.maximumresults)

     in der Konfiguration für das Apache Sling GET Servlet festlegen. Wenn dieser Grenzwert überschritten wird, wird das Rendering ausgeblendet. Der Standardwert für Sling innerhalb von AEM ist 1000.

   • Deaktivieren Sie als Präventivmaßnahme die anderen Standard-Renderer (HTML, Nur Text, XML). Konfigurieren Sie dazu ebenfalls das Apache Sling GET Servlet.

   VORSICHT

   Deaktivieren Sie nicht den JSON-Renderer. Dieser ist für den normalen Betrieb von AEM erforderlich.

3. Verwenden Sie eine Firewall, um den Zugriff auf Ihre Instanz zu filtern.

   • Eine Firewall auf Betriebssystemebene ist erforderlich, um den Zugriff auf Punkte Ihrer Instanz zu filtern, die ungeschützt möglicherweise zu DoS-Angriffen führen können.

Abmildern von DoS mithilfe der Formularauswahl

Da AEM keine Standardindizes für FormChooserServlet bereitstellt, löst die Verwendung der Formularauswahl in Abfragen einen aufwendigen Repository-Durchlauf aus, der meist die AEM-Instanz stoppt. Formularauswahl-Instanzen können anhand der Zeichenfolge *.form.* in Abfragen erkannt werden.

Führen Sie zum Beheben dieses Problems die folgenden Schritte aus:

1. Gehen Sie zur Web-Konsole, indem Sie im Browser https://<Server-Adresse>:<Serverport>/system/console/configMgr aufrufen.

2. Suchen Sie nach Day CQ WCM Form Chooser Servlet.

3. Klicken Sie auf den Eintrag, deaktivieren Sie im folgenden Fenster die Option Advanced Search Require (Erweiterte Suche erforderlich).

4. Klicken Sie auf Speichern.

Abmildern von DoS durch Asset Download Servlet

Mit dem Standard-Servlet für den Asset-Download können authentifizierte Benutzerinnen und Benutzer beliebig große gleichzeitige Download-Anfragen stellen, um ZIP-Dateien von Assets zu erstellen. Das Erstellen großer ZIP-Archive kann den Server und das Netzwerk überlasten. Um ein mögliches DoS-Risiko (Denial of Service) zu reduzieren, das durch dieses Verhalten verursacht wird, AssetDownloadServletist die OSGi-Komponente auf der Experience Manager-Veröffentlichungsinstanz standardmäßig deaktiviert. Auf der Experience Manager-Autoreninstanz ist sie standardmäßig aktiviert.

Wenn Sie die Download-Funktion nicht benötigen, deaktivieren Sie das Servlet auf Autoren- und Veröffentlichungsbereitstellungen. Wenn Sie die Asset-Download-Funktion im Rahmen Ihrer Einrichtung aktivieren müssen, finden Sie weitere Informationen in diesem Artikel. Sie können auch eine maximale Download-Grenze definieren, die Ihre Bereitstellung unterstützen kann.

Deaktivieren von WebDAV

WebDAV sollte sowohl in Autoren- als auch in Veröffentlichungsumgebungen deaktiviert werden. Stoppen Sie dazu die entsprechenden OSGi-Bundles.

1. Stellen Sie eine Verbindung zur Felix Management Console her, die ausgeführt wird unter:

   https://<*host*>:<*port*>/system/console

   Beispiel http://localhost:4503/system/console/bundles.

2. Suchen Sie in der Liste der Bundles nach einem Bundle mit dem folgenden Namen:

   Apache Sling Simple WebDAV Access to repositories (org.apache.sling.jcr.webdav)

3. Klicken Sie in der Spalte „Aktionen“ auf die Schaltfläche „Stopp“, um dieses Bundle zu stoppen.

4. Suchen Sie erneut in der Liste der Bundles nach einem Bundle mit dem folgenden Namen:

   Apache Sling DavEx Access to repositories (org.apache.sling.jcr.davex)

5. Klicken Sie auf die Schaltfläche „Stopp“, um dieses Bundle zu stoppen.

   HINWEIS

   Ein Neustart von AEM ist nicht erforderlich.

Sicherstellen, dass keine personenbezogenen Informationen im Home-Pfad von Benutzern offengelegt werden

Der Schutz Ihrer Benutzer ist wichtig. Stellen Sie daher sicher, dass Sie keine personenbezogenen Informationen im Home-Pfad von Repository-Benutzern offenlegen.

Ab AEM 6.1 ändert sich mit der neuen Implementierung der Schnittstelle AuthorizableNodeName die Art, wie Benutzer-ID-Knotennamen (auch als autorisierbare ID-Knotennamen bezeichnet) gespeichert werden. Die neue Schnittstelle legt nicht mehr die Benutzer-ID im Knotennamen offen, sondern generiert stattdessen einen zufälligen Namen.

Es ist keine Konfiguration erforderlich, um sie zu aktivieren, da dies nun die Standardvorgehensweise zum Generieren von autorisierbaren IDs in AEM ist.

Obwohl dies nicht empfohlen wird, können Sie sie deaktivieren, wenn Sie die alte Implementierung aus Gründen der Abwärtskompatibilität mit vorhandenen Applikationen benötigen. Gehen Sie dazu wie folgt vor:

1. Navigieren Sie zur Web-Konsole und entfernen Sie den Eintrag org.apache.jackrabbit.oak.security.user.RandomAuthorizableNodeName aus der Eigenschaft requiredServicePids in Apache Jackrabbit Oak SecurityProvider.

   Sie können den Oak Security Provider auch finden, indem Sie in den OSGi-Konfigurationen nach der PID org.apache.jackrabbit.oak.security.internal.SecurityProviderRegistration suchen.

2. Löschen Sie die OSGi-Konfiguration Apache Jackrabbit Oak Random Authorizable Node Name aus der Web-Konsole.

   Um die Suche zu vereinfachen, beachten Sie, dass die PID für diese Konfiguration org.apache.jackrabbit.oak.security.user.RandomAuthorizableNodeName lautet.

Verhindern von Clickjacking

Um Clickjacking zu verhindern, sollten Sie Ihren Webserver so konfigurieren, dass er die HTTP-Kopfzeile X-FRAME-OPTIONS bereitstellt, die auf SAMEORIGIN festgelegt ist.

Weitere Informationen zum Thema Clickjacking finden Sie auf der OWASP-Website.

Sicherstellen, dass Verschlüsselungsschlüssel bei Bedarf korrekt repliziert werden

Bestimmte AEM-Funktionen und Authentisierungsschemata erfordern, dass Sie Ihre Verschlüsselungsschlüssel in allen AEM-Instanzen replizieren.

Bevor Sie das tun, beachten Sie, dass die Schlüsselreplikation von Version zu Version unterschiedlich sein kann, da die Art der Speicherung von Schlüsseln zwischen der Version 6.3 und älteren Versionen unterschiedlich ist.

Weitere Informationen finden Sie im folgenden Abschnitt.

Replizieren von Schlüsseln in AEM 6.3

In älteren Versionen wurden die Replikationsschlüssel im Repository gespeichert, ab AEM-Version 6.3 werden sie jedoch im Dateisystem gespeichert.

Daher müssen Sie zum Replizieren Ihrer Schlüssel auf den Instanzen diese von der Quellinstanz an den Speicherort im Dateisystem der Zielinstanzen kopieren.

Genauer gesagt, müssen Sie Folgendes tun:

1. Greifen Sie auf die AEM-Instanz zu, auf der sich die zu kopierenden Schlüsseldaten befinden. In der Regel handelt es sich dabei um eine Autoreninstanz.

2. Suchen Sie im lokalen Dateisystem das Bundle com.adobe.granite.crypto.file. Es kann sich z. B. unter diesem Pfad befinden:

   • <author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21

   Die Datei bundle.info in jedem Ordner identifiziert den Bundle-Namen.

3. Navigieren Sie zum Ordner „data“. Beispiel:

   • <author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data

4. Kopieren Sie die HMAC- und die Master-Dateien.

5. Navigieren Sie dann zur Zielinstanz, auf der Sie den HMAC-Schlüssel duplizieren möchten, und dann zum Ordner „data“. Beispiel:

   • <publish-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data

6. Fügen Sie die beiden zuvor kopierten Dateien ein.

7. Aktualisieren Sie das Crypto-Bundle, wenn die Zielinstanz bereits ausgeführt wird.

8. Wiederholen Sie die vorherigen Schritte für alle Instanzen, auf denen Sie den Schlüssel replizieren möchten.

Replizieren von Schlüsseln in AEM 6.2 und älteren Versionen

In AEM 6.2 und älteren Versionen werden die Schlüssel im Repository im Knoten /etc/key gespeichert.

Für eine sichere Replikation der Schlüssel auf Ihren Instanzen wird empfohlen, nur diesen Knoten zu replizieren. Sie können Knoten in CRXDE Lite selektiv replizieren:

1. Öffnen Sie CRXDE Lite unter https://<Server-Adresse>:4502/crx/de/index.jsp.
2. Wählen Sie den /etc/key-Knoten aus.
3. Wechseln Sie zur Registerkarte Replikation.
4. Klicken Sie auf die Schaltfläche Replikation.

Durchführen eines Penetrationstests

Adobe empfiehlt dringend, Ihre AEM-Infrastruktur vor dem Einsatz in einer Produktionsumgebung einem Penetrationstest zu unterziehen.

Best Practices für die Entwicklung

Es ist wichtig, dass neue Entwicklungen den Security Best Practices entsprechen, um eine dauerhaft sichere AEM-Umgebung zu gewährleisten.

Ressourcen für Business.Adobe.com

Automated Onboarding Theme Editor Content As A Service Dynamic Forms Headless Cms Digital Asset Management