← Zum vorherigen Versionsunterschied Zum nächsten Versionsunterschied →

Version vom 26. Oktober 2026, 11:21 Uhr

Öffentliche Freigabe

Apps auf mobilen Geräten und externe Systeme erreichen den REST-Server nur, wenn er aus dem Internet erreichbar ist. Diese Seite stellt die drei Wege dafür gegenüber und richtet sich an die IT-Administration, die über die Freigabe entscheidet.

HINWEIS: Der REST-Dienst läuft auf dem OBS-Server oder auf einem eigenen Server. Auf dem OBS-Server läuft häufig auch die Datenbank. Die Varianten unterscheiden sich vor allem darin, ob eine Verbindung aus dem Internet den Server des REST-Dienstes direkt erreicht. Ein Zertifikat ist in allen Varianten nötig, auch im VPN, weil die App nur per HTTPS verbindet.

Varianten im Vergleich

Merkmal	Direkte Portfreigabe	Reverse-Proxy	VPN
Aus dem Internet erreichbar	Server des REST-Dienstes: Port des REST-Servers, bei Prüfart http-01 zusätzlich Port 80	nur der Proxy (Port 443)	nur das VPN-Gateway
Aufwand für die Nutzer der App	keiner	keiner	VPN-Client einrichten und vor der Nutzung einschalten
Aufwand für die IT	Portweiterleitung am Router	Proxy betreiben, Zertifikat am Proxy	VPN-Zugang für jedes Gerät
Filtern und Protokollieren vor dem REST-Dienst	–	✓	nur auf Netzebene
Zertifikat	im REST-Server, Prüfart http-01 oder dns-01	öffentlich am Proxy, dazu eines im REST-Server für die Strecke vom Proxy	im REST-Server, Prüfart dns-01
REST-Server sieht die IP-Adresse des Geräts	✓	nur im Protokoll (über X-Forwarded-For)	✓, sofern das VPN-Gateway die Adressen nicht umsetzt (NAT)

Schutz durch den REST-Server

Unabhängig von der Variante schützt sich der REST-Server selbst. Diese Mechanismen greifen in allen drei Varianten:

Verschlüsselung: ausschliesslich TLS 1.2 mit Forward Secrecy und AEAD-Verfahren. Unverschlüsselte Anfragen an einen TLS-Port werden vor jeder Verarbeitung abgewiesen. Optional mTLS: jeder Client braucht ein gültiges Client-Zertifikat.
Zugänge: Jede Anfrage braucht einen gültigen API-Key, wahlweise zusätzlich JWT. Jeder Zugang ist nur für die Endpunkte freigeschaltet, die er braucht, und lässt sich auf eine Absenderadresse beschränken. API-Keys lassen sich ohne Unterbrechung tauschen.
Widerrufbare Sitzungen: Eine Abmeldung wirkt sofort. Ein Refresh-Token gilt genau einmal; wird ein verbrauchtes erneut vorgelegt, sperrt der Server die ganze Sitzung.
Grenzen gegen Missbrauch: getrenntes Rate-Limit für erfolgreiche und fehlgeschlagene Anfragen, eine Obergrenze gleichzeitiger Anfragen und Verbindungen sowie Grössengrenzen für Anfragen und Uploads.
Keine Informationen nach aussen: Fehlerantworten enthalten nie interne Details. Die stehen nur im Protokoll, mit einer Korrelations-ID je Anfrage. Kennwörter und Token werden dort maskiert.
Kurze Öffnung für die Zertifikatsprüfung: Bei http-01 öffnet der Dienst Port 80 nur für die Dauer der Prüfung.

Diese Mechanismen schützen den REST-Dienst. Reverse-Proxy und VPN fügen eine Schicht davor hinzu: Sie halten den Server des REST-Dienstes aus dem Internet heraus, und mit ihm häufig auch den OBS-Server und die Datenbank. Das wirkt auch gegen Schwachstellen ausserhalb des REST-Servers und gegen Überlastung. Der Router leitet den Port des REST-Servers aus dem Internet auf den Server des REST-Dienstes weiter. Für die Zertifikatserneuerung mit der Prüfart http-01 wird zusätzlich Port 80 weitergeleitet.

