safetynet/docs/core-dlp-current-status.md

Windows DLP: aktuelle Abnahmegrenzen

Stand: 14. Oktober 2026. Diese Übersicht unterscheidet produktive Integration von isolierten Baustein- und Empfängertests. Das MVP ist nicht abgenommen.

Bereich	Autoritativer aktueller Nachweis	Noch erforderlich
Unveränderte Runtime	Offizielles Electron; eigener Chromium-Build abgebrochen	Ersatz der abstürzenden WebRTC-Header-Sperre erst nach vollständigem Netzwerk-Nachweis
Broker-Transport	Gepackter Production-Child mit privater IPC, authentifiziertem CONNECT, TLS-Ausstellung und scoped Pin-Helper; öffentliche Originalbytes übertragen, Geheimnisse vor Zielverbindung gesperrt	Vollständige Anbindung an den Hauptbrowser und geschützten Windows-Dienst
Signierte Regeln	Bestehende Core-Signaturprüfung, Device-Assignment, Ablauf, Widerruf, Generation und Rollback geprüft	Geschützte dauerhafte Mindestversion und vollständiger produktiver Bootstrap
Transferprüfung	Header, URLs und Multipart-Verträge; tatsächlicher Production-Child blockiert geheime PDF-Teile in JSON und Prozent-Data-URLs mit lokalem Parser	Hauptbrowser-Abnahme einschließlich aller Clipboard-/Editor-Pfade; echte Unternehmens-Scanner-Endpunkte
Downloads	Production-Child prüft Inline-PNG/PDF samt tatsächlichem Datei-Hash, sperrt Attachment bei deaktiviertem Speichern und geheimes PDF ohne PDF-Bytes; kausale Audit-Ereignisse persistiert	Hauptbrowser-SaveAs-, Blob- und Cache-Pfade
PDF	Gepaarter nativer AppContainer-/PDFium-/OCR-Test besteht: Geheimnis erkannt, null Zielverbindungen; öffentliches statisches PDF exakt übertragen	Erweiterung und ausdrücklich dokumentierte Grenzen für weitere PDF-Funktionen; finale Browser-/Installer-Abnahme
Office	Nativer AppContainer-/Broker-Test besteht für reale DOCX/XLSX: öffentliche Originalbytes übertragen; Geheimnisse in Metadaten/Hidden Sheet erkannt und ohne Zielverbindung blockiert	Weitere Office-Funktionen; komplexes PowerPoint und unbekannte Inhalte bleiben unvollständig und gesperrt
Windows-Netzwerkgrenze	Resolver- und STUN-Teilnachweise; WFP-Plan und Installer-Fehlertests. Aktueller nicht erhöhter Token kann WFP öffnen, Filterenumeration scheitert mit Access Denied (5)	Geschützter SCM-Host und Dienst-SID, Receiver-/Portübernahmeschutz, erhöhte Installation und Filter-Readback; IPv4/IPv6/UDP/TCP/Loopback/DNS-Umgehungstests
Broker-Runtime	Neunter geprüfter Payload: offizielles Node 24.21.0, 313 Dateien / 64 Quellnachweise, sechs tatsächliche Isolationsprüfungen einschließlich Management- und WFP-Module	Neuere Credential-/Policy-Änderungen erneut paketieren und prüfen; produktiven nativen Host und signierte Installation ergänzen
Auslieferung	Standalone-Payload außerhalb des Repositorys getestet; historischer Node-24.20-Nachweis bleibt erhalten	Gemeinsamer finaler Installer mit Broker, Scanner und Modellen; Fresh-System-Test
Unternehmens-Proxy	Achter gepackter Production-Child besteht HTTPS-Proxy und aktive IP-Policy mit sechs numerisch gebundenen CONNECT-Routen, ursprünglicher TLS-Hostname-Prüfung und gesperrten kodierten Geheimnissen	Hauptbrowser-/Dienst-Anbindung; PAC/system/SOCKS/NTLM/Kerberos noch nicht unterstützt
Diagnose und Audit	Bestehende Browser-Diagnostik sowie tatsächliche isolierte Broker-OTLP-Tests	Broker-Diagnostik und dauerhafte Sicherheitsereignisse im produktiven Prozesspfad; zentrale Abschaltung beibehalten

Die nächste Abnahme folgt dieser Reihenfolge: frisches gepacktes Proxy-/Download- Verhalten, geschützter Dienst samt authentifizierter Benutzeranbindung, vollständiger Hauptbrowserpfad, gemeinsamer Installer und native Netzwerk-/Clipboard-Umgehungstests. Bausteintests erlauben kein Entfernen der bestehenden WebRTC-Sperre. Management, Inspector und autorisierte OTLP-Exporte müssen vor einer Browser-EXE-Netzwerksperre über ausdrücklich erlaubte Dienstoperationen laufen; eine breite Ausnahme wäre kein Ersatz für diesen Pfad.

Konkrete Transport-Migration vor Aktivierung:

