docs 📄 TP16 Schritt 5: vw-Access-Leck geschlossen + Wildcard-login_method-Fund

vw von bypass/everyone auf non_identity(Heim-IP)+allow(email:christoph) umgestellt
(reusable-Policy via App-PUT detacht). Neuer 🔴 Fund dokumentiert: Wildcard
*.emsenhuber.net login_method:github/google = jeder Eingeloggte erreicht alles
(user-gated). hass-400 = HA-Origin (nicht Access), gateway-dw WG offen. §10.6.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/cf-tunnel-mapping.md

@@ -263,6 +263,13 @@ Tokens: nur im Container-Env + jederzeit via `GET /accounts/…/cfd_tunnel/<id>/
 - Tote CNAMEs gelöscht: `pbs`, `nginx-bf`, `hermes`, `hermes-geli`. NAS-cloudflared-Leichen `oc-tzcharlie`/`oc-johnny2` entfernt.
 - `gateway-dw` (192.168.178.1, nur via WG) bleibt CNAME→bf-nas = **404** (kein BF-Connector hat die WG-Route). **Offen: klären/entfernen.**
 
-### 10.6 OFFEN — Schritt 5 Access-Strang (user-gated, s. TP16)
-- **`vw` = aktuell `bypass` (öffentlich!)** ⚠️ Sicherheitsleck. „Geschützt heben" bricht aber Vaultwarden-Clients (Bitwarden-App/Extension können kein interaktives Access-Login) → Fix = **WARP-Device-Identity** (Gerät enrollen, dann Access via Device-Posture statt Login) statt Passthrough. Entscheidung/Trade-off mit User.
-- **`hass` 400 / `ha-mcp` 403** = CF-Access davor, HA-Companion-App kann kein Access-Login → gleicher Fix: iPhone in **WARP** enrollen (`Warp Login App`-Policy `allow:christoph` existiert). Client-seitig, braucht User am Gerät.
+### 10.6 Schritt 5 Access-Strang — TEILWEISE ✅ (2026-07-10)
+**✅ `vw`-Leck geschlossen:** vw-App (`1dbc45ca`) hatte 1 Policy = **bypass/everyone (öffentlich)**. Ersetzt durch 2 eigene (engere als die Wildcard!) Policies: `non_identity bf4-home-ip` (`90.146.35.38/32` = Heim ohne Login) + `allow christoph` (email `christoph@emsenhuber.com`, **kein** `login_method:*`). Bypass war eine **reusable** Policy `a8129e37` → nicht via App/Policies-DELETE löschbar, sondern per **App-PUT detacht** (nur die 2 neuen im `policies`-Array). Verifiziert: Heim = 200, kein `everyone` mehr; Account-weiter Sweep = **keine** App mehr öffentlich. Heim-IP `90.146.35.38` = aktuell (== bf4-DNS).
+
+**🔴 NEUER FUND (wichtiger als vw!) — Wildcard `*.emsenhuber.net` (`16aaec78`) zu offen:** Policy `christoph` hat `include: email:christoph OR login_method:github OR login_method:google`. **`login_method:<idp>` als include matcht JEDEN, der sich via GitHub/Google einloggt** — nicht nur christoph. D.h. **jeder GitHub-/Google-User erreicht nach Login alle internen Dienste** (hass, grafana, portainer, pve, gitea, …). Fix = die zwei `login_method`-Includes raus (nur `email:christoph` + ggf. weitere erlaubte Mails + `non_identity bf4` + `claude-mcp`). **NICHT einseitig geändert** (ändert Login-Verhalten überall) → User-Entscheidung. War im Memory schon als „Policy christoph verschlanken" geflaggt.
+
+**⏸️ `hass` 400 / `ha-mcp` — zwei getrennte Layer:**
+- **Access-Layer (remote):** HA-Companion-App kann kein interaktives Access-Login → Fix = iPhone in **WARP** enrollen (`Warp Login App` `6c32fe23` `allow:christoph` existiert → christoph darf enrollen). Client-seitig, braucht User am Gerät. Vom Heim-Netz (bf4-IP) ohnehin ohne Login erreichbar.
+- **Origin-Layer:** `hass.emsenhuber.net` gibt **vom Heim-Netz** (Access passt via bf4-IP) trotzdem **400** (CF `server:cloudflare`, aber Origin-verursacht) = **HA lehnt den Request ab** — HA-`http:`-Config (`use_x_forwarded_for` + `trusted_proxies` inkl. cloudflared-Range, ggf. Host-Allowlist). **Separates HA-Thema, NICHT Tunnel/Access** — offen.
+
+**gateway-dw** (192.168.178.1, nur via WG) = CNAME→bf-nas = 404 (kein BF-Connector hat WG-Route). Offen: Route bauen oder CNAME entfernen.