Was hat sich geändert

Jede Inhaltsänderung wird versioniert. Wählen Sie eine Version, um sie mit der vorherigen zu vergleichen.

Version 1 → 2

Aktualisierung

3 Lektionen aktualisiertDauer

Inhaltliche Aktualisierung. Eingeschriebene Lernende wurden benachrichtigt.

Dauer von 10 auf 12 Minuten geändert.

Wer verbunden war, wer genehmigte, wer das Geheimnis sah

Prüfer sagen selten "zeigen Sie mir die Logs". Sie stellen eine konkrete Frage zu einer Person, einem System und einem Zeitraum. Weil Monopam jede Sitzung und jede Anzeige vermittelt, gibt es für die meisten dieser Fragen genau einen richtigen Ort. | Der Prüfer fragt | Wo die Antwort liegt | Nicht hier | | --- | --- | --- | | Wer griff letztes Quartal auf diesen Server zu, wer genehmigte es und was wurde getan? | Im Sitzungsverlauf des Servers, zusammen mit seinen Genehmigungen und Aufzeichnungen gelesen: Jede vermittelte Sitzung ~~ist mit~~gehört einem benannten Benutzer, ~~ihrer Genehmigung und ihrer~~ihre Aufzeichnung ~~verknüpft~~liegt unter `Recordings`, und die Genehmigung dahinter ist die passende Anfrage unter `Requests` | `Live Sessions` zeigt nur, wer jetzt verbunden ist. `Requests` allein enthält die Genehmigungen, aber nicht, was getan wurde | | Wer hat dieses Passwort tatsächlich angesehen oder kopiert? | Im Audit-Ereignis `Vault Revealed / Copied` mit Feldname und Benutzer | Das Öffnen der Eintragsseite ist keine Anzeige | | Welche Sitzungen öffnete ein KI-Assistent, und was rief er auf? | Am Badge `AI` in `Recordings` und `Live Sessions` sowie an einer Audit-Zeile `MCP Tool Call` je Tool-Aufruf | Eine Sitzung ohne Badge wurde nicht über den Monopam-MCP-Server geöffnet | | Zeigen Sie mir alle Zugriffsanfragen des Mandanten | `Requests` mit dem Bereich `Everyone` | Der Standardbereich `Mine` listet nur eigene Anfragen und solche, die auf Ihre Entscheidung warten | ::diagram pam-evidence-map Drei Details machen diese Antworten belastbar. **Eine Anzeige wird je Feld erfasst.** Ein Vault-Eintrag kann mehrere geschützte Felder haben, und das Ereignis nennt das angezeigte oder kopierte Feld. Der Wert verschwindet nach 30 Sekunden vom Bildschirm, doch das ist Komfort, keine Kontrolle: Einen Screenshot verhindert es nicht. Der Nachweis ist das Ereignis. **Tool-Aufrufe werden erfasst, ob sie gelingen oder scheitern.** Jede Zeile `MCP Tool Call` trägt Tool, Ergebnis und Argumente, wobei geheim wirkende Argumentwerte maskiert sind. Ein Assistent arbeitet mit den Berechtigungen und Richtlinien des Benutzers oder der Identität dahinter. Das Badge sagt also, wie eine Sitzung geöffnet wurde, nicht, dass andere Regeln galten. **Der Bereich `Everyone` braucht eine Berechtigung.** Einem internen Prüfer, der nur eigene Anfragen sieht und keinen Schalter `Everyone` hat, fehlt `monopam.requests.full`. Als Genehmiger benannt zu sein, verleiht sie nicht. Der Server setzt dieselbe Regel durch wie die Oberfläche. ### Notizen an Aufzeichnungen sind kein Nachweis Prüfende können an einem Moment einer Aufzeichnung Notizen hinterlassen, standardmäßig `Shared`. Notizen sind Prüfmaterial. Sie gehören nicht zur manipulationssicheren Audit-Kette, ein Autor kann seine eigenen bearbeiten, und ein Super-Admin kann jede löschen, aber nicht umschreiben. Das zählt, wenn eine Notiz schiefgeht. Angenommen, jemand fügt ein Produktionspasswort in eine geteilte Notiz ein und geht in den Urlaub. Ein Super-Admin löscht die Notiz. Löschen rotiert nichts, und die Notiz wurde vielleicht schon gelesen, also gilt das Passwort als offengelegt und wird rotiert. Braucht die Vorfallsakte den Text, kopieren Sie ihn vor dem Löschen. > Tipp: Proben Sie vor dem Audit. Melden Sie sich mit dem Konto an, das der Prüfer nutzen wird, öffnen Sie `Requests` und prüfen Sie, ob der Umschalter `Everyone` vorhanden ist. Ein fehlendes `monopam.requests.full` lässt sich eine Woche vorher leicht beheben und ist in der Besprechung unangenehm zu entdecken.