• Enrollment und Management benötigen einen im signierten Deployment gebundenen HTTPS-Origin und den bestehenden ML-DSA-87-Kanal-Pin. Das bisherige Deployment v1 enthält diese Bindung nicht; ein vom Renderer eingegebener Server darf keine allgemeine Dienst-Fetch-Berechtigung erzeugen. Versionierter Vertrag in Arbeit.
• Device-Identität, Challenge, verschlüsselte Policy/Evidence, Heartbeat, Ereignisse, Bookmarks und Library brauchen begrenzte typisierte Operationen statt beliebiger URL-/Header-/Token-Weiterleitung. Pre-Enrollment bleibt gesondert nachzuweisen.
• Browserseitige Clipboard-/AI-/manuelle Scans verwenden noch authentifiziertes Loopback-HTTP zum Inspector. Sie müssen über den Dienst laufen; bereits brokerseitig erfolgreiche Upload-Scans beweisen diese Browser-Pfade nicht.
• Große Dokumente brauchen begrenzte Chunk-Transfers oder geschützte Handles; der 2-MiB-Bootstrap und spätere 64-KiB-Frames sind keine 16-MiB-Datei-RPC.
• Autorisierte OTLP-Exporte brauchen ihren eigenen begrenzten Dienstpfad. Agentensteuerung muss vom Browser-Loopback-Listener auf authentifizierte lokale Pipes wechseln und vorhandene PQ-, Grant- und Replay-Prüfungen erhalten.

Der Dienstadapter ist unabhängig auf seine Paketauflösung geprüft: tatsächliches electron-builder File-Matching, ASAR-Erstellung/Extraktion und isolierter Modul- Load bestehen. Ausschließlich apps/network-broker/framed-channel.cjs wird als zusätzliche Browser-Abhängigkeit eingebettet, kein allgemeines Broker-Wildcard. Dies beweist keine fertig installierte Dienstverbindung.

Aktuelle Broker-Regression (ohne den separat zu prüfenden Payload-Staging-Test): 188 Fälle, davon 181 bestanden und sieben ausdrücklich aktivierbare native Prüfungen übersprungen; keine Fehler. Die übersprungenen Tests werden nicht als native Abnahme gezählt. Die vier gezielten Diagnose-/Factory-/Download-/Proxy- Dateien bestanden zuvor mit 28 Fällen einschließlich tatsächlichem privatem OTLP-Empfänger. Der vorhandene geschützte Collector meldet null Commitfehler und null abgewiesene Schreibzugriffe; der bestehende Trace e5ebf887a1ad8d90f065739a86cd2261 wurde mit 55 Spans abgerufen. Das beweist keine neuen produktiven Broker-Exporte. Lokale Evidenz: artifacts/core-broker-development-check-2026-10-14.json.

Der erste native Lauf des fünften Payloads mit tatsächlichem HTTPS-Unternehmens- Proxy ist fehlgeschlagen: öffentlicher Roh-Upload wurde übertragen, decodierte Dokumentprüfungen erreichten jedoch das feste fünfsekündige Request-Limit statt eines vollständigen Scannerurteils. Der Inspector erlaubt bis zu 29 Sekunden begrenzte Arbeit. Diese Zeitbudget-Inkompatibilität und die Unterdrückung später Urteile nach einem bereits protokollierten Timeout sind vor einer erneuten Proxy-Abnahme zu korrigieren. Ein funktionierender Roh-Upload beweist hier keine Dokumentabdeckung. Der Testprozess endete; ursprüngliche Fehlerevidenz bleibt.

Nach Korrektur auf ein absolutes 30-Sekunden-Gesamtbudget besteht der sechste gepackte native Lauf (1/1, 26,5 Sekunden): geheime Raw-/JSON-/Data-URL-Inhalte werden mit tatsächlicher Scanner-Regel vor zusätzlicher Zielverbindung gesperrt. Öffentliche äußere JSON-Bytes bleiben unverändert. PNG-Inline-Inhalt funktioniert trotz allowDownloads=false, Attachment-Speicherung wird gesperrt. Öffentliches Inline-PDF funktioniert, geheimes PDF gibt keine PDF-Bytes frei. 13 persistierte Ereignisse enthalten geprüfte echte Dateigrößen und SHA-256 sowie kausale UUIDs. Privater Testempfänger: 22 echte OTLP-Spans, 33.635 Bytes, null ungültige Exporte, null aktuelle/lebenslange Exportfehler; dauerhafte Trace-ID 2943810ad3499cd0d331a45206b2780d wurde tatsächlich abgerufen, Audit-Span und Request-Elternspan verknüpft. Supervisor bestätigt geschlossen, ohne Quarantäne. Nachweis: artifacts/broker-production-native/proof-2026-10-14T10-31-22.318Z.json. Die Spans stammen vom privilegierten Test-Parent, nicht vom produktiven Child- Exporter. Hauptbrowser, Windows-Dienst und Installer bleiben separate Gates.

