Praktische Cloud-Sicherheit, 2. Auflage

Kapitel 4. Identitäts- und Zugangsmanagement

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Das Identitäts- und Zugriffsmanagement (IAM) ist vielleicht die wichtigste Sicherheitskontrolle. Bei Einbrüchen in Webanwendungen sind verlorene oder gestohlene Zugangsdaten seit mehreren Jahren das meistgenutzte Mittel der Angreifer.¹ Wenn Angreifer über gültige Zugangsdaten verfügen, um sich in dein System einzuloggen, können alle Patches und Firewalls der Welt sie nicht abhalten!

Identitäts- und Zugangsmanagement werden oft zusammen diskutiert, aber es ist wichtig zu verstehen, dass es sich dabei um unterschiedliche Konzepte handelt:

• Eine Identität ist die Art und Weise, wie eine Person (oder Automatisierung) im System dargestellt wird.² Der Prozess, bei dem überprüft wird, ob die Person, die eine Anfrage stellt, wirklich der Inhaber der Identität ist, wird Authentifizierung genannt (oft abgekürzt als "authn").

• BeimZugriffsmanagement geht es darum, dass Identitäten die Aufgaben ausführen können, die sie ausführen müssen (und in einer Umgebung mit geringsten Rechten nur die Aufgaben, die sie ausführen müssen). Der Prozess, bei dem geprüft wird, welche Berechtigungen eine Identität haben sollte, wird Autorisierung genannt (oft abgekürzt als "authz").

Authentifizierung ist der Nachweis, dass du derjenige bist, der du vorgibst zu sein. In der physischen Welt kann dies durch die Vorlage eines Ausweises geschehen, der von einer vertrauenswürdigen Behörde ausgestellt wurde und auf dem dein Bild zu sehen ist. Jeder kann diesen Ausweis einsehen, dich ansehen und entscheiden, ob du derjenige bist, der du vorgibst zu sein. Wenn du zum Beispiel auf einer Militärbasis vorfährst und deinen Führerschein vorlegst, versuchst du, dich gegenüber dem Wachpersonal zu authentifizieren. Der Wachmann kann dir glauben, oder er kann entscheiden, dass du den Führerschein einer anderen Person vorgelegt hast oder dass er gefälscht ist, oder er kann dir sagen, dass die Basis nur Militärausweise und keine Führerscheine akzeptiert.

Die Berechtigung bezieht sich auf die Fähigkeit, eine bestimmte Aktion auszuführen, und hängt in der Regel zuerst von der Authentifizierung ab (zu wissen, wer jemand ist). Der Wachmann auf dem Stützpunkt kann zum Beispiel sagen: "Ja, ich glaube, Sie sind der, für den Sie sich ausgeben, aber Sie dürfen diesen Stützpunkt nicht betreten." Oder du darfst zwar rein, aber zu den meisten Gebäuden hast du keinen Zutritt.

In der IT-Sicherheit verwechseln wir diese beiden Konzepte oft miteinander. Wir können zum Beispiel eine Identität für eine Person erstellen (mit zugehörigen Anmeldedaten wie einem Passwort) und dann implizit jedem mit einer gültigen Identität den Zugriff auf alle Daten im System erlauben. Oder wir entziehen jemandem den Zugang, indem wir seine Identität löschen - das funktioniert zwar, ist aber so, als würde man seinen Führerschein zerreißen, anstatt ihm einfach den Zugang zu verweigern. Auch wenn diese Lösungen in manchen Fällen angemessen sind, ist es wichtig, den Unterschied zu verstehen. Ist es wirklich sinnvoll, jedem Nutzer vollen Zugang zum System zu gewähren? Was ist, wenn du jemandem außerhalb der Organisation eine Identität geben musst, um ihm den Zugang zu einem anderen Bereich des Systems zu ermöglichen - erhält dieser Benutzer dann automatisch auch Zugang zu internen Ressourcen?

Beachte, dass die Konzepte (und Analogien) sehr schnell kompliziert werden können. Stell dir zum Beispiel ein System vor, bei dem du deinen Führerschein nicht überall vorzeigen musst, sondern einen Zugangsausweis, den du anderen zeigst, und einen Aktualisierungsausweis, den du nur dem Ausweisaussteller zeigen musst. Der Zugangsausweis legitimiert dich gegenüber allen, gilt aber nur für einen Tag. Danach musst du zum Ausweisbüro gehen und den Refresh-Badge vorzeigen, um einen neuen Zugangsausweis zu erhalten. Jeder Standort, an dem du deinen Zugangsausweis vorlegst, überprüft die Unterschrift auf dem Ausweis, um sicherzustellen, dass er gültig ist, und ruft dann eine zentrale Behörde an, um zu fragen, ob du auf der Liste für den Zugang zu dieser Ressource stehst. Das ähnelt der Funktionsweise einiger IT-Zugangssysteme, aber zum Glück kümmern sich dein Browser und die Systeme, die dir den Zugang gewähren, um diese Details für dich!

Ein wichtiger Grundsatz beim Identitäts- und Zugriffsmanagement wie auch in anderen Sicherheitsbereichen ist es, die Anzahl der Organisationen und Personen, denen du vertrauen musst, zu minimieren. Außer in den Fällen, in denen eine Zero-Knowledge-Verschlüsselung funktioniert, musst du zum Beispiel³ musst du den Authentifizierungs- und Autorisierungsverfahren deines Cloud-Providers vertrauen, damit deine Daten nicht von Unbefugten eingesehen werden können. Du musst das Risiko in Kauf nehmen, dass deine Daten gefährdet sind, wenn dein Anbieter vollständig kompromittiert ist. Da du dich jedoch bereits entschieden hast, dem Cloud-Provider zu vertrauen, solltest du es vermeiden, anderen Personen oder Organisationen zu vertrauen, wenn du stattdessen dieses bestehende Vertrauen nutzen kannst, ohne ein zusätzliches Risiko einzugehen.⁴ Stell dir das wie eine Eintrittsgebühr vor: Wenn du die "Gebühr" für das Vertrauen in ein bestimmtes Unternehmen bezahlt hast, solltest du es voll ausschöpfen, um kein zusätzliches Risiko in das System zu bringen.

Unterschiede zur traditionellen IT

In herkömmlichen IT-Umgebungen erfolgt die Zugriffskontrolle häufig durch physische Zugriffskontrollen (wer darf das Gebäude betreten) oder durch Netzwerkzugriffskontrollen (wer darf sich aus der Ferne mit dem Netzwerk verbinden). Du kannst dich zum Beispiel auf eine Perimeter-Firewall als zweite Schutzschicht verlassen, wenn du einen Administrator entlässt und vergisst, ihm den Zugang zu einem der Server zu entziehen.

Aber selbst in einer Nicht-Cloud-Umgebung ist das oft ein sehr schwaches Sicherheitsniveau - bist du sicher, dass die Zugriffskontrollen für alle deine Ethernet-Ports, drahtlosen Zugangspunkte und VPN-Endpunkte auch nur einem zufälligen Angriff standhalten? In den meisten Unternehmen könnte jemand auf die Toilette gehen und auf dem Weg dorthin ein 5-Dollar-Gerät für den Fernzugriff an einen Ethernet-Port anschließen oder die Zugangsdaten für WLAN oder VPN stehlen, um sich Zutritt zu verschaffen, ohne auch nur einen Fuß auf das Gelände zu setzen. Die Wahrscheinlichkeit, dass die Zugangsdaten einer einzelnen Person gestohlen werden, mag gering sein, aber die Wahrscheinlichkeit, dass sich Unbefugte im Netzwerk aufhalten, steigt schnell, wenn immer mehr Personen in der Umgebung sind.⁵ Das gilt erst recht für Cloud-Umgebungen, in denen der gesamte Zugang per Fernzugriff erfolgt und die Wahrscheinlichkeit, dass sich Unbefugte in einem vermeintlich sicheren Netzwerk aufhalten, noch höher ist.

In herkömmlichen Umgebungen wird die Zugriffskontrolle manchmal einfach durch den Entzug der gesamten Identität eines Nutzers durchgeführt, so dass er sich überhaupt nicht mehr anmelden kann. In Cloud-Umgebungen reicht das aber oft nicht aus, um das Problem vollständig zu lösen. Viele Dienste bieten langlebige Authentifizierungs-Tokens an, die auch dann noch funktionieren, wenn man sich nicht mehr anmelden kann. Wenn du nicht darauf achtest, einen "Offboarding"-Feed einzurichten, der die Anwendung benachrichtigt, wenn eine Person die Anwendung verlässt, damit diese den Zugang sperren kann, kann es sein, dass die Personen weiterhin Zugang zu Dingen haben, die du nicht beabsichtigt hast. Ein Beispiel: Wenn du einen Webmail-Dienst nutzt, wann hast du das letzte Mal dein Webmail-Passwort eingegeben? Das Ändern deines Passworts oder das Sperren der Anmeldeseite würde nichts nützen, wenn der Webmail-Anbieter nicht auch die in deinen Browser-Cookies gespeicherten Zugriffstoken bei einer Passwortänderung widerrufen würde.

Es gibt viele Beispiele für Datenschutzverletzungen, die dadurch verursacht wurden, dass Amazon S3-Buckets für den öffentlichen Zugriff offen gelassen wurden. Wenn es sich dabei um Dateifreigaben handelte, die für jeden im Unternehmen hinter einer Unternehmensfirewall zugänglich waren, hätte ein Angreifer oder Forscher im Internet sie vielleicht nicht gefunden. (In jedem Unternehmen mit einer vernünftigen Größe gibt es mit ziemlicher Sicherheit bösartige Akteure im internen Netzwerk, die diese Daten hätten stehlen können, vielleicht sogar unentdeckt, aber die Wahrscheinlichkeit eines Angriffs ist höher, wenn er über das Internet erfolgt).

Hinter diesen Beispielen steckt die Erkenntnis, dass viele Unternehmen mit laxen IAM-Kontrollen vor Ort leben und diese für die Cloud deutlich verbessern müssen. Zum Glück gibt es Dienste, die das einfacher machen.

Lebenszyklus für Identität und Zugang

Viele Menschen machen den Fehler, bei IAM nur an Authentifizierung und Autorisierung zu denken. Obwohl beides sehr wichtig ist, umfasst IAM auch andere Teile des Identitätslebenszyklus. In unserem Beispiel über den Versuch, eine Militärbasis zu betreten, sind wir davon ausgegangen, dass du, der Antragsteller, bereits eine Identität hast (deinen Führerschein) - aber wie hast du die bekommen? Und wer hat deinen Namen auf die Liste der Personen gesetzt, die den Stützpunkt betreten durften?

Viele Organisationen handhaben dies schlecht. Die Beantragung einer Identität kann durch einen Anruf oder eine Nachricht an einen Administrator erfolgen, der die Identität genehmigt und anlegt, ohne darüber Buch zu führen. In sehr kleinen Organisationen oder Umgebungen mit geringem Risiko mag das gut funktionieren, aber in vielen Fällen brauchst du ein System, das aufzeichnet, wann jemand Zugang beantragt, wie der Antragsteller authentifiziert wurde und wer die neue Identität oder den Zugang genehmigt hat.

Noch wichtiger ist das Backend des Lebenszyklus. Du brauchst ein System, das in regelmäßigen Abständen automatisch überprüft, ob die Identität und der Zugang einer Person noch benötigt werden. Vielleicht hat die Person das Unternehmen verlassen oder ist in eine andere Abteilung gewechselt und sollte keinen Zugang mehr haben. (Oder noch schlimmer: Stell dir vor, du hast die unangenehme Aufgabe, jemanden zu entlassen, und musst einen Monat später feststellen, dass die Person aufgrund eines menschlichen Fehlers immer noch Zugang zu einem wichtigen System hat).

Es gibt viele verschiedene Versionen von IAM-Lebenszyklusdiagrammen mit unterschiedlich detaillierten Schritten. Das Diagramm in Abbildung 4-1 zeigt die minimale Anzahl von Schritten und behandelt sowohl die Erstellung und Löschung von Identitäten als auch die Erstellung und Löschung von Zugriffsregeln für diese Identitäten. Identität und Zugriff können von verschiedenen Systemen oder demselben System verwaltet werden, aber die Schritte sind ähnlich.

Beachte, dass du nicht unbedingt ein ausgeklügeltes automatisiertes System brauchst, um jeden einzelnen dieser Schritte umzusetzen. In einer Umgebung mit wenigen Antragstellern und wenigen Genehmigern kann ein überwiegend manueller Prozess gut funktionieren, solange er konsequent umgesetzt wird und es Kontrollen gibt, die verhindern, dass ein einziger menschlicher Fehler Probleme verursacht. Die meisten automatisierten Systeme zur Verwaltung des gesamten Lebenszyklus (oft auch Identity-Governance-Systeme genannt) richten sich an größere Unternehmen und sind in der Regel teuer und schwierig zu implementieren. Es gibt jedoch einen wachsenden Trend, diese Governance-Lösungen wie andere Dienste in der Cloud anzubieten. Diese sind oft Teil anderer Identitäts- und Zugangsdienste, so dass auch kleinere Unternehmen davon profitieren können.

