Security-Logging und Monitoring richtig aufsetzen

1. Warum Security-Logging über Erkennung entscheidet

Die meisten erfolgreichen Angriffe werden nicht in Minuten entdeckt, sondern erst nach Tagen oder Wochen, oft durch Dritte statt durch eigenes Monitoring. Zwischen Kompromittierung und Entdeckung liegt genau der Zeitraum, in dem Angreifer Daten abziehen, Hintertüren einbauen oder Zahlungsdaten abgreifen. Security-Logging schließt diese Lücke, indem es die Ereignisse festhält, die für eine spätere Rekonstruktion und für eine sofortige Alarmierung notwendig sind. Ein normales Application-Log für Debugging reicht dafür nicht aus, weil es andere Fragen beantwortet: Warum ist ein Request fehlgeschlagen, nicht wer hat versucht, sich unautorisiert Zugriff zu verschaffen.

Für Magento-Shops kommt hinzu, dass das Admin-Panel und der Checkout-Prozess bevorzugte Angriffsziele sind, insbesondere für Magecart-artige Skimmer, die Zahlungsdaten direkt im Checkout abgreifen. Ohne durchgängiges Security-Monitoring bleibt ein kompromittierter Admin-Account oder ein manipuliertes Zahlungsmodul oft monatelang unentdeckt. Regulatorische Anforderungen wie PCI DSS Anforderung 10 oder die 72-Stunden-Meldepflicht der DSGVO bei Datenschutzverletzungen setzen zudem voraus, dass überhaupt belastbare Logs existieren, aus denen sich Umfang und Zeitpunkt eines Vorfalls rekonstruieren lassen.

2. Welche Events wirklich sicherheitsrelevant sind

Nicht jedes Ereignis gehört ins Security-Log, sonst versinkt das relevante Signal im Rauschen. Kernkategorien sind: Authentifizierung (erfolgreiche und fehlgeschlagene Logins, Logouts, Passwort-Resets, Multi-Faktor-Ereignisse), Autorisierung (verweigerte Zugriffe auf geschützte Ressourcen, Versuche mit falscher Rolle auf Admin-Routen zuzugreifen), sowie administrative Aktionen (Konfigurationsänderungen, Anlegen oder Löschen von Benutzerkonten, Änderungen an Zahlungs- oder Versandmethoden). Jede dieser Kategorien liefert ein anderes Angriffssignal: gehäufte Login-Fehlschläge deuten auf Brute-Force hin, wiederholte Permission-Denials auf Privilegieneskalationsversuche.

Zusätzlich lohnt sich die Protokollierung von Input-Validierungsfehlern, die auf automatisierte Scans oder gezielte Injection-Versuche hindeuten, sowie von API-Rate-Limit-Überschreitungen und ungewöhnlichen Datei-Uploads. Entscheidend ist bei jedem Event derselbe Kontext-Satz: wer hat gehandelt, was wurde versucht, wann, von welcher Quelle und mit welchem Ergebnis. Fehlt einer dieser fünf Bausteine, wird das Log für die Vorfallsanalyse deutlich weniger wertvoll, weil sich Ereignisse dann nicht mehr eindeutig einer Ursache zuordnen lassen.

<?php
declare(strict_types=1);

namespace Mironsoft\SecuritySuite\Observer;

use Magento\Framework\Event\Observer;
use Magento\Framework\Event\ObserverInterface;
use Psr\Log\LoggerInterface;

/**
 * Logs failed customer login attempts with structured context.
 * Never logs the submitted password, only metadata needed for detection.
 */
class LogFailedLoginObserver implements ObserverInterface
{
    /**
     * @param LoggerInterface $securityLogger Dedicated security channel logger
     */
    public function __construct(private readonly LoggerInterface $securityLogger)
    {
    }

    /**
     * Handles the customer_customer_authenticate_after event on failure.
     *
     * @param Observer $observer Event observer carrying request context
     * @return void
     */
    public function execute(Observer $observer): void
    {
        $email = (string) $observer->getEvent()->getData('email');
        $exception = $observer->getEvent()->getData('exception');

        if ($exception === null) {
            return;
        }

        // Structured, machine-parseable context, no credentials included
        $this->securityLogger->warning('auth.login.failed', [
            'event_type' => 'authentication_failure',
            'actor_email_hash' => hash('sha256', strtolower($email)),
            'source_ip' => $_SERVER['REMOTE_ADDR'] ?? 'unknown',
            'user_agent' => $_SERVER['HTTP_USER_AGENT'] ?? 'unknown',
            'reason' => $exception->getMessage(),
            'timestamp' => (new \DateTimeImmutable())->format(DATE_ATOM),
        ]);
    }
}