Der Transportbaustein für den nativen Dienst verwendet längenbegrenztes UTF-8- JSON (initial maximal 2 MiB, danach 64 KiB), höchstens acht ausstehende Writes und feste Fehlercodes; acht Tests einschließlich fragmentierter Frames, ungültigem UTF-8 und tatsächlichem Duplex-Transport des bestehenden Audit-RPC bestehen. Disconnect bestätigt ausstehende Writes nicht als erfolgreich; ein später Callback kann kein zweites Ergebnis liefern. Dieser Baustein authentifiziert keinen Peer und ist noch nicht aktiviert. Die native Dienst-/Client-Identitätsprüfung vor dem ersten Frame sowie die Produktionsanbindung bleiben separate Abnahmebedingungen.

Der eigene native Dienst-Host wurde mit MSVC 14.44 als Testvariante kompiliert (kein Chromium-Neubau). Ein tatsächlicher Windows-Selbsttest beweist die Ablehnung fehlender Dienst-SID, Job-Mitgliedschaft von Kind und Enkel, deren beendeten Zustand nach Job-Schließen und die Ablehnung eines falschen Hashes. artifacts/native-service-host/proof.json bindet diesen Nachweis an den damaligen Quell-/Binary-Hash und weist installed=false sowie wfpActivated=false aus. Die unabhängige Quellprüfung verlangt weitere Korrekturen vor Aktivierung: Pipe-DACL ohne FILE_CREATE_PIPE_INSTANCE für Benutzer, exakter geschützter Browserpfad, geschützter Deployment-Vertrauensanker, absolute Frame-Zeitgrenzen und abbrechbare Writes. Der Selbsttest beweist keine Dienstinstallation oder authentifizierte produktive Benutzerverbindung.

Nachfolgende native Testvariante: explizite Benutzer-Pipe-Rechte verweigern eine zweite Instanz auch ohne FIRST_PIPE_INSTANCE; unberechtigter Client und zu großer Frame werden tatsächlich abgewiesen. Job-Tests bleiben grün. Ein zusätzlicher anonymer Pipe-Test unterscheidet erfolgreich abgeschlossenen Write mit gesundem Idle von einem blockierten, abgebrochenen Write. Die Installation bleibt unbewiesen; das aktuell weiterentwickelte Quellfile muss jeweils erneut zum Hash des kompilierten Nachweises passen.

Ein noch nicht aktivierter Service-Bootstrap-Baustein verwirft einen vom Aufrufer gewählten Policy-Schlüssel, eine fremde Geräte-ID und eine Mindestversion unter der geschützten Zuordnung vor dem Factory-Aufruf. Sechs Tests bestehen, darunter eine echte Vendor-/Kundensignatur-Kette und die Ablehnung einer fremden in der Testfixture übergebenen SID. Das ist keine native Pipe-Identitätsprüfung. Sein privilegierter Trust-Loader muss zuvor Release-Signatur, delegierte Kundensignatur, geschützte dauerhafte Rollback-Grenzen und die tatsächlich vom nativen Pipe-Peer ermittelte SID prüfen; ein injizierter Test-Loader beweist diese Voraussetzungen nicht. Die Benutzer-SID darf ausschließlich aus der nativen Peer-Prüfung stammen, niemals aus dem START-JSON oder einer übernommenen Benutzer-Umgebungsvariable. Der Baustein sperrt zudem einen Start nach Deployment-Ablauf und schließt einen laufenden Broker bei Ablauf, auch wenn die Browser-Policy länger gültig wäre. Mehrere Close-Aufrufe warten auf denselben ursprünglichen Cleanup und erhalten dessen Fehler; ein bereits begonnener Cleanup gilt nicht als abgeschlossen.

Die neue Service-Acceptance-Prüfung verifiziert Release-, Kunden- und Policy- Signaturen zusammen, erzwingt die Gerätezuordnung und erhält gespeicherte Policy-Mindestversionen pro Nutzer-SID, Gerät und Policy-Schlüssel. Auch eine neuere Deployment-Freigabe oder eine Schlüsselrotation löscht alte Grenzen nicht. Der kanonische vollständige Zustand ist auf 2 MiB und 8.192 eindeutige Einträge begrenzt; 1.024 Bytes des Frame-Budgets bleiben für den festen Snapshot-/CAS- Umschlag reserviert. Der vollständige serialisierte Commit wird zusätzlich gegen das 2-MiB-Limit geprüft. Überfüllung wird gesperrt. Der Commit-Gate wartet auf die exakte native Persistenzbestätigung und akzeptiert weder unsichere Ergebnisse noch automatische Wiederholung nach einem ungewissen Commit.