Abbildung 4-1. IAM-Lebenszyklus

Beachte auch, dass die verwendeten Prozesse und Dienste je nach Unternehmen sehr unterschiedlich sein können. Die Arten des Identitäts- und Zugriffsmanagements, die verwendet werden, um deinen Mitarbeitern Zugang zu deinem Cloud-Provider und deinen internen Anwendungen zu gewähren, unterscheiden sich erheblich von denen, die verwendet werden, um deinen Kunden als Endnutzer Zugang zu deinen Anwendungen zu gewähren. In der folgenden Diskussion werde ich zwischen diesen beiden allgemeinen Fällen unterscheiden.

Tipp

Vergiss nicht die Identitäten für nicht-menschliche Dinge im System, wie z. B. Anwendungen. Diese müssen genauso verwaltet werden wie menschliche Identitäten. Viele Teams sind sehr gut darin, den Zugang für Menschen zu kontrollieren, haben aber sehr laxe Kontrollen darüber, was die Automatisierung tun darf.

Lass uns jeden dieser Schritte durchgehen. Der Prozess beginnt damit, dass jemand oder etwas eine Anfrage einreicht. Das kann der Vorgesetzte eines neu eingestellten Mitarbeiters sein oder eine Automatisierung wie dein HR-System.

Anfrage

Der Lebenszyklus beginnt, wenn eine Entität einen Antrag auf Identitäts- oder Zugangsmanagement stellt. Diese Person sollte normalerweise auf irgendeine Weise authentifiziert werden. Innerhalb deines Unternehmens möchtest du keine anonymen Zugriffsanträge stellen, auch wenn in manchen Fällen die Authentifizierung so einfach sein kann, dass jemand die Person visuell oder akustisch erkennt.

Wenn der Öffentlichkeit Zugang gewährt, z. B. für eine Webanwendung, möchtest du oft eine Verknüpfung mit einer anderen Identität herstellen, z. B. mit einer bestehenden E-Mail-Adresse oder einer Handynummer.

Die häufigsten Anfragen sind:

• Erstelle eine Identität (und gewähre dieser Identität oft implizit zumindest eine Basisstufe des Zugriffs).

• Lösche eine Identität, wenn die Entität sich nirgendwo mehr authentifizieren muss.

• Gewähre einer bestehenden Identität Zugang - zum Beispiel zu einem neuen System.

• Entziehe den Zugang zu einer bestehenden Identität.

In Cloud-Umgebungen erfolgt der Antragsprozess oft "out of band", d.h. über einen Antragsprozess innerhalb deines Unternehmens, an dem das Cloud-IAM-System noch nicht beteiligt ist.

Genehmigen Sie

In manchen Fällen ist es akzeptabel, den Zugang implizit zu genehmigen. Wenn du zum Beispiel den Zugang zu einer öffentlich zugänglichen Webanwendung gewährst, wird jeder, der den Zugang beantragt, oft automatisch zugelassen, sofern er bestimmte Anforderungen erfüllt. Diese Anforderungen können der Betrugsbekämpfung dienen, wie z. B. die Angabe einer gültigen Handynummer oder E-Mail-Adresse, die Angabe einer gültigen Kreditkartennummer, das Ausfüllen eines CAPTCHA- oder "Ich bin kein Roboter"-Formulars oder die Tatsache, dass die Anfrage nicht von einem anonymisierenden Ort wie einem VPN-Anbieter oder einem bekannten Tor-Exit-Knoten stammt.

Innerhalb einer Organisation sollten die meisten Zugriffsanträge jedoch ausdrücklich genehmigt werden. In vielen Fällen sind zwei Genehmigungen sinnvoll - zum Beispiel durch den unmittelbaren Vorgesetzten des Nutzers und den Eigentümer des Systems, zu dem der Zugang beantragt wird. Wichtig ist, dass der oder die Genehmigenden in der Lage sind zu wissen, ob der beantragte Zugriff sinnvoll und notwendig ist. Auch dies ist ein interner Prozess für dein Team, der normalerweise ohne Interaktion mit deinen Cloud-Providern abläuft.

Erstellen, Löschen, Erteilen oder Widerrufen

Nach der Genehmigung kann die eigentliche Aktion zum Erstellen einer Identität, zum Löschen einer Identität, zur Gewährung des Zugangs oder zum Entzug des Zugangs automatisch erfolgen. Zum Beispiel kann das Antrags-/Genehmigungssystem Cloud-Provider-APIs verwenden, um die Identität zu erstellen oder den Zugang zu gewähren.

In anderen Fällen kann dies zu einem Ticket, einer E-Mail oder einer anderen Benachrichtigung führen, die eine Person zu manuellen Maßnahmen zwingt. Zum Beispiel muss sich ein Administrator in das Cloud-Portal einloggen, um die neue Identität zu erstellen und ihr eine bestimmte Zugriffsstufe zu gewähren. Vor allem bei häufig nachgefragten Dingen ist eine Automatisierung vorzuziehen, um die Möglichkeit menschlicher Fehler zu verringern.

Authentifizierung

Bis jetzt unterscheidet sich vieles von dem, was wir besprochen haben, nicht wirklich von der Zugangsverwaltung in lokalen Umgebungen - bevor eine Identität existiert, musst du sie beantragen und einen Prozess haben, um sie zu erstellen. Bei der Authentifizierung beginnen jedoch die Unterschiede zwischen Cloud-Umgebungen und den vielen verfügbaren Identitätsdiensten.

Es ist wichtig, zwischen dem Identitätsspeicher, d.h. der Datenbank, in der alle Identitäten gespeichert sind, und dem Protokoll zu unterscheiden, das zur Authentifizierung von Nutzern und zur Überprüfung ihrer Identitäten verwendet wird (OpenID, SAML, LDAP oder andere).

Je nachdem, wer authentifiziert werden soll, gibt es verschiedene Cloud-Dienste, die dabei helfen:

• Die Authentifizierung der Mitarbeiter deines Unternehmens bei deinen Cloud-Providern fällt unter die Business-to-Business-Authentifizierung (B2B), und der Cloud-Dienst wird oft als "Cloud IAM" bezeichnet.

• Die Authentifizierung der Kunden deines Unternehmens mit deinen eigenen Anwendungen, die in der Cloud laufen, wird oft als Business-to-Consumer-Authentifizierung (B2C) bezeichnet, und der Cloud-Service wird oft als "Customer IAM" oder "CIAM" bezeichnet.

• Die Authentifizierung der Mitarbeiter deines Unternehmens mit deinen eigenen Anwendungen wird oft als Business-to-Employee-Authentifizierung (B2E) bezeichnet; sie kann dieselben Dienste wie die B2C-Authentifizierung nutzen oder auch als "Workforce Identity" bezeichnet werden.

Cloud IAM Identitäten

Die meisten Cloud-Provider bieten IAM-Dienste an, die beim Zugriff auf ihre Cloud-Dienste genutzt werden müssen. Diese sind in der Regel ohne zusätzliche Kosten verfügbar. Sie ermöglichen es dir, an einem zentralen Ort die Identitäten der Cloud-Administratoren in deinem Unternehmen zu verwalten und den Zugriff dieser Identitäten auf alle vom Cloud-Provider angebotenen Dienste zu regeln.

Das kann eine große Hilfe sein. Wenn du Dutzende oder Hunderte von Diensten eines Cloud-Providers nutzt, kann es schwierig sein, sich einen Überblick darüber zu verschaffen, welche Zugriffsrechte eine bestimmte Person hat, wenn du jeden Dienst einzeln aufrufen musst. Es kann auch schwierig sein, sicherzustellen, dass du den Zugang einer Person widerrufen hast, wenn sie dein Unternehmen verlässt. Der Entzug des Zugangs ist besonders wichtig, da viele dieser Dienste direkt über das Internet genutzt werden können!

Tabelle 4-1 enthält einige Beispiele für Identitätsdienste zur Authentifizierung deiner Cloud-Administratoren bei Cloud-Providern.

Tabelle 4-1. Cloud-Provider Identitätsdienste

Anbieter	Cloud-Identitätsdienst
Amazon Web Services	AWS IAM
Microsoft Azure	Azure Active Directory
Google Cloud Plattform	Cloud IAM
IBM Cloud	Cloud IAM

Business-to-Consumer und Business-to-Employee

Zusätzlich zu den Identitäten, die dein Unternehmen für den Zugriff auf Cloud-Provider-Dienste verwendet, musst du möglicherweise auch die Identitäten deiner Endnutzer verwalten, egal ob es sich um externe Kunden oder deine eigenen Mitarbeiter handelt.

Du kannst die Kundenidentität zwar selbst verwalten, indem du einfach Zeilen mit Passwörtern in einer Datenbank anlegst, aber das ist oft nicht ideal für deine Endnutzer, die dann mit einem weiteren Login und Passwort jonglieren müssen. Außerdem gibt es bei der Überprüfung von Passwörtern erhebliche Sicherheitslücken zu vermeiden, wie in "Passwörter, Passphrasen und API-Schlüssel" beschrieben . Es gibt zwei bessere Optionen:

• Nutze einen bestehenden Identitätsdienst. Das kann ein interner Identitätsdienst für deine Mitarbeiter oder die Mitarbeiter deiner Kunden sein. Für Endnutzer kann es auch ein externer Dienst wie Facebook, Google oder LinkedIn sein. Dies setzt voraus, dass du diesem Identitätsdienst vertraust, dass er die Nutzer/innen ordnungsgemäß für dich authentifiziert. Außerdem wird deine Verbindung mit dem Identitätsdienst für deine Endnutzer/innen offensichtlich, wenn sie sich anmelden, was nicht immer wünschenswert ist.

• Verwende Kundenidentitäten, die für deine Anwendung spezifisch sind, und verwende einen Cloud-Service, um diese Kundenidentitäten zu verwalten. Die Nutzerinnen und Nutzer müssen sich zwar immer noch mit einem weiteren Berechtigungsnachweis auseinandersetzen, aber zumindest musst du den Nachweis nicht mehr überprüfen.

Die Namen dieser Identity-as-a-Service (IDaaS)-Angebote machen nicht immer deutlich, was sie leisten. In Tabelle 4-2 sind einige Beispiele von großen Cloud-Infrastrukturanbietern und Drittanbietern aufgeführt. Es gibt viele Drittanbieter in diesem Bereich und sie wechseln häufig, daher ist dies keine Empfehlung für einen bestimmtenAnbieter. Die meisten dieser IDaaS-Dienste können auch auf die Daten deiner Mitarbeiter zugreifen, z. B. auf dein internes Verzeichnis.

Tabelle 4-2. ID-Management-Systeme

Anbieter	Cloud-Dienste für das Identitätsmanagement von Kunden und Arbeitskräften
Amazon Web Services	Amazon Cognito
Microsoft Azure	Azure Active Directory B2C
Google Cloud Plattform	Identitätsplattform
IBM Cloud	App ID
Okta	Customer Identity Cloud, Workforce Identity Cloud
Ping	PingOne für Kunden, PingOne für Arbeitskräfte

Hinweis

Unabhängig davon, ob du selbst Identitäten erstellst oder einen Cloud-Dienst nutzt, können alle personenbezogenen Daten, die du erhebst oder verarbeitest, gesetzlichen Anforderungen wie der EU-Grundverordnung unterliegen.

Multi-Faktor-Authentifizierung

Die Multi-Faktor-Authentifizierung ist eine der besten Methoden, um sich vor schwachen oder gestohlenen Anmeldeinformationen zu schützen, und stellt bei richtiger Implementierung nur eine geringe zusätzliche Belastung für die Nutzer dar. Die meisten der in Tabelle 4-2 aufgeführten Identitätsdienste unterstützen dieMulti-Faktor-Authentifizierung.

Zum Hintergrund: Die verschiedenen Authentifizierungsfaktoren werden üblicherweise wie folgt definiert:

1. Das weißt du. Passwörter sind die bekanntesten Beispiele, aber auch persönliche Identifikationsnummern (PINs) - die im Gegensatz zu einem Passwort nur in Verbindung mit einem bestimmten Gerät verwendet werden können - werden immer beliebter.

2. Etwas, das du hast. Zum Beispiel einen Zugangsausweis, ein Mobiltelefon oder Daten, die du dir nicht merken kannst, wie zum Beispiel einen zufällig generierten privaten Schlüssel.

