Wenn MFA nicht ausreicht

Regel Nummer eins der Cloud-Sicherheit lautet: „Du sollst jederzeit MFA verwenden.“ Warum? Nun, beim Wechsel in die Public Cloud nehmen Sie im Grunde sämtliche administrativen Schnittstellen, fassen sie in einem einzigen Portal oder einer einzigen API zusammen und stellen sie dann … ins Internet, geschützt durch Benutzername, Passwort und (vielleicht) MFA. Selbst dann, wenn Sie eine Föderation einsetzen.

Doch es zeigt sich: Selbst MFA reicht nicht immer aus, wie mehrere große Sicherheitsvorfälle zeigen, darunter der Fall bei Uber.

Das ist einer der wichtigsten Unterschiede zwischen Cloud und traditioneller Infrastruktur, und deshalb hören Sie immer wieder den Satz „Identität ist der neue Perimeter“. Vor der Cloud haben wir unser Rechenzentrum aus privaten Netzwerken heraus verwaltet (oder über kontrollierte Zugangspunkte wie VPNs und Jump Boxes). Mit der Cloud steht all das standardmäßig im Internet und lässt sich nur schwer abschotten, zumal wir inzwischen häufiger remote arbeitende Mitarbeitende und Administratoren unterstützen.

MFA ist ein wirksames Mittel, um die Authentifizierung von Benutzern und Administratoren abzusichern. Es gibt zahlreiche Optionen, von etwas sicherer (nachrichtenbasierte MFA) bis richtig sicher (Hardware-Schlüssel). Das Problem selbst bei MFA ist jedoch, dass Benutzer dauerhaften Zugriff mit dauerhaften Berechtigungen haben. Wenn Sie einem Benutzer eine Rolle zuweisen, kann er diese Berechtigungen nach der Authentifizierung jederzeit nutzen. Angreifer wissen das und haben eine Reihe von Techniken entwickelt, um sich authentifizierten Zugriff zu verschaffen. Sie:

• missbrauchen statische Anmeldedaten, insbesondere wenn keine MFA im Einsatz ist.
• überwinden manche MFA-Verfahren. Beispielsweise nutzen sie SIM-Swapping, um Textnachrichten an Mobiltelefone abzufangen.
• bringen Administratoren durch Social Engineering dazu, MFA zu deaktivieren oder auf ein von ihnen kontrolliertes Gerät zurückzusetzen.
• bringen Benutzer durch Social Engineering dazu, einen MFA-Code preiszugeben.
• stehlen Sitzungsdaten vom System eines Benutzers, nachdem dieser sich bereits authentifiziert hat, und verwenden sie von einem System unter der Kontrolle des Angreifers aus.

Sobald ein Angreifer Zugriff erlangt hat, beginnt er, Berechtigungen auszukundschaften, und nutzt diese schließlich für schädliche Aktivitäten.

Least Privilege ist eine Lüge

Das Kernproblem ist, dass wir Berechtigungen nicht danach vergeben, was jemand zu einem bestimmten Zeitpunkt tun muss, sondern danach, was er künftig tun könnte. Benutzer, insbesondere Administratoren, verfügen über den maximalen Satz an Berechtigungen für alle möglichen Aktionen. Jeder Sicherheitsstandard der Welt fordert, dass IAM standardmäßig auf Deny und Least Privilege ausgelegt sein soll, doch das ist gewissermaßen eine Lüge, denn der Satz der „geringsten Berechtigungen“ wird durch den maximalen Satz an Berechtigungen definiert, die jemand irgendwann benötigt, nicht ständig.

Selbst wenn wir Benutzern erlauben, Rollen zu wechseln und in verschiedenen Sitzungen unterschiedliche Berechtigungen zu nutzen, haben sie fast immer jederzeit Zugriff auf diese Rollen. In Wirklichkeit sollte Least Privilege zeitgebunden sein, nicht nur benutzergebunden. Historisch verwalten wir Berechtigungen über die Zuweisung von Rollen, und Rollen verfügen über Berechtigungen in einem bestimmten Geltungsbereich. „Sie sind Administrator für diese 5 Konten und normaler Benutzer für die übrigen 98.“ Häufig weisen wir einem Benutzer sogar mehrere Rollen zu, die entweder Berechtigungen kombinieren oder zwischen denen er für unterschiedliche Aufgaben wechseln kann.