Die unabhängige Prüfung reproduzierte außerdem einen Start-Binding-Fehler: eine andere gültig signierte Policy unter derselben Version konnte eine neue Factory erreichen, obwohl ein vorheriger Plan andere Inhalte bestätigt hatte. Der Start vergleicht jetzt zusätzlich den exakten Digest des bestätigten Policy-Payload-Feldes und die Version, bevor die Factory aufgerufen wird. Direkte Plan-/Commit-/Start-Komposition und gleichversionige Alternativ-Policy werden zusammen geprüft: acht Akzeptanz-/Commit-Tests und sechs Bootstrap-Tests bestanden. Ein weiterer Akzeptanztest beweist die Sperre von 8.000 einzeln gültigen Einträgen durch das gesamte serialisierte Byte-Budget (neun Akzeptanztests grün). Der Digest der Policy verwendet das Base64url-Payload-Feld als String; Release-/Deployment-Digests verwenden die decodierten kanonischen Bytes. Die native Implementierung muss diese unterschiedlichen Verträge einhalten.

Diese Regeln und Callback-Bestätigungen beweisen noch keinen Registry-Commit. Offen ist ein tatsächlich geschützter einzelner AcceptanceState-Wert mit Vergleich des vorherigen Zustands, vollständiger monotoner Transition und RegFlushKey vor Bestätigung. Fehlender Zustand darf nicht als Version null initialisiert werden. Installation und Freigabe dieses Stores bleiben offen.

Der native Store verwendet dafür feste Helper-Rollen --trust-snapshot und --commit-acceptance, einen einzelnen AcceptanceState-Registrywert und eine begrenzte Compare-and-swap-Anfrage. Der Quellpfad prüft Dienst-SID, tatsächlichen geschützten Node-Elternprozess, signierte Zuordnung, Flush und Rücklesen vor Bestätigung. Bisher wurde kein produktiver HKLM-Write ausgeführt; die uninstallierte Rollen-Ablehnung ersetzt keine positive Dienst-/Store-Prüfung. Die JavaScript-Anbindung wird separat auf genau eine gerahmte Antwort und bestätigtes Prozessende geprüft, ohne vom Renderer gewählte Pfade oder Schlüssel.

Offene native Ownership-Prüfung: Eine aktivierte Dienst-SID ist nicht automatisch als Eigentümer zulässig. Windows verlangt für einen Gruppen-Owner das SE_GROUP_OWNER-Attribut; siehe Microsoft TOKEN_OWNER. Eine Alternative muss implizites WRITE_DAC des Kontoeigentümers ausdrücklich einschränken und tatsächlich testen; Microsofts SID-Dokumentation beschreibt die OWNER-RIGHTS-SID. Ein Plan oder DACL-String allein ist kein Nachweis der tatsächlichen LocalService-/SCM-Berechtigungen.

Der native Test bestätigt inzwischen eine Alternative ohne SeRestore und ohne angenommene Service-SID-Owner-Eignung: Standardkontoeigentümer plus ausdrückliche OWNER-RIGHTS-ReadControl-Berechtigung. Im tatsächlichen Test wird WRITE_DAC mit Access Denied (5) verweigert, während Mutex-Synchronisation und Modify erlaubt sind. Das prüft die Owner-Regel, nicht einen installierten SCM-Commit.

Die JavaScript-Service-Anbindung besitzt einen eigenen festen Entry-Pfad und wartet auf die native Persistenzbestätigung vor Factory/Listen. 16 gezielte Transport-/Entry-/Akzeptanztests bestehen. Die unabhängige Quellprüfung fand noch Interoperabilitätskorrekturen vor einem nativen Lauf: Die vom Host ermittelte SID muss ausdrücklich an den Helper weitergegeben werden; der begrenzte rohe Release-Envelope muss den Base64-Overhead berücksichtigen; partielle Dateireads benötigen vollständige begrenzte Verarbeitung und Vorher-/Nachher-Prüfung. Die Fake-/Subprozess-Tests schließen diese tatsächlichen Dienst-Gates nicht.

Nach unabhängiger Korrektur bestehen 18 gezielte Service-Store-/Entry-/Akzeptanz- Tests. Ein tatsächlicher Subprozess erhält nur die validierte vom Host ermittelte SID und die beiden Windows-Systemvariablen. Ein echter signierter Release mit 6.007 Dateien und mehr als 2 MiB rohem Envelope wurde über begrenzte partielle Reads vollständig gelesen und kryptografisch verifiziert. Dateiidentitätswechsel und ungültige Antworten werden gesperrt. Das ist weiterhin keine positive SCM-/HKLM-Abnahme.

Zusätzliche offene WFP-Abnahme: CONNECT-Filter allein reichen nicht aus. Microsofts ALE-Dokumentation beschreibt, dass nach erster Freigabe eines eingehenden oder ausgehenden Flows beide Richtungen zustandsbehaftet erlaubt sind. Deshalb braucht die Browser-EXE auch RECV_ACCEPT-Sperren für neue eingehende IPv4-/IPv6-Flows und tatsächliche inbound-first-UDP-/TCP-Tests. Vor einer Aktivierung müssen bisherige lokale Agent-/Management-/Inspector-/OTLP-Listener bzw. Transporte über den Broker laufen. Der bisherige Vier-CONNECT-Filter-Plan und eine normale Unternehmens-Firewall beweisen diese Grenze nicht. Keine dieser neuen WFP-Regeln wurde aktiviert.

