Authentifizierung

Überblick

Ein Monitor, der ein 401 erhält, meldet einen Ausfall, der keiner ist. Jeder HTTP- und gRPC-Monitor kann deshalb eigene Zugangsdaten mitführen, ausgewählt im Block Authentifizierung des Anlegedialogs und der Bearbeitungsansicht.

Verfahren	Was gesendet wird	Verfügbar für
Basic Auth	Authorization: Basic <Benutzer:Passwort>	HTTP, gRPC
Bearer-Token	Authorization: Bearer <Token>	HTTP, gRPC
API-Schlüssel	Ein benannter Header oder ein URL-Parameter	HTTP, gRPC (nur Header)
Sitzungscookie	Ein roher Cookie-Header	HTTP, gRPC
OAuth2 Client Credentials	Ein von Ihrem IdP geholtes Token, dann Bearer	HTTP
Client-Zertifikat (mTLS)	Ein Client-Zertifikat während des TLS-Handshakes	HTTP

Monitors für Datenbanken, SMTP, IMAP und Redis melden sich stattdessen mit einem eigenen Benutzer-/Passwort-Paar an — siehe Datenbanken und Mail & Cache.

Wo die Geheimnisse leben

Jedes Geheimnis auf dieser Seite ist im Ruhezustand verschlüsselt, in einer von der Monitor-URL getrennten Spalte. Liest man einen Monitor zurück — über das Dashboard, die öffentliche API, das Audit-Log oder einen DSGVO-Export —, kommen das Verfahren und seine nicht geheimen Einstellungen zurück (Token-Endpunkt, Header-Name, Client-ID), das Geheimnis selbst ersetzt durch ***.

Diese Maskierung erhält auch das Bearbeitungsformular. Lassen Sie ein maskiertes Feld unverändert, bleibt der gespeicherte Wert erhalten; tragen Sie etwas anderes ein, wird er ersetzt. Deshalb müssen Sie nie ein Token neu eingeben, um eine unabhängige Einstellung zu ändern.

Ein API-Schlüssel, der in der URL übergeben wird, ist überall maskiert, wo die URL angezeigt oder protokolliert wird — so, wie Zugangsdaten der Form https://benutzer:passwort@host beim Speichern aus der URL herausgelöst werden.

Bearer-Token

Der häufigste Fall: ein statisches Token, das der überwachte Dienst ausgibt.

Authorization: Bearer eyJhbGciOiJIUzI1NiIs…

Fügen Sie nur das Token ein — das Präfix Bearer ergänzt OKStatus.

API-Schlüssel

Zwei Formen, weil sich die Dienste auf beide verteilen:

• Header — X-API-Key: <Schlüssel> oder der Name, den der Dienst erwartet.
• URL-Parameter — ?api_key=<Schlüssel>, bei jeder Prüfung an die Monitor-URL angehängt.

Bevorzugen Sie den Header, wenn der Dienst beides akzeptiert: Ein Schlüssel in einer URL landet in den Zugriffsprotokollen des Ziels, und die liegen außerhalb unserer Reichweite.

Sitzungscookie

Für einen Endpunkt, der nur einer angemeldeten Browsersitzung antwortet. Fügen Sie den rohen Inhalt des Cookie-Headers ein:

session=abc123; csrf=def456

Ein Sitzungscookie läuft ab — meist innerhalb von Stunden oder Tagen. Dann schlagen die Prüfungen mit dem Statuscode der Anmeldeseite fehl. Nutzen Sie das für eine kurzfristige Diagnose, nicht als Dauerlösung; dafür sind OAuth2 oder ein API-Schlüssel die tragfähige Antwort.

OAuth2 Client Credentials

Für eine API hinter Entra ID, Keycloak, Auth0, Okta oder einem beliebigen OAuth2-Autorisierungsserver, der den Grant client_credentials unterstützt (RFC 6749 §4.4).

Einstellung	Beschreibung
Token-Endpunkt	z. B. https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token
Client-ID	Die Kennung der Anwendung
Client-Secret	Verschlüsselt gespeichert
Scope	Optional — api://monitoring/.default, read:status …
Audience	Optional — von Auth0 verlangt, von den meisten anderen ignoriert
Zugangsdaten gesendet als	client_secret_basic (HTTP-Basic-Header, Standard) oder client_secret_post (Formular-Body)

Vor jeder Prüfung holt der Regions-Agent ein Token und behält es bis zum Ablauf (30 s Sicherheitsabstand). Ein Monitor, der alle 30 Sekunden aus fünf Regionen läuft, fragt Ihren IdP also einige Male pro Stunde an — nicht vierzehntausendmal am Tag.

Schlägt der Token-Endpunkt selbst fehl, scheitert die Prüfung mit der eindeutigen Meldung OAuth2 authentication failed: …, die den Token-Endpunkt benennt: Ein IdP-Ausfall ist kein Ausfall des überwachten Dienstes, und beide werden nicht am selben Ort behoben.

Client-Zertifikat (mTLS)

Für einen Endpunkt, der ein Client-Zertifikat verlangt: interne APIs, Banken, Gesundheitswesen, IoT.

Einstellung	Beschreibung
Client-Zertifikat	PEM. Von Natur aus öffentlich, wird trotzdem verschlüsselt gespeichert
Privater Schlüssel	PEM, unverschlüsseltes PKCS#8. Verschlüsselt gespeichert, nie von der API zurückgegeben
Zertifizierungsstelle	PEM, optional — für eine interne PKI, deren CA nicht öffentlich vertraut wird

Ein passwortgeschützter Schlüssel wird beim Speichern abgelehnt, statt angenommen und dann stillschweigend unbrauchbar zu sein: Die Regions-Agenten legen das Zertifikat über native-tls vor, das ihn nicht entschlüsseln kann. Wandeln Sie ihn vorher um:

openssl pkcs8 -topk8 -nocrypt -in verschluesselt.key -out monitoring.key

Das Zertifikat des Servers wird weiterhin gegen die öffentlichen Wurzelzertifikate geprüft (oder gegen die CA, die Sie angeben). Die Option TLS-Prüfung überspringen am Monitor schaltet diese Prüfung ab, auch für die mTLS-Verbindung.

gRPC-Monitors

gRPC-Prüfungen senden dieselben Zugangsdaten als Metadaten: Basic, Bearer, API-Schlüssel im Header oder Cookie. Zwei Formen haben keine Entsprechung und werden ausdrücklich abgelehnt, statt stillschweigend ignoriert zu werden:

• ein API-Schlüssel im URL-Parameter — ein gRPC-Aufruf hat keinen Query-String;
• OAuth2 und mTLS — am gRPC-Kanal noch nicht angebunden.

Was nicht abgedeckt ist

AWS SigV4, selbst signierte JWTs, HMAC-Signaturen je Anfrage, NTLM und Kerberos sind noch nicht verfügbar. Wiederverwendbare, zwischen Monitors geteilte Zugangsdaten (einmal definiert, überall referenziert) stehen auf der Roadmap; heute trägt jeder Monitor seine eigenen.