Private Statusseiten

Nicht jede Statusseite gehört ins offene Netz. Ein internes Portal, eine Plattform, die nur eine Handvoll Kunden nutzt, ein Dienst unter Vertraulichkeitsvereinbarung: Da ist die Information für einen klar umrissenen Kreis gedacht, nicht für Suchmaschinen.

Dafür kannst du eine Statusseite hinter ein Passwort legen, sie auf bestimmte Netzwerke beschränken — oder beides.

Verfügbar im Tarif Business. Wechselst du in einen kleineren Tarif, bleiben Passwort und Netzwerk-Beschränkung bestehen, bis du sie entfernst. Entfernen geht in jedem Tarif, neu setzen nur mit Business.

Einrichten

  1. Statusseiten → deine Seite → Reiter „Darstellung" → Sichtbarkeit
  2. Unter Passwortschutz ein Passwort eintragen (mindestens 8 Zeichen)
  3. Speichern

Ab sofort sehen Besucher ein Eingabefeld statt der Statusseite. Das Passwort gibst du selbst weiter — wir verschicken es nicht.

Ausnahme ist dein Team, und nur in der Vorschau. Angemeldet und mit bestätigter E-Mail-Adresse sieht dein Team die Seite über Vorschau im Dashboard ohne Passwort und ohne die Netzwerk-Prüfung weiter unten. Unter der eigenen Adresse der Seite gilt der Schutz für alle, auch für dein Team — teste ihn dort oder in einem privaten Browserfenster.

Ändern: Neues Passwort eintragen und speichern. Das alte gilt dann nicht mehr, und alle, die bereits eingeloggt waren, müssen sich neu anmelden. Das ist Absicht: Ein Passwortwechsel, der bestehende Sitzungen offen lässt, wäre keiner.

Aufheben: Der Schalter Passwortschutz entfernen erscheint, sobald ein Passwort gesetzt ist. Die Seite ist danach wieder für alle mit dem Link lesbar.

Das Feld zeigt nie das gesetzte Passwort an — wir speichern nur dessen Hash und können es auch selbst nicht auslesen. Wenn du es vergisst, setzt du ein neues.

Was geschützt ist

Alles, was die Seite veröffentlicht:

  • die Statusseite selbst und jede Vorfall- und Wartungsseite
  • die Verlaufsseite
  • der RSS-Feed und der Kalender-Feed
  • das eingebettete Status-Badge
  • die Status-API unter /summary.json

Wichtig für Badges: Ein Badge auf einer fremden Website hat keine Sitzung und bekommt deshalb nur noch eine Fehlermeldung statt eines Bildes. Wenn du Badges im Einsatz hast, entscheide dich: entweder Passwortschutz oder öffentlich eingebundene Badges. Beides zusammen funktioniert nicht.

Was nicht geschützt ist — und warum

Die Abmeldelinks in E-Mails an deine Abonnenten. Wer sich abmelden will, muss das können, ohne ein Passwort zur Hand zu haben. Jemanden zum Passwort zu zwingen, bevor er deine Mails abbestellen darf, wäre nicht nur unfreundlich, sondern rechtlich heikel. Verifizierungs-, Abmelde- und Verwaltungslinks funktionieren deshalb immer.

Die Seiten hinter diesen Links zeigen nur die Daten des jeweiligen Abonnenten, keine Vorfälle.

Auf Netzwerke beschränken

Statt oder zusätzlich zum Passwort kannst du festlegen, aus welchen Netzwerken die Seite überhaupt erreichbar ist. Typischer Fall: eine interne Statusseite, die nur aus dem Firmennetz und über den VPN-Ausgang geöffnet werden soll.

Unter Sichtbarkeit → Auf Netzwerke beschränken trägst du einzelne Adressen oder Bereiche ein:

203.0.113.4
10.0.0.0/8
2001:db8::/32

IPv4 und IPv6, einzelne Adressen und CIDR-Bereiche. Ein leeres Feld bedeutet: keine Beschränkung.

Wer von außerhalb kommt, sieht eine Hinweisseite mit der eigenen IP-Adresse — die kann er an die Person weitergeben, die die Liste pflegt. Geschützt ist dasselbe wie beim Passwort: Seite, Vorfälle, Wartungen, Verlauf, Feeds, Badge. Abmeldelinks funktionieren auch hier von überall.

Beides zusammen ist ein Und, kein Oder. Ist beides gesetzt, muss ein Besucher im erlaubten Netz sein und das Passwort kennen. Die Netzwerkprüfung kommt zuerst: von außerhalb wird gar nicht erst nach dem Passwort gefragt.

Prüfe deine eigene Adresse, bevor du speicherst. Trägst du ein Netz ein, in dem du selbst nicht bist, sperrst du dich von der öffentlichen Seite aus — das Dashboard bleibt davon unberührt, du kannst die Liste also jederzeit korrigieren.

Eine Einschränkung, die du kennen solltest: Verglichen wird die Adresse, mit der die Anfrage bei uns ankommt. Setzt du deine Statusseite hinter einen eigenen Proxy oder ein CDN, kommt dort dessen Adresse an, nicht die deiner Besucher. Sag uns Bescheid, wenn du so etwas vorhast.

Kein Ersatz für Zugangsverwaltung

Ein Passwort, das alle teilen, ist ein Passwort, das alle teilen. Du erfährst nicht, wer die Seite geöffnet hat, und wenn jemand das Unternehmen verlässt, musst du das Passwort für alle wechseln.

Für den Zweck, für den Statusseiten da sind — „läuft der Dienst gerade?" — ist das in aller Regel angemessen. Für alles darüber hinaus gehören die Details woanders hin.

Die Eingabeseite selbst wird nie von Suchmaschinen indexiert, unabhängig von deinen sonstigen Einstellungen.

Zu viele Fehlversuche

Die Eingabe ist auf 10 Versuche pro Minute und IP-Adresse begrenzt. Wer darüber liegt, bekommt für eine Weile eine Fehlermeldung. Das bremst automatisiertes Durchprobieren, ohne einem Kunden im Weg zu stehen, der sich zweimal vertippt.

Über die API

Setzen, ändern und entfernen geht auch über die REST-API:

# Setzen oder ändern
curl -X PATCH https://statuswerk.eu/api/v1/statuspage \
  -H "Authorization: Bearer $STATUSWERK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"access_password": "mindestens-acht-zeichen"}'

# Entfernen
curl -X PATCH https://statuswerk.eu/api/v1/statuspage \
  -H "Authorization: Bearer $STATUSWERK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"access_password": null}'

Die Netzwerkliste ebenso:

curl -X PATCH https://statuswerk.eu/api/v1/statuspage \
  -H "Authorization: Bearer $STATUSWERK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"access_ip_allowlist": ["203.0.113.4", "10.0.0.0/8"]}'

Eine leere Liste hebt die Beschränkung auf. Ungültige Einträge werden mit 422 abgelehnt, statt still nicht zu greifen.

Die API gibt das Passwort nie zurück. Das Feld is_password_protected sagt dir nur, ob eines gesetzt ist; access_ip_allowlist enthält die Liste im Klartext, die ist kein Geheimnis.

Ein Token mit dem Recht Nur lesen kann das Passwort nicht ändern — siehe API-Tokens.