3. Etwas, das du bist. Zum Beispiel dein Fingerabdruck, dein Gesicht oder dein Netzhautmuster.

Wie der Name schon sagt, werden bei der Multi-Faktor-Authentifizierung mehr als einer dieser Faktoren für die Authentifizierung verwendet. Die Verwendung von zwei gleichen Faktoren, wie z. B. zwei verschiedenen Passwörtern, bringt nicht viel, da beide Passwörter mit dem gleichen Angriff abgegriffen werden können! Die gängigste Implementierung ist die Zwei-Faktor-Authentifizierung (2FA), bei der etwas, das du kennst (z. B. ein Passwort) und etwas, das du hast (z. B. dein Handy), verwendet wird.

Hinweis

2FA erfordert nicht, dass einer der Faktoren ein Passwort ist. Passwortlose Anmeldungen mit zwei Faktoren (z. B. ein physisches Gerät, das du besitzt, und dein Fingerabdruck zum Entsperren des Geräts) können wesentlich sicherer und bequemer sein als die Passwortauthentifizierung.

2FA sollte der Standard für die meisten Zugänge sein. Wenn sie richtig implementiert ist, erfordert sie für die meisten Nutzer nur sehr wenig zusätzlichen Aufwand. Du solltest 2FA unbedingt überall dort einsetzen, wo die Auswirkungen eines Verlusts oder Diebstahls von Zugangsdaten hoch wären, z. B. bei privilegierten Zugängen, beim Zugang zum Lesen oder Ändern sensibler Daten oder beim Zugang zu Systemen wie E-Mail, die zum Zurücksetzen anderer Passwörter missbraucht werden können. Wenn du z. B. eine Bank-Website betreibst, könntest du entscheiden, dass die Auswirkungen gering sind, wenn jemand den Kontostand eines Nutzers ablesen kann, aber hoch (wenn 2FA erforderlich ist), wenn jemand versucht, Geld zu überweisen. Die Forderung nach einer zusätzlichen Authentifizierung für risikoreichere Aktivitäten wird als Step-up-Authentifizierung bezeichnet.

Wenn du eine Cloud-Umgebung verwaltest, stellt der unbefugte administrative Zugriff auf das Cloud-Portal oder die APIs ein sehr hohes Risiko für dich dar, da ein Angreifer mit diesem Zugriff in der Regel alle deine Daten kompromittieren kann. Für diese Art des Zugangs solltest du die Zwei-Faktor-Authentifizierung aktivieren; die meisten Cloud-Provider unterstützen dies von Haus aus. Wenn du Single Sign-On (SSO) verwendest (siehe "Single Sign-On"), kann es auch sein, dass dein SSO-Anbieter bereits 2FA für dich durchführt.

Viele Dienste bieten mehrere Authentifizierungsmethoden an. Die gängigsten Methoden sind:

Passwörter und Passphrasen (etwas, das du kennst)

Ein Passwort ist nicht an ein bestimmtes Gerät gebunden und funktioniert von überall aus. Die Probleme mit Passwörtern sind zahlreich und wohlbekannt: Viele Menschen wählen Passwörter, die häufig verwendet werden und Gegenstand von Wörterbuchangriffen sind, oder die einfach und kurz genug sind, um mit Brute-Force-Angriffen geknackt zu werden, oder die bei mehreren Diensten wiederverwendet werden, so dass ein Angreifer durch die Kompromittierung eines Dienstes das Passwort für einen anderen erhält (das durch Credential Stuffing-Angriffe entdeckt werden kann). Es ist wirklich an der Zeit, sie nicht mehr zu verwenden, aber Veränderungen sind schwer.

PINs (etwas, das du kennst)

Oberflächlich betrachtet mögen PINs schlechter sein als Passwörter, weil sie in der Regel einfacher sind, aber das Wichtige an PINs ist, dass sie nur in Verbindung mit einem bestimmten physischen Gerät nützlich sind. Jemand, der deine PIN errät, ohne das dazugehörige Gerät zu besitzen (in der Regel ein Mobiltelefon, einen Laptop oder einen Hardware-Sicherheitsschlüssel), kann keinen Zugriff darauf erhalten, was einen erfolgreichen Angriff deutlich erschwert.

SMS-Textnachrichten an ein mobiles Gerät (etwas, das du hast)

Diese Methode ist in Ungnade gefallen, weil es so einfach ist, die Telefonnummer einer anderen Person zu stehlen (durch SIM-Klonen oder Nummernportierung) oder die Nachricht abzufangen. Daher sollten neue Implementierungen diese Methode nicht verwenden und bestehende Implementierungen sollten auf eine andere Methode umsteigen. Um die Textnachrichten zu empfangen, ist ein Zugang zum Mobilfunknetz erforderlich.

Zeitbasierte Einmal-Passcodes, oder TOTPs (etwas, das du hast)

Bei dieser Methode muss ein mobiles Gerät mit einem anfänglichen "Geheimnis" versehen werden (das normalerweise durch einen 2D-Barcode übertragen wird). Das Geheimnis ist eine Formel, mit der etwa jede Minute ein Einmalpasswort errechnet wird. Das Einmalpasswort muss nur ein oder zwei Minuten lang sicher aufbewahrt werden, aber das anfängliche Geheimnis kann es jedem Gerät ermöglichen, gültige Passwörter zu generieren, und sollte daher nach Gebrauch vernichtet oder an einem physisch sicheren Ort aufbewahrt werden. Nach der Übertragung des anfänglichen Geheimnisses ist für das mobile Gerät kein Netzwerkzugang erforderlich, sondern nur eine synchronisierte Uhr. Der größte Nachteil ist, dass TOTPs für die Nutzer/innen weniger bequem sind und "phishable" sind, d.h. ein Angreifer, der dich dazu verleitet, sowohl das Passwort als auch den Passcode auf einer gefälschten Website einzugeben, kann Zugang erhalten.

Hash-basierte One-Time-Passcodes oder HOTPs (etwas, das du hast)

Diese ähneln in ihren Vor- und Nachteilen den TOTPs, verwenden aber einen Zähler anstelle der Uhrzeit und benötigen daher keine synchronisierte Uhr. Allerdings können sie aus dem Takt geraten, wenn zu viele Codes erzeugt und nicht verwendet werden.

Push-Benachrichtigungen an ein mobiles Gerät (etwas, das du hast)

Bei dieser Methode stellt eine bereits authentifizierte Client-Anwendung auf einem mobilen Gerät eine Verbindung zu einem Server her, der einen Code zur einmaligen Verwendung zurückschickt oder um Erlaubnis bittet. Dies ist sicher, solange die Authentifizierung der bereits authentifizierten Client-Anwendung sicher ist, erfordert aber einen Netzwerkzugang für das mobile Gerät. Der größte Nachteil ist, dass ein Angreifer den Nutzer entweder mit einer raffinierten Fälschungsseite oder durch eine Vielzahl von Anfragen dazu bringen kann, seine Zustimmung zu geben.

Fingerabdruckleser, Gesichtsleser und Retina-Leser (etwas, das du bist)

Obwohl diese biometrischen Methoden mit genügend Aufwand oft überlistet werden können (indem man Replikate von Fingern, Gesichtern oder Augen erstellt), werden die Implementierungen immer besser und sie sind als Einzelfaktor gut genug, um die meisten Sicherheitsanforderungen zu erfüllen.

Ein Hardware-Gerät, z. B. eines, das den Standards FIDO Universal 2nd Factor (U2F) oder FIDO2 entspricht (etwas, das du hast)

FIDO U2F ist nur ein zweiter Authentifizierungsfaktor, der in der Regel zusammen mit einem Passwort verwendet wird, während FIDO2 als kombiniertes Multifaktor-Gerät funktioniert und eine passwortlose Authentifizierung ermöglicht. FIDO2-Geräte werden auch Passkeys genannt. Das ist bei weitem die beste Option, denn der Passkey weiß, mit welcher Anwendung er kommuniziert und kann nicht von gefälschten Websites getäuscht werden. Ursprünglich gab es sie nur als eigenständige Hardware-Sicherheitsschlüssel, aber inzwischen ist die Technologie in die meisten Laptops und mobilen Geräte eingebaut. Es ist wahrscheinlich, dass diese Art der Authentifizierung in naher Zukunft allgegenwärtig sein wird und in Smartphones und tragbare Technologien wie Uhren und Ringe integriert wird. Ein FIDO2-Gerät kann mit einer PIN oder einem biometrischen Faktor entsperrt werden, der zwei Faktoren in einem Gerät kombiniert und so eine sehr starke, Phishing-resistente und passwortlose Authentifizierung ermöglicht.

Warnung

Beachte, dass viele dieser Methoden zur Verifizierung von "etwas, das du hast" anfällig für soziale Angriffe sind, wie z.B. das Anrufen des Nutzers unter falschem Vorwand und die Frage nach dem einmaligen Passcode! Selbst die stärksten Formen der Authentifizierung, wie FIDO2, sind anfällig für Downgrade-Angriffe, wenn der Nutzer auf eine gefälschte Seite geht, auf der steht: "Das hat nicht funktioniert, bitte versuche eine andere (schwächere) Methode". Zusätzlich zur Einführung der Multi-Faktor-Authentifizierung musst du den Nutzern ein Mindestmaß an Schulungen anbieten, damit sie gängige Angriffe erkennen können.

Alle großen Cloud-Provider bieten Möglichkeiten zur Implementierung der Multi-Faktor-Authentifizierung, obwohl Google den freundlicheren Begriff "2-Step Verification" verwendet.

Passwörter, Passphrasen und API-Schlüssel

Wenn du eine Multi-Faktor-Authentifizierung verwendest, sind Passwörter oder Passphrasen nicht mehr deine einzige Verteidigungslinie. Trotzdem ist es wichtig, gute Passwörter zu wählen, es sei denn, du hast dich für ein passwortloses Modell entschieden. Das gilt umso mehr in Cloud-Umgebungen, denn in vielen Fällen können Angreifer Passwörter direkt über das Internet von überall auf der Welt erraten.

"Passphrase" ist nur ein Begriff für ein längeres, sichereres Passwort, deshalb verwende ich hier den allgemeineren Begriff "Passwort". Obwohl es viele Ratschläge und Diskussionen über gute Passwörter gibt, sind meine Empfehlungen für die Wahl von Passwörtern einfach:

1. Verwende niemals Passwörter wieder, es sei denn, es ist dir wirklich egal, ob Unbefugte Zugang zu den Ressourcen erhalten, die durch das Passwort geschützt sind. Du könntest z. B. dasselbe Passwort in einem Dutzend Foren verwenden, weil es dir egal ist, ob jemand in einem oder allen Foren als du schreibt. (Aber selbst dann besteht immer noch die Gefahr, dass der Nutzer oder die Nutzerin diesen Zugang ausnutzt, um andere Passwörter zurückzusetzen, deshalb ist es am besten, Passwörter überhaupt nicht wiederzuverwenden). Wenn du ein Passwort auf einer Website eingibst, solltest du davon ausgehen, dass die Administratoren der Website böswillig sind und das von dir angegebene Passwort benutzen, um in andere Websites einzubrechen.

2. Wenn du Passwörter nicht wiederverwendest, hast du am Ende viele Passwörter, also verwende eine seriöse Passwortbörse, um den Überblick zu behalten. Bewahre Kopien von Master-Passwörtern oder Wiederherstellungsschlüsseln an einem sicheren Ort auf, z. B. in einem guten Safe oder einem Bankschließfach.

3. Für Passwörter, die du dir nicht merken musst (z. B. solche, die du aus deiner Passwortbörse kopieren und einfügen kannst), solltest du einen sicheren Zufallsgenerator verwenden. Zwanzig Zeichen sind ein gutes Ziel, auch wenn es Systeme gibt,die nicht so viele Zeichen akzeptieren; in diesen Fällen solltest du so viele Zeichen wie möglich verwenden.⁶

4. Für Passwörter, die du dir merken musst, wie z. B. das Passwort für deine Passwort-Wallet, solltest du ein Diceware-Passwort mit sechs Wörtern erstellen⁷ und setze zwischen jedes Wort dasselbe nicht-alphabetische Zeichen, z. B. ein Dollarzeichen, ein Gleichheitszeichen oder ein Komma. Du kannst das Passwort ein paar Mal neu generieren, bis du ein Passwort gefunden hast, zu dem du dir eine lustige Geschichte ausdenken kannst, damit du es nicht vergisst. So kannst du es dir schnell merken und es ist für einen Angreifer fast unmöglich, es zu erraten. Der einzige Nachteil ist, dass es eine Weile dauert, es zu tippen, du willst es also nicht ständig tippen müssen!

