Bundesamt für Sicherheit in der Informationstechnik

M 4.397 Protokollierung sicherheitsrelevanter Ereignisse von Web-Anwendungen und Web-Services

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator, Entwickler

Sicherheitsrelevante Ereignisse (zum Beispiel Zugriffe auf Ressourcen, Authentisierungsversuche) müssen nachvollziehbar protokolliert werden, damit im Stör- oder Fehlerfall oder nach Angriffsversuchen die Protokolldaten zur Ursachenfindung herangezogen werden können.

Neben den Empfehlungen in den Maßnahmen M 5.9 Protokollierung am Server und M 2.110 Datenschutzaspekte bei der Protokollierung sollten zusätzlich die folgenden Punkte bei der Protokollierung sicherheitsrelevanter Ereignisse von Web-Anwendungen und Web-Services beachtet werden.

Zu protokollierende Ereignisse bei Web-Anwendungen und Web-Services

Zusätzlich zur Protokollierung auf den Server- und Hintergrundsystemen (zum Beispiel Betriebssystem, Web- und Applikationsserver, Datenbank) sollte auch die Anwendung sicherheitsrelevante Ereignisse protokollieren. Mindestens folgende Ereignisse sollten auf Anwendungsebene erfasst werden:

  • erfolgreiche und erfolglose Anmeldeversuche an der Webanwendung oder dem Web-Service,
  • fehlgeschlagene Autorisierungsversuche beim Zugriff auf Ressourcen (zum Beispiel Datenbankzugriffe) und Funktionen der Webanwendung oder des Web-Service,
  • fehlgeschlagene Validierung von Ein- und Ausgabedaten,
  • fehlgeschlagene XML -Schema-Validierungen,
  • XML -Parser-Fehler,
  • aufgetretene Fehler (zum Beispiel Exceptions),
  • Änderungen von Berechtigungen für Benutzer oder Benutzergruppen der Webanwendung oder des Web-Service (zum Beispiel Zugriffsrechte, Änderung an der Web-Service-Policy),
  • Änderungen an Benutzerkonten (zum Beispiel Passwortänderung),
  • Löschvorgänge der Webanwendung (zum Beispiel Beiträge),
  • erkannte Manipulationsversuche und unerwartete Änderungen (zum Beispiel Anmeldeversuche mit ungültigen oder abgelaufenen Session- ID s),
  • administrative Funktionsaufrufe und Änderungen an der Konfiguration (zum Beispiel Abruf von Benutzerdaten, Aktivierung und Deaktivierung der Protokollierung),
  • Starten und Stoppen von Diensten,
  • Produktionsübernahme (Deployment) neuer oder bestehender Web-Services.

Zu protokollierende Merkmale von Ereignissen

Um sicherheitsrelevante Vorgänge anhand von Protokolldaten nachvollziehen zu können, müssen grundlegende Merkmale der Ereignisse verfügbar sein. Daher sollten mindestens die folgenden Merkmale protokolliert werden:

  • Datum,
  • Uhrzeit mit Zeitzone,
  • assoziierter Benutzername,
  • betroffenes Objekt (zum Beispiel Benutzerkonto, Datei, Datenquelle),
  • Status der Aktion (zum Beispiel fehlgeschlagen, erfolgreich),
  • Ort des Auftretens (zum Beispiel Komponente),
  • Aktion (zum Beispiel Authentisierung, Autorisierung),
  • Schweregrad (zum Beispiel Information, Warnung, Fehler).

Darüber hinaus kann es auch hilfreich sein, folgende Merkmale zu protokollieren:

  • Source-IP-Adresse,
  • Referenzen auf die SessionID (nicht die SessionID selbst),
  • IT -System, an dem der Fehler aufgetreten ist,
  • Softwarestand (Version) der Webanwendung.

Vertrauliche und sicherheitsrelevante Daten (zum Beispiel SessionID, Zugangsdaten) sollten nicht protokolliert werden.

Geeignete Datenformate und Mechanismen

Die protokollierten Daten sollten in einem einheitlichen Format gespeichert werden, damit eine effiziente Auswertung möglich ist. Die Protokollierungskomponente der Webanwendung oder des Web-Service sollte aus diesem Grund ein Datenformat verwenden, das in bestehende Lösungen integriert werden kann. Wird beispielsweise eine zentrale Komponente für die Auswertung der Protokolldaten verwendet, so sollten Datenformate gewählt werden, die diese Komponente unterstützt.

Serverseitige Protokollierung durch eine zentrale Komponente

