Überwachung und Incident Response
Eine wirksame Überwachung ermöglicht es, Sicherheitsvorfälle schnell zu erkennen und einzudämmen. Dieser Abschnitt überprüft, ob die Protokollierungs- und Überwachungsfunktionen von Passwork korrekt konfiguriert sind und ob die Organisation über dokumentierte Reaktionsverfahren für wichtige Sicherheitsereignisse verfügt.
1. Aktivitätsprotokoll
Passwork zeichnet alle Benutzer- und Systemaktionen im Aktivitätsprotokoll auf. Dieses Protokoll ist der primäre Audit-Trail zur Untersuchung von Sicherheitsvorfällen und zum Nachweis der Compliance.
1.1 Überprüfen, dass das Audit-Log aktiviert ist
Navigieren Sie zu Einstellungen → Aktivitätsprotokoll.
Überprüfen Sie, dass der Aktionsverlauf Ereignisse aufzeichnet. Wenn das Protokoll für ein aktives System leer oder sehr spärlich ist, untersuchen Sie, ob ein Konfigurationsproblem die Ereignisse unterdrückt.
1.2 Aufbewahrungsdauer
Überprüfen Sie die Aufbewahrungsdauer des Audit-Logs. Navigieren Sie zu Einstellungen → Aktivitätsprotokoll → Einstellungen.
| Regulatorische Anforderung | Mindestaufbewahrung |
|---|---|
| Allgemein (keine spezifische Vorgabe) | mindestens 90 Tage |
| ISO 27001 | 1 Jahr empfohlen |
| GDPR Art. 5(2) Rechenschaftspflicht | Dauer der Verarbeitung + Untersuchungszeitraum |
| PCI-DSS | 1 Jahr (mit 3 Monaten unmittelbar verfügbar) |
Wenn die integrierte Aufbewahrung nicht ausreicht, konfigurieren Sie die Syslog-Weiterleitung an ein externes SIEM mit längerer Aufbewahrung (siehe Abschnitt 2).
1.3 Zu überwachende zentrale Ereigniskategorien
Passwork protokolliert Ereignisse über alle Objekttypen hinweg. Die folgenden Kategorien sind am sicherheitsrelevantesten:
| Ereigniskategorie | Sicherheitsrelevanz |
|---|---|
| Authentifizierungsfehler | Brute-Force-Versuche, Credential Stuffing |
| Admin-Aktionen (Rollenänderungen, Benutzererstellung/-löschung) | Rechteausweitung, unbefugte Kontoerstellung |
| Änderungen am Tresorzugriff (Benutzer hinzugefügt/entfernt) | Unbefugte Zugriffsgewährungen |
| Passwort-Exporte | Datenexfiltration |
| Erstellung von API-Tokens | Einrichtung unbefugten API-Zugriffs |
| Aktivierung des Notfallmodus | Kritisch — muss eine sofortige Untersuchung auslösen |
| Benutzer sperren/entsperren | Überprüfen, dass alle Entsperrungen autorisiert sind |
| Ergebnisse der LDAP-Synchronisierung | Synchronisierungsfehler identifizieren, die veralteten Zugriff hinterlassen können |
Vollständige Ereignisliste: Ereignisliste des Aktivitätsprotokolls
2. SIEM-Integration über Syslog
2.1 Überprüfen, dass die Syslog-Weiterleitung konfiguriert ist
Navigieren Sie zu Einstellungen → Aktivitätsprotokoll → Einstellungen und überprüfen Sie, dass Aktivitätsprotokolle in das Syslog oder Windows-Ereignisprotokoll schreiben aktiviert ist.
Ereignisse werden im CEF (Common Event Format) geschrieben, das mit den wichtigsten SIEM-Plattformen kompatibel ist (Splunk, QRadar, Microsoft Sentinel, Elastic SIEM, ArcSight).
Speicherorte der Protokolldateien nach Plattform:
| Plattform | Protokolldatei |
|---|---|
| Debian / Ubuntu / Astra Linux | /var/log/syslog |
| RHEL / CentOS / RED OS | /var/log/messages |
| Docker | /<passwork>/log/php/syslog |
| Windows Server | Windows Event Viewer |
Zur Konfiguration des Windows Event Viewer siehe Konfiguration des Event Viewer.
2.2 Überprüfen, dass das SIEM Ereignisse empfängt
Bestätigen Sie mit dem SIEM-Administrator, dass Passwork-Ereignisse aufgenommen werden:
- Erzeugen Sie ein Testereignis: Melden Sie sich bei Passwork an und führen Sie eine bekannte Aktion aus (z. B. ein Passwort anzeigen)
- Durchsuchen Sie das SIEM innerhalb von 5 Minuten mit dem Passwork-Quellbezeichner nach dem Ereignis
- Überprüfen Sie, dass die Ereignisfelder (suid, suser, passworkIp, Event ID, Severity) korrekt geparst werden
Wenn die Ereignisse nicht im SIEM erscheinen, prüfen Sie:
- Ob syslog-ng oder rsyslog auf dem Server installiert ist und läuft (
apt install syslog-ng -yunter Debian) - Ob der SIEM-Collector so konfiguriert ist, dass er von der IP des Passwork-Servers empfängt
- Die Netzwerkverbindung vom Passwork-Server zum SIEM-Collector-Endpunkt
2.3 SIEM-Alarmregeln
Überprüfen Sie, dass in Ihrem SIEM Alarme für die folgenden Ereignisse mit hoher Priorität konfiguriert sind:
| Alarm | Auslösebedingung | Empfohlenes Reaktions-SLA |
|---|---|---|
| Wiederholte Authentifizierungsfehler | ≥ 5 Fehlversuche von einer Quelle in 5 Minuten | Untersuchung innerhalb von 1 Stunde |
| Anmeldung eines Admin-Kontos außerhalb der Geschäftszeiten | Jede Admin-Anmeldung von 22:00–06:00 Ortszeit | Untersuchung innerhalb von 1 Stunde |
| Aktivierung des Notfallmodus | Jedes Ereignis mit einer Änderung von IS_EMERGENCY_RESET_ENABLED oder einem Zurücksetzen des Besitzer-Passworts | Sofort |
| Massenhafte Gewährung von Tresorzugriff | Mehr als 10 Benutzer in < 1 Minute zu einem Tresor hinzugefügt | Untersuchung innerhalb von 4 Stunden |
| Rollenausweitung | Benutzerrolle in Besitzer oder Admin geändert | Untersuchung innerhalb von 2 Stunden |
| Erstellung von API-Tokens | Neues API-Token generiert | Überprüfung innerhalb von 24 Stunden |
3. Security Dashboard
Das Security Dashboard analysiert alle Passwörter in den von Ihnen administrierten Tresoren und identifiziert Sicherheitsrisiken.
3.1 Analyse ausführen
Navigieren Sie zu Einstellungen → Security Dashboard und klicken Sie auf Analysieren.
3.2 Ergebnisse nach Kategorie überprüfen
| Ergebnistyp | Definition | Erforderliche Maßnahme |
|---|---|---|
| Schwach | Passwort-Score unter dem Schwellenwert | Verantwortliches Team benachrichtigen; Aktualisierung innerhalb von 30 Tagen verlangen |
| Alt | Seit > 180 Tagen nicht aktualisiert | Überprüfen und rotieren; Servicekonten priorisieren |
| Kompromittiert | Der Zugriff des Benutzers wurde entzogen, das Passwort aber nicht geändert | Sofortige Rotation erforderlich |
„Kompromittierte" Passwörter sind eine kritische Feststellung. Sie stellen Anmeldedaten dar, die für Benutzer zugänglich waren, deren Zugriff entzogen wurde — sei es durch Offboarding, Entfernung aus einer Gruppe oder Änderung des Tresorzugriffs — bei denen die Anmeldedaten jedoch anschließend nicht geändert wurden. Jeder autorisierte Benutzer, der zuvor Zugriff hatte, könnte die Anmeldedaten noch auswendig kennen oder extern gespeichert haben.
3.3 Eine Baseline festlegen
Nach der ersten Analyse und Behebung:
- Dokumentieren Sie den Baseline-Zustand (null kompromittiert, null kritisch schwach)
- Planen Sie eine wiederkehrende Analyse (empfohlen: monatlich)
- Weisen Sie die Verantwortung für die Security-Dashboard-Ergebnisse jedes Tresortyps einem benannten Administrator zu
4. Incident-Response-Verfahren
4.1 Vermuteter Kompromittierung von Anmeldedaten
Auslöser: Ein Benutzer meldet verdächtigen Zugriff, im Audit-Log wird ungewöhnliche Aktivität beobachtet oder externe Threat Intelligence weist auf eine Exposition von Anmeldedaten hin.
| Schritt | Aktion | Verantwortlich |
|---|---|---|
| 1 | Das betroffene Benutzerkonto sofort sperren | IT-Admin |
| 2 | Alle aktiven Sitzungen des betroffenen Benutzers beenden | IT-Admin |
| 3 | Security Dashboard gefiltert nach dem betroffenen Benutzer ausführen | Security Lead |
| 4 | Alle Anmeldedaten rotieren, auf die der Benutzer Zugriff hatte (privilegierte Konten priorisieren) | Tresor-Admins |
| 5 | Audit-Log auf die Aktionen des Benutzers der letzten 30 Tage überprüfen | Security Lead |
| 6 | Alle vom Benutzer erstellten aktiven geteilten Links widerrufen | Tresor-Admins |
| 7 | Betroffene Abteilungen benachrichtigen | Project Lead |
| 8 | Ergebnisse im Incident-Record dokumentieren | Security Lead |
4.2 Unbefugter administrativer Zugriff
Auslöser: Eine Admin-Aktion erscheint im Audit-Log, die keiner autorisierten Person zugeordnet werden kann, oder ein Admin-Konto wird von einem unerwarteten Ort oder zu einer unerwarteten Zeit verwendet.
| Schritt | Aktion |
|---|---|
| 1 | Alle unter dem Konto durchgeführten Aktionen identifizieren (Audit-Log) |
| 2 | Das Passwort des Kontos ändern und alle aktiven Sitzungen widerrufen |
| 3 | Alle vorgenommenen Änderungen überprüfen: Rollenzuweisungen, Tresorzugriffsgewährungen, Systemeinstellungen |
| 4 | Alle unbefugten Änderungen rückgängig machen |
| 5 | Den ursprünglichen Zugriffsvektor ermitteln: Kompromittierung von Anmeldedaten, gestohlene Sitzung, Insider |
| 6 | Einen Sicherheitsvorfallbericht einreichen |
4.3 Massenhafter Datenzugriff oder -export
Auslöser: Das Audit-Log zeigt, dass ein Benutzer in kurzer Zeit auf eine ungewöhnlich große Anzahl von Passwörtern zugreift oder diese exportiert.
| Schritt | Aktion |
|---|---|
| 1 | Die Audit-Log-Einträge für den Vorfallszeitraum sichern |
| 2 | Alle aufgerufenen Tresore und Datensätze identifizieren |
| 3 | Den Benutzer und seinen Vorgesetzten zur Klärung kontaktieren |
| 4 | Bei Unbefugtheit: das Konto sperren, alle aufgerufenen Anmeldedaten rotieren |
| 5 | Die Tresor-Exportberechtigungen in der betroffenen Rolle überprüfen und verschärfen |
4.4 Server-Kompromittierung (On-Premise)
Auslöser: Hinweise auf unbefugten Serverzugriff: unerwartete Prozesse, veränderte Konfigurationsdateien, unbefugte SSH-Schlüssel, abnormale ausgehende Verbindungen.
| Schritt | Aktion |
|---|---|
| 1 | Den Server vom Netzwerk isolieren (nicht ausschalten — Speicher erhalten) |
| 2 | Davon ausgehen, dass alle serverseitigen Daten kompromittiert sind |
| 3 | Den Server-Verschlüsselungsschlüssel rotieren (erfordert eine vollständige Neuverschlüsselung der Daten — Passwork-Support kontaktieren) |
| 4 | Alle Benutzer auffordern, ihre Passwork-Passwörter zu ändern |
| 5 | Wenn CSE deaktiviert war: alle gespeicherten Passwörter als kompromittiert behandeln; alle Tresorbesitzer benachrichtigen |
| 6 | Wenn CSE aktiviert war: Passwörter sind clientseitig verschlüsselt; eine Server-Sicherheitsverletzung legt nur unverschlüsselte Metadaten offen (Datensatznamen, URLs usw.) |
| 7 | Nach Abschluss der Server-Forensik aus einem sauberen Backup wiederherstellen |
5. Zeitplan für regelmäßige Überprüfungen
| Aktivität | Häufigkeit | Verantwortlich |
|---|---|---|
| Security-Dashboard-Analyse | Monatlich | Security Lead |
| Überprüfung des Audit-Logs auf Anomalien | Wöchentlich | Security Lead |
| Überprüfung der SIEM-Alarmregeln | Vierteljährlich | SIEM-Admin |
| Vollständige Sicherheitsüberprüfung (diese Checkliste) | Vierteljährlich oder nach wesentlichen Änderungen | Security Lead |
| Audit der Tresor-Zugriffsrechte | Vierteljährlich | Tresor-Admins + Security Lead |
| Test der Backup-Wiederherstellung | Halbjährlich | Server-Admin |
| Externer Penetrationstest | Jährlich | Externer Anbieter |
Zusammenfassende Checkliste
| # | Kontrolle | Status |
|---|---|---|
| 1.1 | Aktivitätsprotokoll ist aktiviert und zeichnet Ereignisse auf | |
| 1.2 | Audit-Log-Aufbewahrung erfüllt die regulatorischen Anforderungen | |
| 2.1 | Syslog-/Ereignisprotokoll-Weiterleitung ist aktiviert | |
| 2.2 | SIEM empfängt und parst Passwork-CEF-Ereignisse | |
| 2.3 | SIEM-Alarmregeln für vorrangige Sicherheitsereignisse konfiguriert | |
| 3.1 | Security-Dashboard-Analyse wurde ausgeführt | |
| 3.2 | Null „kompromittierte" Passwörter im Security Dashboard | |
| 3.3 | Security-Dashboard-Baseline festgelegt und Überprüfung geplant | |
| 4 | Incident-Response-Verfahren dokumentiert und kommuniziert | |
| 5 | Zeitplan für regelmäßige Überprüfungen mit benannten Verantwortlichen festgelegt |