API-Schlüssel sind Passwörtern sehr ähnlich, aber sie sind für die Automatisierung und nicht für Menschen gedacht. Aus diesem Grund kannst du mit API-Schlüsseln keine Multi-Faktor-Authentifizierung verwenden und sie sollten lange, zufällige Zeichenfolgen sein, wie in Punkt 3 der vorangegangenen Liste beschrieben. Im Gegensatz zu den meisten Benutzeridentitäten, bei denen du eine öffentliche Benutzer-ID und ein privates Passwort hast, hast du in der Regel nur einen privaten API-Schlüssel, der dem System mitteilt, wer du bist, und der dich auch authentifiziert.

Passwörter überprüfen

Es kann auch sein, dass du die Passwörter der Benutzer/innen überprüfen sollst, was viel komplizierter sein kann, als es scheint. Vermeide diese Aufgabe, wenn möglich!

Die einfachste Methode zur Überprüfung von Passwörtern ist es, eine Liste mit Benutzern und Passwörtern zu speichern und dann zu prüfen, ob das eingegebene Passwort mit dem auf der Liste übereinstimmt. Das ist jedoch eine sehr schlechte Idee, denn wenn sich jemand Zugang zu deiner Liste verschafft, hat er alles, was er braucht, um sich als jeder Benutzer auf der Liste auszugeben!

Eine viel bessere Methode ist es, nicht die Passwörter selbst zu speichern, sondern etwas, das zur Überprüfung der Passwörter verwendet werden kann. Dies wird mit einem Einweg-Hash realisiert, den du mit einer Funktion ableiten kannst, wenn du das Passwort hast, der aber nicht verwendet werden kann, um das Passwort zurück zu bekommen. Der Teufel steckt jedoch im Detail: Wenn du die falsche Funktion oder die falschen Parameter für die Funktion verwendest, können die Passwörter leicht durch einen Brute-Force-Angriff ermittelt ("geknackt") werden, indem du viele mögliche Passwörter errätst. Perfekte Hash-Algorithmen wie SHA-256 eignen sich schlecht für Passwort-Hashes, weil sie von Haus aus schnell zu berechnen sind.

Zum jetzigen Zeitpunkt sollten Passwort-Hashes mit den Funktionen scrypt, bcrypt, PBKDF2 oder Argon2 mit vernünftigen Parametern gespeichert werden. Die Empfehlungen für Funktionen und Parameter ändern sich im Laufe der Zeit, da die Hardware zum Knacken von Passwörtern immer ausgefeilter wird und Schwachstellen in den Hash-Algorithmen gefunden werden, so dass du deine Auswahl mindestens einmal im Jahr überprüfen musst. Wenn du Algorithmen oder Parameter änderst, werden alle neuen Kennwörter die neuen Methoden verwenden, aber es gibt keine Möglichkeit, die alten Hashes in neue umzuwandeln. Wenn ein dringender Änderungsbedarf besteht (z. B. wenn es Beweise für einen Einbruch gibt, bei dem Zugang zu den Passwort-Hashes erlangt wurde), musst du alle Benutzerpasswörtersofort zurücksetzen.

Auch wenn du Hashes sicher speicherst, solltest du einen Prüfmechanismus einrichten, um zu verhindern, dass Benutzer/innen wirklich einfach zu erratende Passwörter wie abc123 oder Fall2018 verwenden. Angreifer nutzen zunehmend Techniken wie das "Passwort-Spraying", bei dem sie ein einfaches Passwort an Hunderten oder Tausenden von IDs auf einmal ausprobieren. Das löst oft keinen Alarm aus, da es sich nur um einen einzigen fehlgeschlagenen Login für jede ID handelt. Du solltest auch darauf achten, dass viele Fehlversuche von einem Ort ausgehen, was oft auf Credential Stuffing-Angriffe hindeutet, bei denen ein Angreifer eine Liste von Passwörtern von einer Website erhält und sie auf anderen Websites ausprobiert.

Verwende für Cloud-Dienste und -Anwendungen nach Möglichkeit eine föderierte Identität von einem anderen Anbieter oder einen IAM-Cloud-Dienst für Verbraucher/Mitarbeiter. Verwende für den Zugang auf Systemebene eine schlüsselbasierte Authentifizierung oder eine zentralisierte Authentifizierung mit Prüfung der Passwortstärke. Speichere und überprüfe Passwort-Hashes nicht selbst, es sei denn, es gibt keine guteAlternative.

Gemeinsame IDs

Gemeinsame IDs sind Identitäten, für die mehr als eine Person das Passwort oder andere Anmeldeinformationen hat, wie z. B. das integrierte Root- oder Administratorkonto auf einem System. In Cloud-Umgebungen kann es schwierig sein, damit umzugehen, genauso wie in lokalen Umgebungen.

Wenn möglich, sollte jeder Benutzer oder jedes Tool eine eigene ID haben, die von niemandem oder nichts anderem verwendet wird. Viele Systeme erlauben es Benutzern, für bestimmte Aktivitäten eine privilegierte Rolle oder eine separate, höher privilegierte ID anzunehmen, z. B. durch die Verwendung von sudo auf Unix-ähnlichen Systemen. Wenn du gemeinsame IDs verwenden musst, musst du genau feststellen können, welche Person (oder automatisiertes Werkzeug) die ID für einen Zugriff verwendet hat.

Wenn du eine ID freigeben musst, wie z. B. root, kann das System, auf dem du die gemeinsame ID verwendest, nicht unterscheiden, wer sie benutzt hat. Das bedeutet, dass du einen separaten Prozess und Werkzeuge brauchst, um die gemeinsam genutzten Anmeldedaten auszuchecken und sie zu ändern, wenn sie wieder eingecheckt werden. Dieses Tool wird in der Regel als Privileged Access Management (PAM) oder Privileged Identity Management (PIM) System bezeichnet und kann auch andere Funktionenerfüllen, wie z. B. die Aufzeichnung der Sitzung oder das Verbot der Verwendung bestimmter Befehle.

Föderierte Identität

Federated Identity ist ein Konzept, keine bestimmte Technologie. Es bedeutet, dass du Identitäten auf zwei verschiedenen Systemen haben kannst und die Administratoren dieser Systeme sich darauf einigen können, Technologien zu verwenden, die diese Identitäten miteinander verbinden, damit du nicht auf jedem System manuell separate Konten erstellen musst. Aus deiner Perspektive als Nutzer/in hast du nur eine einzige Identität.

In der Praxis bedeutet das in der Regel, dass sowohl Unternehmen A als auch Unternehmen B deine Unternehmens-E-Mail-Adresse (z. B. [e-mail]) als deine Identität verwenden und Unternehmen B sich an Unternehmen A wendet, um dich tatsächlich zu authentifizieren. Unternehmen A gibt dann eine Behauptung oder ein Token mit seinem Gütesiegel zurück: "Ja, das ist tatsächlich [e-mail]; ich habe sie verifiziert, hier ist meine Unterschrift, um zu beweisen, dass ich es bin, und du hast bereits zugestimmt, dass du mir bei der Authentifizierung von Nutzern mit Kennungen, die auf @firma-a.com enden, vertraust."

Single Sign-On

Single Sign-On (SSO) ist eine Reihe von Technologieimplementierungen, die auf dem Konzept der föderierten Identität basieren.

Früher gab es für jede Website ein eigenes Login und Passwort. Das ist eine Menge an Passwörtern, die sich die Nutzer/innen merken müssen! Das vorhersehbare Ergebnis ist, dass die Nutzer/innen oft dasselbe Passwort für mehrere Websites verwenden, was bedeutet, dass das Passwort der Nutzer/innen nur so gut geschützt ist wie die schwächste Website.

Hier kommt SSO ins Spiel. Die Idee ist, dass eine Website nicht mehr nach der ID und dem Passwort eines Nutzers fragt, sondern den Nutzer an einen zentralen Identitätsanbieter (IdP) weiterleitet, dem sie vertraut. (Der Identitätsanbieter muss nicht einmal zur gleichenOrganisation gehören - die einzige Voraussetzung ist, dass die Website ihm vertraut). Der IdP übernimmt die Authentifizierung des Nutzers, z. B. durch einen Benutzernamen und ein Passwort und hoffentlich einen zusätzlichen Autorisierungsfaktor. Anschließend schickt er den Nutzer mit dem Nachweis, dass er den Nutzer verifiziert hat, zurück an die ursprüngliche Website. In einigen Fällen sendet der IdP auch Informationen (wie z. B. die Gruppenzugehörigkeit), die die Website nutzen kann, um Entscheidungen über die Autorisierung zu treffen, z. B. ob der Nutzer als normaler Nutzer, als Administrator oder gar nicht zugelassen werden soll.

In den meisten Fällen funktioniert SSO nur für Websites und mobile Anwendungen, obwohl sich das langsam ändert. Für die zentrale Authentifizierung von Nicht-Web-Assets wie Netzwerkgeräten oder Betriebssystemen benötigst du möglicherweise ein anderes Protokoll (wie LDAP, Kerberos, TACACS+ oder RADIUS).

Selten findet man etwas, das sowohl einfacher für die Nutzer ist als auch mehr Sicherheit bietet! Die Nutzer/innen müssen sich nur einen Satz von Anmeldedaten merken, und da diese Daten nur vom Identitätsanbieter (und nicht von den einzelnen Websites) eingesehen werden, kann eine Kompromittierung dieser Websites nicht die Anmeldedaten der Nutzer/innen gefährden. Darüber hinaus kann dein SSO-Anbieter Kontrollen einführen, die anderen Zero-Trust-Prinzipien folgen, wie z. B. die Überprüfung, ob ein nicht verwaltetes oder veraltetes Gerät verwendet wird oder ob die Anmeldedaten des Nutzers aus zwei verschiedenen Ländern gleichzeitig verwendet werden. Diese Arten von Kontrollen lassen sich nur sehr schwer für jede Anwendung einzeln implementieren.

Der einzige Nachteil von SSO ist, dass es für eine Website etwas schwieriger zu implementieren ist als schlechte Authentifizierungsmechanismen, wie der Vergleich mit einem Klartextpasswort oder einem unsicher gehashten Passwort in einer Datenbank.

SAML und OIDC

Derzeit sind die Security Assertion Markup Language (SAML - die Abkürzung reimt sich auf "Kamel") und OpenID Connect (OIDC) die gängigsten SSO-Technologien. Während die Endergebnisse ähnlich sind, unterscheiden sich die Mechanismen, die sie verwenden, etwas.

Die aktuelle SAML-Version ist 2.0, und es gibt sie bereits seit 2005. Es ist eine der gängigsten SSO-Technologien, insbesondere für große Unternehmensanwendungen. Es gibt zwar viele ausführliche Erklärungen, wie SAML funktioniert, aber hier ist eine sehr vereinfachte Version:

1. Du rufst mit deinem Webbrowser eine Webseite auf, auf die du zugreifen möchtest (den sogenannten Service Provider oder SP).

2. Die SP-Webseite sagt: "Hey, du hast kein SAML-Cookie, also weiß ich nicht, wer du bist. Geh zu dieser Webseite des Identitätsanbieters und hol dir einen", und leitet dich weiter.

3. Du gehst zum IdP und meldest dich mit deinem Benutzernamen, deinem Passwort und hoffentlich einem zweiten Faktor oder einer passwortlosen Methode an.

4. Wenn der IdP sicher ist, dass du es wirklich bist, gibt er deinem Browser ein Cookie mit einer kryptografisch signierten XML-"Assertion", die besagt: "Ich bin der Identitätsanbieter, und dieser Benutzer ist authentifiziert", und leitet dich dann wieder zurück.

5. Dein Webbrowser gibt dieses Cookie an die erste Webseite (SP) zurück. Der SP prüft die kryptografische Signatur und sagt: "Du hast es geschafft, den IdP von deiner Identität zu überzeugen, also ist das gut genug für mich. Komm rein."

Nachdem du dich einmal eingeloggt hast, geschieht das alles eine Zeit lang automatisch, bis die Assertion-Dokumente ablaufen und du dich erneut beim IdP anmelden musst.

Ein wichtiger Punkt ist, dass es keine direkte Kommunikation zwischen der ursprünglichen Webseite und dem Identitätsanbieter gab - dein Browser hat die ganze Arbeit gemacht, um die Informationen von einem Ort zum anderen zu bringen. Das kann in manchen Fällen wichtig sein, wenn die Netzwerkkommunikation eingeschränkt ist.

Beachte auch, dass SAML von Haus aus nur Identitätsinformationen liefert. Ob du berechtigt bist, dich anzumelden oder andere Aktionen durchzuführen, ist eine andere Frage, obwohl einige SAML-Implementierungen zusätzliche Informationen mit der Assertion übermitteln (z. B. die Gruppenzugehörigkeit), die von der Anwendung verwendet werden können, umAutorisierungsentscheidungen zu treffen.

