27 KiB

Raw Blame History

GPO-/Baselineanalyse – Bedrohungsmodell und Speichergrenze

Stand: 2026-09-06

Tooluebergreifende AI search (Phase 7, 2026-09-06)

Die ausdrueckliche Nutzerfreigabe erweitert die Suche auf alle FindingReader-Tools. Der lokale, quellenbelegte Public-Identifier-Katalog ergaenzt die bisherigen GPO-Begriffe um exakte Registryziele, Windows-Rechte, ASR- und Scanner-Regelkennungen. Exportiert wird ausschliesslich die katalogeigene Schreibweise oder festes Fachvokabular; kein ungepruefter Berichtstext. Eng begrenzte numerische/boolesche Baselineziele werden nur fuer erkannte Einstellungen und als ausgewaehlter, nicht unabhaengig verifizierter Benchmarkwert weitergegeben. Kundenseitige Istwerte, Konten/SIDs, Namen, Quellpfade, freie Beschreibungen/Abhilfe und importierte URLs bleiben ausgeschlossen. Unbekannte Regeln bleiben als Topic-Suche gekennzeichnet. Keine automatische Anfrage oder Uebernahme von AI-Antworten in Bewertungen. Dies praezisiert/erweitert die historischen Freigaben unten; Details, Grenzen und Katalogpflege siehe public-ai-search.md. Google-Verbindungs-/Kontodatenverarbeitung und betriebliche Freigaben bleiben unveraendert relevant.

Phase: 13B, verifiziert bis zum Registry.pol-Parser sowie zur Job- und Ergebnispersistenz

AppLocker-Wertdarstellung (Phase 7, 2026-09-06)

Die reine Leseprojektion formatiert AppLocker-XML mit dem vorhandenen SAX-Parser als escapeten Text. Grenzen: 262.144 Zeichen, 2.000 Elemente, 32 Ebenen, 128 Attribute je Element. DTD, Processing Instructions, fremde Namespaces und fehlerhaftes XML werden nicht strukturiert dargestellt; der unveraenderte Wert bleibt inerte Textausgabe. Bedingungen, Ausnahmen und unbekannte Erweiterungen bleiben getrennt erhalten. Keine aktive HTML-Darstellung, externen Referenzabrufe, Bewertungsaenderung oder Mutation der Originaldaten.

Schutzgüter

Vertraulichkeit unveränderter GPO- und Baselineoriginale
Integrität von Artefakten, Inventaren, Processing Runs, Policybeobachtungen und Evaluationen
Reproduzierbarkeit über Parser- und Regelversionen
Verfügbarkeit des Backends trotz manipulierten oder sehr großen Eingaben
fachliche Korrektheit: keine erfundene Vollständigkeit, Wirksamkeit, Severity oder Zielzuordnung

Vertrauensgrenzen

Conflict-Results-Leseprojektion (2026-09-06): Aus vorhandenen normalisierten Beobachtungen abgeleitete Konfliktvarianten und Quellreferenzen werden im bestehenden Results-Fenster ausschliesslich als escapete Tabellenzellen/Praeambel dargestellt, niemals als HTML, Markdown-Links oder aktive Pfade. Der interne JSON-Umschlag wird vor Darstellung auf Version, Form, zwei Tabellen, maximal acht Spalten/20.000 Zeilen je Tabelle und 10 MiB Text begrenzt; bei Fehlern bleibt die urspruengliche Evidenzansicht bestehen. Whitespace wird im Umschlag escapet, damit die generische Tabellenprojektion signifikante Wertunterschiede nicht verwischt. Keine neue externe Navigation, Uebermittlung, Datenbankmutation oder Vergleichsentscheidung.