Die Protokollierung der Webanwendung oder des Web-Service ist ausschließlich serverseitig durchzuführen, da nur auf diese Weise die Protokolldaten zentral ausgewertet werden können. Die Protokolldaten sollten von einer einzigen, zentralen Protokollierungskomponente der Webanwendung oder des Web-Service und nicht von unterschiedlichen Protokollierungskomponenten erhoben werden.

Eine fehleranfällige Neuentwicklung der Protokollierungskomponente sollte vermieden werden. Stattdessen sollte auf die Funktionalität etablierter Frameworks zurückgegriffen werden, die in der Regel einen zentralisierten Protokollierungsansatz und die Protokollierung in verbreiteten Protokolldatenformaten unterstützen (siehe Abschnitt Geeignete Datenformate und Mechanismen).

Schutz vor unbefugtem Zugriff und der Manipulation von Protokolldaten

Da die Protokolldaten vertrauliche Informationen (zum Beispiel über das Benutzerverhalten und den Aufbau beziehungsweise die Konfiguration der Webanwendung oder des Web-Service) enthalten können, muss der Zugriff auf die Protokolldaten reglementiert und nur befugten Benutzern ermöglicht werden. Der Zugriff auf Protokolldaten sollte nicht über öffentliche Schnittstellen möglich sein. Protokolldaten sollten daher in dedizierten Logverzeichnissen (zum Beispiel außerhalb des Web-Root-Verzeichnisses des Web-Servers) gespeichert werden.

Werden die Protokolldaten in einer Datenbank abgelegt, so sollten die Protokolldaten von den eigentlichen Nutzdaten getrennt werden. Diese Trennung kann mittels einer separaten Datenbanktabelle erreicht werden. Darüber hinaus kann ein eigener Datenbankbenutzer für die Protokollierung den Schutz der Protokolldaten erhöhen. In diesem Fall darf der Datenbankbenutzer für die Nutzdaten keine Zugriffsrechte auf die Protokolldaten haben.

Alternativ können die Protokollierungsdaten mit hohem Schutzbedarf auch in einer separaten Datenbankinstanz gespeichert werden.

Sichere Protokollauswertung

Ein Angreifer kann bewusst Protokoll-Einträge provozieren (zum Beispiel wenn Eingabefelder protokolliert werden), die schadhaften Programmcode beinhalten. Daher sollte bei der Auswertung der Protokolldaten sichergestellt werden, dass Schadcode in Protokoll-Einträgen vom Auswertungsprogramm nicht interpretiert wird (zum Beispiel durch die Ansicht in einem Browser und der Interpretation von JavaScript-Code in den Protokolldaten).

Da bei der Protokollauswertung keine Änderungen an den Protokolldaten vorgenommen werden dürfen, sind die Protokolldaten ausschließlich in einem schreibgeschützten Modus zu analysieren.

Zeitsynchronisation

Die Protokolldaten verschiedener Komponenten einer Webanwendung oder eines Web-Service (zum Beispiel Applikationsserver, Webserver, Datenbankserver) müssen in der Regel korreliert werden, um komponentenübergreifende Vorgänge vollständig nachvollziehen zu können. Dazu sollte die Zeit auf den Systemen synchronisiert sein, um anhand der Uhrzeiten Vorgänge in den Protokollen konsistent nachverfolgen zu können. Hierzu sollte M 4.227 Einsatz eines lokalen NTP-Servers zur Zeitsynchronisation beachtet werden.

Prüffragen:

  • Werden sicherheitsrelevante Ereignisse mit den erforderlichen Merkmalen von der Webanwendung oder dem Web-Service protokolliert?

  • Werden keine vertraulichen Daten (zum Beispiel Zugangsdaten) protokolliert?

  • Wird die Protokollierung ausschließlich serverseitig von einer zentralen Komponente der Webanwendung oder des Web-Service durchgeführt?

  • Ist der Zugriff auf die Protokolldaten nur befugten Benutzern ermöglicht?

  • Wird der Zugriff auf die Protokolldaten über die öffentliche Schnittstelle unterbunden?

  • Verwendet die Webanwendung oder der Web-Service Datenformate und Mechanismen zur Protokollierung, die eine Integration in bestehende Lösungen ermöglicht?

  • Wird eine Zeitsynchronisation für die Komponenten der Webanwendung oder des Web-Service umgesetzt?

  • Wird das Ausführen von Schadcode bei der Protokollauswertung verhindert?

Stand: 14. EL Stand 2014