Digitale Souveränität zurückerobern am Beispiel digitaler Identitäten

Digitale Identitäten sind der Schlüssel zur digitalen Souveränität. Wer Identitäten verwaltet, kontrolliert Zugänge, Datenflüsse und letztlich die Spielregeln im digitalen Raum. Nutzt man dafür Cloud-Services mit Sitz in den USA wie z. B. Entra ID oder Okta, so schafft das Abhängigkeiten und Risiken für Nutzer:innen und Anbieter.

Digitale Identitäten bündeln eine Vielzahl von Informationen zu einer Person. Informationen wie Benutzername, E-Mail-Adresse, Telefonnummern und Berechtigungen werden je nach Bedarf mit verschiedenen Anwendungen geteilt. Abhängig vom Umfeld hat jede Identität Credentials wie Passwörter, Multi-Faktor-Authentifikation, Passkeys, Recovery Keys sowie kurzlebige Tokens.

Dieser Vortrag zeigt verschiedene Beispiele, wie Digitale Identitäten für Mitarbeiter, Kunden, Partnerorganisationen und Bürger umgesetzt und selbst gehostet werden können. Dabei kommen offene Standards wie OpenID Connect und SAML sowie Open-Source-Lösungen wie OpenLDAP und Keycloak zum Einsatz.

Transcript

