TLS-Gate: Der Login steht über dem Modul (Handout für die Crew)
native & lokal → lesbar → möglich oder nicht. Nicht verhandelbar.
Von: Branko → OZMAI, Crew
Stand: 12. Oktober 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3, keine automatische Geltung, kein Brain-Status)
Charakter: NACHTRAG zu 2026-10-12_TLS-GATE-V3-16-0-NETBOX-ZUGAENGE-IM-WEB-UND-LIVE-TEST-SEEDS-NACHTRAG_BRANKO.md. Ersetzt nichts. Dieser Eintrag erklärt das Ökosystem der Crew, er meldet keinen neuen Code.
Anlass: Branko, 12.10.: Die Crew hat verstanden, warum es kein „neues Tool“ gibt. Gewünscht ist eine Erklärung ohne Folien, als ASCII in einer .md, für ältere Kolleginnen und Kollegen. Branko: „3FA … nur wenn 2FA sich bewiesen hat!“
Quelle: Repo TLS-Gate-Mock-Pipeline docs/LOGIN_UEBER_DEM_MODUL.md (dc7ba38). Code-Stand v3.16.0 (b9a33fa), native_php/. Werte und Regeln stammen aus src/Auth/Auth.php, src/Catalog/Bookings.php, src/Audit/Audit.php, src/Http/SslController.php und database/schema.sql. Lesen im Terminal mit glow <datei>, alle Bilder höchstens 80 Spalten.
Belege: Die Bilder beschreiben gebauten und getesteten Code (VM-Suiten vom 12.10. grün, siehe Vorgänger-Eintrag). Die zwei Audit-Zeilen im Bild sind ausgedacht. NIS2, DSGVO, CA und DNS sind als Bezug genannt, nicht als Konformität. Eine Prüfung gab es nicht.
Legende: ✅ real/gebaut · 🧪 gebaut, getestet, nicht live · 🛠 spezifiziert · ⬜ OPEN · ❓ UNKNOWN
Der Leitsatz
┌──────────────────────────────────────────────────────────────┐
│ │
│ NATIVE PHP, SQL und Bash. Kein Framework, kein │
│ Cloud-Dienst, kein Paketmanager zur Laufzeit. │
│ │
│ LOKAL Läuft auf der eigenen Node. Login, Gruppen, │
│ Buchungen und Audit gehen auch ohne Internet. │
│ │
│ LESBAR Jede Regel steht im Code, mit Fehlercode. │
│ Jede Tabelle in einer .sql-Datei. Kein Zauber. │
│ │
│ MÖGLICH Die Antwort ist ja oder nein, mit Grund im │
│ ODER NICHT Audit. Es gibt kein "vielleicht". │
│ │
└──────────────────────────────────────────────────────────────┘
Warum kein „neues Tool“? Ein Tool beantwortet eine Frage, zum Beispiel „Zertifikat bestellen“. Davor stehen aber immer dieselben Fragen: Wer bist du, zu wem gehörst du, was darfst du, und wo steht das? Wenn jedes Tool sie selbst beantwortet, gibt es fünf Logins, fünf Rechtemodelle und fünf Logs. Bei uns beantwortet der Login sie einmal. Die Module (SSL, Katalog, NetBox, Bestand) fragen nur noch nach.
Mensch
│
▼
╔═══════════════════════════════════════════════════════════╗
║ LOGIN Passwort + TOTP · Gruppe · Rolle · Audit ║ ← klärt
╚═══════════════════════════════════════════════════════════╝
│ fragt nur noch: "darf diese Rolle das hier?"
▼
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ SSL- │ │ Katalog │ │Dashboard│ │ NetBox- │ │ Bestand │ ← tun
│ Konsole │ │Buchungen│ │ │ │ Spiegel │ │Registrar│
└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘
│
▼
┌───────────────────────────────────────────────────────────┐
│ audit_log nur anhängen · nie ändern · nie löschen │ ← belegt
└───────────────────────────────────────────────────────────┘
1. Was klärt der Login?
E-Mail + Passwort ──► Konto aktiv? ──► nicht gesperrt? ──► Passwort ok?
│
┌────────────────────────────────────────────┘
▼
TOTP schon eingerichtet?
│ │
ja nein
▼ ▼
6-stelliger Code QR-Code zeigen, erst der erste
aus der App gültige Code schaltet TOTP scharf
│ │
└────────┬───────────┘
▼
Sitzung mit Gruppe + Rolle → auth.login ok
| Frage | Antwort im Code ✅ |
|---|---|
| Bist du es? | Passwort (Argon2id, 15 bis 128 Zeichen) und TOTP (RFC 6238). Zwei Faktoren. |
| Wie lange gilt das? | 30 Minuten ohne Aktivität, höchstens 12 Stunden (Auth::IDLE_TIMEOUT, ABSOLUTE_TIMEOUT). |
| Was bei Raten? | 5 Fehlversuche je Konto → 15 Minuten gesperrt. 10 je IP in 15 Minuten → IP blockiert. |
| Verrät die Meldung etwas? | Nein. Immer dieselbe Meldung: „Anmeldung fehlgeschlagen oder Konto vorübergehend gesperrt.“ |
| Kann man einen Code zweimal nutzen? | Nein, ein benutzter Code ist gesperrt (Replay-Schutz). |
| Cookie und Formulare | Cookie __Host-, SameSite=Strict, CSRF-Token auf jedem Formular, strikte CSP ohne Inline-Skripte. |
| Und ohne DB? | Die Seite antwortet mit 503. Sie lässt niemanden „zur Not“ herein (fail closed). |
MFA-Modus je Gruppe (groups.mfa_policy):
code klassisch: einmal QR, danach nur noch der Code aus der App
qr bei jedem Passwort-Login ein neues QR
⚠ wer das Passwort kennt, sieht das QR → kein echter 2. Faktor
gedacht für reine Login-Produkte, nicht für Root/SSL-Gruppen
Und 3FA? 🛠
3FA erst, wenn 2FA sich bewiesen hat. (Branko, 12.10.)
Faktor 1 Wissen Passwort ✅ gebaut
Faktor 2 Besitz TOTP-App ✅ gebaut
Faktor 3 Verhalten Erkennung/Bewegung im 🛠 Idee, nicht gebaut
Nullfeld (Logging, Muster)
Der dritte Faktor baut auf dem auf, was das Audit schon heute aufzeichnet (Abschnitt 4). Er kommt erst, wenn die Crew mit 2FA im Alltag arbeitet und das Audit zeigt, dass es trägt. Vorher wäre er Rauschen auf einem ungeprüften Fundament.
2. Was klären Gruppe, Rolle und Zugehörigkeit?
┌─ Gruppe (groups) ──────────────────────────────────────────┐
│ slug · Name · Typ: eigen | reseller · MFA-Modus │
│ │
│ ┌─ Konto (users) ──┐ ┌─ Konto ──────┐ ┌─ Konto ──────┐ │
│ │ admin │ │ user │ │ readonly │ │
│ └──────────────────┘ └──────────────┘ └──────────────┘ │
│ │
│ SOAP-Zugänge · NetBox-Zugänge · Freigaben · Buchungen │
│ (alles gehört genau einer Gruppe) │
└────────────────────────────────────────────────────────────┘
│
✗ keine Sicht in eine andere Gruppe:
eine fremde ID heißt "unbekannt", nicht "verboten"
(verrät nicht einmal, dass es sie gibt)
Jedes Konto gehört zu genau einer Gruppe (users.group_id, Pflichtfeld). Die Gruppe ist die Grenze: SOAP-Zugänge, NetBox-Zugänge, Freigaben und Buchungen hängen an ihr.
Die Rolle ist eine Leiter. Jede Stufe darf alles, was die Stufen darunter dürfen:
4 admin ████████ Benutzer, Gruppen, Katalog, Freigaben,
für andere buchen, Kontobindung NetBox
3 group_admin ██████ Zugänge (SOAP, NetBox) der EIGENEN Gruppe
2 user ████ bestellen, verlängern, Authcode, Besitzer-
daten, eigene Zusätze buchen und beenden
1 readonly ██ nur lesen: Liste, Details, DCV, Cross-Check
| Prüfung | Wo | Ergebnis bei Nein |
|---|---|---|
| Mindestrolle für die Seite | Auth::requireLogin($min) |
403 + auth.forbidden im Audit |
| Mindestrolle je SSL-Aktion | SslController::ACTION_ROLES |
ssl.<aktion> denied mit need |
SSL nur für Gruppentyp eigen |
Auth::sslAllowed() |
Reseller sehen die Konsole nicht |
| Datensatz der eigenen Gruppe | jede Abfrage mit group_id |
„Unbekannter Zugang“ + denied |
Werkzeuge in bin/ |
Guard: nur root/sudo oder Besitzer der Instanz |
Exit 3, nichts geschrieben |
Kurz: Die Gruppe sagt, wo du bist. Die Rolle sagt, was du dort darfst.
3. Wie hängen Produkte und Zusatzleistungen am Login?
Vier Schritte, und jeder hat einen anderen Verantwortlichen:
KATALOG FREIGABE BUCHUNG AKTIVIERUNG
(für alle) (je Gruppe) (je Person) (durch Inhaber)
products ──► group_products ──► user_products ──► state: active
+ categories aktiv, ab wann, Grundprodukt offered → active
Preisreferenz + Zusätze nur der Inhaber
admin admin admin / user Inhaber
Bucht ein User selbst, ist die Buchung sofort active.
Bucht der Admin für ihn, wartet sie als offered auf ihn.
Eine Buchung ist ein Baum, der an einem Login hängt:
user01@gruppe (Login)
│
├── VM Small #proxmox ← Grundprodukt: braucht einen Anker
│ anker: netbox:101 (welches Gerät?), bucht nur der admin
│ │
│ ├── Backup #addon ← Zusatz: hängt am Grundprodukt
│ ├── Monitoring #addon derselben Person
│ └── SSL #hosting
│
└── Server #baremetal
anker: mac:02:AA:BB:CC:DD:01
Beenden: erst die Zusätze, dann das Grundprodukt.
Regel ✅ (src/Catalog/Bookings.php) |
Code im Audit |
|---|---|
readonly bucht nichts |
rolle |
| Ein User bucht nur für sich, ein Admin nur in seiner Gruppe | nur_fuer_sich, fremde_gruppe |
| Ohne aktive Freigabe der Gruppe keine Buchung | keine_freigabe, noch_nicht_verfuegbar |
| Grundprodukt nur mit Anker und nur durch den Admin | anker_fehlt, nur_admin_grundprodukt |
| Zusatz nur unter einem eigenen, laufenden Grundprodukt | parent_fehlt, parent_ungueltig |
Admin-Dienste (Achse access) nur für Rolle admin |
nur_admin |
| Preis nur bei Kategorien mit Preisart „priced“ | kein_preis_erlaubt |
| Anker auf ein NetBox-Gerät ohne Kontobindung (Regel b) | kein_kontobezug |
| Aktivieren nur durch den Inhaber | nur_inhaber |
| Im Dashboard nur Zusätze beenden | nur_zusatz |
Wer sieht was? Die Systemakte (sot_ref, z. B. der NetBox-Link) sieht nur der Inhaber, nicht einmal der Admin der Gruppe. Preis und Schätzung sehen der Inhaber und der Admin der Gruppe.
Wo kommen CA und DNS ins Spiel? Der Anker verbindet die Buchung mit einem echten Gerät in NetBox. An diesem Gerät hängt später das Gerätezertifikat der eigenen CA (nur der Gerätename steht darin, keine MAC). Gekaufte SSL-Zertifikate laufen über den Registrar, die Domain wird per DNS bestätigt. ❓ Die Node-CA ist nicht in native_php. Sie läuft auf der Ansible-Node, ihr Ort für die ozm-Knoten ist offen.
4. Was landet im Audit-Log?
audit_log
┌─────┬──────────────┬─────┬─────┬─────────────┬────────┬──────┬───────────┐
│ id │ ts (UTC) │ user│group│ action │ result │ ip │ ctx (JSON)│
├─────┼──────────────┼─────┼─────┼─────────────┼────────┼──────┼───────────┤
│ 412 │ 10-12 17:02Z │ 7 │ 3 │ auth.login │ ok │ 10.… │ role │
│ 413 │ 10-12 17:03Z │ 7 │ 3 │ booking.add │ denied │ 10.… │ reason: │
│ │ │ │ │ │ │ │ keine_fr… │
└─────┴──────────────┴─────┴─────┴─────────────┴────────┴──────┴───────────┘
(Beispielzeilen, ausgedacht, gekürzt)
UPDATE ✗ Trigger: "audit_log ist append-only"
DELETE ✗ Trigger: "audit_log ist append-only"
Was hineinkommt ✅, nach Bereich:
auth.* login (ok, fail mit Grund, blocked_ip) · password · mfa
mfa_enroll · mfa_rotate · logout · session_timeout
session_revoked · account_locked · forbidden (Seite ohne Recht)
admin.* user_add · user_role · user_enable · user_passwd · user_unlock
user_reset_mfa · group_add · group_mfa
ssl.* jede Aktion der Konsole: requested · denied · Ergebnis
mit Rohantwort des Registrars und Pflicht-Grund beim Bestellen
booking.* offer · add · activate · end (auch jede Ablehnung)
catalog.* product_/category_ add · edit · active · delete
link · unlink · withdraw
(beim Löschen steht der gelöschte Datensatz drin)
web.*/cli.* SOAP- und NetBox-Zugänge: add · replace · test · delete
Kontobindung · netbox_view · netbox_sync · inventory_sync
migrate · key_rotate · user_* am Terminal (mit echtem Akteur)
module.denied Modul ohne Berechtigung aufgerufen
Wo der Registrar oder NetBox beteiligt ist, steht dazu der Code-Stand (ctx.build, Commit), also welcher Stand gelaufen ist und nicht nur welche Version.
Was nie hineinkommt ✅: Passwörter, TOTP-Secrets, SOAP-Zugangsdaten, NetBox-Token, private Schlüssel, die Systemakte.
Was bewusst drinsteht und wichtig ist ❓: E-Mail-Adresse und IP. Das sind personenbezogene Daten (DSGVO). Weil das Log nur anhängt, gibt es heute keine Löschfrist. Wie lange die Daten bleiben und wer das Log lesen darf (heute nur admin über auditlog.php), muss die Crew festlegen.
Auf einen Blick
┌───────────────┬──────────────────────────────┬────────────────────────────┐
│ Frage │ beantwortet durch │ Beleg │
├───────────────┼──────────────────────────────┼────────────────────────────┤
│ Wer? │ Login: Passwort + TOTP │ auth.login │
│ Wo? │ Gruppe │ group_id in jeder Zeile │
│ Was darf er? │ Rolle (1 bis 4) │ auth.forbidden / denied │
│ Was hat er? │ Buchungsbaum mit Anker │ booking.* │
│ Woran? │ Gerät in NetBox (Anker) │ netbox:<id> / mac / wg │
│ Was geschah? │ audit_log, nur anhängen │ Trigger gegen UPDATE/DELETE│
│ Welcher Code? │ Commit-Stempel │ ctx.build │
└───────────────┴──────────────────────────────┴────────────────────────────┘
Bezug zu NIS2, DSGVO, CA und DNS
Es geht hier um Bezug, nicht um Konformität. Eine Prüfung hat nicht stattgefunden.
- NIS2 (Art. 21 Abs. 2 lit. j: Multi-Faktor-Authentisierung): 2FA ist Pflicht für jedes Konto, Sperren und Audit sind gebaut. Die Grundlage steht im Kopf von
src/Auth/Auth.php. - DSGVO: Datensparsamkeit (Export ohne E-Mail, Systemakte nur für den Inhaber). ❓ Offen ist die Löschfrist des Audits.
- CA: Die eigene CA stellt nur für Geräte aus, die NetBox kennt, und nur an Konten mit Kontobindung. Der private Schlüssel bleibt auf dem Gerät.
- DNS: Eine Domain gilt erst als bestätigt, wenn der Registrar oder das DNS es zeigt. Eine Selbstmeldung reicht nie.
Offen ❓
- Löschfrist und Leserechte für das Audit (DSGVO).
- 3FA: welche Muster, ab wann, und wer entscheidet, dass 2FA „bewiesen“ ist.
- Ort der Node-CA für die ozm-Knoten.
- RZ-NetBox ohne Tenants: Wie wird ein Gerät einer Gruppe zugeordnet?
Quellen im Repo: native_php/src/Auth/Auth.php, src/Catalog/Bookings.php, src/Audit/Audit.php, src/Http/SslController.php, database/schema.sql. Ausführlich: docs/ARCHITEKTUR.md, docs/SECURITY.md, docs/DESIGN_KATALOG_BUCHUNGEN.md, docs/DESIGN_NETBOX_CONNECTOR.md.