Assessor_2.0/docs/GPO_BASELINE_EVALUATION.md

GPO-Backup-Vergleich mit Baselinevarianten

Stand: 2026-09-16 · Phase 7/13B · Evaluator policy-baseline-evaluation@1.9.0

Prüfgegenstand

Geprüft wird die importierte GPO-Backup-Konfiguration gegen die ausdrücklich referenzierten Microsoft-Baselineanalysen. Das ist kein Nachweis der effektiv angewendeten Gerätekonfiguration, der Erreichbarkeit eines Dienstes oder einer tatsächlich ausnutzbaren Überprivilegierung. Baselinepakete bleiben getrennte Prüfungen; ein Ergebnis gilt nicht automatisch für andere Pakete, Betriebssysteme oder Rollen.

Ein PingCastle-Scan ist keine Voraussetzung. OS-Inventar und Domain Functional Level dürfen eine einzelne GPO weder automatisch einer Zielrolle zuordnen noch ihre Anwendung beweisen. Die vorhandene Vorlagenauswahl akzeptiert nur einen eindeutigen, expliziten Vergleichskontext; beobachtungsgebundene Inventarkontexte wählen keine Rolle aus. Unbekannte Vorlagen bleiben Kandidaten. Eine explizite Auswahl ohne passende Vorlage bleibt ungeklärt.

Operativer Scope und Score

Die normale GPO-Analyse ist auf Fehlkonfigurationen innerhalb des tatsächlich konfigurierten, technisch vergleichbaren und ausdrücklich anwendbaren Kundenscopes begrenzt. Eine fehlende Microsoft-Empfehlung bleibt als Not configured transparent sichtbar, erzeugt aber weder ein operatives Finding noch eine Standard-Remediation oder einen Scoreabzug. Die vollständige Einführung einer Microsoft-Baseline ist ein eigener, ausdrücklich beauftragter Hardening-Scope.

Präzisierung vom selben Tag: Not configured bleibt ein score-neutrales Policy-Urteil. Duplicates und Conflicts bleiben eigenständige Diagnosekategorien der technischen Policy-Einstellung, sind aber keine alternativen Urteile, die Pass, Fail oder Review required verdecken. Die Mitgliedsvergleiche werden genau einmal je technischer Policy-Identität zusammengeführt: Weicht mindestens ein konfigurierter, eindeutig vergleichbarer In-Scope-Wert nachweislich ab, lautet das Gesamturteil der Policy-Einstellung Fail; Conflict-/Duplicate-Merkmale bleiben zusätzlich sichtbar. Bestehen alle anwendbaren Mitglieder, lautet das Urteil Pass. Sind Anwendbarkeit, Vorrang oder Vergleich ungeklärt, bleibt das Urteil Review required. Mehrere Quellzeilen, doppelte Vorkommen und Diagnosemarker vervielfachen den Scorebeitrag nicht.

Der GPO-Score ist deshalb ausschließlich als Konformität der konfigurierten, vergleichbaren In-Scope-Einstellungen zu bezeichnen. Er ist kein Nachweis vollständiger Microsoft-Baseline-Umsetzung oder -Abdeckung.

Entscheidungsvertrag

Jede berücksichtigte Vorlage wird für dieselbe aufgelöste technische Einstellung einschließlich Computer-/Benutzerbereich einzeln verglichen. Der neutrale Vergleich verwendet exakte, typisierte Gleichheit. Bei Kontenlisten ist die Reihenfolge unerheblich; Originalwerte bleiben erhalten. Registrytypen und die Reihenfolge von REG_MULTI_SZ bleiben relevant. Abweichend bedeutet hier nicht automatisch schwächer: Eine gesonderte fachliche Regel wäre nötig, um eine strengere Einstellung als zulässig zu behandeln.

Nachgewiesener Zustand	Ergebnis in Work
Konfiguriertes IST erfüllt jede berücksichtigte Variante	Pass
Konfiguriertes IST weicht von jeder berücksichtigten Variante ab	Fail / Filter Deviation
Einzelurteile widersprechen sich	Review required
Wertvergleich, Kandidatenabdeckung oder explizite Anwendbarkeit ist ungeklärt	Review required
Empfohlenes Setting besitzt im analysierten Backupsatz keinen beobachteten konfigurierten Wert	Not configured; score-neutral
Der analysierte Backupsatz ist nur ein ausgewählter Teilbestand	Not configured mit Scope-Diagnose; keine behauptete Abwesenheit in Domäne oder effektivem Gerätezustand
Für die technische Einstellung existiert überhaupt kein Baselinewert	Kein erfundener Pass-/Fail-Vergleich

Verbindliche Registry-Zustandsregeln

Registry.pol-Anweisungen sind Sollzustände und keine fehlenden Baselinewerte. Innerhalb des analysierten Backup-Sets gelten deshalb folgende Regeln; sie behaupten weiterhin keinen effektiven Registry-Zustand auf einem Gerät:

