Architektur · Bedrohungsmodell · Mitigationen · bekannte Lücken

Was dieses Dossier deckt — und was nicht.

2.1 Komponenten

2.2 Trust-Boundaries

   Aussenwelt (HTTPS)
        |
        | (1) Skript-Download und Katalog-Fetch
        v
   ============== Trust-Boundary 1: Server <-> Endpoint ==============
        |
   +----+--------------------------------------------+
   |  Service (LocalSystem)                          |
   |  - validiert Skript-URL gegen BaseUrl-Whitelist |
   |  - lädt Skript via HTTPS                        |
   |  - führt PowerShell mit SYSTEM-Rechten aus      |
   +---+---------------------------------------------+
       |
       | (2) Named Pipe (lokal, ACL)
       v
   ============== Trust-Boundary 2: Service <-> UI ==============
       |
   +---+-----------------------------+
   |  UI (Nutzerkontext, kein Admin) |
   |  - rendert Katalog              |
   |  - sendet Install-Requests      |
   +---------------------------------+

2.3 Datenflüsse

Voraussetzungen, ohne die das Modell nicht hält.

Werden diese Annahmen verletzt, sind eigene Mitigationen nötig.

1. §3.1

   Der Kunde kuratiert die PowerShell-Skripte selbst und verantwortet ihren Inhalt. Der Kiosk garantiert, dass nur Skripte einer vom Kunden kontrollierten BaseUrl ausgeführt werden — nicht, dass diese Skripte sicher sind.

2. §3.2

   Der Webserver an BaseUrl ist mindestens so geschützt wie ein interner Code-Repository. Schreibzugriff darauf entspricht Admin-Rechten auf jedem ausgerollten Endpoint.

3. §3.3

   Der Endpoint ist nicht bereits vollständig kompromittiert. Ein Angreifer mit lokalen Admin-Rechten oder einem geschriebenen Kernel-Treiber kann den Kiosk so wenig schützen wie jede andere Anwendung auf der Maschine.

4. §3.4

   Das CA-Trust-Store des Endpoints ist intakt. Der Kiosk verlässt sich auf das System-CA-Pinning (kein eigenes Cert-Pinning in v1.2 — siehe §6).

5. §3.5

   Strukturierte Logs werden in ein SIEM oder zumindest manuell gereviewt. Der Kiosk schreibt; der Audit-Wert entsteht erst durch Lesen.

Acht Architektur-Prinzipien, im Code durchgesetzt.

1. §5.1

   Privilegien-Trennung als harter Boundary. UI ist Standardnutzer, Service ist LocalSystem. Es gibt keinen Code-Pfad, der diese Grenze ohne Pipe-Request überschreitet.

2. §5.2

   Skript-Whitelist über BaseUrl. Jede Skript-URL wird vor dem Download mit IScriptValidator geprüft. Validierung umfasst HTTPS, BaseUrl-Prefix, kein Path-Traversal, keine Credentials.

3. §5.3

   Named-Pipe-ACL. Pipe akzeptiert nur authentifizierte lokale Nutzer. Keine Netzwerk-Exposition, keine offenen Ports.

4. §5.4

   Pipe-Identitäts-Discovery. Service nutzt TokenImpersonationLevel.Identification, um die echte Client-Identität zu ermitteln (FEAT-207). UI-claimed Username wird nicht für Autorisierungs-Entscheidungen verwendet.

5. §5.5

   Strukturiertes Logging. Serilog mit File-Sink + optional SIEM-Sink. Jede Installation hinterlässt einen vollständigen Audit-Eintrag.

6. §5.6

   Single-Concurrent-Install. Concurrent-Requests werden mit Busy zurückgewiesen — keine Race-Conditions.

7. §5.7

   Skript-Timeout. ScriptTimeoutMinutes (default 30) verhindert hängende Prozesse.

8. §5.8

   Detection nur lesend. Probes (winget, Registry, File, Script) MÜSSEN read-only sein. Script-Probes werden vom selben IScriptValidator validiert wie Install-Skripte.

Was wir noch nicht haben — ehrlich offengelegt.

Wir legen diese offen, weil ein Pen-Tester sie ohnehin findet und weil wir keine Sicherheits-Theatralik betreiben. Jede Lücke hat eine Roadmap-Position oder eine bewusste Akzeptanz-Entscheidung.

Auf Anfrage stellen wir kuratierte Auszüge aus diesem Audit-Trail bereit, ohne dass Sie das gesamte Repository einsehen müssen.