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.
Eine Flow-Engine, die Authentifizierung, MFA, Entscheidungen und Routing in einer einzigen servicebasierten Definition besitzt.
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.
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.
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.
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.
Die Flow-Engine im Detail, die Bausteine, aus denen Richtlinienregeln bestehen, und die geplanten Erweiterungen, um sie auszubauen.
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.
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.
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.
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.
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.
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.
Eine native Ausdruckssprache wird entwickelt, die es einer einzigen Richtlinie ermöglicht, Identität, Gruppe, Zeit, Quell-IP, Geolokalisierung und Geräte-Posture zu einer einzigen lesbaren Regel zu kombinieren — zum Beispiel ein einziger Ausdruck, der besagt „Rolle Admin UND Zeit innerhalb der Geschäftszeiten UND geografischer Ursprung auf der Erlaubnisliste UND Gerätevertrauen über Schwelle". Dieselbe Logik ist heute durch Verketten von Switch- und DecisionPoint-Aktionen erreichbar; die DSL komprimiert verbreitete Ketten in einen einzigen Ausdruck.
Native Evaluatoren für IP-to-Geo-Lookup, Zeitfenster und Geräte-Vertrauensscore (über den Endpoint Trust Manager) sind auf der Roadmap; so können Flows über diese Signale verzweigen, ohne dass der Upstream sie zuerst berechnen muss. Für Umgebungen, die bereits eine bevorzugte Geo- oder IP-Reputationsquelle haben, wird der Header-Injektionspfad weiterhin unterstützt.
Die Mechanik, die das sichere Ausrollen und einfache Auditieren von Richtlinienänderungen ermöglicht.
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.
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 Load Balancer ohne Koordinationsaufwand betreiben.
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.
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.
Ein grafischer Editor für die Flow-Engine wird entwickelt; Operatoren können Zugriffs-Flows visuell erstellen, Übergänge validieren und Ergebnisse mit synthetischen Benutzern in der Vorschau ansehen, ohne JSON manuell zu bearbeiten. Bis zur Veröffentlichung werden Flows in versionierter Konfiguration definiert und mit der standardmäßigen Change-Control überprüft.
Ein geplanter Dry-Run-Modus führt eine synthetische Sitzung durch einen Flow, ohne reale Benutzer zu beeinflussen; er gibt die Aktion-für-Aktion-Spur und das Endergebnis zurück. Kombiniert mit dem visuellen Builder verwandelt er Richtlinienänderungen in testbare Artefakte statt blinder Produktions-Deployments.
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.
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.
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.
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.
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.