Erweiterung AI-Suchkontext (2026-09-06, Phase 7): Auf ausdruecklichen Nutzerwunsch werden Scope (computer/user), exakt freigegebene oeffentliche Baselinebezeichnungen und feste Vergleichslabels als anonymes Backup-Pruefszenario uebermittelt. Diese Freigabe ersetzt die vorherige vollstaendige Auslassung dieser Kontextfelder. Audit-Abhilfe fuer bekannte Microsoft-Subkategorien System Integrity/Logoff wird nur aus einer vollstaendig passenden, begrenzten Grammatik mit zwei eindeutigen booleschen Sollflags und passendem Titel/Scope neu aufgebaut; Expected und Must include bleiben getrennt. Unbekannte IDs, Zusatztexte, mehrdeutige Felder und andere freie Abhilfetexte werden verworfen. Description-Platzhalter sowie nicht unabhaengig verifizierte importierte Beschreibungen bleiben ausgeschlossen. Keine automatische Uebermittlung, keine Kundennamen/Istwerte/Quellpfade und keine Live-Suche mit Test- oder Kundendaten. Oeffentliche Fachbegriffe allein sind keine Zusicherung von DSGVO-Konformitaet: Google verarbeitet weiterhin Verbindungs-/IP- und gegebenenfalls Kontodaten; betriebliche Freigaben bleiben erforderlich. Historische Schutzentscheidungen gelten ausserhalb dieser engen Nutzerfreigabe unveraendert.

Praezisierung AI search (2026-09-06): Auf ausdruecklichen Nutzerwunsch ersetzt ein Google-AI-Mode-Browserlink (search?udm=50&q=...) die klassische Suchnavigation. Der Prompt verlangt offizielle Microsoft-Quellen, genaue Konfigurationshinweise und versionsabhaengige Baselineempfehlungen; dies ist eine Anfrage an Google, keine Garantie ueber die Antwortqualitaet oder Quellenauswahl. Eine feste Liste oeffentlicher Firewall-Einstellungsnamen, Domain-/Private-/Public-Profilbezeichnungen und Microsoft-Produktversionen ergaenzt die bestehenden freigegebenen Begriffe. Nur exakte Einstellungsnamen werden uebernommen, indem auf die fest hinterlegte oeffentliche Schreibweise abgebildet wird; rohe Metadaten bleiben lokal. Unbekannte Namen fallen auf das Fachthema zurueck. Keine Aenderung an Opener-/Referrerschutz oder Klickpflicht; keine API-/Aboanbindung, keine automatische Pruefung privater Google-Kontodaten. Google kann AI Mode je nach Konto/Region sperren oder den Deep Link aendern; Suchantworten werden nicht in Assessor-Bewertungen uebernommen.

Nutzerfreigegebene Websuche (2026-09-06): Der GPO-FindingReader darf ausschliesslich nach einem bewussten Klick eine HTTPS-Suche bei Google mit site:learn.microsoft.com oeffnen. Die Query wird nur aus fest im Quellcode freigegebenem oeffentlichem Microsoft-Vokabular aufgebaut. Importierte Finding-/GPO-/Kunden-/Baseline-Namen, Ist-/Sollwerte, Registry-/Datei-/Netzwerkpfade, Beschreibungen, URLs und Identitaeten werden niemals in die Query kopiert. Fuer exakt bekannte oeffentliche Einstellungsnamen existiert eine kleine feste Zuordnung; ansonsten wird ein allgemeines Fachthema gesucht. noopener, noreferrer und referrerPolicy=no-referrer verhindern Opener-/Referrerweitergabe. Keine automatische Anfrage, Telemetrie, Vorabpruefung, Such-API oder Uebertragung von Uploads. Der Suchanbieter erhaelt technisch weiterhin die Browserverbindung/IP und ggf. seine eigenen Cookies; keine Zusage anonymer Nutzung. ADML-Beschreibungen und abgeleitete Abhilfe werden nur als escapeter Text gerendert, nicht als HTML oder ausfuehrbare Links. Diese ausdrueckliche Freigabe erweitert nicht die uebrigen lokalen Verarbeitungsgrenzen.

Alle Uploadbytes, Dateinamen, Browser-Relativpfade, Archivpfade, XML-Inhalte, Backupmetadaten, Zeitstempel und Herstellerpakete sind nicht vertrauenswürdig. Der Browser, Dateiendungen und Client-MIME sind keine Autorität. Das Backend validiert Bytes, Hash, Pfade, Größen, Beziehungen und Benutzerentscheidungen erneut. PostgreSQL speichert Fachzustand; Originalbytes liegen getrennt außerhalb des Webroots hinter einer backendkontrollierten Speicher-ID.