Der Plan und die Installer-/Probe-Quellen enthalten jetzt sechs Browser-Regeln: vier CONNECT- und zwei RECV_ACCEPT-Sperren. Sechs JavaScript-Planprüfungen und 21 Python-Vertrags-/Fehlertests bestehen. Das sind keine aktivierten Windows- Filter oder physischen Egress-Tests. Zusätzlich muss die tatsächliche WFP- Arbitration geprüft werden: höher priorisierte Hard-PERMITS können gewöhnliche Sperren beeinflussen; siehe Microsofts Filterarbitration. Die bisherige niedrige Sublayer-Priorität allein beweist keine wirksame Grenze. Eindeutige Priorität/Kollisionsregeln, native Topologieprüfung, relevante Änderungsüberwachung und tatsächliche TCP-/UDP-Tests bleiben vor Freigabe offen.

Die DNS-Migrationslücke ist im neuen Broker behoben: Alle aufgelösten Adressen werden gegen security.dns.blockedIPs geprüft; eine gesperrte Adresse verwirft die Route. Bei aktiver IP-Policy erhält der Unternehmens-Proxy ausschließlich die freigegebene numerische CONNECT-Adresse. SNI, Host und TLS-Zertifikatsprüfung bleiben an den ursprünglichen Namen gebunden. Der achte native Factory-Test beweist sechs tatsächliche numerische Tunnel und unveränderte DLP-Blockierungen. Der System-/VPN-Resolver bleibt der unterstützte Pfad. Konfiguriertes Secure DNS wird ausdrücklich als nicht unterstützt abgewiesen statt still heruntergestuft. Die Hauptbrowser-/Dienst-Migration und externe Kunden-Proxy-Abnahme bleiben offen.

Für diese Release-Verifikation wird standardisierte P-256/ECDSA mit Windows CNG und getrennt delegiertem Kundenschlüssel entwickelt. Das ist klassische Signaturkryptografie und kein Nachweis quantensicherer Artefakt-Signaturen. Produktionssignierung und die vollständige Windows-Verifikation bleiben offen.

Die unabhängige Prüfung des Release-Inventars fand einen Integrationsfehler: kanonisch signierte JSON-Objekte hatten eine andere Feldreihenfolge als das Dateiinventar und wurden deshalb fälschlich abgewiesen. Der Vergleich prüft jetzt explizit Pfad, Größe und SHA-256 bei unveränderter vollständiger Inventarabdeckung. Eine echte Signieren-/Verifizieren-/Dateisystem-Prüfung und anschließende gleichgroße Dateimanipulation prüfen beide Richtungen. Diese Testschlüssel liegen nur im Speicher; daraus entsteht kein produktiver Signaturnachweis.

Reihenfolge der verbleibenden Core-Arbeit

Der erste echte Start des neuen gepackten Production-Childs war vor READY gesperrt. Der feste lokale Startcode broker-startup-transport identifizierte eine konkrete Typinkompatibilität: Die Factory lieferte ein CA-Array, während der geprüfte HTTPS-Forwarder ausschließlich PEM-String oder Buffer akzeptiert. Die Korrektur verbindet die freigegebenen öffentlichen PEM-Zertifikate zu einem String; TLS-Prüfung und Hostname-Prüfung bleiben aktiv. Der tatsächliche neu gestagte Prozess-/Transfernachweis bestand nach dieser Korrektur: tatsächlicher Production-Child mit offiziellem Node, enthaltenem Inspector und privater IPC, öffentlicher Upload exakt 16 Bytes / 201 / eine Zielverbindung, Geheimnis 403 ohne zusätzliche Zielverbindung und tatsächliche erkannte Regel im fsync-Audit. Nachweis: broker-production-native/proof-2026-10-14T09-10-08.981Z.json unter artifacts; bestätigtes Prozessende. Dies ersetzt weder den Hauptbrowserpfad noch Download-, Unternehmens-Proxy- und WFP-Abnahmen. Ein später erfolgreicher direkter Inspector-Start ersetzt diesen Nachweis nicht.

Umgesetzt: bekannte Base64-verpackte binäre Dokumente in JSON/Data-URLs erhalten vor Freigabe Magic-Byte-, Fingerprint- und lokale Parserprüfung. Native Nachweise stehen unten. Download-Blockierungen besitzen typisierte Download-Fakten und registrierte Scanner-Regel-IDs. Dies ersetzt keine allgemeine Abdeckung beliebiger Kodierungen oder die noch offene Hauptbrowser-Anbindung.

