Das eigene Relay absichern — Zugang, Gerätezertifikate und Schlüssel

Worum es geht

Ein eigenes Relay ist aus dem Internet erreichbar und vermittelt den Zugriff auf alle Ihre Geräte. Diese Seite ist eine Prüfliste: was Sie nach der Installation einstellen, damit nur die Richtigen hineinkommen, sich kein fremder Rechner als Ihr Gerät ausgibt und Ihre Schlüssel einen Serverausfall überstehen.

Das brauchen Sie

• Ein eigenes Relay (B2) und ein Konsolenkonto als System-Administrator.
• Zugriff auf den Server (Firewall, Umgebungsvariablen des Dienstes).

So geht's

1. Netz und Zertifikat

1. Ein echtes TLS-Zertifikat für den Namen des Relays hinterlegen — RSA mit der Kette „ISRG Root X1“ (B2).
2. In der Firewall nur öffnen, was das Relay braucht: 9013/tcp, 3478/udp, 5349/tcp und gegebenenfalls den Bereich „Relay-Ports von/bis“. Die Datenbank nie nach außen öffnen.
3. Das Relay ohne TLS-beendenden Reverse-Proxy betreiben. Es wertet nur die echte Gegenstelle aus. Hinter einem Proxy greifen die Bremsen je Adresse und die vertrauten Netze nicht.

2. Konsole

1. Benannte Konten anlegen und für jedes den zweiten Faktor einrichten (B4).
2. Der Notfall-Anmeldung (ohne Benutzername) ein langes Kennwort geben: Einstellungen → Admin-Zugang → Abschnitt „Admin-Passwort“ → Ändern. Die Notfall-Anmeldung hat keinen zweiten Faktor.
3. Die Konsole auf Ihre Netze beschränken: Admin-Zugang → Vertraute Netze (B7).

3. Geräte

1. Einstellungen → Geräte-Zertifikate (mTLS). Jedes Gerät bekommt beim Beitritt ein eigenes Zertifikat und weist sich damit aus — so kann sich kein fremder Rechner als bekanntes Gerät ausgeben.
2. Unter Durchsetzung zuerst „Vorgelegte Zertifikate prüfen“ einschalten. „Zertifikat erzwingen“ erst, wenn nachweislich alle Geräte per mTLS verbinden.
3. Geräte, die nach einer Neuinstallation kein Zertifikat mehr haben, warten unter Anmelde-Anfragen. Prüfen Sie sie und klicken Sie Freigeben.
4. Je Zugang festlegen, wer steuern darf: Mandant bearbeiten → Governance-Policy → Steuerung nur aus dem eigenen Mandanten (B6). Ohne diese Stufe genügen Kennung und Gerätekennwort.
5. Zentral gesetzte Gerätekennwörter aus älteren Fassungen bleiben mit einem schwächeren Verfahren gespeichert, bis Sie sie neu setzen: Geräte → Menü des Geräts → Passwort setzen.

4. Schlüssel und Sicherung

1. BD_KEYRING_KEY setzen. Mit diesem Wert verschlüsselt das Relay seinen Schlüsselring. Docker legt ihn bei der Installation in .env an. Unter Linux ohne den Wert liegt der Ring unverschlüsselt, und das Relay warnt beim Start. Unter Windows schützt Windows den Ring für diesen Rechner.
2. Den Wert getrennt vom Server sichern, zum Beispiel im Passwortmanager — nie in der relay.json und nie neben der Sicherung.
3. Eine Backup-Passphrase setzen (B8). Nur dann sichert das Relay seine Schlüssel mit.
4. Jeden Aufruf des Programms am Server (etwa --set-setting) mit derselben Umgebung starten wie den Dienst.

Daran sehen Sie, dass es geklappt hat

• Jede Konsolen-Anmeldung fragt nach dem Code.
• Im Startprotokoll des Relays steht keine Warnung mehr, dass der Schlüsselring im Klartext liegt.
• Der Sicherungsjob meldet keine fehlenden Nachweise mehr.

Gut zu wissen

• Verlust von BD_KEYRING_KEY heißt Verlust aller verschlüsselten Werte — Geräte-CA (alle Gerätezertifikate ungültig), Lizenz-Aktivierung, Kennwörter für Mail und Anmeldedienste.
• Ein Programmaufruf ohne den Wert bricht ab, wenn der Ring eingehüllt ist. Das ist gewollt; er würde sonst Schlüssel neu anlegen.
• Wartende Betrachter je Adresse: Höchstens fünf nicht angemeldete Betrachter dürfen von einer Adresse gleichzeitig auf ein Gerät warten (einstellbar unter Konfiguration → Server). Hinter einem Proxy teilen sich alle diese fünf.
• Ein einzelnes Gerät sperren: Geräte → Menü des Geräts → Sperren. Sein Zertifikat zurücksetzen: Zertifikat zurücksetzen — das nächste Beitreten stellt ein neues aus.
• Verdacht, dass eine Datenbank-Kopie in fremde Hände kam: Den Schlüssel für Anmelde-Tokens erneuert ein Aufruf der Verwaltungs-API; ein Formular dafür gibt es nicht. Danach müssen alle Programme neu beitreten. Schreiben Sie in diesem Fall an info@browserdesk.de.
• Den Server selbst härten Sie wie jeden anderen Server (SSH nur mit Schlüssel, Firewall, Updates des Betriebssystems). Dafür gibt BrowserDesk keine eigene Anleitung.

Wenn es nicht klappt