1. Digitale Souveränität zurückerobern am Beispiel digitaler Identitäten Alexander Schwartz | Principal Software Engineer | IBM Dennis Kniep | Principal Architect Identity and Access Management | Merck KGaA IT Summit | München (DE) | 2025-11-12
2. Bausteine digitale Souveränität Daten Anwendungen Identitäten
3. Kontrolle vs. Vertrauen
4. Fehlende Kontrolle über Dienstverfügbarkeit “… Microsoft habe seine Dienste für den Strafgerichtshof insgesamt "zu keinem Zeitpunkt eingestellt oder ausgesetzt".” https://heise.de/-10387368
5. Fehlende Kontrolle über Daten “… bei korrekten Anfragen müsse Microsoft auf jeden Fall seiner Verpflichtung nachkommen und die angefragten Daten weitergeben. Der Konzern wolle ferner die betroffenen Kunden hierüber informieren, müsse bei den US-Behörden jedoch erst um eine Erlaubnis hierzu bitten.” https://heise.de/-10494684
6. Fehlende Kontrolle über die Architektur “Mit dem gestohlenen Schlüssel ließen sich offenbar Zugangstoken und Benutzerkonten für nahezu alle Microsoft-Cloud-Dienste erstellen” https://heise.de/-9297240.html
7. Fehlende Kontrolle durch Multi-Tenancy “Da Microsoft sein EntraID als universelles Login auch über verschiedene Tenants ermöglicht und das Password weiterhin als Klartext übermittelt…” https://www.heise.de/-10518817.html
8. Fehlende Kontrolle über Audit-Logs “...als Admin für beliebige Tenants ausgeben...keine Spuren in Logs hinterlässt” https://heise.de/-10662375.html
9. Fehlende Kontrolle über (Security) Features, Policies, Roadmap & Prios “...discovered an active and successful device code phishing campaign by a threat actor we track as Storm-2372” https://www.microsoft.com/
10. Fehlende Kontrolle über (Fremd-) Zugriffe “... Kundendienstabteilung kompromittiert wurde” https://heise.de/-10662375.html
11. Identity and Access Management selber hosten Volle Kontrolle über: Volle Verantwortung für: • • • • • • • • • • • • Vertraulichkeit Integrität Verfügbarkeit APIs und Funktionen Regeln Audit-Logs Vertraulichkeit Integrität Verfügbarkeit APIs und Funktionen Regeln Audit-Logs
12. IAM als Datenbank Speichert: Herausforderungen: • • • • • • • • • Benutzer-ID Vorname, Nachname, … E-Mail-Adresse Berechtigungen (Rollen, Gruppen, …) Credentials (Passwörter, 2FA, …) Verfügbarkeit Software-Updates Backup und Restore Vertraulichkeit
13. IAM ist aus dem Internet erreichbar Erreichbar für: Herausforderungen: • • • • • • • • • Kunden Mitarbeiter Partnerunternehmen OSINT Angreifer Härten Auditing Monitoring und Gegenmaßnahmen Denial of Service
14. IAM als Speicherort für Credentials Speichert und aktualisiert: Herausforderungen: • • • • • • • Passwörter 2FA Tokens Passkeys • Prozesse für Credential Rotation Rollout von Passkeys Verlorene Credentials Passkeys als Lösung und Herausforderung Standards, die sich weiterentwickeln
15. IAM als Integrationsplattform Integriert mit: Herausforderungen: • • • • Personalwirtschaft Partnerunternehmen BundID • • • Automatisierung Onboarding/Offboarding Konsistenz und Aktualität Audit-Logs Standards zur Integration die sich weiterentwickeln
16. Keycloak ist eine Open Source Identity und Access Management Lösung 🎂 Erster Commit 2013-07-02 🏆 Cloud Native Computing Foundation Incubating project seit April 2023 📜 Apache License, Version 2.0 ⭐ 31k GitHub stars
17. Keycloak standalone betreiben Request < Token > Log in f ri Ve Services Cloud API en ok t y
18. Erster Kontakt mit Keycloak
19. Keycloak über We- UI, REST oder CLI verwalten Verwaltung für Admins
20. Benutzerdaten, Passwort, 2FA Selbstverwaltung für Benutzer
21. Keycloak an LDAP anbinden LDAP • • • • • • Read-Only? Benutzer importieren? Caching? Für Authentifikation verwenden? Synchronisieren? Kerberos?
22. Keycloak an andere Identity Provider anbinden SAML SAML OpenID Connect OpenID Connect OAuth 2.0 OAuth 2.0 • • Welche Claims und Attribute? Lokale Credentials erlauben?
23. Case Studies Hitachi Ltd. nutzt Keycloak um Security für FinTechs zu vereinfachen OpenTalk erreicht flexible Integration von Identitäten mit Keycloak BRZ migrierte das Business Service Portal mit 2M+ Nutzern zu Keycloak https://www.keycloak.org/case-studies
24. “Authentifiziert wird zu Hause”
25. Ausschließlich Passkeys • FIDO erzwingen, Convenience vs. Security (kein Downgrade) Konsequenz: Es muss überall funktionieren (legacy, special cases,...) ◦ Detached Authentication als Lösung für legacy Webviews ◦ Identity Proxy • Dedizierter FIDO-Server für verschiedene Szenarien • Passkeys an Geräte koppeln
26. Ein funktionierendes Identity Management erfordert ein individuell anpassbares Ecosystem
27. Credential Portal • • • • Onboarding FIDO management Recovery … …self-service ist entscheidend
28. Realtime ITDR Threat detection & risk evaluation Automation • • • • • • • Machine Learning Entity Behavior Analysis (User, Endpoint, etc.) Anomaly Detection Algorithmic Rules / Signatures (via FlinkSQL) Verschiedene Datenquellen miteinander verbinden (IdentityFabric, ThreadIntel etc.) Automatische response Threat resolutions via workflow engine
29. IAM Hosting mit Open Source ist möglich • • Zentraler Antrieb für IAM sollte Security sein - Konsequenz ist Compliance Seine “Haupteingangstür” sollte man selber kontrollieren • • Stop duct-taping - start integrating! Investiert in Mitarbeiter, nicht in Lizenzen • Höhere Automatisierung durch Self-Service schafft Zeit für strategische Themen Adaptiert Passkeys! •
30. 󰭈 2025 ist ein großartiges Jahr um sein eigenes SSO/IAM/IdP zu hosten. Lasst uns Keycloak In die breite Community bringen 📣 !
31. Links • Keycloak https://www.keycloak.org/ • Case Studies https://www.keycloak.org/case-studies • Keycloak DevDay https://www.keycloak-day.dev/ Folien:
32. Kontakt Alexander Schwartz Principal Software Engineer Dennis Kniep Identity and Access Management Architect alexander.schwartz@gmx.net https://www.ahus1.de dennis.kniep@merckgroup.com https://denniskniep.github.io @ahus1.de @ahus1@fosstodon.org @dennis_kniep