Stellen Sie sich vor, wie viel schwerer es ein Angreifer hätte, wenn wir dauerhafte Berechtigungen abschaffen. Statt dass ein Benutzer sich authentifiziert und Zugriff auf all seine Berechtigungen hat, erhält er Zugriff mit einem sehr kleinen Satz an Berechtigungen und muss für alles potenziell Schädliche eskalieren.

Mehr Sicherheit durch dynamische Autorisierungen

Ich schlage nicht vor, MFA oder andere Sicherheitsmaßnahmen auf Authentifizierungsebene abzuschaffen. Sie sind nach wie vor von entscheidender Bedeutung, aber manchmal reichen sie nicht aus. Das gilt besonders für die Cloud-Sicherheit, da hier von Haus aus eine größere Exposition gegenüber dem Internet besteht. Die Cloud bietet jedoch auch Vorteile, darunter sitzungsbasierte Föderation und feingranulare Autorisierungen (bis hinunter zu einzelnen API-Aufrufen).

Statt Benutzern dauerhaften Zugriff auf alle Berechtigungen zu geben, die sie jemals benötigen könnten, geben wir ihnen einen stärker eingeschränkten Zugriff, und sie fordern dann Zugriff auf erweiterte Berechtigungen an. Das ist kein neues Konzept; Produkte zur Verwaltung privilegierter Benutzer setzen es seit Jahren ein. Doch diese Produkte stützen sich häufig noch auf umständliche Techniken wie Proxy-Sitzungen und rotierende temporäre Passwörter. Die Cloud ist von Natur aus flexibler, da die nativen IAM-Modelle inhärent sitzungsbasiert sind und Berechtigungen in Policy-Dokumenten (typischerweise in JSON geschrieben) definiert werden.

So funktionieren Tools wie unser FireMon Authorization Control. Oder werfen Sie einen Blick auf Netflix ConsoleMe als Open-Source-Beispiel. Benutzer fordern Zugriff an, wenn sie ihn benötigen, und die Plattformen bestimmen anhand von Richtlinien, was für eine Genehmigung erforderlich ist. Sind diese Bedingungen erfüllt, etwa Freigaben durch eine Führungskraft oder eine Kollegin bzw. einen Kollegen, wird der Benutzer autorisiert, eine Rolle für eine Sitzung zu nutzen. Die Plattformen können sogar Bedingungen einfügen, etwa „diese Sitzung nur von der IP-Adresse erlauben, von der sie angefordert wurde“. Diese Anfragen laufen typischerweise out-of-band und nutzen Seitenkanäle wie ChatOps für Genehmigungen, wodurch der Prozess bewusst auffällig gestaltet wird, insbesondere bei sensiblem Produktionszugriff.

Sicherheit auf Autorisierungsebene macht das Leben für alle einfacher, von Entwicklern und Benutzern bis hin zu Sicherheitsadministratoren. Sie müssen den vollständigen Satz möglicher Berechtigungen nicht im Voraus kennen. Stattdessen fordern Benutzer das an, was sie brauchen, wenn sie es brauchen. Richtlinien bestimmen den reibungsärmsten Weg, diesen Zugriff bereitzustellen, ohne die Sicherheit zu beeinträchtigen. Tools wie ChatOps ermöglichen es einem Entwickler, Zugriff auf ein neues Konto anzufordern und innerhalb von Sekunden eine Antwort zu erhalten, statt eine Anfrage in einem Ticketsystem einzureichen, die Tage oder Wochen dauern kann.

Indem wir die Autorisierung absichern, verringern wir die Auswirkungen gestohlener Anmeldedaten und kompromittierter Authentifizierungen – und reduzieren zugleich Reibungsverluste und Aufwand.