Der neue begrenzte Carrier-Extractor ist implementiert und nach unabhängiger Prüfung um JSON-interne Prozentkodierung, verschachtelte Text-Envelopes und strikte JSON-Primitive erweitert. Acht Regressionstests und Lint bestehen. Die Integration erhält ein gemeinsames Byte-/Teil-/Knoten-/Rekursionsbudget über alle decodierten Teile und erzwingt tatsächliche Dokumentparser. Unbekannte rohe Binärkodierungen und Vektor-/SVG-Rendering sind damit nicht pauschal abgedeckt; ausdrücklich deklarierte unprüfbare Carrier müssen sperren. Die kombinierte native Production-Child-Prüfung besteht nach kontrolliert nachgewiesener Ergänzung von genau USERPROFILE, LOCALAPPDATA und APPDATA in der Windows-Umgebung. Geheimnisse im Hex-PDF werden in JSON und Prozent-Data-URL mit tatsächlicher registrierter Regel ohne zusätzliche Zielverbindung blockiert. Öffentliche äußere JSON-Bytes werden nach vollständiger Parserprüfung unverändert übertragen. Öffentlicher PDF-Download funktioniert; gesperrter PDF-Download gibt keine PDF-Bytes frei und erhält ein kausal verknüpftes download.block-Ereignis. Neun fsync-persistierte synthetische Ereignisse; bestätigtes Broker-Prozessende. Der ursprüngliche fehlgeschlagene kombinierte Nachweis bleibt erhalten. Die Umgebungskorrektur verändert weder ACLs noch Parser-, TLS- oder Policy-Prüfungen. Factory-Unternehmens-Proxy und Hauptbrowser-/Installer-Abnahmen bleiben offen. Nachweis: broker-production-native/proof-2026-10-14T09-48-31.825Z.json unter dem ignorierten lokalen artifacts-Verzeichnis.

Verbindlicher Auslieferungsvertrag

Ein gemeinsamer Windows-Installer enthält Browser, separaten DLP-Broker, dessen private Runtime, lokale Scanner und Modelle. Auf dem Zielgerät ist keine Entwicklungsinstallation von Node oder Python und kein manueller Broker-Start erforderlich. Der Zielpfad startet und überwacht den enthaltenen Broker über einen geschützten Windows-Dienst; dessen Installation und produktive Anbindung sind noch nicht nachgewiesen. Fehlt dieser, ist er manipuliert oder fällt er aus, dürfen geschützte Transfers nicht auf einen ungeprüften direkten Netzwerkpfad ausweichen. Update und Deinstallation müssen auch die zugehörigen verwalteten Komponenten berücksichtigen. Ein entpacktes Entwicklungsverzeichnis allein erfüllt diesen Vertrag nicht.

Neue lokale Integrationsnachweise

