identitaet

Identität

Kurz: Im Sicherheitskontext: die Menge an Merkmalen, mit denen ein Nutzer, Gerät oder System eindeutig identifiziert werden kann — Grundlage für Authentifizierung und Autorisierung.

Genauer: Digitale Identität kann sich auf Personen (Benutzerkonto), Geräte (Zertifikat auf einem Endgerät) oder Dienste (Server-Zertifikat) beziehen. Der Nachweis einer Identität läuft meist über einen von drei Faktoren: Wissen (Passwort), Besitz (Hardware-Token, Smartphone) oder Inhärenz (Fingerabdruck). Die Kombination mehrerer Faktoren ist die Grundlage von 2FA.

Im Detail

Identität und Authentifizierung werden oft verwechselt, beschreiben aber verschiedene Schritte:

Identifikation     - "Ich bin admin@firma.de" (eine Behauptung, ungeprüft)
Authentifizierung  - "Beweise es" (Passwort, Zertifikat, biometrisches Merkmal)
Autorisierung      - "OK, du bist admin@firma.de — was darfst du jetzt tun?"

Identität ist dabei der Ausgangspunkt der gesamten Kette: Ohne eine klar definierte, eindeutige Identität lässt sich weder sinnvoll authentifizieren (wessen Echtheit soll geprüft werden?) noch autorisieren (welche Rechte gelten für wen?). In komplexen Systemen wird Identität deshalb oft zentral verwaltet — über sogenannte Identity Provider (IdP), die einmal die Identität einer Person prüfen und dieses Ergebnis dann an mehrere andere Systeme weitergeben (Single Sign-On), statt dass jedes System eigene Zugangsdaten verwaltet.

Neben menschlichen Identitäten gibt es zunehmend auch nicht-menschliche: Ein Endgerät kann über ein Client-Zertifikat eine eigene, maschinelle Identität besitzen (z. B. ein IoT-Sensor, der sich gegenüber einem Server ausweist), und auch automatisierte Dienste oder APIs authentifizieren sich untereinander über eigene Identitäten (z. B. API-Keys oder Service-Accounts), ganz ohne einen Menschen im Ablauf.

Identity Provider und Single Sign-On im Detail

Das Prinzip eines Identity Providers (IdP) löst ein reales Praxisproblem: Ohne zentrale Identitätsverwaltung müsste sich ein Nutzer für jede einzelne Anwendung eines Unternehmens (E-Mail, interne Tools, Kalender, Ticketsystem) separat mit eigenen Zugangsdaten anmelden — unpraktisch für Nutzer und ein Sicherheitsrisiko, weil jede zusätzliche Zugangsdaten-Kombination ein weiteres potenzielles Einfallstor darstellt. Bei Single Sign-On (SSO) meldet sich der Nutzer EINMAL beim zentralen Identity Provider an (z. B. über Microsoft Entra ID oder Okta), dieser stellt dann für jede weitere Anwendung ein kryptografisch signiertes Token aus, das die bereits geprüfte Identität bestätigt — die einzelnen Anwendungen selbst prüfen nur noch dieses Token, statt eigene Passwort-Datenbanken zu pflegen.

Identitätsdiebstahl als Angriffsziel

Weil Identität die Grundlage für Authentifizierung UND Autorisierung ist, zielen viele Angriffe direkt auf den Diebstahl von Identitätsmerkmalen ab, statt technische Schwachstellen auszunutzen — Phishing, gestohlene Zugangsdaten aus Datenlecks anderer Dienste (Credential Stuffing, bei dem Angreifer bei Dienst A geleakte E-Mail/Passwort-Kombinationen automatisiert bei Dienst B durchprobieren, in der Hoffnung auf Passwort-Wiederverwendung) oder Identitätsdiebstahl im wörtlichen Sinne (jemand gibt sich mit gestohlenen persönlichen Daten als eine andere reale Person aus, z. B. um in deren Namen einen Kredit aufzunehmen). Das erklärt, warum moderne Sicherheitskonzepte zunehmend auf “Identity as the new perimeter” setzen — statt sich primär auf Netzwerkgrenzen (Firewalls) zu verlassen, wird die verlässliche Prüfung JEDER einzelnen Identität bei JEDEM Zugriff zum zentralen Schutzmechanismus (siehe auch das Zero-Trust-Sicherheitsmodell).

Föderierte Identität

Über eine einzelne Organisation hinaus gibt es das Konzept der föderierten Identität: Statt für jeden Dienst ein eigenes Konto anzulegen, kann sich ein Nutzer mit einer bereits bestehenden Identität bei einem großen Anbieter (z. B. “Mit Google anmelden”, “Mit Microsoft anmelden”) auch bei völlig fremden Drittanbieter-Diensten einloggen — technisch meist über offene Standards wie OpenID Connect oder SAML umgesetzt. Der Drittanbieter muss dabei nicht selbst eine eigene Passwort-Datenbank pflegen und trägt entsprechend geringere Verantwortung für den Schutz der Zugangsdaten, verlässt sich aber vollständig auf die Vertrauenswürdigkeit des föderierten Identity Providers.

Siehe auch: Authentifizierung, Digitale ID, Authentizität