3. Was niemals im Log landen darf

Ein Log, das Passwörter, vollständige Session-Tokens, API-Keys oder Kreditkartennummern im Klartext enthält, verwandelt sich selbst in ein Angriffsziel: Wer Zugriff auf die Logs bekommt, bekommt gleich die Zugangsdaten mit dazu. Dieses Muster ist als CWE-532 (Insertion of Sensitive Information into Log File) katalogisiert und gehört zu den häufigsten Fehlern in selbstgebauten Logging-Lösungen. Die Regel ist einfach: Alles, was zur Authentifizierung, Autorisierung oder Zahlung verwendet werden kann, gehört maskiert, gehasht oder komplett ausgelassen, niemals im Klartext gespeichert.

In der Praxis bewährt sich ein zentraler Redaction-Mechanismus, der nicht an jeder einzelnen Log-Stelle manuell umgesetzt werden muss, sondern automatisch greift, bevor ein Log-Eintrag den Handler erreicht. Ein Monolog-Processor ist dafür der richtige Ansatzpunkt: Er durchsucht rekursiv Context- und Extra-Daten nach bekannten sensiblen Schlüsselnamen und ersetzt die Werte durch eine feste Maske. So bleibt die Korrelation über eine gehashte oder gekürzte Kennung erhalten, ohne dass das Originalgeheimnis jemals persistiert wird.

<?php
declare(strict_types=1);

namespace Mironsoft\SecuritySuite\Logger\Processor;

/**
 * Removes sensitive values from log records before they reach any handler.
 * Runs as a Monolog processor, so redaction happens once, centrally, for
 * every channel instead of relying on every call site to sanitize manually.
 */
class SensitiveDataProcessor
{
    /** @var string[] Field names that must never appear in plain text */
    private const REDACTED_KEYS = [
        'password', 'passwd', 'pwd', 'token', 'access_token', 'refresh_token',
        'authorization', 'secret', 'api_key', 'credit_card', 'cvv',
    ];

    private const MASK = '***REDACTED***';

    /**
     * Processes a single log record and redacts sensitive keys recursively.
     *
     * @param array $record Monolog log record (message, context, extra, ...)
     * @return array Sanitized log record safe to persist or ship
     */
    public function __invoke(array $record): array
    {
        $record['context'] = $this->redact($record['context'] ?? []);
        $record['extra'] = $this->redact($record['extra'] ?? []);

        return $record;
    }

    /**
     * Walks an array recursively and masks values whose key looks sensitive.
     *
     * @param array $data Arbitrary context data attached to a log entry
     * @return array Data with sensitive values replaced by a fixed mask
     */
    private function redact(array $data): array
    {
        foreach ($data as $key => $value) {
            if (is_array($value)) {
                $data[$key] = $this->redact($value);
                continue;
            }

            $normalizedKey = strtolower((string) $key);
            foreach (self::REDACTED_KEYS as $sensitiveKey) {
                if (str_contains($normalizedKey, $sensitiveKey)) {
                    $data[$key] = self::MASK;
                    continue 2;
                }
            }
        }

        return $data;
    }
}

4. Strukturiertes Logging: Format und Kontext

Freitext-Logzeilen wie "Login failed for user X" lassen sich von Menschen lesen, aber schlecht maschinell auswerten, sobald Millionen Zeilen pro Tag zusammenkommen. Strukturiertes Logging im JSON-Format löst dieses Problem, weil jedes Feld gezielt abgefragt, gefiltert und korreliert werden kann, ohne fragile Regex-Parser zu bauen. Ein durchgängiges Schema mit festen Feldern wie timestamp, event_type, severity, actor, source_ip und outcome macht Log-Einträge über verschiedene Systeme hinweg vergleichbar, egal ob sie aus dem PHP-Backend, dem Webserver oder einer Payment-Integration stammen.