OpenID Connect ist eine viel neuere Authentifizierungsschicht, die 2014 fertiggestellt wurde und auf OAuth 2.0 aufbaut. Sie verwendet JSON-Web-Tokens (JWTs, manchmal auch "jots" ausgesprochen) anstelle von XML und verwendet eine etwas andere Terminologie ("vertrauende Partei" wird in OIDC in der Regel verwendet, im Gegensatz zu "Dienstanbieter" in SAML, zum Beispiel).

OIDC bietet sowohl Authorization Code Flows (für traditionelle Webanwendungen) als auch Implicit Flows (für Anwendungen, die mit JavaScript auf der Client-Seite implementiert werden). Obwohl es zahlreiche Unterschiede zu SAML gibt, sind die Endergebnisse ähnlich, da die Anwendung, mit der du dich authentifizierst, nie dein tatsächliches Passwort sieht und du dich nicht für jede Anwendung neu authentifizieren musst.

Einige Dienste können Anfragen von OIDC-fähigen Anwendungen entgegennehmen und diese in Anfragen an einen SAML IdP "übersetzen". In größeren Organisationen ist es üblich, beide Standards zu verwenden, und die meisten IdPs unterstützen beide.

SSO mit Legacy-Anwendungen

Was ist, wenn du Single Sign-On für eine Legacy-Anwendung bereitstellen willst, die es nicht unterstützt? Eine Möglichkeit ist, der Anwendung etwas vorzuschalten, das die SSO-Anfragen bearbeitet und der Legacy-Anwendung mitteilt, wer die Nutzer sind.

Die Legacy-Anwendung vertraut diesem Frontend-Dienst (oft ein Reverse Proxy), um die Authentifizierung durchzuführen, aber es ist sehr wichtig, dass er keine Verbindungen von anderen Diensten akzeptiert. Techniken wie diese werden manchmal benötigt, wenn eine bestehende Anwendung in die Cloud verlagert wird, bis die Anwendung überarbeitet werden kann, um SSO nativ zu ermöglichen. Viele der oben genannten Identity-as-a-Service-Anbieter bieten auch Möglichkeiten, Legacy-Anwendungen mit SSO zu versehen.

Instanz-Metadaten und Identitätsdokumente

Wie bereits in diesem Kapitel erwähnt, gehen wir oft davon aus, dass die Automatisierung, z. B. ein Programm, das auf einem System läuft, bereits eine Identität und einen Weg hat, diese Identität zu beweisen. Wenn ich zum Beispiel ein neues System einrichte, kann ich einen Benutzernamen und ein Kennwort für dieses System erstellen und diesen Benutzernamen und dieses Kennwort dem System als Teil des Erstellungsprozesses mitteilen. In vielen Cloud-Umgebungen gibt es jedoch einfachere Wege.

Ein Prozess, der auf einem bestimmten System läuft, kann sich mit einem bekannten Endpunkt in Verbindung setzen, der ihm alles über das System, auf dem er läuft, mitteilt, und der Prozess stellt auch einen kryptografisch signierten Weg zur Verfügung, um die Identität dieses Systems zu beweisen. Die genauen Details unterscheiden sich von Anbieter zu Anbieter, aber im Prinzip sieht es wie in Abbildung 4-2 aus.

Abbildung 4-2. Verwendung von Ausweispapieren

Dies ist jedoch nicht narrensicher, da jeder Prozess auf dem System diese Metadaten anfordern kann, unabhängig von seiner Berechtigungsstufe auf dem System. Das bedeutet, dass du entweder nur Prozesse mit der gleichen Vertrauensstufe auf dem System zulassen oder Maßnahmen ergreifen musst, um zu verhindern, dass Prozesse mit niedrigeren Privilegien die Identität des gesamten Systems übernehmen. Dies kann besonders in Containerumgebungen problematisch sein, da jeder Container auf einem Hostsystem das Identitätsdokument anfordern und dann vorgeben könnte, dieses Hostsystem zu sein. In solchen Fällen musst du die Container daran hindern, denMetadatendienst zu erreichen.

Dieses System setzt außerdem voraus, dass der Cloud-Dienst die besondere Art des Dokuments und der Signatur erkennt, die der Metadatendienst verwendet. Wenn es doch nur ein Standardformat für diese Dokumente und Signaturen gäbe, damit der Cloud-Dienst entscheiden könnte, ob er Containern, die in einem bestimmten Cluster erstellt wurden, oder virtuellen Maschinen, die in einem bestimmten Cloud-Konto erstellt wurden, vertraut! Hier kommt SPIFFE ins Spiel, eine Standardmethode, mit der sich ein Workload (z. B. ein Container, eine virtuelle Maschine oder eine Anwendung mit mehreren Knoten) gegenüber einem anderen authentifizieren kann. SPIRE ist eine Referenzimplementierung der SPIFFE-Spezifikation. Zum jetzigen Zeitpunkt ist SPIFFE noch nicht weit verbreitet, aber es ist wahrscheinlich, dass diese oder eine ähnliche Spezifikation die weit verbreitete Verwendung von statischen API-Schlüsseln zur Authentifizierung überflüssig machen wird. Anstatt das System so zu konfigurieren, dass es jedem vertraut, der den API-Schlüssel erhält, wirst du es so konfigurieren, dass es nur denjenigen Workloads vertraut, die sowohl eine gültige ID vorweisen können als auch auf deiner Liste der Dinge stehen, denen du vertraust.

Wenn du Identitätsdokumente verwenden kannst, brauchst du nicht so viele Geheimnisse zu verwalten. Ich kann eine einfache Anfrage stellen und bekomme die Geheimnisse, die ich für den Zugriff auf andere Ressourcen benötige, dann vergesse ich die Geheimnisse und frage später wieder nach. Da Identitätsdokumente jedoch noch nicht weit verbreitet sind und viele Arten von Ressourcen sie noch nicht akzeptieren, brauchst du einige Werkzeuge und Techniken, um Geheimnisse zu verwalten. Diese werden wir uns als Nächstes ansehen.

Geheimnisse Management

Ich habe vorhin über Passwörter vor allem im Zusammenhang mit der Authentifizierung einer Person an einem System gesprochen. Für Verwaltungsbenutzer und Endbenutzer gibt es Techniken zur Verwaltung von Geheimnissen schon so lange, wie es Geheimnisse gibt. Sie reichen von gut (Passwortbörsen und physische Tresore) bis richtig schlecht (die allgegenwärtigen Post-it-Zettel auf dem Monitor oder unter der Tastatur). Obwohl der Begriff Geheimhaltungsmanagement im Allgemeinen immer dann verwendet wird, wenn man sich an ein Geheimnis erinnern muss, wird er in der Regel speziell für Geheimnisse verwendet, die von einem System verwendet werden, um mit einem anderen zu kommunizieren.

Betrachten wir zum Beispiel den Fall, dass ein Anwendungsserver mit einem Datenbankserver kommunizieren muss. Hier kann natürlich keine Multi-Faktor-Authentifizierung verwendet werden, denn der Anwendungsserver hat weder einen Hardware-Sicherheitsschlüssel noch einen Fingerabdruck!⁸ Das bedeutet, dass du mit den Authentifizierungsdaten für System-zu-System-Verbindungen sehr vorsichtig umgehen musst, denn sie können deine einzige Verteidigungslinie für die Authentifizierung sein.

Die Authentifizierung von System zu System kann mit einem Passwort, einem API-Schlüssel, einem kryptografischen Token oder einem Paar öffentlicher/privater Schlüssel erfolgen. Alle diese Lösungen haben etwas, das geheim gehalten werden muss. Wir bezeichnen all diese Dinge einfach als Geheimnisse, und bei der Verwaltung der Geheimnisse geht es darum, sie demjenigen zur Verfügung zu stellen, der sie braucht - und niemandem sonst. (Außerdem gibt es möglicherweise Dinge, die nichts mit der Authentifizierung zu tun haben, wie z. B. Verschlüsselungsschlüssel; diese sind zwar technisch gesehen auch Geheimnisse, werden aber normalerweise unter der Verwaltung von Verschlüsselungsschlüsseln behandelt).

Geheimnisse sind gefährliche Dinge, mit denen man vorsichtig umgehen sollte. Hier sind einige Grundsätze für den Umgang mit Geheimnissen:

• Geheimnisse sollten in regelmäßigen Abständen leicht zu ändern sein und immer dann, wenn es Grund zur Annahme gibt, dass sie nach außen gedrungen sein könnten. Wenn das Ändern des Geheimnisses bedeutet, dass du die Anwendung herunterfahren und es an vielen Stellen manuell ändern musst, ist das ein Problem.

• Geheimnisse sollten im Ruhezustand und in Bewegung immer verschlüsselt sein und nur nach ordnungsgemäßer Authentifizierung und Autorisierung an Systeme weitergegeben werden.

• Wenn möglich, sollte kein Mensch die Geheimnisse kennen - nicht die Entwickler, die den Code schreiben, nicht die Bediener, die einen Blick auf das laufende System werfen können, niemand. Das ist oft nicht möglich, aber wir sollten uns zumindest bemühen, die Anzahl der Personen zu minimieren, die Geheimnisse kennen!

• Das System, in dem die Geheimnisse gespeichert und weitergegeben werden, sollte gut geschützt sein. Wenn du alle Geheimnisse in einem Tresor aufbewahrst und dann die Schlüssel für den Tresor an Dutzende von Menschen verteilst, ist das ein Problem.

• Geheimnisse sollten für einen Angreifer so nutzlos wie möglich sein und gleichzeitig das Funktionieren des Systems ermöglichen. Auch hier gilt das Prinzip des geringsten Privilegs: Versuche, keine Geheimnisse zu haben, die den Schlüssel zum Königreich darstellen, wie z.B. Root-Zugriff auf alle Systeme, sondern nur begrenzte Geheimnisse, wie z.B. ein Geheimnis, das nur Lesezugriff auf eine bestimmte Datenbank erlaubt.

• Alle Zugriffe und Änderungen an Geheimnissen sollten protokolliert werden.

Selbst Unternehmen, die bei der Authentifizierung und Autorisierung gute Arbeit leisten, vernachlässigen oft die Verwaltung von Geheimnissen. Du kannst zum Beispiel sehr gut verfolgen, welche Personen persönliche IDs mit Zugang zu einer Datenbank haben, aber wie viele Personen kennen das Passwort, das der Anwendungsserver für die Kommunikation mit der Datenbank verwendet? Wird es regelmäßig geändert, und zwar sofort, wenn jemand das Team verlässt? Im schlimmsten Fall befindet sich dieses Passwort im Code des Anwendungsservers und ist in einem öffentlichen Repository wie GitHub hinterlegt.⁹

Es gab schon viele Sicherheitsverletzungen, weil Geheimnisse wie AWS API-Schlüssel versehentlich im Quellcode gespeichert wurden. Der Code braucht die Anmeldeinformationen, um zu funktionieren, wenn er bereitgestellt wird, aber Geheimnisse direkt im Quellcode (oder im Quellcode-Repository als Teil einer Konfigurationsdatei) zu speichern, ist aus zwei Gründen eine wirklich schlechte Idee:

• Das Quellcode-Repository wurde wahrscheinlich nicht in erster Linie für die Geheimhaltung von Informationen entwickelt. Seine Hauptfunktion besteht darin, die Integrität des Quellcodes zu schützenund zu verhindern, dass Unbefugte ihn verändern, um zum Beispiel eine Hintertür einzubauen. In vielen Fällen wird der Quellcode im Rahmen einer Social Coding-Initiative standardmäßig für alle zugänglich gemacht.

• Selbst wenn das Quellcode-Repository absolut sicher ist, ist es sehr unwahrscheinlich, dass jeder, der Zugriff auf den Quellcode hat, auch berechtigt sein sollte, die in der Produktionsumgebung verwendeten Geheimnisse zu sehen.

Die naheliegendste Lösung ist es, die Geheimnisse aus dem Quellcode zu nehmen und sie an einem anderen Ort zu speichern, z. B. an einem sicheren Ort in deinem Deployment-Tool oder auf einem speziellen Geheimhaltungsserver.

In den meisten Fällen besteht die Bereitstellung einer Anwendung aus drei Teilen, die zusammenkommen:

• Der Anwendungscode

• Die Konfiguration für diesen speziellen Einsatz

• Die Geheimnisse, die für diesen speziellen Einsatz benötigt werden

Wie bereits erwähnt, ist es keine gute Idee, alle drei Dinge zusammen zu speichern. Konfiguration und Geheimnisse zusammen aufzubewahren, ist ebenfalls oft eine schlechte Idee, denn Systeme, die für die Speicherung von Konfigurationsdaten konzipiert sind, sind möglicherweise nicht dafür ausgelegt, diese Daten geheim zu halten.