Ein Parserworker begrenzt Zeit und Speicher, isoliert aber keinen bösartigen nativen Code. Importierte Programme, Skripte, Bibliotheken und Makros werden niemals geladen oder ausgeführt. Ein später optionaler externer Adapter benötigt einen administrativ freigegebenen festen Pfad und Hash, einen niedrig privilegierten Prozess ohne Shell und Netzwerk sowie harte Zeit-, Umgebungs- und Ausgabegrenzen.

Wesentliche Bedrohungen und Gegenmaßnahmen

Bedrohung	Verbindliche Gegenmaßnahme
Prozessabbruch zwischen privater Dateiveröffentlichung, Artefaktanlage und Jobanlage erzeugt ein unreferenziertes Objekt oder ein GPO-Artefakt ohne Analyseauftrag.	Artefakt und initialen Job in einer Repository-Transaktion anlegen; neu geschriebenes Objekt bei Commitfehler sofort kompensierend entfernen. Periodisch projektübergreifend Referenzen ermitteln, fehlende GPO-Jobs idempotent reparieren und ausschließlich reguläre, nicht referenzierte Objekte nach 24 Stunden Schonfrist sowie mit festem Löschlimit entfernen. Bei leerem vertrauenswürdigem Referenzbestand jede Objektlöschung fail-safe sperren.
Flüchtiger UI-Zustand zeigt nach Navigation einen laufenden, fehlgeschlagenen oder wiederaufgenommenen GPO-Auftrag nicht mehr an.	Status projektgebunden aus persistentem Artefakt, Ingestion Job und Processing Run ableiten; nur opake IDs und technische Zustände liefern und die sichtbare Mandantenansicht regelmäßig sowie bei Fokus aktualisieren.
Bewusstes Löschen eines Dead-Letter-Imports commitet die Datenbank, der Prozess endet jedoch vor dem Entfernen der privaten Dateikopie.	Löschung nur projektgebunden, nur für vollständig fehlgeschlagene GPO-Jobs und nach exakter Bestätigung zulassen. Artefakt-/Job-/Verarbeitungshistorie und unabhängigen Löschauftrag atomar committen; Dateikopie anschließend idempotent entfernen und offene Aufträge beim Start sowie periodisch wiederaufnehmen.
Manipulierte Browser-Relativpfade, Unicode-/Case-Kollisionen oder eine übergroße Ordnerauswahl erzeugen einen unsicheren beziehungsweise ressourcenintensiven Transportumschlag.	Jeden Pfad vor dem Dateilesen kanonisieren, Pfadkollisionen containerweit ablehnen, Eintrags-/Einzel-/Gesamtgrößen begrenzen, Dateien sequenziell lesen und ausschließlich einen deterministischen unkomprimierten Umschlag erzeugen; der Backend-Worker validiert den Umschlag unabhängig erneut.
Eine ältere oder ungültige persistierte Speicherreferenz lässt die gesamte Reconciliation abbrechen oder führt nach dem Herausfiltern zu unsicherer Orphan-Löschung.	Ungültige Referenzen nur technisch zählen und nicht an den Dateispeicher übergeben; sobald mindestens eine vorliegt, jede reguläre unreferenzierte Objektlöschung fail-safe sperren. Lösch-Outbox, Stagingbereinigung und Jobreparatur dürfen davon unabhängig fortgesetzt werden.
Ein großer zulässiger GPO-Umschlag wird beim Workerstart vollständig strukturell geklont und überschreitet dadurch trotz gültiger Eingabe das Heaplimit.	Eine eigene Bytekopie anlegen und deren ArrayBuffer per Transferliste in den Worker übertragen; die Caller-Bytes bleiben unverändert, gleichzeitig gelten weiterhin Eingabe-, Parallelitäts-, Zeit- und konfigurierbare Heapgrenzen. Jedes kurzlebige JSDOM-Fenster in Metadaten- und Preference-Parsern in `finally` schließen und nur persistenzrelevante Ergebnisse statt vollständiger Parser-Zwischenmodelle über die Workergrenze übertragen.
ZIP-Slip, absolute/UNC-/Laufwerkspfade oder Alternate Data Streams	Gemeinsame strikte relative Pfadkanonisierung vor Inventarisierung und Speicherung; `..`, `.`, Doppelseparatoren, Doppelpunkte, Windows-Gerätenamen und Sonder-Schrägstriche ablehnen.
Unicode-, Groß-/Kleinschreibungs- oder Windows-Namenskollision	NFC und case-insensitiven Kollisionsschlüssel je Container prüfen; kollidierendes Inventar vollständig blockieren.
Symlinks, Reparse Points oder manipulierte Header	Keine Extraktion über Betriebssystempfade; Link-/Spezialdateieinträge ablehnen und deklarierte gegen tatsächlich gelesene Größen und Hashes prüfen.
ZIP-Bomb, verschachtelte Archive oder Ressourcenerschöpfung	GPO-Transporte blockieren verschachtelte Archive. Microsoft-Baselinepakete duerfen erwartete Office-Dokumente als opake ZIP-signierte Dateien enthalten, oeffnen sie aber nie: Containerpfade, Typen und deklarierte Grenzen werden insgesamt geprueft; nur Backup.xml, Registry.pol, ADMX und ADML werden selektiv mit lokalen Headern, tatsaechlicher Groesse, Kompressionsverhaeltnis, CRC und SHA-256 entpackt. Grenzverletzung bricht atomar ab.
XML-Entitäten, externe Schemas, XInclude oder Netzwerkzugriff	DTD/ENTITY/SYSTEM/PUBLIC/XInclude und externe Referenzen vor dem Parser ablehnen; begrenzten Parser ohne Netzwerk verwenden.
Manipulierte ADMX-/ADML-Dateien erzeugen falsche Identitaeten oder lokalisierte Texte werden als technische Schluessel verwendet.	XML nur begrenzt und ohne DTD, Entitaeten, Includes, Schemas oder fremde Processing Instructions lesen; Zielnamespace und Policy-Name als technische ADMX-Referenz verwenden, doppelte Namespaces/IDs blockieren, Registryziel nur eindeutig zuordnen und ADML-Strings ausschliesslich als katalogversionierte Anzeige-Metadaten behandeln.
Skript- oder Binärausführung	Nur inventarisieren und hashen; niemals importieren, laden, entschlüsseln oder starten.
Manipulierte oder herstellerspezifisch erweiterte `Registry.pol`-Datensaetze erzeugen falsche Instruktionen oder Ressourcenverbrauch.	PReg-Signatur und Version, Feldabschluesse, Schluessel und Wertnamen, Typen, Datengroessen, Datensatzanzahl und Gesamtgroesse vor Reduktion begrenzen; nur freigegebene Typen und REG_NONE als exakt leere Schluesselanlage akzeptieren, sonst das Artefakt ohne Salvage blockieren. Keine Datei ausfuehren und keinen externen Prozess starten.
GPP-`cpassword` oder andere Geheimnisse	Nur Vorhandensein und Locator erfassen; Wert bereits an der Parsergrenze maskieren, niemals entschlüsseln, loggen oder exportieren.
Manipulierter oder unbeabsichtigt ausgetauschter Policy-Regelkatalog	Einen extern kuratierten Katalog nur aus einer lokalen regulären Nicht-Symlink-Datei bis 5 MiB laden, wenn Pfad und erwarteter SHA-256 gemeinsam konfiguriert sind. Hash vor UTF-8-/JSON-Parsing prüfen, danach den vollständigen fachlichen Katalogvertrag fail-closed validieren und bei jeder Abweichung vor Repository- und Serverstart abbrechen. Keine automatische Netzwerkquelle oder stille Aktivierung.
Pfad-/Namensheuristik erzeugt falsche Policy- oder Zielidentität	Technische IDs ausschließlich aus unterstützten Artefaktinhalten und versionierten Regeln; Namen und Pfade bleiben Provenienz. Microsoft-Vorlagennamen werden nur auf ausdruecklichen Analyzer-Opt-in aus begrenzten XML-Feldern gelesen, nie als GPO-/Backup-/Policy-ID. Eine enge, versionierte Namensgrammatik darf den dokumentierten Vorlagenkontext beschreiben, aber nicht die Anwendung einer Kunden-GPO beweisen. Auswahl nur gegen genau einen expliziten Vergleichskontext; Inventarbeobachtungen, unbekannte Vorlagen und widerspruechliche Namen erzwingen keine Rollenwahl.
Historische Backups werden gemeinsam aggregiert	Explizite Backup-GUID, GPO-GUID, Domänenidentität, manifestgestützte Set-ID und Erhebungsfenster prüfen; doppelte GPOs, Zeitkonflikte und Domänenmischung blockieren.
Ausgewählte Teilmenge wird als vollständige Umgebung bewertet	Setvollständigkeit getrennt von Instanzvollständigkeit modellieren; negative Schlussfolgerungen nur bei manifestgestütztem vollständigem Set mit erwarteter und beobachteter Anzahl.
Backup wird mit effektiver Anwendung verwechselt	Ohne RSoP-/Group-Policy-Results-Evidenz niemals Scope oder Wirksamkeit bestätigen; Ergebnisse als konfigurierte, nicht als effektiv angewandte Abweichung qualifizieren.
Reprocessing überschreibt Historie	Originalartefakte, Inventare, Beobachtungen und Kataloge unveränderlich halten; neue versionierte Processing-/Evaluation-Runs mit Supersession erzeugen.