• Gemeinsamer Repository-Lauf: ESLint und sämtliche JavaScript-Syntaxprüfungen bestehen; 1.119 Node-Tests, davon 1.107 bestanden, null Fehler und zwölf explizite native Opt-in-Skips. Der Lauf ersetzt diese ausgelassenen nativen Abnahmen nicht. Tatsächlicher privater OTLP-Trace 4a4cbe86f72921e7e1d9a2b94abcb4b8 enthält fünf korrelierte Spans, null aktuelle/lebenslange Exportfehler. Zwei anschließend ergänzte Credential-Lifecycle-Consumer-Regressionen bestehen separat.
• Credential-Lifecycle korrigiert: Der native Request muss zuerst exakt zur aktuellen angenommenen Policy passen. Für denselben SID, Device, Origin und Policy-Key kann der jüngste zulässige ältere Credential-Datensatz wiederverwendet werden; seine eigenen Metadaten bleiben an die DPAPI-Entropie gebunden. Ein gleiches Versionsdatum mit anderem Digest, zukünftige Versionen und Mehrdeutigkeit werden abgewiesen. Provisionierung ersetzt diese stabile Identität statt ihre Versionshistorie unbegrenzt anzuhäufen. Native Auswahl-/CAS-/Registry-Ausführung ist weiterhin nicht nachgewiesen; die zwei JS-Tests prüfen die Consumer-Grenze.
• DPAPI-Capability-Helfer gehärtet: private Python-Runtime mit -I -B und ausschließlich erlaubten Windows-Umgebungsvariablen. Ausgabe ist vorallokiert und begrenzt; späte Daten nach einem Fehler werden ignoriert. Höchstens acht ursprüngliche Helper-Prozesse bleiben bis zu ihrem tatsächlichen Ende belegt; ein fehlgeschlagener Kill gibt keine Kapazität frei. Fehler bleiben bereinigt. Tatsächliche Windows-DPAPI-Roundtrips bestehen auch für 32.768 Eingabebytes und 44.000 Ciphertext-Bytes sowie bei manipulierten Python-Umgebungsvariablen. Fünf Tests, null Skips. Die früher kleinere Entschlüsselungsgrenze wurde an den tatsächlich größeren Ciphertext angepasst, ohne Klartextgrenze zu erhöhen. artifacts/dpapi-helper/proof.json enthält vier tatsächliche private OTLP-Spans, Trace a2f37753f5620155c4944b26ef1189bd, null Exportfehler. Die beiden Credential-Stufen wurden mit tatsächlichem Parent und Zeiten abgerufen. Der Audit-Korrelationsanker ist synthetisch; kein Browser-Upload fand statt.
• Begrenzte Management-Operationen prüfen jetzt Identität und verschlüsselte Policy über fest vorgegebene HTTPS-Routen. ML-KEM-1024, gepinnte ML-DSA-87- Signaturen, Device-Bindung, Mindestversion und gleicher-Version-Digest werden geprüft. Beide Policy-Aufrufe teilen ein Deadline-/Job-Budget; Widerruf nach Challenge verhindert den zweiten POST. 16 Tests bestehen. Das Policy-Ergebnis aktiviert keine Regeln und ersetzt keinen geschützten Floor-Commit.
• Native Topologie-/Credential-Quellen sind erweitert und kompilieren. Ihre aktuelle Ausführung ist ausdrücklich nicht nachgewiesen: Beim Topologie- Selftest war die EXE vor dem Start vorhanden und gehasht; der Start scheiterte mit UNKNOWN:spawn, danach fehlte die Datei. Gezielte schreibgeschützte Defender-/CodeIntegrity-Abfragen belegen keine Ursache dieses Fehlers. topology-compile-only-proof.json und current-compile-only-proof.json unter artifacts/native-service-host unterscheiden Kompilierung von Ausführung. Frühere native v2-Erfolge gelten für den damaligen Hash. Kein Endpoint-Schutz wurde deaktiviert, kein neuer Registry-/SCM-/WFP-Zustand aktiviert.
• Neunter Payload: broker-prepared-service-proof-ninth.json unter artifacts, 313 Dateien / 64 Quellnachweise, sechs tatsächliche Paket-Isolationsprüfungen. Native Test-EXEs, Signing-Assets und damals unreviewte Credential-Helfer sind ausgeschlossen. Spätere Policy-/Credential-Quellen benötigen einen neuen expliziten Snapshot; dieser Komponenten-Nachweis ist keine Installer-Abnahme.
• Dienst-Lifecycle weiter geprüft (broker-service-lifecycle-proof-2026-10-14.json unter artifacts): Paketprüfung, Startbereitschaft und Herunterfahren besitzen benannte tatsächliche OTLP-Spans. Trace d0e4c73944250d8f96864c043e6a83d9 enthält fünf korrelierte Spans; aktuelle und lebenslange Exportfehler null. Instrumentierung kann Prüfungen nicht überspringen, ersetzen oder wiederholen. Der Prozesspfad wartet ursprüngliche Factory-/Listen-/Cleanup-Promises ab; verspätete Ergebnisse geben keine Bereitschaft frei. Cleanup-Fehler bleiben beim wiederholten Close erhalten statt als erfolgreicher Abschluss zu gelten. 25 gezielte Prozess-/Dienst-/Framing-Tests bestehen. Ein parallel noch mit altem Testinhalt gestarteter Lauf hing an unterdrücktem Startup-Fault; der korrigierte Test wartet die tatsächliche Quarantäne-Disconnection ab.
• Deployment v2 bindet HTTPS-Management-Origin und bestehenden ML-DSA-87-Pin. Native MSVC-Kompilierung besteht; sechs positive und 23 tatsächlich signierte negative native Manifestfälle geprüft. Der native Parser validiert PQ-Key- Metadaten; die tatsächliche PQ-Signaturprüfung bleibt im vorhandenen Node- Kanal. Die erste begrenzte Management-Operation prüft Identität über HTTPS mit Ed25519 und gepinntem ML-DSA-87. Sechs physische HTTPS-Tests bestehen. Geschützte Credentials, Enrollment und produktive IPC-Anbindung sind noch nicht umgesetzt.
• Dienst-Bootstrap akzeptiert ausschließlich Receiver-Port 43120, passend zur festen nativen/WFP-Grenze. Andere Ports scheitern vor Trust-Load und Konstruktion; 20 kombinierte Bootstrap-/Acceptance-/Service-Tests bestehen. Der separate isolierte Production-Child-Empfängertest darf weiterhin Testports verwenden. Neue Trust-/Lifecycle-/Topologiequellen erfordern vor dem nächsten Paketnachweis einen frischen explizit geprüften Payload; der achte bleibt historische Evidenz.
• Achter Payload: broker-prepared-service-proof-eighth.json unter artifacts, 309 Dateien / 60 Quellnachweise, sechs physische Paket-Isolationsprüfungen. Aktualisierter nativer Production-Child-Test besteht: broker-production-native/proof-2026-10-14T11-28-12.697Z.json, sechs numerische HTTPS-Proxy-Tunnel mit ursprünglichem SNI, 13 persistierte Ereignisse und 22 tatsächliche private OTLP-Spans. Trace 40c28b579ce1adb8010503bae74b40f5 wurde mit seinem Audit-Kindspan abgerufen; aktuelle und lebenslange Exportfehler null. Die Exporte stammen vom privilegierten Test-Parent, nicht vom Dienst-SDK.
• Neuer Browser-Dienstadapter startet ausschließlich den fest installierten nativen Host mit --client-stdio. Installation und Broker-Paket müssen vorher unabhängig verifiziert sein. Fünf Adaptertests mit tatsächlichem Node-Testchild plus zehn bestehende Supervisor-Tests bestehen. Das ist kein SCM-Positivnachweis. Der zusätzliche OTLP-Test persistiert ein synthetisches Audit-Ereignis mit fsync und ruft zwei tatsächliche, kausal verbundene Spans ab: 8be57a1790a8429140f5eeb71e0e219c, null Exportfehler. Ein erster Test scheiterte an einer ungültigen Fixture-UUID; die strikte Validierung blieb unverändert. Hauptbrowser-Aktivierung und native Dienst-Authentifizierung stehen noch aus.
• Office-Timings mit tatsächlichem AppContainer-Inspector und privatem OTLP- Testempfänger geprüft: private-otlp-proof-2026-10-14T08-29-16.980Z.json unter artifacts/office-native-observability. Vier benannte Office-Spans hängen am tatsächlichen Parse-Span; defektes Archiv erzeugt einen bereinigten Fehler- Span. Aktuelle und lebenslange Exportfehler: null. Dies ist kein Nachweis der produktiven Collector-Konfiguration; diese wurde nicht geändert.
• Kurzlebige Broker-TLS-Zertifikate werden im Speicher erstellt, mit exakter SAN, ohne CA-Berechtigung und mit begrenztem Cache. Physischer Node-HTTPS-Test prüft die Zertifikatskette und verwirft einen falschen Hostnamen. Die Browser- Vertrauensbindung und die produktive Factory bleiben gesondert offen.
• Sitzungsgebundene Zertifikat-Pins mit tatsächlichem Stock-Electron 44.7.0 / Chromium 152.0.7977.130 geprüft (broker-certificate-pins/proof.json unter artifacts): registriertes kurzlebiges Leaf liefert 200, unregistriertes Leaf wird ohne Anwendungsanfrage abgewiesen. Der Fingerprint wird aus Electrons tatsächlichem Certificate.data berechnet. Generation, SAN, Ablauf und Policy werden geprüft. Electrons Callback liefert keinen Port und cached Ergebnisse; CONNECT-/SNI-/Host-Bindung sowie Schließen alter Verbindungen bleiben zwingend. Der produktive Browser ist noch nicht auf diesen Helper umgestellt.
• Der Parent-Audit-Adapter wurde mit tatsächlichem Windows-DPAPI und einer synchronen fsync-/Rename-Persistenz geprüft (broker-parent-audit/proof-7IKfqn unter artifacts). Die ursprüngliche Broker-Ereignis-ID wird erst nach Commit bestätigt; Klartext-ID fehlt in der geschützten Datei. Fehler, asynchrones Einreihen und uneindeutige boolesche Writer-Ergebnisse geben keine Bestätigung. Die produktive Private-IPC-/Browser-Anbindung dieses Adapters bleibt offen.
• Der tatsächliche lokale SIEM-Dateiexporter erhält die Broker-Ereignis-UUID und die Verbindung zwischen Freigabe und anschließendem Übertragungsfehler. ECS/CEF-Felder und deren Grenzen stehen in broker-siem.md. Eine Freigabe hat einen unbekannten Lieferstatus; Terminalfehler werden als Fehler ausgewiesen. Dieser Nachweis ersetzt keine externe SIEM-Abnahme.

