Assessor_2.0/docs/CLIENT_INFORMATION.md

106 lines
16 KiB
Markdown

# Client Information
Stand: 2026-10-04. Core capability seit ASSESSOR 2.14.0; Cloud-Uebersicht 2.14.2, read contract 1.1.0.
Client Information bezeichnet die bisher als scannerbezogene Zusatzinformationen behandelten Beobachtungen und Original-Berichtsabschnitte. Der vorhandene Bestand bleibt in `EnvironmentObservation` und `ScannerReportSection` gespeichert. Es gibt keine neue Datenbank, Tabelle, Migration oder zweite Kopie des Bestands. Bestehende Namen auf Persistenzebene bleiben kompatibel. Die technischen Einzelbefundfelder im Finding Reader unter Additional Information und die Stammdaten Name/Consultant sind andere bestehende Funktionen.
## Gezielter Abruf
Aktuelle Korrektur 2.14.2: Die unten historisch dokumentierten Verfuegbarkeitshinweise der Cloud-Kachel sind durch konkrete berichtete Werte bzw. `Not reported` ersetzt. Details und Grenzen stehen unter **Konkrete Cloud-Uebersicht**; die permanente Sichtbarkeit und der Results-Scope bleiben verbindlich.
Client Info besitzt den Button **Client Information**. Er oeffnet das gemeinsame Datenfenster fuer den ausgewaehlten Mandanten und die ausgewaehlten Scanlaeufe. Erst beim Oeffnen beginnt die Abfrage. Bereich, Freitext, exakter Eigenschaftsschluessel und exakte Objektidentitaet schraenken die Ergebnisse ein. Details zeigen den kompletten Originalwert, Erfassungszustand, Erfassungszeit (falls von der Quelle angegeben), Datei, Scanlauf, Quellposition und Mapping-Metadaten. Vorhandene Quellabschnitte behalten ihre Tabellen und Verweise. Apply und Reset wirken nur auf diese Abfrage, nicht auf Work.
Nutzerentscheidung 2026-10-04, umgesetzt ab 2.14.1: Die zusaetzliche **Cloud Information**-Kachel in der bestehenden Umgebungskachelreihe ist immer sichtbar, auch ohne Cloud-Nachweise. Ihre vier Felder zeigen die Verfuegbarkeit von Quellnachweisen fuer Sign-in/Conditional Access, Rollen/Berechtigungen, Application consent und externen Zugriff/Sharing. `No retained information` kennzeichnet fehlende Nachweise; `Source evidence not assessed` kennzeichnet vorhandene, nicht als beobachtet erfasste Nachweise. Keiner dieser Texte leitet aus einem Teststatus eine konkrete Konfiguration ab. Results oeffnet denselben Client-Information-Browser, eingeschraenkt auf die vier Cloud-Bereiche; Bereichsauswahl und Reset bleiben innerhalb dieses Cloud-Scope. Ohne gespeicherten Mandanten zeigt Results den bestehenden leeren Quellenhinweis, ohne eine API-Abfrage zu erfinden. Die immer sichtbare Kachel ersetzt die zuvor vorgeschlagene Bedingung, sie nur bei vorhandenen Cloud-Daten einzublenden.
Der Jetzt-Zustand ist der aktuelle **importierte** Bestand im gewaehlten Scope. Er ist kein Liveinventar. Ohne explizite Zeitraumauswahl bedeutet die API alle nicht ersetzten Importlaeufe des Mandanten, nicht automatisch den zeitlich letzten Timeslot. Unterschiedliche Quellen, widerspruechliche Werte und fehlende Zeitangaben werden nicht zu einem vermeintlich eindeutigen aktuellen Wert verschmolzen.
HTTP: `GET /api/v1/projects/{projectId}/client-information`
| Parameter | Bedeutung |
| --- | --- |
| `assessmentId` | Optionaler Timeslot, muss zum Mandanten gehoeren |
| `scanRunIds` | Exakte Scanlaeufe; wiederholter Parameter |
| `includeSuperseded` | Standard `false`; `true` erlaubt auch ersetzte historische Importlaeufe |
| `areas` | Fachliche Bereiche, wiederholbar |
| `properties` | Exakte Eigenschaftsschluessel, wiederholbar |
| `subjectTypes`, `subjectIds` | Exakter Objekttyp / Quellidentitaet, wiederholbar |
| `toolIds`, `states` | Exakte Scanner-ID / Erfassungszustaende, wiederholbar |
| `search` | Teiltext in Quellwert, Label, Eigenschaft, Objekt; bei Abschnitten auch Text/Tabellen |
| `offset`, `limit` | Beobachtungsseite; Standard 0/50, maximal 200 pro Seite |
| `sectionOffset`, `sectionLimit` | Seite primaerer Quellabschnitte; Standard 0/10, maximal 50 |
Selektoren einer Liste werden mit ODER, verschiedene Listen mit UND verknuepft. Fehlende oder leere Listen beschraenken nicht. Erlaubt sind maximal 100 Eintraege pro Liste und 500 Zeichen pro Eintrag oder Suchtext. Unbekannte Parameter/Bereiche/Zustaende, ungueltige Seitengroessen, doppelte skalare HTTP-Parameter und fremde Mandanten-/Timeslot-/Scan-Zuordnungen werden abgewiesen.
Bereichsschluessel: `directory`, `inventory`, `resilience`, `password-policy`, `certificates`, `cloud-access`, `cloud-roles`, `cloud-apps`, `cloud-sharing`, `source-metadata`, `other`. Die Zuordnung nutzt deklarierte Importmetadaten oder stabile Eigenschafts-/Objekt-/Abschnittsschluessel; keine Bewertung aus Ueberschriften.
Beispiel: `/api/v1/projects/synthetic-client/client-information?assessmentId=synthetic-slot&properties=domain.fqdn&limit=50`.
Die Antwort erhaelt den Snapshot mit `contractVersion`, `purpose: internal-analysis`, `repositoryRevision`, `scopeMode`, getrennten Gesamtsummen und Seitengrenzen. `coverage` beschreibt den vollstaendigen gefilterten Bestand, nicht nur die Seite. Beobachtungen sind nach property/id, Abschnitte nach ordinal/id sortiert. Passende Originalabschnitte bleiben vollstaendig; sie koennen weitere Werte enthalten als die ausgewaehlten Beobachtungen. Exakte, eindeutige Linkziele derselben Datei und desselben Laufs werden auch ueber Seitengrenzen mitgeliefert und in `linkedSectionIds` benannt. Sie zaehlen nicht zur primaeren Seitengroesse. Mehrdeutige Ziele werden nicht geraten.
Bei mehreren Seiten `repositoryRevision` vergleichen. Aendert sie sich, die Seitenauswahl neu beginnen; die API stellt keinen dauerhaft reservierten Snapshot-Token bereit. Jede einzelne Abfrage prueft die committed Revision vor und nach dem Lesen und wiederholt bei Aenderung hoechstens dreimal, danach folgt ein Konfliktfehler. PostgreSQL liest dafuer die Datenbankrevision, nicht nur den lokalen Prozesscache. Historischer Abruf liefert erhaltene Importbeobachtungen, keine zeitpunktbezogene Rekonstruktion geloeschter Daten oder alter Repository-Revisionen.
## Read-only-Port fuer Engines
Der veroeffentlichte Vertrag ist `src/persistence/client-information-read-port.ts` (`ClientInformationReadPort`). UI/API und spaetere Engines nutzen `queryClientInformation` mit demselben `ClientInformationQuery` aus `src/domain/client-information.ts`.
Die Backend-Komposition bindet den Port an eine **read-only** Repository-/Datenbanksitzung und reicht nur den eingefrorenen Port an die Engine weiter:
```ts
const port = clientInformationReadPortFrom(readOnlyRepository,
() => readOnlyRepository.getCommittedRevision());
const information = await port.queryClientInformation({
projectId, assessmentId, scanRunIds,
areas: ['cloud-access'], limit: 100
});
```
Das ist Kompositionscode, kein direkter Repository-/Tabellenzugriff aus einer Engine. Engines bekommen keine Mutationsmethoden. Die Rueckgabe ist eine unabhaengige Kopie; Veraenderungen durch einen Leser veraendern den Core nicht. Optionalen Engines ausgeschaltet zu lassen hat keinen Einfluss auf diese Core-Funktion. Bestehende Context-/Report-Ports bleiben kompatibel und werden nicht still auf neue Inputs umgestellt.
Diese Daten dienen interner Analyse. Der Port ist keine Result-DB- oder Exportfreigabe. Was eine Engine anzeigt oder exportiert, muss weiter die bestehenden Disclosure- und Datenschutzregeln durchlaufen. Cloud-Testnachweise werden nicht als neue Result-DB-Zeilen oder Findings veroeffentlicht. Der neue Port fuegt keine Bewertung, Prioritaet oder Scoreberechnung hinzu.
## Neuer fachlicher Mehrwert und Grenzen
| Quelle | Bereits vorhandener Bestand | Neu in dieser Umsetzung |
| --- | --- | --- |
| PingCastle | Directory, Inventar, Resilienz, Kennwortrichtlinien, PKI und erhaltene Originaltabellen | Gezielter einheitlicher Zugriff; keine doppelte AD-Extraktion |
| Purple Knight | Bereits erhaltene Assessment-/Reportinformationen | Derselbe Zugriff auf den vorhandenen Bestand |
| CIS-CAT | Bereits erhaltene Host-/Benchmark-/Berichtsinformationen | Derselbe Zugriff auf den vorhandenen Bestand |
| Maester | Tenant, Reportmetadaten und Testzaehler | Erhaltene Detailnachweise zu Anmeldung/Conditional Access, Rollen, App-Zustimmung und externem Zugriff/Sharing separat auffindbar |
| Andere Profile | Nur tatsaechlich bereits erzeugte Beobachtungen/Abschnitte | Gemeinsamer Zugriff; keine behauptete neue Quellabdeckung |
Maester HTML (`ResultDetail.TestResult`) sowie Excel/CSV mit exakter bekannter Regel-ID und getrennten Status-/Detailspalten werden erweitert. CSV `Result` plus `ResultDetail` und Excel/CSV `Status` plus `Result` werden unterstuetzt. Die generische Tabellenpipeline verarbeitet weiterhin saemtliche Zeilen. JSON/XML und beliebige unbekannte Exportspalten erhalten durch diesen Schritt keine neue Cloud-Semantik.
Die Eigenschaften haben die Form `cloud.<group>.<native-id-in-lowercase>.reported_evidence`; etwa `cloud.authentication.eidsca.af01.reported_evidence`. Der vollstaendige Originaltext bleibt unveraendert; enthaltene Markdown-Tabellen werden als Originalbelege mitgefuehrt. Metadaten nennen `informationKind: reported-test-evidence`, `inventoryComplete: false`, Regel-ID, Quellstatus und Mapping-Version. Dies sind die vom jeweiligen Test berichteten Informationen, **kein vollstaendiges Konfigurationsinventar** und keine Ermittlung der effektiv wirksamen Richtlinie. Ein nativer Teststatus allein erzeugt keinen Konfigurationswert. Nicht ausgefuehrte/fehlerhafte Tests mit Detailtext bleiben `not-assessed`; fehlende Nachweise werden nicht zu `false` oder `0`.
Exakte freigegebene IDs der Version 1.0.0:
- Authentication: EIDSCA.AF01-06, AG01-03, AM01-04, AM06-07, AM09-10, AP01, AS04, AT01-02, AV01 (jeweils Praefix EIDSCA.).
- Conditional Access: MT.1001, MT.1003-1021, MT.1035, MT.1036, MT.1038.
- Rollen: MT.1025-1032; CISA.MS.AAD.7.1-7.6.
- Zustimmung: EIDSCA.AP08-10, CP01, CP03-04, CR01-04; CISA.MS.AAD.5.1-5.4.
- Externer Zugriff/Sharing: EIDSCA.AP04, AP07, ST08, ST09; CISA.MS.SHAREPOINT.1.1-1.3, 2.1-2.2, 3.1-3.3.
Die genaue Liste steht deklarativ im Importmodul; Titel-/Aehnlichkeitssuche erweitert sie nicht. Quellpruefung 2026-10-04: offizieller [Maester-Testkatalog](https://maester.dev/docs/tests/), exemplarisch [EIDSCA.AF01](https://maester.dev/docs/tests/EIDSCA.AF01/), [MT.1005](https://maester.dev/docs/tests/MT.1005/) und [MT.1032](https://maester.dev/docs/tests/MT.1032/). Offline-Zusammenfassung der fachlichen Zuordnung: Der Katalog ordnet diese IDs Tests fuer Authentifizierungsmethoden, Conditional Access, privilegierte Rollen, Zustimmungseinstellungen und Gast-/Sharing-Einstellungen zu. Er garantiert keine vollstaendige Konfiguration im Export; allein die tatsaechlich enthaltenen Originalwerte sind massgeblich. Kein Onlineaufruf ist fuer Import oder Abfrage erforderlich.
Das Maester-Profil wird auf 1.2.0 und der HTML-Extractor auf 1.2.0 angehoben, der Tabellen-Extractor startet mit 1.0.0. Der historische Verarbeitungsmanifest bleibt erhalten, der Vergleichsschluessel unveraendert. Fruehere Maester-Importe empfehlen regulaeren Reimport. Es erfolgt kein automatischer Kunden-Reimport. Supported Maester reports enthalten weiterhin keinen nutzbaren nativen numerischen Overall Score; der deklarierte Grund und die gemeinsame Fallback-Scoringlogik bleiben unveraendert.
## Verifikation und verbleibende Grenzen
### Konkrete Cloud-Uebersicht (2026-10-04, 2.14.2)
Nutzerkorrektur: Die dauerhaft sichtbare Cloud-Kachel zeigt je Bereich einen belegten Istwert statt Verfuegbarkeitshinweisen. Weitere Fakten und Originale bleiben in Results. Fehlende, nicht ausgefuehrte oder nicht eindeutig erkennbare Angaben erscheinen als `Not reported`. Konflikte werden genannt; mehrere Scan-/Tenant-Scopes werden nicht zusammengerechnet. Passed/Failed, Empfehlungen und generische Scores erzeugen keine Konfiguration.
Die reine Core-Normalisierung `cloudInformationFacts` projiziert bereits gespeicherte Maester-Testdetails. Lesevertrag **1.1.0** ergaenzt `cloudFacts` fuer den gesamten gefilterten Scope vor Pagination: kanonische Property, Original-/Anzeigewert, `reported-setting`/`reported-subset`, Beobachtungs-ID, Scanlauf, Datei, Regel-ID, Quellposition, Quellzeit und Mapping-Version. Engines lesen weiterhin ausschliesslich den veroeffentlichten read-only Port, ohne interne Module zu importieren. Propertyfilter beziehen sich weiter auf die erhaltenen Beobachtungs-Properties; `cloudFacts` enthaelt nur Fakten dieser gefilterten Beobachtungen. Es gibt keine DB-Schreibvorgaenge oder Schemaaenderung. Bereits erhaltene passende Nachweise profitieren ohne Reimport; fehlen die in 2.14.0 eingefuehrten Nachweise, ist weiter ein regulaerer Reimport erforderlich. Profil-/Extractor-Versionen und nativer Scorevertrag bleiben unveraendert.
Offline-Mapping 1.0.0, Quellpruefung 2026-10-04:
- EIDSCA.AF01/AM01/AT01/AV01: State von FIDO2, Authenticator, Temporary Access Pass und Voice. AP08/CR01/AP10: Consent-Policy, Admin-Request-State, App-Registrierung. AP04/AP07/ST08/ST09: Gast-Einladungen, Gastrolle, Gruppenbesitz/-Zugriff. Exakte native erste Saetze liefern den berichteten Wert, einschliesslich ausdruecklich nicht konfigurierter Angaben und des kombinierten Ist-/Sollwertsatzes. Alternativ ist nur eine eindeutige zweispaltige `Setting`/`Actual Value`-Tabelle fuer das exakt benannte Feld erlaubt, nie `Expected Value`.
- CISA.MS.AAD.7.4: exakte Tabelle `Role / Principal Type / Display Name / Status` mit `No Expiration` oder expliziter Satz ueber keine entsprechenden Zuweisungen. MT.1025-1028: Anzahl exakt berichteter Listenzeilen fuer den jeweiligen Principal-Typ. Diese Zahlen beschreiben nur die berichtete Pruefteilmenge. MT.1031: expliziter PIM-Management-Satz; derselbe Helper-Satz unter MT.1032 erzeugt keine PIM-Aussage.
- MT.1007: eindeutige berichtete All-User-MFA-Policy-Links oder expliziter Satz ueber keine entsprechende Policy. Keine Gesamtzahl aktiver/Report-only-Policies. CISA.MS.SHAREPOINT.1.1: nur ausdruecklicher `Current setting`-Wert.
Offizielle Quellen: [EIDSCA-Generator AF01](https://github.com/maester365/maester/blob/main/powershell/internal/eidsca/Test-MtEidscaAF01.ps1) und entsprechende AP08/AP07/CR01-Generatoren im selben Verzeichnis; [permanente Rollen](https://github.com/maester365/maester/blob/main/powershell/public/cisa/entra/Test-MtCisaPermanentRoleAssignment.ps1), [privilegierte Zuweisungen](https://github.com/maester365/maester/blob/main/powershell/public/maester/entra/Test-MtPrivPermanentDirectoryRole.ps1), [PIM-Alerts](https://github.com/maester365/maester/blob/main/powershell/public/maester/entra/Test-MtPimAlertsExists.ps1), [All-User MFA](https://github.com/maester365/maester/blob/main/powershell/public/maester/entra/Test-MtCaMfaForAllUsers.ps1), [Graph-Markdown](https://github.com/maester365/maester/blob/main/powershell/internal/Get-GraphObjectMarkdown.ps1), [SharePoint Sharing](https://github.com/maester365/maester/blob/main/powershell/public/cisa/spo/Test-MtCisaSpoSharing.ps1). Microsoft beschreibt die bekannten [Consent-Policies](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent) und [Gastrollen](https://learn.microsoft.com/en-us/entra/identity/users/users-restrict-guest-permissions). Das Mapping kuerzt deren Anzeige; exakte Originalwerte bleiben im Vertrag und in Results. Keine Online-Abfrage zur Laufzeit.
Synthetische Tests decken alle drei erweiterten Formate, Originalwerte/Tabellen/Quellpositionen, unbekannte IDs, fehlende/bare Statusnachweise, Error/Skipped, false/0/Leerwerte, Konflikte, Pagination/Links, Mandanten-/Timeslotgrenzen, explizite Historie, konkurrierende Revisionen, read-only PostgreSQL-SQL, HTTP-Validierung und den tatsaechlichen Client-Info-Button ab. UI-Pruefungen umfassen beide Themes, Apply/Reset, Fehler/Retry, spaete Antworten und ausgeschaltete Engines. Keine Kundenberichte oder Kundendaten wurden fuer diese Implementierungspruefung gelesen.
Filterung erfolgt derzeit ueber den vorhandenen scoped Snapshot im Backend. Es gibt keine SQL-Filterindizes oder serverseitige Stream-Pagination; sehr grosse Scopes koennen deshalb trotz begrenzter Antwortseiten Arbeitsspeicher beanspruchen. Vollstaendige Cloud-Inventare aus weiteren echten Exportstrukturen erfordern eine gesonderte, quellengestuetzte Profilerweiterung und bleiben offen.