Trotz fortschreitender Digitalisierung sind Daten-Silostrukturen in Unternehmen vorherrschend. Für das Identity & Access Management (IAM) bedeutet dies: Redundanz, Inkonsistenz und hoher Verwaltungsaufwand.Der dezentrale, nutzerzentrierte Ansatz der Self-Sovereign Identity (SSI) ist ein wesentlicher Schritt siloübergreifende Strukturen zu fördern und die Identifikation des „Gegenübers“ zweifelsfrei sicherzustellen. Gleichzeitig wird ein schnelles, flexibles und sichereres IAM ermöglicht.Technische Grundlage ist die Blockchain-Technologie (genauer Distributed Ledger Technology), die es ermöglicht, die Schutzziele der Informationssicherheit (Vertraulichkeit, Integrität und Verfügbarkeit) für das Unternehmen sowie die Persönlichkeits- und Selbstbestimmungsrechte jedes Nutzers zu gewährleisten.

Limitationen aktueller IAM-Lösungskonzepte

Der Identitätsbegriff im digitalen Bereich wird ähnlich wie in der physischen Welt als Summe von Merkmalen und Eigenschaften, die ein Individuum auszuweisen vermag, verstanden. Genügen gewöhnlich ein Personalausweis, ein Führerschein oder je nach Kontext sogar weniger, tritt in der vernetzten Welt schnell Unübersichtlichkeit ein. Die Inanspruchnahme von Online-Diensten und betrieblichen Applikationen setzt aktuell im Regelfall eine Registrierung mit Benutzernamen und Passwort voraus. Das Problem potenziert sich für ein Individuum bei der holistischen Betrachtung aller Lebensbereiche: Privat, im Beruf oder bei Behördengängen (zur Illustration siehe Abbildung 1: Status Quo digitale Identität). Im Umgang mit Silostrukturen und heterogenen Systemlandschaften, die in komplexen Organisationen mit verschachtelten legalen Einheiten und Abteilungen sowie hunderten produktiv eingesetzten Applikationen meist vorzufinden sind, wird das Verwalten aller Accounts schnell zur unkomfortablen und fehleranfälligen Aufgabe. Eine Vereinfachung ermöglichen Passwortmanager, zentrale Authentifizierungsdienste oder Social Logins im privaten Bereich.

Im betrieblichen Kontext, insbesondere bei Großkonzernen, wird meist ein integrierter Identity- und Access-Management-Ansatz verfolgt, der die Abbildung der klassischen IAM-Anwendungsfälle zum Ziel hat:

• Erfassung im Personalbestand („Onboarding“)
• Beantragung von Zugriffsberechtigungen („Access Request“)
• Genehmigungsabläufe („Approval Workflows“)
• Umsetzung von Anträgen („Fulfillment“)
• Automatisierte Umsetzung von Anträgen („Provisioning“)
• Funktionstrennungsüberwachung („Segregation of Duties“)
• Periodische Prüfung/Rezertifizierung von Zugriffsberechtigungen („Recertification“)
• Löschung von Zugriffsberechtigungen („Revocation“)

Durch die Implementierung von marktgängigen IAM-Produktlösungen wir der Versuch unternommen, die Anwendungsfälle standardisiert abzubilden. Tatsächlich weicht das Idealbild der IAM-Umsetzungen in vielen Organisationen stark von der praktizierten Realität ab, wie Tabelle 1: IAM-Idealbild und Realität aufzeigt:

Self-Sovereign Identity als innovativer IAM-Lösungsansatz

Bring Your Own Identity (BYOI)

Digitalisierung benötigt verlässliche Standards, um nachhaltig, zukunftsweisend und -sicher ausgestaltet werden zu können. Eine Schlüsselfunktionalität ist die der digitalen Identität. Die Möglichkeit, sich online als Mensch, Organisation, Gerät oder andere technische Instanz eindeutig auszuweisen, ist unabdingbar, aber, wie zuvor ausgeführt, mit bisherigen technischen Ansätzen nur unzureichend gelöst. Der konzeptionelle Lösungsvorschlag der esatus AG proklamiert daher eine selbstverwaltete digitale Identität – ein Konzept, das inzwischen als „Self-Sovereign Identity“ (SSI) Bekanntheit erlangt hat. Bei SSI steht der Nutzer der digitalen Identität im Mittelpunkt, denn er selbst ist im Besitz seiner persönlichen Daten und entscheidet über den Fremdzugriff. „Bring Your Own Identity“ (BYOI) bezeichnet hierbei die Idee und das Ziel, diese eigene Identität bei Bedarf in beliebigem Umfeld, sei es privat oder geschäftlich, zum Online-Shopping oder in behördlichem Kontext, nutzen zu können (zur Illustration siehe Abbildung 2: Nutzerzentriertes Identitätsmanagement mit SSI).

