Es gibt eine Frage, die jeder IT-Administrator irgendwann nicht mehr laut stellt, weil er akzeptiert hat, dass es keine eindeutige Antwort darauf gibt.
„Warum weiß ich alles über dieses Gerät – und fast nichts darüber, wer gerade davor sitzt?“
Sie haben Zugriff auf Patch-Status, Compliance-Informationen, App-Inventar und Standort. Sie können diese Daten um 2 Uhr nachts per Fernzugriff von Ihrem Smartphone löschen. Aber was ist mit der Person, die sich um 9 Uhr morgens einloggt? Da handelt es sich im Wesentlichen immer noch um eine Authentifizierungsvereinbarung und ein Passwort, das wahrscheinlich schon von drei anderen Konten verwendet wurde.
Diese Lücke ist der Grund für die Existenz von OneIdP. Und zwei Jahre später folgt hier die ehrliche Geschichte, was nötig war, um sie zu schließen.
Die Welt, in der IT-Teams tatsächlich lebten
Die herkömmliche Antwort war bereits etabliert: Man kauft ein IAM-Tool, integriert es in das UEM-System und konfiguriert SSO irgendwo dazwischen.
Verschiedene Anbieter, verschiedene Dashboards und verschiedene Orte, an denen Ihre Richtlinien sich stillschweigend selbst widersprechen können, sobald ein Sonderfall auftritt.
Das eigentliche Problem war, dass Scalefusion Etablierte IT-Umgebungen in Unternehmen basieren nicht auf idealisierten Szenarien, sondern auf Ausnahmefällen. Beispiele hierfür sind gemeinsam genutzte Geräte, Remote-Onboarding, externe Mitarbeiter mit ihren privaten Laptops und verteilte Teams über fünf Zeitzonen hinweg.
Das waren keine Sonderfälle, mit denen man sich abfinden musste. Das waren die tatsächlichen Betriebsbedingungen.
Die meisten Zugriffsstrategien waren jedoch noch immer für eine Welt konzipiert, in der alle täglich im selben Büro mit demselben verwalteten Gerät arbeiteten. Daher wurde die Authentifizierung zum Allzweckinstrument. Man betrachtete die Authentifizierung als gelöstes Problem: Passwort überprüfen, Sitzung gewähren. Fertig.
Die meisten Zugriffsentscheidungen wurden weiterhin nur auf Basis unvollständiger Informationen getroffen. Denn die Kenntnis der Identität einer Person sagt fast nichts darüber aus, von welchem Gerät sie sich anmeldet. Ob das Gerät mit Sicherheitsupdates versehen ist. Ob es der Organisation gehört. Ob es sich um das registrierte Gerät aus dem letzten Quartal oder einen privaten Laptop in einer Hotellobby handelt.
Das war die Lücke, die wir schließen wollten.
Was wir am ersten Tag versendet haben – und warum das erst der Anfang war
Als OneIdP auf den Markt kam, haben wir uns bewusst für eine Lösung entschieden, die die meisten Produktteams nicht wählen. Wir haben ein Fundament anstelle einer Funktionsliste veröffentlicht.
Ein Cloud-Verzeichnis. Bedingter Zugriff per Schlüsselkarte. Multi-Faktor-Authentifizierung (MFA) direkt im Dashboard, das IT-Teams bereits täglich nutzten. Die Basis wurde bewusst solide gestaltet, bevor der Funktionsumfang erweitert wurde.
Schlüsselkarte Ermöglicht IT-Teams die Festlegung konkreter Zugriffsbedingungen – genehmigte Standorte, vertrauenswürdige IP-Bereiche, spezifische WLAN-Netzwerke und zeitbasierte Zeitfenster. Für Teams, die mit gemeinsam genutzten Passwörtern und Zero-Context-Logins arbeiten, stellte selbst diese erste Version eine neue Arbeitsweise dar.
Fester Untergrund, bevor wir mit dem Bauen begannen.
Und dann geschah etwas, das uns zeigte, dass das Fundament tatsächlich gefestigt war. Innerhalb weniger Monate fragten die Kunden nicht mehr, ob OneIdP funktioniere. Sie dachten bereits darüber nach, was als Nächstes kommen würde.
- Wie man ihre bestehende Okta- oder Entra-Konfiguration einbindet.
- Wie man Zugriffsentscheidungen trifft, die die Gerätekonformität und nicht nur die Identität berücksichtigen.
- Wie man es für Schichtteams umsetzen kann, die sich Maschinen über einen ganzen Arbeitstag hinweg teilen.
Das war die Karte, und wir haben uns daran gehalten.
Zwei Jahre Aufbauarbeit für diese Realität
Die meisten Identitätswerkzeuge basieren auf Annahmen.
Dass gültige Anmeldeinformationen eine sichere Sitzung gewährleisten. Dass IT-Teams ihr Verzeichnis an die neue Plattform anpassen. Dass jemand mit umfassender IAM-Expertise für die Wartung zur Verfügung steht.
Diese Annahmen sind seit Jahren fester Bestandteil des Enterprise Access Managements, weil sie einfach niemand hinterfragt hat.
Wir befragten alle drei.
1. Die Identität genügt, um Zugriff zu gewähren.
SSO, wie es in der Branche seit jeher implementiert ist, endet mit der Überprüfung der Anmeldeinformationen. Der Benutzer ist der, für den er sich ausgibt. Sitzung gewährt.
Es wurde nie gefragt, was sich hinter den Anmeldeinformationen verbirgt. Ob das Gerät gepatcht ist. Ob die Anfrage von einem plausiblen Ort stammt. Ob die Anwendung, auf die zugegriffen wird, überhaupt zu diesem Zeitpunkt auf diesem Rechner geöffnet sein sollte.
Wir bauen Erweiterte Zugriffsrichtlinien (XAP) Genau das zu fragen.
Jeder Login wird im Gesamtkontext geprüft. Live-Konformitätssignale von Veltar fließen direkt in die Zugriffsentscheidung ein. Bei Problemen wird der Zugriff gestoppt, bevor etwas geöffnet wird. Keine manuelle Überprüfung. Kein Eingreifen des Administrators. Die Richtlinie funktioniert einfach.
Dann haben wir uns die andere Seite desselben Problems angesehen.
Auf einem Gerät, das OneIdP bereits kennt und dem es vertraut, bringt die erneute Passworteingabe keinen Vorteil. Sie erzeugt lediglich unnötigen Aufwand und signalisiert dem IT-Support, dass er dem Benutzer nicht vertraut. Erweitertes SSO auf verwalteten Geräten beseitigt dieses Problem vollständig. Der Compliance-Status des Geräts dient als Anmeldeinformation. Der gesamte Vorgang wird dadurch unmerklich – im besten Sinne.
2. Sie beginnen mit einer neuen Identität.
Jedes „Wechseln Sie einfach zu unserer Plattform“-Angebot hat denselben blinden Fleck.
Es wird davon ausgegangen, dass IT-Teams ihre jahrelang aufgebauten Verzeichniskonfigurationen, IdP-Integrationen und Zugriffsrichtlinien aufgeben und alles in einem neuen Tool von Grund auf neu aufbauen. Für ein Team, das 800 Geräte auf zwei Kontinenten verwaltet, ist das keine einfache Migration.
Identity Federation wurde für diese Realität entwickelt.
OneIdP fungiert als Zugriffsrichtlinienebene über der bereits bestehenden Infrastruktur. Entra, Google Workspace, Okta, PingOne oder lokale Active Directory-Konfigurationen, die vor dem aktuellen IT-Team bestanden – all dies bleibt bestehen.
Wir gingen sogar noch einen Schritt weiter mit SCIM Eingehend und ausgehend. Beim Eintritt eines neuen Mitarbeiters werden die Zugriffsrechte automatisch bereitgestellt. Ändert sich die Rolle des Mitarbeiters, werden die Zugriffsrechte angepasst. Beim Ausscheiden eines Mitarbeiters werden die Konten gelöscht, ohne dass ein Ticket erstellt oder ein manueller Schritt ausgelassen werden muss. Die Mitarbeiterabbildung bleibt in allen verbundenen Anwendungen stets korrekt.
3. Es wird immer jemanden geben, der es betreibt.
Die Entscheidung für die Architektur ist der einfache Teil. Kompliziert wird es meist erst im Umgang mit der Plattform, wenn es um das Identitätsmanagement geht.
Lokale Administratorpasswörter Sie sind ein gutes Beispiel für ein Problem, das unbemerkt im Hintergrund bleibt, bis es plötzlich relevant wird. Identische Anmeldeinformationen auf Hunderten von Rechnern, monatelang unverändert, weil die manuelle Aktualisierung ein Projekt ist, für das niemand Zeit hat. LAPS automatisiert diesen Vorgang. Die Aktualisierung erfolgt planmäßig. Jede Anmeldeinformation wird geprüft. Das Risiko verschwindet, ohne dass jemand eingreifen muss.
Das Benutzerportal bot Mitarbeitern eine zentrale Anlaufstelle für alle genehmigten Anwendungen. Von der IT-Abteilung zusammengestellt, stets aktuell und ohne Unklarheiten bezüglich der Genehmigungen. Eine Lösung, die zwar kein Lob erntet, aber eine bestimmte Kategorie von Helpdesk-Anfragen dauerhaft überflüssig macht.
Gerätebasiertes SSO löste das seit dem Start bestehende Problem der gemeinsamen Gerätenutzung. Jeder registrierte Benutzer auf einem verwalteten Gerät erhält Zugriff auf seine App. Eine erneute Registrierung zwischen den Schichten ist nicht erforderlich. Der Zugriff ist an den Benutzer gebunden. Das Gerät bleibt für den nächsten Benutzer bereit.
SSO-Zugriffsprotokolle lieferten jedem CISO den Prüfpfad, den er bei seiner ersten Sicherheitsüberprüfung angefordert hatte – automatisch, ohne dass jemand ihn in einer Tabellenkalkulation erstellen musste.
Drei Annahmen. Drei bewusste Entscheidungen, anders zu bauen.
Doch Entscheidungen auf dem Papier und Entscheidungen in der Produktion sind zwei ganz verschiedene Dinge.
So hat es sich tatsächlich zugetragen.
Der Zeitplan, ehrlich gesagt
Es ist hilfreich zu sehen, wie sich das Ganze entwickelt hat – nicht als Produkt-Roadmap, sondern als eine Reihe von Reaktionen auf das, was wir gelernt haben:
OneIdP-Start
Verzeichnis, Single Sign-on, Schlüsselkarte.
Integrationen von Identitätsanbietern
GWS, Entra, Okta, PingOne, On-Prem AD usw.
Benutzerportal & Identitätsföderation
Kuratiertes, IT-gesteuertes Portal für jede genehmigte Bewerbung.
SCIM v2.0 – Bereitstellung in großem Umfang
Benutzerdaten werden synchronisiert. Ausgeschiedene Mitarbeiter werden automatisch abgemeldet.
Erweiterte Zugriffsrichtlinien (XAP)
Gewähren Sie SSO-Zugriff basierend auf Gerätekompatibilität, Standort, IP-Adresse und App-Präsenz.
Gerätebasiertes SSO + LAPS
Ermöglicht es kompatiblen verwalteten Geräten, unabhängig vom angemeldeten Benutzer auf Apps zuzugreifen.
Benutzergruppenbasierte SSO-Zuweisungen
Fügen Sie Ausnahmen für den bedingten Zugriff in SSO-Konfigurationen hinzu oder weisen Sie Benutzer mithilfe von Benutzergruppen in großen Mengen SSO-Konfigurationen zu.
Hauptschlüssel
Passwortlose Anmeldung per Biometrie, Sicherheitsschlüsseln und vertrauenswürdigen Geräten. Zentrale Verwaltung durch die IT-Abteilung, Selbstbedienung für Benutzer.
Wie OneIdP heute tatsächlich aussieht
Bei unserem Start ging es in den Gesprächen darum, die richtige Grundlage zu schaffen. Gerätevertrauen und Identität in derselben Richtlinienebene zu vereinen. Bedingten Zugriff so zu gestalten, dass er die Vorgänge auf dem Endgerät in Echtzeit widerspiegelt.
Heute drehen sich die Gespräche darum, was diese Grundlage leisten kann. Tiefere Integrationen, eine breitere Flottenabdeckung, Zugriffsrichtlinien, die sich über die gesamte Infrastruktur erstrecken – denn die Plattform wurde genau dafür entwickelt.
Diese Weiterentwicklung von der Basis bis zur vollständigen Plattform entspricht genau dem, was wir beabsichtigt hatten.
OneIdP Heute werden Identität, Gerätevertrauen und Zugriffsrichtlinien gemeinsam ausgewertet – bei jedem einzelnen Login, in Echtzeit, ohne Lücke zwischen dem verwalteten Endpunkt und dem kontrollierten Zugriff. Gerät und Benutzer agieren endlich im selben Richtlinienuniversum.
Was uns dabei stets begleitet hat, ist etwas, das in der Produktentwicklung ständig auf die Probe gestellt wird: „Die ausgefeilteste Zugriffsplattform ist nur so wertvoll wie die Fähigkeit des IT-Teams, sie auch tatsächlich zu betreiben. Ein schlankes Team, das eine verteilte Geräteflotte verwaltet, sollte keinen dedizierten IAM-Ingenieur benötigen, um den reibungslosen Betrieb zu gewährleisten.“
Jede Veröffentlichung der letzten zwei Jahre hat diesem Anspruch entsprochen – leistungsstark genug für eine komplexe Umgebung, bedienerfreundlich genug für die Menschen, die sich tatsächlich darin befinden.
Auf diese Ausgewogenheit sind wir besonders stolz.
Was kommt
Zwei Jahre Erfahrung in der Zusammenarbeit mit IT-Teams beim Aufbau von Systemen lehren einen etwas Nützliches: Das Problem ist immer größer als das, das man gerade gelöst hat.
Das Vertrauen in Geräte führte zu Fragen des Netzwerkzugriffs. Der Netzwerkzugriff wiederum führte zu Fragen der Infrastruktur. Cloud-RADIUS-Unterstützung und identitätsbasierter SSH-Zugriff sind die nächsten Lösungsansätze – bereits in Entwicklung und geprägt von denselben Diskussionen, die all die oben genannten Erkenntnisse hervorgebracht haben.
Der Umfang dessen, was Zero-Trust-Zugriff regeln muss, erweitert sich ständig, und wir beabsichtigen, uns entsprechend weiterzuentwickeln.
