85 lines
19 KiB
Markdown
85 lines
19 KiB
Markdown
# GPO-/Baselineanalyse – Bedrohungsmodell und Speichergrenze
|
||
|
||
Stand: 2026-08-04
|
||
Phase: 13B, verifiziert bis zum Registry.pol-Parser sowie zur Job- und Ergebnispersistenz
|
||
|
||
## 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
|
||
|
||
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. |
|
||
| Pfad-/Namensheuristik erzeugt falsche Policy- oder Zielidentität | Technische IDs ausschließlich aus unterstützten Artefaktinhalten und versionierten Regeln; Namen und Pfade bleiben Provenienz. |
|
||
| 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
|
||
|
||
- 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.
|
||
- 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.
|
||
|
||
|