Vorteile

Die einfachste Einrichtung, es wird keine weitere Komponente gebraucht.
Die App funktioniert überall, ohne dass die Nutzer etwas tun müssen.
Der REST-Server sieht die IP-Adresse jedes Geräts. Alle Schutzmechanismen des REST-Servers, auch Host-Beschränkung und Rate-Limit, arbeiten damit je Gerät.

Nachteile

Der Server des REST-Dienstes ist direkt aus dem Internet erreichbar. Läuft der REST-Dienst auf dem OBS-Server, gilt das für den OBS-Server und häufig auch für die Datenbank. Die Schutzmechanismen des REST-Servers greifen, eine zusätzliche Schicht davor gibt es aber nicht.
Mit der Prüfart http-01 ist zusätzlich Port 80 weitergeleitet. Mit der Prüfart dns-01 entfällt das.

Reverse-Proxy

Ein Reverse-Proxy, zum Beispiel in einer DMZ oder als Funktion der Firewall, nimmt HTTPS auf Port 443 an. Er prüft die Anfrage und reicht sie über eine eigene, ebenfalls verschlüsselte Verbindung an den REST-Server weiter.

Vorteile

Der Server des REST-Dienstes ist aus dem Internet nicht erreichbar, nur der Proxy.
Am Proxy lassen sich Anfragen nach Ihren Vorgaben filtern, drosseln und protokollieren.
Für die Nutzer der App ändert sich nichts.
Das öffentliche Zertifikat liegt am Proxy. Für die Strecke vom Proxy genügt im REST-Server ein Zertifikat Ihrer internen Zertifizierungsstelle oder ein selbst signiertes. Es muss vor Ablauf getauscht werden.

Nachteile

Der Proxy muss betrieben und gepflegt werden.
Der REST-Server sieht als Absender nur den Proxy. Die Host-Beschränkung eines Zugangs kann keine Geräte unterscheiden, und Anfragen ohne API-Key teilen sich einen Zähler des Rate-Limits. Die IP-Adresse des Geräts steht nur im Protokoll, wenn der Proxy den Header X-Forwarded-For setzt.

Die Einrichtung beschreibt Betrieb hinter einem Reverse-Proxy.

VPN

Die Geräte verbinden sich per VPN mit dem Netz, in dem der REST-Dienst läuft. Die App spricht durch den Tunnel per HTTPS mit dem REST-Server. Aus dem Internet ist nur das VPN-Gateway erreichbar.

Vorteile

Für den REST-Server ist kein Port aus dem Internet offen.
Nur Geräte mit VPN-Zugang erreichen den REST-Server.
Setzt das VPN-Gateway die Adressen nicht um, sieht der REST-Server die VPN-Adresse jedes Geräts.

Nachteile

Jedes Gerät braucht einen VPN-Client und einen eigenen Zugang. Ohne zentrale Geräteverwaltung schalten die Nutzer das VPN von Hand ein. Ist es aus, meldet die App, dass der Server nicht erreichbar ist.
Ein VPN-Zugang öffnet den Weg ins Netz. Beschränken Sie ihn auf die Adresse und den Port des REST-Servers.
Das Zertifikat lässt sich nur mit der Prüfart dns-01 erneuern, weil die Zertifizierungsstelle den Server nicht erreicht.
Der Name des REST-Servers muss auf dem Gerät auf die interne Adresse zeigen. Das geht über einen DNS-Server, den das VPN mitliefert, oder über einen öffentlichen DNS-Eintrag mit der internen Adresse. Manche Router verwerfen solche Antworten als Schutz gegen DNS-Rebinding; dann löst der Name in diesem Netz nicht auf.

Das Zertifikat richten Sie wie unter Zertifikatserneuerung beschrieben mit der Prüfart dns-01 ein.

REST-Dienst auf einem eigenen Server

Der REST-Dienst muss nicht auf dem OBS-Server laufen. Er lässt sich auch auf einem eigenen Server betreiben, zum Beispiel in einer DMZ. Voraussetzung ist, dass dieser Server

per SMB auf den OBS-Server zugreifen kann und
die Datenbank erreicht.

