Antwort OZMAI — TLS-Gate v3.16.0 / NetBox-Live-Test / Login ĂŒber dem Modul

Von: OZMAI → Branko / Crew
Stand: 13. Oktober 2026
Bezug: 2026-10-12_TLS-GATE-V3-16-0-NETBOX-ZUGAENGE-IM-WEB-UND-LIVE-TEST-SEEDS-NACHTRAG_BRANKO.md, 2026-10-12_TLS-GATE-LOGIN-UEBER-DEM-MODUL-HANDOUT-NACHTRAG_BRANKO.md
Charakter: Gegendruck / RĂŒckmeldung. Keine automatische OZM-Geltung fĂŒr TLS-Gate-Entscheidungen.

Branko ❀ diesmal trĂ€gt vor allem der Live-NetBox-Lauf. Er zeigt nicht nur, dass der Connector sprechen kann, sondern wo eine lokale Verwaltungsannahme an einer zweiten realen Umgebung nicht mehr trĂ€gt.

1. Tenant ist eine lokale Grenze, keine universelle Gruppengrenze

FĂŒr seeds.crumbforest.io ist Tenant eine echte NetBox-Struktur und kann dort als scoped Verwaltungsgrenze funktionieren.

FĂŒr die RZ-NetBox meldest du dagegen: keine Tenants.

Damit:

TENANT_BOUNDARY(crumbforest_netbox)
⇏ UNIVERSAL_GROUP_BOUNDARY

Das ist fĂŒr uns wichtiger als die Frage, ob Site oder Tag „besser“ wĂ€re. Bitte nicht vorschnell das RZ so umbauen, dass es zum bereits gebauten Connector passt. Erst prĂŒfen, welche Relation dort wirklich die gewĂŒnschte Gruppierung trĂ€gt.

Die Passkante soll die beiden RĂ€ume verbinden; sie soll nicht eine lokale Ontologie auf den anderen Raum ĂŒbertragen.

2. NetBox sagt ... bleibt administrative Aussage

Der Live-Lauf Àndert die IdentitÀtsgrenze nicht:

NETBOX_RECORD
⇏ OBSERVED_PHYSICAL_DEVICE

netbox:<id> kann ein sehr guter stabiler Verwaltungsanker sein. MAC, WG-Key, IP usw. sind Eigenschaften/Bindungen in diesem Inventarscope. Eine Änderung kann einen starken PrĂŒfgrund erzeugen, aber noch keine physische Attestierung.

Schritt 4 mit GerÀte-Zertifikaten wird deshalb besonders interessant: Die Zertifikatsausstellung darf sichtbar halten, auf welcher administrativen und gegebenenfalls zusÀtzlich beobachteten Grundlage sie beruht.

3. Sehr guter Gegendruck: ein roter Test kann der PrĂŒfer sein

Der Locale-Fall von test_device_cert ist fĂŒr uns ein echter Gewinn:

RED_TEST ⇏ PRODUCT_DEFECT

Der Testparser war unter de_DE.UTF-8 falsch konfiguriert, wÀhrend das Zertifikat selbst die erwartete Laufzeit hatte.

Damit gehört in einen belastbaren Finding-Scope nicht nur der getestete Code, sondern auch die Bedingungen des Verifiers/Testharness. Genau solche FĂ€lle brauchen wir spĂ€ter fĂŒr den automatisierten Gegendruck.

4. Die SSL-Normalisierung ist jetzt besser als vorher

Danke fĂŒr die Korrektur aus v3.15.0.

Die bestÀtigte Relation ist nur:

SSL-<n> ↔ <n>

Nicht automatisch:

ssl-4 = SSL-04 = SSL-4

Dass unbestĂ€tigte Schreibvarianten jetzt roh bleiben und form_nicht_normalisiert von kein_katalogeintrag getrennt wird, ist genau die gewĂŒnschte kontrollierte Reduktion:

CONFIRMED_EQUIVALENCE
⇏ PLAUSIBLE_EXTRA_EQUIVALENCE

Unsere eigene Brain-Notiz war an dieser Stelle bereits zu weit und wird korrigiert.

5. „Login steht ĂŒber dem Modul“: mechanisch verstĂ€ndlich, semantisch bitte enger

Als Betriebsbild trÀgt das Handout gut: zentrale Session, Gruppen-/Rollenmodell, Module benutzen die vorhandene Authentisierung und Policy-Infrastruktur.

Ich wĂŒrde aber drei SĂ€tze nicht als allgemeine Semantik ĂŒbernehmen.

Erstens:

AUTHENTICATED_SESSION ⇏ physische oder persönliche IdentitĂ€t vollstĂ€ndig festgestellt

Gerade der qr-MFA-Fall zeigt schon, dass „Passwort + TOTP“ nicht automatisch unabhĂ€ngig etablierte zwei Faktoren bedeutet.

Zweitens:

ROLE ⇏ vollstĂ€ndige Authorization

Die Rolle ist ein Eingang. Aktion, Gruppenscope, Objektzustand, Kontobindung und weitere Policies entscheiden im konkreten Pfad mit.

Drittens: möglich oder nicht darf eine deterministische Entscheidung sein, aber nicht zu einer Wahrheitslogik werden:

ALLOW / DENY
≠ TRUE / FALSE ĂŒber die Welt

Ein System darf bei unzureichender Grundlage fail-closed DENY sagen, ohne damit zu behaupten, die zugrunde liegende Weltfrage vollstÀndig geklÀrt zu haben.

6. „3FA“ noch nicht als dritten Faktor festschreiben

Verhaltens-/Bewegungsmuster im Nullfeld sind als spĂ€tere Sonde interessant. Ich wĂŒrde sie bis zu einem realen Mechanismus aber noch nicht Faktor 3 nennen.

Vorher mĂŒsste der konkrete Claim klar sein:

Was wird beobachtet?
Wie wird es an einen Login gebunden?
Welche Fehlerraten gibt es?
Welche Umgehung ist möglich?
Welche Wirkung darf daraus folgen?

Bis dahin ist es eher ein möglicher zusÀtzlicher Beobachtungs-/Risikosignal-Pfad als bereits ein authentifizierender Faktor.

7. Der nÀchste wertvolle Versuch

FĂŒr uns ist jetzt nicht noch ein neues Diagramm am wichtigsten, sondern:

  1. Welche Relation trĂ€gt in der RZ-NetBox tatsĂ€chlich die gewĂŒnschte Gruppengrenze?
  2. Kann der Connector diese Relation lesen, ohne die Crumbforest-Tenant-Semantik still zu importieren?
  3. Welche Aussage trÀgt ein GerÀte-Zertifikat danach wirklich?
  4. Kann ein absichtlich widersprĂŒchlicher Verwaltungsstand (z. B. Slot gleich, MAC geĂ€ndert, WG-Key unverĂ€ndert oder umgekehrt) unterschiedliche Findings erzeugen, ohne automatisch „GerĂ€t X ist es / ist es nicht“ zu behaupten?

Wenn wir diese FĂ€lle real fahren, haben wir eine echte Passkante statt nur ein Integrationsschema. đŸŒČ🩉