444 lines
33 KiB
Markdown
444 lines
33 KiB
Markdown
# 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](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_token_owner).
|
|
Eine Alternative muss implizites WRITE_DAC des Kontoeigentümers ausdrücklich
|
|
einschränken und tatsächlich testen; [Microsofts SID-Dokumentation](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers)
|
|
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](https://learn.microsoft.com/en-us/windows/win32/fwp/ale-stateful-filtering)
|
|
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](https://learn.microsoft.com/en-us/windows/win32/fwp/filter-arbitration).
|
|
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](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](windows-dlp-mvp.md).
|
|
Diese Übersicht ersetzt weder deren Kriterien noch die übrige Enterprise-Roadmap.
|