Der eigene Server lässt sich mit jeder der drei Varianten kombinieren. Bei der direkten Portfreigabe zeigt die Weiterleitung dann auf diesen Server statt auf den OBS-Server.

Vorteile

Eine Verbindung aus dem Internet erreicht weder den OBS-Server noch die Datenbank direkt, auch bei direkter Portfreigabe.
Die Verarbeitung der Anfragen läuft nicht auf dem OBS-Server. Die Datenbank wird weiterhin belastet.

Nachteile

Ein weiterer Server muss betrieben und gepflegt werden.
Vom eigenen Server ins interne Netz müssen SMB und der Port der Datenbank offen sein. Beschränken Sie diese Wege auf den OBS-Server und den Datenbankserver.

Entscheidungshilfe

Keine eingehende Verbindung zum OBS-Server erlaubt, DMZ oder Firewall mit Proxy-Funktion vorhanden: Reverse-Proxy.
Keine eingehende Verbindung zum OBS-Server erlaubt, aber kein Proxy vorhanden: REST-Dienst auf einem eigenen Server in einer DMZ, mit direkter Portfreigabe auf diesen Server.
Geräte werden zentral verwaltet oder ein VPN ist ohnehin im Einsatz: VPN.
Kleine Installation ohne Vorgaben der IT: Direkte Portfreigabe, möglichst mit der Prüfart dns-01, damit Port 80 geschlossen bleibt.

Siehe auch

@@ Zeile 5: / Zeile 5: @@
 Apps auf mobilen Geräten und externe Systeme erreichen den REST-Server nur, wenn er aus dem Internet erreichbar ist. Diese Seite stellt die drei Wege dafür gegenüber und richtet sich an die IT-Administration, die über die Freigabe entscheidet.
-{{Hinweis|Der REST-Dienst läuft auf dem OBS-Server oder auf einem [[#REST-Dienst auf einem eigenen Server|eigenen Server]]. Auf dem OBS-Server läuft häufig auch die Datenbank. Die Varianten unterscheiden sich vor allem darin, ob eine Verbindung aus dem Internet den Server des REST-Dienstes direkt erreicht.}}
+{{Hinweis|Der REST-Dienst läuft auf dem OBS-Server oder auf einem [[#REST-Dienst auf einem eigenen Server|eigenen Server]]. Auf dem OBS-Server läuft häufig auch die Datenbank. Die Varianten unterscheiden sich vor allem darin, ob eine Verbindung aus dem Internet den Server des REST-Dienstes direkt erreicht. Ein Zertifikat ist in allen Varianten nötig, auch im VPN, weil die App nur per HTTPS verbindet.}}
 == Varianten im Vergleich ==
@@ Zeile 19: / Zeile 19: @@
 | Filtern und Protokollieren vor dem REST-Dienst || – || ✓ || nur auf Netzebene
 |-
-| Öffentliches Zertifikat || im REST-Server, Prüfart http-01 oder dns-01 || am Proxy || im REST-Server, Prüfart dns-01
+| Zertifikat || im REST-Server, Prüfart http-01 oder dns-01 || öffentlich am Proxy, dazu eines im REST-Server für die Strecke vom Proxy || im REST-Server, Prüfart dns-01
 |-
 | REST-Server sieht die IP-Adresse des Geräts || ✓ || nur im Protokoll (über ''X-Forwarded-For'') || ✓, sofern das VPN-Gateway die Adressen nicht umsetzt (NAT)
@@ Zeile 52: / Zeile 52: @@
 * Am Proxy lassen sich Anfragen nach Ihren Vorgaben filtern, drosseln und protokollieren.
 * Für die Nutzer der App ändert sich nichts.
-* Das öffentliche Zertifikat liegt am Proxy. Die Zertifikatserneuerung des REST-Servers wird nicht gebraucht.
+* Das öffentliche Zertifikat liegt am Proxy. Für die Strecke vom Proxy genügt im REST-Server ein Zertifikat Ihrer internen Zertifizierungsstelle oder ein selbst signiertes. Es muss vor Ablauf getauscht werden.
 '''Nachteile'''