Wer hat was geändert: eine Audit-Spur für den Host
Auf einem geteilten Host ist die härteste Frage nach einem Vorfall nicht, was kaputtging; es ist, wer vorher was geändert hat. Atlas schreibt eine Audit-Spur für kritische Operationen: Akteur, Aktion, Zeit und Ergebnis, auf dem Host an zwei Orten gehalten.
Warum wer was tat meist unbeantwortbar ist
Standardwerkzeuge verstreuen die Beweise. Das PVE-Aufgabenprotokoll kennt manche Operationen, die Shell-History andere, und Konfigurationsänderungen kennen oft gar nichts. Einen Abend zu rekonstruieren heißt, Zeitstempel über alle drei zusammenzunähen.
Geteilter Root-Zugriff macht es schlimmer. Wenn mehrere Personen als root handeln können, haben Aktionen keine Autoren mehr; History-Dateien kann dieselbe Macht bearbeiten, die die Änderung machte.
Und die meisten Audits passieren zur schlechtesten Zeit: nach einem Vorfall, unter Druck, während die Person mit der Antwort womöglich die Person ist, die ihn verursachte.
Einen Vorfall von Hand rekonstruieren
Ohne Spur sieht die übliche Untersuchung so aus:
Das PVE-Aufgabenprotokoll rund ums Vorfallfenster lesen und notieren, was es sah.
Shell-Histories auf dem Host durchsuchen und hoffen, dass niemand ein geteiltes Konto benutzte.
journalctl für dasselbe Fenster durchgehen und Zeitstempel abgleichen.
Aktuelle Konfigurationen gegen das letzte Backup diffen, um stille Änderungen zu finden.
Im Team-Chat fragen, wer den Host an dem Tag angefasst hat.
Eine Vorfallnotiz auf Basis von vermutlich schreiben und weitermachen.
Was Atlas festhält
Kritische Operationen hinterlassen eine Spur, während sie passieren, kein Rätsel danach.
Kritische Aktionen, aufgezeichnet
Operationen, die das System ändern oder gefährden, destruktive Speicher- und Netzwerkarbeit, Prozessabbrüche, berechtigungssensible Aktionen, werden im Lauf in die Spur geschrieben.
Akteur, Aktion, Zeit, Ergebnis
Jeder Eintrag beantwortet die vier Vorfallfragen auf einmal: wer es auslöste, was genau lief, wann, und ob es gelang.
Zwei Kopien, manipulationsresistent
Einträge gehen ins System-Journal, das Nicht-Root-Benutzer nicht umschreiben können, und in eine separate Datei. Spuren zu löschen heißt, beide zu besiegen.
Proxmox-Rollen, respektiert
Atlas erfindet keine eigene Berechtigungswelt. Wer was darf, kommt aus Proxmox-Benutzern und -Rollen, sodass die Spur auf echte Identitäten abbildet.
Keine Geheimnisse im Protokoll
Passwörter und Token werden nie geschrieben. Die Spur hält fest, dass eine Aktion geschah, nicht die Zugangsdaten, die sie trugen.
Befunde kommen an
Der Watch-Wächter meldet kritische Befunde per Mail, während sie passieren; die Spur wird vor dem Vorfall gelesen, nicht erst danach.
Häufig gestellte Fragen
- Was genau wird protokolliert?
- Kritische und berechtigungssensible Operationen: destruktive Speicher- und Netzwerkänderungen, Prozesssignale, Aktionen auf Dienstebene und Ähnliches. Routinelesen ist kein Rauschen in der Spur.
- Kann ein Admin seine Spuren löschen?
- Die Spur wird zweifach gehalten: im System-Journal, das ohne Manipulation auf Root-Ebene nicht umgeschrieben werden kann, und in einer separaten Datei. Geschichte still zu bearbeiten hört auf, trivial zu sein.
- Werden Passwörter oder Request-Bodies gespeichert?
- Nein. Geheimnisse werden nie in die Spur geschrieben; Einträge tragen Akteur, Aktion, Zeit und Ergebnis.
- Wo lebt das Protokoll?
- Auf dem Host, im System-Journal plus einer separaten Datei. Nichts wird an einen externen Dienst geschickt.
- Nutzt es Proxmox-Konten?
- Ja. Atlas spiegelt Proxmox-Benutzer, -Gruppen und -Rollen, statt eigene zu erfinden; Audit-Einträge passen zu den ohnehin verwalteten Identitäten.
- Bremst das Protokollieren den Host?
- Nein. Aufgezeichnet werden nur kritische Operationen, nicht jeder Klick; die Spur umfasst wenige Zeilen pro riskanter Aktion.
Verwandte Einträge
- Ich habe den Zugriff entzogen und sie sind immer noch drin: Sitzung und Berechtigung sind nicht dasselbe Sie haben die Berechtigung entfernt, sogar das Konto deaktiviert, und die Person kann weiterhin etwas tun. Nichts ist kaputt: Zugriff entziehen und eine Sitzung beenden sind zwei getrennte Handlungen.
- Weg von root: die Entscheidung, zu der niemand zwingt und die sich am meisten auszahlt Als root zu arbeiten fliegt nicht eines Tages auf. Es beschädigt still zwei Dinge: worauf der Datensatz zeigt und wo ein falscher Klick aufhört. Die Lösung ist nicht, root abzuschalten, sondern ihm die tägliche Arbeit wegzunehmen.
- Der Prüfeintrag: die Antwort auf "wer war es", nicht auf "was ist passiert" Überwachung sagt dir, was passiert ist, ein Prüfeintrag sagt dir, wer es war. Sein Wert zeigt sich an Tagen, die du dir nie wünschst, und hast du ihn an dem Tag nicht, hat er nie existiert.