Der Nexun Infrastruktur-Bericht: Wie Sieben Automatisierte Checks Und Eine Signierte JSON Unser No-Logs-Versprechen Woechentlich Beweisen

Die meisten VPN-"Transparenzberichte" sind jaehrliche PDFs, geschrieben von derselben Marketing-Abteilung, die auch die Verkaufsseite verfasst hat. Unserer ist anders. Jede Woche laesst ein geplanter Job auf unserer Produktions-Infrastruktur sieben automatisierte Checks gegen das Live-System laufen, schreibt das Ergebnis als signierte JSON-Payload in eine Datenbank-Zeile und veroeffentlicht es auf nexun.io/transparency/infrastructure. Das Ergebnis ist eine kryptografisch verifizierbare Attestation, wie das Nexun-Backend jetzt gerade tatsaechlich aussieht — und zwei beliebige Wochen koennen direkt verglichen werden, um zu sehen, dass sich nichts darunter veraendert hat.

Was die Report-Karte auf einen Blick zeigt

Oben auf /transparency/infrastructure steht die Report-Karte. Sie enthaelt vier Dinge: eine Report-ID wie 2026-W16-093318 (ISO-Jahr, ISO-Woche, Zeitstempel), ein Generierungs-Datum sekundengenau, eine Gesamt-Statuspille ("Alle Checks bestanden" oder "Zu pruefen"), und einen 64 Zeichen langen SHA-256 Content-Hash. Dieser Hash wird ueber die kanonische JSON-Payload berechnet. Wird ein einziges Byte der Payload geaendert, wird der Hash zu einer komplett anderen Zeichenkette. So weisst du, dass die Seite, die du liest, nicht manipuliert wurde.

Die sieben Checks, erklaert

Unter dem Header siehst du einen Zusammenfassungs-Block mit sieben Zeilen, jede als pass oder fail markiert. Jede Zeile wird von einer anderen automatisierten Probe erzeugt, die auf der echten Maschine laeuft — keine statische Konfigurationsdatei. Das beweist jede Zeile:

• Keine Logdateien auf Disk — die Probe scannt /var/log/wireguard, /var/log/nexun und /var/log/openvpn. Existiert eines dieser Verzeichnisse oder enthaelt Dateien, schlaegt der Check fehl. Ein bestandenes Ergebnis bedeutet: es gibt keinen Ort auf Disk, wo Verbindungs-Logs landen koennten, selbst wenn etwas zu schreiben versuchte.
• API-Oberflaeche enumeriert — FastAPI introspektiert seine eigene Routing-Tabelle und listet jeden gemounteten Prefix mit seinen HTTP-Methoden (/admin mit 33 Endpoints, /beta mit 62, /transparency mit 5). Es geht nicht um die Zahlen — sondern darum, dass die vollstaendige Form der API oeffentlich ist. Keine versteckten Routen.
• Daten-Inventar dokumentiert — die Probe liest das Live-PostgreSQL-Schema fuer vpn_users, vpn_subscriptions, vpn_support_tickets und billing_events und klassifiziert jede Spalte (identifier, contact, payment, operational, timestamp, credential, unknown). Wird in Produktion eine neue Spalte hinzugefuegt, die nicht im Inventar steht, schlaegt der Check fehl.
• User-Tabellen haben keine IP-Spalten — die Probe sucht in jeder Nutzer-Tabelle nach Spalten namens client_ip, ip_address, ip, remote_ip, created_ip, last_ip oder source_ip. Ein einziger Treffer wuerde den Check fehlschlagen lassen. Das Passergebnis bedeutet: die Datenbank hat buchstaeblich keine Spalte, in der eine IP gespeichert werden koennte.
• Datenbank-Query-Logging deaktiviert — PostgreSQL-Einstellungen werden live gelesen: log_duration=off, log_statement=none, log_connections=off, log_disconnections=off, log_min_duration_statement=-1. Wenn jemand eine dieser Flags je anschaltete "um etwas zu debuggen", faengt der Report das innerhalb von 7 Tagen ab.
• Keine Analytics-SDKs in Abhaengigkeiten — die Probe parst die genau installierten Python-Pakete der laufenden API (22 Pakete) und vergleicht sie mit einer Deny-Liste: sentry-sdk, datadog, newrelic, mixpanel, segment-analytics-python, posthog, rollbar, bugsnag, google-analytics, amplitude, heap, fullstory. Ein Passergebnis bedeutet: keine der ueblichen stillen Daten-Abfluss-Bibliotheken ist in der Umgebung.
• Keine Audit- oder Log-Extensions installiert — die Probe queryt pg_extension gegen eine Deny-Liste: pgaudit, pg_stat_statements, pg_qualstats, auto_explain. Das sind Postgres-Extensions, die Query-Historie leise protokollieren. Nur pgcrypto und plpgsql sind installiert — beide notwendig, keine davon loggt irgendetwas.

Die Schema-Erlaeuterungen — warum wir die "unheimlichen" Spalten zeigen