Lieferanten- und Site-Berichte, Zugriffsprüfungen

Zwei Fragen kehren bei jedem Audit wieder: "Was hat dieser Lieferant in unseren Systemen getan?" und "Was geschah an diesem Standort?". Monopam hat für jede einen fertigen Bericht und einen Prüfprozess für Lieferantenkonten. ### Der Activity Report des Lieferanten Auf der Seite `Vendors` bietet das Zeilenmenü eines Lieferanten `Activity Report`. Wählen Sie einen Zeitraum und nutzen Sie `Export CSV` oder `Export PDF`. Die Datei listet die Verbindungen der Benutzer dieses Lieferanten mit Benutzer, E-Mail, Ressource, Typ, Status, Startzeit, letzter Aktivität und der Angabe, ob die Sitzung aufgezeichnet wurde. Genau diese Quartalsdatei verlangt ein Prüfer zu einem Lieferanten. Der Export selbst hinterlässt eine Spur: Jeder wird als Ereignis `Downloaded` mit Format, Zeitraum und Zeilenzahl in den Audit-Trail geschrieben. So lässt sich auch zeigen, wer eine Kopie des Berichts gezogen hat. ### Der Site-Bericht und seine eine Falle Jede Site hat einen gleichartigen Aktivitätsbericht mit denselben Exporten. Er beantwortet "was geschah an diesem Standort", wird aber aus den **der Site zugewiesenen Ressourcen** gebildet, nicht aus dem Gateway, das eine Sitzung trug. Ein Werk kann daher auf dem Papier still wirken und in Wirklichkeit geschäftig sein. Wurden die Gateways des Werks der Site zugewiesen, seine Server aber nie, tragen die Gateways Hunderte Sitzungen, und der Site-Bericht bleibt leer. Prüfen Sie die Zahl `Resources` in der Liste `Sites`, weisen Sie die Ressourcen zu (`Advanced` > `Site`), und der Bericht füllt sich. ::diagram pam-site-report ### Zugriffsprüfungen für Lieferanten `Start Access Review` an einem Lieferanten verlangt vom Prüfenden eine Entscheidung zu jedem externen Benutzer des Lieferanten. | Entscheidung | Wirkung | | --- | --- | | Approve | Der Zugriff bleibt. Nichts ändert sich | | Reject | Das Konto wird deaktiviert und seine Live-Sitzungen werden getrennt. Die Änderung zeigt sich innerhalb etwa einer Minute | Sagen Sie das den Prüfenden vorher. Wer einen Dienstleister mitten im Wartungsfenster ablehnt, beendet dessen Arbeit sofort. Ein irrtümlich abgelehnter Benutzer lässt sich auf der Seite `Users` wieder aktivieren. Der Start einer Prüfung und jede Deaktivierung stehen im Audit-Trail, und das ist der Beleg, dass die Prüfung stattfand. ### Eine Quartalsroutine 1. Exportieren Sie für jeden Lieferanten den `Activity Report` des Quartals und legen Sie ihn ab. 2. Vergleichen Sie in der Liste `Sites` den Zähler `Resources` jeder Site mit dem, was dort tatsächlich steht. Eine Null neben einem geschäftigen Werk bedeutet einen leeren Bericht. 3. Starten Sie für jeden Lieferanten `Start Access Review` und sagen Sie den Prüfern vorher, dass `Reject` laufende Sitzungen trennt.

Discovery-, Maschinen- und Datenbank-Datensätze