Bestehende Konzepte wie „Public Key Infrastructure“ (PKI) werden nicht verworfen, sondern den sich abzeichnenden Herausforderungen angepasst und im Sinne einer „Decentralized PKI“ (DPKI) weiterentwickelt. An die Stelle von Key-Servern, die der Speicherung und dem Abruf von Public Keys dienen, tritt eine Blockchain. Auf zentrale Instanzen kann hier verzichtet werden, da der Nutzer, der selbst seinen privaten Schlüssel kontrolliert, seine Zertifikate eigenhändig ausstellt und die Blockchain als hochverfügbare „Revocation List“ fungiert. Ferner können Wiederherstellungsmechanismen für verlorene Private Keys und Kerneigenschaften der Blockchain-Technologie, wie eindeutige Nachweisbarkeit und Unveränderlichkeit von Transaktionen, im Sinne der Identity-Lösung umgesetzt werden.

Ein sich herauskristallisierender Standard für SSI, der über eine Arbeitsgruppe des World Wide Web Consortium (W3C) formuliert wurde, sind die sogenannten „Decentralized Identifiers“, kurz DIDs. Dieser Standard wird für eine Plattform-unabhängige Umsetzung von digitalen Identitäten benötigt. DIDs sind ein neuartiger Typ von Identifikator für verifizierbare digitale Identitäten. DIDs stehen vollständig unter der Kontrolle des Eigentümers der Identität. Sie sind unabhängig von einer zentralisierten Registrierungs- oder Zertifizierungsstelle oder eines Identity-Providers. Man kann diese DIDs als eine Form der Identifizierung für selbstverwaltete digitale Identität ansehen. Um weiterhin die Privatsphäre zu erhöhen und eine Korrelation von Daten zu vermeiden, besteht eine digitale Identität aus sehr vielen DIDs. Es bedarf somit keiner „höheren“ Instanz, die ein DID erst generieren und daraufhin einem Benutzer zuweisen muss. Mit DIDs existiert ein interoperables System, das ähnlich den URLs (Uniform Resource Locators) im Internet agiert und eine Identitätsschnittstelle im Web bildet, mit dem Ziel, zentrale Punkte zu eliminieren und kritische zentrale Infrastruktur abzuschaffen.

DIDs verweisen wiederum auf „DID Documents“, die die Informationen enthalten, wie ein spezieller DID zu benutzen ist. In einem DID Document sind alle Metadaten enthalten, um den Besitz und die Kontrolle des dazugehörigen DID zu beweisen: Dazu gehören die kryptographischen Schlüssel (Public Keys), verschiedene Metadaten bezüglich der Erstellung des DID und ein Pointer auf eine Referenz (Endpoint). Ein Endpoint kann beispielsweise eine IP-Adresse sein, über die jede weitere Kommunikation zwischen zwei Parteien stattfindet. Sie ist somit „Off-Ledger“ (nicht auf der Blockchain). Eine DID-basierte Architektur fokussiert sich darauf, die minimale Menge an Attributen, die für eine sichere Kommunikation zwischen zwei Parteien notwendig ist, zu teilen.

Die dynamische Realisierung von Zertifikaten, die mit flexiblen Inhalten bestückt in verschiedensten Szenarien einsatzfähig sind, erfolgt über sog. „Verifiable Claims“ – ein Konzept, das ebenfalls durch eine W3C-Arbeitsgruppe erstellt wurde. Ein Verifiable Claim ist eine Qualifizierung, eine Errungenschaft oder eine Information über den Hintergrund einer Entität, z. B. dessen Name, Adresse, Bankverbindung, Schul- oder Universitätsabschluss. Ein solcher Claim beschreibt Qualität und Eigenschaften dieser Entität, die deren Existenz und Einzigartigkeit etablieren. Ein Set von Verifiable Claims wird als „Verifiable Credential“ bezeichnet, ein Set von Credentials aggregiert sich zu einem Profil.

Chancen der SSI-Technologie für Unternehmen