Genauso wichtig wie die einzelnen Felder ist eine durchgängige Correlation-ID oder Trace-ID, die bei Eingang eines Requests erzeugt und durch alle nachgelagerten Log-Einträge, Services und asynchronen Jobs durchgereicht wird. Erst damit lässt sich eine komplette Anfrage, vom fehlgeschlagenen Login über den anschließenden Zugriffsversuch auf eine geschützte Ressource bis zur eventuellen Sperrung des Kontos, als zusammenhängende Kette rekonstruieren. Ohne Correlation-ID bleiben verteilte Systeme bei der forensischen Analyse ein Puzzle aus isolierten Einzelereignissen.

{
  "timestamp": "2026-07-12T14:32:07Z",
  "event_type": "authentication_failure",
  "severity": "warning",
  "actor": {
    "type": "customer",
    "id_hash": "9f3a1c2b7e4d5f6a8b9c0d1e2f3a4b5c",
    "email_hash": "c1a5e2f8b3d4a9e7f6b2c1d0e9f8a7b6"
  },
  "source": {
    "ip": "203.0.113.42",
    "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
  },
  "context": {
    "reason": "invalid_credentials",
    "attempt_count": 3,
    "account_locked": false
  },
  "trace_id": "b7e1f6a2-4c3d-4e5f-9a1b-2c3d4e5f6a7b",
  "application": "magento",
  "environment": "production"
}

5. Magento Admin Activity Logging

Magento bringt seit 2.4 mit dem Modul Magento_AdminActionsLog ein eingebautes Protokoll für Admin-Aktivitäten mit, sichtbar unter System > Admin Actions Log. Es erfasst Logins, Logouts und grundlegende Konfigurationsänderungen samt Admin-Benutzer und Zeitstempel. Für viele Shops reicht das als Basis, aber es protokolliert generische Framework-Ereignisse, nicht zwangsläufig fachliche Aktionen wie das Ändern eines Produktpreises, das Anlegen eines neuen Admin-Kontos mit Rolle „Administrator" oder das Deaktivieren einer Zahlungsmethode. Für diese granulare Ebene braucht es eigene Plugins.

Ein Plugin um die Controller-execute()-Methode herum ist der zuverlässigste Ansatz, weil es unabhängig davon greift, ob ein Modul Magentos Standard-Konventionen für Admin-Grids verwendet oder eigene Controller mitbringt. Wichtig ist, die geloggten Request-Parameter vor dem Schreiben zu filtern, damit auch dort keine Passwortfelder oder Tokens landen. Kombiniert mit der ID des Admin-Benutzers, der ausgeführten Action und der Quell-IP entsteht ein Audit-Trail, der bei einem kompromittierten Admin-Account genau zeigt, welche Änderungen wann vorgenommen wurden.

<?php
declare(strict_types=1);

namespace Mironsoft\SecuritySuite\Plugin;

use Magento\Backend\App\Action;
use Magento\Backend\Model\Auth\Session;
use Psr\Log\LoggerInterface;

/**
 * Logs every executed backend controller action for audit purposes.
 * Wraps execute() instead of relying only on Magento's built-in admin log,
 * so custom controllers (e.g. Mironsoft modules) are covered too.
 */
class LogAdminActionPlugin
{
    /**
     * @param LoggerInterface $securityLogger Dedicated security channel logger
     * @param Session $authSession Backend auth session for the current admin user
     */
    public function __construct(
        private readonly LoggerInterface $securityLogger,
        private readonly Session $authSession
    ) {
    }

    /**
     * Logs the admin action before it is executed.
     *
     * @param Action $subject Backend controller being invoked
     * @param callable $proceed Original execute() call
     * @return mixed Result of the wrapped controller action
     */
    public function aroundExecute(Action $subject, callable $proceed)
    {
        $adminUser = $this->authSession->getUser();
        $request = $subject->getRequest();

        $this->securityLogger->info('admin.action.executed', [
            'event_type' => 'admin_action',
            'admin_user_id' => $adminUser?->getId(),
            'admin_username' => $adminUser?->getUsername(),
            'action' => $request->getFullActionName(),
            'params' => $this->filterParams($request->getParams()),
            'source_ip' => $request->getClientIp(),
        ]);

        return $proceed();
    }

