Ihre Uptime-Überprüfung sagt, dass die Anwendung in Ordnung ist. In der Zwischenzeit kann sich niemand anmelden, weil der Identitätsanbieter, der davor sitzt, eine Zeitüberschreitung hat. Für jede Anwendung hinter einer Identity and Access Management (IAM)-Authentifizierung ist der Login Teil des Produkts, und ein Monitor, der an der Login-Hürde stoppt, überwacht das falsche Element. Die Faustregel lautet: Behandle die Authentifizierung wie benutzerorientierten Anwendungscode, selbst wenn der IdP zu einem Anbieter gehört, denn Benutzer erleben niemals „App läuft, Login ausgefallen“ als Teilausfall – für sie ist das Produkt einfach nicht vorhanden.
Authentifizierte Anwendungen sind der klassische Blinde Fleck in der synthetischen Überwachung. Ein einfacher HTTP-Check bekommt von der öffentlichen Login-Seite ein gesundes 200 zurück, während die SSO-Weiterleitungskette, die MFA-Herausforderung oder der Token-Austausch dahinter defekt sind. Die einzige Möglichkeit zu sehen, was ein angemeldeter Benutzer sieht, ist, den gesamten Ablauf einschließlich der Zugangsdaten, des zweiten Faktors usw. zu skripten und zeitgesteuert auszuführen.
Das wirft die Fragen auf, die dieser Leitfaden beantwortet: Wie skripten Sie durch eine SSO-Weiterleitungskette? Was tun Sie mit MFA-Codes, die zur Verhinderung von Automatisierung entwickelt wurden? Wo bewahren Sie die Zugangsdaten auf, damit sie nicht durchsickern? Und wie erkennen Sie, ob ein langsamer Login Ihr App-Problem oder das Ihres Identitätsanbieters ist?
Was ist Identity and Access Management (IAM)?
Identity and Access Management ist das Framework aus Richtlinien und Diensten, das entscheidet, wer auf welche Ressourcen zugreifen darf, und dies beim Anmelden beweist. In der Praxis bedeutet das, dass ein zentraler Identitätsanbieter (IdP) wie Okta, Microsoft Entra ID, Auth0 oder Ping die Authentifizierung für viele Anwendungen über Single Sign-On (SSO) übernimmt, meist über SAML oder OpenID Connect, mit Multi-Faktor-Authentifizierung (MFA) obendrauf. Wenn Sie die Protokollmechanik im Detail möchten, sehen Sie unser Begleitstück über wie Identitätsmanagement und Authentifizierung funktionieren. Für Überwachungszwecke ist eine Eigenschaft am wichtigsten: Der Login-Pfad geht jetzt über Systeme, die Sie nicht vollständig kontrollieren, und jeder von ihnen kann unabhängig von Ihrer Anwendung ausfallen.
Warum authentifizierte Anwendungen schwer zu überwachen sind
Vier Dinge machen IAM-geschützte Anwendungen schwerer zu überwachen als eine öffentliche Seite.
Die Login-Hürde blendet einfache Checks aus. Ein HTTP-Verfügbarkeitscheck kann nur bestätigen, dass die Login-Seite gerendert wird. Alles, wofür Benutzer tatsächlich bezahlen, liegt hinter der Authentifizierung, sodass ein Ausfall im Anmeldefluss oder in der Anwendung selbst unsichtbar bleibt, bis sich jemand beschwert.
Der Ablauf umfasst mehrere Parteien. Ein einmaliger Anmeldevorgang berührt Ihre Anwendung, Ihren IdP, den MFA-Dienst und oft einen Token-Endpunkt, jeweils auf einer eigenen Domain mit eigener DNS-, TLS- und Infrastruktur. Ihre Anwendung kann völlig gesund sein, während ein Ausfall eines Drittanbieter-IdP alle aussperrt. Dasselbe Abhängigkeitsproblem tritt bei Anwendungen auf, die SSO verwenden im Allgemeinen.
SSO ist eine Weiterleitungskette, keine Seite. SAML- und OAuth/OIDC-Flows leiten den Browser über zwei oder drei Domains weiter, tauschen Assertions oder Autorisierungscodes aus und setzen dabei Sitzungscookies. Ein Anfrage-Tool, das kein JavaScript ausführt und Weiterleitungen nicht wie ein echter Browser verfolgt, wird den Ablauf bei jedem Schritt falsch melden.
MFA existiert, um Skripts zu stoppen. Einmalige Codes, Push-Prompts und CAPTCHAs sind bewusst gegen Automatisierung gerichtet. Die Überwachung muss mit der Richtlinien-Engine des IdP arbeiten, nicht gegen sie, was Planung erfordert, die ein einfacher Uptime-Check nie brauchte.
Karten Sie die SSO-Weiterleitungskette, bevor Sie sie skripten
Bevor Sie etwas aufzeichnen, gehen Sie den Login einmal in einem Browser mit offenen Entwickler-Tools durch und notieren Sie jeden Schritt. Ein typischer SP-initiierter Flow sieht so aus: Der Benutzer fordert die Anwendung an, wird zum IdP weitergeleitet, die IdP-Login-Seite wird gerendert, Zugangsdaten werden übermittelt, eine MFA-Herausforderung erscheint, der IdP sendet eine SAML-Assertion oder gibt einen OAuth-Autorisierungscode an Ihre Callback-URL zurück, die Anwendung tauscht diesen gegen eine Sitzung ein, und die erste authentifizierte Seite lädt.
Jeder Schritt in dieser Kette ist ein eigenständiger Ausfallpunkt: DNS-Auflösung der IdP-Domain, ein abgelaufenes Zertifikat an der Callback-URL, ein langsames IdP-Seiten-Rendering, ein Timeout beim Token-Austausch. Die von Ihnen notierten Schritte werden zu den Checkpoints Ihres Skripts und den Grenzen, an denen Sie später Zeitaufteilungen vornehmen möchten.
Beachten Sie, welche Domains Ihnen gehören und welche einem Anbieter zugeordnet sind. Diese Unterscheidung verwandelt eine Warnung in eine Routing-Entscheidung: Ein Fehler auf der IdP-Domain geht an das Identity-Team oder die Statusseite des Anbieters, ein Fehler an der Callback-URL geht an Ihr Anwendungsteam. Wenn Ihre Architektur auch OAuth für APIs nutzt, verdient der Token-Endpunkt einen eigenen Anfrage-Level-Check; siehe Monitoring von JWT-Tokens und OAuth-Token-Endpunkten, um direkt die Token-Ausgabe zu überwachen.
Die Domain-Karte ist auch der Grund, warum die Statusseite Ihres IdP nicht Ihr eigenes Monitoring ersetzen kann. Ein grünes „All Systems Operational“-Banner bedeutet, dass der Dienst des Anbieters global verfügbar ist; es sagt nichts über die SAML-Konfiguration Ihres Mandanten, das Zertifikat an Ihrer Callback-URL oder den Netzwerkpfad zwischen Ihren Benutzern und deren Login-Seite aus. Das End-to-End-Skript ist der einzige Check, der die Frage Ihrer Benutzer tatsächlich beantwortet.
Wie man einen authentifizierten Login-Ablauf Schritt für Schritt skriptet
Schritt 1: Erstellen Sie ein dediziertes Überwachungskonto. Richten Sie einen dienstartigen Testbenutzer in Ihrem IdP ein, der nur für die Überwachung existiert: geringste Privilegien, kein Zugriff auf echte Kundendaten und ein erkennbarer Name wie svc-synthetic-monitor, damit seine Logins leicht in Audit-Logs identifizierbar sind.
Schritt 2: Zeichnen Sie den Login als mehrstufige Browser-Transaktion auf. Verwenden Sie ein echtes Browser-Skript-Tool wie EveryStep, um die vollständige Sequenz zu erfassen: Öffnen der Anwendungs-URL, Weiterleitung zum IdP folgen, Zugangsdaten eingeben, absenden und auf der authentifizierten Seite landen. Ein echter Browser ist wichtig, da er JavaScript ausführt, domänenübergreifenden Weiterleitungen folgt und Cookies genau wie der Browser eines Benutzers verwaltet.
Schritt 3: Entscheiden Sie Ihre MFA-Strategie, bevor Sie das Skript beenden. Die Optionen und ihre Vor- und Nachteile werden im nächsten Abschnitt behandelt. Wählen Sie bewusst; ein Skript, das nur funktioniert, weil MFA zufällig zwischengespeichert wurde, wird später an einem willkürlichen Punkt fehlschlagen.
Schritt 4: Prüfen Sie auf etwas, das nur ein angemeldeter Benutzer sehen kann. Das Erreichen einer URL ist kein Beweis für einen Login. Validieren Sie ein Element nach dem Login, wie die Überschrift des Dashboards oder den Anzeigenamen des Kontos, mit Inhaltsprüfungen. Viele Fehlanmeldungen landen auf einer gestalteten Fehlerseite, die HTTP 200 zurückgibt, und nur eine Assertion fängt das ab.
Schritt 5: Verlängern Sie das Skript um eine Aufgabe nach dem Login. Öffnen Sie einen Datensatz, führen Sie eine Suche durch, laden Sie einen Bericht. Eine erfolgreich authentifizierte Anmeldung, während die dahinterliegende Anwendung defekt ist, ist ein echter Fehlerzustand, und ein zusätzlicher Schritt deckt diesen ab. Die Struktur ist dieselbe wie bei jedem Web-Transaktionsüberwachungsskript: Jede Benutzeraktion ist ein Schritt, und jeder Schritt wird gemessen.
Schritt 6: Setzen Sie Schwellenwerte und Warnungen pro Schritt. Geben Sie jedem Schritt sein eigenes Zeitbudget und verknüpfen Sie Fehler mit Ihren Alarmregeln, damit eine Meldung lautet „MFA-Schritt hat Schwellenwert überschritten“ und nicht nur „Login langsam“.
Schritt 7: Führen Sie es von dort aus, wo Ihre Benutzer sind. Externe Standorte für eine öffentliche SaaS-Anwendung; ein privater Agent in Ihrem Netzwerk für interne Anwendungen, deren IdP- oder App-Schicht vom öffentlichen Internet nicht erreichbar ist.
Umgang mit MFA und OTP in synthetischen Skripten
MFA ist der Punkt, an dem die meisten authentifizierten Überwachungsprojekte ins Stocken geraten, da der gesamte Sinn des zweiten Faktors darin besteht, dass ein Passwort allein, wie es ein Skript natürlich hat, nicht ausreicht. Es gibt vier praktikable Strategien, und die richtige hängt davon ab, wie viel des MFA-Schritts Sie durchlaufen müssen und wie strikt Ihr Sicherheitsteam Ausnahmen kontrolliert.
| Strategie | Wie es funktioniert | Kompromiss | Beste Anwendung |
|---|---|---|---|
| Bedingte Zugriffsausnahme | IdP-Richtlinie überspringt MFA für das Testkonto, wenn es sich von bekannten Monitoring-IP-Adressen anmeldet | Der MFA-Schritt selbst wird nicht getestet; erfordert strenge IP-Begrenzung | Teams, deren IdP netzwerkbasierte Richtlinien unterstützt |
| TOTP-Seed im Skript | Testkonto registriert sich in einem Authenticator; das Skript speichert den Seed in einem Tresor und berechnet den aktuellen Code zur Laufzeit | Seed ist ein dauerhaftes Geheimnis, das gesichert und rotiert werden muss | Vollständiges Durchlaufen und Timen des echten MFA-Schritts |
| Email- oder SMS-OTP-Abruf | Skript pollt ein Test-Postfach oder SMS-Endpunkt nach dem Einmal-Code und gibt ihn ein | Langsam und zustellungsabhängig, daher mehr Fehlalarme | Apps, die nur Code per E-Mail oder SMS anbieten |
| App-Passwörter / Umgehungscodes | Ein statisches sekundäres Anmeldecredential umgeht die interaktive Herausforderung | Schwächste Option; viele IdPs stellen diese aus | Altsysteme ohne besseren Ansatz |
Der TOTP-Ansatz verdient die Standardposition, wenn Ihr IdP ihn erlaubt. Weil zeitbasierte Codes aus einem gemeinsamen Seed mittels eines dokumentierten Algorithmus generiert werden, kann ein Skript zur Laufzeit einen gültigen Code produzieren und die echte Herausforderung durchlaufen, sodass der Monitor den MFA-Schritt timet, statt ihn zu überspringen. Für eine detaillierte Anleitung dieser Methode, siehe wie man OTP-geschützte Webanwendungen überwacht.
Was immer Sie wählen, beschränken Sie es ausschließlich auf das Monitoring-Konto. Eine MFA-Ausnahme oder ein Umgehungscode, der auf mehr als einen einzelnen Least-Privilege-Testbenutzer angewendet wird, beschränkt auf Quell-IP, verwandelt eine Überwachungsbequemlichkeit in eine Angriffsfläche. Ihr Sicherheitsteam sollte den Mechanismus absegnen, und die Ausnahme sollte in deren Richtlinienüberprüfungen auftauchen.
Sichere Aufbewahrung von Monitoring-Zugangsdaten
Ein Login-Monitor ist eine Menge gültiger Zugangsdaten, die zeitgesteuert ausgeführt werden, und sollte mit der gleichen Sorgfalt behandelt werden wie jede andere Service-Anmeldeinformation.
Leihen Sie nie das Konto eines Menschen. Echte Konten zeigen echte Daten in Screenshots und Aufzeichnungen, brechen den Monitor bei jeder Passwortänderung und verunreinigen Sicherheitsprotokolle mit Aktivitäten, die niemand zuordnen kann. Das stattdessen zu erstellende Konto sollte die Blast-Radius-Frage bestehen: Wenn diese Anmeldeinformationen durchsickern, was könnte jemand sehen oder ändern, bevor sie deaktiviert werden? Die richtige Antwort ist langweilig – keine Admin-Rollen, keine Kundendatensätze, keine Möglichkeit, langlebige Tokens zu erstellen.
Sichern Sie die Geheimnisse im Tresor. Passwörter, TOTP-Seeds und Client-Geheimnisse gehören in verschlüsselte Speicher, auf die das Skript zur Laufzeit zugreift, etwa Dotcom-Monitors Secure Vault, niemals im Skripttext, wo sie in Exporten, Versionsverläufen und geteilten Bildschirmen auftauchen. Maskierung sollte auch auf Logs, Screenshots und Videoaufzeichnungen des Monitors ausgeweitet werden.
Rotieren Sie Zugangsdaten planmäßig und notieren Sie es im Kalender. Credential-Rotation ist gute Hygiene, und ein abgelaufenes Testkonto-Passwort ist auch die häufigste Ursache falscher Login-Alarmmeldungen. Rotieren Sie den Tresoreintrag, nicht die Skripte, damit eine Aktualisierung überall propagiert wird, und setzen Sie eine Erinnerung vor jeder von Ihrem IdP erzwungenen Ablaufregel.
Machen Sie synthetische Logins erkennbar. Ein klar benanntes Konto und bekannte Quell-IP-Adressen ermöglichen Ihrem Sicherheitsteam, den Monitor von Credential-Stuffing-Versuchen zu unterscheiden, und erlauben es Ihnen, dessen Sessions aus Produktanalysen auszuschließen, damit er die Nutzungszahlen nicht verfälscht.
Sitzungsablauf, Token-Aktualisierung und erneute Login-Logik
Sitzungen sind der Ort, an dem authentifizierte Monitore still verkümmern. Zwei gegensätzliche Verhaltensweisen verursachen Probleme: Ein Monitor, der eine zwischengespeicherte Sitzung wiederverwendet, testet den Login überhaupt nicht mehr, und ein Monitor, der eine halb abgelaufene Sitzung übernimmt, schlägt auf Arten fehl, die die Anwendung einem echten Nutzer nie zeigte.
Die Regel, die beides verhindert: Starten Sie jeden geplanten Durchlauf mit einer sauberen Browsersitzung, ohne Cookies oder Tokens aus der vorherigen Ausführung. Ein frischer Start erzwingt bei jedem Zyklus die vollständige Weiterleitungskette, die Übergabe der Zugangsdaten und MFA, sodass ein IdP-Ausfall beim nächsten Lauf sichtbar wird, statt hinter einem noch gültigen Cookie versteckt zu bleiben.
Auch die Sitzungs-Persistenz ist testenswert, aber bewusst und separat. Wenn Ihre Anwendung auf stumme Token-Aktualisierung setzt, um Benutzer angemeldet zu halten, bauen Sie eine längere Transaktion, deren spätere Schritte nach Ablauf der Zugriffs-Token-Lebensdauer ausgeführt werden, und prüfen Sie, ob der Benutzer am Ende noch angemeldet ist. Ein Aktualisierungsfehler zeigt sich, wenn Benutzer mitten in einer Aufgabe zur Login-Seite zurückgeworfen werden, was genau das Symptom ist, das dieses Skript reproduziert.
Auf API-Ebene kann die Token-Ausgabe sogar ganz ohne Browser überwacht werden: Ein Anfrage-Level-Check gegen den OAuth-Token-Endpunkt verifiziert, dass Tokens bei jedem Zyklus ausgegeben und akzeptiert werden. Dotcom-Monitors OAuth API Monitoring bearbeitet diesen Ablauf und ergänzt gut das Browser-skript, da beide zusammen zwischen „IdP kann keine Tokens ausgeben“ und „Anwendung kann sie nicht verarbeiten“ unterscheiden.
Zeitmessung pro Schritt: Wo ein authentifizierter Ablauf langsamer wird
„Login dauerte neun Sekunden“ ist nicht aussagekräftig. Neun Sekunden wo? Ein authentifizierter Ablauf überschreitet mindestens zwei Organisationen, daher hängt der Wert des Monitors davon ab, diese Gesamtdauer an den zuvor kartierten Grenzen aufzuteilen: initiale Weiterleitung, Seiten-Rendering des IdP, Validierung der Zugangsdaten, MFA-Herausforderung, Assertion- oder Token-Austausch und das Laden der ersten authentifizierten Seite.
Skripted Browser-Schritte geben genau diese Aufteilung, da jeder Schritt unabhängig gemessen wird und eigene Anforderungs-Wasserfälle mitbringt. Legen Sie für jeden Schritt einen Normalbereich als Baseline fest, statt einzelne Durchläufe zu bewerten, und alarmieren Sie bei Abweichungen auf Schritt-Ebene, damit eine Verschlechterung bei einer Etappe auffällt, selbst wenn die End-zu-End-Gesamtzeit noch akzeptabel ist.
Die Zeitmessung pro Schritt macht aus einer Debatte eine Routing-Entscheidung. Wenn das Rendering der IdP-Seite sich verdoppelte, geht das Ticket mit Zeitstempeln an den Identity-Anbieter. Verdoppelte sich das Laden der Nach-Callback-Seite, geht es an Ihr Anwendungsteam. Ohne die Aufteilung zeigen beide aufeinander.
Das Routing wird präziser, wenn jeder Schritt vom Tag der Kartierung mit einem Eigentümer-Tag versehen ist: app-eigen (Callback-URL, Sitzungserstellung, erste authentifizierte Seite), IdP-eigen (Login-Seiten-Rendering, Zugangsdaten-Validierung, Token-Austausch), richtliniengesteuert (MFA-Herausforderung, Conditional-Access-Entscheidungen, Zustimmungsprompts) und netzwerkgesteuert (DNS, TLS, Proxies, Erreichbarkeit privater Agenten). Eine Warnung mit dem Text „richtliniengesteuerter Schritt hat sich geändert“ startet eine Incident-Übergabe statt einer Debatte im Krisenraum.
Schritt-basierte Baselines fangen außerdem das langsam schleichende Fehlerbild auf, das binäre up/down-Checks vollständig übersehen: Ein MFA-Dienst, der sich über einen Monat von einer auf fünf Sekunden verschlechtert, löst nie einen Ausfallalarm aus, degradieren aber jede einzelne Anmeldung, und das ist klar in der Schritt-Zeit-Trendlinie sichtbar. Beobachten Sie den Login-Ablauf so, wie Sie jede Login-Seite überwachen würden, und lassen Sie die Schritt-für-Schritt-Daten Ihnen sagen, welche Seite der SSO-Grenze Aufmerksamkeit braucht.
Das Fazit
Die Überwachung einer IAM-geschützten Anwendung bedeutet, den Authentifizierungspfad als Teil der Anwendung zu überwachen, weil er es für Ihre Benutzer ist. Das bewährte Rezept: Karten Sie die SSO-Weiterleitungskette, skripten Sie den vollständigen Login als mehrstufige Echt-Browser-Transaktion unter einem dedizierten Least-Privilege-Konto, behandeln Sie MFA bewusst mit einer eingeschränkten Ausnahme oder einem gesicherten TOTP-Seed, bewahren Sie jedes Geheimnis in verschlüsseltem Speicher auf, starten Sie jeden Durchlauf mit einer sauberen Sitzung und teilen Sie Zeiten auf jeden Schritt auf, damit Fehler beim ersten Alarm an das richtige Team weitergeleitet werden.
Tun Sie das, und die Login-Hürde ist kein blinder Fleck mehr. Sie wissen, dass der IdP langsam ist, bevor der Helpdesk es weiß, Sie wissen, ob ein Fehler bei Ihnen oder Ihrem Anbieter liegt, und Sie haben die Schritt-für-Schritt-Aufzeichnung, um jeden Fall zu belegen.
Überwachen Sie hinter der Login-Hürde
Skripten Sie Ihren vollständigen SSO-Login als Echt-Browser-synthetische Überwachung-Transaktion mit EveryStep, sichern Sie die Zugangsdaten im Tresor und messen Sie jede Phase des Ablaufs. Starten Sie eine kostenlose Testversion.