Häufig fokussiert sich die Diskussion um SSI auf die Vorzüge für den Nutzer: Zurückgewinnung über die Hoheit der Daten, Sicherstellung der Privatsphäre, das Recht auf Selbstbestimmung. Dies ist alles erstrebenswert und weiterhin gültig. Für Unternehmen besteht eine gleichermaßen schwergewichtige Chance, das IAM auf die nächste, zukunftssichere Ebene zu heben. SSI bietet gegenüber herkömmlichem IAM wesentliche Vorteile. Derzeitige Lösungen wie Single-Sign-On (SSO), die Möglichkeit unterschiedliche Zugangsdaten und besonders lange und wechselnde Passwörter zu eliminieren, sind mit SSI leicht zu realisieren. Die Potenziale gehen aber weit darüber hinaus:

Schnelligkeit – SSI-aktivierte Applikationen sind sofort für den Anwender verfügbar. Das benötigte IAM-Ökosystem wird signifikant vereinfacht, fehlerbehaftete und zeitraubende Synchronisierungen entfallen. Das Unternehmen stattet den Mitarbeiter einfach und unkompliziert mit entsprechenden Credentials aus, um den unmittelbaren Zugang zu gewähren. Die Attribute in den Credentials kommen direkt aus den Datenquellen, in denen sie originär entstehen („Golden Source“ oder „Authoritative Source“). Direkte Kommunikation relevanter Komponenten ermöglicht es, den administrativen Aufwand auf ein Minimum zu reduzieren. Genauso schnell wie die Vergabe geht die Entziehung von Berechtigungen. Reaktionszeiten sind minimal und Berechtigungen bestehen dann und nur so lange, wie sie benötigt werden bzw. gerechtfertigt sind.

Flexibilität – SSI hat eine PKI-ähnliche Funktionsweise und ein PKI überlegenes Sicherheitsniveau. Mit dynamisch generierbaren Zertifikatsschemata (bei SSI Credential Definition genannt) und der expliziten Möglichkeit, jeden im dezentralisierten Netzwerk zum Aussteller zu machen (im Gegensatz zu PKIs, wo dies nur zentrale Certificate Authorities können), entsteht bisher ungekannte Flexibilität. Credentials können nach Bedarf erstellt, zugeteilt und wieder entzogen werden – und zwar jedem, unabhängig von Organisationszugehörigkeit. Der Mitarbeiter kann die ihm ausgestellten Credentials anwendungs-, betriebssilo- und sogar unternehmensübergreifend nutzen. Vereinbarung, Design und Implementierung individueller Schnittstellen (APIs) zwischen Systemen, ggf. zwischen unterschiedlichen Organisationen, sind obsolet. Ein Unternehmen kann allen (oder ausgewählten) Mitarbeitern eines neuen Dienstleisters auf definierte Bereiche des Intranets Zugriff gewähren, ohne diese in eigene Verzeichnisdienste aufnehmen oder für diese Benutzerkonten in den Applikationen anlegen zu müssen.

Sicherheit – Derzeit sind Authentifizierungs- und Autorisierungsprozesse aufwändig und beruhen auf der Annahme, dass der eingeloggte Anwender tatsächlich der Eigentümer der Logindaten ist. Eine nicht vernachlässigbare Unsicherheit verbleibt. Mit Zwei-Faktor-Authentifizierung (2FA) bzw. Multi-Faktor-Authentifizierung (MFA) wird angestrebt, die Sicherheit zu erhöhen. SSI-Credentials werden ausschließlich der berechtigten Person zugeteilt und in deren Wallet abgespeichert. Nur der Anwender als Eigentümer der Credentials kann diese auch verwenden, um „Proofs“ auf diese zu erstellen. Bei einer Kompromittierung der Wallet oder eines Gerätes kann der Anwender die Verwendung seiner Credentials unterbinden. Durch SSI lässt sich somit unverfälschbar sicherstellen, dass es sich um den „richtigen“ Mitarbeiter handelt.

Regulatorische Konformität – SSI bedeutet echte „Privacy by Design“ und realisiert regulatorische Anforderungen an die Sicherheit und den Datenschutz, eingebaut und ohne Zusatzaufwand. Die (personenbezogenen) Daten liegen ausschließlich beim Eigentümer, in dessen Wallet auf dem Smartphone oder dem von ihm gewählten Cloud-Dienst. Darauf basierend können Freigaben an gewünschte Empfänger getätigt werden. Die zu Grunde liegende Blockchain liefert eine eindeutige Transaktionsdokumentation und bildet die Möglichkeit ab, die Gültigkeit von Credentials jederzeit zu prüfen. Die dezentrale Struktur der Blockchain-Technologie und das Open-Source Design aller Softwarekomponenten unterstreichen Verfügbarkeit und Unabhängigkeit.

