TLS-Gate v3.6.0: Modulkette als Regel mit Ende-zu-Ende-Test (nicht verdrahtet), Checkliste 2FA/Container

Von: Branko → OZMAI
Stand: 5. Oktober 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3 — keine automatische Geltung, kein Brain-Status)
Charakter: STAND + NACHTRAG. Setzt 2026-10-05_TLS-GATE-V3-4-0-BIS-V3-5-0-MFA-MODUS-JE-GRUPPE-UND-PRODUKT-STAMMDATEN_BRANKO.md fort. Ersetzt eine Aussage dieser Vorgängerdatei: dort steht unter „Offene Punkte“, die Verkettung der Module sei „nicht abgebildet und nicht getestet“. Seit v3.6.0 gibt es dafür eine Regel und einen Test, aber nur als Auswertung, in keiner Seite verdrahtet (siehe §2). Alles andere der Vorgängerdatei gilt unverändert.
Quelle: Repo TLS-Gate-Mock-Pipeline (git.crumbforest.org). Tag v3.6.0 = Commit 88e18fa (Vorgänger v3.5.0 = 7cc3f2e). Dokument: 5c99a2a.
Belege: tests/test_chain.sh (43), alle Host-Suiten grün; die VM-Suiten wurden für v3.6.0 nicht neu gestartet (siehe §4).

Legende: ✅ real/gebaut · 🧪 gebaut, getestet, nicht live · 🛠 spezifiziert · ⬜ OPEN · ❓ UNKNOWN

Keine Zugangsdaten, keine Kunden-Domains, keine Reseller-IDs.

1. Anlass

Branko gab für die Modulkette #login → #crew → #schlüssel → #CA → #hosting → #SSL an, dass „genau das“ bisher nicht getestet wurde (jedes Glied einzeln ja, die Verkettung nein), und zwei Vorgaben: (a) sofern nach dem ersten Zugang eine neue Anlage möglich ist, und (b) wer nicht modulberechtigt ist und zugreift, dessen Fehlversuch wird im Audit geloggt. Die Definitionen, was ein Glied erfüllt, blieben unbeantwortet; sie sind unten als vorläufig gekennzeichnet.

2. Was gebaut ist

• 🧪 src/Modules/Chain.php: reine Auswertung je Gruppe aus den Stammdaten (status, access, next, check, requireModule). Kein eigener Zustand, kein Schema-Wechsel.
• 🧪 Regel 1, keine Sackgasse: Der Zugang zu einem Glied verlangt nur, dass die Glieder davor nicht fehlen, nicht dass es selbst erfüllt ist. Damit lässt sich das nächste Glied nach dem ersten Zugang immer selbst anlegen. Beispiel: fehlt schluessel, ist das Modul erreichbar (zum Anlegen), hosting und ssl bleiben zu.
• 🧪 Regel 2, Fehlversuch im Audit: Abgelehnte Aufrufe schreiben module.denied / denied mit reason (vorgaenger_fehlt, keine_freigabe, unbekanntes_modul) und blocked_by. Erlaubte Aufrufe schreiben nichts. Keine Zugangsdaten im Eintrag (geprüft).
• 🧪 Glied ca = open: Platzhalter, blockiert nicht und wird so ausgewiesen. Grund: Die CA ist heute nur eine Test-CA der Node (bin/node_ca.php), kein Objekt je Gruppe.
• ✅ Bewusst nicht eingebaut: check() hängt in keiner Seite. Sonst wäre die heutige SSL-Konsole für alle Gruppen ohne Freigabe (group_products) sofort gesperrt. Verhalten der Anwendung ist unverändert.
• ✅ Dokument (DOC): docs/CHECKLISTE_2FA_CONTAINER_ZUGANG.md (5c99a2a): Anmeldung, Audit-Meldungen, MFA-Modus je Gruppe, Support-Weg, ssh (Port 2222, nur Schlüssel), last_login. Anlass: Auf die Frage nach einer 2FA-Container-Checkliste fand die RAG-Antwort nur die allgemeine SECURITY_CHECKLIST.md und sagte selbst, dass „2FA-Container“ in den Quellen nicht vorkommt. Die Liste gab es tatsächlich noch nicht.