Der Bericht enthaelt ausserdem eine kurze Erlaeuterungs-Sektion. Einige unserer Spaltennamen wirken neben einem "keine Logs"-Versprechen alarmierend, und statt sie in einem Hinterzimmer zu verstecken, erklaeren wir sie alle auf derselben Seite. Verstecken wuerde den Zweck dieser Seite zerstoeren.

• vpn_support_tickets.log_data — ein Debug-Paket, das ein Nutzer freiwillig an ein Support-Ticket anhaengt. Abgeriegelt durch das include_logs-Boolean in derselben Zeile. Wird nie fuer normalen VPN-Verkehr geschrieben; nur, wenn jemand im Support-Formular bewusst "Logs anhaengen" anklickt.
• vpn_users.test_password — ein Klartext-Passwort fuer App-Store- und Google-Play-Reviewer-Konten. Apple und Google verlangen beide einen funktionierenden Test-Login, um App-Updates freizugeben. Ein Datenbank-CHECK-Constraint (chk_test_password_only_for_test) macht es physisch unmoeglich, diese Spalte in einer Zeile zu setzen, in der is_test_account false ist.
• vpn_users.notes — ein Freitext-Feld fuer Betriebs-Notizen (Refund-Kontext, Support-Follow-ups). Nie fuer andere Nutzer sichtbar; nur von Level-9-Admins lesbar. Jede DSGVO-Auskunftsanfrage enthaelt dieses Feld im Export.
• vpn_subscriptions.raw — die exakte Webhook-Payload, die wir von Stripe / Apple / Google fuer jedes Subscription-Ereignis empfangen, woertlich gespeichert, um Billing-Disputes rekonziliieren zu koennen. Enthaelt keine Information jenseits dessen, was der Payment-Provider selbst bereits ueber dieselbe Transaktion hat.

Die vollstaendige JSON-Payload und wie du sie selbst pruefst

Ganz unten auf der Report-Seite rendern wir das exakte JSON-Dokument, ueber das der SHA-256 berechnet wurde. Jeder kann hindurchscrollen: die Checks, die Findings-Arrays, jede Tabelle und jede Spalte im Daten-Inventar, die Postgres-Einstellungen, die installierten Extensions, die Dependency-Liste und die Summary. Das Format ist stabil (schema_version: 2), sodass zwei Reports aus verschiedenen Wochen direkt verglichen werden koennen. Zur Pruefung des Hashes kanonisierst du die JSON (sortierte Keys, kein extra Whitespace) und berechnest einen SHA-256 ueber die Bytes. Stimmt dein Ergebnis mit dem Hash in der Header-Karte ueberein, ist der Bericht intakt. Stimmt es nicht, ist etwas faul und wir moechten davon wissen.

Was sich zwischen Wochen aendert

Weil der Bericht automatisch aus dem Live-System erzeugt wird, aendert er sich, wenn sich das System tatsaechlich aendert. In einer typischen Woche kann sich total_packages leicht aendern, wenn wir Dependencies updaten, oder der endpoint_count unter /beta, wenn wir Beta-Features hinzufuegen oder abschalten. Was sich nie aendern sollte ist die Menge der Kategorien ("keine IP-Spalten", "kein Query-Logging", "keine Analytics-SDKs", "keine Audit-Extensions") — jede Aenderung hier wuerde overall_pass auf false setzen und eine rote "Zu pruefen"-Pille statt der gruenen zeigen. Siehst du das je, schulden wir dir eine Erklaerung, und der Bericht ist so gebaut, dass die Erklaerung unausweichlich ist.

Warum das ehrlicher ist als ein jaehrliches PDF

Ein jaehrliches PDF ist ein Snapshot, von Menschen geschrieben. Es kann neu redigiert, umformuliert und still nachgereicht werden. Eine woechentliche signierte Attestation, die die Maschine selbst erzeugt, kann das nicht. Die Datenbank-Zeile jedes Reports ist nach ISO-Woche geschluesselt; der Hash steht zum Zeitpunkt der Erstellung fest; und jede Zeile der Payload ist ein direktes Lesen aus der Live-Infrastruktur. Muessten wir je stillschweigend eine Aussage abschwaechen, wuerden die Checks fehlschlagen und die Seite wuerde es zeigen. Das ist der echte Unterschied zwischen Privatsphaere versprechen und Privatsphaere beweisen.

Wie du den Bericht als Nutzer nutzt

Oeffne nexun.io/transparency fuer einen Blick auf die aktuelle Woche: Canary-Farbe, Infrastructure-Statuspille, SHA-256-Fingerabdruck. Klick weiter auf /transparency/infrastructure, um jeden Check zu lesen. Setz ein Lesezeichen und oeffne die Seite eine Woche spaeter — Report-ID (2026-Wxx-...) und Hash muessen beide veraendert sein, als Beweis, dass die Attestation live ist. Aendert sich etwas im "never-log"-Abschnitt oder der Check-Liste ohne oeffentliche Ankuendigung von uns, behandle das als Anlass fuer Nachfragen. Genau dafuer gibt es diesen Bericht.