Das Identity and Access Management (IAM) ist das vielleicht wichtigste Werkzeug unter Ihren Schutzmaßnahmen. Bei Einbrüchen in Webanwendungen sind verloren gegangene oder gestohlene Credentials seit Jahren der häufigste Zugangsweg.1 Haben Angreifer gültige Credentials, um sich an Ihrem System anzumelden, können alle Patches und Firewalls der Welt nichts dagegen tun!
Identity Management und Access Management werden oft gemeinsam behandelt, aber es ist wichtig, sich darüber im Klaren zu sein, dass es sich um unterschiedliche Konzepte handelt:
Beim Authentifizieren beweisen Sie, dass Sie derjenige sind, der Sie vorgeben zu sein. In der realen Welt würde man dafür vielleicht einen Ausweis zeigen, der von einer vertrauenswürdigen Instanz ausgestellt wurde und auf dem Ihr Foto zu sehen ist. Jeder kann sich diesen Nachweis anschauen, Sie anschauen und dann entscheiden, ob Sie wirklich derjenige sind, als der Sie sich vorstellen. Ein Beispiel: Sie fahren zu einer Militärbasis und zeigen Ihren Führerschein, um zu versuchen, sich bei der Wache zu authentifizieren. Die Wache entscheidet sich vielleicht dazu, Ihnen zu glauben, oder sie ist der Meinung, dass das der Führerschein von jemand anderem ist, dass er vielleicht sogar komplett gefälscht ist, oder Sie erfahren, dass hier statt Führerscheinen nur Militärausweise akzeptiert werden.
Bei der Autorisierung geht es um die Möglichkeit, eine bestimmte Aktion auszuführen, und sie hängt im Allgemeinen von einer vorgeschalteten Authentifizierung ab (wir wollen wissen, wer jemand ist). Die Wache der Militärbasis könnte beispielsweise sagen: »Ja, ich glaube Ihnen, dass Sie derjenige auf dem Führerschein sind, aber Sie haben nicht die Erlaubnis, die Basis zu betreten.« Oder Sie erhalten die Erlaubnis, dürfen aber in die meisten Gebäude nicht hinein.
Bei der IT-Sicherheit vermengen wir oft diese beiden Konzepte. So erstellen wir beispielsweise eine Identität für jemanden (mit zugehörigen Credentials, wie zum Beispiel einem Passwort) und erlauben dann implizit jedem mit einer gültigen Identität, auf alle Daten auf dem System zuzugreifen. Oder wir entziehen jemandem den Zugriff, indem wir die Identität der Person löschen – das funktioniert, würde aber einem Zerschneiden des Führerscheins entsprechen, statt einfach nur den Zutritt zu verwehren. Auch wenn diese Lösungen in manchen Fällen passend sein können, ist es wichtig, den Unterschied zu verstehen. Ist es wirklich sinnvoll, jedem User vollständigen Zugriff auf das System zu geben? Was passiert, wenn wir jemandem außerhalb der Organisation eine Identität geben müssen, damit derjenige auf bestimmte Bereiche des Systems zugreifen kann – wird dieser User dann auch automatisch Zugriff auf interne Ressourcen erlangen?
Beachten Sie, dass die Konzepte (und Analogien) sehr schnell kompliziert werden können. Stellen Sie sich beispielsweise ein System vor, bei dem Sie nicht überall Ihren Führerschein vorzeigen, sondern nur ein Access-Badge erhalten, das Sie anderen zeigen, und dazu ein Refresh-Badge, das Sie nur dem Badge-Ausgebenden vorweisen müssen. Das Access-Badge authentifiziert Sie gegenüber jedermann, funktioniert aber nur für einen Tag – danach müssen Sie wieder zum Badge-Office gehen und das Refresh-Badge vorzeigen, um ein neues Access-Badge zu erhalten. Jede Site, der Sie Ihr Access-Badge zeigen, überprüft die Signatur darauf, um dessen Gültigkeit sicherzustellen, und ruft dann eine zentrale Stelle an, um zu fragen, ob Sie auf der Zugangsliste für diese Ressource stehen. Das entspricht der Art und Weise, wie manche IT-Zugangssysteme funktionieren, auch wenn sich Ihr Browser und die Systeme im Hintergrund glücklicherweise um all die Details kümmern!
Ein wichtiges Prinzip beim Identity and Access Management, aber auch in anderen Sicherheitsbereichen, ist, die Anzahl an Organisationen und Personen zu minimieren, denen Sie vertrauen müssen. So müssen Sie beispielsweise außer in Fällen, in denen Zero-Knowledge-Verschlüsselung funktioniert,3 den Authentifizierungs- und Autorisierungsprozessen Ihres Providers dahin gehend vertrauen, dass Ihre Daten vor fremden Augen verborgen bleiben. Sie müssen das Risiko in Kauf nehmen, dass Ihre Daten kompromittiert sind, wenn Ihr Provider vollständig kompromittiert ist. Aber da Sie sich schon dazu entschieden haben, dem Cloud-Provider zu vertrauen, werden Sie vermeiden, weiteren Personen oder Organisationen zu vertrauen, wenn Sie stattdessen das bestehende Vertrauen ohne zusätzliche Risiken nutzen können.4 Stellen Sie sich das wie einen Eintrittspreis vor – sobald Sie den »Preis« gezahlt haben, einer bestimmten Organisation zu vertrauen, sollten Sie das auch ausnutzen und es vermeiden, zusätzliche Risiken in das System zu bringen.
In klassischen IT-Umgebungen geschieht die Zugriffskontrolle oft teilweise über eine physische Zugangskontrolle (wer kann das Gebäude betreten) oder über eine Kontrolle des Netzwerkzugangs (wer kann sich aus der Ferne mit dem Netzwerk verbinden). So könnten Sie beispielsweise auf eine Perimeter-Firewall als zweite Verteidigungslinie setzen, wenn Sie einen Admin feuern und vergessen haben, ihm seinen Zugang zu einem der Server zu entziehen.
Es sei darauf hingewiesen, dass das selbst in einer Nicht-Cloud-Umgebung oft ein sehr geringes Sicherheitsniveau ist – sind Sie sicher, dass der Zugriffsschutz all Ihrer Ethernet-Ports, Wireless Access Points und VPN-Endpoints auch nur einem einfachen Angriff statthält? In den meisten Organisationen kann man fragen, ob man mal kurz die Toilette benutzen darf, um dann auf dem Weg ein Remote Access Device für 5 Euro in einen Ethernet-Port zu stecken. Oder man stiehlt WLAN- oder VPN-Credentials und gelangt ins Netz, ohne auch nur einen Fuß auf das Gelände zu setzen. Die Chancen mögen gering sein, dass einer bestimmten Person die Credentials gestohlen werden, aber die Gesamtwahrscheinlichkeit für unautorisierte Personen im Netzwerk nimmt schnell zu, wenn mehr und mehr Menschen in der Umgebung zu tun haben.5 Das ist in den Cloud-Umgebungen erst recht der Fall, wo der gesamte Zugriff remote geschieht und die Wahrscheinlichkeiten noch höher sind, dass sich unautorisierte Personen in einem angenommen sicheren Netzwerk befinden.
In klassischen Umgebungen geschieht eine Zugriffskontrolle manchmal einfach durch das Zurückziehen der gesamten Identität eines Users, sodass dieser sich gar nicht mehr anmelden kann. Aber in Cloud-Umgebungen würde das oft gar nicht das gesamte Problem lösen. Aus Bequemlichkeitsgründen stellen manche Services langlebige Authentifizierungstoken bereit, die auch dann noch funktionieren, wenn man sich nicht mehr an einer neuen Session anmelden kann. Sofern Sie so sorgfältig sind, einen »Offboarding«-Prozess zu haben, der Anwendungen darüber informiert, dass jemand die Firma verlässt, und die App dann den Zugriff komplett sperren kann, behalten die Personen eventuell auf Dinge Zugriff, den Sie nicht wollen. Denken Sie beispielsweise an einen Webmail-Service: Wann haben Sie das letzte Mal Ihr Passwort eingegeben? Das Ändern des Passworts oder ein Unterbinden des Anmeldens über die Log-in-Seite würde nicht helfen, wenn die Webmail-Provider nicht auch noch während einer Passwort-Änderungsaktion die Zugriffstoken in Ihren Browser-Cookies löschen würden.
Es gibt viele Beispiele für das Abfließen von Daten, weil Amazon-S3-Buckets für den öffentlichen Zugriff freigegeben waren. In jeder Organisation mit ausreichender Größe gibt es aber fast immer auch böswillige Personen im internen Netzwerk, die diese Informationen stehlen könnten – vielleicht sogar ohne dass dies bemerkt wird –, aber die Wahrscheinlichkeit eines Angriffs ist größer, wenn man aus dem Internet an die Daten kommt.
Mit diesen Beispielen will ich zeigen, dass viele Organisationen, die in On-Premises-Umgebungen mit laxen IAM-Schutzmaßnahmen gelebt haben, diese nun für die Cloud signifikant verbessern müssen. Glücklicherweise gibt es Services, die Ihnen das Leben dabei leichter machen.
Viele Menschen machen den Fehler, IAM nur als Authentifizierung und Autorisierung zu betrachten. Auch wenn beides sehr wichtig ist, enthält IAM darüber hinaus weitere Teile des Identitätslebenszyklus. Im Beispiel des Zutritts zu einer Militärbasis haben wir angenommen, dass Sie – der Anfordernde – schon eine Identität besitzen (Ihren Führerschein). Aber wie haben Sie ihn erhalten? Und wer hat Ihren Namen auf die Liste der Personen gesetzt, die auf der Basis zugelassen sind?
Viele Organisationen handhaben das so lala. Das Anfordern einer Identität geschieht vielleicht durch einen Anruf beim Administrator oder eine Mail an die Administratorin, die dann die Identität genehmigen und erstellen, ohne das Ganze zu dokumentieren. Das mag für sehr kleine Organisationen oder Umgebungen mit geringem Risiko in Ordnung sein, aber oft brauchen Sie ein System, das aufzeichnet, wann jemand Zugriff anfordert, wie sich der Anfordernde authentifiziert hat und wer die neue Identität oder den Zugriff genehmigt hat.
Noch wichtiger ist das Ende des Lebenszyklus. Sie benötigen ein System, das regelmäßig und automatisch prüft, ob die Identität und der Zugriff eines Users weiterhin notwendig sind. Vielleicht hat die Person die Firma verlassen oder die Abteilung gewechselt und sollte nicht länger Zugriff haben. (Oder schlimmer noch: Stellen Sie sich vor, Sie hätten die undankbare Aufgabe, jemanden zu feuern, und stellen einen Monat später fest, dass diese Person aufgrund menschlichen Versagens immer noch Zugriff auf ein wichtiges System hat!)
Es gibt viele verschiedene Versionen eines IAM-Lebenszyklusdiagramms mit unterschiedlichem Detaillierungsgrad. Das Diagramm in Abbildung 4-1 zeigt die minimale Anzahl an Schritten und adressiert sowohl das Erstellen wie auch das Löschen von Identitäten zusammen mit dem Erstellen und Löschen von Zugriffsregeln für diese Identitäten. Identität und Zugriff werden vom gleichen oder von verschiedenen Systemen gehandhabt, aber die Schritte bleiben die gleichen.
Abbildung 4-1: IAM-Lebenszyklus
Beachten Sie, dass Sie nicht unbedingt ein schickes automatisiertes System benötigen, um jeden einzelnen dieser Schritte zu implementieren. In einer Umgebung mit wenigen Anfordernden und wenigen Genehmigenden kann ein größtenteils manueller Prozess ausreichen, solange er konsistent implementiert ist und es Kontrollen gibt, um zu verhindern, dass ein einzelner Fehler einer Person zu Problemen führt. Aktuell sind die meisten automatisierten Systeme zum Managen des gesamten Lebenszyklus (häufig als Identity Governance Systems bezeichnet) auf größere Unternehmen ausgerichtet – in der Regel sind sie teuer und nur aufwendig zu implementieren. Aber es gibt einen wachsenden Trend, diese Governance-Lösungen wie andere Services in der Cloud bereitzustellen. Oft sind sie als Teil eines anderen Identity-and-Access-Service enthalten, sodass selbst kleinere Organisationen von ihnen profitieren können.
Es sei auch darauf hingewiesen, dass sich die genutzten Prozesse und Services deutlich unterscheiden können – abhängig davon, was die Entitäten sind. Die IAM-Systeme, mit denen Sie Ihren Mitarbeitenden Zugriff auf Ihren Cloud-Provider und Ihre internen Anwendungen geben, unterscheiden sich signifikant von solchen, bei denen Ihre Kunden einen Endanwenderzugriff auf Ihre Anwendung erhalten. Ich werde im Folgenden zwischen diesen beiden allgemeinen Fällen unterscheiden.
Vergessen Sie nicht die Identitäten für nicht menschliche Dinge im System, etwa für Anwendungen. Auch diese müssen wie Identitäten für Menschen gemanagt werden. Viele Teams sind wirklich gut darin, den Zugriff für Personen zu kontrollieren, haben aber nur sehr laxe Regeln für das, was Automationsprozesse dürfen.
Schauen wir uns diese Schritte an. Der Prozess beginnt, wenn jemand oder etwas eine Anforderung einreicht. Das kann die Führungskraft eines neuen Mitarbeitenden sein oder ein Automationsprozess wie Ihr HR-System.
Der Lebenszyklus beginnt, wenn eine Entität eine Identität oder einen Zugriff anfordert. Diese Entität sollte normalerweise auf irgendeine Art und Weise authentifiziert werden. Innerhalb Ihrer Organisation werden Sie keine anonymen Zugriffsanforderungen haben wollen, auch wenn die Authentifizierung in manchen Fällen einfach visuell oder akustisch geschehen kann, um die Person zu erkennen.
Soll ein Zugriff für die allgemeine Öffentlichkeit erfolgen – zum Beispiel für eine Webanwendung –, werden Sie diesen oft mit einer anderen Identität verbinden wollen, zum Beispiel einer bestehenden E-Mail-Adresse oder einer Mobilfunknummer.
Die üblichen Anforderungen sind:
In Cloud-Systemen geschieht der Anforderungsprozess oft »out of Band« also über einen Anfrageprozess innerhalb Ihrer Organisation, der das IAM-System der Cloud noch gar nicht einbezieht.
In manchen Fällen ist es akzeptabel, einen Zugriff implizit zu genehmigen. Wenn es beispielsweise um eine öffentlich verfügbare Webanwendung geht, wird oft jeder, der das möchte, automatisch Zugriff erhalten, sofern bestimmte Anforderungen erfüllt sind. Bei diesen Anforderungen kann es um Betrugsbekämpfung gehen, wie zum Beispiel eine gültige Mobilfunknummer, E-Mail-Adresse oder Kreditkartennummer anzugeben, ein CAPTCHA oder ein »Ich bin kein Roboter«-Formular abzuarbeiten oder nicht von einem anonymisierenden Ort zu kommen (wie einem VPN-Provider für Endanwender oder einem bekannten Tor Exit Node).
Aber innerhalb einer Organisation sollten die meisten Zugriffsanforderungen explizit bestätigt werden. In viele Fällen sind zwei Genehmigungen vernünftig – beispielsweise von dem oder der direkten Vorgesetzten des Users und von den Verantwortlichen für das System, auf das zugegriffen werden soll. Wichtig ist, dass man sich beim Genehmigen in einer Position befindet, in der man weiß, ob der angeforderte Zugriff sinnvoll und notwendig ist. Das ist ebenfalls ein interner Prozess für Ihr Team, der normalerweise ohne Interaktion mit Ihren Cloud-Providern abläuft.
Nach der Genehmigung kann das tatsächliche Erzeugen oder Löschen einer Identität und das Zuweisen oder Zurückziehen eines Zugriffs automatisch geschehen. So kann beispielsweise das Anforderungs-/Genehmigungssystem die APIs des Cloud-Providers nutzen, um die Identität zu erstellen oder den Zugriff zu gewähren.
In anderen Fällen kann ein Ticket, eine E-Mail oder eine andere Benachrichtigung erzeugt werden, aufgrund dessen oder deren eine Person manuell etwas tun muss. So muss sich vielleicht ein Admin am Cloud-Portal anmelden, um die neue Identität zu erstellen und ihr einen gewissen Basiszugriff zu gewähren. Automation ist zu bevorzugen, insbesondere für häufig angeforderte Elemente, um die Möglichkeit menschlicher Fehler zu verringern.
Die bisher besprochenen Punkte unterscheiden sich nicht wirklich von der Zugriffskontrolle in On-Premises-Umgebungen – bevor eine Identität existiert, müssen Sie sie anfordern, und Sie brauchen einen Prozess, um sie zu erstellen. Aber bei der Authentifizierung fängt es mit den Unterschieden an, weil es so viele mögliche Identitätsservices gibt.
Es ist wichtig, zwischen dem Identity Store und dem Protokoll zu unterschieden. Der Store ist die Datenbank mit allen Identitäten, während das Protokoll zum Authentifizieren von Usern und zum Überprüfen ihrer Identitäten dient – zum Beispiel Open-ID, SAML, LDAP oder andere.
Es gibt verschiedene Cloud-Services, die Ihnen dabei helfen können – abhängig davon, wer authentifiziert wird:
Die meisten Cloud-Provider bieten IAM-Services an, die genutzt werden müssen, wenn Sie auf deren Cloud-Services zugreifen wollen. Im Allgemeinen stehen sie ohne weitere Kosten zur Verfügung. Mit ihnen haben Sie eine zentrale Stelle, an der Sie die Identitäten der Cloud-Administratorinnen und -Administratoren in Ihrer Organisation und die ihnen zugewiesenen Zugriffsberechtigungen aller Services des Cloud-Providers managen können.
Das ist eventuell eine große Hilfe. Nutzen Sie Dutzende oder Hunderte Services von einem Cloud-Provider, kann es sehr schwierig sein, einen guten Überblick darüber zu bekommen, welche Zugriffsmöglichkeiten eine bestimmte Person hat, wenn Sie jeden Service einzeln aufrufen müssen. Außerdem kann es kompliziert sein, sicherzustellen, dass Sie alle Zugriffsmöglichkeiten deaktiviert haben, wenn diese Person Ihre Organisation verlässt. Das Zurückziehen von Zugriffsmöglichkeiten ist besonders wichtig, weil viele dieser Services direkt vom Internet aus genutzt werden können!
In Tabelle 4-1 finden Sie Beispiele für Identity-Services zum Authentifizieren Ihrer Cloud-Administratoren und -Administratorinnen bei den Services des Cloud-Providers.
Tabelle 4-1: Identity-Services der Cloud-Provider
Provider |
Cloud-Identity-Services |
Amazon Web Services |
AWS IAM |
Microsoft Azure |
Azure Active Directory |
Google Cloud Platform |
Cloud IAM |
IBM Cloud |
Cloud IAM |
Neben den Identitäten, die Ihre Organisation für den Zugriff auf die Services des Cloud-Providers nutzt, werden Sie auch Identitäten für Ihre Endanwender und Endanwenderinnen managen müssen – egal ob externe Kunden oder Ihre Mitarbeitenden.
Auch wenn Sie das Kundenidentitätsmanagement selbst in die Hand nehmen können, indem Sie einfach in einer Datenbank Einträge mit Passwörtern erzeugen, ist das oft für Ihre Kunden keine gute Experience, weil sie mit noch einem Log-in und einem weiteren Passwort hantieren müssen. Zudem gilt es signifikante Sicherheitsfallstricke zu vermeiden, wenn Sie Passwörter überprüfen (siehe Abschnitt »Passwörter, Passphrasen und API-Schlüssel« auf Seite 83). Es gibt zwei bessere Optionen:
Die Namen dieser Identity-as-a-Service-(IDaaS-)Angebote machen nicht immer klar, was sie tun. In Tabelle 4-2 finden Sie Beispiele großer Cloud-Provider, aber auch von Fremdanbietern. Es gibt in diesem Bereich viele Anbieter, die häufig wechseln, daher will die Tabelle keine Empfehlungen für genau diese Anbieter aussprechen. Bei Business-to-Employee-Szenarien können die meisten dieser IDaaS-Services auch Ihr Mitarbeiterverzeichnis nutzen, zum Beispiel Ihr internes Directory.
Tabelle 4-2: ID-Management-Systeme
Provider |
Services zum Management von Kunden- und Mitarbeiteridentitäten |
Amazon Web Services |
Amazon Cognito |
Microsoft Azure |
Azure Active Directory B2C |
Google Cloud Platform |
Identity Platform |
IBM Cloud |
App ID |
Okta |
Customer Identity Cloud, Workforce Identity Cloud |
Ping |
PingOne for Customers, PingOne for Workforce |
Egal ob Sie selbst Identitäten erzeugen oder einen Cloud-Service nutzen: Sämtliche personenbezogenen Daten, die Sie speichern oder verarbeiten, können gesetzlichen Regelungen wie der DSGVO der EU unterliegen.
Die Multifaktor-Authentifizierung ist eine der besten Möglichkeiten, sich vor schwachen oder gestohlenen Credentials zu schützen. Ist sie sauber implementiert, sorgt sie auch nur für wenig zusätzliche Last bei den Usern. Die meisten der in Tabelle 4-2 aufgeführten Identity-Services unterstützen eine Multifaktor-Authentifizierung.
Die verschiedenen Authentifizierungsfaktoren sind im Allgemeinen wie folgt definiert:
Wie der Name schon sagt, gehört zur Multifaktor-Authentifizierung der Einsatz von mehr als einem dieser Faktoren zur Authentifizierung. Das Verwenden von zwei gleichen Faktoren – zum Beispiel zwei Passwörtern – hilft nicht viel, weil mit einem Angriff gleich beide Passwörter ermittelt werden könnten! Die am häufigsten verwendete Implementierung ist die Zwei-Faktor-Authentifizierung (2FA), die etwas nutzt, das Sie wissen (zum Beispiel ein Passwort), und etwas, das Sie haben (wie zum Beispiel Ihr Mobiltelefon).
Bei 2FA ist es nicht erforderlich, dass einer der Faktoren ein Passwort ist. Passwortlose Anmeldungen mit zwei Faktoren (wie zum Beispiel einem physischen Device, das Sie haben, und Ihrem Fingerabdruck zum Entsperren des Device) können durchaus sicherer und bequemer als eine Authentifizierung über ein Passwort sein.
2FA sollte für die meisten Zugriffe der Standard sein. Korrekt implementiert, sorgt es für den Großteil der User für nur sehr wenig zusätzlichen Aufwand. Auf jeden Fall sollten Sie 2FA dort einsetzen, wo die Auswirkungen verlorener oder gestohlener Credentials groß wären, wie zum Beispiel für jeglichen privilegierten Zugriff, das Lesen oder Schreiben kritischer Daten oder den Zugriff auf Systeme (wie zum Beispiel E-Mails), mit denen sich andere Passwörter zurücksetzen lassen. Betreiben Sie zum Beispiel eine Banking-Site, könnten Sie sich dazu entscheiden, dass die Auswirkungen gering sind, wenn jemand einen Kontostand einsehen kann, aber groß (was heißt, dass 2FA erforderlich ist), wenn jemand versucht, Geld zu überweisen. Eine zwingend erforderliche zusätzliche Authentifizierung für risikoreichere Aktivitäten wird als Step-Up Authentication bezeichnet.
Managen Sie eine Cloud-Umgebung, birgt der unautorisierte administrative Zugriff auf das Cloud-Portal oder auf APIs ein sehr hohes Risiko, weil es bei solch einem Angriff im Allgemeinen möglich ist, all Ihre Daten zu kompromittieren. Sie sollten für solche Art von Zugriffen eine Zwei-Faktor-Authentifizierung einschalten – die meisten Cloud-Provider unterstützen das schon nativ. Nutzen Sie Single Sign-On (SSO) (siehe Abschnitt »Single Sign-On« auf Seite 86), führt Ihr SSO-Provider eventuell schon 2FA für Sie durch.
Viele Services bieten mehrere Authentifizierungsmethoden an. Die gebräuchlichsten sind:
Passwörter und Passphrasen (etwas, das Sie wissen)
Ein Passwort ist nicht an ein bestimmtes Device gebunden und funktioniert von überall. Die Probleme mit Passwörtern sind reichlich und wohlbekannt: Viele Menschen wählen Passwörter, die verbreitet sind und sich durch Dictionary-Angriffe aushebeln lassen oder so einfach und kurz sind, dass Brute-Force-Attacken Erfolg haben. Oder sie werden für mehrere Services genutzt, sodass das Kompromittieren eines Service dafür sorgt, dass auch andere (die durch Credential-Stuffing-Attacken ermittelt werden können) kompromittiert sind. Es ist wirklich an der Zeit, keine Passwörter mehr zu nutzen, aber Veränderungen sind immer schwerfällig.
PINs (etwas, das Sie wissen)
Oberflächlich betrachtet, scheinen PINs noch schlimmer als Passwörter zu sein, weil sie im Allgemeinen einfacher sind. Entscheidend bei ihnen ist aber, dass sie nur zusammen mit einem physischen Device nützlich sind. Jemand, der Ihre PIN errät, ohne das zugehörige Device zu besitzen (meist ein Mobiltelefon, ein Laptop oder ein Hardwaresicherheitsschlüssel), kann damit nichts anfangen, was einen erfolgreichen Angriff viel schwieriger macht.
SMS-Nachrichten auf ein Mobilgerät (etwas, das Sie haben)
Diese Methode ist nicht mehr so beliebt, weil sich die Telefonnummer leicht von jemandem (per SIM Cloning oder Nummernportierung) übernehmen oder weil sich die Nachricht abfangen lässt, daher sollte sie bei neuen Umsetzungen nicht mehr zum Einsatz kommen, und bestehende sollten zu einer anderen Methode wechseln. Um die SMS-Nachrichten empfangen zu können, benötigt man zudem Mobilfunkempfang.
Time-based One-time Passcodes, TOTPs (etwas, das Sie haben)
Für diese Methode ist ein Mobilgerät mit einem initialen »Secret« (meist durch einen 2-D-Barcode übermittelt) erforderlich. Das Secret ist eine Formel, mit dem beispielsweise jede Minute ein Einmal-Passwort berechnet wird. Das Einmal-Passwort muss nur für ein oder zwei Minuten sicher aufbewahrt werden, aber mit dem initialen Secret kann jegliches Device gültige Passwörter erzeugen und sollte daher nach der Verwendung zerstört oder an einem sicheren Ort deponiert werden. Nachdem das initiale Secret übermittelt wurde, ist für das Mobilgerät nur noch eine synchronisierte Uhrzeit, aber keine Netzwerkverbindung mehr erforderlich. Der größte Nachteil ist, dass TOTPs für User weniger praktisch sind und sich »abfischen« lassen – ein Angreifer, der Sie dazu bringt, sowohl das Passwort als auch den Passcode auf einer Fake-Site einzugeben, kann Zugriff erlangen.
Hash-based One-time Passcodes oder HOTPs (etwas, das Sie haben)
Diese haben ähnliche Vor- und Nachteile wie die TOTPs, nutzen aber einen Zähler statt der Uhrzeit, sodass keine synchronisierte Uhr notwendig ist. Sie können jedoch aus dem Tritt kommen, wenn zu viele Codes erzeugt, aber nicht genutzt wurden.
Push-Benachrichtigungen auf ein Mobilgerät (etwas, das Sie haben)
Mit dieser Methode stellt eine schon authentifizierte Clientanwendung auf einem Mobilgerät eine Verbindung zu einem Server her, der dann einen einmalig nutzbaren Code zurückschickt oder um Bestätigung bittet. Das ist so lange sicher, wie die Authentifizierung für die schon authentifizierte Clientanwendung sicher ist, erfordert aber einen Netzwerkzugriff für das Mobilgerät. Der größte Nachteil ist, dass ein Angreifer eventuell dazu in der Lage ist, den User dazu zu bringen, einer clever gefälschten Seite zuzustimmen oder ihn durch sehr viele Anfragen dazu zu bringen, irgendetwas abzunicken.
Fingerabdruckleser, Gesichts- oder Retinaerkennung (etwas, das Sie sind)
Diese biometrischen Methoden lassen sich zwar oft mit genug Aufwand täuschen (durch das Herstellen von Replikas des Fingers, Gesichts oder Auges), aber die Implementierungen werden nach und nach besser und sind mittlerweile gut genug, um als einzelner Faktor die meisten Sicherheitsanforderungen zu erfüllen.
Ein Hardware-Device, wie zum Beispiel eines, das die Standards FIDO Universal 2nd Factor (U2F) oder FIDO2 erfüllt (etwas, das Sie haben)
FIDO U2F ist nur ein zweiter Authentifizierungsfaktor, der meist zusammen mit einem Passwort genutzt wird, während FIDO2 als kombiniertes Multifaktor-Device dienen kann, das eine passwortlose Authentifizierung ermöglicht. FIDO2-Devices werden auch als Passkeys bezeichnet (https://oreil.ly/vo9ed). Das ist die bei Weitem beste Option, weil der Passkey weiß, mit welcher Anwendung er redet, und er sich nicht durch Fake-Sites in die Irre führen lässt. Zuerst gab es nur Stand-alone-Hardwaresicherheitsschlüssel, aber die Technologie ist mittlerweile in die meisten Laptops und Mobilgeräte eingebaut. Diese Art von Authentifizierung wird vermutlich in der nahen Zukunft allgegenwärtig sein – integriert in Smartphones und Wearables wie Uhren oder Ringe. Ein FIDO2-Device lässt sich mit einer PIN oder einem biometrischen Faktor entsperren, was zwei Faktoren in einem Device für eine sehr starke, gegen Phishing resistente und passwortlose Authentifizierung ermöglicht.
Beachten Sie, dass viele der Methoden, mit denen überprüft wird, ob Sie »etwas haben«, bei Social-Engineering-Angriffen verletzlich sind, wie zum Beispiel, den User unter falschen Vorgaben anzurufen und ihn nach dem Einmal-Passwort zu fragen! Selbst die stärkste Form der Authentifizierung, wie zum Beispiel FIDO2, kann Opfer eines Downgrade-Angriffs sein, bei dem der User auf einer Fake-Seite landet, die schreibt: »Das hat nicht funktioniert, bitte versuche eine andere (unsicherere) Methode.« Neben dem Ausrollen einer Multifaktor-Authentifizierung müssen Sie den Usern auch ein Minimum an Training angedeihen lassen, damit sie die verbreiteteren Angriffe erkennen können.
Alle großen Cloud-Provider bieten Möglichkeiten an, eine Multifaktor-Authentifizierung zu implementieren, auch wenn Google den netteren Begriff 2-Step-Verification nutzt.
Nutzen Sie eine Multifaktor-Authentifizierung, sind Passwörter oder Passphrasen nicht mehr länger Ihre einzige Verteidigungslinie. Sofern Sie aber nicht zu einem vollständig passwortlosen Modell wechseln, ist es weiterhin wichtig, gute Passwörter zu wählen. Das gilt noch mehr in Cloud-Umgebungen, weil ein Angreifer in vielen Fällen Passwörter von jedem Ort der Welt direkt über das Internet ausprobieren kann.
Eine »Passphrase« ist nur der Begriff für ein längeres, sichereres Passwort, daher werde ich hier den allgemeineren Begriff »Passwort« nutzen. Es gibt zwar viele Ratschläge und Diskussionen über gute Passwörter, meine Empfehlungen für die Wahl von Passwörtern sind aber einfach:
API-Schlüssel sind Passwörtern sehr ähnlich, aber dafür gedacht, nicht von Menschen, sondern von Automatismen genutzt zu werden. Daher können Sie hier keine Multifaktor-Authentifizierung nutzen. Stattdessen sollte es sich um lange Zufallsstrings handeln (siehe Punkt 3 der obigen Liste). Anders als bei den meisten User-Identitäten, bei denen Sie eine öffentliche User-ID und ein privates Passwort haben, gibt es in solchen Szenarien normalerweise nur einen privaten API-Schlüssel, der dem System mitteilt, wer Sie sind, und Sie gleichzeitig authentifiziert.
Passwörter verifizieren
Vielleicht haben Sie die Aufgabe bekommen, die Passwörter der User zu verifizieren. Das kann komplizierter sein, als es auf den ersten Blick scheint. Sofern das möglich ist, sollten Sie diese Aufgabe vermeiden!
Am einfachsten verifizieren Sie Passwörter, indem Sie eine Liste der User und Passwörter ablegen und dann prüfen, ob das eingegebene Passwort zu dem auf der Liste passt. Das ist aber eine ausgesprochen schlechte Idee, denn wenn eine Person Zugriff auf Ihre Liste erhält, hat sie alles, was sie braucht, um sich als einer dieser User auszugeben!
Eine viel bessere Methode ist, nicht die Passwörter selbst zu speichern, sondern etwas, das genutzt werden kann, um die Passwörter zu verifizieren. Das wird durch die Verwendung eines Einweg-Hashs umgesetzt, den Sie mit einer Funktion ermitteln können, wenn Sie das Passwort haben, der sich aber nicht umgekehrt nutzen lässt, um das Passwort zu erhalten. Der Teufel liegt hier jedoch im Detail – nutzen Sie die falsche Funktion oder die falschen Parameter für die Funktion, kann das Passwort leicht durch einen Brute-Force-Angriff geknackt werden, indem man sehr viele mögliche Passwörter ausprobiert. Sehr gute Hash-Algorithmen wie SHA-256 sind für Passwort-Hashes eine Katastrophe, weil sie sich schon durch ihr Design schnell berechnen lassen.
Aktuell sollten Passwort-Hashes mithilfe von scrypt-, bcrypt-, PBKDF2- oder Argon2-Funktionen mit sinnvollen Parametern gespeichert werden. Die Empfehlungen für Funktionen und Parameter verändern sich mit der Zeit, weil die Cracking-Hardware ausgefeilter wird und Schwächen in Hashing-Algorithmen gefunden werden. Daher müssen Sie Ihre Entscheidungen zumindest jährlich begutachten. Ändern Sie Algorithmen oder Parameter, werden alle neuen Parameter die neuen Methoden nutzen, aber es gibt durch das Design keine Möglichkeit, die alten Hashes in neue Hashes umzuwandeln. Ist eine Änderung sehr dringend (weil es beispielsweise Beweise für einen Einbruch gibt, der Zugriff auf die Passwort-Hashes erlangt haben könnte), müssen Sie sofort alle User-Passwörter zurücksetzen.
Selbst wenn Sie Ihre Hashes sicher ablegen, sollten Sie einen Testmechanismus umsetzen, der User davon abhält, allzu leicht zu erratende Passwörter wie abc123 oder Herbst2018 zu nutzen. Bei Angriffen werden zunehmend Techniken wie das »Password Spraying« genutzt, bei denen ein einfaches Passwort gleichzeitig für Hunderte oder Tausende IDs ausprobiert wird. Dadurch wird oft kein Alarm ausgelöst, weil jede ID nur einen einzelnen fehlgeschlagenen Anmeldeversuch registriert. Sie sollten auch überwachen, ob viele Fehlanmeldungen von einem Ort aus kommen, was oft ein Indiz für Credential-Stuffing-Angriffe ist, bei denen eine Liste mit Passwörtern von einer Site bei einer anderen Site ausprobiert wird.
Nutzen Sie bei Cloud-Services und Anwendungen wenn möglich eine Federated Identity von einem anderen Provider oder einem Consumer/Employee IAM Cloud Service. Für einen Zugriff auf Systemebene verwenden Sie eine schlüsselbasierte Authentifizierung oder eine zentrale Authentifizierung mit einer Prüfung auf sichere Passwörter. Speichern und überprüfen Sie Passwort-Hashes nicht selbst, solange Sie eine gute Alternative dafür haben.
Shared IDs sind Identitäten, für die mehr als eine Person das Passwort oder andere Credentials besitzt, wie zum Beispiel der eingebaute root- oder Administrator-Account eines Systems. Das kann in Cloud-Systemen genauso wie in On-Premises-Systemen schwierig sein.
Wenn es möglich ist, sollte jeder User und jedes Tool eine eigene ID haben, die nicht von irgendjemand oder irgendetwas anderem genutzt wird. Viele Systeme erlauben es, Usern eine privilegierte Rolle oder für manche Aktivitäten eine ID mit mehr Berechtigungen zuzuweisen, wie dies beispielsweise durch sudo auf unixoiden Systemen der Fall ist. Müssen Sie Shared IDs verwenden, ist es notwendig, genau sagen zu können, welches Individuum (oder welches automatisierte Tool) die ID für einen Zugriff genutzt hat.
Beim gemeinsamen Verwenden einer ID (wie zum Beispiel root) hat das System, auf dem Sie die Shared ID nutzen, keine Möglichkeit, zu erkennen, wer sich da gerade angemeldet hat. Sie benötigen also einen eigenen Prozess und dazu passende Tools, um die gemeinsam genutzten Credentials auszuchecken und sie danach zu ändern, wenn sie wieder eingecheckt werden. Solche Tools werden meist als Privileged-Access-Management- (PAM-) oder Privileged-Identity-Management-(PIM-)Systeme bezeichnet, die auch noch andere Funktionen erfüllen können, wie beispielsweise das Aufzeichnen der Session oder das Verhindern bestimmter Befehle.
Eine Federated Identity ist keine bestimmte Technologie, sondern ein Konzept. Dabei können Sie Identitäten auf zwei verschiedenen Systemen haben, und die Administrationsteams dieser Systeme nutzen Technologien, die diese Identitäten miteinander verknüpfen. So müssen Sie nicht jeweils manuell Accounts auf jedem System erstellen. Aus der Sicht des Users haben Sie nur eine einzige Identität.
In der Praxis bedeutet das im Allgemeinen, dass sowohl Firma A als auch Firma B Ihre Firmen-E-Mail-Adresse, etwa user@company-a.com, als Ihre Identität nutzen und Firma B sich an Firma A wendet, um Sie zu authentifizieren. Firma A wird dann eine Assertion oder ein Token mit ihrem Gütesiegel zurückschicken: »Ja, das ist tatsächlich user@company-a.com; wir haben das überprüft, hier ist unsere Signatur, um zu beweisen, dass wir es sind, und Sie haben schon zugestimmt, dass Sie uns vertrauen, User zu authentifizieren, dessen Identität auf @company-a.com endet.«
Single Sign-On (SSO) ist ein Satz von Technologieimplementierungen, die auf dem Konzept der Federated Identity aufbauen.
In der schlechten alten Zeit besaß jede Website eine eigene Kombination aus Log-in und Passwort. Das sind dann ganz schön viele Passwörter, um die sich die User kümmern müssen! Das vorhersehbare Ergebnis ist, dass die User häufig die gleichen Passwörter auf mehreren Sites nutzten, sodass diese nur so gut geschützt waren wie die schwächste Site.
Auftritt SSO: Die Idee ist, dass eine Website nicht nach der ID und dem Passwort des Users fragen, sondern den User stattdessen an einen zentralen Identity Provider (IdP) weiterleitet, dem sie vertraut. (Beachten Sie, dass der Identity Provider nicht einmal Teil der gleichen Organisation sein muss – die einzige Anforderung ist, dass die Website ihm vertraut.) Der IdP kümmert sich um das Authentifizieren des Users, zum Beispiel per Username und Passwort sowie hoffentlich einem zusätzlichen Faktor. Dann schickt er den User zurück an die ursprüngliche Website und gibt dabei den Beweis mit, dass er den User überprüft hat. Manchmal wird der IdP auch noch Informationen (wie Gruppenmitgliedschaften) mitliefern, durch die die Website Autorisierungsentscheidungen treffen kann, zum Beispiel ob der User normaler User, Administrator oder gar nichts sein sollte.
SSO funktioniert meist nur mit Websites und mobilen Anwendungen, auch wenn sich das langsam ändert. Eventuell brauchen Sie ein anderes Protokoll (wie LDAP, Kerberos, TACACS+ oder RADIUS), wenn Sie eine zentrale Authentifizierung für Nicht-Web-Assets wie Netzwerk-Devices oder Betriebssysteme durchführen wollen.
Sie finden kaum etwas anderes, das für die User einfacher ist und eine bessere Sicherheit bietet! Die User müssen sich nur einen Satz Credentials merken, und weil diese Credentials nur der Identity Provider zu Gesicht bekommt (und keine der einzelnen Sites), würde eine kompromittierte Site nicht die Credentials der User kompromittieren. Zudem kann Ihr SSO-Provider Schutzmaßnahmen implementieren, die sich an anderen Zero-Trust-Prinzipien orientieren, wie zum Beispiel der Prüfung, ob ein ungemanagtes oder veraltetes Device genutzt wird oder ob die Credentials des Users gleichzeitig aus zwei verschiedenen Ländern zum Einsatz kommen. Solche Schutzmaßnahmen lassen sich für einzelne Anwendungen nur schwer umsetzen.
Der einzige Nachteil von SSO ist, dass es für eine Website etwas aufwendiger zu implementieren ist als schlechtere Authentifizierungsmechanismen (wie das Vergleichen mit einem Klartextpasswort oder einem unsicher gehashten Passwort in einer Datenbank).
Aktuell sind die Security Assertion Markup Language (SAML – die Abkürzung reimt sich auf »Camel«) und OpenID Connect (OIDC) die verbreitetsten SSO-Technologien. Die Endergebnisse sind zwar gleich, aber die verwendeten Mechanismen unterscheiden sich durchaus.
SAML gibt es seit 2005 und aktuell in der Version 2.0. Es ist eine der verbreitetsten SSO-Technologien – vor allem bei Anwendungen für große Unternehmen. Es gibt viele ausführliche Beschreibungen zur Funktionsweise von SAML, aber hier will ich eine sehr vereinfachte liefern:
Nachdem Sie sich einmal angemeldet haben, funktioniert alles eine Weile automatisch, bis dieses Assertion-Dokument abgelaufen ist – dann müssen Sie sich erneut beim IdP anmelden.
Es sei hier noch erwähnt, dass es nie eine direkte Kommunikation zwischen der initialen Webseite und dem Identity Provider gibt – Ihr Browser muss die ganze Arbeit erledigen und die Informationen von einem Ort zum anderen tragen. Das kann in manchen Fällen wichtig sein, in denen die Netzwerkkommunikation eingeschränkt ist.
Beachten Sie auch, dass SAML aufgrund ihres Designs nur Identitätsinformationen liefert. Sie beantwortet nicht die Frage, ob Sie dazu autorisiert sind, sich anzumelden oder andere Aktivitäten auszuführen, auch wenn manche SAML-Implementierungen zusammen mit der Assertion zusätzliche Informationen (etwa eine Gruppenmitgliedschaft) mitgeben, die von der Anwendung genutzt werden können, um Autorisierungsentscheidungen zu treffen.
OpenID Connect ist ein deutlich neuerer Authentifizierungslayer, der 2014 fertiggestellt wurde und auf OAuth 2.0 aufsetzt. Er verwendet kein XML, sondern JSON Web Tokens (JWTs, manchmal auch »Jots« ausgesprochen), und nutzt etwas andere Begriffe (so gibt es bei OIDC beispielsweise meist die »Relying Party«, die dem »Service Provider« in SAML entspricht).
OIDC bietet sowohl Authorization Code Flows (für klassische Webanwendungen) als auch Implicit Flows (für Anwendungen, die auf der Clientseite in JavaScript implementiert sind). Es gibt zwar diverse Unterschiede zu SAML, aber im Endergebnis erhält die zu authentifizierende Anwendung auch hier niemals Ihr Passwort, und Sie müssen sich nicht für jede Anwendung neu authentifizieren.
Manche Services können Requests von mit OIDC zusammenspielenden Anwendungen annehmen und diese für einen SAML-IdP »übersetzen«. In größeren Organisationen kommt es oft vor, dass beide Standards im Einsatz sind, und die meisten IdPs unterstützen auch beide.
Was müssen Sie tun, wenn Sie Single Sign-On zusammen mit einer Legacy-Anwendung nutzen wollen, die das nicht unterstützt? Eine Möglichkeit besteht darin, etwas vor die Anwendung zu setzen, das die SSO-Requests verarbeitet und dann der Anwendung mitteilt, wer die User sind.
Die Legacy-Anwendung wird diesem Frontend-Service (oft ein Reverse Proxy) in Bezug auf die Authentifizierung vertrauen, aber es ist sehr wichtig, dass keine Verbindungen von irgendetwas anderem angenommen werden. Solche Techniken sind manchmal erforderlich, wenn eine bestehende Anwendung in die Cloud gebracht wird, aber noch nicht so überarbeitet wurde, dass SSO direkt unterstützt wird. Viele der weiter oben aufgeführten Identity-as-a-Service-Provider bieten auch Wege für SSO zusammen mit Legacy-Anwendungen an.
Wie schon weiter oben erwähnt, gehen wir oft davon aus, dass bei Automationen, wie zum Beispiel einem Programm, das auf einem System läuft, schon eine Identität zugewiesen und eine Möglichkeit zum Überprüfen dieser Identität ermöglicht wurde. Wenn ich beispielsweise ein neues System aufsetze, kann ich einen Usernamen und ein Passwort für dieses System erstellen, um darauf zuzugreifen, und das Erstellen dieser Credentials als Teil des Aufsetzprozesses durchführen. In vielen Cloud-Umgebungen gibt es allerdings einfachere Möglichkeiten.
Ein Prozess, der auf einem bestimmten System läuft, kann einen wohlbekannten Endpoint kontaktieren, der ihm alles über das aktuelle System erzählen wird, und der Prozess wird zudem einen kryptografisch signierten Weg bereitstellen, um die Identität des Systems beweisen zu können. Die genauen Details unterschieden sich je nach Provider, aber konzeptionell sieht das Ganze wie in Abbildung 4-2 aus.
Abbildung 4-2: Identitätsdokumente nutzen
Das ist jedoch nicht narrensicher, weil jeder Prozess auf dem System diese Metadaten anfordern kann – unabhängig von seiner Berechtigungsstufe im System. Sie dürfen also entweder nur Prozesse der gleichen Vertrauensstufe auf dem System ausführen oder müssen Maßnahmen ergreifen, mit denen niedriger privilegierte Prozesse davon abgehalten werden, die Identität des gesamten Systems zu ermitteln. Das kann insbesondere in Containerumgebungen wichtig sein, bei denen jeder Container auf einem Hostsystem das Identitätsdokument anfordern und sich dann als dieses Hostsystem ausgeben könnte. In solchen Fällen müssen Sie die Container davon abhalten, den Metadatenservice zu erreichen.
Bei diesem System ist auch erforderlich, dass der Cloud-Service diese Art des vom Metadatenservice genutzten Dokuments und der Signatur erkennt. Gäbe es doch nur ein Standardformat für solche Dokumente und Signaturen, sodass sich der Cloud-Service dazu entscheiden könnte, Containern in einem bestimmten Cluster oder virtuellen Maschinen in einem bestimmten Cloud-Account zu vertrauen! Hier schlägt die große Stunde von SPIFFE (https://spiffe.io) – einer Standardmethode, die es einer Workload (zum Beispiel einem Container, einer virtuellen Maschine oder einer Multi-Node-Anwendung) erlaubt, sich bei jemand anderem zu authentifizieren. SPIRE ist eine Referenzimplementierung der SPIFFE-Spezifikation. Aktuell kommt SPIFFE noch nicht sehr oft zum Einsatz, aber irgendwann werden diese oder ähnliche Spezifikationen den weitverbreiteten Einsatz statischer API-Schlüssel für die Authentifizierung ablösen. Anstatt das System so zu konfigurieren, dass es jedem vertraut, der den API-Schlüssel besitzt, werden Sie es so konfigurieren, dass es nur den Workloads vertraut, die sowohl eine gültige ID besitzen als auch auf Ihrer Liste der vertrauenswürdigen Dinge stehen.
Können Sie Identitätsdokumente nutzen, müssen Sie nicht so viel Secrets Management betreiben. Als Workload kann ich einen einfachen Request ausführen und erhalte dann die Secrets, mit denen ich andere Ressourcen ansprechen kann. Danach vergesse ich die Secrets wieder und frage erneut nach ihnen, wenn ich sie wieder brauche. Da Identitätsdokumente aber noch nicht allzu verbreitet sind und viele Arten von Ressourcen sie noch nicht akzeptieren, werden Sie Tools und Techniken zum Managen von Secrets benötigen. Das schauen wir uns als Nächstes an.
Ich habe schon weiter oben über Passwörter gesprochen – dort aber vor allem im Kontext einer Person, die sich an einem System authentifiziert. Administrative User und Enduser setzen Techniken zum Secrets Management schon so lange ein, wie es Secrets gibt – von guten Techniken (Passwort-Wallets und physischen Safes) bis hin zu wirklich schlechten (den allgegenwärtigen Post-its am Monitor oder unter der Tastatur). Während der Begriff Secrets Management eigentlich immer dann passt, wenn Sie ein Secret haben, das Sie sich merken müssen, wird er im Allgemeinen spezifischer eingesetzt, um sich auf Secrets zu beziehen, die von einem System genutzt werden, um mit einem anderen zu sprechen.
Schauen wir uns beispielsweise den Fall an, bei dem ein Anwendungsserver mit einem Datenbankserver sprechen muss. Hier kann natürlich keine Multifaktor-Authentifizierung zum Einsatz kommen – der Anwendungsserver hat keinen Hardware-Security-Schlüssel und auch keinen Fingerabdruck!8 Sie müssen also mit den Authentifizierungs-Credentials für System-to-System-Verbindungen sehr vorsichtig sein, weil sie Ihre einzige Verteidigungslinie sein könnten.
Credentials für die System-to-System-Authentifizierung können ein Passwort, einen API-Schlüssel, ein kryptografisches Token oder ein Public/Private-Key-Paar beinhalten. Sämtliche dieser Lösungen besitzen etwas, das geheim gehalten werden muss. Wir nennen all diese Dinge einfach Secrets, und beim Secrets Management geht es darum, sie denjenigen zur Verfügung zu stellen, die sie benötigen – aber sonst niemandem. (Sie können zudem Elemente haben, die nichts mit einer Authentifizierung zu tun haben, aber trotzdem geheim gehalten werden müssen, wie zum Beispiel kryptografische Schlüssel – die sind technisch gesehen zwar Secrets, werden aber meist spezifischer durch ein Encryption Key Management behandelt.)
Secrets sind gefährliche kleine Dinger, die sehr vorsichtig behandelt werden sollten. Hier ein paar Prinzipien zum Managen von Secrets:
Selbst Organisationen, die Authentifizierung und Autorisierung sehr gut im Griff haben, übersehen oft das Secrets Management. So bekommen Sie es vielleicht gut hin, zu protokollieren, welche Personen persönliche IDs für den Zugriff auf eine Datenbank haben, aber wie viele Personen kennen das Passwort, das der Anwendungsserver nutzt, um mit der Datenbank zu sprechen? Wird es regelmäßig geändert – und sofort, wenn jemand das Team verlässt? Im schlimmsten Fall findet sich dieses Passwort im Code des Anwendungsservers und ist in ein öffentliches Repository (wie GitHub) eingecheckt.9
Es gibt viele Einbrüche, die unabsichtlich im Quellcode gespeicherte Secrets – zum Beispiel AWS-API-Schlüssel – ausgenutzt haben. Der Code benötigt die Credentials, damit er nach dem Deployen funktioniert, aber es ist eine wirklich schlechte Idee, Secrets direkt im Quellcode abzulegen (oder im Quellcode-Repository als Teil einer Konfigurationsdatei). Dafür gibt es zwei Gründe:
Die offensichtlichste Lösung ist, die Secrets aus dem Quellcode herauszunehmen und sie woanders abzulegen – zum Beispiel an einem sicheren Ort innerhalb Ihrer Deployment-Tools oder auf einem dedizierten Secrets-Server.
In den meisten Fällen besteht ein Deployment einer Anwendung aus drei Elementen, die zusammenspielen:
Es ist eine wirklich schlechte Idee, diese drei Dinge gemeinsam abzulegen (siehe oben). Es ist oft auch nicht gut, Konfiguration und Secrets gemeinsam zu verwalten, weil Systeme, die zum Managen von Konfigurationsdaten entworfen sind, nicht unbedingt dafür gedacht sind, die Daten geheim zu halten.
Schauen wir uns für das Secrets Management vier sinnvolle Ansätze an – von minimaler bis zu der höchsten Sicherheit.
Beim ersten Ansatz nehmen wir bestehende Configuration Management Systems und Deployment-Systeme für das Speichern von Secrets. Viele verbreitete Systeme besitzen eine Funktionalität, um neben normalen Konfigurationsdaten auch Secrets zu verwalten – zum Beispiel Ansible Vault oder Chef Encrypted Data Bags. Das kann ein vernünftiger Ansatz sein, wenn die Deployment-Tools sorgfältig mit den Secrets umgehen und vor allem wenn der Zugriff auf das Deployment-System und die Schlüssel eng begrenzt ist. Aber oft gibt es zu viele Personen, die die Secrets lesen können. Zudem ist bei einem Ändern der Secrets ein erneutes Deployen des Systems erforderlich, was in manchen Umgebungen schwieriger sein kann.
Beim zweiten Ansatz nutzen wir einen Secrets-Server. Mit solch einem eigenen Server benötigen Sie in den Konfigurationsdaten nur eine Referenz auf das Secret und die Möglichkeit, mit dem Secrets-Server zu sprechen. Dann kann entweder die Deployment-Software oder die Anwendung das Secret erhalten, indem sie sich beim Secrets-Server authentifiziert, wozu ein Passwort erforderlich ist … Sie sehen das Problem, oder? Jetzt haben Sie ein weiteres Secret (das Passwort zum Secrets-Server), um das Sie sich Gedanken machen müssen.
Diese Lösung ist zwar nicht perfekt, aber sie hat durchaus ihren Wert:
Der dritte Ansatz bietet alle Vorteile eines Secrets-Servers, nutzt aber eine sichere Vorbereitungsmethode, um die Wahrscheinlichkeit zu verringern, dass bei einem Angriff die Credentials für den Zugriff auf den Secrets-Server ergattert werden:
Ihr Deployment-Tool benötigt weiterhin einen Satz statischer Credentials für Ihren Secrets-Server, aber damit kann es nur Einmal-Schlüssel erhalten und noch nicht direkt auf die Secrets zugreifen. (Wenn Ihr Deployment-Tool vollständig kompromittiert ist, kann ein Angreifer auch eine Fake-Kopie einer Anwendung deployen, um Secrets zu lesen, aber das ist schwieriger, als die Secrets direkt abzurufen, und wird auch mit größerer Wahrscheinlichkeit erkannt.)
Operations-Personal kann die Secrets oder die Credentials zum Secrets-Server nur mit größerem Aufwand einsehen. Statt beispielsweise einfach das Secret aus einer Konfigurationsdatei auszulesen, müsste eine böswillige Person den Systemspeicher in eine Datei schreiben und dort nach dem Secret suchen oder einen Debugger mit einem Prozess verbinden, um das Secret zu finden.
Beim vierten Ansatz nutzen Sie – sofern verfügbar – Angebote von Ihrer Cloud-Plattform, um das »Turtles all the way down«-Problem zu vermeiden:
Fassen wir die vier sinnvollen Ansätze des Secrets Management einmal zusammen:
Es gibt eine Reihe von Produkten und Services, die Ihnen beim Managen von Secrets helfen. HashiCorp Vault und Keywhiz sind eigenständige Produkte, die in On-Premises-Umgebungen oder in der Cloud implementiert werden können, während der AWS Secrets Manager als As-a-Service-Modell zur Verfügung steht.
Haben Sie die Authentifizierungsphase abgeschlossen und wissen, wer Ihre User sind, müssen Sie nun sicherstellen, dass sie nur die Aktivitäten ausführen, die sie auch ausführen dürfen. Beispiele für eine Autorisation sind der Zugriff auf eine Anwendung im Ganzen, auf eine Anwendung mit Schreibzugriff, auf Teile des Netzwerks oder auf die Cloud-Konsole.
Enduser-Anwendungen kümmern sich oft selbst um die Autorisierung. Es mag zum Beispiel einen Eintrag pro User in einer Datenbank oder in einem Dokument geben, der festlegt, was für Zugriffsberechtigungen der User hat. Das ist sinnvoll, weil jede Anwendung spezifische Funktionen hat, die zu autorisieren sind, aber es bedeutet auch, dass Sie jede Anwendung aufsuchen müssen, wenn Sie herausfinden wollen, was ein User alles darf.
Die wichtigsten Konzepte, die man bei Autorisierungen im Hinterkopf behalten sollte, sind Least Privilege und Separation of Duties. Least Privilege bedeutet, dass Ihre User, Systeme oder Tools nur auf das zugreifen können, was sie zum Erledigen ihrer Aufgaben benötigen – aber nicht mehr. In der Praxis bedeutet dies meist, dass Sie eine »Deny by Default«-Richtlinie verfolgen, sodass etwas nicht möglich ist, sofern Sie es nicht spezifisch erlauben.
Die Separation (oder Segregation) of Duties kommt eigentlich aus der Finanzwelt, wo für Schecks, die einen gewissen Betrag übersteigen, zwei Unterschriften erforderlich sind. In der Welt der Cloud-Sicherheit wird das meist eher allgemein umgesetzt, indem sichergestellt wird, dass nicht eine Person allein die Sicherheit der gesamten Umgebung unterminieren kann. So sollte beispielsweise jemand mit der Möglichkeit, Änderungen an Systemen vorzunehmen, nicht auch die Möglichkeit besitzen, die Logs für diese Systeme anzupassen oder sie zu überprüfen.
Für Cloud-Systeme und interne Anwendungen wird eine zentrale Autorisation zunehmend beliebter.
Das Problem der alten Ad-hoc-Praxis mit den über die ganze Firma verteilten Identitäten wurde durch Federated Identities und Single Sign-On gelöst. Aber eventuell sind immer noch die Autorisierungsberechtigungen wild verteilt – jede Anwendung kann für sich selbst dokumentieren, was die User dürfen und was nicht.
Sie können jemanden komplett deautorisieren, indem Sie seine Identität löschen (sofern nicht persistente Zugriffstoken noch eine Weile einen Zugriff ermöglichen), aber wie sieht es aus, wenn man nur bestimmte Zugriffe unterbinden möchte? Es ist wichtig, die Identität von jemanden entfernen zu können, aber das ist für ein Access Management schon ein sehr grobes Vorgehen. Oft benötigen Sie feingranularere Wege, den Zugriff zu managen. Mit einer zentralen Autorisierung sehen und kontrollieren Sie an einem Ort, worauf Ihre User Zugriff haben.
In einer klassischen Anwendung wurden alle Autorisierungsaufgaben in der Anwendung selbst umgesetzt. In der Welt der zentralen Autorisierung wird die Zuständigkeit meist zwischen der Anwendung und dem zentralen Autorisierungssystem aufgeteilt. Die Details unterscheiden sich je nach System, aber dies sind die grundlegenden Komponenten:
Policy Enforcement Point (PEP)
Dieses Element ist in der Anwendung dort implementiert, wo der Zugriff gesteuert wird. Haben Sie nicht den angegebenen Zugriff in der Policy, wird der Service oder die Anwendung das Ausführen dieser Funktion auch nicht zulassen. Die Anwendung prüft das Ganze, indem sie den Policy Decision Point nach einer Entscheidung fragt.
Policy Decision Point (PDP)
Dieses Element ist im zentralen Autorisierungssystem implementiert. Der PDP erhält die Informationen von der Anwendung (wie zum Beispiel die Identität und die angefragte Funktion), schaut in seine Policy und liefert der Anwendung seine Entscheidung zurück, ob der Zugriff für diese bestimmte Funktion gewährt wird oder nicht.
Policy Administration Point (PAP)
Dieses Element ist ebenfalls im zentralen Autorisierungssystem implementiert. Dabei handelt es sich im Allgemeinen um eine Weboberfläche samt zugehöriger API, über die Sie dem zentralen Autorisierungssystem mitteilen können, wer wozu berechtigt ist.
Die meisten Cloud-Provider bieten eine zentrale Access-Management-Lösung an, die ihre Services für Zugriffsentscheidungen konsultieren, statt selbst Entscheidungen zu treffen. Wenn diese Mechanismen vorhanden sind, sollten Sie sie nutzen, damit Sie alle gewährten Zugriffe für einen bestimmten Administrator oder eine Administratorin an einer Stelle überblicken können.
Viele Cloud-Provider bieten Rollen oder Trusted Profiles an, die Shared IDs insofern ähneln, als Sie eine Rolle annehmen, Aktionen ausführen, die diese Rolle erlaubt, und die Rolle dann wieder verwerfen. Das unterscheidet sich ein wenig von der klassischen Definition einer Rolle, bei der es sich um einen Satz von Berechtigungen handelt, die einem User oder einer Gruppe gewährt werden.
Der Hauptunterschied zwischen Shared IDs und Rollen von Cloud-Providern ist, dass eine Shared ID eine eigene Identität mit festen Credentials ist. Eine Rolle eines Cloud-Providers ist keine vollständige Identität – es handelt sich um einen speziellen Status, der von einer anderen Identität angenommen wird, der der Zugriff auf die Rolle erlaubt wurde und die dann temporäre Credentials für den Zugriff auf diese Rolle erhält.
Ein rollenbasierter Zugriff kann als zusätzliche Sicherungsschicht eingefügt werden. Dabei werden User oder Services dazu verpflichtet, für privilegiertere Operationen explizit eine eigene Rolle einzunehmen und damit dem Least-Privilege-Prinzip zu folgen. Die User können diese privilegierten Aktivitäten normalerweise nicht ausführen – sie müssen sich erst den »Rollenhut« aufsetzen und ihn nach Abschluss der Arbeiten wieder abnehmen. Das System kann zudem jede Anforderung der Rolle protokollieren, sodass die Administration später herausfinden kann, wer diese Rolle zu einem bestimmten Zeitpunkt innehatte, um das mit den ausgeführten Aktivitäten in einem System abzugleichen.
Nicht nur Personen können Rollen annehmen. Manche Komponenten (wie zum Beispiel virtuelle Maschinen) können beim Erstellen eine Rolle annehmen und Aktionen ausführen, die dieser Rolle zugewiesen wurden.
Rollen versus Gruppen
Sie fragen sich jetzt vielleicht: »Was ist der Unterschied zwischen einer Gruppe und einer Rolle?« Die zentralen Punkte sind:
In der Praxis legen viele Rollen auch die User (und Gruppen) fest, denen sie zugewiesen sind, und in manchen Fällen versorgt die Gruppenmitgliedschaft ihre Mitglieder mit einem einzelnen permanenten Satz an Berechtigungen (einer einzelnen Rolle). Die Begriffe werden oft bunt durcheinandergewürfelt, aber bei manchen Cloud-Providern ist die Unterscheidung wichtig (wie zum Beispiel bei AWS-IAM-Gruppen und -Rollen).
Ihre User und Automationen sollten nun Identitäten besitzen und dazu autorisiert sein, nur das zu tun, was getan werden muss. Jetzt müssen Sie sicherstellen, dass dies die Zeit überdauert.
Wie schon erwähnt, ist der Revalidierungsschritt in klassischen wie auch in Cloud-Umgebungen sehr wichtig, aber in Cloud-Umgebungen haben Sie eventuell keine zusätzlichen Schutzmechanismen (wie einen physischen Zutritt zu einem Gebäude oder Schutzmaßnahmen in der Netzwerkinfrastruktur), die Sie absichern, wenn Sie vergessen, einen Zugriff zurückzunehmen. Sie müssen regelmäßig jede Autorisierung kontrollieren, um sicherzustellen, dass sie weiterhin gebraucht wird.
Die erste Form der Revalidierung ist die automatische Revalidierung auf Basis bestimmter Parameter. Sie sollten beispielsweise ein System haben, das automatisch eine Anforderung zum Zurückziehen aller Zugriffsmöglichkeiten erzeugt, wenn jemand die Organisation verlässt. Beachten Sie, dass das einfache Löschen der Identität des Users eventuell nicht ausreicht, weil er gecachte Credentials (wie zum Beispiel Zugriffstoken) haben kann, die sich noch nutzen lassen, ohne sich anmelden zu müssen. In solchen Situationen benötigen Sie einen Offboarding Feed, bei dem es sich um eine Liste mit Entitäten handelt, deren Zugriff zurückgezogen werden soll. Jedes System, das langlebigere Credentials wie Zugriffstoken ausgibt, muss diesen Offboarding Feed mindestens täglich abarbeiten und den Zugriff dieser Entitäten direkt zurücknehmen.
Für die zweite Form der Revalidierung sind Einschätzungen durch Menschen dahin gehend erforderlich, ob eine bestimmte Entität immer noch Zugriff benötigt. Es gibt im Allgemeinen zwei Arten von einschätzungsbasierter Revalidierung:
Positive Bestätigung
Diese ist stärker – sie bedeutet, der Zugriff geht verloren, sofern nicht jemand explizit sagt: »Dieser Zugriff ist weiterhin erforderlich.«
Negative Bestätigung
Diese ist schwächer – sie bedeutet, der Zugriff bleibt bestehen, bis jemand sagt: »Dieser Zugriff ist nicht mehr länger erforderlich.«
Negative Bestätigung ist für Autorisierungsstufen mit geringeren Auswirkungen ausreichend, aber bei Zugriffen mit hohen Auswirkungen auf das Business sollten Sie positive Bestätigung nutzen. Ihre Nachteile sind, dass sie mehr Arbeit verursachen und der Zugriff unabsichtlich verloren gehen kann, wenn die Anfrage nicht rechtzeitig bearbeitet wird (was wiederum zu noch mehr Aufwand bei Operations führen kann).
Durch das Revalidieren verhindert man als größtes Risiko, dass jemand, der die Firma (vielleicht unter schwierigen Umständen) verlassen hat, noch mal Zugriff auf das System erlangt. Zudem tendieren Berechtigungen mit der Zeit dazu, sich anzusammeln – wie Krempel in der Krempelschublade in der Küche (Sie haben bestimmt auch so eine). Durch das Revalidieren wird dieser Krempel ausgemistet.
Wenn es allerdings schwierig ist, Zugriff zu erlangen, werden Ihre User häufig behaupten, sie bräuchten ihn, auch wenn dies eigentlich nicht mehr der Fall ist. Ihre Revalidierungsaufwände werden beim Zurückschneiden unnötiger Zugriffe viel effektiver sein, wenn Sie gleichzeitig einen schnellen und einfachen Prozess für das Zuweisen erforderlicher Berechtigungen haben. Ist das nicht möglich, kann es effektiver sein, den Zugriff automatisch zurückzuziehen, wenn er eine Zeit lang nicht mehr genutzt wird, statt zu fragen, ob er immer noch gebraucht wird. Das beinhaltet allerdings ein gewisses Risiko, weil Sie vielleicht niemanden mit Zugriffsrechten finden, wenn es notwendig ist!
Identity-as-a-Service-Angebote in der Cloud bieten neben dem Authentifizieren und Autorisieren zunehmend auch das Managen des gesamten Identitätslebenszyklus an. Mit anderen Worten: Provider erkennen die Wichtigkeit des Anfangs und Endes einer Beziehung und helfen dabei, das Beenden zu vereinfachen und zu formalisieren.
Was sind das alles für Tools?
Die Namen der diversen Tools, die beim Secrets und Identity Management helfen, können verwirrend sein. Es gibt durchaus unterschiedliche Ansichten zu den Namen, und viele Produkte erfüllen auch mehr als eine Funktion, aber hier möchte ich Ihnen einen Überblick über die gebräuchlichsten Namen und Funktionen geben:
Erinnern Sie sich an unsere einfache Webanwendung aus Kapitel 1? Ergänzen wir das Diagramm um Informationen zum Identity and Access Management, dann sieht es wie in Abbildung 4-3 aus. Ich habe die ganzen Trust Boundaries der Anwendung entfernt, damit es nicht zu unübersichtlich wird. Eine Beschreibung der Schritte, von denen viele aus mehreren Unterschritten bestehen, folgt noch.
Leider wird das Diagramm dadurch ein bisschen komplizierter! Schauen wir uns ein paar der neuen Interaktionen im Detail an:
Jedes Mal, wenn eine unserer Trust Boundaries der Anwendung passiert wird, muss die passierende Entität authentifiziert und autorisiert werden, um eine Aktion ausführen zu können. Es gibt noch weitere Trust Boundaries außerhalb der Anwendung, die hier nicht dargestellt sind, wie zum Beispiel die Trust Boundaries rund um die Systeme der Cloud und der Organisation.
Abbildung 4-3: Diagramm der Beispielanwendung mit IAM
Viele Organisationen sind in ihren On-Premises-Umgebungen aus historischen Gründen beim Identity and Access Management eher lax vorgegangen und haben sich zu sehr auf andere Sicherheitsmechanismen verlassen (wie zum Beispiel physische Sicherheit und Netzwerkbeschränkungen). IAM ist aber in Cloud-Umgebungen von überragender Wichtigkeit. Auch wenn die Konzepte bei On-Premises- und Cloud-Deployments ähnlich sind, gibt es neue Technologien und Cloud-Services, die die Sicherheit verbessern und das Leben einfacher machen.
Im gesamten großen Identitäts- und Zugriffslebenszyklus ist es leicht, die Anforderungs-, Genehmigungs- und Revalidierungsschritte zu vergessen. Diese lassen sich zwar manuell ausführen, aber viele As-a-Service-Angebote, die zunächst nur die Authentifizierungs- und Autorisierungsschritte übernommen haben, bieten nun auch Workflows für den Genehmigungsschritt – und das wird sich noch weiterentwickeln.
Zentrale Autorisierungssysteme geben der Administration und den Endusern eine einzelne Identität, die dann für viele verschiedene Applikationen und Services genutzt wird. So etwas gibt es zwar schon sehr lange, aber in Cloud-Umgebungen sind sie noch viel wichtiger, weshalb sie dort auch standardmäßig zur Verfügung stehen. Angesichts der Zunahme von Cloud-Systemen und -Services kann das Managen von getrennten Identitäten auf jedem einzelnen System und für jeden Service selbst bei kleinen Deployments schnell zu einem Albtraum werden. Alte, vergessene Identitäten werden vielleicht von ihren früheren Besitzern oder durch Angreifer wiederverwendet, die auf der Suche nach einem einfachen Zugangsweg sind. Selbst bei einer zentralen Authentifizierung müssen Sie immer noch gute Passwörter und Multifaktor-Authentifizierung nutzen. Die Cloud-Administration und die Enduser authentifizieren sich oft über unterschiedliche Systeme.
Wie bei den Authentifizierungssystemen ermöglichen zentrale Autorisierungssysteme, alles, wozu eine Entität autorisiert ist, an einem Ort zu sehen und zu bearbeiten. Das kann das Zuteilen und Zurückziehen von Zugriffsmöglichkeiten vereinfachen und macht Konflikte bei der Separation of Duties offensichtlicher. Achten Sie darauf, den Prinzipien von Least Privilege und Separation of Duties zu folgen, wenn Sie Personen oder Automatismen für Aufgaben autorisieren, und vermeiden Sie Identitäten und täglich genutzte Credentials mit Superkräften.
Secrets Management ist ein sich schnell weiterentwickelndes Feld. Dabei werden Secrets für den System-to-System-Zugriff getrennt von anderen Konfigurationsdaten gehalten und anhand strikter Prinzipien von Vertraulichkeit und Auditing gehandhabt. In manchen Fällen lässt sich eine System-to-System-Authentifizierung durch Identitätsdokumente realisieren, was den Bedarf von getrennt gehandhabten Secrets verringert. Secrets Management steht in bestehenden Produkten zum Configuration Management zur Verfügung, in eigenständigen Secrets-Server-Produkten und als As-a-Service-Cloud-Angebote.
Nachdem Sie nun verstanden haben, wie Sie eine der häufigsten Ursachen von Einbrüchen vermeiden – ein nicht ausreichendes Identity and Access Management –, wollen wir uns eine der anderen sehr wichtigen Ursachen anschauen: unzureichendes Vulnerability Management.
