Das Dilemma: öffentlich per Konstruktion

Die meisten selbst-gehosteten Dienste versteckt man hinter Single-Sign-On: Wer nicht angemeldet ist, kommt nicht mal an die Login-Maske. Sauber.

Bei einem Dokumenten-Server geht das nicht. Wenn man in der eigenen Cloud eine Tabelle öffnet, lädt der Browser den Editor direkt vom Dokumenten-Server — und der Browser sitzt im offenen Internet. Setzt man einen Auth-Gate davor, bricht die Kommunikation zwischen Editor und Cloud. Der Dienst muss also öffentlich erreichbar sein.

Ein kurzer Test von außen bestätigt es: Die Startseite antwortet mit einem schlichten OK. Erst dachte ich an ein Leck — aber das ist nur der Health-Check. Die eigentliche Frage ist nicht „ist es erreichbar?", sondern „was kann man erreichen?".

Zugriff schützen statt Erreichbarkeit

Der Denkfehler wäre, den Dienst verstecken zu wollen. Der richtige Ansatz: die Erreichbarkeit ist öffentlich, der Zugriff ist es nicht.

• Dokumente öffnen sich nur mit einem kurzlebigen Token, das ausschließlich die authentifizierte Cloud-Anwendung ausstellt — für berechtigte Nutzer, pro Sitzung. Ohne Token: Anfrage abgewiesen.
• Die Startseite verrät nichts außer „läuft" — kein Verzeichnis, keine Version, keine Funktion.

Die Admin-Fläche gehört nicht ins Internet

Ein Dokumenten-Server bringt eine Admin-Konsole mit — Live-Sitzungen, Speicher, Metriken. Die braucht im öffentlichen Netz niemand. Zwei Maßnahmen:

1. Öffentlich sperren. Am Reverse Proxy bekommt der Admin-Pfad einen eigenen Regelblock, der von außen konsequent mit 403 antwortet. Nichts, was ein Scanner findet, führt irgendwohin.

2. Nur intern öffnen. Erreichbar ist die Konsole ausschließlich über das private Overlay-Netz (VPN) — und dort bequem als Kachel im SSO-Portal, sichtbar nur für die Admin-Gruppe. Genau wie die anderen internen Werkzeuge: Man klickt im Portal, ist über das VPN schon „drin", und der Rest ist eine Frage der Gruppenzugehörigkeit.

Der unscheinbare, aber wichtige Teil: Entkopplung

Wie bringt man die Admin-Konsole ins VPN, ohne den öffentlichen Dienst zu gefährden? Naiv würde man den Port direkt an die VPN-Adresse binden. Das koppelt aber den Start des Dienstes an das VPN — und wenn nach einem Neustart die VPN-Adresse ein paar Sekunden zu spät kommt, startet der Dienst gar nicht. Ausgerechnet der öffentliche Editor hinge dann am internen Netz.

Die Lösung ist ein winziger, eigenständiger Weiterleiter: Er nimmt die VPN-Verbindung an und reicht sie lokal an den Dienst durch. Der Dienst selbst bleibt unangetastet und öffentlich; fällt die VPN-Adresse beim Booten kurz aus, versucht es nur der Weiterleiter erneut.

Sicherheitsheader — aber ohne den Editor zu erschlagen

Der letzte Schliff sind Sicherheitsheader. Und hier lauert die Falle: Man ist versucht, reflexartig alle „empfohlenen" Header zu setzen — inklusive strikter Regeln, wer die Seite in einen Rahmen (iframe) einbetten darf.

Nur: Der Editor wird absichtlich eingebettet — die Cloud-Anwendung zeigt ihn in einem Rahmen an. Eine strikte Frame-Regel hätte also genau die legitime Nutzung zerstört.

Deshalb: die unschädlichen Header setzen (Transportverschlüsselung erzwingen, MIME-Sniffing abschalten, Referrer sparsam) — und bei den Frame-Regeln bewusst zurückhaltend bleiben, statt eine Checkliste blind abzuhaken.

Gesetzt:   HSTS · nosniff · zurückhaltende Referrer-Regel
Bewusst weggelassen: strikte Frame-/CSP-Regel (würde den Editor-Embed brechen)

Von außen nachprüfen

Härtung, die man nicht misst, ist nur eine Vermutung. Der Abschluss war deshalb ein Test von außen und von innen:

• Öffentlicher Admin-Pfad → 403 ✅
• Editor validiert weiterhin Ende-zu-Ende ✅ (die Header haben nichts gebrochen)
• Admin-Konsole über das VPN → erreichbar, mit Login ✅
• Die Firewall-Grundregeln des Servers → unverändert ✅

Was man mitnimmt

• Nicht alles lässt sich verstecken. Wo Erreichbarkeit sein muss, verlagert man den Schutz auf den Zugriff — Tokens, Anmeldung, minimale Antworten.
• Admin-Flächen sind kein Internet-Material. Öffentlich sperren, intern über VPN + SSO öffnen.
• Entkoppeln, was nicht zusammengehören muss. Ein kleiner Weiterleiter hält den öffentlichen Dienst frei von internen Abhängigkeiten.
• Header mit Verstand. Die „beste" Sicherheitsregel ist wertlos, wenn sie die legitime Funktion zerstört.
• Messen, nicht glauben. Erst der Test von außen macht aus „müsste sicher sein" ein „ist nachweislich zu".

Sicherheit ist selten ein einzelner Schalter. Sie ist die Summe kleiner, bewusster Entscheidungen — und der Disziplin, jede davon einmal gegen die Realität zu prüfen.