58 lines
16 KiB
Markdown
58 lines
16 KiB
Markdown
# GPO-/Baselineanalyse – technischer Ausgangsstand
|
||
|
||
Stand: 2026-08-04
|
||
Phase: 13B, Umsetzungsschritte 1 bis 5 und Job-/Persistenzteil aus Schritt 11 in Arbeit
|
||
|
||
## Vorhandener gemeinsamer Unterbau
|
||
|
||
- Uploads werden anhand tatsächlicher Signaturen und Inhaltsstruktur erkannt; Dateiendung und Client-MIME sind nur Hinweise.
|
||
- Die Ressourcenrichtlinie begrenzt Datei-, Text-, Tabellen-, XML-, JSON- und ZIP-Ressourcen. ZIP64, verschlüsselte Einträge, nicht erlaubte Kompression, ausbrechende Pfade und auffällige Kompressionsverhältnisse werden für Excel-Container bereits geprüft.
|
||
- Serverseitige Parser laufen in begrenzten Workern. Worker sind eine Ressourcen-, keine Sicherheits-Sandbox.
|
||
- Allgemeine Importartefakte, unveränderliche Processing Runs und persistente Ingestion Jobs sind als projektgebundene Repository- und PostgreSQL-Verträge vorhanden.
|
||
- Der Scannerpfad trennt Formatadapter, Source Extractor, Candidate-Mapping und kanonisches Finding. Dieser Pfad bleibt für Scanner bestehen.
|
||
|
||
## Noch nicht vorhandene GPO-Funktionalität
|
||
|
||
- Der generische Scannerimport weist ZIP-Container weiterhin als `unsupported-container` ab. GPO-Backups besitzen einen getrennten projektgebundenen Backend-Endpunkt, der Container vor Speicherung im eigenen ressourcenbegrenzten Worker inventarisiert und nur erkannte Kandidaten als persistentes Artefakt mit Analysejob annimmt. Im Datahub kann für einen vorhandenen Mandanten unter Chrome ein vollständig entpackter GPO-Backupordner ausgewählt werden; die Oberfläche überführt dessen relative Pfade und unveränderte Dateibytes deterministisch in einen unkomprimierten Transportumschlag und sendet ihn an genau diesen Endpunkt. Dieselbe Mandantenansicht lädt Artefakt-, Queue-, Retry-, Dead-Letter- und Processingzustände dauerhaft aus dem Backend und aktualisiert sie während der sichtbaren Ansicht; Navigation verwirft nur die Darstellung, nicht den Status.
|
||
- Der dateibasierte Rohartefaktspeicher ist im Serverruntime angebunden, sein Root ist konfigurierbar und eine Lage innerhalb des Webroots wird abgelehnt. GPO-Artefakt und initialer Analysejob werden in einer Repository-Transaktion angelegt; ein fehlgeschlagener Commit entfernt die gerade geschriebene Dateikopie kompensierend. Eine periodische Reconciliation repariert fehlende GPO-Jobs idempotent und entfernt reguläre unreferenzierte Objekte sowie Stagingreste erst nach einer konfigurierbaren, standardmäßig 24-stündigen Schonfrist und mit begrenzter Löschanzahl. Ohne mindestens eine vertrauenswürdige backendkontrollierte Datenbankreferenz ist die automatische Objektlöschung vollständig gesperrt. Dasselbe gilt, sobald eine persistierte backendkontrollierte Referenz nicht dem aktuellen opaken Speicherformat entspricht; der Zustand wird gezählt, Jobreparatur und Lösch-Outbox laufen weiter. Benutzer-/Rollenautorisierung, Verschlüsselung und fachliche Löschfristen bleiben vor dem Firmenbetrieb offen.
|
||
- Fehlgeschlagene GPO-Analysen bleiben als referenzierte Dead-Letter-Artefakte erhalten und sind keine unkontrollierten Datenleichen. Sie können in der Mandantenansicht ohne erneuten Upload erneut eingeplant oder nach expliziter Bestätigung aus ASSESSOR gelöscht werden. Die Löschung entfernt relationale GPO-Historie atomar zusammen mit einem unabhängigen persistenten Löschauftrag; die private Dateikopie wird anschließend entfernt und nach einem Prozessabbruch beim Start beziehungsweise stündlich erneut verarbeitet. Quelldateien und Quellordner des Benutzers werden weder verändert noch gelöscht.
|
||
|
||
- Vertraege fuer einen hochgeladenen Mandanten-GPO-Backup-Snapshot, dessen enthaltene technische GPO-Datensaetze, Artefaktinventar, Analysesnapshot und Vollstaendigkeit sowie der deterministische Snapshot-Builder sind vorhanden. Technische XML-Metadaten werden begrenzt geparst und konservativ je enthaltenem GPO gespeichert. Die Submission ist im lokalen Same-origin-Backend verfuegbar; Lease-basierte Jobausfuehrung, Policy-Beobachtungen und atomare relationale Persistenz der unveraenderlichen GPO-Datensaetze sind implementiert.
|
||
- Strikt begrenzte Parser fuer GPO-Backupmetadaten, Security Templates, Advanced Audit Policy, `Registry.pol`, Registry Preferences, Local Users and Groups, Services sowie Drive Maps sind vorhanden. Security-Template-Abschnitte werden getrennt reduziert; Advanced Audit verwendet ausschliesslich technische Subcategory-GUIDs und numerische Auditflags. Der `Registry.pol`-Parser bewahrt Reihenfolge, Byteoffset-Provenienz und typisierte Set-, Delete-, SecureKey-, Soft- sowie leere REG_NONE-Schluesselanlage-Instruktionen. Preference-Beobachtungen bewahren Item-UID, CSE-Aktion, Reihenfolge, Common Options und nicht ausgewertetes Item-Level-Targeting. Local Users and Groups trennt Benutzer, Gruppen und geordnete Mitgliedschaftsoperationen und priorisiert SIDs. Services bleibt computergebunden, verwendet `configure` statt C/D/R/U und trennt Dienstaktion, Starttyp, Fehleraktionen und rohe dokumentierte Zeitfelder. Drive Maps bleibt usergebunden und bewahrt Aktion, UNC-Ziel, Startbuchstabe, aktionsabhaengigen `useLetter`-Auswahlmodus sowie getrennte Sichtbarkeit. Bei kennworttragenden CSEs wird `cpassword` ausschliesslich als Vorhandenheitsindikator gespeichert. Unbekannte Registrytypen, Preference-CSEs und Schemaerweiterungen bleiben unvollstaendig oder werden entsprechend ihrer validierten Struktur blockiert; effektive Anwendung bleibt unbekannt. Weitere Group Policy Preferences und Skriptinventare fehlen noch.
|
||
- Ein globaler Microsoft-Security-Baseline-Paketkatalog mit privater Originalaufbewahrung, Hash-Deduplizierung, Produkt-/Versions-/Rollen-/Scope-Metadaten und fail-closed Paketauswahl ist implementiert. Baseline-Einstellungsparser, stabile Policy-Identitaet, Comparatoren, Consensus, Evaluation und Finding Factory sind noch nicht implementiert.
|
||
- Scope, Verknüpfung, Vererbung, Filterung und effektive Anwendung werden nicht aus Backups abgeleitet.
|
||
|
||
## Verbindliche Integrationsgrenze
|
||
|
||
GPO- und Baselinepakete dürfen den Scannerpfad nicht als scheinbare Tabellenfindings durchlaufen. Sie verwenden die allgemeinen Upload-, Artefakt-, Ressourcen-, Job-, Audit- und Persistenzgrenzen, erzeugen fachlich jedoch zunächst `PolicyObservation`-Vorstufen. Erst eine vollständig nachvollziehbare Evaluation darf ein kanonisches Finding erzeugen.
|
||
|
||
Der Browser erhält keine Datenbank- oder Dateisystemberechtigung. Der Server schreibt angenommene Originalpakete über zufällige Speicher-IDs, private Staging-/Objektbereiche und Integritätsprüfungen; der konfigurierte beziehungsweise lokale Standardroot wird gegen den statischen Webroot validiert. Der projektgebundene Endpunkt gibt ausschließlich opake Artefakt-/Job-IDs, Hash, Größe und Queuezustand zurück. Der dedizierte Backend-Worker darf Inhalte ausschließlich nach vollständiger Strukturprüfung begrenzt im Speicher entpacken, um Ist-Größe, CRC und SHA-256 zu verifizieren. Große zulässige Umschläge werden über eine eigene übertragene Bytekopie statt per Structured Clone gestartet; Standardgrenzen von 1.024 MB Old Generation und 128 MB Young Generation bleiben konfigurierbar und hart begrenzt. GPO-Metadaten- und Preference-Parser schließen jedes JSDOM-Fenster garantiert; der Worker überträgt keine Parser-Zwischenmodelle, sondern nur Diagnosen und persistierbare Backupinstanzen.
|
||
|
||
Die Browserordnerauswahl ist ausschließlich eine Transportfunktion und keine zusätzliche fachliche Parsergrenze. Relative Browserpfade werden vor dem Lesen kanonisiert, auf Unicode-/Case-Kollisionen geprüft und gemeinsam mit Anzahl und Größen begrenzt. Der unkomprimierte Umschlag vermeidet eine clientseitige Dekompressionsannahme; der Backend-Worker behandelt ihn trotzdem vollständig als nicht vertrauenswürdigen Container und prüft Pfade, Header, Größen, CRC und Hash erneut. Leere Verzeichnisse besitzen keine Policysemantik und werden vom Browser nicht übertragen.
|
||
|
||
## Sichere Umsetzungsreihenfolge
|
||
|
||
1. Bedrohungsmodell und Aufbewahrungsgrenze festlegen.
|
||
2. Sichere Pfadkanonisierung sowie Backup-, Inventar-, Snapshot- und Vollständigkeitsverträge implementieren.
|
||
3. Container ausschließlich in ein geprüftes Inventar überführen; noch keine Policybewertung.
|
||
4. Artefaktparser und CSE-spezifische Reducer einzeln ergänzen.
|
||
5. Technische Identitäten, freigegebene Baselines, Comparatoren und Consensus implementieren.
|
||
6. Erst danach Finding Factory, API, UI und Reprocessing anbinden.
|
||
|
||
## Verifizierter Implementierungsstand
|
||
|
||
Der aktuelle Schnitt modelliert technische Identität, Domäne, explizite Backup-Set-Mitgliedschaft, Erhebungszeit, Abschnittsstatus, Artefaktinventar und Snapshotkonsistenz. Die Chrome-Ordnerauswahl erzeugt aus höchstens 20.000 Einträgen und höchstens 100 MB einen deterministischen, unkomprimierten Transportumschlag; Pfadnormalisierung, Kollisionsprüfung und Byteerhaltung sind synthetisch verifiziert. Der GPO-Worker prüft dessen ZIP-Struktur, Pfade, Typen, tatsächliche Größen, Kompressionsverhältnisse, CRC und SHA-256 und liest ausgewählte Metadaten erst nach vollständiger Verifikation. Der XML-Metadatenparser trennt GPO- und Backup-GUID, Domäne und Sicherungszeit ausschließlich aus Inhalten, lehnt externe Referenzen sowie widersprüchliche oder gemischt gültige Felder fail-closed ab und meldet mögliche `cpassword`-Vorkommen ohne Wert. Backupinstanzen benötigen Metadaten- und SYSVOL-Evidenz derselben Wurzel; Backupsatz, Zielkontext, Vollständigkeit und Wirksamkeit werden nicht erfunden. Die projektgebundene Submission prüft vor Aufbewahrung, speichert Originale mit `secret`-Sensitivität und erzeugt einen persistenten `analyze-gpo-backup`-Job. Status-API und Mandantenansicht leiten `queued`, `running`, `succeeded`, `partial`, `dead-letter` oder `recovery-required` ausschließlich aus persistenten Artefakt-, Job- und Processingdaten ab; Versuche, Fehlercode, Zeitpunkte und die Zahl der im einen Mandanten-Backup-Snapshot erkannten GPOs bleiben nach Navigation und Neustart sichtbar. Der Lease-basierte Runner liest das projektgebundene Original erneut mit Integritätsprüfung, persistiert Processing Run und Backupinstanzen über eine atomare Repositorygrenze und schließt den Job erst danach ab. Deterministische IDs machen Crash-Retries revisionsneutral, während abweichende Historie abgelehnt wird; Migrationen 004 bis 006 sind PostgreSQL-verifiziert. Dead-Letter-Retry ohne Reupload sowie bestätigtes Löschen mit persistenter, crashsicher wiederaufnehmbarer Lösch-Outbox sind in derselben Mandantenansicht verfügbar. Security Templates, Advanced Audit Policy, Registry Preferences, Local Users and Groups, Services und Drive Maps besitzen validierte PolicyObservation-Verträge und eigene versionierte Reducer; alle Beobachtungen werden in der unveränderlichen Backupinstanz mitpersistiert. Ein synthetischer Lastlauf mit 1.740 Dateien, 80.186.702 Bytes und 300 Backupinstanzen ist unter der produktiven 1-GB-Workergrenze erfolgreich. Weitere Preference-CSEs, stabile Policy-Identitäten, weitere Reducer und Policybewertung bleiben offen.
|
||
|
||
Der neue technische Identity-Resolver bildet einzelne Registry-Wert- und Registry-Schluesselziele stabil aus Scope, Hive und case-insensitiv kanonisiertem Ziel; ADMX-Zielnamespace, Policy-Name und Element-ID werden nur als optionale Metadatenreferenz gebunden, ADML-Texte nie als Identitaet. Der Microsoft-Baselineadapter prueft den ZIP-Container strukturell, laesst Dokumente und Skripte opak und entpackt nur Backup.xml, Registry.pol, ADMX und ADML mit Integritaets- und Ressourcenpruefung. Alle Registry.pol-Inhalte laufen durch denselben Parser und Reducer wie Kundenbackups. Der freigegebene Referenzbestand wurde ohne Persistenzmutation technisch verifiziert: 11/11 Pakete, 79 GPO-Backups, 89 Registry.pol-Dateien, 3.580 stabile technische Einstellungen und 185 eindeutige Zuordnungen zu den mitgelieferten ergaenzenden ADMX-Definitionen. Weil vollstaendige Windows-Inbox-ADMX-Kataloge fehlen, bleibt jede Paketanalyse korrekt partial.
|
||
|
||
Der `Registry.pol`-Pfad ist als versionierter, begrenzter read-only PReg-Parser im vorhandenen GPO-Worker implementiert. Er bewahrt die Reihenfolge und Byteoffset-Provenienz technischer Set-, Delete-, SecureKey-, Soft- und Schluesselanlage-Instruktionen; Datentypen ausserhalb des freigegebenen Satzes und ungueltige Strukturen blockieren fail-closed. Der unveraenderte freigegebene Mandantenbestand wurde ohne neue Processing- oder Persistenzschreibvorgaenge technisch verifiziert: ein hash- und groessenrichtiges Quellartefakt, drei Backups, eine unterstuetzte `Registry.pol`-Datei, vier Registry-Policy-Beobachtungen und keine Worker- oder Blockierungsfehler.
|
||
|
||
Reale, ausdruecklich freigegebene GPMC-Backups wurden am 2026-08-04 erstmals durch den Produktionspfad verifiziert. Synchron geworfene Parserablehnungen werden nun als strukturierte Diagnosen zurueckgegeben. Lokale GPMC-Sicherungszeiten ohne Offset bleiben mit unbekannter Zeitzone `partial`, ohne separat belegte Identitaet oder Domaene zu verwerfen. Der freigegebene Dummy-Upload ist ein ausgewaehlter Mandanten-GPO-Backup-Snapshot mit drei aufgeloesten enthaltenen GPOs, drei vollstaendigen Einzel-GPO-Inventaren und 47 Policy-Beobachtungen und wurde mit persistentem Status `partial` gespeichert; eine fachfremde XLSX im Auswahlroot blieb als verschachteltes Archiv fail-closed ausgeschlossen. Der lokale Rohartefaktspeicher ist wegen fehlender Hardlink-Unterstuetzung des synchronisierten Workspace-Dateisystems explizit auf einen privaten NTFS-Pfad ausserhalb des Webroots konfiguriert.
|
||
Ein ausgewaehlter Hauptordner definiert genau einen Mandanten-GPO-Backup-Snapshot. Alle darunter erkannten GPO-Wurzeln erhalten dieselbe Backup-Set-ID mit Scope selected-gpos und Evidenz user-selection; sie werden gemeinsam aggregiert. Diese Gruppierung belegt weder einen vollstaendigen Domaenenexport noch konkrete Verknuepfung oder tatsaechliche Wirksamkeit. Bereits persistierte technische Einzel-GPO-Datensaetze ohne Set-ID werden lesekompatibel ueber ihr gemeinsames Quellartefakt zu demselben ausgewaehlten Snapshot gruppiert und nicht umgeschrieben.
|
||
|
||
|
||
|
||
Der Datahub haelt persistente GPO-Artefakte ausschliesslich im getrennten Bereich GPO Processing; Inventarisierungs-, Job- und Parserstatus werden weder als Scanbericht noch im Berichtzaehler projiziert. Linked Scan Reports nimmt GPO-bezogene Daten erst auf, wenn ein persistierter Baseline-Evaluation-Run mit fachlichen Ergebnissen existiert. Migration 011 speichert den globalen Microsoft-Security-Baselinekatalog; Original-ZIPs liegen unveraendert im privaten Artefaktspeicher und bleiben in der Reconciliation referenziert. Migration 012 speichert erkannte Paketklassifikationen unveraenderlich und versioniert. Ein Paket darf mehrere Produktkontexte besitzen, etwa Windows 10 und Windows Server; die automatische Paketauswahl ist nur bei genau einer Uebereinstimmung von Produktfamilie, Produktversion, Rolle und Scope zulaessig. Der Katalog ist damit die Eingangs- und Auswahlgrenze fuer die spaetere Evaluation. Stabile technische Registry-Zielidentitaet, versionierter ADMX-/ADML-Metadatenkatalog und read-only Registry.pol-Baselineanalyse sind implementiert; persistente Worker-/Repository-Anbindung, vollstaendige freigegebene Inbox-ADMX-Kataloge und Comparatoren fehlen weiterhin, daher wird noch kein Policyvergleich behauptet.
|
||
|
||
Die 11 vom Nutzer freigegebenen Originalpakete wurden am 2026-08-04 gegen den laufenden PostgreSQL-Katalog geprueft: alle SHA-256-Werte stimmen bytegenau ueberein, alle Pakete enthalten GPO-Strukturen, und Detektorversion `microsoft-baseline-filename-v2` bildet kombinierte Pakete als mehrere Produktkontexte ab. Die reale Auswahlpruefung fuer Windows Server 2016, Windows 10 1809, Windows Server 20H2 und Microsoft 365 Apps 2512 lieferte jeweils genau das erwartete Paket.
|