Conditional Access lässt sich nicht mit einer einfachen Erlaubnisliste verwalten
Die moderne Zugriffsentscheidung besteht nicht mehr nur aus der Frage „Ist der Benutzername korrekt?". Die richtige Entscheidung muss die Identität des Benutzers, den Vertrauenszustand des Geräts, den Standort, die Zeit, die Sensibilität des zugegriffenen Service, das angeforderte MFA-Niveau und Risikoänderungen innerhalb der Sitzung gemeinsam betrachten.
Statische Regeln und flache Erlaubnislisten können diese Komplexität nicht tragen. Mit der Zeit wird jede Ausnahme zu einer neuen Regel, jede Anwendung zu einem neuen Sonderfall, jedes Risikosignal zu einem separaten Kontrollpunkt. Das Ergebnis ist ein Richtlinienberg, den niemand von Anfang bis Ende lesen kann und bei dem im Audit nicht klar erklärt werden kann, warum er erlaubt oder warum er abgelehnt hat.
Manche Lösungen verlagern diese Entscheidung in eine separate Richtlinien-Cloud. Das wiederum macht den kritischsten Moment der Authentifizierung von einer externen API abhängig. Wenn Identität, MFA, Service-Routing und Audit auf unterschiedliche Systeme verteilt sind, wird der Zugriffspfad unsichtbar; die Organisation sieht nur das Ergebnis, nicht wie die Entscheidung zustande kam.
Conditional Access sollte hingegen eine einzige Entscheidungs-Engine sein, die neben Ihren Identitäten und Services läuft. Jeder Schritt sollte sichtbar, jede Bedingung erklärbar, jede Entscheidung auditierbar sein.
Denn Zugriffssicherheit betrifft nicht nur, wer eintrat, sondern in welchem Kontext, mit welcher Stärke der Verifizierung und mit welcher Begründung der Zugriff gewährt wurde.
Unser Ansatz
Eine Flow-Engine, die Authentifizierung, MFA, Entscheidungen und Routing in einer einzigen servicebasierten Definition besitzt.
Jeder Service betreibt seinen eigenen Zugriffs-Flow
Ein Zugriffs-Flow verkettet Login, MFA, Entscheidungspunkte, Switches, Lockout-Verwaltung und Access-Granted/Denied-Terminals. Jeder Service deklariert seinen eigenen Flow; eine Intranet-Anwendung mit geringem Risiko bleibt schlicht, ein privilegierter Admin-Pfad bleibt streng — ohne beide in dieselbe Form zu zwingen.
Pattern-basierte Verzweigung über jede Variable
Switch-Knoten routen über jede Variable, die der Flow sehen kann — Sitzungseigenschaften, Anfrage-Header, ausgewertete Templates, Upstream-Signale von Ihrem Edge — mit fünf Match-Modi (exact, prefix, suffix, contains, regex) und optionaler Case-Insensitive-Option. Entscheidungen werden als Pattern-Matching ausgedrückt, nicht als Skript.
Signale vom Edge fließen in den Flow ein
Geolokalisierung, IP-Reputation, Risikoscore, Netzwerkzone — alles, was Ihr Edge berechnen kann, kann als Anfrage-Header injiziert und von einem Switch oder Entscheidungspunkt gelesen werden. Der Flow bleibt die einzige Quelle; Signale von außerhalb des Gateways speisen den Flow, ohne einen externen Dienst in den Authentifizierungspfad einzubringen.
Jeder Übergang steht im Audit-Log
Jede Aktionsauswertung — welcher Schritt lief, was der Input war, welcher Zweig gewählt wurde, welches Terminal erreicht wurde — fällt in einen strukturierten Audit-Flow. Operatoren spielen Sitzungen Schritt für Schritt erneut ab; Sicherheitsteams korrelieren Zugriffsentscheidungen über SIEM-Streaming mit dem Rest der Telemetrie.
Fähigkeiten
Die Flow-Engine im Detail, die Bausteine, aus denen Richtlinienregeln bestehen, und die geplanten Erweiterungen, um sie auszubauen.
Flow-Engine — eine einzige Kette für Auth, MFA, Entscheidung und Routing
Eine einzige Engine orchestriert Login, Multi-Faktor-Challenge, Lockout-Verwaltung, Entscheidungspunkte, Switch-Routing und Access-Granted-/Access-Denied-Terminals. Jeder Schritt ist eine Aktion mit expliziten Übergängen; der Pfad von der anonymen Anfrage zur authentifizierten Sitzung ist ein zusammengesetzter Graph statt verstreuter Konfiguration.
Servicebasierte Flow-Definition
Jeder Service registriert seine eigene Flow-Definition. Ein SaaS-Proxy kann nur SSO anfordern; eine interne Anwendung kann TOTP hinzufügen; ein Produktionssystem kann TOTP plus ein frisches OTP plus einen expliziten Entscheidungspunkt verketten. Die Richtlinie eines Service zu ändern wirkt sich nicht auf die anderen aus.
Switch — mehrwegiges Routing nach Pattern-Matching
Die Switch-Aktion wertet eine konfigurierbare Variable aus (Header, Sitzungseigenschaft, AAM-Template) und routet den Flow durch Abgleich mit einer geordneten Pattern-Liste zu einer Ziel-Aktion. Fünf Match-Modi — exact, prefix, suffix, contains, regex — zusammen mit optionaler Case-Insensitivität; deckt alles von der Rollenprüfung bis zum Regex-Match auf dem Anfragepfad ab.
Entscheidungspunkte für Ja/Nein-Verzweigung
DecisionPoint-Aktionen teilen den Flow je nach Vorhandensein eines konfigurierten Signals in zwei Pfade. Heute ist das Signal ein Anfrage-Header, der von Ihrem Edge (CDN, Upstream-Richtlinienmodul oder Netzwerk-Gateway) gesetzt wird; die Aktionsoberfläche hält die Flow-Struktur konstant, während die darunterliegende Bedingung weiterentwickelt wird, um reichhaltigere Ausdrücke auszuwerten.
AAM-Template-Variablen in Bedingungen
In die Flow-Konfiguration eingebettete Variablen — Benutzeridentität, Gruppenmitgliedschaft, Service-ID, Umgebung, benutzerdefinierte Sitzungseigenschaften — werden zur Auswertungszeit über die AAM-Template-Engine aufgelöst. Dieselbe Template-Syntax, die in Branding, Routing und Fehlermeldungen verwendet wird, treibt auch Richtlinienentscheidungen; Operatoren lernen eine einzige Substitutionssprache und verwenden sie überall.
Flow-gesteuertes Step-up und verkettetes MFA
Da MFA innerhalb desselben Flows eine Aktion ist, kann Conditional Access einen zweiten Faktor nur auf bestimmten Zweigen anfordern — zum Beispiel TOTP anfordern, wenn der Switch eine Admin-Rolle erkennt, oder TOTP plus frisches OTP verketten, wenn die Route ein Terminal mit hoher Sensibilität erreicht. Die Eskalation lebt in der Richtlinie, nicht in der Benutzerwahrnehmung.
Operative Tiefe
Die Mechanik, die das sichere Ausrollen und einfache Auditieren von Richtlinienänderungen ermöglicht.
Schrittbasiertes Audit mit Input und Ergebnis
Jede Aktionsauswertung im Flow schreibt einen strukturierten Audit-Eintrag — Aktions-ID, Aktionstyp, Input-Variablen, gewählter Zweig, erreichtes Terminal, Latenz. Sitzungen werden in einer einzigen Timeline-Ansicht Schritt für Schritt erneut abgespielt, statt aus verstreuten Logs rekonstruiert zu werden.
Über Redis koordinierte zustandslose Flow-Ausführung
Der Flow-Zustand lebt in Redis; so kann jede Gateway-Instanz jede Sitzung in jedem Schritt übernehmen. Horizontale Skalierung und Rolling Upgrades ohne Ausfall verlieren keinen laufenden Authentifizierungszustand; Operatoren können mehrere Gateway-Pods hinter einem Application Delivery Controller ohne Koordinationsaufwand betreiben.
Über den Flow hinweg koordinierte Sperrung
Fehlgeschlagene Faktorversuche, abgelehnte MFA-Challenges und Access-Denied-Terminals speisen dieselben Sperrzähler, die die Login-Attack-Protection-Schicht der Plattform verwendet. Ein Benutzer kann einen fehlgeschlagenen Faktor nicht per Brute-Force angreifen, während er einen parallelen Versuch auf einem Switch-Zweig in einem anderen Schritt offenhält.
Versionierte Flow-Konfiguration
Flow-Definitionen leben in der an das Gateway ausgelieferten JSON-Konfiguration; Konfigurationsänderungen können pro Umgebung gestaffelt, überprüft und ausgerollt werden. Die Kombination aus versionierter Konfiguration und schrittbasiertem Audit macht die Frage „Warum kam dieser Benutzer gestern hinein?" aus einer einzigen Quelle beantwortbar.
In welchen Szenarien es genutzt wird
Servicebasierte MFA-Durchsetzung
Dieselbe Flow-Engine, die den Benutzer authentifiziert, entscheidet, ob ein bestimmter Service MFA erfordert, welcher Faktor angewendet wird und ob der Vertrauenswürdiges-Gerät-Shortcut gültig ist. Die MFA-Richtlinie ist kein separates Produkt — sie ist ein Knoten im Zugriffs-Flow dieses Service.
Geo- und IP-Reputations-bewusster Zugriff
Edge-Komponenten (CDN, IP-Reputations-Feeds, Netzwerk-Gateway) injizieren Geo- und Reputations-Header; die Switches und Entscheidungspunkte des Flows verzweigen über diese Signale — lehnen zum Beispiel Anmeldungen von bekannten bösartigen Netzwerken ab oder leiten Hochrisiko-Regionen zu strengeren MFA-Ketten.
Rollen- und gruppenbasierte Verzweigung
Switch-Knoten, die nach Benutzerrolle oder Gruppenmitgliedschaft routen, bilden Zugriffsebenen in einem einzigen Flow ab — Administratoren gehen über einen Pfad mit strengerem MFA, normale Benutzer über einen reibungslosen Pfad, Auftragnehmer über einen dritten Pfad, gebunden an eine Zeit- und Asset-Liste. Der Flow bleibt als ein einziges Artefakt auditierbar.
Compliance-umfasste Zugriffspfade
PCI-DSS-, HIPAA-, GDPR-, ISO-27001-umfasste Services betreiben ihre eigenen strengeren Flows — erzwungenes MFA, erzwungene Registrierung zu Sitzungsbeginn, kein Vertrauenswürdiges-Gerät-Shortcut. Der Prüfer betrachtet eine einzige Flow-Definition und einen einzigen Audit-Flow statt eines überlappenden Regelbergs.
Häufige Fragen
Wie wird eine Conditional-Access-Richtlinie heute definiert?
Wie werden Bedingungen wie Geolokalisierung, Zeit und Geräte-Posture ausgewertet?
Unterstützt der Switch (Pattern-Matching-Routing) Regex?
Wie wird jede Zugriffsentscheidung auditiert?
Kann eine Richtlinienänderung getestet werden, bevor sie live geht?
Holen Sie Ihre Zugriffsrichtlinie auf eine einzige Engine zurück
Eine Flow-Engine, eine Quelle, ein Audit-Flow — für jeden Service, jeden Schritt, jede Entscheidung. Lassen Sie uns Sie durch eine Live-Einrichtung auf Ihren eigenen Anwendungen führen.