Werfen wir einen Blick auf vier vernünftige Ansätze zur Verwaltung von Geheimnissen, die von minimal sicher bis hochsicher reichen.

Der erste Ansatz besteht darin, bestehende Konfigurationsmanagementsysteme und Bereitstellungssysteme für die Speicherung von Geheimnissen zu nutzen. Viele gängige Systeme bieten heute die Möglichkeit, zusätzlich zu den normalen Konfigurationsdaten auch Geheimnisse zu speichern - zum Beispiel Ansible Vault und Chef verschlüsselte Datentaschen. Das kann ein sinnvoller Ansatz sein, wenn die Verteilungswerkzeuge sorgfältig mit den Geheimnissen umgehen und vor allem, wenn der Zugriff auf das Verteilungssystem und die Verschlüsselungsschlüssel streng kontrolliert wird. Allerdings gibt es oft zu viele Personen, die die Geheimnisse lesen können. Außerdem erfordert das Ändern von Geheimnissen in der Regel eine Neuverteilung des Systems, was in manchen Umgebungen schwieriger sein kann.

Der zweite Ansatz ist die Verwendung eines Geheimdienstservers. Mit einem separaten Geheimnisserver brauchst du nur einen Verweis auf das Geheimnis in den Konfigurationsdaten und die Möglichkeit, mit dem Geheimnisserver zu kommunizieren. Dann kann entweder die Verteilungssoftware oder die Anwendung das Geheimnis erfahren, indem sie sich mit dem Kennwort des Geheimservers authentifiziert... aber du siehst das Problem, oder? Jetzt musst du dich um ein weiteres Geheimnis (das Passwort für den Secrets Server) kümmern.

Auch wenn dieser Ansatz nicht perfekt ist, so ist er doch sehr wertvoll für dieVerwaltung von Geheimnissen:

• Die Anfragen des Geheimdienstservers können protokolliert werden, so dass du möglicherweise einen unbefugten Benutzer oder eine unbefugte Einrichtung erkennen und daran hindern kannst, auf die Geheimnisse zuzugreifen. Dies wird in Kapitel 7 näher erläutert.

• Der Geheimnisserver kann neben dem Passwort noch andere Möglichkeiten nutzen, um festzustellen, ob die Anfrage legitim ist, z. B. den IP-Adressbereich, der das Geheimnis anfordert. Wie in Kapitel 6 erläutert, reicht die IP-Zulassungsliste allein in der Regel nicht aus, aber sie ist eine nützliche zusätzliche Kontrolle.

• Du kannst die Geheimnisse später ganz einfach aktualisieren, und alle deine Systeme, die die Geheimnisse abrufen, erhalten die neuen Geheimnisse automatisch.

Der dritte Ansatz hat alle Vorteile eines Geheimservers, verwendet aber eine sichere Einführungsmethode, um die Wahrscheinlichkeit zu verringern, dass ein Angreifer die Anmeldeinformationen für den Zugriff auf den Geheimserver erhalten kann:

1. Dein Deployment Tooling kommuniziert mit dem Secrets Server, um ein einmalig verwendbares Geheimnis zu erhalten, das es an die Anwendung weitergibt.

2. Die Anwendung tauscht das Geheimnis dann gegen das echte Geheimnis auf dem Geheimnisserver ein und verwendet es, um alle anderen benötigten Geheimnisse zu erhalten und im Speicher zu speichern. Wenn jemand das Einmalgeheimnis bereits benutzt hat, schlägt dieser Schritt fehl und die Anwendung kann eine Warnung senden, dass etwas nicht stimmt.

Dein Deployment Tooling benötigt immer noch einen Satz statischer Anmeldedaten für deinen Secrets Server, aber damit kann es nur einmalige Schlüssel erhalten und nicht direkt Geheimnisse einsehen. (Wenn dein Deployment Tooling komplett kompromittiert ist, könnte ein Angreifer eine gefälschte Kopie einer Anwendung einsetzen, um die Geheimnisse zu lesen, aber das ist schwieriger als das direkte Lesen der Geheimnisse und wird eher entdeckt).

Das Betriebspersonal kann die Geheimnisse oder die Anmeldedaten für den Geheimhaltungsserver nur mit komplizierten Techniken zum Auslesen des Speichers einsehen. Anstatt das Geheimnis einfach aus einer Konfigurationsdatei auszulesen, müsste ein Schurke beispielsweise den Systemspeicher auslesen und ihn nach dem Geheimnis durchsuchen oder einen Debugger an einen Prozess anhängen, um das Geheimnis zu finden.

Der vierte Ansatz, falls verfügbar, ist die Nutzung einiger Angebote, die vom Cloud-Provider in deine Cloud-Plattform integriert wurden, um das Problem der "Schildkröten auf dem Weg nach unten" zu vermeiden:

1. Einige Cloud-Provider bieten Instanz-Metadaten oder Identitätsdokumente für Systeme an, die in der Cloud bereitgestellt werden. Deine Anwendung kann dieses Identitätsdokument abrufen, das in etwa besagt: "Ich bin Server ABC. Der Cloud-Provider hat dieses Dokument für mich kryptografisch signiert, was meine Identität beweist."

2. Der Secrets Server kennt dann die Identität des Servers sowie Metadaten wie z. B. Tags, die mit dem Server verbunden sind. Er kann diese Informationen nutzen, um eine Anwendung, die auf dem Server läuft, zu authentifizieren und zu autorisieren und ihr die restlichen Geheimnisse zukommen zu lassen, die sie zum Funktionieren braucht. In Zukunft könntest du das Identitätsdokument direkt mit den meisten Cloud-Diensten verwenden und bräuchtest den Geheimhaltungsservergar nicht mehr!

Fassen wir die vier vernünftigen Ansätze zur Verwaltung von Geheimnissen zusammen:

• Bei der ersten Methode werden die Geheimnisse nur im Verteilungssystem gespeichert und der Zugang zum Verteilungssystem wird streng kontrolliert. Standardmäßig sieht niemand die Geheimnisse, und nur autorisierte Personen haben die technische Möglichkeit, sie im Verteilungssystem einzusehen oder zu ändern.

• Der zweite Ansatz ist die Verwendung eines Secrets-Servers, der Geheimnisse speichert. Entweder der Verteilungsserver oder die verteilte Anwendung kontaktiert den Geheimhaltungsserver, um die notwendigen Geheimnisse zu erhalten und sie zu verwenden. In vielen Fällen sind die Geheimnisse auch nach der Bereitstellung noch in den Konfigurationsdateien oder Umgebungsvariablen der laufenden Anwendung sichtbar, so dass das Betriebspersonal die Geheimnisse oder die Anmeldedaten für den Geheimdienstserver leicht einsehen kann.

• Bei der dritten Methode kann der Deployment-Server nur ein einmaliges Token erhalten und es an die Anwendung weitergeben, die dann die Geheimnisse abruft und im Speicher hält. So bist du davor geschützt, dass die Anmeldedaten für den Geheimhaltungsserver oder die Geheimnisse selbst abgefangen werden.

• Der vierte Ansatz nutzt die Bereitstellungsplattform selbst als Basis des Vertrauens. Ein IaaS-Anbieter gibt zum Beispiel signierte Identitätsdokumente an virtuelle Maschinen aus, anhand derer der Secrets-Server entscheiden kann, welche Geheimnisse er der virtuellen Maschine zur Verfügung stellt.

Es gibt mehrere Produkte und Dienste, die dir bei der Verwaltung von Geheimnissen helfen. HashiCorp Vault und Keywhiz sind eigenständige Produkte, die vor Ort oder in der Cloud implementiert werden können, und AWS Secrets Manager ist über ein As-a-Service-Modell verfügbar.

Autorisierung

Sobald du die Authentifizierungsphase abgeschlossen hast und weißt, wer deine Nutzer sind, musst du sicherstellen, dass sie nur die Aktionen ausführen dürfen, für die sie bestimmt sind. Einige Beispiele für die Autorisierung sind die Erlaubnis, überhaupt auf eine Anwendung zuzugreifen, auf eine Anwendung mit Schreibrechten zuzugreifen, auf einen Teil des Netzwerks zuzugreifen oder auf die Cloud-Konsole zuzugreifen.

Endbenutzer-Anwendungen verwalten die Autorisierung oft selbst. So kann es zum Beispiel für jeden Benutzer eine Datenbankzeile oder ein Dokument geben, in dem die Zugriffsberechtigung des Benutzers aufgeführt ist. Das ist zwar sinnvoll, weil jede Anwendung bestimmte Funktionen zulassen kann, aber es bedeutet, dass du jede Anwendung besuchen musst, um alle Zugriffsrechte eines Benutzers zu sehen.

Die wichtigsten Konzepte, an die du dich bei der Autorisierung erinnern musst, sind das geringstmögliche Recht und die Trennung der Aufgaben. Zur Erinnerung: Least Privilege bedeutet, dass deine Benutzer, Systeme oder Tools nur auf das zugreifen können sollten, was sie für ihre Arbeit benötigen, und nicht mehr. In der Praxis bedeutet das in der Regel, dass du eine "Standardverweigerungsrichtlinie" einführst, d. h., wenn du etwas nicht ausdrücklich genehmigst, ist es nicht erlaubt.

Die Trennung (oder Segregation) von Aufgaben kommt eigentlich aus der Welt der Finanzkontrolle, wo für Schecks über einen bestimmten Betrag zwei Unterschriften erforderlich sind. In der Welt der Cloud-Sicherheit bedeutet dies in der Regel, dass sichergestellt werden muss, dass keine Person die Sicherheit der gesamten Umgebung vollständig untergraben kann. Zum Beispiel sollte jemand, der in der Lage ist, Änderungen an Systemen vorzunehmen, nicht auch die Möglichkeit haben, die Protokolle dieser Systeme zu ändern, oder die Verantwortung für die Überprüfung der Protokolle dieser Systeme tragen.

Für Cloud-Dienste und interne Anwendungen wird die zentrale Autorisierung immer beliebter.

Zentralisierte Autorisierung

Die Probleme mit der alten Ad-hoc-Praxis, Identitäten überall zu verstreuen, wurden durch föderierte Identitäten und Single Sign-On gelöst. Allerdings kann es sein, dass du immer noch überall verstreute Berechtigungsdatensätze hast - jede Anwendung kann ihre eigenen Datensätze darüber führen, wer was in dieser Anwendung tun darf.

Du kannst jemandem die Berechtigung komplett entziehen, indem du seine Identität löschst (vorausgesetzt, die dauerhaften Zugriffstoken sorgen nicht dafür, dass die Berechtigung eine Weile bestehen bleibt), aber was ist, wenn du nur einen Teil des Zugriffs entziehst? Die Möglichkeit, jemandem die Identität zu entziehen, ist wichtig, aber es ist eine ziemlich schwerfällige Art, die Zugriffsverwaltung durchzuführen. Oft braucht man eine feiner abgestufte Zugriffsverwaltung. Mit einer zentralen Autorisierung kannst du an einer einzigen Stelle sehen und kontrollieren, worauf deine Nutzer/innen Zugriff haben.

In einer herkömmlichen Anwendung wurde die gesamte Autorisierungsarbeit intern in der Anwendung durchgeführt. In der Welt der zentralen Autorisierung werden die Verantwortlichkeiten normalerweise zwischen der Anwendung und dem zentralen Autorisierungssystem aufgeteilt. In manchen Systemen gibt es mehr Details, aber hier sind die grundlegenden Komponenten:

Policy Enforcement Point (PEP)

Dieser Punkt wird in der Anwendung implementiert, wo die Anwendung den Zugriff kontrolliert. Wenn du nicht den in der Richtlinie festgelegten Zugriff hast, lässt der Dienst oder die Anwendung dich die Funktion nicht ausführen. Die Anwendung prüft den Zugang, indem sie den Policy Decision Point um eine Entscheidung bittet.

Politischer Entscheidungspunkt (PDP)

Dieser Punkt ist im zentralisierten Autorisierungssystem implementiert. Die PDP nimmt die von der Anwendung zur Verfügung gestellten Informationen (z. B. Identität und angeforderte Funktion), konsultiert ihre Richtlinien und gibt der Anwendung die Entscheidung, ob der Zugang für diese bestimmte Funktion gewährt wird.

Policy Administration Point (PAP)

Dieser Punkt wird auch im zentralen Autorisierungssystem implementiert. Dabei handelt es sich in der Regel um eine Web-Benutzeroberfläche und eine zugehörige API, über die du dem zentralen Autorisierungssystem mitteilen kannst, wer was tun darf.

Die meisten Cloud-Provider verfügen über ein zentrales Zugriffsmanagement, das ihre Dienste für Zugriffsentscheidungen heranziehen, anstatt sie selbst zu treffen. Du solltest diese Mechanismen nutzen, wenn sie verfügbar sind, damit du alle Zugriffsrechte, die einem bestimmten Administrator gewährt wurden, an einer Stelle einsehen kannst.

