Vendor Lock-in: Die versteckten Kosten von IAM

Ich dachte früher, Vendor Lock-in sei vor allem ein Preisthema. 

Also: Du entscheidest sich für einen Anbieter, nutzt dessen Plattform, irgendwann steigen die Kosten, und dann wird es unangenehm. Das stimmt auch. Aber inzwischen glaube ich, dass das nur der offensichtlichere Teil ist. 

Der vielleicht interessantere Teil liegt woanders. 

Mir ist in Gesprächen über Cloud und Digitalisierung aufgefallen, dass sehr viel über Daten gesprochen wird. 

Kundendaten. Bewegungsdaten. Vertragsdaten. Gesundheitsdaten. Finanzdaten. Alles wichtig. Keine Frage. 

Über Identitätsdaten wird oft etwas weniger gesprochen. Vermutlich, weil sie so technisch klingen. Benutzerkonten, Rollen, Gruppen, Tokens, Sessions, MFA-Informationen, Audit-Logs. Das klingt erst einmal nach Maschinenraum. 

Ist es auch. Aber eben nach einem ziemlich zentralen Maschinenraum. 

Denn Identitätsdaten beschreiben nicht nur Personen oder technische Zugänge. Sie beschreiben Beziehungen: Wer darf was? In welchem Kontext? Für welche Anwendung? Mit welcher Berechtigung? Und wer hat das wann entschieden? 

Wenn ich darüber nachdenke, ist das eine ziemlich sensible Sammlung von Informationen. 

Trotzdem landen diese Daten in vielen Architekturen recht schnell irgendwo. Nicht unbedingt unüberlegt, aber manchmal doch ein wenig beiläufig. Du entscheidest dich für einen Dienst, weil er schnell verfügbar ist. Weil er gut integriert ist. Weil er im Konzernstandard steht. Weil das Projekt ohnehin schon spät dran ist. 

Das ist menschlich. Projekte sind selten so aufgeräumt wie Architekturfolien. 

Aber die Frage bleibt: Wem gehören diese Identitäten eigentlich? Oder präziser: Wer hat die Kontrolle über sie? 

Datenhoheit bedeutet für mich nicht, dass alles zwingend im eigenen Keller laufen muss. Ich habe wenig nostalgische Gefühle für Serverräume. Die waren oft laut, kalt und rochen nach Ozon und alter Verantwortung. 

Aber ich möchte verstehen können, wo genau die Identitätsdaten liegen, wer Zugriff darauf hat, welche Rechtsräume beteiligt sind und wie ich das Betriebsmodell ändern könnte, wenn es nötig sein sollte. 

Keycloak ist in diesem Zusammenhang kein Selbstzweck. Es ist ein Werkzeug, mit dem sich unterschiedliche Antworten auf diese Fragen bauen lassen. On-Premises, private Cloud, Managed Service, europäischer Betrieb, eigener Cloud Account. Je nach Anforderung. 

Das ist nicht immer die bequemste Variante. Aber sie lässt Raum für Entscheidungen. 

Und genau darum geht es mir bei digitaler Souveränität: nicht alles selbst machen, sondern selbst entscheiden können, was man selbst macht und was nicht. 

Vielleicht ist das die nüchternere Definition. 

 

IAM-Perspektiven von Robert Bauer | intension 

Robert Bauer ist Lead für Identity bei intension und beschäftigt sich mit Open Source IAM, Keycloak und digitaler Souveränität in modernen Unternehmensarchitekturen.