    /**
     * Removes sensitive request parameters before they are logged.
     *
     * @param array $params Raw request parameters
     * @return array Parameters with sensitive keys removed
     */
    private function filterParams(array $params): array
    {
        unset($params['password'], $params['current_password'], $params['token']);

        return $params;
    }
}

6. Zentrale Log-Aggregation für Anomalieerkennung

Ein einzelner Server-Log ist für Anomalieerkennung fast wertlos, weil Angriffe selten auf eine Quelle beschränkt bleiben. Erst wenn PHP-Anwendungslogs, Webserver-Zugriffslogs, Datenbank-Audit-Logs und WAF-Ereignisse an einem Ort zusammenlaufen, werden Muster sichtbar, die sich über mehrere Systeme erstrecken, etwa ein Login-Fehlschlag gefolgt von einem erfolgreichen Login von einer anderen IP-Adresse Minuten später. Zentrale Log-Aggregation mit Werkzeugen wie Filebeat, Fluentd oder Logstash sammelt Logs von allen Quellen ein, normalisiert sie und schiebt sie in ein durchsuchbares Backend wie Elasticsearch, Loki oder eine SIEM-Lösung.

Für Magento-Setups bedeutet das konkret, dass neben den PHP-Logs unter var/log/ auch Nginx- oder Varnish-Zugriffslogs, MySQL-Slow-Query-Logs und gegebenenfalls Logs eines vorgeschalteten Web Application Firewalls eingebunden werden sollten. Ein Log-Shipper wie Filebeat liest die Dateien inkrementell, erkennt Rotation automatisch und versieht jeden Eintrag mit Metadaten wie Hostname und Umgebung, bevor er ihn weiterreicht. Wichtig ist eine verschlüsselte Verbindung zum zentralen Backend, damit die Übertragung selbst nicht zur Schwachstelle wird.

# filebeat.yml - forward Magento security-relevant logs to Logstash
filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /var/www/magento/var/log/security.log
      - /var/www/magento/var/log/exception.log
      - /var/www/magento/var/log/system.log
    fields:
      app: magento
      environment: production
    json.keys_under_root: true
    json.add_error_key: true
    multiline.pattern: '^\['
    multiline.negate: true
    multiline.match: after

output.logstash:
  hosts: ["logstash.internal:5044"]
  ssl.certificate_authorities: ["/etc/filebeat/ca.crt"]

processors:
  - drop_fields:
      fields: ["agent.ephemeral_id", "ecs.version"]
  - add_host_metadata: {}

7. Anomalien erkennen: Muster und Korrelation

Statische Regeln wie „mehr als fünf fehlgeschlagene Logins" erkennen offensichtliche Brute-Force-Versuche, greifen aber bei langsamen, verteilten Angriffen zu kurz, bei denen ein Angreifer über viele IP-Adressen jeweils nur ein oder zwei Versuche pro Konto startet. Ergänzend braucht es statistische Baselines: Wie viele Logins pro Stunde sind für diesen Shop normal, aus welchen Ländern kommt üblicherweise Traffic, zu welchen Uhrzeiten arbeiten die Admin-Benutzer typischerweise. Abweichungen von dieser Baseline, etwa ein Admin-Login aus einem bisher nie gesehenen Land, sind oft aussagekräftiger als jeder feste Schwellenwert.

Besonders wirksam ist die Korrelation mehrerer schwacher Signale zu einem starken: Eine „Impossible Travel"-Regel erkennt, wenn sich derselbe Benutzer innerhalb weniger Minuten von geografisch weit entfernten Standorten anmeldet, was physisch nicht möglich ist und auf einen gestohlenen Session-Token oder ein kompromittiertes Passwort hindeutet. SIEM-Systeme wie Elastic Security oder Wazuh bringen vorgefertigte Korrelationsregeln für solche Muster mit, die sich mit shopfremden Signalen wie Threat-Intelligence-Feeds für bekannte bösartige IP-Adressen kombinieren lassen.

8. Alerting-Schwellenwerte ohne Alert Fatigue