3. Vorläufige Festlegungen (NICHT von der Crew bestätigt)

Die drei Rückfragen dazu (was „schlüssel“ und „CA“ bedeuten, was bei einer Lücke geschehen soll) wurden gestellt und nicht beantwortet; die Empfehlungen des Entwicklers wurden gesetzt und als solche gekennzeichnet (Kopf von Chain.php, Changelog, Entwurf).

4. Belegt, und was nicht

• 🧪 test_chain.sh 43: Ende-zu-Ende von der leeren Gruppe bis zum freigegebenen SSL, mit der 30-Minuten-Verzögerung über available_from, deaktivierter Freigabe, abgeschaltetem Produkt, vertauschten Produktarten, getrennten Gruppen, unbekanntem Modul, deaktivierter Gruppe. Audit-Zählung: jede Ablehnung steht im Audit (15 von 15).
• 🧪 Gegenprobe: drei absichtlich kaputte Fassungen färben den Test rot (ohne Audit: 3 rot; mit Sackgasse: 8 rot; open blockiert: 12 rot), die Originalfassung ist grün.
• ❓ VM-Suiten nicht neu gelaufen (run, p3–p6): Die neue Datei wird von keiner Seite geladen, das Risiko wurde als gering eingeschätzt, aber nicht geprüft.
• ❓ Kein Test über das Web: requireModule() (Sitzung, HTTP 403) ist nicht ausgeführt worden, weil keine Seite sie aufruft. Getestet ist check() mit nachgestellter Sitzung (tg_uid, tg_gid).

5. Einordnung als Prüffall (Branko, nicht OZMAI-Geltung)

Die Berechtigung leitet sich aus Stammdaten ab (Freigabe, Konto, Zugang), nicht aus einem früheren erfolgreichen Zugriff, und check() ist lesend: Eine erlaubte Prüfung erzeugt keine stärkere Bindung, eine abgelehnte hinterlässt nur einen Audit-Eintrag. Das passt zum Kernsatz des Identitäts-Prüffalls („Eine erfolgreiche Prüfung einer Bindung darf nicht stillschweigend eine stärkere Bindung erzeugen“) und zu „Wiederholung ≠ Bestätigung“: wiederholte Ablehnungen bestätigen nichts, sie sind Belege. Ob das als Prüffall taugt, entscheidet OZMAI/Alex.

6. Offene Punkte

• ⬜ SSL hängt an einer Hosting-Freigabe. Die Kette verlangt alle Glieder davor, also auch hosting. Das widerspricht „SSL nur beim RZ, kein SSL-Reseller als Kundentyp“, wenn ein reiner SSL-Kunde kein Hosting hat. Entscheidung offen (Kette lockern, SSL aus der Kette nehmen oder RZ-Gruppen ausnehmen).
• ⬜ Altbestand: Vor einem Einbau brauchen bestehende Gruppen Freigaben (group_products), sonst sperrt die Kette die heutige SSL-Konsole. Einbuchen offen.
• ⬜ Bedeutung von schluessel und ca (SOAP-Zugang, ssh-Schlüssel, Test-CA, Bestellung mit Beleg node_ca): nicht entschieden. Ein ssh-Schlüssel ist nur als Datei im Container-Dateisystem vorhanden, nicht in der DB; die Anwendung kann ihn heute nicht prüfen.
• ⬜ Verhalten bei Lücke im Dashboard: sperren mit Hinweis oder ausblenden; Empfehlung des Entwicklers ist „sperren mit Hinweis“, nicht bestätigt.
• ⬜ Die übrigen Punkte der Vorgängerdatei bleiben offen: Startpunkt der 30-Minuten-Regel, MFA-Modus für bare, Quelle für Preis/Verbrauch, SOT-Vermerk, Registry-Handle, qrlogin ohne eigenen Test.
• ⬜ NetBox/Ansible (SOT-Vermerk des Schlüssels eines Geräts) und das Verhalten offline sind weder modelliert noch getestet; group_products.sot_ref ist nur ein Verweis, TLS-Gate schreibt nicht nach außen.