Der Begriff Digital Identity bzw. Digitale Identität wird seit vielen Jahren im akademischen Bereich benutzt und hat nun auch schon seit längerem Einzug in die Wirtschaft gefunden. Doch was bedeutet das und was steckt eigentlich hinter dem Begriff "Digitale Identität“?
Im Privatbereich kennt jeder das Problem, dass man sich auf beinahe allen Seiten registrieren und dabei jede Menge zusätzliche Information ausfüllen muss. Das erscheint zwar im ersten Moment oft lästig, ist aber genau genommen notwendig. Denn wie z. B. möchte man online etwas bestellen, ohne seine Adresse anzugeben, oder etwas bezahlen, ohne eine Zahlungsquelle zu hinterlegen? Da der User nicht bei jeder Aktion immer und immer wieder dieselben Daten eingeben möchte, kann man diese natürlich in den einzelnen Portalen speichern, was einen deutlichen Komfortgewinn darstellt.
Auf der anderen Seite bringt dies jedoch auch mehrere Probleme mit sich. Zum einen müssen die Daten in den verschiedenen Portalen auch aktuell gehalten werden. Ändert sich beispielsweise die Adresse, die Telefonnummer oder die Kreditkartennummer eines Users, muss er diese Änderung auch in seinen Portalen anpassen und dabei wird gerne auf das ein oder andere Portal vergessen. Zum anderen erhöht sich mit jedem Online-Portal natürlich auch das Risiko, dass seine persönlichen Daten "abhanden“ kommen, oder in irgendeiner Form missbraucht werden.
Ein weiteres Problem liegt in der Authentifizierung. Wie beweist man dem Portal, dass einem jene Daten, die man benutzen möchte – z.B. um einen Kauf zu tätigen – auch tatsächlich gehören? Im einfachsten Fall geschieht das durch ein Login mittels Benutzername und Passwort. Und das wiederum führt dazu, dass man auch diese Daten unzählige Male eingegeben hat, woraus dann in weiterer Folge die sehr bekannte "Passwort-Problematik“ entsteht. Auf Letzteres möchte ich hier im Detail nicht näher eingehen, darüber wurde bereits sehr viel gesagt und geschrieben:
All das fällt unter die Thematik "Digital Identity“. Auf den ersten Blick wäre es wünschenswert, wenn es eine zentrale Stelle gäbe, bei der alle Daten hinterlegt, und dann diese mithilfe einer sicheren Authentifizierung und einem sicheren Protokoll den einzelnen Portalen zur Verfügung gestellt werden könnten. Teilweise gibt es derartige Bestrebungen, z.B. kennt vermutlich jeder "Anmelden mit Google/Github/…“. Es stellt einen besseren Komfort und sehr wohl auch einen Sicherheitsgewinn dar.
Global betrachtet wird dieser Gedanke in solcher Form allerdings ziemlich sicher nie vollständig umgesetzt werden, d.h. also auch inkl. Kreditkartendaten, usw. Denn abgesehen von politischen, gesellschaftspolitischen und rechtlichen Gründen sind rein zentralistisch organisierte Systeme noch nie der Weisheit letzter Schluss gewesen. Eher wahrscheinlich ist eine komplett dezentrale Lösung, in einer Form, dass man all diese Daten lokal bei sich selbst gespeichert haben wird (z.B. auf einer Smartcard) und man diese dann über ein standardisiertes Protokoll zur Verfügung stellen kann.
In kleinerem Rahmen, z.B. in einem Unternehmen, oder einer Unternehmensgruppe, lässt sich das alles aber sehr wohl umsetzen und ist in vielen Firmen auch schon Teil der Infrastruktur. Was in diese Thematik nämlich hineinfällt ist das sogenannte Single-Sign-On (SSO).
Auch wenn es noch keine endgültige(n) Lösung(en) dafür gibt, und schon gar nicht auf globaler Basis, ist doch schon sehr vieles vorhanden. Damit das Gesamtkonzept funktioniert, muss man mehrere Funktionsblöcke betrachten.
Zum einen ist das der Identity-Provider, das ist das System, das die Authentifizierungsmerkmale der Benutzer und auch die Autorisierung kennt. Vereinfacht dargestellt sind das die Rechte, die jemand in einem System hat. In Unternehmen wird hierfür oft das Active Directory hergenommen, braucht man allerdings eine flexiblere Lösung mit größerem Funktionsumfang, gibt es dafür auch andere Systeme, z.B. Keycloak.
Der Identity-Provider ist allerdings nur eine Rolle, damit nun Benutzer, Clients und Server zusammenspielen sind ebenfalls Protokolle erforderlich. Die bekanntesten und am weitesten verbreiteten sind OAUTH und SAML.
Der vermutlich schwierigste Teil ist die Schnittstelle zwischen Benutzer und System, denn diese sollte einerseits sehr sicher sein, da die Angriffswahrscheinlichkeit hoch ist, zum anderen soll es gleichzeitig aber auch benutzerfreundlich sein.
In den vergangenen Jahrzehnten wurde hier das simple Passwort-Konzept benutzt. Obwohl man schon sehr lange weiß, dass diese Form der Authentifizierung sehr unsicher ist, ist es dennoch der Standard, oder zumindest die Grundeinstellung. Und der Grund dafür ist ebenfalls simpel: es ist supereinfach zu implementieren und zu verstehen.
Heute gilt eine Form der Hardware-gestützten Authentifizierung als sicher und im Unternehmensbereich (insbesondere im IT-Sektor) ist es eine Pflichtvoraussetzung für eine robuste Infrastruktur. Zertifikatsbasierte Authentifizierung mittels Hardware-Token gilt derzeit als die sicherste Authentifizierungsvariante.
Diese Authentifizierungsvariante funktionierte jedoch (zumindest in der Vergangenheit) nicht out-of-the-Box und sorgte oftmals für mehr Probleme, als sie gelöst hat. Ursache dafür waren schlichtweg fehlende oder unzureichende Standards. Als Folge gab es zwar jede Menge Smartcards, allerdings fehlende Treiber und problematische Middleware. Proprietäre Protokolle haben eine problemlose Funktion verhindert und gerade in der IT in erster Linie Kopfschmerzen verursacht.
Mittlerweile sieht das Ganze wesentlich besser aus. So ist z. B. zertifikatsbasierte Authentifizierung im Microsoft-Umfeld bereits integraler Bestandteil von Windows, d.h. es muss i.d.R. kaum separat problematische 3rd-Party-Software installiert werden. Da die meisten Anwendungen sowohl lokal als auch global Web-basiert sind, hat man sich auch an dieser Stelle auf einen gemeinsamen Standard, nämlich FIDO2, geeinigt. Dieser definiert im Wesentlichen ein Protokoll zwischen Web-Anwendung (Server und Client) und Smartcard. Die Big Player im Internet haben das schon länger umgesetzt, so ist es in nahezu allen Browsern integriert und auch serverseitig aktiv. Somit ist eine Anmeldung z. B. bei Google oder Microsofts Office365, mittlerweile aber auch bei vielen anderen Portalen, möglich.
Im Bereich der Low-Level-Kommunikation (Schnittstelle zwischen Computer bzw. Betriebssystem und Smartcard) hat sich vieles getan und es gibt auch da Standards z.B. zur Verwaltung von Zertifikaten und Schlüsseln auf Smartcards, z.B. Personal Identity Verification (PIV), oder OpenPGP. Damit lässt sich eine direkte Windows-Anmeldung, Linux, SSH, RDP, u.v.m. recht einfach umsetzen.
IT-Security in einem Unternehmen besteht selbstverständlich nicht nur aus der Authentifizierung der Benutzer, allerdings wird man über ein gewisses Sicherheitsniveau nicht hinwegkommen, wenn man Passwort-Authentifizierung nicht durch Hardware-basierte Multifaktor-Authentifizierung (MFA) ersetzt. Angreifer werden immer versuchen das schwächste Glied zu brechen und in einer gehärteten Infrastruktur zählt Passwort-Authentifizierung eben zum wichtigsten Einfallstor.
Bernhard R. Fischer begann seine Karriere als Netzwerktechniker, verantwortlich für den Aufbau eines österreichweiten IP-Backbones und später für die Entwicklung und den Betrieb der wichtigsten Internetservices für dieses Netzwerk, wie z.B. DNS und Email. Nach dem Wirtschaftsinformatikstudium auf der Universität Wien wurde er Forschungsmitarbeiter und Dozent an der Fachhochschule St. Pölten, in den Bereichen Computernetzwerke, Betriebssysteme und IT-Security. Seit 2017 ist er Security-Consultant bei der Firma Antares-NetlogiX GmbH.
Während seiner gesamten Karriere hat Bernhard an öffentlichen Projekten und Diskussionen teilgenommen, hat auf vielen Konferenzen Vorträge gehalten und an zahlreichen Open-Source-Projekten mitgewirkt, nicht nur als Fürsprecher, sondern auch als Software-Engineer und Entwickler. Sein Hauptaugenmerk liegt immer auf Robustheit und Qualität von Software und Lösungen. Akribisch recherchiert er viele Details und gibt dieses Wissen auch bereitwillig an alle Interessierten weiter.
Einige seiner eigenen Open-Source-Projekte befinden sich auf Github und manche Artikel auf seinem persönlichen Tech- & Society-Blog und auf Twitter. Bernhard ist außerdem sehr aktiv in der Yachtsegelbranche als Ausbildner und Schiffsführer, betreibt seine eigene Webseite und produziert den Fachpodcast Schiff – Captain – Mannschaft für Seglerinnen und Segler.