Diskretion (bzw. Privatsphäre) – In der SSI-Welt gibt es für jeden Mitarbeiter eine einzigartige Identität, die auch unternehmensübergreifend genutzt wird – wie im echten Leben. Allerdings wahrt SSI in außerordentlichem Maße die Privatsphäre jedes Nutzers, viel stärker, als es heute in der Handhabung von Online-Accounts und physischen Ausweisen in der realen Welt jemals möglich wäre. Es kann keinerlei Korrelation stattfinden, da für jede Beziehung eine neue vom Nutzer kreierte Identität – eine DID – erzeugt wird. Der Nutzer baut so sukzessive seine individuelle digitale Identität auf, deren Einzigartigkeit aber allein ihm selbst ersichtlich ist. Dabei profitieren Unternehmen auch vom Schutz der Privatsphäre, die hier anders genannt wird: Diskretion. Genauso wie Credentials nur für die involvierten Parteien einsehbar sind, bleiben auch die Beziehungen zwischen den Parteien diskret.

Der SSI-basierte Ansatz im IAM ist somit schnell, flexibel, sicher, konform und diskret. Im unternehmerischen Kontext erschließen sich dem Unternehmen große Potenziale. SSI erleichtert die Digitalisierung drastisch und garantiert gleichzeitig langfristige, nachhaltige Technologiesicherheit.

Anwendungsbeispiel: Neue Mitarbeiterin benötigt Zugriff

Die tatsächliche Realisierung des klassischen IAM-Anwendungsfalls „Neue Mitarbeiterin benötigt Zugriff auf eine interne, projektspezifische Web-Applikation“ gestaltet sich mit SSI wie folgt aus (das zugehörige Sequenzdiagramm befindet sich in Abbildung 3: Realisierung von Zugriffsberechtigungen mit SSI-Credentials):Alice hat sich erfolgreich beworben und möchte Mitglied der Organisation „Alliance of Pros“ (AP) werden, da sie dort im attraktiven Projekt „Strong Cyber“ (SC) tätig werden möchte.

1. Die Personalabteilung bestätigt im Onboarding-Prozess die Zugehörigkeit zu AP sowie die Zugehörigkeit zu Bobs Team mittels Credentials, die Alice in ihrer Wallet App abspeichert.
2. Alice möchte auf die für SC wesentliche Applikation „Vulnerability Pro“ (VP) im Intranet zugreifen.
3. Alice scannt mit ihrer Wallet App den auf der VP-Seite gezeigten Login QR-Code.
4. Die VP-Intranetseite zeigt an, dass Alice ihre Zugehörigkeit zur Organisation AP, zu Team Bob und Projekt SC für den Zugriff nachweisen muss.
5. Alice‘ Wallet App kontaktiert das für VP zuständige SSI-Gateway.
6. Das SSI-Gateway fragt die erforderlichen Credentials in Alice‘ Wallet App über einen Proof Request an.
7. Die Wallet App meldet, dass nur zwei der erforderlichen drei Attribute durch einen Proof bestätigt werden können: AP (= Organisation) und Bob (= Team). Es fehlt SC (= Projekt), was Bob bestätigen könnte.
8. Alice fordert am SSI-Gateway die Ausstellung des benötigten Credentials an.
9. Bobs Wallet App informiert ihn über die Anfrage, da er verantwortlich für die Ausstellung dieses Credentials ist.
10. Bob bestätigt Alice’ Zugehörigkeit zu SC.
11. Bobs Wallet App veranlasst das SSI-Gateway zur Credential-Erstellung.
12. Das SSI-Gateway erstellt das SC-Credential und aktualisiert dabei die Revocation Registry auf dem SSI-Ledger.
13. Das SSI-Gateway übermittelt das SC-Credential an Alice‘ Wallet App.
14. Alice speichert das SC-Credential in der Wallet App ab.
15. Alice scannt erneut mit ihrer Wallet App den auf der VP-Seite gezeigten Login QR-Code.
16. Das SSI-Gateway fragt erneut die erforderlichen Credentials in Alice‘ Wallet App über einen Proof Request an.
17. Die Wallet App meldet, dass alle drei Attribute durch einen Proof bestätigt werden können: AP (= Organisation), Bob (= Team) und SC (= Projekt).
18. Alice bestätigt die Erstellung des Proofs.
19. Die Wallet App sendet den Proof an das SSI-Gateway.
20. Das SSI-Gateway stellt eine Validierungsanfrage für den Proof an das SSI-Ledger.
21. Das SSI-Ledger meldet die Gültigkeit aller Attribute an das SSI-Gateway.
22. Das SSI-Gateway meldet an VP, dass Alice für den Zugriff autorisiert ist.
23. VP stellt Alice Funktionen und Daten bereit.