Sitzungen erscheinen im Dashboard, während die Spalte für den Benutzernamen leer bleibt, und der erste Reflex ist, den Parser zu beschuldigen. Dieser Reflex überspringt drei frühere Stufen, auf denen der Wert verloren gegangen sein könnte. Ein Gateway kann eine Identität per Richtlinie maskieren, eine Ingest-Regel kann sie vor der Indexierung löschen, und eine Extraktion zur Suchzeit kann es schlicht versäumen, sie zu benennen. Die Behebung hängt davon ab, welche Grenze Sie als verantwortlich nachweisen können, deshalb ist die nützliche Arbeit der Vergleich und nicht die Konfiguration.

Beginnen Sie mit einem Ereignis, nicht mit dem Dashboard

Wählen Sie ein einzelnes Authentifizierungsereignis und notieren Sie, was es identifiziert: Gateway-Modell und Release, Authentifizierungsmethode, Ereignis-ID, Zeitstempel und Quelladresse. Fügen Sie den Benutzernamen genau so hinzu, wie die Person ihn eingegeben hat, einschließlich Groß- und Kleinschreibung, denn eine groß- und kleinschreibungssensitive Suche kann ein vorhandenes Feld verbergen. Behandeln Sie dieses Ereignis als Referenz für jeden späteren Vergleich.

Ereignistypen teilen kein gemeinsames Schema. Ein fehlgeschlagener Versuch, eine erfolgreiche Anmeldung ohne Client und ein erneuter Tunnelaufbau können jeweils andere Felder erzeugen, und manche Gateways lassen die Identität weg, wenn der Versuch die Benutzerauthentifizierung nie erreicht hat. Eine leere Spalte bei einem Ereignistyp ist daher ein schwacher Hinweis auf ein Pipeline-Problem.

Arbeiten Sie mit einer freigegebenen Testidentität statt mit einem echten Mitarbeiterkonto und halten Sie den Vergleich innerhalb der Zugriffsregeln, die für die Logdaten bereits gelten. Eine breit aktivierte ausführliche Authentifizierungsprotokollierung nur für eine Stichprobe verändert das System, das Sie messen wollen.

Vergleichen Sie die vier Grenzen der Reihe nach

Der Wert kann an einer von vier Stellen verschwinden. Jede Stelle hat einen anderen Verantwortlichen und eine andere Reparatur.

BoundaryWhat to compareA gap means
Gateway event viewThe device's own event display and logging policyThe identity was masked or never emitted
Collector receiveThe raw event as received, before parsingTransport, filter or source selection dropped it
Index-time pipelineTransforms applied before storageRedaction or rewriting removed the value
Search-time extractionThe field name and regex used by the queryThe label does not match the stored key

Halten Sie an der ersten Grenze an, an der der Wert verschwindet. Eine Abweichung zwischen Geräteansicht und Rohkopie deutet auf Transport oder Collector-Konfiguration; eine Übereinstimmung dort, aber ein fehlender Wert im indexierten Ereignis deutet auf eine Transformation; ein im indexierten Ereignis vorhandener, im Dashboard aber fehlender Wert deutet auf Extraktion oder Abfrage.

Diese Reihenfolge ist wichtig, weil jede spätere Stufe nur Informationen verlieren und sie niemals wiederherstellen kann. Ein regulärer Ausdruck kann eine Zeichenfolge nicht zurückholen, die eine frühere Stufe durch einen Platzhalter ersetzt hat, und eine Datenschutzeinstellung kann einen Wert nicht erklären, der nie gesendet wurde.

Maskierung an der Quelle ist Richtlinie, kein Parserfehler

Ciscos Dokumentation zur ASA-Protokollierung beschreibt das Ausblenden von Benutzernamen als konfigurierbares Verhalten, einschließlich der Darstellung ungültiger oder unbekannter Benutzernamen. Eine maskierte Identität im Quellereignis kann daher genau das sein, was die Datenschutzrichtlinie verlangt, und ihre Behandlung als Parsingfehler führt zu einer Anfrage, die die Kontrolle schwächt.

Die genaue Darstellung hängt vom Release und vom Nachrichtentyp ab. Ein Ereignis kann einen Platzhalter tragen, ein anderes kann das Feld ganz weglassen, und ein Authentifizierungsfehler enthält möglicherweise nie einen Namen. Prüfen Sie das dokumentierte Verhalten für das konkrete Ereignis, statt einen alten Fehlerbericht auf jede fehlende Identität anzuwenden.

Wenn die Maskierung beabsichtigt ist, verschiebt sich die Frage davon, wie das Feld wiederhergestellt wird, darauf, ob die Audit-Anforderung anders erfüllt werden kann. Sitzungs-IDs, ein kontrolliertes Identitätsmapping bei einer kleineren Gruppe oder ein engerer autorisierter Ereignisstrom erfüllen den Bedarf oft, ohne jeden versuchten Benutzernamen jedem Logleser vorzulegen.

Anonymisierung vor der Indexierung lässt sich nicht rückgängig machen

Splunks Dokumentation zur Ereignisverarbeitung beschreibt Anonymisierung über sed-Ausdrücke und Transformationen, die Daten vor der Indexierung umschreiben oder entfernen. Genau diese Platzierung ist der Punkt: Das Rohereignis wird beim Eingang verändert, sodass eine Extraktion zur Suchzeit nichts mehr zu finden hat.

Redaktion zur Indexzeit und Feld-Extraktion zur Suchzeit lösen unterschiedliche Probleme. Redaktion begrenzt, wer den Wert überhaupt sehen kann; Extraktion entscheidet nur, welchen Namen die Abfrage verwendet. Hashing ist eine mittlere Option, die Korrelation erhält, aber ein stabiler Hash über einen kleinen Benutzernamensraum ist weiterhin identifizierend, wenn jemand Kandidatennamen dagegen testen kann.

Wenn das gespeicherte Ereignis die Identität noch enthält, liegt das Problem weiter unten: Quelltyp, Zeilenumbruch, Behandlung von Trennzeichen, Feld-Aliase oder die Abfrage selbst. Das sind gewöhnliche Parsing-Reparaturen, und sie berühren die Datenschutzgrenze nicht.

Wählen Sie die Behebung, die zur Grenze passt

Drei Bedingungen entscheiden die Reaktion. Erstens: Soll die Datenschutzrichtlinie die Identität ausschließen? Zweitens: Braucht der Audit- oder Untersuchungsprozess die Identität, ein Pseudonym oder nur die Sitzung? Drittens: An welcher Grenze wird der Wert benötigt — Erfassung, Speicherung oder Darstellung?

Wenn die Richtlinie den Ausschluss beabsichtigt, ändern Sie die Anforderung oder die Darstellung, nicht die Kontrolle. Wenn die Richtlinie die Identität erlaubt, die Erfassung sie aber verwirft, reparieren Sie den Collector und bestätigen Sie das Rohereignis. Wenn die Speicherung intakt ist, reparieren Sie die Extraktion und testen Sie sie gegen das freigegebene Ereignis, das Sie zu Beginn erfasst haben.

Schließen Sie die Untersuchung ab, indem Sie die Grenze im Änderungsdatensatz benennen: an der Quelle maskiert, beim Ingest entfernt oder von der Extraktion übersehen. Dieser eine Satz sagt dem nächsten Engineer, wo zuerst nachzusehen ist, und er verhindert, dass aus einer Dashboard-Beschwerde eine still deaktivierte Datenschutzfunktion wird.

Ähnliche Artikel