Zu sensible Alarme führen dazu, dass ein Security-Team nach kurzer Zeit jede Benachrichtigung reflexhaft wegklickt, ohne sie noch zu prüfen, echte Vorfälle eingeschlossen. Dieses Phänomen heißt Alert Fatigue und ist eine der häufigsten Ursachen dafür, dass Angriffe trotz vorhandenem Monitoring unentdeckt bleiben. Die Lösung liegt in gestaffelten Schweregraden statt einer einzigen Alarmstufe: Informative Events landen im Dashboard, mittlere Auffälligkeiten erzeugen ein Ticket, nur eindeutig kritische Muster wie eine erfolgreiche Anmeldung nach zehn Fehlversuchen von einer neuen IP lösen eine sofortige Benachrichtigung mit Eskalation aus.

Zeitfenster und Aggregation sind der zweite Hebel: Statt bei jedem einzelnen fehlgeschlagenen Login zu alarmieren, wird über ein rollierendes Fenster gezählt, etwa fünf Fehlversuche innerhalb von 15 Minuten pro Konto oder IP, und Duplikate innerhalb eines Zeitraums werden zu einem einzigen Alarm zusammengefasst. Schwellenwerte sollten außerdem regelmäßig anhand echter Vorfälle und Fehlalarme nachjustiert werden, statt einmal festgelegt und nie wieder angefasst zu werden. Ein Alarm ohne klar definierte, dokumentierte Reaktion ist ohnehin nur Rauschen und gehört entweder geschärft oder entfernt.

9. Aufbewahrung, Zugriffsschutz und Compliance

Wie lange Security-Logs aufbewahrt werden müssen, ist ein Kompromiss zwischen forensischer Nützlichkeit und Datenschutz: PCI DSS verlangt für zahlungsrelevante Systeme mindestens ein Jahr Aufbewahrung, davon drei Monate sofort verfügbar für Analysen, während die DSGVO im Sinne der Datenminimierung fordert, personenbezogene Daten nicht länger als nötig zu speichern. In der Praxis bedeutet das häufig eine gestaffelte Strategie: kurzfristig vollständige, durchsuchbare Logs für aktive Untersuchungen, langfristig aggregierte oder anonymisierte Daten für Trendanalysen.

Der Zugriff auf Security-Logs selbst muss nach dem Prinzip der geringsten Rechte geschützt werden, denn wer Logs manipulieren oder löschen kann, kann Spuren eines Angriffs verwischen. Immutable- oder WORM-Speicher (Write Once, Read Many) verhindert nachträgliche Änderungen, und getrennte Zugriffsrechte zwischen den Teams, die Logs erzeugen, und denen, die sie auswerten, reduzieren das Risiko eines Insider-Angriffs. Wer Logs zentral aggregiert, sollte deshalb auch den Aggregations-Layer selbst wie ein kritisches System behandeln, mit eigenem Audit-Log für Zugriffe auf die Logs.

Sicherheitsrelevante Ereignisse strukturiert zu protokollieren ist die eine Hälfte der Aufgabe, sensible Daten dabei zuverlässig fernzuhalten die andere. Die folgende Tabelle stellt naive Logging-Praxis der empfohlenen, sicheren Variante gegenüber.

10. Zusammenfassung

Security-Logging und Monitoring lösen ein einziges Kernproblem: die Zeit zwischen Kompromittierung und Entdeckung so kurz wie möglich zu halten. Authentifizierungsereignisse, Autorisierungsverstöße und administrative Aktionen bilden den Kern dessen, was protokolliert werden muss, jeweils mit vollständigem Kontext aus Akteur, Quelle, Zeitpunkt und Ergebnis. Passwörter, Tokens und Zahlungsdaten gehören dabei niemals im Klartext ins Log, ein zentraler Redaction-Mechanismus wie ein Monolog-Processor setzt diese Regel automatisch durch, statt sich auf manuelle Disziplin an jeder Log-Stelle zu verlassen.

Erst zentrale Log-Aggregation macht Muster über mehrere Systeme hinweg sichtbar, von Impossible-Travel-Logins bis zu verteilten Brute-Force-Versuchen. Damit dieses Signal nicht im Rauschen untergeht, braucht es gestaffelte Alarmstufen, Zeitfenster-Aggregation und regelmäßig nachjustierte Schwellenwerte, sonst führt Alert Fatigue dazu, dass echte Vorfälle in der Masse der Benachrichtigungen untergehen. Magentos eingebautes Admin Actions Log ist ein solider Ausgangspunkt, ersetzt aber kein eigenes, feingranulares Audit-Trail für kritische Geschäftsaktionen.

11. FAQ: Security-Logging und Monitoring