Baseline-Sollzustand	Zustand im analysierten Kunden-Backup	Urteil
Einzelnen Wert löschen	Zielwert nicht konfiguriert oder ausdrücklich gelöscht	Pass
Einzelnen Wert löschen	Zielwert wird gesetzt	Fail
Alle Werte eines Schlüssels löschen	Kein Wert für das Schlüsselziel konfiguriert oder ausdrückliche Delete-all-Anweisung	Pass
Alle Werte eines Schlüssels löschen	Ein Wert für das Schlüsselziel wird gesetzt	Fail
Schlüssel anlegen	Schlüsselanlage ist konfiguriert	Pass
Schlüssel anlegen	Schlüsselanlage fehlt	Fail
Typisierten leeren Text setzen	Wert existiert mit identischem Registrytyp und Inhalt ""	Pass
Typisierten leeren Text setzen	Wert fehlt, besitzt einen anderen Typ oder ist nicht leer	Fail

Ein leerer REG_SZ- oder REG_EXPAND_SZ-Inhalt ist damit ein expliziter Wert und niemals allein wegen seiner Länge „Baselinewert nicht verfügbar“. Delete-, Delete-all- und Create-key-Anweisungen erhalten einen typisierten Registry-Zustand (absent, key-empty, key-present) in der gespeicherten Vergleichsevidenz. Andere Sonderoperationen bleiben fail-closed Review required, bis ihre Semantik separat vereinbart und getestet ist.

Einträge außerhalb der Vereinigung aller erlaubten Kontenlisten weichen zwangsläufig von jeder dieser Varianten ab. Die Vereinigung ist dennoch kein neuer Sollwert. Auch innerhalb der Vereinigung ist bei exaktem Vergleich ein Fail möglich, wenn keine einzelne Variante vollständig erfüllt wird. Ein Treffer bei nur einer von mehreren widersprüchlichen Varianten ist kein Gesamt-Pass.

Eine fehlende oder unlesbare Variante neben vorhandenen Empfehlungen wird nicht herausgefiltert, um Einigkeit herzustellen. Strukturell unvollständige oder nicht erklärbar partielle Baselineanalysen blockieren das Gesamturteil. Partielle Diagnosen werden auf den betroffenen Bereitstellungsmechanismus begrenzt: Eine fehlerhafte Security-Template-Zeile blockiert keinen separat technisch aufgelösten Registry-Policy-Vergleich. Für eine Security-Template-Einstellung bleibt dieselbe Diagnose dagegen ein Blocker. Nicht unterstützte Sektionen besitzen keine vergleichbare Identität und bleiben als Abdeckungslücke am Lauf sichtbar, ohne einen unabhängigen aufgelösten Wert zu entwerten. Ausschließlich fehlende/mehrdeutige ADMX-Metadaten blockieren ebenfalls keine bereits technisch aufgelösten nativen Werte; die Diagnose bleibt erhalten.

Dasselbe gilt für explizit bekannte, wertunabhängige Metadatenlücken der Baseline: fehlende Domäne, Backupzeit oder Zeitzone. Diese Angaben belegen keine Gerätezielrolle und verändern den gelesenen Sollwert nicht. Unbekannte Diagnosen, fehlerhafte Metadatenstruktur und Identitätskonflikte werden nicht pauschal freigegeben.

Mehrere widersprüchliche Einträge derselben Einstellung innerhalb derselben Baseline-GPO sind keine unabhängigen Rollenvarianten. Ohne eindeutig reduzierte Empfehlung bleibt dieser Fall Review required, auch wenn das IST von sämtlichen Einzelwerten abweicht.

Unterschiedliche Baselineempfehlungen sind kein Kunden-GPO-Konflikt. Die bestehende Kundenquellenprüfung für Conflicts und Duplicates wird durch diese Änderung nicht neu definiert. Ihr Nachweis behauptet ebenfalls keine effektive Anwendung. Review required bleibt in Work unter All sichtbar; das verbindliche GPO-Statusmenü bleibt unverändert bei All, Deviation, Passed, Not configured, Conflicts und Duplicates. Eine Risikoakzeptanz verändert dieses technische Urteil nicht.

Die spätere Nutzerpräzisierung vom 2026-09-16 ersetzt ausschließlich die frühere Interpretation score-neutraler Conflict-/Duplicate-Container: Der Container ist seit Evaluator 1.7.0 ein Diagnosemerkmal, das Policy-Gesamturteil wird separat aufgerollt. Work speichert das Urteil im Status und Conflict/Duplicate zusätzlich in den eigenen Feldern; die Statusfilter lesen diese Achsen getrennt. Dadurch kann dieselbe Zeile sowohl Deviation als auch Conflicts beziehungsweise Duplicates erfüllen, ohne einen zweiten Scorebeitrag zu erzeugen. Historische Evaluationen werden nicht rückwirkend umgedeutet.

Nachweis und Historie