1. Nativer PDF-/Office-Nachweis mit verpflichtender Audit-Persistenz bestanden: office-proof-2026-10-14T08-23-30.852Z.json unter dem ignorierten lokalen Evidenzverzeichnis artifacts/broker-native-inspection. Sieben mit fsync persistierte synthetische Ereignisse, drei tatsächliche erkannte Geheimnisregeln, keine Zielverbindung für gesperrte Dokumente und keine verbleibenden eigenen Inspector-Prozesse. Die Fixture beweist weder produktive Audit-Verschlüsselung noch SIEM-Auslieferung; Diagnostik war zentral deaktiviert.
2. Sicherheitsereignisse für frühe CONNECT-/Framing-Blockierungen und Fehler nach Transferfreigabe ergänzen. Eine protokollierte Freigabe ist kein Nachweis einer erfolgreichen Übertragung. Erlaubte Dokumente müssen funktionieren; Geheimnisse dürfen beim kontrollierten Empfänger nicht ankommen.
3. Zertifikats-/Trust-, Proxy-, Audit- und Management-Pfade vollständig integrieren. Kein ungeprüftes CONNECT-Piping oder DIRECT-Fallback als Ersatz.
4. Windows-Regeln über den geprüften Installer-/Service-Pfad aktivieren und unabhängig nativ prüfen. Erst dann die bisherige Header-Sperre ersetzen.
5. Gemeinsamen Installer bauen und ohne Entwicklungsruntime abnehmen, einschließlich Ausfall, Widerruf, Update und fehlender/manipulierter Broker-Dateien.

Die detaillierten Anforderungen bleiben in windows-dlp-mvp.md. Diese Übersicht ersetzt weder deren Kriterien noch die übrige Enterprise-Roadmap.