Speicher- und Aufbewahrungsgrenze

Speicher-IDs werden serverseitig zufällig erzeugt und enthalten weder Dateiname noch Mandantendaten.
Die Datenbank speichert Hash, Größe, Sensitivität, Beziehungen und Speicherreferenz, nicht einen öffentlich erreichbaren Pfad.
Schreiben erfolgt zuerst in einen nicht veröffentlichten Stagingbereich, anschließend werden tatsächliche Größe und SHA-256 geprüft und die Datei atomar veröffentlicht.
Nach der Veröffentlichung werden GPO-Artefakt und initialer Analysejob gemeinsam atomar in PostgreSQL angelegt. Scheitert der Commit, wird ausschließlich die dabei neu erzeugte opake Speicher-ID kompensierend entfernt.
Lesen erfolgt nur projektgebunden über autorisierte Backendlogik; keine statische Auslieferung und keine direkte Browser-URL.
UI, Audit, Diagnosen und Exporte enthalten standardmäßig nur maskierte Metadaten und keine Rohwerte möglicher Geheimnisse.
Löschung muss Projekt-, Artefakt-, Processing- und Evaluationreferenzen berücksichtigen. Konkrete Fristen, Schlüsselverwaltung und Datenträgerverschlüsselung bleiben vor Firmenbetrieb zu entscheiden.