Praezisierung 2026-09-18 (Work-Zeilen): Mehrere Baselinepakete fuer dieselbe technische Einstellung werden in Work zu genau einer Zeile je Projekt, Snapshotaggregation und Computer-/Benutzerbereich zusammengefasst. Diese Zeile verwendet dieselbe Urteilprioritaet wie die bestehenden Policy-Zaehler (Fail, Review required, Pass, Not configured). Die innerhalb eines Pakets gespeicherte Variantenentscheidung bleibt unveraendert; ein dort gemischter Vergleich bleibt Review required. Der Baselinefilter waehlt Mitgliedschaften dieser gemeinsamen Zeile und berechnet ihr Gesamturteil nicht aus der Filterauswahl neu. Einzelne Paketvergleiche, Settingreferenzen und unterschiedliche Sollwerte bleiben im Reader und in Result DB nachvollziehbar; es entsteht kein synthetischer gemeinsamer Sollwert. Quellen werden anhand ihrer exakten Beobachtungsidentitaet dedupliziert, rote Markierungen muessen gegen alle erhaltenen aktuellen Varianten belegt sein. Historische oder nicht verfuegbare Bewertungen erlauben keine solche Markierung.

Bestehende lokale Notizen zu frueheren Baselinezeilen bleiben im Reader unter Previous baseline-specific reviews lesbar. Uebereinstimmende Notizen werden fuer die gemeinsame Work-Zeile uebernommen; unterschiedliche Notizen werden nicht willkuerlich vereinigt. Risikoakzeptanzen werden niemals automatisch auf die gemeinsame Zeile umgehaengt. Die Projektion benoetigt weder Reimport noch Neuauswertung; gespeicherte Vergleiche und Datenbankschema bleiben unveraendert.

Jedes neue Ergebnis speichert baselineVariantAssessment Version 1 mit Prüfgrenze backup-configuration, unveränderten Kunden-/Baselinewerten, Baseline-Settingreferenzen, typisierten Einzelvergleichen, Blockierungsdiagnosen und Gesamtentscheidung. Ausgewählte Settingreferenzen und sämtliche Auswahlkandidaten bleiben getrennt; die vorhandenen Evidenzreferenzen führen zu Analyse, Datei-/Hash-/Zeilenherkunft und Kundenbeobachtungen. Die Schreibvalidierung prüft Referenzabdeckung und Konsistenz von Einzelurteilen, Gesamturteil und Klassifikation.

Ein einzelner aggregierter Baselinewert wird nur bei tatsächlich gemeinsamem Quellwert ausgegeben. Bei unterschiedlichen Werten zeigen Work, Result DB und der JSONL-Export die Einzelvarianten. Empfehlungen kombinieren niemals die Alternativen; vor einer konkreten Änderung muss die passende Vorlage feststehen.

Evaluator 1.5.0 ersetzte die pauschale Sperre aus 1.4.0 bei unterschiedlichen Baselinewerten. Evaluator 1.6.0 begrenzt globale Parserdiagnosen auf den tatsächlich betroffenen Bereitstellungsmechanismus. Evaluator 1.7.0 vergleicht die erhaltenen Mitgliedswerte eines Kundenkonflikts einzeln und rollt einen nachgewiesenen Fail auf die technische Policy-Einstellung hoch. Evaluator 1.8.0 hält gewöhnliche fehlende Empfehlungen auch in einem ausgewählten analysierten Backupsatz als Not configured filterbar und markiert die begrenzte Aussage mit policy-evaluation-customer-absence-scope-limited; eine Domänen- oder Geräteabwesenheit wird nicht behauptet. Evaluator 1.9.0 behandelt die oben vereinbarten Delete-, Delete-all-, Create-key- und typisierten Leerwert-Sollzustände als vergleichbare Baselineevidenz. Alte Läufe werden nicht umgeschrieben. 1.3.3 bis 1.8.0 bleiben historisch lesbar; die aktuelle Version hat Vorrang. Data Hub fordert über den bestehenden Versionsvergleich eine explizite Re-evaluation der erhaltenen Eingaben an. Kein Scanner-Reimport, erneuter Upload oder SQL-Schemawechsel allein wegen dieses Bewertungswechsels; fehlende/unlesbare Ursprungsevidenz bleibt gesondert zu klären.

Verifikation und Grenzen

Synthetische Regressionen prüfen zusätzliche und fehlende Konten, Treffer nur einer Variante, Übereinstimmung aller Varianten, vertauschte Kontenreihenfolge, Typunterschiede, unbekannte/fehlende/unlesbare Varianten, explizite und inventarbasierte Kontexte, fehlende Einstellungen bei vollständiger und partieller Erfassung, die vier Registry-Zustandsregeln einschließlich ihrer Work-Urteile, unveränderte Eingaben, serialisierte Evidenz, Schreibvalidierung, historische Versionsauswahl sowie Work-Filter, Guidance und gerenderte Result-DB-Details. Historische Kundendaten werden nicht automatisch neu bewertet. Die Standardprüfung ersetzt keine freigegebene Integration gegen den kanonischen PostgreSQL-Bestand und keinen RSoP-/GP-Results-Nachweis.