Rollen

Viele Cloud-Provider bieten Rollen oder vertrauenswürdige Profile an, die ähnlich wie Shared IDs sind: Du nimmst eine Rolle an, führst Aktionen aus, die die Rolle erlaubt, und gibst die Rolle wieder auf. Dies unterscheidet sich ein wenig von der traditionellen Definition einer Rolle, die eine Reihe von Berechtigungen oder Ansprüchen für einen Nutzer oder eine Gruppe darstellt.

Der Hauptunterschied zwischen geteilten IDs und Cloud-Provider-Rollen besteht darin, dass eine geteilte ID eine eigenständige Identität mit festen Anmeldeinformationen ist. Eine Cloud-Provider-Rolle ist keine vollständige Identität, sondern ein besonderer Status, der von einer anderen Identität eingenommen wird, die zum Zugriff auf eine Rolle berechtigt ist und der dann temporäre Anmeldeinformationen für den Zugriff auf diese Rolle zugewiesen werden.

Der rollenbasierte Zugriff kann eine zusätzliche Sicherheitsebene schaffen, indem er Benutzer/innen oder Dienste dazu verpflichtet, für privilegiertere Vorgänge explizit eine eigene Rolle zu übernehmen, nach dem Prinzip der geringsten Privilegien. Die meiste Zeit kann der Nutzer diese privilegierten Aktivitäten nicht ausführen, es sei denn, er setzt sich explizit den Rollen-"Hut" auf und nimmt ihn ab, wenn er fertig ist. Das System kann auch jede Anfrage zur Übernahme einer Rolle protokollieren, so dass Administratoren später feststellen können, wer diese Rolle zu einem bestimmten Zeitpunkt innehatte, und diese Informationen mit Aktionen im System vergleichen können, die Auswirkungen auf die Sicherheit haben.

Menschen sind nicht die einzigen Entitäten, die Rollen übernehmen können. Einige Komponenten (z. B. virtuelle Maschinen) können bei ihrer Erstellung eine Rolle übernehmen und Aktionen mit den dieser Rolle zugewiesenen Rechten durchführen.

Rollen versus Gruppen

An dieser Stelle fragst du dich vielleicht: "Was ist der Unterschied zwischen einer Rolle und einer Gruppe?" In ihrer reinsten Form sind das die Unterschiede:

• Eine Gruppe ist eine Sammlung von Entitäten, wie z. B. Benutzern, ohne Informationen darüber, welche Berechtigungen den Entitäten in dieser Gruppe erteilt werden. Die Gruppe VMAdminGroup könnte Chris und Barbara enthalten, aber du weißt nicht, was sie tun dürfen.

• Eine Rolle ist eine Sammlung von Berechtigungen, die Benutzern, Gruppen oder anderen Einheiten wie VMs gewährt werden können. Eine "reine" Rolle enthält jedoch keine Informationen darüber, wem diese Berechtigungen gewährt werden. Eine Rolle mit dem Namen VMAdminRole kann dir das Recht geben, virtuelle Maschinen zu erstellen und zu löschen, aber die Rollendefinition sagt dir nicht, wer diese Rechte tatsächlich erhält. In einigen Fällen wird eine Rolle bestimmten Benutzern oder Gruppen dauerhaft zugewiesen, und in anderen Fällen kann ein Benutzer berechtigt sein, eine Rolle explizit zu "übernehmen" und sie wieder abzulegen, wenn sie nicht mehr benötigt wird.

In der Praxis geben viele Rollen auch die Benutzer (oder Gruppen) an, für die sie gelten, und in vielen Fällen erhalten die Gruppenmitglieder durch die Gruppenmitgliedschaft einen einzigen permanenten Satz von Berechtigungen (eine einzige Rolle). Die Begriffe werden oft synonym verwendet, aber bei einigen Cloud-Providern ist die Unterscheidung wichtig (z. B. bei AWS IAM-Gruppen und Rollen).

Revalidiere

Zu diesem Zeitpunkt sollten deine Benutzer und die Automatisierung über Identitäten verfügen und nur das tun dürfen, was sie tun müssen. Du musst dafür sorgen, dass dies auch im Laufe der Zeit so bleibt.

Wie bereits erwähnt, ist der Schritt der Revalidierung sowohl in traditionellen als auch in Cloud-Umgebungen sehr wichtig, aber in Cloud-Umgebungen hast du möglicherweise keine zusätzlichen Kontrollen (wie z. B. physischen Gebäudezugang oder Netzwerkkontrollen), die dich retten, wenn du vergisst, den Zugriff zu widerrufen. Du musst jede Berechtigung regelmäßig überprüfen, um sicherzustellen, dass sie noch gebraucht wird.

Die erste Art der Revalidierung ist die automatische Revalidierung auf der Grundlage bestimmter Parameter. Du solltest zum Beispiel ein System haben, das automatisch einen Antrag auf Entzug des Zugangs stellt, wenn jemand die Organisation verlässt. Beachte, dass es nicht ausreicht, einfach nur die Identität des Nutzers zu löschen, da der Nutzer möglicherweise über zwischengespeicherte Zugangsdaten wie z. B. Zugriffstoken verfügt, die auch ohne die Möglichkeit, sich anzumelden, verwendet werden können. In solchen Situationen brauchst du einen Offboarding-Feed, also eine Liste von Personen, denen der Zugang entzogen werden soll. Jedes System, das längerfristige Anmeldeinformationen wie Zugangstoken ausgibt, muss diesen Offboarding-Feed mindestens einmal täglich verarbeiten und den Zugang dieser Personen sofort widerrufen.

Die zweite Art der Revalidierung erfordert ein menschliches Urteil, um festzustellen, ob eine bestimmte Person noch Zugang benötigt. Im Allgemeinen gibt es zwei Arten von Revalidierungen, die auf einem Urteil basieren:

Positive Bestätigung

Das ist stärker - es bedeutet, dass der Zugang verloren geht, es sei denn, jemand sagt ausdrücklich: "Dieser Zugang wird noch benötigt."

Negative Bestätigung

Das ist schwächer - es bedeutet, dass der Zugang erhalten bleibt, bis jemand sagt: "Dieser Zugang wird nicht mehr benötigt."

Eine negative Bestätigung ist für weniger wichtige Berechtigungsstufen geeignet, aber für Zugriffsarten mit großen Auswirkungen auf das Unternehmen solltest du eine positive Bestätigung verwenden. Der Nachteil der positiven Bestätigung ist, dass sie mehr Arbeit macht und der Zugriff versehentlich widerrufen werden kann, wenn die Anfrage nicht rechtzeitig bearbeitet wird (was zu betrieblichen Problemen führen kann).

Das größte Risiko bei der Revalidierung ist, dass jemand, der die Organisation (vielleicht unter umstrittenen Umständen) verlassen hat, weiterhin Zugang zu den Systemen hat. Außerdem sammelt sich der Zugang mit der Zeit an wie der Müll in der Küchenschublade (du kennst sie). Eine Revalidierung räumt diesen Müll aus.

Wenn es jedoch schwierig ist, Zugang zu erhalten, werden deine Nutzer/innen oft behaupten, dass sie immer noch Zugang brauchen, auch wenn sie ihn nicht mehr brauchen. Deine Bemühungen, unnötigen Zugang zu sperren, sind viel effektiver, wenn du auch ein schnelles, einfaches Verfahren hast, um den Zugang bei Bedarf zu gewähren. Wenn das nicht möglich ist, kann es effektiver sein, den Zugang automatisch zu entziehen, wenn er eine bestimmte Zeit lang nicht genutzt wurde, anstatt zu fragen, ob er noch gebraucht wird. Auch das birgt Risiken, denn es kann sein, dass niemand Zugang hat, wenn er gebraucht wird!

Cloud-Identity-as-a-Service-Angebote bieten neben den Authentifizierungs- und Autorisierungsdiensten zunehmend auch das Management des gesamten Identitätslebenszyklus an. Mit anderen Worten: Die Anbieter erkennen, wie wichtig es ist, dass die Beziehung nicht nur beginnt, sondern auch endet, und sie helfen dabei, die Beendigung zu rationalisieren und zu formalisieren.

Was sind das für Werkzeuge?

Die Namen der verschiedenen Tools, die bei der Verwaltung von Geheimnissen und Identitäten helfen, können verwirrend sein. Es herrscht Uneinigkeit über die Namensgebung, und viele Produkte erfüllen mehr als eine Funktion, aber hier ist ein Spickzettel mit einigen der gängigsten Namen und Funktionen:

• Eine Passwortmappe ist etwas, das Einzelpersonen benutzen, um Passwörter sicher zu speichern und automatisch auszufüllen. Einige Programme für Passwortbörsen bieten auch die Möglichkeit, Passwörter mit anderen Nutzern zu teilen.

• Ein Berechtigungsnachweis-Tresor, ein System zur Verwaltung von privilegiertem Zugang oder ein System zur Verwaltung von privilegierter Identität ist ein System, das es Einzelpersonen (und manchmal auch der Automatisierung) ermöglicht, Berechtigungsnachweise zu speichern, auszuchecken und zu verwenden. Dabei geht es vor allem darum, die individuelle Verantwortlichkeit zu gewährleisten, damit du weißt, welche Person einen Berechtigungsnachweis zu einem bestimmten Zeitpunkt verwendet. Das System kann auch andere Funktionen erfüllen, z. B. vorhandene privilegierte Konten aufspüren, Sitzungen aufzeichnen oder kontrollieren, welche Befehle erteilt werden können.

• Ein Verzeichnisdienst führt eine Liste von Benutzern und Gruppen und verfügt in der Regel über eine Möglichkeit, sie zu authentifizieren. Verzeichnisdienste sind heute oft Bestandteil andererProdukte.

• Ein Identity Access Management System oder Identity Provider ist ein System, das viele der zuvor beschriebenen Authentifizierungsarten durchführen kann und Föderationsprotokolle wie SAML und OIDC implementiert.

• Ein Identity-Governance-System ist ein System, das die Antrags-, Genehmigungs- und Überprüfungsphasen des Lebenszyklus abwickelt; es kann auch andere Funktionen haben, z. B. bei der Suche nach Problemen der Aufgabentrennung oder der Vereinfachung von Rollen.

• Ein System zur Verwaltung von Geheimnissen dient hauptsächlich der sicheren Speicherung von Anmeldeinformationen für die Automatisierung, aber auch Einzelpersonen können es nutzen. Es ist oft Teil einer Bereitstellungspipeline, die es ermöglicht, dass die neue Bereitstellung die Geheimnisse erhält, die sie zum Funktionieren braucht.

• Ein System zur Verwaltung von Verschlüsselungsschlüsseln ist speziell auf Geheimnisse ausgerichtet, die Verschlüsselungsschlüssel sind, und ermöglicht es dir auch, Funktionen wie die sichere Erzeugung von Schlüsseln und die Durchführung von Wrap/Unwrap-Funktionen mit Schlüsseln durchzuführen.

• Ein Zertifikatsmanagementsystem ist speziell auf X.509-Zertifikate ausgerichtet; es kann dir ermöglichen, sie zu erstellen und zu signieren und dich zu benachrichtigen, wenn sie ablaufen.

Alles in der Beispielanwendung zusammenfügen

Erinnerst du dich an unsere einfache Webanwendung aus Kapitel 1? Fügen wir nun Informationen zum Identitäts- und Zugriffsmanagement in das Diagramm ein, das nun wie in Abbildung 4-3 aussieht. Ich habe die gesamte Vertrauensgrenze der Anwendung entfernt, um das Diagramm zu vereinfachen.Es folgt eine Beschreibung der Schritte, von denen viele aus mehreren Teilen bestehen.

Abbildung 4-3. Beispielhaftes Anwendungsdiagramm mit IAM

Das hat das Diagramm leider ziemlich verkompliziert! Schauen wir uns einige der neuen Interaktionen im Detail an:

1. Der Endnutzer versucht, auf die Anwendung zuzugreifen und wird automatisch für den Zugriff zugelassen, wenn er eine gültige Identität besitzt und optional einige Tests zur Betrugsbekämpfung bestanden hat. Der Nutzer meldet sich mit SSO an, sodass die Identität der Anwendung mit dem externen Identitätsanbieter des Nutzers zusammengeführt wird und die Anwendung keine Passwörter überprüfen muss. Aus Sicht des Nutzers verwendet er dieselbe Identität wie in seinem Unternehmen oder auf seiner bevorzugten Social-Media-Seite.

2. Der Administrator beantragt den Zugang zur Verwaltung der Anwendung, der genehmigt wird. Der Administrator wird dann über ein zentrales Autorisierungssystem autorisiert. Die Autorisierung kann im IAM-System der Cloud erfolgen, oder das IAM-System der Cloud kann so konfiguriert sein, dass es das interne Autorisierungssystem der Organisation mit der Autorisierung beauftragt.