Fail-closed-Regeln

Ein unsicherer Pfad, eine Kollision, ein Link, eine Grenzverletzung, ein Hashfehler oder ein widersprüchliches Manifest blockiert das gesamte betroffene Containerinventar. Parserlücken und unbekannte Artefakte dürfen dagegen als unsupported beziehungsweise inventory-only nachvollziehbar erhalten bleiben, sofern das Inventar selbst sicher ist. Keine dieser Situationen erzeugt automatisch ein Finding oder eine Severity.

Verifizierte technische Kontrollen

Nachtrag 2026-09-06: Metadaten-XML verwendet einen SAX-Parser ohne DOM, mit maximal 64 MiB je Datei, 500.000 Elementen, Tiefe 128 und begrenztem Identitaetsfeldpuffer. Das gemeinsame selektive Entpackbudget betraegt hoechstens 128 MiB; globale ZIP-, Datei-, Workerzeit- und Heapgrenzen bleiben erhalten. Die fruehere Anforderung an ein schliessbares Metadaten-JSDOM entfaellt; Preference-DOMs bleiben unveraendert. Synthetischer Lasttest: 2300 GPOs ueber ZIP und Ordnertransport, einschliesslich einer Metadatendatei groesser als 2 MiB.
Nachtrag 2026-09-06: Baselinepakete lesen auch Security-Template- und Advanced-Audit-Artefakte durch dieselben begrenzten Parser/Reducer wie Kundenbackups. Native Abschnitt-/Schluesselidentitaeten ersetzen keine Registry- oder Targetingsemantik. Automatische Profilableitung bleibt auf gespeicherte Beobachtungen desselben Assessments begrenzt; unbekannte Plattformen und mehrere Snapshotgruppen erzeugen keine erfundene Freigabe. Bestehende Vollstaendigkeits-, Konflikt-, Risiko- und Finding-Grenzen gelten unveraendert.
Der persistente GPO-Statusendpunkt prüft den Mandanten und gibt je GPO-Artefakt nur technischen Dateinamen, Größe, Queue-/Processingzustand, Versuche, Zeitpunkte, Fehlercode und Backupinstanzzahl aus. Die Mandantenansicht lädt diese Werte neu und pollt nur solange sie sichtbar ist; Speicherschlüssel und Rohinhalte werden nicht ausgegeben.
Die Artefakt-/Jobanlage ist in lokaler und PostgreSQL-Persistenz atomar. PostgreSQL-Rollback, unmittelbares Entfernen einer neuen Dateikopie bei Commitfehler, idempotente Reparatur eines Legacy-Artefakts ohne Job sowie alters- und mengenbegrenztes Entfernen eines synthetischen unreferenzierten Objekts sind verifiziert. Reconciliation startet mit dem Backend und läuft standardmäßig stündlich; unbekannte Namen, Links und junge Objekte werden nicht gelöscht; bei leerem vertrauenswürdigem Referenzbestand findet überhaupt keine Objektlöschung statt.
Ein Dead-Letter-Job kann ausschließlich innerhalb seines Projekts und ohne Änderung des Originalartefakts auf queued mit null Versuchen zurückgesetzt werden. Das Löschen erfordert eine exakte Bestätigung und ist nur möglich, wenn alle zugehörigen GPO-Jobs dead-letter sind. Migration 006 hält den Speicherauftrag unabhängig von der anschließend gelöschten Artefaktzeile; ein simulierter Abbruch zwischen Commit und Objektlöschung sowie die spätere Reconciliation sind synthetisch und in PostgreSQL verifiziert.
Die Chrome-Ordnerauswahl akzeptiert ausschließlich relative webkitdirectory-Pfade, normalisiert und kollisionsprüft sie vor dem Lesen und erzwingt die gemeinsame Grenze von 20.000 Einträgen sowie 100 MB. Dateien werden sequenziell gelesen und bytegleich in einen deterministischen ZIP-STORE-Transportumschlag geschrieben. Derselbe projektgebundene Backend-Endpunkt und derselbe gehärtete Worker prüfen diesen Umschlag erneut; der Browser erhält dadurch keine Backend-Dateisystemberechtigung.
Der dedizierte GPO-Inventar-Worker besitzt Eingabe-, Parallelitäts-, Heap- und Zeitgrenzen und wird als eigener Server-Build-Einstieg erzeugt.
Vor jeder Dekompression werden beide ZIP-Strukturebenen, Pfadkanonisierung, Unicode-/Case-Kollisionen, Dateitypen und Datenbereiche vollständig geprüft.
Dekompression erfolgt ausschließlich im Worker-Speicher. Tatsächliche Einzel-/Gesamtgrößen und Kompressionsverhältnisse, CRC und SHA-256 werden geprüft; nur ausdrücklich ausgewählte, vollständig verifizierte Metadateneinträge werden innerhalb eines zusätzlichen Bytebudgets an den Parser übergeben.
Links, Spezialdateien, verschachtelte ZIPs, verschlüsselte oder mehrteilige Archive, ZIP64 sowie nicht eindeutig UTF-8-kodierte Nicht-ASCII-Pfade blockieren das gesamte Inventar.
Der GPO-Metadatenparser läuft im begrenzten Worker, akzeptiert nur begrenztes UTF-8 beziehungsweise BOM-markiertes UTF-16, lehnt DTD, Entitäten, externe Referenzen, XInclude, Schemas und fremde Processing Instructions ab und übernimmt technische IDs nur konfliktfrei aus Inhalt. cpassword wird nur als Indikator erkannt; der Wert verlässt die Parsergrenze nicht.
Der Security-Template-Parser läuft in derselben Ressourcenbegrenzung und erzwingt Datei-, Zeichen-, Zeilen- und INF-Feldgrenzen. Unterstützte Abschnitte werden semantisch getrennt reduziert; unterschiedliche Dubletten bleiben Konflikte, unbekannte Abschnitte partial, ungültige Registry-Instruktionen blockiert und effektive Anwendung bleibt ohne RSoP immer unknown. Rohwerte werden nicht über die bestehende Backend-/Projektgrenze veröffentlicht.
Präzisierung 2026-09-08 (Security-Template-Parser 1.1.0): Metadaten und unbekannte Abschnitte werden vor der Key/Value-Validierung übersprungen, da beispielsweise Service-Einträge eine eigene CSV-artige Grammatik haben. Isolierte defekte Einträge in unterstützten Abschnitten werden mit Diagnose verworfen; gültige Instruktionen behalten Originalwert und Quellzeile bei Dokumentstatus partial. Dies ersetzt ausschließlich die bisherige artefaktweite Verwerfung wegen einzelner defekter INF-Einträge. Beschädigte Abschnittsgrenzen, Einträge ohne Abschnitt und Ressourcenverletzungen bleiben blockiert; Dekodierungsfehler werden weiterhin abgewiesen. partial/inventory-only bleiben in Baselineanalyse und Kundeninventar sichtbar und erlauben keine Vollständigkeitsbehauptung. Historische Analysen bleiben erhalten; Baseline-Analyzer 1.2.0 und GPO-Processing 2.2.3 erzeugen versionierte Nachfolger.
Der Advanced-Audit-Parser verwendet den allgemeinen CSV-Pfad nur zur begrenzten lexikalischen Dekodierung mit physischen Quellzeilen. Er verlangt die technischen Spalten Policy Target, Subcategory GUID und Setting Value, akzeptiert nur kanonische Subcategory-GUIDs sowie numerische Flags 0 bis 3 und ignoriert lokalisierte Anzeigenamen. Nur Systemziele werden reduziert; benutzerspezifische Ziele bleiben partial. Abweichende GUID-Dubletten bleiben Konflikte, ungültige unterstützte Zeilen blockieren ohne Salvage und effectiveState bleibt ohne RSoP unknown. Advanced und Legacy Audit werden nicht zusammengeführt.
Der Registry.pol-Parser laeuft im begrenzten GPO-Worker und akzeptiert ausschliesslich PReg Version 1 mit festen Datei-, Datensatz- und Datenfeldgrenzen. Er dekodiert freigegebene Registrytypen typisiert, erhaelt Instruktionsreihenfolge und Byteoffset-Provenienz und behandelt REG_NONE nur als leere Schluesselanlage. Delete-, DeleteValues-, DeleteKeys-, SecureKey- und Soft-Operationen bleiben getrennt; unbekannte Typen und fehlerhafte unterstuetzte Strukturen blockieren ohne Salvage, unbekannte reservierte Operationen bleiben als nicht unterstuetzt sichtbar. Weder Shell noch LGPO.exe noch Netzwerk werden verwendet.
Der Group-Policy-Preferences-Parser läuft in derselben Ressourcenbegrenzung, akzeptiert nur begrenztes UTF-8 beziehungsweise BOM-markiertes UTF-16 und lehnt DTD, Entitäten, externe Referenzen, Schemas sowie fremde Processing Instructions ab. Registry Preferences benötigen die dokumentierten technischen CLSIDs, kanonische Item-UIDs, gültige Hives, Ziele, Werttypen, Aktionen und boolesche Common Options. Verarbeitungsreihenfolge, Disabled, Remove-on-unapply und Apply-once bleiben erhalten. Item-Level-Targeting wird strukturell validiert, aber ohne Umgebungsevidenz nur durch Filtertypen und Ausdruckshash als nicht auswertbar gebunden. Unbekannte CSEs beziehungsweise Registry-SubProperties bleiben partial; fehlerhafte unterstützte Strukturen blockieren ohne Salvage. cpassword wird nur als Indikator erkannt, nie entschlüsselt oder in Dokument, Beobachtung, Diagnose beziehungsweise Export übernommen.
Der Local-Users-and-Groups-Reducer prüft die dokumentierten Groups-, User- und Group-CLSIDs, kanonische Item-UIDs, Aktionen, lokale Benutzer-/Gruppenziele, optionale SIDs, boolesche Kontoeigenschaften und geordnete Member-Aktionen. Bei Gruppen hat eine gültige SID Vorrang vor dem Namen; Delete-all-users/-groups bleibt als vorgelagerte Operation getrennt von der Add/Remove-Mitgliedsliste. Bei lokalen Benutzern wird ein vorhandenes cpassword ausschließlich als passwordAttributePresent: true und Geheimnisdiagnose abgebildet. Der Attributwert wird nicht inhaltlich ausgewertet, nicht entschlüsselt, nicht in Instruktionen übernommen und nicht über Persistenz oder Export weitergegeben.
Der Services-Reducer prüft die dokumentierten NTServices-/NTService-CLSIDs, kanonische Item-UIDs, Common Options, Computer-Scope sowie die erlaubten Dienst-, Start- und Fehleraktionen. Die Preference-Instruktion bleibt configure; serviceAction, startupType, Dienstkonto, Interaktionsflag, Fehleraktionen und nichtnegative dokumentierte Zeitfelder werden weder zusammengeführt noch in einen behaupteten Endzustand umgerechnet. User-Scope und unbekannte Eigenschaften bleiben partial; ungültige unterstützte Enums, Zahlen und boolesche Werte blockieren fail-closed. Ein vorhandenes cPassword wird nur als passwordAttributePresent: true und Geheimnisdiagnose abgebildet; sein Wert wird nicht inhaltlich ausgewertet, entschlüsselt, persistiert oder exportiert.
Der Drive-Maps-Reducer prüft die dokumentierten Drives-/Drive-CLSIDs, kanonische Item-UIDs, User-Scope, C/D/R/U, UNC-Ziele, Laufwerksbuchstaben, boolesche Persistenz-/Auswahlflags und Sichtbarkeitswerte. Die aktionsabhängige Bedeutung von useLetter=0 bleibt als Delete-Bereich, erster freier Buchstabe oder erstes vorhandenes Mapping im Bereich erhalten; thisDrive wird nicht mit allDrives kollabiert. Computer-Scope und unbekannte Eigenschaften bleiben partial; ungültige unterstützte Buchstaben, UNC-Pfade, Sichtbarkeiten, Kontostrukturen oder boolesche Werte blockieren fail-closed. Ein vorhandenes cpassword wird nur als passwordAttributePresent: true und Geheimnisdiagnose abgebildet; der Wert wird nicht entschlüsselt, persistiert oder exportiert.
Der Rohartefaktspeicher erzeugt zufällige opake Schlüssel, schreibt mit exklusiven Rechten in privates Staging, flusht, prüft tatsächliche Größe und SHA-256, veröffentlicht überschreibungsfrei und prüft beides bei Lesezugriff erneut. Der Server lehnt einen Speicherroot innerhalb des Webroots ab. Submission prüft Projekt und Container vor Aufbewahrung, persistiert eine projektgebundene Artefakt-/Jobreferenz und gibt den Speicherschlüssel nicht an den Browser aus. Benutzer-/Rollenautorisierung folgt erst mit dem Firmenbetrieb.
Der dedizierte analyze-gpo-backup-Jobtyp ist additiv migriert und projektweit idempotent; Annahme bedeutet ausschließlich queued, nicht erfolgreiche Analyse oder Vollständigkeit. Der Lease-basierte Runner claimt nur diesen Typ, liest das projektgebundene Original erneut mit Größen-/SHA-256-Prüfung und persistiert Processing Run plus Backupinstanzen atomar vor dem Jobabschluss. Deterministische IDs ermöglichen exakte revisionsneutrale Crash-Retries; abweichende Wiederholungen überschreiben keine Historie.
Nicht durch einen verifizierten Parser unterstützte Artefaktrollen bleiben inventory-only beziehungsweise unsupported; dadurch bleiben Einzel- und Setvollständigkeit konservativ.

27 KiB Raw Blame History Unescape Escape