Ein Datensatz ist nur dann ein Nachweis, wenn Sie wissen, was er sagt und was nicht. Drei Arten werden leicht falsch gelesen. ::diagram pam-record-limits ### Discovery-Läufe Jeder Discovery-Lauf steht im Laufverlauf, und seine Funde verweisen auf ihn. Läufe, die älter als **90 Tage** sind, werden einmal täglich entfernt. Keine Einstellung ändert das. Die Funde bleiben, sie verlieren nur den Verweis auf ihren Lauf. Für Compliance heißt das: vorausplanen. Verlangt das Audit im nächsten Jahr einen Beleg für jeden Discovery-Lauf des Jahres, sichern Sie die Laufdatensätze, solange es sie gibt, etwa als Teil einer monatlichen Kontrolle. Auf die Anfrage des Prüfers zu warten, ist für alles Ältere als 90 Tage zu spät. Auch das Lesen der Funde verlangt Sorgfalt: | Fund | So ist er zu lesen | | --- | --- | | Ein Unix-Konto mit uid 0, das nicht in sudoers steht | Ein echter Administrator. uid 0 wird immer als Administrator markiert, gleich wie das Konto heißt | | `Exclude Built-in Accounts` ist an, dennoch erscheint ein uid-0-Konto | Korrekt. Die Option lässt Systemkonten mit niedriger uid aus, aber niemals root oder ein anderes uid-0-Konto | | Ein sudo- oder wheel-Benutzer erscheint als gewöhnliches Konto | Ein Agent, der Administratoren nicht auflisten kann, liefert Konten ohne diese Markierung, statt zu scheitern. Die Zeilen in `Logs` zeigen die Warnung | | Der Lauf ist abgeschlossen und ein Konto fehlt in der Liste | Kein Beweis, dass das Konto nicht existiert. Prüfen Sie zuerst die `Logs`-Zeilen dieses Hosts | Die letzte Zeile ist die schmerzhafte. Ein Kunde verlangt die schriftliche Bestätigung, dass ein lokales Admin-Konto fort ist, weil der letzte Lauf es nicht aufführte. Ein abgeschlossener Lauf kann dennoch Zeilen übersprungen haben, die er nicht lesen konnte, oder ohne Administratorliste gearbeitet haben. Lesen Sie die `Logs`-Zeilen des Hosts, bevor Sie etwas unterschreiben. ### Maschinelle Lesezugriffe auf Geheimnisse Pipelines und Operatoren lesen Geheimnisse über Maschinenidentitäten, oft jede Minute. Damit das Audit lesbar bleibt, gibt es unter `System` > `Secrets API` die Einstellung `Machine read audit window (minutes)`, standardmäßig 10. Innerhalb des Fensters erhöht eine Wiederholung desselben Lesezugriffs durch dieselbe Identität nur einen Zähler, und der nächste Eintrag nennt, wie viele Lesezugriffe er aufgenommen hat. Anmeldungen, Schreibzugriffe und Anzeigen durch Menschen werden immer einzeln protokolliert. Verlangt eine Aufsicht einen Datensatz je Lesezugriff, etwa für eine Zahlungs-Pipeline, setzen Sie das Fenster auf `0`. Dann erhält jeder Lesezugriff eine eigene Zeile, und die Audit-Tabelle wächst entsprechend. Lesezugriffe und Anmeldungen über die Vault-kompatible API tragen im Audit den Zusatz `(Vault-compatible API)`. So unterscheiden Sie einen Client im Stil von HashiCorp Vault von der Monopam-CLI, wenn beide dieselbe Identität nutzen. ### Datenbankanweisungen Der Datenbank-Proxy schreibt **je Anweisung** einen Audit-Datensatz mit der getroffenen Entscheidung: erlaubt, blockiert, maskiert oder zur Genehmigung gesendet. Eine Anweisung, die die Richtlinie passierte, aber an der Datenbank scheiterte, wird als Backend-Fehler erfasst. Das ist der Nachweis für "was haben Benutzer ausgeführt, und was wurde gestoppt". `Requests` enthält nur die Genehmigungsanfragen. Standardmäßig wird die Anweisung bereinigt gespeichert: Literale werden durch Platzhalter ersetzt, Sie sehen also `UPDATE customers SET email = $1 WHERE id = $2`. Die Option `AuditRawSql` speichert ab dem Einschalten den Rohtext samt Literalen. Literale können personenbezogene Daten oder Geheimnisse enthalten, entscheiden Sie also gemeinsam mit dem Datenschutzbeauftragten. > Tipp: Stellen Sie zwei Fragen, bevor Sie einen dieser Datensätze übergeben. Wie lange wird er aufbewahrt? Was wurde zusammengefasst oder weggelassen? Die Laufhistorie bleibt 90 Tage, maschinelle Lesezugriffe werden im Fenster zusammengefasst, und Statements werden ohne ihre Literale gespeichert, solange `AuditRawSql` aus ist.