3. Der Administrator authentifiziert sich mit einem starken Passwort und einer Multi-Faktor-Authentifizierung beim Cloud IAM Service und erhält ein Zugangstoken, das er an andere Dienste weitergeben kann. Optional kann der Cloud IAM-Dienst auch so konfiguriert werden, dass er den Benutzer an das interne Authentifizierungssystem der Organisation weiterleitet.

4. Der Administrator stellt Anfragen an Cloud-Provider-Dienste, z. B. um eine neue virtuelle Maschine oder einen Container zu erstellen. (Hinter den Kulissen fragt der Cloud-VM-Dienst den Cloud-IAM-Dienst, ob der Administrator berechtigt ist).

5. Der Administrator nutzt einen Cloud-Provider-Dienst, um bei Bedarf Befehle auf den virtuellen Maschinen oder Containern auszuführen. (Hinter den Kulissen fragt der Cloud-Dienst "Befehl ausführen" den IAM-Dienst der Cloud, ob der Administrator berechtigt ist, diesen Befehl auf dieser virtuellen Maschine oder diesem Container auszuführen.) Wenn diese Funktion bei einem bestimmten Cloud-Provider nicht verfügbar ist, kann der Administrator eine herkömmliche Methode wie SSH verwenden, wobei die virtuelle Maschine das LDAP-Protokoll zur Authentifizierung und Autorisierung von Administratoren gegenüber einem Identitätsspeicher nutzt. Beachte, dass in einer Container-Umgebung die Ausführung von Befehlen möglicherweise nicht einmal für normale Wartungsarbeiten und Upgrades erforderlich ist, da der Administrator einen neuen Container bereitstellen und den alten löschen kann, anstatt Änderungen am bestehenden Container vorzunehmen.

6. Ein Geheimdienst dient dazu, das Passwort oder den API-Schlüssel für den Anwendungsserver für den Zugriff auf das Datenbanksystem zu speichern. Abbildung 4-3 zeigt, wie der Anwendungsserver ein Identitätsdokument vom Cloud-Provider erhält, direkt auf den Secrets-Server zugreift, um das Geheimnis zu erfahren, und auf die Datenbank zugreift. Wenn die Datenbank das Identitätsdokument direkt akzeptiert, brauchst du den Geheimnisserver vielleicht gar nicht! Der gleiche Prozess könnte für die Authentifizierung zwischen dem Webserver und dem Anwendungsserver ablaufen, aber derEinfachheit halber wird nur eine Geheimdienstinteraktion gezeigt. Der Geheimdienst kann von der Organisation selbst betrieben werden oder ein As-a-Service-Angebot eines Cloud-Providers sein.

Beachte, dass jedes Mal, wenn eine der Vertrauensgrenzen unserer Anwendung überschritten wird, die Entität, die die Vertrauensgrenze überschreitet, authentifiziert und autorisiert werden muss, um eine Aktion durchzuführen. Es gibt noch weitere Vertrauensgrenzen außerhalb der Anwendung, die nicht abgebildet sind, z. B. die Vertrauensgrenzen um die Cloud und die Organisationssysteme.

Fazit

Viele Unternehmen haben in der Vergangenheit das Identitäts- und Zugriffsmanagement in lokalen Umgebungen eher lax gehandhabt und sich zu sehr auf andere Kontrollen (wie physische Sicherheit und Netzwerkkontrollen) verlassen. In Cloud-Umgebungen ist IAM jedoch äußerst wichtig. Obwohl die Konzepte in der Cloud und vor Ort ähnlich sind, gibt es neue Technologien und Cloud-Dienste, die die Sicherheit verbessern und die Arbeit erleichtern.

Im gesamten Identitäts- und Zugangslebenszyklus werden die Schritte Beantragung, Genehmigung und Revalidierung leicht vergessen. Obwohl sie manuell durchgeführt werden können, bieten viele As-a-Service-Angebote, die ursprünglich nur die Authentifizierungs- und Autorisierungsschritte abdeckten, jetzt auch Workflows für den Genehmigungsschritt an, und dieser Trend beschleunigt sich.

Zentralisierte Authentifizierungssysteme geben Administratoren und Endnutzern eine einzige Identität, die in vielen verschiedenen Anwendungen und Diensten verwendet werden kann. Diese Systeme gibt es zwar schon lange in verschiedenen Formen, aber in Cloud-Umgebungen, wo sie standardmäßig verfügbar sind, sind sie noch wichtiger. Angesichts der Vielzahl von Cloud-Systemen und -Diensten kann die Verwaltung von Identitäten für jedes einzelne System und jeden einzelnen Dienst schnell zu einem Albtraum werden, wenn es sich nicht um die kleinsten Implementierungen handelt. Alte, vergessene Identitäten können von ihren früheren Besitzern oder von Angreifern genutzt werden, die nach einem einfachen Weg ins System suchen. Auch bei zentraler Authentifizierung musst du gute Passwörter und eine Mehrfaktor-Authentifizierung verwenden. Cloud-Administratoren und Endnutzer authentifizieren sich oft über unterschiedliche Systeme.

Wie bei den Authentifizierungssystemen kannst du mit zentralisierten Autorisierungssystemen alles, wozu eine Person berechtigt ist, an einer Stelle einsehen und ändern. Das kann die Gewährung und Überprüfung des Zugriffs erleichtern und Konflikte bei der Aufgabentrennung deutlicher machen. Achte darauf, dass du die Prinzipien der geringsten Privilegien und der Aufgabentrennung befolgst, wenn du sowohl Menschen als auch Automatisierung für Aufgaben autorisierst, und vermeide es, übermächtige Identitäten und Anmeldedaten für den täglichen Gebrauch zu haben.

Die Verwaltung von Geheimnissen ist ein sich schnell entwickelnder Bereich, in dem Geheimnisse, die für den Zugriff von System zu System verwendet werden, getrennt von anderen Konfigurationsdaten aufbewahrt und nach strengen Grundsätzen der Vertraulichkeit und Prüfung behandelt werden. In einigen Fällen kann die System-zu-System-Authentifizierung mit Hilfe von Identitätsdokumenten durchgeführt werden, wodurch die Notwendigkeit, Geheimnisse separat zu verwalten, verringert werden kann. Funktionen für die Verwaltung von Geheimnissen sind in bestehenden Konfigurationsmanagement-Produkten, eigenständigen Secrets-Server-Produkten und as-a-Service Cloud-Angeboten verfügbar.

Nachdem du nun weißt, wie du eine der Hauptursachen für Sicherheitsverstöße - unzureichendes Identitäts- und Zugriffsmanagement - vermeiden kannst, wollen wir uns nun eine der anderen Hauptursachen ansehen: unzureichendes Schwachstellenmanagement.

Übungen

1. Welche Schritte werden üblicherweise im Lebenszyklus der Zugangsverwaltung verwendet? Wähle alle zutreffenden aus.

   1. Zugang anfordern

   2. Zugang genehmigen

   3. Zugang nutzen

   4. Zugang neu validieren

2. Welche der folgenden Aussagen zur Authentifizierung ist richtig?

   1. Bei der Authentifizierung geht es darum zu beweisen, dass du derjenige bist, der du vorgibst zu sein.

   2. Um auf eine Anwendung zuzugreifen, brauchst du nur eine Authentifizierung.

   3. API-Schlüssel können für die Multi-Faktor-Authentifizierung verwendet werden.

   4. Für die interne Kommunikation ist keine Authentifizierung erforderlich.

3. Welche der folgenden Aussagen über die Autorisierung sind wahr? Wähle alles aus, was zutrifft.

   1. Bei der Autorisierung geht es um die Erlaubnis, auf eine bestimmte Anwendung zuzugreifen oder eine bestimmte Aktion durchzuführen.

   2. Wenn nicht jeder für eine bestimmte Aktion autorisiert ist, ist eine Autorisierung nur in Kombination mit einer Authentifizierung sinnvoll.

   3. Die Autorisierung kann sowohl zentral als auch dezentral wirksam sein.

4. Welche der folgenden Aussagen über Cloud-Identitätsdienste sind wahr? Wähle alles aus, was zutrifft.

   1. Ein Cloud-Identitätsdienst bietet in der Regel einen zentralen Dienst an, der die Nutzer authentifizieren kann.

   2. Ein Cloud-Identitätsdienst stellt in der Regel einen zentralen Dienst zur Verfügung, der Nutzer autorisieren kann.

   3. Ein Cloud-Identitätsdienst bietet in der Regel einen zentralen Dienst zur Speicherung von Geheimnissen an.

   4. Cloud-Identitätsdienste gibt es in verschiedenen Formen, z. B. Business-to-Consumer und Business-to-Employee.

5. Welche der folgenden Aussagen über Föderation und Single Sign-On sind wahr? Wähle alles aus, was zutrifft.

   1. Federation und Single Sign-On sind unterschiedliche Technologien, die ähnliche Ziele verfolgen.

   2. Föderierte Identität ist das Konzept der Verknüpfung von Identitäten auf zwei verschiedenen Systemen.

   3. Single Sign-On ist eine Möglichkeit, föderierte Identitäten zu nutzen.

   4. Single Sign-On ist für die Nutzer einfacher, geht aber oft mit einem Kompromiss aus geringerer Sicherheit einher.

¹ Siehe z.B. den Verizon Data Breach Investigations Report.

² Es gibt auch den Prozess der Überprüfung, ob eine Person diejenige ist, die sie vorgibt zu sein, bevor sie ihr eine Identität gibt. Diese Aufgabe wird normalerweise von den Onboarding-Prozessen der Unternehmen und den Helpdesk-Passwortwiederherstellungsprozessen übernommen und liegt normalerweise nicht in der Verantwortung der Nutzer von Cloud-Diensten.

³ Zero-Knowledge-Verschlüsselung bedeutet, dass dein Anbieter keine technische Möglichkeit hat, die Daten zu entschlüsseln, weil du normalerweise nur verschlüsselte Daten ohne Schlüssel sendest. Dies schränkt die Möglichkeiten des Anbieters stark ein und eignet sich vor allem für Backup-Dienste, bei denen der Anbieter nur eine große Menge an Daten ohne jegliche Verarbeitung vorhalten muss.

⁴ Ich bezeichne dies scherzhaft als das "Prinzip, dass man bereits am Arsch ist". Es ist aber gut, eine Möglichkeit zu haben, die Aktionen deines Anbieters zu überwachen, um eine mögliche Gefährdung zu erkennen.

⁵ Wenn du dir zu 99,9 % sicher bist, dass die Anmeldedaten eines Benutzers in einem Jahr nicht gestohlen werden, und du 1.000 Benutzer hast, dann bist du nur zu 36,7 % sicher, dass die Anmeldedaten keines deiner Benutzer in einem Jahr gestohlen werden. Wahrscheinlichkeiten machen Spaß!

⁶ Passwort Die Stärke eines Passworts wird normalerweise in "Entropie-Bits" gemessen. Eine sehr vereinfachte Erklärung ist, dass, wenn du einem Angreifer alle möglichen Informationen darüber gibst, wie ein Passwort aufgebaut ist, aber nicht das eigentliche Passwort, wie z. B. "es sind 20 Großbuchstaben", die Anzahl der Bits der Entropie ungefähr _log2(Anzahl der möglichen Passwörter) ist.

⁷ Diceware basiert auf der Idee, dass es für Menschen viel einfacher ist, sich Sätze als Buchstaben zu merken, und dass fast jeder ein paar sechsseitige Würfel finden kann. Du kannst die Diceware-Wortliste herunterladen und dann mit Würfeln fünf oder sechs Wörter aus der Liste zufällig auswählen. Es gibt auch Webseiten, die lokal eine Passphrase für dich generieren. Das Ergebnis ist ein extrem sicheres Passwort, das du dir leicht merken kannst.

⁸ Einige Anwendungen können sich an ein TOTP-Geheimnis erinnern und es zusammen mit einem Passwort zum Einloggen verwenden, aber das geschieht in der Regel nur dann, wenn ein Testtool vorgibt, ein Benutzer zu sein, der sich einloggt. Wenn ein Angreifer in diese Anwendung eindringt, findet er sowohl das Passwort als auch das TOTP-Geheimnis an derselben Stelle. In dieser Situation ist der zweite Faktor also aus Sicht der Sicherheit nicht wirklich hilfreich.

⁹ Es gibt sogar einen gängigen Begriff für Geheimnisse in öffentlichen GitHub-Repositories: "GitHub Deppen". Das Problem ist so weit verbreitet, dass GitHub jetzt Möglichkeiten hat, Code-Pushes zu blockieren, die Geheimnisse enthalten.